Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

ANT Time Synchronization Example Understanding

Rank

Total Posts: 2

Joined 2016-09-05

PM

Hello,

could you please explain how the time synchronization works?

What does the function sd_ant_time_sync_broadcast_tx(...) do? Does it include the rtc value of the transmitter into the message that is sent to the receiver when the transmitter sends the message? If this is true, what is the value of the flag byte of the extended data message the receiver receives?

How is the time synchronized? The lower 2 Bytes of the transmitter's rtc is also sent to the receiver as part of the payload and then the receiver does
comp_chann_val = time_stamp - offset + LED_INVERT_PERIOD;
for what?

Thanks      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

Hi,

We're working on an app note to describe how the feature works, but in the meantime I can give a brief summary here.

As ANT uses an "isochronous adaptive coexistence" scheme, the application does not know when exactly a message it requests to send is actually transmitted over the air to potential receivers.

The sd_ant_time_sync_broadcast_tx function tells the ANT stack to use the 2 byte RTC time placed in bytes 6-7 of the payload as a starting event time on the transmitter, and then before the message is scheduled for transmission, this value is replaced with the offset between that event time and when the message was actually transmitted over the air.

This offset is then used in the equation you listed above by receivers to determine when the last timing event occurred on the transmitter, and then set up the next timing event so that they can now both fire that event simultaneously next time (or set a common time, etc).

The "page invalidation" and "page number" fields are used to help make determining invalid events easier if the application is not continuously updating the master channel with new messages.

If the ANT channel is running faster than the timing events, and the application does not update the transmit buffer using any transmit message function, then the stack will automatically update the page number field with a pre-specified "invalid page number", to indicate that the re-transmitted time sync message is no longer valid.      
Rank

Total Posts: 11

Joined 2016-05-08

PM

While your example uses RTC1 (in the SDK 1.2?), I assume the same will be true of RTC2 as well when using the appropriate time base. One thing that I found particularly confusing was the code's comments for the ANT_TIME_BASE_ defines:

#define ANT_TIME_BASE_ANT      ((uint8_t)0x00) ///< Local ANT time (2 byte time stamp)
#define ANT_TIME_BASE_ALT1     ((uint8_t)0x01) ///< RTC1 (4 byte time stamp)
#define ANT_TIME_BASE_ALT2     ((uint8_t)0x02) ///< RTC2 (4 byte time stamp) 


There should be some comment there saying that time sync will use two bytes when the appropriate time base is used as a time sync. Alternatively add a note in the ANT_TIME_SYNC_CONFIG declaration which tells the developer what to expect out of the feature.

Additionally, does setting the invalidation to true mean that on a roll-over, you will also write the first byte of the payload with the invalidation byte set in the config?      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

Hi,

Thanks for the feedback. Correct, RTC2 would display the same behavior as well.

In a nutshell, if invalidation is enabled, it means that if the application does not update the transmit buffer by calling one of the "send X message" functions before ANT re-transmits it, then the invalidation byte will be sent instead to indicate to receivers that the time sync value is no longer valid.

We're planning to release an application note which will explain these features in further detail by the end of the week.