Search found 58 matches: MTK_BINARY

Searched query: mtk binary

by Gimbal
Wed May 22, 2013 5:58 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

viewtopic.php?f=8&t=649&start=1540

"Hi!
3drobotics just released a new firmware for MTK 3329 it is called 1.9 or "AXN1.51_2776_3329_384.1151100.5_v19.bin". You can grab it here: http://code.google.com/p/ardupilot-mega ... n&can=2&q=

This FW 1.9 responds in binary mode with one decimal more precision(!)than current mtk binary or nmea and has therefor an altered syncword."

And then un comment "//#define MTK_BINARY19" in config.h
by felixrising
Tue May 07, 2013 4:25 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Hi Tryss,

Code changes/commits can be found here: https://code.google.com/p/multiwii/source/list

I don't have a MediaTek, so I'm inferring here.
The MediaTek MT3329 (please confirm that is the one you have), talks NMEA (you can try the binary modes though which I think it better than NMEA) you should only have to connect it to Serial 2 and uncomment '#define GPS_SERIAL 2', '#define GPS_BAUD 115200', '#define NMEA', '#define INIT_MTK_GPS'. You may need to update your GPS firmware to get the BINARY modes.

Do some thread searches for your GPS model number. Some more on MTK_BINARYxx here http://www.multiwii.com/forum/search.php?keywords=MTK_BINARY&t=649&sf=msgonly
by felixrising
Tue Apr 02, 2013 12:40 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

KeesvR wrote:I have a Flytron Navigator V1 GPS.
I'm trying to get my GPS working with binary protocol, but it's not working.
I've flashed the gps with 1.9 firmware.
With Minigps set it to 115200 and 10hrz also tried 5hrz.

With NMEA protocol it's working fine, but with Binary protocol I see nothing in the GUI.

What am I doing wrong, or is it not possible with my GPS ?
What are the settings for I2C GPS Config.H and MultiWii Config.H ?

Thanks.


Hi,

I'm not sure about binary protocol vs NMEA. As I understand it, if you are using a I2C-GPS-Nav module, you should just modify the config.h file as follows uncomment the "#define I2C_GPS" and optionally "#define GPS_LEAD_FILTER" and configure MAG_DECLINATION (which btw you can get from the Android MultiWii EZ-GUI app under the Dashboard GPS button).

Perhaps I'm misunderstanding your question.. is it the binary mode data transfer between the GPS module and I2C-GPS-NAV module that's not working?

EDIT: I'm looking at the I2C-GPS-NAV_v2_2 code, the two binary mode transfers the GPS supports look like MTK specific stuff. I assume if you set BAUD rate to the 38400 and define NMEA along with INIT_MTK_GPS it should be auto-configured, you could try changing the NMEA define to each of the binary modes and see whether it automagically gets configured and works, if it doesn't work just go back to NMEA. I assume your GPS module is this one? (http://www.flytron.com/osd-headtrackers ... odule.html) which is indeed a MeditaTek unit, but I can't find any information about switching it to use MTK Binary protocol 16 or 19 manually if the auto define INIT_MTK_GPS doesn't work.. This document indicates it does RTCM(?) and NMEA 0183 v3.01 as well as two others: http://www.flytron.com/pdf/OPA6B.pdf.. if you have a I2C-GPS-NAV board, then unless it's really not keeping up with NMEA sentence parsing as well as the NAV code, then I'd be happy with NMEA at 10hz... Personally I find the NEO-6M module from Crius (CN-06 v2) which talks ublox and can be had for as little as $25 is very easy to integrate and works well. Another interesting thread which mentions your GPS here: viewtopic.php?f=8&t=649&start=1030.
by gabe
Tue Feb 26, 2013 3:42 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Hi guys,

Im using this i2c GPS board with NMEA protocol:
http://www.drotek.fr/shop/fr/88-i2c-gps-pa6c-llc.html

Would it be more efficient to use it with MTK binary 19 protocol?
This GPS board is based on PA6C chip. Can I update it with the Dec 28th 2012 firmware?
http://code.google.com/p/i2c-gps-nav/downloads/detail?name=AXN1.51_2776_3329_384.1151100.5_v19.bin&can=2&q=

It seems this firmware is built for PA6B chipset.
I haven't found a firmware update tutorial. O you have an idea where I could find the procedure?

Many thanks!
by EOSBandi
Wed Jan 30, 2013 8:28 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

JayBee wrote:
EOSBandi wrote:Hi Folks,

i2c-gps-nav v2.2beta1 is just released for testing!
you can get it from : http://code.google.com/p/i2c-gps-nav/downloads/list

New features :
MTK Binary protocol 1.9 (from DIYDrones)
UBLOX init
MTK init
Lead predictive filtering (updated)
SONAR handling (See config.h for more info)

This is the first beta release, is sould work with MW 2.1 and recent devs BUT there will be some upcoming fixes which will impact data structures so the final I2C-V2.2 release will work only with MW 2.2 (or a TBD revision from SVN)

Disclaimer : Since I don't see a penny from third party manufacturers i2cgps board versions, i cannot provide support for such boards. The primary supported platform for I2C-GPS-NAV is a pure vanilia arduino mini or nano with direcly attached GPS and sonar modules.


Hello EOSBandi,

I have a little problem with the SONAR handling.
When my HC-SR04 module get no echo from the sending pulses (distance to high for example) there`s no timeout at the Echo pin (from 38 ms like it should be in original module data sheet).
So the echo pin stays high until the module will be (re)triggered.
The Sonar_update will be only send a new trigger signal if the Sonar_waiting_echo flag was cleared by a falling edge at the echo pin => a deadlock situation has occurred.
The easiest solution is to deactivate the Sonar_waiting_echo flag. So the blink_sonar_update, which calls the Sonar_update every 50 ms, will handle the timeout automatically.


JayBee


Thanks for catching it... will update the repo soon... but first I have to finish my cinestar 8 build... i suppose it will be the first MultiWii powered cinestar :D
by JayBee
Wed Jan 30, 2013 7:53 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

EOSBandi wrote:Hi Folks,

i2c-gps-nav v2.2beta1 is just released for testing!
you can get it from : http://code.google.com/p/i2c-gps-nav/downloads/list

New features :
MTK Binary protocol 1.9 (from DIYDrones)
UBLOX init
MTK init
Lead predictive filtering (updated)
SONAR handling (See config.h for more info)

This is the first beta release, is sould work with MW 2.1 and recent devs BUT there will be some upcoming fixes which will impact data structures so the final I2C-V2.2 release will work only with MW 2.2 (or a TBD revision from SVN)

Disclaimer : Since I don't see a penny from third party manufacturers i2cgps board versions, i cannot provide support for such boards. The primary supported platform for I2C-GPS-NAV is a pure vanilia arduino mini or nano with direcly attached GPS and sonar modules.


Hello EOSBandi,

I have a little problem with the SONAR handling.
When my HC-SR04 module get no echo from the sending pulses (distance to high for example) there`s no timeout at the Echo pin (from 38 ms like it should be in original module data sheet).
So the echo pin stays high until the module will be (re)triggered.
The Sonar_update will be only send a new trigger signal if the Sonar_waiting_echo flag was cleared by a falling edge at the echo pin => a deadlock situation has occurred.
The easiest solution is to deactivate the Sonar_waiting_echo flag. So the blink_sonar_update, which calls the Sonar_update every 50 ms, will handle the timeout automatically.


JayBee
by thebgrian
Sun Jan 20, 2013 11:44 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

EOSBandi wrote:
thebgrian wrote:I have some problems also getting my MTK gps from Navigatron v1 to work with Multiwii on AIO. I have the GPS module disconnected from the 328 chip and using it like a pure serial GPS. All the flashes work fine when tested with the Mini GPS tool. Tried DIY Drones v.1.6 and 1.9. Using TeraTerm I can connect and get data stream at 38400 speed. The data is in the following format:
$GPGGA,182044.600,330x.xxxx,N,0965x.xxxx,W,1,7,1.09,173.8,M,-24.1,M,,*6C
$GPGSA,A,3,21,18,15,29,22,26,09,,,,,,2.02,1.09,1.70*04
$GPRMC,182044.600,A,330x.xxxx,N,0965x.xxxx,W,0.00,138.85,190113,,,A*7A
$GPVTG,138.85,T,,M,0.00,N,0.00,K,A*3A

The x-es are numbers actually.

In config.h I have Serial 2 set for 38400, GPS serial port 2 and GPS speed 38400 (which I believe doesn't matter, since we are not sending any params to the GPS module).
I have only Tx from GPS connected.
For GPS protocol selected is MTK_BINARY19 and the GPS module is flashed with the ver 1.9.
Also tested with MegapirateNG on the same board and the GPS works and shows 3D fix, so the hardware looks fine.
I ran out of ideas what is wrong other than somehow the MultiWii doesn't understand the data sent from the GPS. Can somebody with similar setup give me a hint what is wrong?

Wrong, the code initialise the GPS module, you need two way communication....

Got it finally. It is simple as expected. To have my GPS initialize I had to enable not only #define MTK_BINARY19 but also #define INIT_MTK_GPS. Pretty obvious right? :) So here are my GPS related settings for MTK ver 1.9 (it should be the same for 1.6) for AIO from Hobbyking/Crius:


#define SERIAL2_COM_SPEED 38400

#define GPS_SERIAL 2 // should be 2 for flyduino v2. It's the serial port number on arduino MEGA
#define GPS_BAUD 38400
#define MTK_BINARY19
#define INIT_MTK_GPS // initialize MTK GPS for using selected speed, 5Hz update rate and GGA & RMC sentence or binary settings
by EOSBandi
Fri Dec 28, 2012 9:18 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Hi Folks,

i2c-gps-nav v2.2beta1 is just released for testing!
you can get it from : http://code.google.com/p/i2c-gps-nav/downloads/list

New features :
MTK Binary protocol 1.9 (from DIYDrones)
UBLOX init
MTK init
Lead predictive filtering (updated)
SONAR handling (See config.h for more info)

This is the first beta release, is sould work with MW 2.1 and recent devs BUT there will be some upcoming fixes which will impact data structures so the final I2C-V2.2 release will work only with MW 2.2 (or a TBD revision from SVN)

Disclaimer : Since I don't see a penny from third party manufacturers i2cgps board versions, i cannot provide support for such boards. The primary supported platform for I2C-GPS-NAV is a pure vanilia arduino mini or nano with direcly attached GPS and sonar modules.
by jaames74
Thu Dec 27, 2012 1:15 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

EOSBandi wrote:Hi Folks,
I just committed an update to the GPS parsers. it includes :
- updated initialisation for MTK gps modules correct EGNOS init and set navigation threshold (Thanks for Crashlander for the help and test)
- Added MTK binary protocol for both versions of DiyDrones binary MTK firmwares (v1.6 (AXN1.3-2389) and v1.9(AXN1.51-2776)) (Thanks again to Crashlander for notify me about the new fw)
- Added a forward predictive filter to gps position calculation, which eliminates the gps lag. (based on the code from Jason Short)

Due bad weather it is only tested on the desk, so please use it wisely.


hi Eos,
will you make this update available for "poor" I2C GPS users like me?? :lol:
by dramida
Thu Dec 27, 2012 10:37 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

EOSBandi wrote:Hi Folks,
I just committed an update to the GPS parsers. it includes :
- updated initialisation for MTK gps modules correct EGNOS init and set navigation threshold (Thanks for Crashlander for the help and test)
- Added MTK binary protocol for both versions of DiyDrones binary MTK firmwares (v1.6 (AXN1.3-2389) and v1.9(AXN1.51-2776)) (Thanks again to Crashlander for notify me about the new fw)
- Added a forward predictive filter to gps position calculation, which eliminates the gps lag. (based on the code from Jason Short)

Due bad weather it is only tested on the desk, so please use it wisely.


Great work Eos :) I'll test it along with the new mag calibration procedure and Adrian new altitudevario implementatio viewtopic.php?f=8&t=2371&p=28353#p28352

The Christmas presents are coming later this year :)
by albertoLG
Thu Dec 27, 2012 9:01 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

