estTimestamp difference between two events

Username		Password		Remember Me?	forgot password?

25 May 2016 06:56 AM

bugno Newbie

Total Posts: 16

Joined 2013-10-23

Hello all,

ANT+ newbie here, so sorry if the answer is obvious.

I am recording/logging data from ANT+ powermeter (PT SL+) with an Android app using the ANT+ SDK.

I compare the values with a Joule 2.0 computer. The values match well 99% of the time but
sometimes whereas delta between two times in the CSV file from Joule 2.0 is 0.016-0.017 minutes (~1 second), with my app using ANT+ SDK, I get generally the same timesteps but sometimes higher (0.021) or lower (0.015) which may be annoying as I should trust this time step for another calculations. See the picture below (log from my app). I am using estTimestamp to compute time.

So my question is:

Do we expect a constant 1 second between two events for ANT+ powermeter with time-synchronous update or more or less one second is possible? I suspected a latency/lag in my app so I tried to deactivate other tasks to only record/write data from the powermeter but without success for the moment.

Any answer or advice will be appreciated,

Thanks,

Pierre

Image Attachments

Click thumbnail to see full-size image

Signature

Blog

31 May 2016 10:17 AM #1

BK Sr. Member

Total Posts: 120

Joined 2013-05-07

PM

Hi bugno,

What do you mean by time-synchronous update? Why are you expecting an update rate of approximately 1 second?

I'm not sure if I correctly understood what you are seeing, but from my understanding, what you are seeing here most likely is the effect of Rx failures that is a consequence of the RF environment. Bike Power sensors transmit at 4 Hz, and so timestamps received in events should generally be 1/4 of a second apart (including background pages). But pages transmitted by the Bike Power sensor are not always received by receiving display devices because of poor RF, causing a gap in the received timestamps. Rx failures are common and to be expected.

Other things to note:

The estimated timestamp value is generated by the Android device's ANT chip when the ANT packet containing the relevant information is received. When a packet is received, an event is generated for each relevant piece of data, and the estimated timestamp of when the packet was received is passed in the event. The estimated timestamp value really should not be used for anything other than correlating different events to see if they were received in the same packet. Estimated timestamps should generally not be used to compute time, but if you are using it for time, please account for timestamp rollovers in your calculations.

For any given page transmitted by a Bike Power device, the timestamp on the receiving devices cannot be expected to be the same because timestamp is generated on the receiving devices and not transmitted by the Bike Power device. Therefore, while the Joule and the Android will receive the message at approximately the same absolute time, each will assign a different value for its estimated timestamp relative to when it's clock's zero started, though deltas between messages should still be the same.

Also, since timestamps are generated on the ANT chip - below the firmware layer, applications and tasks running in Android OS will not have an impact of the timestamp value.

Further reading:

ANT Message Protocol Document
ANT+ Bike Power Device Profile.

31 May 2016 02:30 PM #2

bugno Newbie

Total Posts: 16

Joined 2013-10-23

PM

I'm not sure if I correctly understood what you are seeing, but from my understanding, what you are seeing here most likely is the effect of Rx failures that is a consequence of the RF environment. Bike Power sensors transmit at 4 Hz, and so timestamps received in events should generally be 1/4 of a second apart (including background pages). But pages transmitted by the Bike Power sensor are not always received by receiving display devices because of poor RF, causing a gap in the received timestamps. Rx failures are common and to be expected.

Other things to note:

The estimated timestamp value is generated by the Android device's ANT chip when the ANT packet containing the relevant information is received. When a packet is received, an event is generated for each relevant piece of data, and the estimated timestamp of when the packet was received is passed in the event. The estimated timestamp value really should not be used for anything other than correlating different events to see if they were received in the same packet. Estimated timestamps should generally not be used to compute time, but if you are using it for time, please account for timestamp rollovers in your calculations.

For any given page transmitted by a Bike Power device, the timestamp on the receiving devices cannot be expected to be the same because timestamp is generated on the receiving devices and not transmitted by the Bike Power device. Therefore, while the Joule and the Android will receive the message at approximately the same absolute time, each will assign a different value for its estimated timestamp relative to when it's clock's zero started, though deltas between messages should still be the same.

Also, since timestamps are generated on the ANT chip - below the firmware layer, applications and tasks running in Android OS will not have an impact of the timestamp value.

I very appreciate your answer cause I spent a lot of time reading the ANT+ documents and looking for information here and other forums, since my post. I understand now more clearly what happens, after logging each received event, and thus detecting (with event count) missing ones. I also see that Joule 2.0, when an event not arrives enough quickly each second, duplicate the previous values (speed, cadence, power).

Thanks to you, I understand now that estTimestamp is an Android device time when the packet is received and I should decide what to do with it. I fear that my next question will not receive the desired answer but maybe: is there a way to have a timestamp when the record is done on the Bike Power device ?

One another thing I notice from several recent tests I (1 hour of recording my PowerTap SL+ data), that average time between two received events (RawWheelTorque) is 1003.4-1003.5ms. It is calculated by the difference estTimestamp of the last and the first event received during an hour divided by the UpdateEventCount number (example in the pm.csv file).

So either I use the Joule strategy: period is supposed one 1 second and record is duplicated when packet not received at time (10 to 11 times per hour IME), either I suppose a 1.003s period and I can record the data without using estTimestamp.

Pierre

File Attachments

pm.rar (File Size: 248KB - Downloads: 0)

Signature

Blog

31 May 2016 03:39 PM #3

BK Sr. Member

Total Posts: 120

Joined 2013-05-07

PM

Hi Pierre,

Is there a way to have a timestamp when the record is done on the Bike Power device? No.

If your concern is not recording duplicate packets (packets with the same value from the same measurement event, but received multiple times), I would use the Update Event Count field. If the Update Event Count has incremented, record the value. If it remains the same, ignore the event. Note the "Event" referred to by the Update Event Count field is not the Android event, but the information update event on the Bike Power device.

And just a note, the one second interval between wheel torque events cannot and should not be relied upon. Depending on the Bike Power device's implementation, this period could increase or decrease. Rx failures will also affect the veracity of the period.

Let me know if you have further questions.

31 May 2016 11:37 PM #4

bugno Newbie

Total Posts: 16

Joined 2013-10-23

PM

Thanks again BK,

Pierre

Signature

Blog

ANT Forum