MultiWii

Posted: **Sun Aug 26, 2012 1:05 pm**

Is it released for Pro mini? Is there something I can do for Pro mini?

Posted: **Sun Aug 26, 2012 8:18 pm**

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?

Posted: **Mon Aug 27, 2012 9:53 am**

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.

Posted: **Mon Aug 27, 2012 8:31 pm**

Thanks for that. It looked like it was a step in the right direction so I added the code below (by grace of eosbandi and kristaps_r) to the gps.ino after the "#if defined (TINY_GPS)" section. I then added "#define MT3339" to config.h in the GPS section and added a few lines in the multiwii code after "#if defined(GPS_SERIAL)" to init the MT339:
"
#if defined(MT339)
MT3339_init();
delay(200);
#endif
"
It doesn't get in the way of the code but it doesn't initalise the MT3339 either. I feel as if I'm really close. Please help, I'm losing my hair!!!

Code: Select all

#if defined(MT3339)

  #define MTK_SET_SPEED  "$PMTK251,115200*1F\r\n"
  #define MTK_SET_BINARY "$PMTK314,0,1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n"  // not actually for binary but it was easier to reuse the existing variables by eosbandi
  #define MTK_SET_5HZ    "$PMTK220,100*2F\r\n"  //actually it's for 10Hz
  #define MTK_SET_10HZ   "$PMTK300,100,0,0,0,0*2C\r\n" //also for 10Hz, not sure which is needed, but either one should work
  
  void SerialWriteBuffer(uint8_t port, uint8_t *buffer, uint8_t size)
  {
    uint8_t i;
    uint8_t *ptr;  
    ptr = buffer;
    for (i=0;i<size;i++) {
      SerialWrite(port,*ptr);
      ptr++;
    }  
  }
  void MT339_init(void)
  {
    SerialOpen(GPS_SERIAL,38400);
    delay(1500);
    SerialWriteBuffer(GPS_SERIAL, (uint8_t *)MTK_SET_SPEED, sizeof(MTK_SET_SPEED)-1);
    delay(300);
    SerialEnd(GPS_SERIAL);
    SerialOpen(GPS_SERIAL,57600);
    delay(1500);
    SerialWriteBuffer(GPS_SERIAL, (uint8_t *)MTK_SET_SPEED, sizeof(MTK_SET_SPEED)-1);
    delay(300);
    SerialEnd(GPS_SERIAL);
    SerialOpen(GPS_SERIAL,115200);
    SerialWriteBuffer(GPS_SERIAL, (uint8_t *)MTK_SET_BINARY, sizeof(MTK_SET_BINARY)-1);
    delay(1000);
    SerialWriteBuffer(GPS_SERIAL, (uint8_t *)MTK_SET_5HZ, sizeof(MTK_SET_5HZ)-1);  //actually it's still for 10Hz
    delay(300);
    SerialWriteBuffer(GPS_SERIAL, (uint8_t *)MTK_SET_10HZ, sizeof(MTK_SET_10HZ)-1);
    delay(300);
    SerialEnd(GPS_SERIAL);  
  }
#endif

Posted: **Mon Aug 27, 2012 9:48 pm**

Hi guys, here my mod about the setup of serial GPS MTK chipset 3329 with standard commands.
This means that MWii sketch will autodetect the serial default baud rate and then will reconfigure the GPS unit at 115200bps, 10Hz, with GGA+RMC NMEA strings (minimum requested).
This was born thanks to an idea of Eosbandi in this thread viewtopic.php?f=8&t=2166.

1) download the eosbandi gps.zip file and add all others eosbandi indication.
2) Search this part of code and add the following part to the new gps.ino file sketch.

Code: Select all

.....
......
// This code is used for parsing NMEA data
#if defined(GPS_SERIAL)

#if !defined(UBLOX)