EOSBandi wrote:Hi Folks,
I just committed an update to the GPS parsers. it includes :
- updated initialisation for MTK gps modules correct EGNOS init and set navigation threshold (Thanks for Crashlander for the help and test)
- Added MTK binary protocol for both versions of DiyDrones binary MTK firmwares (v1.6 (AXN1.3-2389) and v1.9(AXN1.51-2776)) (Thanks again to Crashlander for notify me about the new fw)
- Added a forward predictive filter to gps position calculation, which eliminates the gps lag. (based on the code from Jason Short)

Due bad weather it is only tested on the desk, so please use it wisely.


uumm... updated my gps firmware to "AXN1.51_2776_3329_384.1151100.5_v19.bin", EOSBandi, tested your revision, gps show in the gui and the leds flash so i have a 3Dfix, but seems more unstable than previous revision I used... with the previous when I switched to PH the quad just was in position with no big swings... now it just go away, try to go back but with big error in position... like was without changing my threshold settings


EDIT:
tested again and seems better now... probably was a poor satellite reception, first test was with very cloudy sky... second test with no clouds... poor MTK antenna? overall... fast 3Dfix than previously and better position and nav (tested a couple of RTH, ah.... wobble a little too much in navigation, need probably to tune PID, I use defaults)
by EOSBandi
Thu Dec 27, 2012 12:42 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Hi Folks,
I just committed an update to the GPS parsers. it includes :
- updated initialisation for MTK gps modules correct EGNOS init and set navigation threshold (Thanks for Crashlander for the help and test)
- Added MTK binary protocol for both versions of DiyDrones binary MTK firmwares (v1.6 (AXN1.3-2389) and v1.9(AXN1.51-2776)) (Thanks again to Crashlander for notify me about the new fw)
- Added a forward predictive filter to gps position calculation, which eliminates the gps lag. (based on the code from Jason Short)

Due bad weather it is only tested on the desk, so please use it wisely.
by Crashpilot1000
Sat Dec 22, 2012 2:00 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Since the world is still online after 21.12.....

Thank you very much for being so active, supportive and helpful all the time in your scarce free time!
Since apm is struggeling with their autodetection code (confusion starts here: http://diydrones.com/xn/detail/705844:Comment:1062391) it may be an idea to make the mtk binary support depending on firmware selectable in the config.h. So the user should know what FW is running on his mtk3329 gps (running MiniGPS will give him clarification of that) a fw before 1.9 or 1.9 and define it in config.h. Mwii users got more guts :) - i guess. My C/Arduino Coding abilities are very limited, i just coded on my purely loved Amiga1000 some Demos 22 years ago, so i am definately not the person to give you any coding advice at all. BUT i am very excited about your work on 2.2 of your gps code!

Since the world didn't destroy itself already I want to wish you and your family a very happy christmas!

Yours
Kraut Rob
by EOSBandi
Fri Dec 21, 2012 9:37 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: End of the world news for MTK 3329 users

Crashpilot1000 wrote:Hi!
3drobotics just released a new firmware for MTK 3329 it is called 1.9 or "AXN1.51_2776_3329_384.1151100.5_v19.bin". You can grab it here: http://code.google.com/p/ardupilot-mega ... n&can=2&q=

This FW 1.9 responds in binary mode with one decimal more precision(!)than current mtk binary or nmea and has therefor an altered syncword.
I added a slightly modified I2C_GPS_NAV-v2.1rc2 from EOS Bandi (http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q=). The config.h is already set to go for mtk binary with the FW 1.9 mentioned above. It is not compatible to the old mtk binary firmwares. In the config.h you will come across my spikefilter wich i find very useful, but you can deactivate it there. You can also alter the minimum sats required for gps functions there. You can now /will have to increase the "P" of your current GPS Pids.

Cheers

Kraut Rob


One significant note. GlobalTop firmwares (which is used by 3Dr) are vendor protected from version 1.5 and up. This means that you can upload this firmware only to a Pa6B or other Global-Top made MT3329 chip based modules. :(
I'll incorporate Rob's changes during the festive season.
by Crashpilot1000
Fri Dec 21, 2012 1:09 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

End of the world news for MTK 3329 users

Hi!
3drobotics just released a new firmware for MTK 3329 it is called 1.9 or "AXN1.51_2776_3329_384.1151100.5_v19.bin". You can grab it here: http://code.google.com/p/ardupilot-mega ... n&can=2&q=

This FW 1.9 responds in binary mode with one decimal more precision(!)than current mtk binary or nmea and has therefor an altered syncword.
I added a slightly modified I2C_GPS_NAV-v2.1rc2 from EOS Bandi (http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q=). The config.h is already set to go for mtk binary with the FW 1.9 mentioned above. It is not compatible to the old mtk binary firmwares. In the config.h you will come across my spikefilter wich i find very useful, but you can deactivate it there. You can also alter the minimum sats required for gps functions there. You can now /will have to increase the "P" of your current GPS Pids.

Cheers

Kraut Rob
by Crashpilot1000
Fri Dec 14, 2012 7:56 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Help!

Sorry to interrupt here, but i am still struggeling with the MTK 3329 module the AXN1.51_2722_3329_384.1151100.5.bin and a valid DGPS fix. I connected the modul directly (via FTDI) to realterm (very good tip - thanks to EOS Bandi :) ) and let it put out NMEA strings (not turned to binary mode) at just 1Hz and observed the GGA strings. I got 10 Sats but never a DGPS fix. I threw every command at it that could possibly activate waas/sbas - nothing. Has anyone DGPS fix running on a binary capable Firmware?
Any help would be very appreciated!
Probably some simple methodical error?

Cheers

Kraut Rob

List of acknowledged commands but without success:

Code: Select all

  #define MTK_SBAS_INTEGRITYMODE"$PMTK319,1*24\r\n"    // TEST:ACK 
  #define MTK_NAVTHRES_OFF      "$PMTK397,0*23\r\n"    // TEST:ACK Threshold was 1.00m before (PMTK447 returns 0.0 NOW)
  #define MTK_SBAS_ON      "$PMTK313,1*2E\r\n"    // Enable search SBAS sat // TEST:ACK
  #define MTK_WAAS_ON           "$PMTK301,2*2E\r\n"    // DGPS MODE WAAS // TEST:ACK


List of commands described in the A11 revision of the MTK commandset but returned "ERROR UNSUPPORTED COMMAND"

Code: Select all

  #define MTK__DT_NAVTHRES_OFF  "$PMTK527,0.00*00\r\n" // Turn off Navthreshold // TEST: ERROR UNSUPPORTED COMMAND
  #define MTK__DT_NAVTHRES_OFF  "$PMTK527,0*2E\r\n" // Turn off Navthreshold // TEST: ERROR UNSUPPORTED COMMAND
  #define MTK_DT_SBAS_ENABLED   "$PMTK513,1*28\r\n"  // Enable Search for SBAS Sats // TEST: ERROR UNSUPPORTED COMMAND
  #define MTK_DT_DGPS_WAAS      "$PMTK501,2*28\r\n"  // DGPS data source mode: WAAS // TEST: ERROR UNSUPPORTED COMMAND
by Crashpilot1000
Thu Dec 13, 2012 5:08 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

@EOS Bandi:
Hi!
Thank you very much for your reply!
I did another version. This time i improved the documentation in the maincode and config.h. Besides this i figured that a different minimum sat-count for different gps functions could be a good idea. PosHold is more a luxury feature so a higher satcount can be set. RTH is a more emergency function where a bigger error/lower satcount is OK. I made these variables accessible in the config.h

Code: Select all

#define MINSATPH 7                     // 5 is default minimal number of sats for gps PosHold, i found valid data with 7 sats. Since PH is luxury we want more sats..
#define MINSATRTH 5                    // 5 is default minimal number of sats for gps Return to Home since this is more an emergency function a 20m error doesn't matter

Concerning the MTK Binary mode i activated everything beneficial i could find. The most of it will be probably already on. The delay between commands is still set to 500 ms :) .....
The simple spikefilter seems to be very usable on 5Hz data.
Keep up your outstanding work !!!

