I was wondering whether anybody else has been experiencing weird offsets in either latitude or longitude coming from the mediatek GPS? Strangely, it only seems to occur when it runs in binary mode and with NMEA I get way better accuracy. In my case I run it with the libraries from the ArdupilotMega repository and using the DIY drones adapter board. I get a 0.4 degree longitude offset (approximately) when running in binary mode. That translates into an error of over 10km or so I think.

I understand that most of the code is still under heavy development but since I suppose feedback is welcome I thought I ask here. My first guess would be that there could be a problem in the GPS parsing code or on the mediatek firmware. On an unrelated note, my mediatek does not seem to store settings when powering down (although I use it with the adapter which has a battery on it).


Views: 2926

Reply to This

Replies to This Discussion

0.4 degree error in latitude (anywhere), or in longitude (at the equator), would be 24Nm or about 40km. {1 minute=1Nm; 1 degree=60Nm}

By any chance have you changed the map datum from WGS-84 to something else? (still wouldn't expect it to cause as big an error as you see, but...)

Is this a degrees to dd:mm.mm or dd:mm:ss conversion issue? What are you looking at that shows the offset?

You can look at what the GPS directly outputs. Put some print statements where the code copies the GPS position out of the message into its own variables. Remember that this is in degrees x 1,000,000, not degrees:minutes.
I looked at the GPS output as parsed by GPS_MTK.cpp (also tried the Arducopter version which is apparently slightly different). Basically I added a Serial.println(data,HEX) to GPS_MTK_Class::Read. Turns out that the bytes match what I see in GPS_MTK_test.

So when I run the mediatek in binary mode (switch: $PGCMD,16,0,0,0,0,0*6A) I get these here:
Lat:602XXXXX Lon:245XXXXXX (the 'X' stands for something else of course)

When I run it in NMEA (switch: $PGCMD,16,1,1,1,1,1*6B) I get these here:

which happens to be correct (I checked another GPS receiver and google maps).
So the distance between these should be closer to 20km.

All I changed was the NMEA/binary mode and the update rate (using $PMTK220,250*29, etc.). I tried various update rates for binary mode and these did not seem to have any effect.

So could it be maybe that the binary-protocol image on my mediatek is corrupted? Is there any way to reflash it using the ArdupilotMega? (BTW: note the Lat string in binary mode is one digit shorter than in NMEA mode..)
I am almost certain that you are having degree vs degree minute misunderstandings.

NMEA output is ddmm.mmm (latitude never needs a 3rd degree digit) or dddmm.mmm

For example, from the GPS's GPGGA message, the string "08151.6838, W"
means 81d 51.6838' W (81 degrees, 51.6838 minutes west)
which could be converted to 81d 51' 41" W (81 degrees, 51 minutes, 41 seconds west) if preferred

The binary output is degrees x 1,000,000

Take the binary, divide by 1,000,000 and save it in a floating point variable, Call this "A"

A = 245XXXXXX / 1000000.0 = 24.5XXXXX

Save the whole number (integer part) of degrees with no rounding. Call this "B'

B = 24 // number of degrees

Subtract the integer part "B" from "A" and call it "C"

C = A - B
C = 24.5XXXXX - 24 = 0.5XXXXX

Multiply C by 60 to get the number of minutes.

Minutes = C * 60.0 = 0.5XXXXX * 60.0 = ???

If you want D:M:S you basically repeat the process; subtract the whole minutes, multiply by 60.

Jebus, 60 North! Kerava? Jarvenpaa?
Has the recent solar activity given you some pretty nights?
Yes.. that's it. Thanks for helping me out on this one, I'm kind of new to this whole navigation thing as you may have guessed :)

I think what got my confused in the first place is that both GPS_NMEA_test and GPS_MTK_test use this GPS object to access the coordinates so I was confused since I thought the library somehow abstracts these conversion issues away. Now I digged a bit deeper and saw that these two are actually different classes and specific to the GPS used. Changed the title of the discussion to reflect that..

