GPS integration

[Termic1]

Cn06 have 25x25mm antena and it is very important

I'm currently using CN-06 GPS Receiver V1 (that does not have 25x25mm antenna) on a Multiwii CRIUS AIO Pro and works fine! V2 should work better...

Luciano

[janekx]

V2 have eeprom and big antenna

[Termic1]

V2 have eeprom and big antenna

You're right! I was just editing my message.

[copterrichie]

I pulled the trigger on Version II, thanks Guys.

[dROb]

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)

[scrat]

...

[dROb]

Everyone, who met the problem that i2c-gps blinks 1 second on - 1 second off, showing that no NMEA data is coming (while it is coming), please note - there is a bug in the software, which makes such blink signal happen when no-3dfix OR satellites < 5, instead of blinking when not receiving NMEA..

[klaudius666]

Hi.

Tested Multiwii althold and RTH la week for first time with all default settings. (v2.1 + CN06 V2 + I2C)

Worked very very well !

Many greetings to multiwii dev team for this feature ! and eosbandi too !

Best regards

[NikTheGreek]

Guys.. i'm a bit confused.
Which is the most stable of the new versions concerning GPS functions ?
I use I2C Gps in a quad .
Thank you in advance.

[diyboy]

Hi Guys.

If I don't went to reset or power down the board. can I relocat the GPS home post?

DIY Boy

[karsten j.]

Hi

Could anyboby post his PID Settings from POS, POSR and NAVR ?
I don´t get reliable settings that the copter stills more or less quiet in the air....
What version from Eosbandi do you use ? (Currently I have installed the R33)

greetz
Karsten

[Termic1]

Hi

Could anyboby post his PID Settings from POS, POSR and NAVR ?
I don´t get reliable settings that the copter stills more or less quiet in the air....
What version from Eosbandi do you use ? (Currently I have installed the R33)

greetz
Karsten

With r1129 I'm using default pid setting for POS, POSR and NAVR...and I'm happy with them.

[eidos]

