Hi all! I try to using a MTK3329 gps with another fc board for comparation test, unfortunately, this board only accepts "standard NMEA" at "38400 baud" by default (and not binary), I flashed the gps with the original firmware, but unfortunately the default output is at 9600 baud.
The board in question receives the data but does not send anything to the GPS, so it initializes, is expected to be ready to send data from gps unit.
With MiniGPS I can make all the changes I want, but when remove power the GPS then returns everything to the default.
I do not have the battery installed on the pin "VBackup", can you tell me if there is a way to write these parameters so that by accessing the unit again to keep them stored?
With "MiniGPS" i try to write the parameters to the internal flash, but from what I can see you can not do because there's no flash in this unit.
You must initialize the unit at each power up. You are correct, you can not write configuration to the Flash.
You flashed it with what "original" firmware? The (about 2 year old "1.4" that has bugs?)
The MTK3329, sold by DIY Drones, will output NMEA @ 38400 bps by default. It must be commanded into binary mode. That sounds compatible with what you are asking for, no?
Quit telling people this. You can save settings to the flash.
Read your NMEA manual! I've posted the commands a few times already, but your unit may differ. There are many units based on the MT3329 chipset.
This is from MY MT3329 chipset based GPS NMEA manual. I don't really like posting it since it may not work for everyone, especially if they have some off-brand or proprietary firmware loaded on their unit. I can confirm that the 3329 chipset saves settings just fine. The particular firmware I use will only let you change them 8 times, then you have to reflash the unit. So make sure you get the settings you really want before committing them.
2.19 PMTK390 API SET USER OPTION
Change default settings of the NMEA output permanently. Write the user setting to the flash to override the default setting. Maximum 8 times without erase the chip.
Command number: 390
PMTK390, Lock, Update_Rate, Baud_Rate, GLL_Period, RMC_Period, VTG_Period, GSA_Period, GSV_Period, GGA_Period, ZDA_Period, MCHN_Period, Datum, DGPS_Mode, RTCM_Baud_Rate
Lock: nonzero: freeze the setting; 0: allow further setting.
Update_Rate: 1~5 (Hz)
Baud_Rate: 115200, 57600, 38400, 19200, 14400, 9600, 4800
RTCM_Baud_Rate: 115200, 57600, 38400, 19200, 14400, 9600, 4800
XXX_Period: NMEA sentence output period
DGPS_Mode: 0 (disable), 1 (RTCM), 2 (SBAS)
Datum: We support more than 200 datum. Please refer to Appendix A for the supported datum list.
The typical value is: 0 (WGS84), 1 (Tokyo-M), 2 (Tokyo-A)
Warning: Keep the lockbit zero. If you enable lockbit, you might corrupt the firmware!
Note: Command PMTK390 settings are stored to non-volatile flash memory. It is restricted to change the settings only 8 times/module. If exceeding the limit, settings cannot be changed until module is re-flashed.
>There are many units based on the MT3329 chipset.
Correct. I have posted that exact comment in other places.
I am discussing the DIY Drones one, since this is the DIY Drones site.
I was quite disappointed to learn that the handful of units I had purchased over the prior year FROM DIYDRONES would not save to flash.
Were YOUR 3329s purchased here? When did you acquire them? If there has been a change to the exact model or the firmware since about August/Sept 2011 I would like to know that.
DIY Drones disabled saving user settings? Why?
Have you tried the PMTK390 command to confirm this?
EDIT: Sorry, noticed you already tried this.
But that only brings up the question why DIYdrones crippled the firmware in this way...
I can only guess. BUT I have been here for a fair number of years. Back since the EM-406 was the preferred GPS. People were having never-ending problems with it because it has a little battery that would retain configuration for ~6 days without power. They would get it into some data rate or other comm error and not be able to get it back. And who waits 6 days before applying power to try again?
I would GUESS (and I hate to do this) that they would want the unit to quickly return to a known state. Cycle power, and BAM! you're back in business.
It seems to me that if you intentionally sent the write to flash command, you knew it was in the state you wanted it, but users are users...
One would think that any user sophisticated enough to work out the proper 390 command, compute the checksum and send it to the unit would be skilled enough to avoid such problems.
This makes me a little worried about what else is disabled in the DIYdrones units. Hopefully I have one on the way and they never mentioned anything in their custom firmware marketing hype about disabling chipset features.
Seems like there is a need for an open source GPS firmware as lots of users seems to be having problems and a lot of others want enhanced features like custom protocols and features.
It's a sad situation the every module maker that slaps MT chips into a module writes their own custom, closed-source firmware... and they all seem to be crippled in some way or another.
Agree pretty much with what you say.
And, if you have access to non-DIYD 3329 firmware that will upload, maybe you will have access to the flash. For that matter, it could even be that a silent change was made to the units. Winter is my busy season so I haven't been around much in recent months nor have I bought any new units since late summer/early fall.
I did start, last summer, a list of which commands were working and which not on my DIY units. I will see if I can find it. Computer I was using at that time went ill and got a new HDD and the last backup I made on USB was eaten by a dog. Slim chance, but still a chance, I have an older copy on the backup server.
The whole customizable firmware thing has made the 3329 a documentation nightmare. You want AGPS? You want different datums? You want custom binary?
Open source firmware might be cool, but could *all* the firmware be open source? How would they ensure the 60K feet & high speed lockout wasn't altered? They'd need a little bit (in with the boot loader?) that could not be changed that did something when the unit was going too fast for a weather balloon. :)
> How would they ensure the 60K feet & high speed lockout wasn't altered?
They wouldn't have to. See Bernstein v. United States, 1995
Open source software is constitutionally protected free speech. ITAR doesn't apply.
Awhile back I did some research on this. As far as I can tell nobody has ever been prosecuted for this sort of thing. Bernstein pre-emptively sued them just to avoid even the possibility of being hassled.