NMEA Import - Times Out by Factor of 4

As it's not possible to have my Android phone physically connected during my recording sessions, I log sessions as an NMEA file from a USB GPS (BN-808) onto a small data-logger for the purposes of importing into RaceChrono Pro version 5.4.4 afterwards. The GPS has been flashed to update at 5 Hz and this frequency is representative within the NMEA file. The session NMEA file was created using the gpsd utility gpspipe and contains RMC, GGA, ZDA and VTG sentences.

I select the NMEA file within "experimental devices" successfully and run the session in RaceChrono and it imports without error on my Android device.

Unfortunately, the lap times shown for sessions in RaceChrono appear to be out consistently by a factor of 4, i.e. the lap times shown in RaceChrono are slower than the real lap times. Similarly, the session duration shown in RaceChrono is 4 times longer than the real session duration.

I see from a previous forum message from @aol (http://racechrono.com/forum/discussion/1240/import-exported-data-from-harrys-laptimer-iphone-version-in-to-racechrono) that the NMEA debug import function plays back at 4x speed - is this play-back factor of 4 connected to my issue?

Comments

  • edited August 2018
    @dfens, the NMEA device is sped up, due to debugging purposes. No time to wait for the actual time. Time from the GPS data are used, not the phone time, so even when speeding up the data, it will still result real world lap times.
  • edited August 2018
    I took a look at your NMEA file, and the problem is that RaceChrono thinks that the time is moving backwards, because GNGGA/GNRMC have decimals in timestamps, and GPGGA/GPRMC do not, and compensates for it. The compensation serves as workaround fix to bugs (time moving backwards) in other receivers.

    So when your receiver says 170145.80 on GNGGA and then 170145 on GPGGA sentence, it thinks time moved .80 backwards and compensates. To fix this, filter your files so that it has only GPGGA+GPRMC or only GNGGA+GNRMC sentences. I recommend doing the latter as it has more precision in timestamps, so it will result 5 Hz data instead of 1 Hz.

    Of course RaceChrono should accept different time formats for GN* and GP*, I'll put this to my TO-DO list but it is on low priority...
  • All sorted at my end by filtering the NMEA sentences! - thanks @aol
Sign In or Register to comment.