MediaTek - ArduPilot - Imu

Can anyone tell me what the standard for the MTK is supposed to be.


I ordered 4xmtk gps units. I still need to investigate why one gets a fix and the other 3 do not.


Before I rip out Jordis firmware from the mtk (if it exists) I would appreciate an understanding of what format the gps should use.


The ArduPilot 2.7 code expects a start byte of 0xB5 however the gps seems to be sending a text based $GPGGS message. 


Do we need to switch ArduPilot to use the GPS_MTK lib instead of the .pde included with 2.7?


I notice the lib has been coded for both the mega and the 328 so I guess it makes sense??


This is an extract of the 2.7 code that waits for the sync char

if(data==0xB5) // MTK sync char 1: DEC=181


Serial debug shows the following:-


Serial.print("GPS: Waiting for start byte: ");


Serial.print(" : ");




This example is from an imu but it uses simiar code to 2.7. 2.7 produced the same results


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

Join diydrones

Email me when people reply –


  • Hi all,
    my first contribution here, and some information of this mediatek issue. (and sorry for my bad english!):

    I received the 3 gps modules+adapters some weeks ago; today I tested them with FTDI 3.3VDC and winXP (using serial terminal and the software from Mediatek).

    These are the results:
    - 2 of them were not working ok. Well, in fact they did, but just for 5 or 6 seconds. After that, garbage was output instead of the nice NMEA sentences they were producing.
    - the other unit worked ok just right out of the box.
    -all units were outputting NMEA at 38400, 1Hz.
    - the units that were not working had 3.07 and 3.08 V at pin#1 in the GPS chip pin. Unable to communicate with them.
    -only solution that worked was connect a wire directly to pin#1 with and external regulator, that gave me a nice 3.3VDC to work with. Modules worked ok and communication was made. (Ken, you were right!)
    - Reflashing of the three units with the latest firmware.
    - the two not working units are still no working with the onboard regulator, even with the new firmware
    -the module that worked right out of the box has 3.12VDC in the pin#1 of the chip, coming form the onboard regulator.

    I'll try to make more tests tomorrow, but would be interested in the solution you may have found to solve this annoying issue.

    regards from Spain!
  • I had a problem with the MediaTek GPS.
    Please have a look at this issue and how I solved the problems:

    And at this issue:
  • Since you have such a large test group (4 GPS modules I mean) it would be nice if you could compare the data you get when these are in binary and in NMEA mode. Many people have reported problems with the binary mode but these apparently show up only in some locations (see the Ardupilot issue list and the "how to understand MTK binary mode" thread).
  • 3D Robotics
    That's just a difference between binary and NMEA format. If the GPS is outputting $GPGGS it's in NMEA (ASCIII) format and should be put into binary mode. If the modules aren't used for a while, they can rerturn to their hardware defaults. The APM MediaTek library automatically puts them into binary at startup, but we may not have implemented that in ArduPilot yet (I'd have to check)

    I believe you can do it manually by sending it (at the default 9600 baud) the string: $PGCMD,16,0,0,0,0,0*6A
This reply was deleted.


DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord:
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: Another incident:
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: What a great way to connect why @diyrobocars community is so valuable and important! Have to start somewhere @IndyAChallenge…
Oct 23