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(data);

Serial.print(" : ");

Serial.println(data,DEC);

 

 

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 –

Replies

  • 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:

    http://code.google.com/p/ardupilot/issues/detail?id=32

    And at this issue:
    http://code.google.com/p/ardupilot/issues/detail?id=30&can=1
  • 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.

Activity