Cheers

Kraut Rob
by EOSBandi
Tue Dec 11, 2012 2:57 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Crashpilot1000 wrote:@EOS Bandi:
I took your code http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q= and did my crazy changes to it. I want to post it "as it is" perhaps it is of some use perhaps an example of how not to do it...
The changes:
I put the multiwii serial part into your code, eliminating the arduino "Serial.begin" etc stuff. The inbuffer is set to 256 Bytes. The whole serial part is modular under the Tab "Serial". I implemented an experimental spikefilter wich i documented here (http://diydrones.com/forum/topics/perha ... pikefilter) it can be turned on/off in the config.h with #define SPIKEFILTER. It sits after the gps data aquisition and before your moving average filter. While playing around with your moving averagefilter i found it useful to be able to turn it off without recompiling the whole mwii code (since your filter is only recommended for 10Hz NMEA data). So i added "#define AFALWAYSOFF" in the config.h to turn off the averagefilter. Than i fiddled around to eliminate the sudden breakouts of the copter during PH etc. So far i couldn't test it because of the wheather. Here is what i did: In case of low sat count (default 5) the nav parameters are reset. In that case i set last_longitude and last_latitude to zero to force the velocity calculation to reset. I am not sure if it is done already. The next thing i did was to make the minimal sat number for gps functions accessible in the config.h "#define MINSAT 7" i set it to 7 because with 5 satellites i see errors in th 30+m range. So no breakouts due to wacky gps positions. I set this nmea parsing variable to unit_32 - i know that a positive effect is doubtful but it can not harm anyway...
Than i replaced the DIY Drones binary protocol parser with my own. Because i had it already done and wanted to put it to use:). I changed the initialization of MTK (binary mode) to the original apm sequence. I stumbled upon a crazy WAAS_ON sequence (http://diydrones.com/forum/topics/myste ... k-common-h). I let it in, perhaps it's some undocumented 3drobotics magic code. Currently i set the MTK to this:
Binary, 57K Baud, 5Hz, SBAS, WAAS, Navthreshold: OFF

The config.h looks like this now (example config for mtk in binary and experimental spikefilter):

Code: Select all

// *********************************** GENERAL GPS TYPE
//#define NMEA
//#define UBLOX
#define MTK                            // Defined: Binary, 57K Baud, 5Hz, SBAS, WAAS, Navthreshold: OFF

// *********************************** GENERAL FILTER VALUES
#define SPIKEFILTER                    // Turn on experimental spikefilter
#define AFALWAYSOFF                    // Always turn off the moving average filter("AF"), doesn't matter whats in mwii config.h defined

// *********************************** GENERAL GPS VALUES
#define MINSAT 7                       // 5 is default minimal number of sats for gps functions, i found valid data with 7 sats

// *********************************** MTK BINARY SPECIAL (FW:AXN1.51_2722_3329_384.1151100.5.bin)
//#define MTK10HZ                      // According to this post: http://www.multiwii.com/forum/viewtopic.php?f=6&t=1881&start=10#p19325
                                       // when enabeling 10HZ in mtk binary mode, you will loose SBAS functionality!! That will just work at 5Hz (default).


So long
Kraut Rob


I did not reviewed it yet, but what I know that $PSRF sentences are for the SIRF chipset, so the "mystery" init sequence very likely some leftover from transferring code segments between gps implementations. MTK chipsets definitely will not understand that.
by Crashpilot1000
Tue Dec 11, 2012 2:46 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

@EOS Bandi:
I took your code http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q= and did my crazy changes to it. I want to post it "as it is" perhaps it is of some use perhaps an example of how not to do it...
The changes:
I put the multiwii serial part into your code, eliminating the arduino "Serial.begin" etc stuff. The inbuffer is set to 256 Bytes. The whole serial part is modular under the Tab "Serial". I implemented an experimental spikefilter wich i documented here (http://diydrones.com/forum/topics/perha ... pikefilter) it can be turned on/off in the config.h with #define SPIKEFILTER. It sits after the gps data aquisition and before your moving average filter. While playing around with your moving averagefilter i found it useful to be able to turn it off without recompiling the whole mwii code (since your filter is only recommended for 10Hz NMEA data). So i added "#define AFALWAYSOFF" in the config.h to turn off the averagefilter. Than i fiddled around to eliminate the sudden breakouts of the copter during PH etc. So far i couldn't test it because of the wheather. Here is what i did: In case of low sat count (default 5) the nav parameters are reset. In that case i set last_longitude and last_latitude to zero to force the velocity calculation to reset. I am not sure if it is done already. The next thing i did was to make the minimal sat number for gps functions accessible in the config.h "#define MINSAT 7" i set it to 7 because with 5 satellites i see errors in th 30+m range. So no breakouts due to wacky gps positions. I set this nmea parsing variable to unit_32 - i know that a positive effect is doubtful but it can not harm anyway...
Than i replaced the DIY Drones binary protocol parser with my own. Because i had it already done and wanted to put it to use:). I changed the initialization of MTK (binary mode) to the original apm sequence. I stumbled upon a crazy WAAS_ON sequence (http://diydrones.com/forum/topics/myste ... k-common-h). I let it in, perhaps it's some undocumented 3drobotics magic code. Currently i set the MTK to this:
Binary, 57K Baud, 5Hz, SBAS, WAAS, Navthreshold: OFF

The config.h looks like this now (example config for mtk in binary and experimental spikefilter):

Code: Select all

// *********************************** GENERAL GPS TYPE
//#define NMEA
//#define UBLOX
#define MTK                            // Defined: Binary, 57K Baud, 5Hz, SBAS, WAAS, Navthreshold: OFF

// *********************************** GENERAL FILTER VALUES
#define SPIKEFILTER                    // Turn on experimental spikefilter
#define AFALWAYSOFF                    // Always turn off the moving average filter("AF"), doesn't matter whats in mwii config.h defined

// *********************************** GENERAL GPS VALUES
#define MINSAT 7                       // 5 is default minimal number of sats for gps functions, i found valid data with 7 sats

// *********************************** MTK BINARY SPECIAL (FW:AXN1.51_2722_3329_384.1151100.5.bin)
//#define MTK10HZ                      // According to this post: http://www.multiwii.com/forum/viewtopic.php?f=6&t=1881&start=10#p19325
                                       // when enabeling 10HZ in mtk binary mode, you will loose SBAS functionality!! That will just work at 5Hz (default).


So long
Kraut Rob
by Crashpilot1000
Sun Dec 09, 2012 3:28 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

EPIC FAIL!!!

@EOS Bandi:

You are right! That was an epic fail of me. But somehow i don't feel to shabby because i rechecked putty. It was set to "Logging: All session output", and the zero bytes in the datasets with satfix were transmitted, but somehow it decides when to much zero bytes occur to cut them out! Your tip of using Realterm was the key! Now all datasets are displayed correctly! This confusion has one upside: Now i have my own working and reliable mtk binary parser. It might be obsolete now but i post it anyway, maybe it is of some use for somebody.

Code: Select all

bool GPS_MTK_newFrame(uint8_t data)
{
   static uint8_t pstep;                              // Parse Step
   static uint8_t lastbyte;                           // Last Byte for Sync detection
   static uint8_t LSLshifter;                         // Bitshiftvalue
   static uint8_t chkA,count;

   static int32_t lat;                                // MTK Dataset
   static int32_t lon;                                // MTK Dataset
   static int32_t alt;                                // MTK Dataset
   static int32_t grspeed;                            // MTK Dataset
   static int32_t grcourse;                           // MTK Dataset
   static uint8_t satn,fixtype;                       // MTK Dataset
   int32_t tmp32;
   bool parsed;
   
   parsed = false;

   if (pstep == 0 && data == 0xdd && lastbyte == 0xd0) pstep = 100; // Detect Sync "0xD0,0xDD" Only search for Sync when not already decoding
   lastbyte = data;

   switch(pstep) {
    case 0:                                           // Special Case: Do Nothing
    break;
    case 100:                                         // Special Case: Prepare next decoding run
    pstep = 1;                                        // Jump into decoding on next run
    chkA = 0; count = 0;                              // Reset values
    break;

    case 1:                                           // Payload Byte is always $20! (This is the first Byte after sync preamble)
    if (data == 0x20) pstep++;                        // Since it is always $20 we take it as extended, undocumented syncword "preamble3"
     else pstep =0;                                   // Error! Wait for sync
    chkA = chkA + data;
    count ++;
    break;

    case 2:                                           // Read Dataset Latitude
    lat = data;
    LSLshifter = 0;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
    case 3:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    lat = lat | tmp32;
    if (LSLshifter == 24){lat = lat * 10; pstep++;}
    chkA = chkA + data;
    count ++;
    break;   

    case 4:                                           // Read Dataset Longitude
    lon = data;
    LSLshifter = 0;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
    case 5:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    lon = lon | tmp32;
    if (LSLshifter == 24){lon = lon * 10; pstep++;}
    chkA = chkA + data;
    count ++;
    break;

    case 6:                                           // Read Dataset MSL Altitude
    alt = data;
    LSLshifter = 0;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
    case 7:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    alt = alt | tmp32;
    if (LSLshifter == 24){alt = alt/100; pstep++;}
    chkA = chkA + data;
    count ++;
    break;

    case 8:                                           // Read Dataset Ground Speed
    grspeed = data;
    LSLshifter = 0;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
    case 9:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    grspeed = grspeed | tmp32;
    if (LSLshifter == 24) pstep++;
    chkA = chkA + data;
    count ++;
    break;

    case 10:                                          // Read Dataset Heading
    grcourse = data;
    LSLshifter = 0;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
    case 11:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    grcourse = grcourse | tmp32;
    if (LSLshifter == 24) pstep++;
    chkA = chkA + data;
    count ++;
    break;

    case 12:                                          // Read number of satellites in view
    satn = data;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;
   
    case 13:                                          // Read Fix Type
    fixtype = data;
    pstep++;
    chkA = chkA + data;
    count ++;
    break;

    case 14:                                          // Wait for cheksum A
    if (count == 33){                                 // 33 = 0x21
      if (chkA == data) pstep++;                      // ChecksumA reached. Correct? than go on
       else pstep = 0;                                // Error?
    }else{
      chkA = chkA + data;
      count ++;}
    break;

    case 15:                                          // Dataset RDY !! Cheksum B omitted, ChkA was OK
    if (fixtype==1){                                  // No Fix
    i2c_dataset.status.gps2dfix = 0;
    i2c_dataset.status.gps3dfix = 0;}
    if (fixtype==2){                                  // GPS 2D Fix
    i2c_dataset.status.gps2dfix = 1;
    i2c_dataset.status.gps3dfix = 0;}
    if (fixtype==3){                                  // GPS 3D Fix
    i2c_dataset.status.gps2dfix = 1;
    i2c_dataset.status.gps3dfix = 1;}
    GPS_read[LAT] = lat;
    GPS_read[LON] = lon;
    i2c_dataset.altitude = alt;
    i2c_dataset.ground_speed = grspeed;
    i2c_dataset.ground_course = grcourse;
    i2c_dataset.status.numsats = satn;
    parsed = true;                                    // RDY
    pstep = 0;                                        // Do nothing
    break;
   }
 return parsed;
}


BTW: I use MTK 3329 with your recommended FW AXN1.51_2722_3329_384.1151100.5.bin. It is called LZ-GPS (http://www.wii-copter.de/lz-gps.html)

So long
Kraut
Rob
by EOSBandi
Sat Dec 08, 2012 10:02 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Crashpilot1000 wrote:@Vaattari:

Thank you for your interest! I use the eos bandi recommended FW AXN1.51_2722_3329_384.1151100.5.bin (http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q=). The change of the baudrates is not accessible in config.h you have to change it in the code directly. I monitored the traffic between arduino and the gps with an ftdi adapter and the free terminal software "PUTTY". Afterwards i analyzed the log file with hexedit (shareware). I will have to change the code from above to sort out gps positions wich produce the syncword... but stay tuned. I think using mtk in binary mode (like ublox) is the way to go.

So long
Kraut Rob


Well, it seems that your capture setup is somehow omits zeroes from the output... try using realterm instead of putty and hexedit....
by Crashpilot1000
Sat Dec 08, 2012 5:06 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

@wilco1967: Your assumption is correct.
I don't know if it is so much better, but it is better than NMEA.
I improved the mtk binary read out from the last post. Since the preamble "D0 DD" is always followed by $20 i took this value as further preamblebyte. So this bytesequence is used for sync now: "D0 DD 20". The next problem is the damn inconstant size of a complete dataset whether sattelites are available or not. The next problem is, that the sync could be generated by lat/lon data so i disabled sync search while lat/lon aquisition.
Here is my next code proposal for MTK binary parsing:

Code: Select all

bool GPS_MTK_newFrame(uint8_t data)
{
   static uint8_t pstep;                              // Parse Step
   static uint8_t lastbyte;                           // Last Byte for Sync detection
   static uint8_t LSLshifter;                         // Bitshiftvalue

   static int32_t lat;                                // MTK Dataset
   static int32_t lon;                                // MTK Dataset
   static int32_t alt;                                // MTK Dataset
   static int32_t grspeed;                            // MTK Dataset
   static int32_t grcourse;                           // MTK Dataset
   static uint8_t satn;                               // MTK Dataset
   int32_t tmp32;
   bool parsed;
   
   parsed = false;

   if(pstep == 0 || pstep>5){                         // Only search for Sync when idle or lat and lon already decoded.
    if (data == 0xdd && lastbyte == 0xd0) pstep = 100;// Detect Sync "0xD0,0xDD"
   }
   lastbyte = data;

   switch(pstep) {
    case 0:                                           // Special Case: Do Nothing
    break;
    case 100:                                         // Special Case: Jump into decoding on next run
    pstep = 1;
    break;

    case 1:                                           // Payload Byte is always $20! (This is the first Byte after sync preamble)
    if (data == 0x20) pstep++;                        // Since it is always $20 we take it as extended, undocumented syncword "preamble3"
     else pstep =0;
    break;

    case 2:                                           // Read Dataset Latitude
    lat = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 3:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    lat = lat | tmp32;
    if (LSLshifter == 24){lat = lat * 10; pstep++;}
    break;   

    case 4:                                           // Read Dataset Longitude
    lon = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 5:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    lon = lon | tmp32;
    if (LSLshifter == 24){lon = lon * 10; pstep++;}
    break;

    case 6:                                           // Read Dataset MSL Altitude
    alt = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 7:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    alt = alt | tmp32;
    if (LSLshifter == 24){alt = alt/100; pstep++;}
    break;

    case 8:                                           // Read Dataset Ground Speed
    grspeed = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 9:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    grspeed = grspeed | tmp32;
    if (LSLshifter == 24) pstep++;
    break;

    case 10:                                          // Read Dataset Heading
    grcourse = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 11:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    grcourse = grcourse | tmp32;
    if (LSLshifter == 24) pstep++;
    break;

    case 12:                                          // Read number of satellites in view
    satn = data;
    pstep++;
    break;
   
    case 13:                                          // Read Fix Type and finish readout, mwii does not need the rest
    if (data==1){                                     // No Fix
    i2c_dataset.status.gps2dfix = 0;
    i2c_dataset.status.gps3dfix = 0;}
    if (data==2){                                     // GPS 2D Fix
    i2c_dataset.status.gps2dfix = 1;
    i2c_dataset.status.gps3dfix = 0;}
    if (data==3){                                     // GPS 3D Fix
    i2c_dataset.status.gps2dfix = 1;
    i2c_dataset.status.gps3dfix = 1;}
    GPS_read[LAT] = lat;
    GPS_read[LON] = lon;
    i2c_dataset.altitude = alt;
    i2c_dataset.ground_speed = grspeed;
    i2c_dataset.ground_course = grcourse;
    i2c_dataset.status.numsats = satn;
    parsed = true;                                    // RDY
    pstep = 0;                                        // Do nothing with the next bytes
    break;
   }
 return parsed;
}



So long

Rob
by wilco1967
Sat Dec 08, 2012 2:51 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

am I correct in assuming that MTK binary protocol is only available in I2C GPS, an not for the serial GPS (directly to Mega) ?

Is binary really soo much better than NEMA ?

Currently using a flyduino with 3329 GPS.... it works fine, but pos hold still rather poor (upto 10 meters drifting off). Perhaps binary mode will improve that, but find it difficult to believe...
by Crashpilot1000
Sat Dec 08, 2012 2:04 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

@Vaattari:

Thank you for your interest! I use the eos bandi recommended FW AXN1.51_2722_3329_384.1151100.5.bin (http://code.google.com/p/i2c-gps-nav/do ... p&can=2&q=). The change of the baudrates is not accessible in config.h you have to change it in the code directly. I monitored the traffic between arduino and the gps with an ftdi adapter and the free terminal software "PUTTY". Afterwards i analyzed the log file with hexedit (shareware). I will have to change the code from above to sort out gps positions wich produce the syncword... but stay tuned. I think using mtk in binary mode (like ublox) is the way to go.

So long
Kraut Rob
by Crashpilot1000
Sat Dec 08, 2012 9:34 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Hi!
From inspecting the MTK serial datastream in binary mode i found some problems wich the current readout in the I2C version, wich also exists in the apm code. The checksum B is not transmitted at all. I rewrote the binary readout for mtk. I omitted the single byte checksum, because i found it useless anyway. It can be added. I watched the data over minutes at 57K serial speed and 10Hz MTK updaterate and had no serial errors at all. Sorry for the simple code - but it works! Perhaps the binary mtk protocol can be re-enabled in the next DEV?

Code: Select all

bool GPS_MTK_newFrame(uint8_t data)
{
   static uint8_t pstep;                              // Parse Step
   static uint8_t lastbyte;                           // Last Byte for Sync detection
   static uint8_t LSLshifter;                         // Bitshiftvalue

   static int32_t lat;                                // MTK Dataset
   static int32_t lon;                                // MTK Dataset
   static int32_t alt;                                // MTK Dataset
   static int32_t grspeed;                            // MTK Dataset
   static int32_t grcourse;                           // MTK Dataset
   static uint8_t satn;                               // MTK Dataset
   int32_t tmp32;
   bool parsed;
   
   parsed = false;

   if (data == 0xdd && lastbyte == 0xd0) pstep = 100; // Detect Sync "0xD0,0xDD"
   lastbyte = data;

   switch(pstep) {
    case 0:                                           //  Special Case: Do Nothing
    break;
    case 100:                                         //  Special Case: Jump into decoding on next run
    pstep = 1;
    break;

    case 1:                                           //  Ignore Payload Byte (This is the first Byte after sync preamble)
    pstep++;
    break;

    case 2:                                           // Read Dataset Latitude
    lat = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 3:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    lat = lat | tmp32;
    if (LSLshifter == 24){lat = lat * 10; pstep++;}
    break;   

    case 4:                                           // Read Dataset Longitude
    lon = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 5:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    lon = lon | tmp32;
    if (LSLshifter == 24){lon = lon * 10; pstep++;}
    break;

    case 6:                                           // Read Dataset MSL Altitude
    alt = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 7:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    alt = alt | tmp32;
    if (LSLshifter == 24){alt = alt/100; pstep++;}
    break;

    case 8:                                           // Read Dataset Ground Speed
    grspeed = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 9:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    grspeed = grspeed | tmp32;
    if (LSLshifter == 24) pstep++;
    break;

    case 10:                                          // Read Dataset Heading
    grcourse = data;
    LSLshifter = 0;
    pstep++;
    break;
    case 11:
    LSLshifter = LSLshifter+8;
    tmp32 = data;
    tmp32 = tmp32<<LSLshifter;
    grcourse = grcourse | tmp32;
    if (LSLshifter == 24) pstep++;
    break;

    case 12:                                          // Read number of satellites in view
    satn = data;
    pstep++;
    break;
   
    case 13:                                          // Read Fix Type and finish readout, mwii does not need the rest
    if (data==1){                                     // No Fix
    i2c_dataset.status.gps2dfix = 0;
    i2c_dataset.status.gps3dfix = 0;}
    if (data==2){                                     // GPS 2D Fix
    i2c_dataset.status.gps2dfix = 1;
    i2c_dataset.status.gps3dfix = 0;}
    if (data==3){                                     // GPS 3D Fix
    i2c_dataset.status.gps2dfix = 1;
    i2c_dataset.status.gps3dfix = 1;}
    GPS_read[LAT] = lat;
    GPS_read[LON] = lon;
    i2c_dataset.altitude = alt;
    i2c_dataset.ground_speed = grspeed;
    i2c_dataset.ground_course = grcourse;
    i2c_dataset.status.numsats = satn;
    parsed = true;                                    // RDY
    pstep = 0;                                        // Do nothing with the next bytes
    break;
   }
 return parsed;
}



So long
Kraut Rob
by Crashpilot1000
Thu Dec 06, 2012 6:26 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Hi mbrak!
I wouldn't flash until you have a save fallback. From what i can read in the shop description they don't publish the current flashed FW. BTW perhaps the FW is compatible to the binary protocol, ask flyduino. In that case you could use #define MTK and alter the main code:

Code: Select all

....
#if defined(MTK)
/* Using the AXN 1.51 firmware which defaults at 1Hz/38400 but supports binary protocol
* First connect to it with 38400, then set the speed to 115200
* and set the update rate to 10Hz
* and finally switch to Binary mode
*/

Serial.begin(38400);

to

Code: Select all

....
#if defined(MTK)
/* Using the AXN 1.51 firmware which defaults at 1Hz/38400 but supports binary protocol
* First connect to it with 38400, then set the speed to 115200
* and set the update rate to 10Hz
* and finally switch to Binary mode
*/

Serial.begin(115200);
...


I would ask flyduino what the "WAAS" enabled FW can do for you in europe since we have SBAS sattelites....

Grüsse

Rob
by Crashpilot1000
Thu Dec 06, 2012 3:09 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Thanks EOSBandi for your reply. 5Hz change done :)

Even after change the update rate from 10Hz to 5Hz the static coordinate measurements were still going all over the place. Just to see the difference I then enabled the GPS filter in Config.h. It seems to do a lot.
We have -20C outside at the moment so I did not test fly. :|
These measurements were taken after 10 minutes of power on and duration is 15 minutes each. Is there any other issue than a delay in correction if wind push the copter away?

Thanks,
janne


BTW the Filter is only active in Pos.Hold mode.
From what i figured out the main problem seems to be the solid dataaquisition. I played around with different modes(NMEA/Binary) and baud rates(115K,57K) and refresh rates(5,10HZ) on my MTK. At the end of the day i think doing 115k on the serial produces drop outs or some weird dataproblems. Maybe it is a Buffer thing or the Serial.read() is somehow wacky at that speed. I got good results with the mtk binary protocol (the firmware recommended by eos bandi: AXN1.51_2722_3329_384.1151100.5.bin - on his d/l page) at 57K serial speed and 10Hz update rate. It seems strange but that worked best. Perhaps the serial readout of the original mwii code is more reliable than the on used in the I2C solution? I don't know. With the nice infos from this post viewtopic.php?f=8&t=649&start=40#p4085 the codechange was very easy. If somebody else wants to try it:

Original:

Code: Select all

....
#if defined(MTK)
/* Using the AXN 1.51 firmware which defaults at 1Hz/38400 but supports binary protocol
 * First connect to it with 38400, then set the speed to 115200
 * and set the update rate to 10Hz
 * and finally switch to Binary mode
 */

Serial.begin(38400);
delay(1500); //let it init
Serial.write("$PMTK251,115200*1F\r\n");
delay(300);
Serial.end();

Serial.begin(115200);
Serial.write("$PGCMD,16,0,0,0,0,0*6A\r\n");
delay(1000);
Serial.write("$PGCMD,16,0,0,0,0,0*6A\r\n");
delay(300);
Serial.write("$PMTK220,100*2F\r\n");
#else
  //open serial port at 115200
  Serial.begin(GPS_SERIAL_SPEED);
#endif
....


To:

Code: Select all

....
#if defined(MTK)
/* Using the AXN 1.51 firmware which defaults at 1Hz/38400 but supports binary protocol
 * First connect to it with 38400, then set the speed to 57600
 * and set the update rate to 10Hz
 * and finally switch to Binary mode
 */

Serial.begin(38400);                          // Handshake
delay(1500); //let it init
Serial.write("$PMTK251,57600*2C\r\n");     // Go down to 57K for data integrity
delay(1000);
Serial.end();
delay(500);
Serial.begin(57600);
Serial.write("$PGCMD,16,0,0,0,0,0*6A\r\n");
delay(1000);
Serial.write("$PGCMD,16,0,0,0,0,0*6A\r\n");
delay(300);
Serial.write("$PMTK220,100*2F\r\n");
#else
  //open serial port at 115200
  Serial.begin(GPS_SERIAL_SPEED);
#endif
....


Anyway while browsing the code i found another question i would like to ask.
There is a part in the code "we does not have 3d fix or numsats less than 5 , stop navigation" (line 1356) than this is executed:

Code: Select all

{      // we does not have 3d fix or numsats less than 5 , stop navigation
                 nav_lat = 0;
                 nav_lon = 0;
                 GPSMode = GPSMODE_NONAV;
                 nav_mode = NAV_MODE_NONE;
                 wp_distance = 0;
                 i2c_dataset.distance_to_home = 0;
                 i2c_dataset.home_to_copter_bearing = 0;
                 GPS_update_i2c_dataset();
               }


Wouldn't it make sense to reset the "static void GPS_calc_velocity" variables "last_longitude" and "last_latitude" also like this:

Code: Select all

{      // we does not have 3d fix or numsats less than 5 , stop navigation
                 last_longitude = 0;               //Crashpilot Reset Velocity LON
                 last_latitude  = 0;               //Crashpilot Reset Velocity LAT
                 nav_lat = 0;
                 nav_lon = 0;
                 GPSMode = GPSMODE_NONAV;
                 nav_mode = NAV_MODE_NONE;
                 wp_distance = 0;
                 i2c_dataset.distance_to_home = 0;
                 i2c_dataset.home_to_copter_bearing = 0;
                 GPS_update_i2c_dataset();
               }


Just another 2 cents, i hope i don't bother everyone here..

So long
Kraut Rob
by Vaattari
Mon Dec 03, 2012 7:09 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

EOSBandi wrote:
Vaattari wrote:Hello,

Can someone please explain why GPS filtering is not needed in binary mode? I logged today the GPS data with WinGUI and there is few big errors coming in from the I2C GPS. The position jumps suddendly like 30+ meters and comes back with the next measurement. These are not filtered by the FC if filtering is disabled or is there a constrain somewhere to handle such jumps? If there is one, can it be tuned to give less room for big changes?

I'm pretty happy with the current GPS in position hold but it is not yet rock solid ;)
http://www.youtube.com/watch?v=TOPzr8Kbhyk

Thanks in advance,
Janne


30 meter jumps are unnacceptable, you either does not have enough sats in view or some other malfunctions are happening. You can mask these errors with filtering up to a certain extent, but it will not solve it.

Filtering is supposed to eliminate the relatively low position resolution of the NMEA protocol. With binary (either ublox or mtk) this kind of filtering is not required.
BTW, last time i checked the MTK binary protocol was acceptable only at 5Hz, and the same is true for ublox too.

EOS


Thanks EOSBandi for your reply. 5Hz change done :)

Even after change the update rate from 10Hz to 5Hz the static coordinate measurements were still going all over the place. Just to see the difference I then enabled the GPS filter in Config.h. It seems to do a lot.
We have -20C outside at the moment so I did not test fly. :|
These measurements were taken after 10 minutes of power on and duration is 15 minutes each. Is there any other issue than a delay in correction if wind push the copter away?

Thanks,
janne
by EOSBandi
Sat Dec 01, 2012 6:27 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Vaattari wrote:Hello,

Can someone please explain why GPS filtering is not needed in binary mode? I logged today the GPS data with WinGUI and there is few big errors coming in from the I2C GPS. The position jumps suddendly like 30+ meters and comes back with the next measurement. These are not filtered by the FC if filtering is disabled or is there a constrain somewhere to handle such jumps? If there is one, can it be tuned to give less room for big changes?

I'm pretty happy with the current GPS in position hold but it is not yet rock solid ;)
http://www.youtube.com/watch?v=TOPzr8Kbhyk

Thanks in advance,
Janne


30 meter jumps are unnacceptable, you either does not have enough sats in view or some other malfunctions are happening. You can mask these errors with filtering up to a certain extent, but it will not solve it.

Filtering is supposed to eliminate the relatively low position resolution of the NMEA protocol. With binary (either ublox or mtk) this kind of filtering is not required.
BTW, last time i checked the MTK binary protocol was acceptable only at 5Hz, and the same is true for ublox too.

EOS
by dROb
Sat Nov 03, 2012 11:45 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Guys, please advise where can I have problem:
I've got diy converter UART-i2c, based on the standard scheme by EOSBandi (or, anyway, just a general standart scheme from interner somewhere :) ),
GPS Module is MTK3339, yet without a binary protocol (yet I have no such firmware for 3339. BTW, maybe someone have?), so data is coming in NMEA

Judging from the UART sniffing - converter as planned is connecting to the module on 9600bps, switches it to 115200, reconnect to module at that speed, and puts the module in 10Hz. This all works. After that, the converter flashing LED lights 1s-1s on-off, which means "not receiving NMEA data". Integrity of pins RX, TX was checked - its all right.

Thought here - maybe I'm the first who is trying to get the converter work with NMEA, and there is an error somewhere in the code? (basically most of the people use uBlox and MTK binary protocols)
by cswiger
Tue Oct 09, 2012 10:27 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Huh, even with gps protocol set and verified in binary, navigatron equiped quad *still* has a case of twitching, no change at all.

https://www.youtube.com/watch?v=6gQb0R9Nsfw

Turning on gps filtering seems to help (subjective, hard to measure 'twitch') altho we are told it's not needed with mtk binary : :?:

6 decimal places precision
by cswiger
Mon Oct 08, 2012 3:56 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Oh, think I got it - had to update the mtk3329 on the Navigatron to the latest and greatest v1.6 ( http://code.google.com/p/ardupilot/wiki/MediaTek ) and NOW the setup part of I2C_GPS_NAV works - at least when copy/pasting the command into realterm ( http://diydrones.com/profiles/blogs/usi ... s-gps-with ) - it starts out in 38400, switches to 115200, switching to binary then sets update rate to 10HZ, at least in realterm - real world test coming soon. Hopefully the low res nmea sentence twitching will end now.

#if defined(MTK)
/* Using the AXN 1.51 firmware which defaults at 1Hz/38400 but supports binary protocol
* First connect to it with 38400, then set the speed to 115200
* and set the update rate to 10Hz
* and finally switch to Binary mode
*/

Serial.begin(38400);
delay(1500); //let it init
Serial.write("$PMTK251,115200*1F\r\n"); // set 115200 baud
delay(300);
Serial.end();

Serial.begin(115200);
Serial.write("$PGCMD,16,0,0,0,0,0*6A\r\n"); // binary
delay(1000);
Serial.write("$PGCMD,16,0,0,0,0,0*6A\r\n"); // twice ??
delay(300);
Serial.write("$PMTK220,100*2F\r\n"); // 10Hz update
by cswiger
Sun Oct 07, 2012 3:19 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Ok, finally got some time and a new ftdi board (the ckdevices one for easy rx/tx crossover) - my goal is to get binary gps data running instead of nmea to get rid of the twitching during gps hold and rth. I've uploaded the mtk 3329 with MTK3329_A1.5E_20110118_10Hz_115200.bin and using the stock I2C_GPS_NAV with MTK set but when snooping the gps module output (in crossover) it still prints lines like:

$GPRMC,004526.900,A,3820.8585,N,08140.6991,W,57.03,318.26,071012,,,A*49

with the twitchy .0001 minute resolution. I thought it should be setting it to binary:

#if defined(MTK)
/* Using the AXN 1.51 firmware which defaults at 1Hz/38400 but supports binary protocol
* First connect to it with 38400, then set the speed to 115200
* and set the update rate to 10Hz
* and finally switch to Binary mode
*/
by crashlander
Wed Oct 03, 2012 8:52 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

pm1 wrote:
Mis wrote:Because in this case MORE Hz is not EQUAL to BETTER. It was written about it about 100 times. GPS have worst precision at 10Hz.


Where does this wisdom come from? Is it because MTK GPSs cannot use WAAS/Egnos at 10 Hz? The precision is a don't care for me. I do not want to make geographical measurements. Consecutive measurements have to be consistent and reflect the movements of the copter. For ublox GPS with 10 Hz this works absolutely fine.

Neo6 is 5Hz by spec. so 10Hz is just some more noise. :)
And when using UBLOX binary protocol you get much better resolution (not precision) and you do not need GPS_FILTERING so you get true 5Hz and not filtered 2Hz (from 10Hz)...
EOSBandi explained that stuff many pages back....
by mmattila
Tue Aug 28, 2012 6:43 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Hi,

Does anyone know if Flyiduino FMP04 (pre 12.07.12) can be flashed with binary protocol SW for MTK 3329. It is MTK 3329 based, but I dont know if it is internally same as PA6B. Layout is at least different.

-Markus
by tsoum
Mon Aug 27, 2012 9:53 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Tizzy wrote:
Bledi wrote:
tsoum wrote:Hello Eosbandi,
i have the following gps board from adafruit that uses a MTK3339 chip: http://www.adafruit.com/products/746#tutorials.
I would like to ask you if this is compatible whith I2C gps. If it is, can i flash it with MTK3329 firmware? If not is it going to be in your future plans?
Thanks in advance!
George

yes it's work (it's what I am using) but you can't use MTK binary protocol. Don't try to flash it with MTK3329 firmware

I've been trying to get my LS20031 MTK3339 working for days now with a Crius AIOP and mwii 2.1, but it has a hard time holding it's config. The module is running the 1.30 firmware but defaults to 57600 1Hz if left to the battery. I tried flashing the firmware to 115200 and 10Hz but that gave an error (illegal sync command at the end) and I'd actually prefer to get it initialized properly by the FC on boot so the unused sentences are switched off.
I've swapped the original gps.ino out with EosBandi's, changed the config.h GPS_BAUD to 57600 and defined MTK and the LEAD_FILTER. I then added the MTK init in the multiwii_2.1.ino. Not working, the FC doesn't receive any data altho the gps module does get initialized.

Checking the code in gps.ino it sets binary mode so I was wondering based on the above remark if it's enough to comment out that line or is there something else I need to do?

My gps works on 9600 baud and 10 Hz.
I didn't solve my problem in this forum, so i asked for help in: http://www.rcgroups.com/forums/showthre ... &page=1885 (my nickname is tsoumelman)
There is a guy named "kristaps_r" that helped me. He send me an attached code for my gps. I didn't flash the gps, i only uploaded the code on my I2C arduino and it worked! I had 10 satelites in GUI!
So i think this guy could help you. I also think that Eosbandi sould check and integrade this change in his code.
by Tizzy
Sun Aug 26, 2012 8:18 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Bledi wrote:
tsoum wrote:Hello Eosbandi,
i have the following gps board from adafruit that uses a MTK3339 chip: http://www.adafruit.com/products/746#tutorials.
I would like to ask you if this is compatible whith I2C gps. If it is, can i flash it with MTK3329 firmware? If not is it going to be in your future plans?
Thanks in advance!
George

yes it's work (it's what I am using) but you can't use MTK binary protocol. Don't try to flash it with MTK3329 firmware

