GPS-RaceDAC synchronisation problem

JakobB88

Hello,

i've got a synchronisation problem with a selfmade datalogger that uses the $RC2 sentence format to communicate with RaceChrono 4.3.9 on my Android phone (Samsung S4 mini):

$RC2,[time],[count],[xacc],[yacc],[zacc],[rpm/d1],[d2],[a1],[a2],[a3],[a4],[a5],[a6],[a7],[a8]*checksum

I send the $RC2 sentence with 50Hz via bluetooth and use the count field. I use the Qstarz bt-q818xt GPS module with the 5 Hz mode.

The figure shows the normalized velocity measured by the GPS module an my datalogger.

https://www.dropbox.com/s/riohz0puealnnws/syncProblem.png?dl=0

The time delay in the beginning of the measurement is much smaller then in the end. It seems the GPS time stamps in the exportet vbo file is correct (the lap times are correct).

Can anyone pleaae help me?

Best regards, Jakob

aol_of_RaceChrono

Is it possible your device has large tx buffer and too small tx throughput? RaceChrono algorithms should compensate anything else.

_Ra_

There may be lot of reasons and almost all of them not connected with RaceChrono. I would suggest starting with low level and your device first: check for example if you didn't set up your code or timer interrupt in your hardware a bit off. Reduce the output rate to 1Hz, compute and output some timestamp values and compare with a clock if the timestamps are aligned all the time after some longer period. Then increase the output frequency and check the same.

I had similar issues in my previous setup and at the end it seemed to be a problem with BT-q818xt. The timestamps and positions sent from GPS seemed to be precise but sent with some delay and the speed of sending them from (probably) some buffer within GPS was not constant resulting in varying delay between GPS and my own data. I haven't managed to overcome this. Instead I changed the general idea of the device and stopped using external gps.

There were threads discussing similar issues:
http://www.racechrono.com/vanilla/discussion/942/whats-the-best-settings-for-use-with-the-qstarz-818xt
http://www.racechrono.com/vanilla/discussion/951/racechrono-with-qstarz-q818xt-obd2-poor-synchronization-lag

aol_of_RaceChrono

I was looking at the graph wrongly, so it cannot be the home built device that is buffering... The GPS data is getting late, and the logger is advancing. Can you give me one hour of raw data from your home built device? Even better if you can include a relative timestamps for each sentence to the log, it would allow me to simulate the timing too. Then I could build a simulator and see if there's something wrong with my algorithms.

Notice it's important to increase the counter even if you have to drop a sentence. Because that's a sure way to have your logger data advanced, if you do updates like this:
0.1s counter = 1
0.2s counter = 2
0.3s counter = 3
0.8s counter = 4
0.9s counter = 5
1.0s counter = 6

What you need to do is:

0.1s counter = 1
0.2s counter = 2
0.3s counter = 3
0.8s counter = 8
0.9s counter = 9
1.0s counter = 10

aol_of_RaceChrono

By looking at my code, the time can drift if the update interval is not exactly 10ms, 20ms, 30ms, 40ms, 50ms, 60ms, 70ms, 80ms, 90ms, 100ms, 200ms, 300ms, 400ms, 500ms, 600ms, 700ms, 800ms, 900ms or 1000ms. So I'm guessing your update interval is something like 21ms? Can you check?

If this is the case, should of course fix my code to allow this...

JakobB88

Thanks Ra and aol for your fast support!

Here is an example of the dataloggers output saved on a sd-card but it is the same sentence send to RaceChrono with bluetooth. The relative timestamps are at the last field in milliseconds.

https://www.dropbox.com/s/wucf7lncgmfijc7/DATALOG_part.TXT?dl=0

Oh damn, now i see every 1000ms i have a big delay between two counts (aroaund 77ms) because i'm closing the file on the sd-card in that moment. That should cause trouble with your counter-sync-method.

I will fix that and report again!

aol_of_RaceChrono

Yes that will screw it up