I just bought a GPS module and it was working correctly at 38400 bps. After some power cycles I wasn't able to get more NMEA sentences from and instead I was getting some garbage. 

I hooked a scope and realize the bit time which corresponds to 24400 bps. I switched baurate on mu PC to 24400 bps and I can get NMEA sentences however I can't change baudrate any longer. Even powering it off keeps the 24400 baud rate.


Tried to flash the firmware but flash tool does not recognize the module (I assume because of the wrong speed)


Any ideas?




I found another user with the same problem: http://forum.trenz-electronic.de/index.php?topic=93.new;topicseen#new 

Views: 977

Reply to This

Replies to This Discussion

Where did you get the module? The DIYDrones ones are shipped with binary, not NMEA.


I bought the module from DIYDrones and as far as I know, the default is NMEA (you can switch to binary after power on)




News to me. Never seen that problem. I suggest you return the module for replacement.



You keep saying this, but it isn't true. The summer (July?), the fall (Sept?), and the winter (January?) firmware all start up in NMEA on both my modules. (DIYStore purchased last summer.)


Both the MTEK and MTEK16 libraries have code to command the GPS into binary mode during initialization. That wouldn't be necessary if the modules reliably came up in binary.


Maybe it is a bug in the firmware. Maybe it is a bug in my hardware. Maybe Jordi's English and the Chinese programmer's English are not compatible on the word "binary." Maybe there is a floating pin that needs tied down to assure it starts in a particular mode. Can't help with the why. But if you want binary, you'd better tell it binary. 





When it is giving you data @ 24400, do you have a solid blue light (lock)? If you have a slow blinking (1/2 Hz -- 1 second on, 1 second off) you may be having, "the low voltage problem." 



Okay, I stand corrected. We never look at the raw data out of the GPS before the setup string, so maybe it is NMEA as you say. But it sure is binary after the setup string is sent. 


There are no bugs in the firmware that I know of. If you're having a problem please state what it is. Right now I know of no problems now that we've released libraries that support firmware 1.6.

I have a slow blinking (.5 Hz). Is there some fix for the "low voltage problem"?

1. Return it to the store.


2. Add a 3.3v regulator of your own choosing in parallel to help the on-board regulator.


Background:  http://www.diydrones.com/forum/topics/mediatek-gps-power-supply?com...


Hi Ken, 

Thanks for the response. I'm using the bare GPS module (http://store.diydrones.com/MediaTek_MT3329_GPS_10Hz_p/mt3329-01.htm) with an external 3.3 regulator.... The one that you mention is for the borad that cames with the regulator, right?



If you are using the bare module and supplying power yourself, make sure Vcc is 3.3v to 3.5v and make sure you have some power to Vbat (2 or 3v OK), but esiest to jump it to Vcc. Make sure to have a low ESR cap near the pins, it draws in surges when it transmits.


   I am a professional engineer and I've just designed a PCB with an MT3329 on it.  I have the same problem as you guys and I've been working on the issue today and thought I'd share my findings with you.


What appears to be happening is the LED output is an input on power on.  If you pull it low, the MT3329 works normally.  If you pull it high then it goes into a strange mode where the data comes out at 24k baud and the LED flashes slower than normal.  I suspect this is designed behaviour and it is some special customer or test mode.


In the MT3329 datasheet it shows an example circuit with the LED connected to GND through a resistor.  If you do this the module works properly because the LED pulls down the LED pin.  However, in this configuration, the LED is off when the GPS has a fix.  If you want the LED to be on for a fix, then you have to connect the LED to Vcc through a resistor.  This is what I have done on my board and is also what is done on the DIY drones 'adaptor board' product.


But the problem is the LED pulls up the LED pin when the module is powered on.  How much depends on the forward drop of the LED.  On my board, I am using a green LED and the forward drop is much less than the blue LED on the adaptor board.  Therefore I have the problem and the adaptor board doesn't.  However I have measured the voltage on the MT3329 LED pin on the adaptor board and it is about 1V on power up which is a bit close for comfort.  Certainly not low enough to be a comfortable, guaranteed low.  It would also change with temperature, supply voltage and from board to board.


A number of threads talk about a power supply issue and putting 3.5V on Vcc.  I suspect that increasing the supply voltage on the MT3329 improves the margin on the LED input (though I have not tested it) and prevents the module switching to the alternate mode.


The way that I have fixed it is to put a 1N4148 diode in series with my greed LED therefore increasing the forward drop.  Depending on your supply voltage and LED type/colour you may need 2 diodes in series and you may want to decrease the resistor value to maintain the same LED brightness.  Alternatively you could buffer the output in some way.


I hope that my solution is helpful to someone out there.


Best Regards,




@Dave, thanks for that solution, sounds like that would work to keep the GPS module functionality the same.

Re-evaluating the situation from an overall functionality standpoint makes me think there may be a better solution. What we're doing now is trying to work around the intended functionality of the LED pin so that we can reassure ourselves with a lock LED that is, for the APM, redundant. When GPS lock is established and recognized by APM, LED C goes solid on the oil pan. Why not use an LED as intended by Mediatek as an error indicator instead? You'll still be able to tell that the module receives power (LED flashes on bootup/waiting for fix) and when 3d fix is established (LED off).

I understand this will create more versioning issues which are always a pain but they're not as painful as GPS modules booting up in various undocumented modes! :)

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

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service