I've been trying to get my LS20031 MTK3339 working for days now with a Crius AIOP and mwii 2.1, but it has a hard time holding it's config. The module is running the 1.30 firmware but defaults to 57600 1Hz if left to the battery. I tried flashing the firmware to 115200 and 10Hz but that gave an error (illegal sync command at the end) and I'd actually prefer to get it initialized properly by the FC on boot so the unused sentences are switched off.
I've swapped the original gps.ino out with EosBandi's, changed the config.h GPS_BAUD to 57600 and defined MTK and the LEAD_FILTER. I then added the MTK init in the multiwii_2.1.ino. Not working, the FC doesn't receive any data altho the gps module does get initialized.

Checking the code in gps.ino it sets binary mode so I was wondering based on the above remark if it's enough to comment out that line or is there something else I need to do?
by kipkool
Mon Aug 06, 2012 11:43 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Hi EosBandi,

I use a mtk3339 here.
I've loaded it with this custom firwmare ( 115200bps + 10hz by default ): AXN2.10_5156_3339_1152.1101000.10.bin
This one doesn't seems to work with MTK binary protocol, only NMEA. Is there some parameter I can setup on miniGPS to activate binary protocol ?

Or do you know other firmware that works ?

That's strange cause for 3329 , 1.51 firmware is ok, but not in 3339 with 2.10 one.