/* Alex optimization 
  The latitude or longitude is coded this way in NMEA frames
 .....
  This function converts this format in a unique unsigned long where 1 degree = 10 000 000

  EOS increased the precision here, even if we think that the gps is not precise enough, with 10e5 precision it has 76cm resolution
  with 10e7 it's around 1 cm now. Increasing it further is irrelevant, since even 1cm resolution is unrealistic, however increased 
  resolution also increased precision of nav calculations
*/
/////////////// NEB (Carlonb) from Eosbandi idea
// Autosetup for serial GPS MTK 3329 chipset
// The strange think is that the new serial speed update will be accepted only if the GSP chiset is in default state at 9600 bps ???!!!
// My GPS will go back in default setttings after 2 days unpowered.
// With this, if GPS is in default state, OK, will be updated with new param, if not, no problem, will not accept these commands and nothig happens, 
// simply means that already has these new parameters (115200bps, 10Hz, GGA and RMC NMEA strings).
void NMEA_MTK_NEB_init(void)  // NEB
{
   const unsigned long baudrates[5] = {9600U, 19200U, 38400U, 57600U, 115200U};
   //const unsigned long baudrates[4] = {9600U, 19200U, 38400U, 57600U};
   
   //#define NMEA_MTK_RESET  "$PMTK104*37\r\n"  // Reset to factory default
   #define NMEA_MTK_STRING  "$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n"  // Command for only GGA & RMC NMEA strings 
  
   #define NMEA_MTK_SET_SPEED  "$PMTK251,115200*1F\r\n"  // 115200 bps
   //#define NMEA_MTK_SET_SPEED  "$PMTK251,57600*2C\r\n"  // 57600 bps
   //#define NMEA_MTK_SET_SPEED  "$PMTK251,9600*17\r\n"  // 9600 bps
   
   #define NMEA_MTK_SET_HZ    "$PMTK300,100,0,0,0,0*2C\r\n"  // 10Hz   
   //#define NMEA_MTK_SET_HZ    "$PMTK300,200,0,0,0,0*2F\r\n"  // 5Hz
   //#define NMEA_MTK_SET_HZ    "$PMTK300,1000,0,0,0,0*1C\r\n"  // 1Hz
   
  for (uint8_t i=0; i<6; i++) {            // Carlonb from idea of EOSBANDI (autosearch of default baud rate)
      SerialOpen(GPS_SERIAL,baudrates[i]);
      delay(200);
      SerialWriteBuffer(GPS_SERIAL, (uint8_t *)NMEA_MTK_SET_SPEED, sizeof(NMEA_MTK_SET_SPEED)-1);  // NEB set GPS serial speed
      delay(200);
      SerialEnd(GPS_SERIAL);
      delay(200);
      }
      
  SerialOpen(GPS_SERIAL,GPS_BAUD);  // NEB changed 57600 with GPS_BAUD
  delay(200);  
  SerialWriteBuffer(GPS_SERIAL, (uint8_t *)NMEA_MTK_SET_HZ, sizeof(NMEA_MTK_SET_HZ)-1);    // NEB set GPS refresh rate (Hz)
  delay(200);
  SerialWriteBuffer(GPS_SERIAL, (uint8_t *)NMEA_MTK_STRING, sizeof(NMEA_MTK_STRING)-1);    // NEB set GPS for GGA & RMC NMEA strings only
  delay(200);
  SerialEnd(GPS_SERIAL);
  delay(100);
}

void SerialWriteBuffer(uint8_t port, uint8_t *buffer, uint8_t size)
{
  uint8_t i;
  uint8_t *ptr;
  
  ptr = buffer;
  
  for (i=0;i<size;i++) {
    SerialWrite(port,*ptr);
    ptr++;
  }
}
/////////////// NEB mod end

#define DIGIT_TO_VAL(_x)   (_x - '0')
....

3) Search this part of code and add the following part to the MultiWii2_1.ino file sketch.

Code: Select all

  #if defined(GPS_SERIAL)
 
 ///////////// EOSBANDI
  #if defined(UBLOX)
   UBLOX_init();
   delay(200);
  #endif

  #if defined(MTK)
     MTK_init();
     delay(200);
  #endif
  
  #if defined(NMEA)    // NEB added for NMEA MTK setup
     NMEA_MTK_NEB_init();
     delay(200);
  #endif 
 ///////////// EOSBANDI  
  
    SerialOpen(GPS_SERIAL,GPS_BAUD); 