Hello!
i have a mt3329 without backup battery with firmware AXN1.30_2389_3329_384.1151100.1_v16, my problem is that it always start at 1hz and 38400 baud rate and also if i set a different rate with minigps when i power cycle it returns to 1hz and 38400 baud rate.
The only thing that i need to do is to send this string:
PMTK300,200,0,0,0,0*2F\r\n$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n
but the method serial.write() returns an error: multiple definition of `__vector_25'
Could you help me?
Thank you!


EDIT: Solved thx to :

I've got a DiyDrones MTK2239
When I use MiniGPS_1.4.exe (with FTDI cable direct to the GPS) to change baud rate from 38400 to 115200 and update speed to 10Hz, it works fine, until power is removed.
All settings then revert to default 38400 baud and 1Hz update.

The work-around is to re-configure the GPS at every MultiWii startup.
In config, make a new #define for your defualt GPS baud rate. #define GPS_DEFAULT_BAUD 38400) (DiyDrones GPS is 38400)
and then also define the new GPS baudrate : #define GPS_BAUD 115200
At the end of gps.pde, make a serial function for the GPS,

Code: Select all

void GPS_Send_Char(const char *c) {
  while (*c) SerialWrite(GPS_SERIAL, *c++);
}

Then, in multiwii.pde, a the end of setup(), add the following code, to re-configure the GPS.......

Code: Select all

#if defined(GPS)  // This code sets the MediaTek GPS default 38400 baud to 115200 and set to send NEMA frames
    SerialOpen(GPS_SERIAL,GPS_DEFAULT_BAUD);    
    delay(10);
    GPS_Send_Char("$PMTK251,115200*1F\r\n");      //set baudrate 115200
    delay(10);
    SerialOpen(GPS_SERIAL,GPS_BAUD);   // open the serial port at the new speed 
    delay(10);
    GPS_Send_Char("$PMTK314,1,1,1,1,1,5,1,1,1,1,1,1,0,1,1,1,1*2C\r\n");  //set to NMEA output 
    delay(10);
    GPS_Send_Char("$PMTK220,100*2F\r\n");         //Will set the GPS to output serial at 10hz 
    delay(10);
  #endif

Sometimes my GPS takes over 3 minutes to get a fix, other times, 35 seconds???

[dramida]

I want to share a good finding about GPS pos hold PID parameters. Multiwii inherited the PosHold algorithm from ArduCopter through EosBandi implementation. We took the values from AC2 and ported "as is" to MWC. We saw the setings "works" and we let them more or less unchanged.
Today i had a windy day, with gusts of wind up to 50 km/h. I played alot with gps pos hold and i realised that raising the PosHold Rate P= 8 , I=0.3 (i let D term default 0.045) produced a way better attitude in front of wind, more stiffness added to position hold.
Tests were made on a 450mm quad DJI clone frame with A2830 850kv and 9 inch props.

The tests are not over yet and this could be only the starting point of a PH atitude similar with top brands flight controllers.
More parameters to play but i need windy day like this one

[copterrichie]

I have stated many times, that PID settings are unique as each copter build. One settings does not fit all.

[dramida]

You are right about different settings for different copters (Power/weight ratio regarding Pos Hold) but default P is 2 and i found that a value four times greater is far better for a precise position hold and a reduced wobble when yaw-ing.

[vpb]

thank you dramida! will try to tweak gps pos hold PID, it's been in my to-do list for a long time . With default PID, and alt-hold activated, it moves around 2-3m. Can you share a clip?

[novian89]

newbie want to ask about the implementation of the waypoint at 2.1 multiwii

The revamped waypointnya figures for the firmware 2.1 or nav module i2c?

define whether the correct number on it that changed?
What data should I enter?

#define I2C_GPS_WP0                                 63   //Waypoint 0 used for RTH location (R/W)
#define I2C_GPS_WP1                     74
#define I2C_GPS_WP2                     85
#define I2C_GPS_WP3                     96
#define I2C_GPS_WP4                     107
#define I2C_GPS_WP5                     118
#define I2C_GPS_WP6                     129
#define I2C_GPS_WP7                     140
#define I2C_GPS_WP8                     151
#define I2C_GPS_WP9                     162
#define I2C_GPS_WP10                     173
#define I2C_GPS_WP11                     184
#define I2C_GPS_WP12                     195
#define I2C_GPS_WP13                     206
#define I2C_GPS_WP14                     217
#define I2C_GPS_WP15                     228

, can give an example of what I need to do to activate the waypoint that will appear in multiwii gui Mision plan and I was able to activate

sorry my english screwed LOL

Thank you very much

[dynai]

hi,

@eidos: think your missing a few lines in the config.h

Code: Select all

    #define GPS
    #define GPS_SERIAL 2 // should be 2 for flyduino v2. It's the serial port number on arduino MEGA
    #define GPS_BAUD   115200
    //#define GPS_BAUD   9600
    #define GPS_DEFAULT_BAUD 38400 // default speed of the gps after power-

up

as posted back in January (viewtopic.php?f=8&t=649&p=7459#p7459)

kind regards Chris

[p25o1]

hi everyone , just want to confirm if gps hold is working in r1240, since i'm not able to make it work in angle or horizon mode.

[scrat]

One question: I have u-Blox CN-06 GPS Receiver V2.0 from rctimer. Do I still need to add 10kohm resistor in serial to Rx line? I'm supplying gps module with 5v power from AIO Pro.

[Termic1]

One question: I have u-Blox CN-06 GPS Receiver V2.0 from rctimer. Do I still need to add 10kohm resistor in serial to Rx line? I'm supplying gps module with 5v power from AIO Pro.

I'm using it without any resistor.

[scrat]

Thank for answer Termic1.

[vpb]

hi everyone , just want to confirm if gps hold is working in r1240, since i'm not able to make it work in angle or horizon mode.

sure it will work

[Vaattari]

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

[EOSBandi]

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

[copterrichie]

Glad to see ya about EOSBandi.

[EOSBandi]

Glad to see ya about EOSBandi.

Thanks,
Still have limited time, but will hang around as much as I can

[Crashpilot1000]

@EOSBandi:
Thank you very much for doing such a terrific job in porting the GPS code !!! That is def. way beyond my coding capabilities!! I had quiet a problem with the NMEA parsing of my MTK module (at 10 and 5 Hz). I solved it the "dumb" way and set everything to uint32 except for the output of "GPS_coord_to_degrees" because GPS_read expects a sign. Now my copter does really well on nmea!
Please have a look at this codechange, perhaps it is of some use

Code: Select all

#define DIGIT_TO_VAL(_x)   (_x - '0')
int32_t GPS_coord_to_degrees(char* s)
{
   char *p, *q;
   uint32_t deg = 0, minute = 0;
        uint32_t frac_min = 0;                         //   unsigned int frac_min = 0;
        uint8_t i;

   // scan for decimal point or end of field
   for (p = s; isdigit(*p); p++)
      ;
   q = s;

   // convert degrees
   while ((p - q) > 2) {
      if (deg)
         deg *= 10;
      deg += DIGIT_TO_VAL(*q++);
   }
   // convert minutes
   while (p > q) {
      if (minute)
         minute *= 10;
      minute += DIGIT_TO_VAL(*q++);
   }
   // convert fractional minutes
   // expect up to four digits, result is in
   // ten-thousandths of a minute
   if (*p == '.') {
      q = p + 1;
      for (i = 0; i < 4; i++) {
         frac_min *= 10;
         if (isdigit(*q))
            frac_min += *q++ - '0';
      }
   }
      deg = deg * 10000000;
      minute = minute * 1000000;
      frac_min = frac_min*100;
      minute = (minute + frac_min)/6;
      deg = deg + minute;
      return deg;                                           //   return deg * 10000000UL + (minute * 1000000UL + frac_min*100UL) / 6;
}

So long

Kraut Rob

[EOSBandi]

@EOSBandi:
Thank you very much for doing such a terrific job in porting the GPS code !!! That is def. way beyond my coding capabilities!! I had quiet a problem with the NMEA parsing of my MTK module (at 10 and 5 Hz). I solved it the "dumb" way and set everything to uint32 except for the output of "GPS_coord_to_degrees" because GPS_read expects a sign. Now my copter does really well on nmea!
Please have a look at this codechange, perhaps it is of some use

Code: Select all

#define DIGIT_TO_VAL(_x)   (_x - '0')
int32_t GPS_coord_to_degrees(char* s)
{
   char *p, *q;
   uint32_t deg = 0, minute = 0;
        uint32_t frac_min = 0;                         //   unsigned int frac_min = 0;
        uint8_t i;

   // scan for decimal point or end of field
   for (p = s; isdigit(*p); p++)
      ;
   q = s;

   // convert degrees
   while ((p - q) > 2) {
      if (deg)
         deg *= 10;
      deg += DIGIT_TO_VAL(*q++);
   }
   // convert minutes
   while (p > q) {
      if (minute)
         minute *= 10;
      minute += DIGIT_TO_VAL(*q++);
   }
   // convert fractional minutes
   // expect up to four digits, result is in
   // ten-thousandths of a minute
   if (*p == '.') {
      q = p + 1;
      for (i = 0; i < 4; i++) {
         frac_min *= 10;
         if (isdigit(*q))
            frac_min += *q++ - '0';
      }
   }
      deg = deg * 10000000;
      minute = minute * 1000000;
      frac_min = frac_min*100;
      minute = (minute + frac_min)/6;
      deg = deg + minute;
      return deg;                                           //   return deg * 10000000UL + (minute * 1000000UL + frac_min*100UL) / 6;
}

So long

Kraut Rob

Hi,
What was your exact problem? The rewrite what you did looks identical to the original, but makes code larger and slower....
(What version of arduino compiller did you used ?)
EOS

[flyrobot]

Hi Andras,

Im very glad to see you. The last try with last fw mwi im happy with the stability espesially altitude hold and loiter. Is it the right time for way point?

Thanks,

John

[Crashpilot1000]

@EOSBandi:

I used Arduino 1.0.1. I had sudden twitches out of nowhere so i found the uint_32 error here: http://code.google.com/p/arducopter/iss ... 0&sort=-id
From my understaning it isn't fixed in our current code. Just changing unsigned int frac_min = 0; to uint32_t frac_min = 0; helped a lot. But i did my own moving average "for idiots" using 64Bit and some new problems occured i couldn't explain from my simple code. The cure for this was the solution above. I am no programmer but i think there is a bug in current NMEA readout.

So long
Kraut Rob

[EOSBandi]

@EOSBandi:

I used Arduino 1.0.1. I had sudden twitches out of nowhere so i found the uint_32 error here: http://code.google.com/p/arducopter/iss ... 0&sort=-id
From my understaning it isn't fixed in our current code. Just changing unsigned int frac_min = 0; to uint32_t frac_min = 0; helped a lot. But i did my own moving average "for idiots" using 64Bit and some new problems occured i couldn't explain from my simple code. The cure for this was the solution above. I am no programmer but i think there is a bug in current NMEA readout.

So long
Kraut Rob

Well, there is one significant difference compared to the AP code. in MultiWii we parse only four digits for the fraction minutes (Since to almost all gps modules returns only four digits of fractional minutes in a format DDMM.MMMM. AP code assumes five digits after the decimal point.

Here is the code from AP

Code: Select all

// convert fractional minutes
// expect up to four digits, result is in
// ten-thousandths of a minute    
 if (*p == '.') {
         q = p + 1;
         for (int16_t i = 0; i < 5; i++) {
             frac_min = (int32_t)(frac_min * 10);
             if (isdigit(*q))
                 frac_min += *q++ - '0';
         }     
}     
ret = (int32_t)deg * (int32_t)1000000UL + (int32_t)((min * 100000UL + frac_min) / 6UL);     
return ret;
 

And this is the code in MultiWii

Code: Select all

  // convert fractional minutes
  // expect up to four digits, result is in
  // ten-thousandths of a minute
  if (*p == '.') {
    q = p + 1;
    for (i = 0; i < 4; i++) {
      frac_min *= 10;
      if (isdigit(*q))
        frac_min += *q++ - '0';
    }
  }
  return deg * 10000000UL + (min * 1000000UL + frac_min*100UL) / 6;

In MultiWii it is not possible to get a larger value in frac_min than 9999 which fits into an unsigned int (uint_16t).
In AP you can easily get a value larger than 65536. So frac_min have to be uint_32t.

So I still does not see a problem here with MultiWii code

Btw, could you share the coordinates where you experienced these glitches ?

EOSBandi

[Crashpilot1000]

Thank you very much for looking into this!!!
I send you the GPS coordinates via PN....

So long

Kraut Rob

[Vaattari]

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

[NikTheGreek]

@Vaattari

Which version of MW GUI you are using ?
Where i can find ?

[Vaattari]

@Vaattari

Which version of MW GUI you are using ?
Where i can find ?

Thanks to EOSBandi for this as well!
You can find the gui here: http://code.google.com/p/mw-wingui/downloads/list

Latest dev did not like WinGUI in my laptop. I can not get it working more than few minutes before the gui GPS side halts. With MW2.1 no probs

[Crashpilot1000]

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

[mbrak]

hi robert

would this file AXN1.51_2722_3329_384.1151100.5.bin also work with the flyduino gps (FMP04) ?

thx kraut michael

[Crashpilot1000]

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

[Crashpilot1000]

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

[Crashpilot1000]

BTW: I omitted the Payload Byte for a reason. It is always $20!! And that is wrong, because with no sattelites a much shorter sentence is send!

Example sequence when no sats:

Code: Select all

D0DD            Dataset
20                Wrong Payloadbyte
84 35 01 C4
EA EB 8A 01
0F 27 34 AD

D0DD           Next Dataset
20               Wrong Payloadbyte
84 35 01 C4 
EA 2B AA 01 
0F 27 94 CD

[Vaattari]

@Crashpilot1000

What GPS & FW version are you using?
I have MTK 1.6 from here: http://code.google.com/p/ardupilot/wiki/MediaTek
I do not think MTK FW 1.6 is supporting 57600 with bin mode, thus I'm using 115200 with 10Hz. With 57600 the GPS does not respond here
I could not see any benefit of 5Hz and I also disabled GPS filter.

How can I easily verify, if and how much, there are RS232 errors?

I'm happy to try the fix you found, when available in dev.

Thanks.
Janne

[Crashpilot1000]

@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

[wilco1967]

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...

[Crashpilot1000]

@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

[EOSBandi]

Hi Rob,
Can you check with MinGPS that you successfully upgraded the firmware on your gps ? I just made a quick test with a PA6B module and AXN 1.51 2722. I got a normal $20 long response without satelite lock too.

Code: Select all

D0DD20000000000000000084350000000000000000000001013C3D0100AE512C0C0F27C2A1
D0DD20000000000000000084350000000000000000000001013C3D010096552C0C0F27AE25
D0DD20000000000000000084350000000000000000000001013C3D01007E592C0C0F279AA9
D0DD20000000000000000084350000000000000000000001013C3D0100665D2C0C0F27862D
D0DD20000000000000000084350000000000000000000001013C3D01004E612C0C0F2772B1
D0DD20000000000000000084350000000000000000000001013C3D010036652C0C0F275E35
D0DD20000000000000000084350000000000000000000001013C3D01001E692C0C0F274AB9
D0DD20000000000000000084350000000000000000000001013C3D0100066D2C0C0F27363D
D0DD20000000000000000084350000000000000000000001013C3D0100EE702C0C0F2721BC
D0DD20000000000000000084350000000000000000000001013C3D0100D6742C0C0F270D40
D0DD20000000000000000084350000000000000000000001013C3D0100BE782C0C0F27F9C4
D0DD20000000000000000084350000000000000000000001013C3D0100A67C2C0C0F27E548

This is consistent with the current parser and documentation.
What module are you using ?

EOS

[EOSBandi]

@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....

[Crashpilot1000]

@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

[Crashpilot1000]

@EOS Bandi:
Do you have any documentation for the AXN1.51_2722_3329_384.1151100.5.bin? I can't find it. It would be interesting to know what is turned on after switching to binary mode by default. From what i see here SBAS and 10HZ in binary is no-go: viewtopic.php?f=6&t=1881&start=10#p19325.

So long
Kraut Rob