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'm not sure what SDK you are using, but I'm using SDK 12.0.1 with S212 v2.0.0.

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).

I understand that you find that puzzling, but I think this is explained here.

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)?

I think so, it actually seems it can be 40 bytes:

#define ANT_EXT_MESG_DEVICE_ID_FIELD_SIZE    ((uint8_t)4)
#define ANT_EXT_MESG_RSSI_FIELD_SIZE         ((uint8_t)4)  // maximum RSSI field size regardless of RSSI type
#define ANT_EXT_MESG_TIME_STAMP_FIELD_SIZE   ((uint8_t)2)
#define ANT_EXT_MESG_ALT_TIME_STAMP_FIELD_SIZE ((uint8_t)4)
#define ANT_EXT_STRING_SIZE                  ((uint8_t)16) // additional buffer to accommdate for 24 byte advance burst mode & encrypted usr data

// The largest serial message is an ANT data message with all of the extended fields
#define MESG_ANT_MAX_PAYLOAD_SIZE            ANT_STANDARD_DATA_PAYLOAD_SIZE

#define MESG_MAX_EXT_DATA_SIZE               (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) // 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?

Please add this as new question.

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!!

The RTC2 is a 24-bit counter.

Edit: Added link.

[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.