....
....

4) ) Search this part of code and add the following part to the config.h file sketch.

Code: Select all

    #define GPS_SERIAL 2   // should be 2 for flyduino v2. It's the serial port number on arduino MEGA
    #define GPS_BAUD  115200  // 57600
       
    #define NMEA
    //#define UBLOX  // Eosbandi
    //#define MTK    // Eosbandi
....
....

That's all, please try and let me know, but remember (and I do not understand why) you need that your GPS serial unit (MTK 3329) must be at default setting, if not seems do not accept the new serial speed. For this is enough that you keep unpowered the unit for a couple of days.
Bye Carlo.

Posted: **Tue Aug 28, 2012 9:21 am**

AH, that looks pretty similar to what I was doing. I'll check and see if it works for the MT3339 as well. Thanks!

Posted: **Tue Aug 28, 2012 6:43 pm**

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

Posted: **Tue Aug 28, 2012 6:58 pm**

Position Hold should be improved with accelerometer data for short term perturbances. Before GPS knows that the wind blows away the copter, accelerometer sensor already knows that. This strategy is used by DJI Naza. And BTW, The gps FMP04 mentioned above can be flashed with MTK3329 10 hz firmware ( i have one this way)

Posted: **Tue Aug 28, 2012 7:05 pm**

Somehow I managed to miss out a 3 in the 3339, it works as is (and checks 38440 and 57600 as mine has defaulted to both of those in the past). Aren't typos a blessing :oops:

Tizzy wrote:Thanks for that. It looked like it was a step in the right direction so I added the code below (by grace of eosbandi and kristaps_r) to the gps.ino after the "#if defined (TINY_GPS)" section. I then added "#define MT3339" to config.h in the GPS section and added a few lines in the multiwii code after "#if defined(GPS_SERIAL)" to init the MT339:
"
#if defined(MT339)
MT3339_init();
delay(200);
#endif
"
It doesn't get in the way of the code but it doesn't initalise the MT3339 either. I feel as if I'm really close. Please help, I'm losing my hair!!!

Code: Select all

#if defined(MT3339)

  #define MTK_SET_SPEED  "$PMTK251,115200*1F\r\n"
  #define MTK_SET_BINARY "$PMTK314,0,1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n"  // not actually for binary but it was easier to reuse the existing variables by eosbandi
  #define MTK_SET_5HZ    "$PMTK220,100*2F\r\n"  //actually it's for 10Hz
  #define MTK_SET_10HZ   "$PMTK300,100,0,0,0,0*2C\r\n" //also for 10Hz, not sure which is needed, but either one should work
  
  void SerialWriteBuffer(uint8_t port, uint8_t *buffer, uint8_t size)
  {
    uint8_t i;
    uint8_t *ptr;  
    ptr = buffer;
    for (i=0;i<size;i++) {
      SerialWrite(port,*ptr);
      ptr++;
    }  
  }
  void MT339_init(void)
  {
    SerialOpen(GPS_SERIAL,38400);
    delay(1500);
    SerialWriteBuffer(GPS_SERIAL, (uint8_t *)MTK_SET_SPEED, sizeof(MTK_SET_SPEED)-1);
    delay(300);
    SerialEnd(GPS_SERIAL);
    SerialOpen(GPS_SERIAL,57600);
    delay(1500);
    SerialWriteBuffer(GPS_SERIAL, (uint8_t *)MTK_SET_SPEED, sizeof(MTK_SET_SPEED)-1);
    delay(300);
    SerialEnd(GPS_SERIAL);
    SerialOpen(GPS_SERIAL,115200);
    SerialWriteBuffer(GPS_SERIAL, (uint8_t *)MTK_SET_BINARY, sizeof(MTK_SET_BINARY)-1);
    delay(1000);
    SerialWriteBuffer(GPS_SERIAL, (uint8_t *)MTK_SET_5HZ, sizeof(MTK_SET_5HZ)-1);  //actually it's still for 10Hz
    delay(300);
    SerialWriteBuffer(GPS_SERIAL, (uint8_t *)MTK_SET_10HZ, sizeof(MTK_SET_10HZ)-1);
    delay(300);
    SerialEnd(GPS_SERIAL);  
  }
