taming FTSP is anything but trivial | Pale Blue Dot
Elapsed Time on Arrival: A simple and versatile primitive for canonical time synchronization services
Clock drift due to temperature can be modeled as 2nd or 3rd order of (ambient temperature and reference temperature)timestamping bug
CC2420 and microsecond precision timestamps (how to decide if packet-level sync iw working) Bug in CC2420 timestamp: edge cases
resynchronization period
Surprisingly, too frequent synchronization to be detrimental to prediction quality. The reason is the limited size of the FTSP regression table, which is 8 entries by default. If the synchronization points are closer together, the drift prediction is less accurate.
"Just before sending a FTSP message, the radio driver adds the time elapsed between the message send request and the actual transmission start to the message. In the reference implementation, the receiver adds this relative value to its local time and not the received global time. We observed that this relative time can be high enough that when coupled with high clock drift, this way of calculation can cause a noticeable error in predictions. We modified the implementation so that this relative value is added to the received global time instead of the local time." This may well be misunderstanding of TEP133, which the reference implementation is compliant with.
There are two parts to a global time report - the global timestamp
and the delay between that timestamp and the time of radio transmission.
The latter is calculated and appended to the FTSP message by the radio
driver (an important feature of FTSP). Observing the global timestamp did
not give any indication of error. However, when observing the delay value, it
was negative on occasion. By debugging the radio driver layer, we discovered
that the delay calculation was flawed.
We managed to trace this back to a yet another bug in the radio driver, this time
in the radio reception code. Again, the incoming transmission was timestamped in a similar fashion as with transmission
FTSP parameters
throwout limit parameterresynchronization period
Surprisingly, too frequent synchronization to be detrimental to prediction quality. The reason is the limited size of the FTSP regression table, which is 8 entries by default. If the synchronization points are closer together, the drift prediction is less accurate.
"Just before sending a FTSP message, the radio driver adds the time elapsed between the message send request and the actual transmission start to the message. In the reference implementation, the receiver adds this relative value to its local time and not the received global time. We observed that this relative time can be high enough that when coupled with high clock drift, this way of calculation can cause a noticeable error in predictions. We modified the implementation so that this relative value is added to the received global time instead of the local time." This may well be misunderstanding of TEP133, which the reference implementation is compliant with.
There are two parts to a global time report - the global timestamp
and the delay between that timestamp and the time of radio transmission.
The latter is calculated and appended to the FTSP message by the radio
driver (an important feature of FTSP). Observing the global timestamp did
not give any indication of error. However, when observing the delay value, it
was negative on occasion. By debugging the radio driver layer, we discovered
that the delay calculation was flawed.
We managed to trace this back to a yet another bug in the radio driver, this time
in the radio reception code. Again, the incoming transmission was timestamped in a similar fashion as with transmission
Read full article from taming FTSP is anything but trivial | Pale Blue Dot
No comments:
Post a Comment