Replies to This Discussion

Permalink Reply by Ken on November 27, 2010 at 3: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...

• ▶ Reply

Permalink Reply by Andrés on November 28, 2010 at 12:58am

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

• ▶ Reply

Permalink Reply by Ken on November 28, 2010 at 10:50am

When the time does not advance, neither does the position. The data just repeats. A guess would be that you have the data output rate higher than the internal recalculation rate. Or, the data repeats during loss of lock, then suddenly jumps forward.

If these are "the jumps", then at other times both time and position do update consistently? Got a data example for that?

• ▶ Reply

Permalink Reply by Andrés on November 29, 2010 at 12:08am

Hi Ken,

the jumps came from the wrong time encoding, well I was just interpreting the time wrong. Still it is intriguing that the GPS is updating only every 250 ms, i.e. the update rate is rather 4 Hz. I tried to update the firmware of the module but failed due to this ominent "Fail!!(Download) BROM_CMD_START_FAIL" (using USB through IMU).

I will try to write directly the command for setting 10 Hz next. I was thinking in writing this command in the GPS_MTK library. In the GPS_MTK_Class::Init member there is one command for setting the binary protocol

Serial1.print("$PGCMD,16,0,0,0,0,0*6A\r\n");

I though of writing

Serial1.print("$PMTK220,100*2F\r\n");

right afterwards. Do I have to do anything special to compile the library, or have I just to compile and upload the whole programm as always?

Besides the duplicated data, everything seems to be fine. It looks allright to me. I'm not sure what type of data example you want.

Greetings,

Andrés

• ▶ Reply

Permalink Reply by hopslink on November 28, 2010 at 2: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.

• ▶ Reply

Permalink Reply by Andrés on November 29, 2010 at 5:31am

I found the reason for the 4 Hz update. I was confused that there are two libraries for MTK. What I was talking about in my last posting was in the wrong library. Looking at the AP_GPS_MTK library one finds in lines 31-32 of AP_GPS_MTK.cpp the following:

// set 4Hz update rate
_port->print(MTK_OUTPUT_4HZ);

I changed this into

// set 10Hz update rate
_port->print(MTK_OUTPUT_10HZ);

Now it works perfectly at 10 Hz:

GPS:122147000,1,8,49.4279403,8.6808176,116.19,-21474836.00,0.00,0.00
GPS:122147100,1,8,49.4279403,8.6808176,116.19,-21474836.00,0.00,0.00
GPS:122147200,1,8,49.4279403,8.6808176,116.19,-21474836.00,0.00,0.00
GPS:122147300,1,8,49.4279403,8.6808176,116.18,-21474836.00,0.00,0.00
GPS:122147400,1,8,49.4279403,8.6808176,116.18,-21474836.00,0.00,0.00
GPS:122147500,1,8,49.4279403,8.6808176,116.18,-21474836.00,0.00,0.00
GPS:122147600,1,8,49.4279403,8.6808176,116.18,-21474836.00,0.00,0.00
GPS:122147700,1,8,49.4279403,8.6808176,116.18,-21474836.00,0.00,0.00
GPS:122147800,1,8,49.4279403,8.6808176,116.18,-21474836.00,0.00,0.00
GPS:122147900,1,8,49.4279403,8.6808176,116.18,-21474836.00,0.00,0.00
GPS:122148000,1,8,49.4279403,8.6808176,116.18,-21474836.00,0.00,0.00

Andrés

• ▶ Reply

Permalink Reply by Mark Grennan on December 3, 2010 at 6: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?

• ▶ Reply

Permalink Reply by Andrés on December 4, 2010 at 1:15am

Hi Mark,

first of all I use Linux, so I hope my info helps you. I download the logs with putty by logging a session into a file:

putty -serial /dev/ttyUSB0 -sercfg 8,1,115200,n,X -log log.txt

Inside the CLI (putty terminal) I tip "logs" and "dump X" to dump all the logs I need. Everything is stored into the "log.txt" file. Then I write a simple C++ programm to filter this text file. I'm not particularly proud of the coding style I used (I coded it fast), so the program could have better structure (see attachment)
Be aware that this is a normal C++ program (not for Arduino) ;) So compile using a normal C++ compiler, such as gcc.

At the moment the program only filters a couple of messages and stores these into file. It is easily extended to store other messages.

Regards,

Andrés

Attachments:

• main.cpp, 4 KB

• ▶ Reply

Permalink Reply by Mark Grennan on December 6, 2010 at 1:04pm

Linux is not a problem. I can translate. (see Linux Firewall-HowTo) :-)

I'll give the code a go through Cygwin and see what turns up. Then I'll try to run it through Google Chart https://code.google.com/apis/chart/ for the graphics. This will make it easy for everyone to use.

• ▶ Reply