#endif

Posted: **Tue Aug 28, 2012 8:04 pm**

dramida wrote: And BTW, The gps FMP04 mentioned above can be flashed with MTK3329 10 hz firmware ( i have one this way)

Hi, Just to make sure you mean the custom binary protocol firmware?

-Markus

Posted: **Wed Aug 29, 2012 12:41 pm**

i was using NMEA protocol . But flashing with binary firmware works also.

Posted: **Sat Sep 01, 2012 3:47 am**

finally i got everything setup and fly it, even mwc with everything are stock pids gps hold work as it intended to be not sure what version of the i2cs nav on the navigatron maybe r33 cant seem to get it updated to the latest not sure why will need to contact flytron for that

later tomorrow gonna do some pid tuning forgot to bring my serial bluetooth today hopefully can getvsome video up too tomorrow! kuddos to the dev for making this happen

Posted: **Sat Sep 01, 2012 7:05 pm**

pm1 wrote:
flyman777 wrote:I tried the Poshold with genuine i2c_gps_nav rc2 from EOS but my copter speeded up after a few seconds forwards and backwards and begin to tilt so I must switch off the gps for avoiding a crash.

That's exactly the situation I met. Therefore I had a deeper look into the code. The lines I did put in limit the possible speed in PH. It didn't show the result I expected. The I saw, that D term was not related to change of speed, but to change of distance. I made D term to zero, then it worked as expected by me.

If you are using i2c GPS, make additionally following modification on the fc (GPS.ino):