thanks.

EDT. I've found this undocumented commandto enable binary mode: Serial.write("$PGCMD,16,0,0,0,0,0*6A\r\n"); I'll try this later.
by tsoum
Sat Aug 04, 2012 9:11 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Bledi wrote:
tsoum wrote:Hello Eosbandi,
i have the following gps board from adafruit that uses a MTK3339 chip: http://www.adafruit.com/products/746#tutorials.
I would like to ask you if this is compatible whith I2C gps. If it is, can i flash it with MTK3329 firmware? If not is it going to be in your future plans?
Thanks in advance!
George

yes it's work (it's what I am using) but you can't use MTK binary protocol. Don't try to flash it with MTK3329 firmware

Thanks Bledi,
i'm happy to hear that it works! Could you describe what exactly shoud i do to make it work for me too? (Because i'm not so familiar with the i2c gps software procedures).
George
by Bledi
Fri Aug 03, 2012 2:43 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

tsoum wrote:Hello Eosbandi,
i have the following gps board from adafruit that uses a MTK3339 chip: http://www.adafruit.com/products/746#tutorials.
I would like to ask you if this is compatible whith I2C gps. If it is, can i flash it with MTK3329 firmware? If not is it going to be in your future plans?
Thanks in advance!
George

yes it's work (it's what I am using) but you can't use MTK binary protocol. Don't try to flash it with MTK3329 firmware
by EOSBandi
Tue Jul 31, 2012 9:44 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

