Eddystone TLM secCount always starts with 0

[yuecelm]

normally the secCount in Eddystone TLM should be the time since power-on or reboot:

https://github.com/google/eddystone/blob/master/eddystone-tlm/tlm-plain.md

but the current implementation looks like this in components/ble/ble_services/eddystone/es_security.c

    m_security_slot[slot_no].timing.time_counter = APP_CONFIG_TIMING_INIT_VALUE;

so while generating EID secCount will be always set to APP_CONFIG_TIMING_INIT_VALUE, which is in my case 0.

Is there an explanation for this non-standard behaviour?

[tesc]

Hi,

I need some help to better understand what is the issue, so that I can verify and file a bug report.

From what I can tell, time_counter is correctly updated through the function es_security_update_time() whenever a beacon packet is sent (see the callback function adv_evt_handler() in nrf_ble_es.c.)

time_counter is set to APP_CONFIG_TIMING_INIT_VALUE on Eddystone module initialization, and/or when an EID slot is configured. Is this the issue, that it should have been set to a non-zero value (or not set at all) in any of those situations?

Regards,
Terje

[yuecelm]

the problem is that time_counter is also used for secCount in Eddystone TLM, and "when an EID slot is configured" is not really the same as "time since power-on or reboot"

[tesc]

Hi,

I am afraid I do not see any connection between time_counter and TLM.

Looking into nRF5 SDK v15.3.0, which is currently the newest release, I find es_tlm.c to use its own stopwatch for populating the SEC_CNT field. It is initialized in es_tlm_init(). Where is the link between the TLM frame in es_tlm.c and the time_counter value in es_security.c?

In es_tlm.c, the SEC_CNT field is called "ADV_SEC" in a code comment, which is incorrect. The es_tlm_frame_t structure correctly uses the name sec_cnt for the field. I think this should be aligned to both use the same terminology, but I do not know if that alone is enough to warrant an update.

Regards,
Terje

[yuecelm]

sorry, you are right, give me some time to re-analyse the problem...