SD332 - BUG with 4 byte NRF52 ANT Timestamps

RE: SD332 - BUG with 4 byte NRF52 ANT Timestamps

shaba — Thu, 27 Oct 2016 21:43:00 GMT

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

RE: SD332 - BUG with 4 byte NRF52 ANT Timestamps

shaba — Tue, 25 Oct 2016 17:32:16 GMT

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.

RE: SD332 - BUG with 4 byte NRF52 ANT Timestamps

Petter Myhre — Tue, 25 Oct 2016 08:58:03 GMT

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?

RE: SD332 - BUG with 4 byte NRF52 ANT Timestamps

shaba — Mon, 24 Oct 2016 17:54:56 GMT

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!

RE: SD332 - BUG with 4 byte NRF52 ANT Timestamps

Petter Myhre — Mon, 24 Oct 2016 14:17:16 GMT

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?

RE: SD332 - BUG with 4 byte NRF52 ANT Timestamps

shaba — Fri, 21 Oct 2016 20:32:28 GMT

I think you are missing the point. I understand that the RTC is 24 bits - the value that your timestamp reports back is not the raw RTC value, but the RTC value divided by 256 (the 8 LSB bits are always 0). This makes it 256 times more coarse than we would like it...

RE: SD332 - BUG with 4 byte NRF52 ANT Timestamps

Petter Myhre — Thu, 20 Oct 2016 14:34:19 GMT

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.

RE: SD332 - BUG with 4 byte NRF52 ANT Timestamps

shaba — Wed, 19 Oct 2016 22:55:31 GMT

Appreciate it Petter! I am happy to run any experiments for you as well. I figure it is more useful for NRF to have these discussions here as well. It will be nice to see this community embrace ANT like they embrace BLE :)

RE: SD332 - BUG with 4 byte NRF52 ANT Timestamps

Petter Myhre — Wed, 19 Oct 2016 10:10:50 GMT

I think Dynastream is better suited to answer this, but I will try to look into it.

RE: SD332 - BUG with 4 byte NRF52 ANT Timestamps

shaba — Tue, 18 Oct 2016 19:03:52 GMT

I have also posted this in the dynastream wiki here: www.thisisant.com/.../