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).
You need to be a member of diydrones to add comments!
I'm also testing the MediaTek (binary output) using ArduPilotMega 1.0 library test software, indoors in a single story wood frame house near a window facing south. I'm having difficult getting GSP lock, which indicates that the unit is not as sensitive as advertised. In addition to this, when I do get a solution, the reported latitude is right on the mark, however the longitude is more than 20 deg in error. I'm certain that Jordi's blog will provide the solution to this issue.
Is there anyone who has managed to resolve the incorrect coordinate issues with the MTK in binary mode?
And if not, is there a way to use the NMEA data in the Ardupilot Mega? That would be desirable because in that mode I do get the correct coordinates.
I have tried simply setting GPS protocol to 0 (NMEA) in the APM code, but that doesn't produce output in debug mode 4 (gps data)
In debug mode 5 (raw gps output) with the mediatek in NMEA mode I receive the
I believe this is hex which translated is:
$GPGGA,175717.000,5126.6341,N,00528.1306,E,1,5,1.45,52.7,M,47.3,M,,*60Ú ... That seems to contain the correct coordinates that I would like to use.
Ofcourse, ideally, a firmware upgrade for the mediatek would be desirable, but maybe until then we may just use the NMEA data, but I wouldn't have a clue as to how to do that :)
Another topic on this issue: http://diydrones.com/forum/topics/mediatek-ardupilot-imu?xg_source=...
Thanks in advance!
Oh btw; when I try to use the test program (GPS_MTK_test) included in the library in the subfolder AP_GPS I get a compiler error: D:\My Documents\Sketchbook\libraries\AP_GPS\AP_GPS_406.cpp:39: error: expected constructor, destructor, or type conversion before '=' token
Is that the test program I should be using, or should I use the one in the parent folder?
thanks again :)
If you have access to NOTAMS (notice to airman), it has directs to block GPS satellite 25 from your aircraft navigations systems. It does not say why you shouldn't use it, but it may be inducing errors in these positions.
I am looking up the specific notam. I will post what i find.
B5 62 01 05 02 17 09 B5 D2 65 32 45 00 00 04 71 00 00 00 00 0A E7 6A 10 09 03 0C 46 5C EC 11 9A
the gps location is Latitude 35.0642 Longitude -76.9532
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
Init Ardupilot 2.7 Beta 5.3
MSG Radio in A: 1500 E: 1500 T :1100 R :1500
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.
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.