Hello!
I'm currently testing a simple homemade datalogger that sends out $RC2 sentence like:
$RC2,,0,-0.02,0.02,0.98,,,1.11,0.96,84.46,,,,,*23
$RC2,,1,-0.02,0.01,0.98,,,0.75,1.04,84.43,,,,,*2D
$RC2,,2,-0.02,0.02,0.98,,,0.94,1.19,84.89,,,,,*28
$RC2,,3,-0.02,0.02,0.99,,,0.62,1.01,84.80,,,,,*21
$RC2,,4,-0.02,0.01,0.98,,,-0.03,1.03,85.04,,,,,*1
$RC2,,5,-0.02,0.01,0.98,,,-0.58,1.10,85.25,,,,,*F
$RC2,,6,-0.02,0.01,0.98,,,-1.02,1.17,85.46,,,,,*0
$RC2,,7,-0.02,0.01,0.98,,,-1.30,1.19,85.68,,,,,*2
$RC2,,8,-0.02,0.02,0.98,,,-1.57,1.25,85.89,,,,,*F
$RC2,,9,-0.02,0.01,0.98,,,-1.76,1.26,86.09,,,,,*6
$RC2,,10,-0.02,0.01,0.98,,,-1.84,1.24,86.31,,,,,*3A
$RC2,,11,-0.02,0.02,0.98,,,-1.70,1.05,86.63,,,,,*37
$RC2,,12,-0.02,0.02,0.98,,,-1.82,1.08,86.83,,,,,*3A
$RC2,,13,-0.02,0.02,0.98,,,-1.93,1.10,87.04,,,,,*3C
$RC2,,14,-0.01,0.03,0.98,,,-1.71,0.83,87.50,,,,,*3F
so with only the counter made with an incrementing variable. Data rate is about 3Hz. Gps is the internal one of the phone (tested with two android phones).
How are supposed to work the counter/timestamp fields? I'm experiencing big delays (in the order of 9 or 10 sec in one of the two phones, around 5 in the other one) between GPS data and $RC2 graph, even if the "live" data display is in sync...
Thanks,
Stefano
Comments
Anyway, the real "problem" is that I see the live values with correct timing while I drive, but when I check the graphs they are not saved in sync with gps traces.
For example: https://www.dropbox.com/s/p8gico43tgy0p88/2015-05-27 23.30.31.png?dl=0
The purple line is the lean angle (not perfect, about -13°deg off) and it is about 9sec ahead of the gps trace (the S turn in the map that is the dip at 1213sec of speed plot).. But while I was driving data was correctly showed in real time..
Any advice? Should I use timestamp (don't know how..)?
Thanks
Stefano
RaceChrono tries to mitigate the change in delays in the Bluetooth connection, using the counter field. So it figures out the (constant) update rate the device outputs, and then uses the counter field to estimate the "real" timestamp for each update. So if the update rate changes a lot and the counter field does not match this, it can throw off the timing.
If you use timestamps it practically means you need to have GPS chip on the device, as the timestamp needs to be GPS timestamp, otherwise it will not be in sync with the other data recorded.
Thank you!
Stefano