void GPS_NewData() {
uint8_t axis;
#if defined(I2C_GPS)
static uint8_t GPS_pids_initialized;
static uint8_t _i2c_gps_status;

//Do not use i2c_writereg, since writing a register does not work if an i2c_stop command is issued at the end
...
...
if (_i2c_gps_status & I2C_GPS_STATUS_NEW_DATA) { //Check about new data
if (GPS_update) { GPS_update = 0;} else { GPS_update = 1;} //Fancy flash on GUI
if (!GPS_pids_initialized) {
GPS_set_pids();
GPS_pids_initialized = 1;
}

Without this modification, you may always use the default pids hard coded in the i2c board. Then try the pids from my post as a start.

Hello
I took over the setting for the Drotek GPS and tested. Works better as Mikrokopter, thanks for the work.

Posted: **Sat Sep 01, 2012 8:25 pm**

great work!

Posted: **Sun Sep 02, 2012 12:41 pm**

Hi,

can anyone explain what are the correct modification on the CODE to have a better Drotek I2CGPS (MT3339 FW AXN2.10_5156_3339_1152.1101000.10) ?

Thanks

Video for explain:

https://vimeo.com/48312799

Gps speed wrong and coordinates when GPS make the fix oscillate

Gpd speed in multiwii gui 2.1

http://www.youtube.com/watch?v=xj_zZj5j-aA&feature=plcp

Gps Tool 1.7.1

http://www.youtube.com/watch?v=FNRbxnYBTzM&feature=plcp

SOLVED thanks to CarlonB

After

Code: Select all

//************* GPGSA FRAME parsing
                   case GPRMC_FRAME:
                     switch(param)
                     {
                       [b][color=#FF0000]case 7: i2c_dataset.ground_speed = (atof(string)*0.5144444)*100;[/color][/b]      //convert to m/s*100

Now

Code: Select all

//************* GPGSA FRAME parsing
                   case GPRMC_FRAME:
                     switch(param)
                     {
                       [b][color=#FF0000]case 7: i2c_dataset.ground_speed = (atof(string)/0.5144444)*1000*100/3600;[/color][/b]      //convert to m/s*100

Now works

Posted: **Sun Sep 02, 2012 7:51 pm**

http://vimeo.com/48696970

Posted: **Wed Sep 05, 2012 10:39 pm**

Finaly I got a gps. It's Skylab skm53 (http://store.fut-electronics.com/Products/PDF/SkyNav_SKM53_Datasheet.pdf). it is based on MKT 3329. It works correctly, well almost. It works when I flash AXN1.30_2389_3329_384.1151100.1_v16 and MTK3329_A1.5E_20110118_10Hz_115200 without any problems. But when I want to switch to binary using AXN1.51_2722_3329_384.1151100.5 I get $PGACK,003,-1*71.
I have found this in the WEB:

Some firmware versions (e.g. most AXN1.50) have a hardware mismatch protection function. When a user flashes a firmware intended for a module (e.g. PA6B) into another one (e.g. PA6C), then a sentence like the following

So it means that I can't switch to binary mode ?
Maybe there is other firmware ?

Bart

Posted: **Thu Sep 06, 2012 5:21 pm**

Hi,

this is the version of my gps.
How can I check if is lastest version and support binary protocol ?

Thanks

Posted: **Thu Sep 06, 2012 6:48 pm**

EOSBandi wrote:Ublox neo modules are not reflashable, but they not need it at all....
You need the u-center software to config the u-blox module.
Here is a settings file for NMEA. You can download it to your module with the tools->GPS configuration menu...
Once the binary protocol parser is committed to Multiwii i'll update the i2c sw too.

One more issue : I found that the onboard battery of these ebay ublox modules are hardly last more than a couple of days... and since the neo-6M does not have flash onboard, then it forgets the settings. So it's worth do buy an i2c EEPROM chip (about .5usd a piece) (Microchip 24AA32A, or ST MC24C32-R) and connect it to the i2c port of the gps (some boards already has i2c port connection, or you can solder it directly to the module). (I'll update the GPS docs about ublox, including the external i2c storage).

I there is interest, i'll make breakout boards with i2c eeprom chips.

Trying to update that file posted on my gps with ucenter but am getting the error that the version I am about to download does not correspond to the version of the gps receiver....on GPS receiver I have 7.03

Posted: **Fri Sep 07, 2012 2:42 am**

pm1 wrote:
flyman777 wrote:I tried the Poshold with genuine i2c_gps_nav rc2 from EOS but my copter speeded up after a few seconds forwards and backwards and begin to tilt so I must switch off the gps for avoiding a crash.

That's exactly the situation I met. Therefore I had a deeper look into the code. The lines I did put in limit the possible speed in PH. It didn't show the result I expected. The I saw, that D term was not related to change of speed, but to change of distance. I made D term to zero, then it worked as expected .

Finally got a chance to give this a good go, got it working pretty well using (PM1) modified code a few posts back. Thanks! Heres a quick vid.http://m.youtube.com/watch?v=CcXDYszoHJ8

Posted: **Fri Sep 07, 2012 9:41 pm**

Is there any way of getting what the GPS module settings are while the GUI is running, it would be nice to know the speed and baud rate are as expected.

Posted: **Sat Sep 08, 2012 3:56 pm**

bill516 wrote:Is there any way of getting what the GPS module settings are while the GUI is running, it would be nice to know the speed and baud rate are as expected.

I think nothing can do it.

Posted: **Sat Sep 08, 2012 4:00 pm**

Anybody can tell me how to configure the UBX module, then I can use the binary parser in I2C-GPS?

Posted: **Mon Sep 10, 2012 2:46 pm**

EmmeDi8 wrote:Hi,

this is the version of my gps.
How can I check if is lastest version and support binary protocol ?

Thanks

Is you r GPS MKT 3329 or MKT 3339?

Posted: **Mon Sep 10, 2012 10:30 pm**

flyboy_____ wrote:
EmmeDi8 wrote:Hi,

this is the version of my gps.
How can I check if is lastest version and support binary protocol ?

Thanks

Is you r GPS MKT 3329 or MKT 3339?

My GPS is MKT 3339. I have read a lot of post and seems that only NMEA I can use.
But If 3339 is evolution of 3329 and binary is better than NMEA maybe I confused some info.
However Saturday I have tested GPS and work fine. With bluetooth and Android app I have noticed
the "distance to home" and "gps speed" have significant delay. I have made a test walking with copter
in my hand (at min throttle of course) and look this two parameter. Delay is about 5/6 second.
Maybe this is the reason of my difficulty to find right param of gps PID.
Next week I'll make a video and post to the forum.

Thanks.

Posted: **Wed Sep 12, 2012 12:00 pm**

is anyone else having problems with the i2c gps modules from RCTimer? I have blown 2 now. they go dead and heat up. it seems to happen after crashing. the first one lasted about 3 weeks and the second one lasted about 3 flights.

Posted: **Fri Sep 14, 2012 7:19 am**

I'm having problems with latest trunk shared version, I have an MTK3329, and doesn't work, but worked with EOSbandi's GPS.ino in binary mode and 115200 @10Hz

Posted: **Fri Sep 14, 2012 2:10 pm**

Hi - Just got a recent build Navigatron and recent Quadrino - looks like it working great but wondering about a slight twitch when gps hold or rth is on.
Looking for some knobs to tweak - I do have gps filtering ON, even tho a comment in the code says:

* With MTK and UBLOX you don't have to use GPS_FILTERING in multiwii code !!!

Here's a video of position hold with the little jerks: http://youtu.be/6gQb0R9Nsfw

RTH works great! I'm looking forward to playing with that this weekend in a large field :lol:

However, with all the twitching.

Posted: **Sun Sep 16, 2012 1:24 am**

Ublox GPS protocol dosen't work anymore on MWC21 R1100 with some MPU boards.

Tested on two different Crius AIO Mega boards with three different ublox GPS receivers and serial ppm. The yellow led is blinking, the GUI shows GPS activity BUT THE SAT NUMBER STAYS 220, SPEED SWINGS AND BAD COORDINATES ARE DISPLAYED.
Strange is that same software worked on a mega controller with BMP085- ITG3200-BMA180 and HMC83xx (Paralel RC channel imput). I even uploaded the same software that worked on AIO board and the GPS dosen't work anymore.

Posted: **Sun Sep 16, 2012 1:43 am**

EOSBandi wrote:The basic rule is that the antenna gain increases with the size (and volume). Antenna manufacturers are giving the antenna gain towards the zenith, but it is more important that how sensitive the antenna towards the horizon and this is where the size really matters. (For example a 25x25mm antenna and a 35x35mm antenna booth have 2dB gain at Zenith, but at 10° elevation the 25x25 antenna has only -4dB gain while the 35x35 antenna has 1.5dB.

Hello Mr. Bandi, we miss you.

Posted: **Sun Sep 16, 2012 2:04 pm**

Hello i also have some problem with binary protocol i have a fmp04 gps (Mtk3329) and have flashed it with the recommended firmware and it runs in 38400baud and if i connect to it with putty (serial consol) i can see that it send $PGACK,003,-1*71 is this correct or do i need to initiate it with some string ?
This wont work when i config my i2c arduino with binary proto and 38400Baud it newer lock or works in gui, but if i change to nemea all works ok ....
Any clue whats wrong ?

// fredde

Posted: **Sun Sep 16, 2012 6:38 pm**

dramida wrote:Ublox GPS protocol dosen't work anymore on MWC21 R1100 with some MPU boards.

Tested on two different Crius AIO Mega boards with three different ublox GPS receivers and serial ppm. The yellow led is blinking, the GUI shows GPS activity BUT THE SAT NUMBER STAYS 220, SPEED SWINGS AND BAD COORDINATES ARE DISPLAYED.
Strange is that same software worked on a mega controller with BMP085- ITG3200-BMA180 and HMC83xx (Paralel RC channel imput). I even uploaded the same software that worked on AIO board and the GPS dosen't work anymore.

Indeed the UBLOX parser is overcomplicated and little crazy

Get fresh r1117 version from repository, and UBLOX should work propertly.
I'm rewrite some pieces of UBLOX parser, and fix it.
Tested on Crius AIO Pro with RC-Timer UBLOX module.

Posted: **Sun Sep 16, 2012 7:05 pm**

Mis wrote:Indeed the UBLOX parser is overcomplicated and little crazy
Get fresh r1117 version from repository, and UBLOX should work propertly.
I'm rewrite some pieces of UBLOX parser, and fix it.
Tested on Crius AIO Pro with RC-Timer UBLOX module.

is this error also in the i2c GPS Code ?

Posted: **Sun Sep 16, 2012 7:40 pm**

LuFa wrote:is this error also in the i2c GPS Code ?

No, only with serial UBLOX GPS connected directly to MWC.

Posted: **Sun Sep 16, 2012 8:18 pm**

Mis wrote:
dramida wrote:Ublox GPS protocol dosen't work anymore on MWC21 R1100 with some MPU boards.

Tested on two different Crius AIO Mega boards with three different ublox GPS receivers and serial ppm. The yellow led is blinking, the GUI shows GPS activity BUT THE SAT NUMBER STAYS 220, SPEED SWINGS AND BAD COORDINATES ARE DISPLAYED.
Strange is that same software worked on a mega controller with BMP085- ITG3200-BMA180 and HMC83xx (Paralel RC channel imput). I even uploaded the same software that worked on AIO board and the GPS dosen't work anymore.

Indeed the UBLOX parser is overcomplicated and little crazy
Get fresh r1117 version from repository, and UBLOX should work propertly.
I'm rewrite some pieces of UBLOX parser, and fix it.
Tested on Crius AIO Pro with RC-Timer UBLOX module.

Thank you, i got the R1116 and now Ublox neo 6m it works fine.
/Mihai

Posted: **Sat Sep 22, 2012 8:33 am**

Hi,

i think it's been asked already...but i couldn't find the exact answerby searching..so i'll ask again. Is it possible to use GPS from remzibi's OSD with Multiwii for RTH/PH functions and use Remzibi OSD as an OSD device at the same time ?

Thanks

Posted: **Sat Sep 22, 2012 12:11 pm**

Yes, just split the TX from the GPS between the two boards. You have to define NMEA and use 5HZ firmware (or 10Hz with Filter enabled in config h)

Posted: **Wed Sep 26, 2012 11:08 am**

Hi,

looking in to the EOSBANDI I2C_GPS_NAV code I try to understand this things :

Code: Select all

////////////////////////////////////////////////////////////////////////////////////
// Calculate nav_lat and nav_lon from the x and y error and the speed
//
static void GPS_calc_poshold(int x_error, int y_error)
{
   int32_t p,i,d;                  
   int32_t output;
   int32_t x_target_speed, y_target_speed;

   // East / West
   x_target_speed   = pi_poshold_lon.get_p(x_error);         // calculate desired speed from lon error
   x_rate_error   = x_target_speed - x_actual_speed;                   // calc the speed error
        .
        .

x_target_speed is a speed (space/time) instead x_error is only space (difference of gps coord).
Maybe "constrain(x_target_speed, -100, 100);" is needed by this issue.

Posted: **Wed Sep 26, 2012 11:18 am**

thinking I have solved.
Space/1sec = Space

Posted: **Wed Sep 26, 2012 11:44 am**

I'm fighting multiple battles with my flyduspider hexa, with failing motors, hover wobbling and PID tuning boredom, but along with these I also have GPS troubles. I've got 2.1 with an i2c gps running EOSBandi's code, and all in all it runs fine, in that it communicates a stable position after getting pos lock and no comm errors get logged.

But I can't see much effect when switching to PH or RTH modes, with the machine floating away from me (a.k.a. home pos) or the position where I switch PH on. I've tried with and without ACC turned on, just because, but I was reading an EOSBandi document yesterday that I found randomly reading other threads and it stated that "Copter must be well trimmed and in level mode". Ok, due to the lack of stability in hover mode and lack of proper deadband setting to match my TX I never got level mode "just right (tm)" so it dawned on me... maybe the tilting to move the copter are all relative to level mode and that's what I have wrong here?

Posted: **Wed Sep 26, 2012 11:58 am**

GPS functions work only in level mode.

Posted: **Wed Sep 26, 2012 3:24 pm**

yes i had that problem. as soon as activate RTH/POS HOLD copter flies away, its because level mode is not trimmed .

if your copter flies away when you go into level mode, you must trim it using the stick technique when on the ground or using a switch connected to PASSTHROUGH , just google multiwii stable mode trim.
my advice: forget about gps until your quad is level, change your switch from POS HOLD/RTH to PASSTHROUGH and perform the stable mode trim according to the instructions. probem is: if you use different batteries or you have a crash, you often have to re-trim so you my as well make the PASSTHROUGH switch a permanent feature!

Posted: **Wed Sep 26, 2012 3:38 pm**

thanks guys. I do trim my level mode on every flight day, but since I have the hover quirks it never gets really stable. I know about inflight level mode trimming using passthrough but never had good results with it. As I said I'm fighting too many battles at once here, so I really just needed the assertion that GPS depends on LEVEL being used, I honestly didn't know that.

Posted: **Wed Sep 26, 2012 8:13 pm**

nav/pos pids are important to. I had issue that sounded like yours but was solved by a major pid tuning in the nav/pos hold region. my copter does has level mode dialled in as well.

Posted: **Sun Sep 30, 2012 7:34 pm**

I refer to EOSBANDI's "ublox-hw-hacks" guide to connect a EEPROM to my NEO-6M GPS. After that I use U-Center to config the GPS to 57600 and 5Hz rate and then save the data to GPS. But all data will return to default configuration after power off the GPS.
Anybody can help me to solve this problem. Thank a lot!

Posted: **Sun Sep 30, 2012 7:48 pm**

diyboy wrote:I refer to EOSBANDI's "ublox-hw-hacks" guide to connect a EEPROM to my NEO-6M GPS. After that I use U-Center to config the GPS to 57600 and 5Hz rate and then save the data to GPS. But all data will return to default configuration after power off the GPS.
Anybody can help me to solve this problem. Thank a lot!

With the new dev 1129 and following multiwii configures RCTimer Ublox GPS at start up. No need to hack anything.

Luciano

Posted: **Sun Sep 30, 2012 8:01 pm**

Termic1 wrote:
diyboy wrote:I refer to EOSBANDI's "ublox-hw-hacks" guide to connect a EEPROM to my NEO-6M GPS. After that I use U-Center to config the GPS to 57600 and 5Hz rate and then save the data to GPS. But all data will return to default configuration after power off the GPS.
Anybody can help me to solve this problem. Thank a lot!

With the new dev 1129 and following multiwii configures RCTimer Ublox GPS at start up. No need to hack anything.

Luciano

Hi Luciano,

Do you mean the updated version "MultiWii_dev_r1143.zip "?
I going to try it. Thanks!

DIYBoy

Posted: **Sun Sep 30, 2012 9:07 pm**

diyboy wrote:
Termic1 wrote:
diyboy wrote:I refer to EOSBANDI's "ublox-hw-hacks" guide to connect a EEPROM to my NEO-6M GPS. After that I use U-Center to config the GPS to 57600 and 5Hz rate and then save the data to GPS. But all data will return to default configuration after power off the GPS.
Anybody can help me to solve this problem. Thank a lot!

With the new dev 1129 and following multiwii configures RCTimer Ublox GPS at start up. No need to hack anything.

Luciano

Hi Luciano,

Do you mean the updated version "MultiWii_dev_r1143.zip "?
I going to try it. Thanks!

DIYBoy

I'm still using dev r1129 and GPS config works great. I assume that it will work with r1143 too.

Of course you need to define GPS, UBLOX, speed, etc...

Luciano

Posted: **Mon Oct 01, 2012 7:20 am**

Hi Luciano,

Thank you!

DIYBoy

Posted: **Mon Oct 01, 2012 8:32 pm**

Termic1 wrote:I'm still using dev r1129 and GPS config works great. I assume that it will work with r1143 too.
Of course you need to define GPS, UBLOX, speed, etc...

Today I loaded new dev r1143 and I confirm that it configures UBLOX GPS correctly.

Luciano

MultiWii

GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Works, but twitchy

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

Re: GPS integration

GPS integration

Re: GPS integration

GPS integration

Re: GPS integration

Re: GPS integration