ANT Forum

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? And lastly, the ANT protocol spec claims that only one channel can be encrypted in a node, I assume that either this means (1) Only one channel can be encrypted at a time, but multiple can be encryption-capable -or- (2) Multiple channels can be simultaneously encrypted.

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

Edit2:

When I enable the following



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?      

Hi,

1) Correct, you can now have 12 bytes of extended data excluding the burst string. This is indicated by the MESG_MAX_EXT_DATA_SIZE definition which is (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). That is 4 + 4 + 4 + 16.

2) ANT_EXT_MESG_TIME_STAMP_FIELD_SIZE was replaced by ANT_EXT_MESG_ALT_TIME_STAMP_FIELD_SIZE in the maximum definition. The ALT time stamp is 4 bytes.

3) If advanced burst or encryption is enabled, the extended string will be shifted based on the time stamp. If the time stamp is an ANT timestamp (2 bytes) the extended string will start at byte 10. If you are using the RTC the extended string will start at byte 12.

4) Multiple channels can be encrypted simultaneously.

5) The nRF52 defines 24-bit RTC's, so it should align with RTC measurements taken in the application.

6) There is no manipulation of the timestamp data. Perhaps the prescaler is dividing it by 256 in the application settings?

Could you send some message data example of when the RSSI issue occurs? I've placed an example on how to parse the timestamp from the extended data below:


     

Our RTC2->PRESCALER is set to 0. I noticed that when I do not enable the extended RSSI settings in the ANT library config, the 4 byte RTC value is as expected (24 bits of significant data). However, I find that when I enable both in parallel - the RTC value seems to be incorrect as I noticed above.

I will confirm this today and post the raw packet data that we are receiving from our broadcaster.      

Raw broadcast message received:


Here is my interpretation of the same:


The actual RTC2->COUNTER value at the time this message was processed was `0x0000f3cd`. I expect the timestamp to contain an RTC value that is a little before this value as it should tell us when the RX got the packet. However, the timestamp data only contains the `0xf3 and 0x00` of significance.

Edit:

It almost seems like the RSSI data should be 3 bytes and the 0xc1 from the RSSI really belongs to the timestamp. This might also be a SD 332 only issue, which I can verify if need be.

Edit2:

Noticed that RSSI_TYPE_DBM_EXT_MESG_FIELD_SIZE is 3 not 4, could this be the issue and we are just off by a single byte?      

Correct, the RSSI data is actually 3 bytes and not 4 bytes, which does look to be the source of your issue.      

Awesome, thank you Harrison!