SD332 - BUG with 4 byte NRF52 ANT Timestamps

[shaba]

ANT experts,

I have been looking at the nrf52 implementation of the ANT timestamp (and timesync) features. One thing that is rather puzzling is the fact that the documentation for the ANT protocol claims that the timestamp in the extended data will be at-most 2 bytes, while the code in the nrf52 includes seem to hint that we can have the timestamp in 2 byte or 4 byte modes (based on the way the timestamp-ing is configured).

Would this mean that the extended messages coming back from the event could potentially have 12 bytes of extended data (if all bits are set for which features are enabled)?

Edit1:

I think you guys meant to extend ANT_EXT_MESG_TIME_STAMP_FIELD_SIZE to 4 (from 2).

MESG_MAX_EXT_DATA_SIZE has the following definition:

(ANT_EXT_MESG_DEVICE_ID_FIELD_SIZE + ANT_EXT_MESG_RSSI_FIELD_SIZE + ANT_EXT_MESG_ALT_TIME_STAMP_FIELD_SIZE + ANT_EXT_STRING_SIZE)

and this corresponding comment

// ANT device ID (4 bytes) + ANT RSSI (4 bytes) + ANT timestamp (4 bytes) + ANT Ext String Size

Additionally, what happens to the extended fields if advanced burst or encrypted channels are enabled?

Thank you for clearing all this up - you guys rock!

Edit2:

When I enable the following

sd_ant_lib_config_set(ANT_LIB_CONFIG_MESG_OUT_INC_TIME_STAMP |
                      ANT_LIB_CONFIG_MESG_OUT_INC_RSSI |
                      ANT_LIB_CONFIG_MESG_OUT_INC_DEVICE_ID);

ANT_TIME_STAMP_CONFIG tsCfg =
{
    .ucTimeBase         = ANT_TIME_BASE_ALT2,
    .bTimeStampEnabled  = true,
};

err = sd_ant_time_stamp_config_set(&tsCfg);

I only get the top 24 bits of the RTC2 counter. Is this a bug that you guys need to resolve in the softdevice? This pretty much makes the RTC based timestamps un-usable!!

Edit3:

I think we might have a handle on whats afoot. I think the RTC value is being divided by 256 to take it from a 24 bit value to a 16 bit value. Furthermore, it seems like someone then took this adjusted value and writes 24 bits (MS-byte is always 0 due to the previous divide) to the timestamp extended field. This totally smells like a SD bug to me - and whats worse is if I assume that RTC reported in the TS message will always be divided by 256 and you guys fix the bug - our code will now break :) We can put in some detectors to work around this, but I would like confirmation from your side that we are not doing anything incorrectly. Please note that this error only occurs when the RSSI and the timestamp (ALT2 or ALT1) fields are enabled in tandem - is that not expected?

[Petter Myhre]

I guess I am. It seems to me that a 32 bit timestamp is reported. The MSB is always 0 because the RTC is 24 bits. The rest are the 24 bits of the RTC value. Maybe I'm misunderstanding. Maybe you can try to explain how you came to the conclusion that it is not the RTC value? Do you see this if you simply add sd_ant_lib_config_set(ANT_LIB_CONFIG_MESG_OUT_INC_RSSI); to the ant time synchronization example found in SDK 12.1?

[shaba]

Exactly. The 32 bit timestamps work just fine if the RSSI flag is not set. However, when the RSSI flag is enabled - the LSB of the 32 bit timestamps is set to 0 which gives us a 32 bit value with only the middle two bytes being significant. More to the point, we wish to enable the RSSI output, the Channel ID as well as the 32 bit timestamp for the extended messages; which we find results in the RTC value being less precise as I described above. Thanks for the help again Petter!

[Petter Myhre]

I'm not able to reproduce this. The LSB of 32 bit timestamps is not 0, with RSSI included. I tested with SDK 12.0.1 and S212 v2.0.0. Maybe you can upload your complete project so we can be sure we are on the same page?

[shaba]

I am using the sdk 12.0.1 with SD332. Could this be an oversight in the softdevice? I could try flipping to 212 and verify the behavior for you Petter. While I will not post my raw project code, I will construct a representative example which reproduces the issue that I am seeing.

[shaba]

Ok turns out that if you are using DBM style measurement, the RSSI_TYPE_DBM_EXT_MESG_FIELD_SIZE is only 3 bytes long. So even though the RSSI field claims to be 4 bytes always, the soon-to-follow timestamp field occupies the last of the 4 bytes in the RSSI field. I am pretty sure this is what is going on as the last byte of the RSSI is believable as the LSB of the timestamp :)