Leaps in Time in Logs with MTK-GPS

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 –

Replies

  • 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?
  • 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.
  • 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
  • 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

DIY Robocars via Twitter
RT @TinkerGen_: "The Tinkergen MARK ($199) is my new favorite starter robocar. It’s got everything — computer vision, deep learning, sensor…
Monday
DIY Robocars via Twitter
Monday
DIY Robocars via Twitter
RT @roboton_io: Join our FREE Sumo Competition 🤖🏆 👉 https://roboton.io/ranking/vsc2020 #sumo #robot #edtech #competition #games4ed https://t.co/WOx…
Nov 16
DIY Drones via Twitter
First impressions of Tinkergen MARK robocar https://ift.tt/36IeZHc
Nov 16
DIY Robocars via Twitter
Our review of the @TinkerGen_ MARK robocar, which is the best on the market right now https://diyrobocars.com/2020/11/15/first-impressions-of-tinkergen-mark-robocar/ https://t.co/ENIlU5SfZ2
Nov 15
DIY Robocars via Twitter
RT @Ingmar_Stapel: I have now explained the OpenBot project in great detail on my blog with 12 articles step by step. I hope you enjoy read…
Nov 15
DIY Robocars via Twitter
RT @DAVGtech: This is a must attend. Click the link, follow link to read the story, sign up. #chaos2020 #digitalconnection #digitalworld ht…
Nov 15
DIY Robocars via Twitter
RT @a1k0n: Got a new chassis for outdoor races (hobbyking Quantum Vandal) but I totally didn't expect that it might cause problems for my g…
Nov 11
DIY Drones via Twitter
First impressions of the Intel OpenBot https://ift.tt/36qkVV4
Nov 10
DIY Robocars via Twitter
Nov 9
DIY Robocars via Twitter
Excellent use of cardboard instead of 3D printing! https://twitter.com/Ingmar_Stapel/status/1324960595318333441
Nov 7
DIY Robocars via Twitter
RT @chr1sa: We've got a record 50 teams competing in this month's @DIYRobocars @donkey_car virtual AI car race. Starting today at 10:00am…
Nov 7
DIY Robocars via Twitter
Nov 6
DIY Robocars via Twitter
RT @a1k0n: Car's view, using a fisheye camera. The ceiling light tracking algorithm gave me some ideas to improve ConeSLAM, and having grou…
Nov 5
DIY Robocars via Twitter
RT @a1k0n: To get ground truth I measured the rug, found the pixel coordinates of its corners, calibrated my phone camera with my standard…
Nov 5
DIY Robocars via Twitter
RT @a1k0n: @DIYRobocars is back in December, but outside. Time to reinvestigate ConeSLAM! I rigged up a quick and dirty ground-truth captur…
Nov 5
More…