So thanks again for solving that "mystery".. You're right, this is Finland (Helsinki to be precise). Didn't see northern lights last night (actually only saw these once and that's years back).
I was also wondering about this, but what if you enter the decimal degree variable the APM code outputs directly into Google Maps?

So if I just take the lat and lon variables from the serial monitor (output by the latest alpha build) and enter it in Maps, shouldn't that point me directly to where I am?

E.g. my LON values are:

NMEA, LON:59393683
MTK, LON: 556005871

So I divide them to become:

NMEA, LON:5.9393683
MTK, LON: 5.56005871

Strangely, the LAT values for both match perfectly.
Per Google's API documents, Google Maps wants its input in degrees. So, yes, if you are looking at raw Ardupilot/ArduIMU data, just divide by 1,000,000 and enter that. Whether it can translate for you if you put spaces and minute markers in it, well, I've never tried so I don't know.

The "degrees:minutes" type of data is "classical". If you were to look up locations of cities, airports, etc. in online databases or printed, you would most likely see that format. And that is the format that NMEA uses, so when a GPS talks NMEA to you, that is what you will get.

Even older references may be in degrees:minutes:seconds. Those must be "doubly" converted to straight degrees for Google, or for ArduXXX.

re. Your latitude match ups. Sometimes the numbers do match up. Or nearly enough that people ignore it. This happens when the number of minutes is low or zero. A degree is divided into 60 minutes, just like an hour is. If we were to switch from using hours:minutes:seconds to hh.hh (decimal hours), every hour on the hour would be exact and the difference between the two strings of digits would be increasing up to 59 minutes after the hour.

So, if you have a "classical" location such as Greenwich's latitude 51° 28' 38"N (taken from http://wwp.greenwich2000.com/ (yes, wwp not www) you divide and add, divide and add.

38" / 60 = 0.63333'
28' + 0.633' = 28.63333'
28.633' / 60 = 0.477222°
51° + 0.4722° = 51.47222°

If you look at http://code.google.com/apis/maps/documentation/staticmaps/ about half way down the page they give the latitude of Greenwich as 51.477222. Bingo!

Your NMEA longitude is a string of characters that just looks like a number, it's not a literal number. You can't divide it yet. You must split it into the degrees part and the minutes part. I see that you are in Netherlands. 5 degrees East is OK. Was there no leading 00? (The GPS should have output 2 characters for latitude degrees and three characters for longitude degrees, ex 0059393683. Maybe they were stripped by the system.)

Anyhow, breaking it into parts and adding the units and decimal point:
0059393683 = 005° 93.93683'

But the 93 minutes is impossible. Should never exceed 59. Are you sure you got that right? Maybe you have NMEA & MTK backwards? Let's try that instead:

00556005871 = 005° 56.005871' (that looks much better)

56.005871' / 60 = 0.9334°

5° + 0.9334° = 5.9334°

Which is close to your "NMEA" (Which is probably your MTK) longitude, 5.9393683
OK.. hmm.. It seems that I was shouting "hurray" a little too early. I still get roughly 22 minutes difference in my longitude. I use this website for reference and also conversion of coordinates.

In the meanwhile I tried to reflash my Mediatek by following the instructions given here. Since I'm running linux (and ran it under wine) it was not as straightforward. Unfortunately the tool reported a failure so I did not succeed in reflashing (although I could use the mediatek tool for display of satellites, etc.). The old code still seems to run as before.

Fabien, nice to know that I'm not the only one having this problem. Did you try to reflash the MTK?
Hey Ken,

Thank you for the good explanation for the DD MM conversion, but I don't think that's the problem.

My "NMEA" is indeed the MTK chip in NMEA mode, but both of the longitudes I gave are directly from Ardupilot telemetry.

Here's the full longitude so you can see it doesn't match:

50934990,556005166 in Ardupilot binary "MTK" mode

509348066,59382166 (with Ardupilot also set to NMEA, so it outputs the right coordinates. These are the same as my iPhone tell me)

So as you can see, when you transform the 556 longitudes it will give 'about' the same coordinates, but not the right ones.

@ Andre: It's indeed about the same problem. I reflashed the MTK with the latest firmware ( I think, it was on that other topic), still the same problem.
Hey! I think I'm getting the error!

I had been testing MediaTek GPSs in NMEA mode, 'cause that is what I use 99% of the time (NMEA that is).
Tonight I tried getting the MediaTek into binary, and I'm halfway around the world wrong. But not always.

MediaTek is in binary, I have position lock, I restart the ArduPilot, and I get this

MediaTek GPS

Init Ardupilot 2.7 Beta 5.3
MSG Radio in A: 1500 E: 1500 T :1100 R :1500
freeRAM: 626
MSG Startup: Ground
MSG WP Total: 255
MSG home: 27****** -82********

All good, but THEN as the data starts coming out it has me at 44 degrees east, not 82 degrees west!
Latitude still looks OK.
Hi guys,

I created a small app here http://ardupilot.googlecode.com/svn/branches/ArduPilot_2_7/Test%20A...
that reads from the serial connected MTK gps and outputs the coords.

Also to update the firmware on the MTK's look here http://code.google.com/p/ardupilot/wiki/MediaTek


Ken, I've been unable to reproduce this error. I ran the latestet Ardupilot build with this setting in config:

#define DEBUG_SUBSYSTEM 4 // Debug the GPS input

I get the proper location.

Could you try this debug setting and record your output? Also try this debug setting to record the raw hex values:

#define DEBUG_SUBSYSTEM 5 // Debug GPS, raw HEX

Please add the results to your issue posting,
No joy.
I set up ArduPilot for debug, but after 1 hour there was no lock (per blue light on GPS) and no data out per ArduPilot.

I hooked the GPS up to an FTDI cable and tried every baud rate. Bytes are coming out of the GPS, but no text, and never found the MTEK header bytes (0xB5 0x62) in the data stream.

I put both my MTEKs on FTDI cables and connected them to a computer on the back table. Same thing. Tried the command to put them back in NMEA text. No change.

So, here is the executive summary.

Yesterday I had 2 MediaTeks:
1. working well in NMEA mode.
2. I decided to try binary, and they switched over successfully
3. Longitude was 44 instead of -82, but otherwise working OK.

Now today, I have 2 MediaTeks
1. unable to get a lock after 2 hours powered on.
2. Sending out data at an unknown rate
3. not accepting commands

Thinking maybe the GPS constellation had been shot down, I pulled out an old EM-406 that looks like a car drove over it. Been in a drawer for weeks. Plugged it in. Sat lock and position fix in a minute.

I'll have access to a Wintel PC tomorrow. If I get time I'll see if I can reflash the MediaTeks.

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service