Discussions

Leaps in Time in Logs with MTK-GPS

Posted by Andrés on November 27, 2010 at 9:03am
Hi,

I got yesterday my APM with a MediaTek GPS. I've been figuring out how to read the log files. I had some success and was able to make and read a log of a walk around my block:


This looks in principle fine, but the data seems to have time leaps  (e.g. height)


I also find in the serial data several duplicated packages (same time, same data). If I filter all 0-locks and the duplicated data entries and then plot the data against their index (instead of time), I get a more or less continuous curve:


Has anyone experienced this? Is the time delivered by the GPS module reliable? Are there any other sources for time?

Cheers,

Andrés


You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –
Follow

Replies

  • Mark Grennan December 3, 2010 at 5:53pm
    I'm setting up to help with a GPS study. I have created cables to speak to all the ports on the APM.

    I have reserved this same issue watching the Ground Station when the APM is connected to the GPS emulator. Meaning the GPS emulator connect to the APM and then the APM sends telemetry to the GS. I have not investigated this yet. It could be the GPS Emulator or it could be coming from the APM. I have also not investigated what the APM is recording.

    Can you post more info on how you are processing the APM downloads?
  • hopslink November 28, 2010 at 1:24am
    The encoding looks like HH:MM:SS:ms(3) since SS increments on a 1000 count of ms and MM increments as SS reaches 60.

    That also explains your plots periodic 60 seconds of data followed by 40 second 'jumps'.

    Interesting that resolution only appears to be to 250ms.
  • Andrés November 27, 2010 at 11:58pm
    Thanks for the answer Ken. I have an idea what the problem is. It seems to be how the time is coded. I read something yesterday of ms since week start (?), so I ussumed that the time is coded as ms. In reality this time is UTC coded as hhmmssddd (?). Is this coding standard for all modules?

    If I take only the GPS entries around the jump it looks like:

    GPS:123859000,1,8,49.4290542,8.6811857,124.70,-21474836.00,1.82,66.84
    GPS:123859000,1,8,49.4290542,8.6811857,124.70,-21474836.00,1.82,66.84
    GPS:123859250,1,8,49.4290504,8.6811923,124.69,-21474836.00,1.84,71.12
    GPS:123859250,1,8,49.4290504,8.6811923,124.69,-21474836.00,1.84,71.12
    GPS:123859250,1,8,49.4290504,8.6811923,124.69,-21474836.00,1.84,71.12
    GPS:123859500,1,8,49.4290504,8.6812000,124.67,-21474836.00,2.06,74.10
    GPS:123859500,1,8,49.4290504,8.6812000,124.67,-21474836.00,2.06,74.10
    GPS:123859750,1,8,49.4290504,8.6812067,124.66,-21474836.00,2.10,76.39
    GPS:123859750,1,8,49.4290504,8.6812067,124.66,-21474836.00,2.10,76.39
    GPS:123859750,1,8,49.4290504,8.6812067,124.66,-21474836.00,2.10,76.39
    GPS:123900000,1,8,49.4290504,8.6812124,124.65,-21474836.00,2.57,78.62
    GPS:123900000,1,8,49.4290504,8.6812124,124.65,-21474836.00,2.57,78.62
    GPS:123900250,1,8,49.4290504,8.6812229,124.64,-21474836.00,2.37,81.54
    GPS:123900250,1,8,49.4290504,8.6812229,124.64,-21474836.00,2.37,81.54
    GPS:123900250,1,8,49.4290504,8.6812229,124.64,-21474836.00,2.37,81.54
    GPS:123900500,1,8,49.4290504,8.6812314,124.62,-21474836.00,2.12,82.80
    GPS:123900500,1,8,49.4290504,8.6812314,124.62,-21474836.00,2.12,82.80
    GPS:123900750,1,8,49.4290504,8.6812381,124.61,-21474836.00,2.56,84.29
    GPS:123900750,1,8,49.4290504,8.6812381,124.61,-21474836.00,2.56,84.29
    GPS:123900750,1,8,49.4290504,8.6812381,124.61,-21474836.00,2.56,84.29
    GPS:123901000,1,8,49.4290504,8.6812467,124.60,-21474836.00,2.28,85.78
    GPS:123901000,1,8,49.4290504,8.6812467,124.60,-21474836.00,2.28,85.78

    So essentially it jumps from 123859750 to 123900000, i.e. this cannot be decimal ms, which speaks for UTC in the above mentioned coding...

    Thanks,

    Andrés
  • Ken November 27, 2010 at 2:37pm
    In general GPS time can be considered very accurate. But, given UAV type use -- fix is valid --> update location; fix is invalid --> coast, it is possible that the time output of the MediaTek is not debugged.

    However, I think that we have not really examined what the different GPS modules do when they lose lock. You write of duplicated times. From that, it seems that when the MediaTek loses lock, not only does the position information freeze, so does the time output. In some ways that makes sense, yet the GPS must have a very accurate clock so one would expect time data to be "reasonably accurate" for a few minutes after loss of lock, eh?

    When am I going to find the time to test this...
This reply was deleted.

Activity