check config.h in I2C_GPS_NAV
Esp these :

/* Serial speed of the GPS */
#define GPS_SERIAL_SPEED 115200

/* GPS protocol
* NMEA - Standard NMEA protocol GGA, GSA and RMC sentences are needed
* UBLOX - U-Blox binary protocol, use the ublox config file (u-blox-config.ublox.txt) from the source tree
* MTK - MTK binary protocol with auto setup, load (AXN1.51_2722_3329_384.1151100.5.bin) firmware to the GPS module (MTK3329 chips only)
* With MTK and UBLOX you don't have to use GPS_FILTERING in multiwii code !!!
*
*/
//#define NMEA
//#define UBLOX
#define MTK
by toxik31
Mon Jul 23, 2012 2:35 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Hello everybody,

I use the following GPS (http://www.drotek.fr/shop/en/90-pa6c-gps-llc.html) in NEMA mode.
It is based on the MT3339 from MediaTek.
Automatic configuration for MTK Binary protocol (must use the AXN1.51_2722_3329_384.1151100.5 firmware which can be found in the updated FirmWare tools package)


mt3329 can be used with binary Protocol if we flash a new compliant firmware.
Can I use the binary protocol with the MT3339?
Has anyone a compliant firmware for the MT3339?

Thank you

Fred
by ReM
Sun Jul 22, 2012 10:38 am
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

EOSBandi wrote:
ReM wrote:I rewrote MTK firmware (AXN1.51_2722_3329_384.1151100.5) and tried to use MTK binary protocol. But in flight I saw big position overshots. GPS effect was too big. Deviations has been increasing...
Before this I used the same GPS module, NMEA protocol, 5Hz. PH and RTH was working very well. PID was the same in both situations.
I tried to decrease PH P to 1, but overshots also were.


Use 5Hz, it seems that MTK is NOT capable of 10Hz with a Binary protocol...
Also try to switch off GPS_FILTERING


I tried 5Hz - no difference.
I tried return to NMEA 5Hz and very surprised. If I turn on PH, quad drifts about 3 meters in wind direction and very fast and strong tilt in right direction. Flight about 5-6 meters and strong tilt back.
In both ways - GPS filtering off.
I connect bluetooth and tried walking 30-40 meters around computer - I see correct coordinates in map (WinGUI).
by Gaijin
Fri Jul 20, 2012 8:04 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Hey Eos,

Have you cracked the UBlox configuration code yet, and when it functions do you still really need an Eeprom?

Surely if you set the module up at every boot there is no point?

N.B After flashing my MTK based module up with the new binary firmware it defaults to 1hz and I no longer seem to have any remaining set attempts in MiniGPS, does this matter or does it set the refresh rate automatically, I'm sure I had at least 8 remaining with the last firmware.
by jaames74
Thu Jul 19, 2012 4:31 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

EOSBandi wrote:
ReM wrote:I rewrote MTK firmware (AXN1.51_2722_3329_384.1151100.5) and tried to use MTK binary protocol. But in flight I saw big position overshots. GPS effect was too big. Deviations has been increasing...
Before this I used the same GPS module, NMEA protocol, 5Hz. PH and RTH was working very well. PID was the same in both situations.
I tried to decrease PH P to 1, but overshots also were.


Use 5Hz, it seems that MTK is NOT capable of 10Hz with a Binary protocol...
Also try to switch off GPS_FILTERING


ok, im a little confused... :?
i have the navigatron v2 what should i define in NAV's config.h??

#define MTK
OR
#define NMEA ??

BTW, what was the default setting with r33??

thanks
by EOSBandi
Wed Jul 18, 2012 10:05 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

ReM wrote:I rewrote MTK firmware (AXN1.51_2722_3329_384.1151100.5) and tried to use MTK binary protocol. But in flight I saw big position overshots. GPS effect was too big. Deviations has been increasing...
Before this I used the same GPS module, NMEA protocol, 5Hz. PH and RTH was working very well. PID was the same in both situations.
I tried to decrease PH P to 1, but overshots also were.


Use 5Hz, it seems that MTK is NOT capable of 10Hz with a Binary protocol...
Also try to switch off GPS_FILTERING
by ReM
Wed Jul 18, 2012 9:00 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

I rewrote MTK firmware (AXN1.51_2722_3329_384.1151100.5) and tried to use MTK binary protocol. But in flight I saw big position overshots. GPS effect was too big. Deviations has been increasing...
Before this I used the same GPS module, NMEA protocol, 5Hz. PH and RTH was working very well. PID was the same in both situations.
I tried to decrease PH P to 1, but overshots also were.
by EOSBandi
Sun Jul 15, 2012 10:58 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

Re: GPS integration

Tazzy wrote:EOSBandi if i use mtk protocol in i2c with my gps is it better to turn filtering off and if so both in i2c config and mwi config ?

If U use mtk binary, then you can switch off GPS_FILTERING, it's ok to comment out in multiwii config.h since it is a runtime setting for i2c-gps.
by EOSBandi
Fri Jul 13, 2012 3:43 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

I2C GPS NAV 2.1 release candidate

Hi Folks,

I updated the I2C_GPS_NAV code to prepare for the release of MultiWii 2.1.
What is new :
Single consolidated code, no need to patch twi libs or copy libraries to arduino libraries folder anymore
Works with arduino 1.0.1 release
Added Lead filter for GPS position forward estimation, this eliminates GPS lag
Support for Ublox and MTK binary protocols, eliminates the need for the GPS_FILTERING in the MultiWii code.
Automatic configuration for MTK Binary protocol (must use the AXN1.51_2722_3329_384.1151100.5 firmware which can be found in the updated FirmWare tools package)

ToDo for final 2.1 release
Automatic Ublox binary configuration
Updating documentation for gps functions

You can find the code here : http://code.google.com/p/i2c-gps-nav/downloads/list
by EOSBandi
Sun Jul 08, 2012 9:08 pm
Forum: Software development
Topic: GPS integration
Replies: 1724
Views: 1109996

MTK Binary parser

And here is the Binary parser for MTK based modules with DIYDrones custom firmware (AXN1.30_2389_3329_384.1151100.1_v16.bin)
Replace the

Code: Select all

 if (GPS_newFrame(SerialRead(GPS_SERIAL))) {

with

Code: Select all

 if (MTK_GPS_newFrame((uint8_t)SerialRead(GPS_SERIAL))) {


Also have to switch the gps module to binary mode since the diydrones firmware start at 38400baud and 1Hz update, so you have to change the speed and the baudrate too.

Code: Select all

  SerialOpen(GPS_SERIAL,38400);
    SerialPrint(GPS_SERIAL,"$PMTK220,200*2C\r\n");
    delay(400);
    SerialPrint(GPS_SERIAL,"$PMTK251,115200*1F\r\n")
    SerialPrint(GPS_SERIAL,"$PGCMD,16,0,0,0,0,0*6A\r\n");
    delay(500);
  SerialEnd(GPS_SERIAL);


Code: Select all


#if defined(MTK)
    struct diyd_mtk_msg {
        int32_t      latitude;
        int32_t      longitude;
        int32_t      altitude;
        int32_t      ground_speed;
        int32_t      ground_course;
        uint8_t      satellites;
        uint8_t      fix_type;
        uint32_t   utc_date;
        uint32_t   utc_time;
        uint16_t   hdop;
    };
// #pragma pack(pop)
    enum diyd_mtk_fix_type {
        FIX_NONE = 1,
        FIX_2D = 2,
        FIX_3D = 3
    };

    enum diyd_mtk_protocol_bytes {
        PREAMBLE1 = 0xd0,
        PREAMBLE2 = 0xdd,
    };

    // Packet checksum accumulators
    uint8_t    _ck_a;
    uint8_t    _ck_b;

    // State machine state
    uint8_t    _step;
    uint8_t      _payload_counter;

    // Time from UNIX Epoch offset
    long      _time_offset;
    bool      _offset_calculated;

    // Receive buffer
    union {
        diyd_mtk_msg   msg;
        uint8_t         bytes[];
    } _buffer;

inline long _swapl(const void *bytes)
{
    const uint8_t   *b = (const uint8_t *)bytes;
    union {
        long   v;
        uint8_t b[4];
    } u;

    u.b[0] = b[3];
    u.b[1] = b[2];
    u.b[2] = b[1];
    u.b[3] = b[0];

    return(u.v);
}

bool MTK_GPS_newFrame(uint8_t data)
{
       bool parsed = false;

restart:
        switch(_step) {

            // Message preamble, class, ID detection
            //
            // If we fail to match any of the expected bytes, we
            // reset the state machine and re-consider the failed
            // byte as the first byte of the preamble.  This
            // improves our chances of recovering from a mismatch
            // and makes it less likely that we will be fooled by
            // the preamble appearing as data in some other message.
            //
        case 0:
            if(PREAMBLE1 == data)
                _step++;
            break;
        case 1:
            if (PREAMBLE2 == data) {
                _step++;
                break;
            }
            _step = 0;
            goto restart;
        case 2:
            if (sizeof(_buffer) == data) {
                _step++;
                _ck_b = _ck_a = data;            // reset the checksum accumulators
                _payload_counter = 0;
            } else {
                _step = 0;                     // reset and wait for a message of the right class
                goto restart;
            }
            break;

            // Receive message data
            //
        case 3:
            _buffer.bytes[_payload_counter++] = data;
            _ck_b += (_ck_a += data);
            if (_payload_counter == sizeof(_buffer))
                _step++;
            break;

            // Checksum and message processing
            //
        case 4:
            _step++;
            if (_ck_a != data) {
                _step = 0;
            }
            break;
        case 5:
            _step = 0;
            if (_ck_b != data) {
                break;
            }

            f.GPS_FIX         = _buffer.msg.fix_type == FIX_3D;
            GPS_coord[LAT]      = _buffer.msg.latitude  * 10;   
            GPS_coord[LON]      = _buffer.msg.longitude * 10;   
            GPS_altitude      = _buffer.msg.altitude;
            GPS_speed                   = _buffer.msg.ground_speed;
            GPS_ground_course           = _buffer.msg.ground_course;
            GPS_numSat              = _buffer.msg.satellites;
            //GPS_hdop         = _buffer.msg.hdop;
            parsed = true;
            GPS_Present = 1;
        }
    return parsed;
}
#endif //MTK