Naze32 hardware discussion thread

JUERGEN_
Posts: 70
Joined: Sat Sep 08, 2012 9:12 am

Re: Naze32 hardware discussion thread

Post by JUERGEN_ »

timecop wrote:Just enable GPS with PWM receiver, and channels3/4 go to GPS, the rest work as usual.
So you have CH 1 2 5 6 7 8, connect them to A, E, T, R, AUX1, AUX2.

timecop wrote:yes. no other changes.
any standard serial gps will work.
rctimer cn06 seems cheap.
works with gps_type=2.

would not be an update of the manual a good idea :?:
- http://www.abusemark.com/downloads/naze32_rev1.pdf

;)

ruffster
Posts: 16
Joined: Wed Sep 05, 2012 5:57 am

Re: Naze32 hardware discussion thread

Post by ruffster »

I'm missing the obvious somewhere - please kick in the right direction...

First I've set my gps module via minigps software to 5Hz and 115200 and can see it outputting stuff:
Screen Shot 2012-09-09 at 09.09.30.png

Flashed the latest firmware, into cli to set all my usual settings + feature gps. Defaults of gps_type=0 & 115200. Save everything, unplug copter from pc.
Power up quad (gps module powered by one of the f20a esc bec's). Plug in the usb, open the com port in multiwiiconf and the GPS isn't showing. So close port, disconnect and power everything down and swap tx/rx cable going from module to naze32. Power up, connect usb and open in multiwiiconf and still nothing. I've repeated this with gps_type = 2 and still nothing.
Screen Shot 2012-09-09 at 09.33.46.png

20120909_093524.jpg

Am I missing a step somewhere or do I need to change the stuff being sent by the module?

hinkel
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: Naze32 hardware discussion thread

Post by hinkel »

timecop wrote:yes. no other changes.
any standard serial gps will work.
rctimer cn06 seems cheap.
works with gps_type=2.

you do need to upgrade to latest dev firmware.


Thanks Timecop for your Fast replys this is fine ;) :) :)

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

@y6 guy - swap TX. rx?

JUERGEN_
Posts: 70
Joined: Sat Sep 08, 2012 9:12 am

Re: Naze32 hardware discussion thread

Post by JUERGEN_ »

ruffster wrote:Image
Am I missing a step somewhere or do I need to change the stuff being sent by the module?

it is not a good idea, the video-tx
over the GPS antenna.

;)

User avatar
LeoWie
Posts: 70
Joined: Sun Aug 05, 2012 7:18 am
Location: Vienna
Contact:

Another Naze32 Test-Copter ;-)

Post by LeoWie »

Project working title:
"Naze32 Micro GPS-Module + KeyCam - Heavy Lifter" :lol:

Axis 160mm (mot. - mot.)
Weight <200g (tow)

Components:
TURNIGY Plush 6A /.8bec/6g Speed Controller
HobbyKing 1612 Brushless Outrunner 3200KV
5030 Propellers (Red + Black)
Turnigy nano-tech 850mah 2S 25~40C Lipo Pack (... max. ~ 1300 mAh)
DSM2 6Ch 2.4Ghz RX

Frame:
8 CFK round 2mm, l=250mm + some extra (RX ...)
1 CFK plate 0,7mm, 55 x 55mm,
8 Wood 4x4mm l=50mm, painted black,
100 cable ties 100x2,5mm black (do NOT glue the cable ties @ the motors),
... some cm of a bicycle racing hose ;-)

Maiden Flight Video:
http://youtu.be/5CWISUnl2hA

Maiden + GPS test report:
- Maiden Flight: was very good, just yaw's P maybe a little too high (had no time too change it on the field, ... too dark).
- GPS test PWM receiver r212 development test-version:
GPS Hold: workes fine, just a little param tuning to do (have to learn what params to change first ... makes circles / spirals closer to the desired point ~ o.k.).
GPS Home: there is a bug I think: copter begins to turn to one side (left) and has some problems when crossing the point ... looks like copter gets confused data sometimes: wants to yaw ... had this 5+ times, 3 times I had 3 harder landings when testing GPS Home (remark: with a copter like this / < 200g I think we have to redefine the word 'crash' to 'falling down softly' or something like this: there was no damage, even no props. I think it's close to the point where the feather effect takes place). Possibly it has to do with the a little too high Yaw P(?) ... problem: it was a copter maiden + GPS test in one.
Never a problem when GPS switched off ... and the new Baro / Height Hold works fine.

~~~ edit 2012-09-10 ~~~
Test report for r213: exactly like r212
Attachments
naze32_micro_gps_settings.jpg
micro_gps_aze32_001_800p_01.JPG
micro_gps_aze32_001_640p_03.JPG
micro_gps_aze32_001_640p_02.JPG
Last edited by LeoWie on Tue Sep 11, 2012 6:22 am, edited 17 times in total.

ruffster
Posts: 16
Joined: Wed Sep 05, 2012 5:57 am

Re: Naze32 hardware discussion thread

Post by ruffster »

timecop wrote:@y6 guy - swap TX. rx?

Tried that with gps_type=0 and gps_type=2 - any other suggestions - or should I just get another module ;)

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

What exactly module is it? MTK? or else why would you be trying type2?
If you configured it for 115200 and it actually STORES that setting and it outputs GPGGA and GPRMC by default, it should work.

ruffster
Posts: 16
Joined: Wed Sep 05, 2012 5:57 am

Re: Naze32 hardware discussion thread

Post by ruffster »

This one: http://www.flytron.com/osd-headtrackers/15-simpleosd-gps-module.html
It stores the 5hz - 115200 setting, I can cycle power and reconnect via mini gps at 115200 and see it outputting stuff...

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

Just tried my MTK (FMP04 breakout from ohararp http://ohararp.com/products.html) which was pre-configured to 115200/10Hz output and it works with gps_type=0 (nmea). By "works" i mean compass blinks and serial data is incoming.

I see something on the flytron page about needing a hack for 3.3V operation, I wonder if that's related?
It's pretty hard to have serial "not work" so I'm going to have to shrug this one off as 'user error' unless someone has better ideas.

User avatar
LeoWie
Posts: 70
Joined: Sun Aug 05, 2012 7:18 am
Location: Vienna
Contact:

Leo the Toaster

Post by LeoWie »

... almost off topic - question: I toasted one of my Rabbit GPS modules.
What could this be? ... red arrow on pic (now it is carbon and the other module is in use / mounted)
bug01.jpg
(107.17 KiB) Not downloaded yet

Thx
~~~ edit 1 ~~~
After 1+ hrs of googling + looking with the magnifying glass I ordered tantal-chip-cap 10V 10 µF (... 5 pcs :oops: )
Thx to TC.
Last edited by LeoWie on Mon Sep 10, 2012 12:00 am, edited 2 times in total.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

Polarized tantalum cap, probably around 47uF.

a944734
Posts: 23
Joined: Mon Sep 03, 2012 9:09 pm

Re: Naze32 hardware discussion thread

Post by a944734 »

Make that two users errors. I have the same Flytron module (defaults are 9600 and 1 Hz, changed defaults cannot be stored - chip limitation). Only way to change would be to find firmware 115200/10 Hz that fits. Not a road I would want to go really.
The module is designed to run on 5 V, tx and rx are 3.3 V

The module connects and works just fine in type=0 AND type=2 but ONLY at 9600 baud.

I certainly believe your pre-configured oharap works as type=0, as the code will not need to sent init strings ...

Unfortunately us other guys need init strings to work in type=2
These seem to work in Multiwii (taken from https://github.com/multiwii/multiwii-fi ... ed/GPS.ino)

Code: Select all

#if defined(GPS_SERIAL)
 #if defined(INIT_MTK_GPS) || defined(UBLOX)
  uint32_t init_speed[5] = {9600,19200,38400,57600,115200};
  void SerialGpsPrint(prog_char* str) {
    char b;
    while(b = pgm_read_byte(str)) {
      SerialWrite(GPS_SERIAL, b);
      #if defined(UBLOX)
        delay(4);
      #endif
      str++;
    }
  }
 #endif
 #if defined(UBLOX)
   prog_char UBLOX_INIT[] PROGMEM = { // PROGMEM array must be outside any function !!!
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x05,0x00,0xFF,0x19, //disable all default NMEA messages
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x03,0x00,0xFD,0x15,
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x01,0x00,0xFB,0x11,
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x00,0x00,0xFA,0x0F,
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x02,0x00,0xFC,0x13,
     0xB5,0x62,0x06,0x01,0x03,0x00,0xF0,0x04,0x00,0xFE,0x17,
     0xB5,0x62,0x06,0x01,0x03,0x00,0x01,0x02,0x01,0x0E,0x47, //set POSLLH MSG rate
     0xB5,0x62,0x06,0x01,0x03,0x00,0x01,0x03,0x01,0x0F,0x49, //set STATUS MSG rate
     0xB5,0x62,0x06,0x01,0x03,0x00,0x01,0x06,0x01,0x12,0x4F, //set SOL MSG rate
     0xB5,0x62,0x06,0x01,0x03,0x00,0x01,0x12,0x01,0x1E,0x67, //set VELNED MSG rate
     0xB5,0x62,0x06,0x16,0x08,0x00,0x03,0x07,0x03,0x00,0x51,0x08,0x00,0x00,0x8A,0x41, //set WAAS to EGNOS
     0xB5, 0x62, 0x06, 0x08, 0x06, 0x00, 0xC8, 0x00, 0x01, 0x00, 0x01, 0x00, 0xDE, 0x6A //set rate to 5Hz
   };
 #endif

  void GPS_SerialInit() {
    SerialOpen(GPS_SERIAL,GPS_BAUD);
    delay(1000);
    #if defined(UBLOX)
      for(uint8_t i=0;i<=5;i++){
        SerialOpen(GPS_SERIAL,init_speed[i]); // switch UART speed for sending SET BAUDRATE command (NMEA mode)
        #if (GPS_BAUD==19200)
          SerialGpsPrint(PSTR("$PUBX,41,1,0003,0001,19200,0*23\r\n")); // 19200 baud - minimal speed for 5Hz update rate
        #endif
        #if (GPS_BAUD==38400)
          SerialGpsPrint(PSTR("$PUBX,41,1,0003,0001,38400,0*26\r\n")); // 38400 baud
        #endif
        #if (GPS_BAUD==57600)
          SerialGpsPrint(PSTR("$PUBX,41,1,0003,0001,57600,0*2D\r\n")); // 57600 baud
        #endif
        #if (GPS_BAUD==115200)
          SerialGpsPrint(PSTR("$PUBX,41,1,0003,0001,115200,0*1E\r\n")); // 115200 baud
        #endif
        delay(10);
      }
      SerialOpen(GPS_SERIAL,GPS_BAUD);
      for(uint8_t i=0; i<sizeof(UBLOX_INIT); i++) { // send configuration data in UBX protocol
        SerialWrite(GPS_SERIAL, pgm_read_byte(UBLOX_INIT+i));
        delay(4); //simulating a 38400baud pace (or less), otherwise commands are not accepted by the device.
      }
    #elif defined(INIT_MTK_GPS) // MTK GPS setup
      for(uint8_t i=0;i<=5;i++){
        SerialOpen(GPS_SERIAL,init_speed[i]); // switch UART speed for sending SET BAUDRATE command
        #if (GPS_BAUD==19200)
          SerialGpsPrint(PSTR("$PMTK251,19200*22\r\n")); // 19200 baud - minimal speed for 5Hz update rate
        #endif
        #if (GPS_BAUD==38400)
          SerialGpsPrint(PSTR("$PMTK251,38400*27\r\n")); // 38400 baud
        #endif
        #if (GPS_BAUD==57600)
          SerialGpsPrint(PSTR("$PMTK251,57600*2C\r\n")); // 57600 baud
        #endif
        #if (GPS_BAUD==115200)
          SerialGpsPrint(PSTR("$PMTK251,115200*1F\r\n")); // 115200 baud
        #endif
        delay(10);
      }
      // at this point we have GPS working at selected (via #define GPS_BAUD) baudrate
      SerialOpen(GPS_SERIAL,GPS_BAUD);
      SerialGpsPrint(PSTR("$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n")); // only GGA and RMC sentence
      SerialGpsPrint(PSTR("$PMTK220,200*2C\r\n")); // 5 Hz update rate
    #endif
  }
#endif

msev
Posts: 186
Joined: Thu Apr 14, 2011 11:49 am

Re: Naze32 hardware discussion thread

Post by msev »

Hehe thats the gps that I have..It works on my osd as it should at 5V, does he use it at 3.3V? I haven't tried it on afro32 yet. Hope.u guys make it work with the init sentences :)

ruffster
Posts: 16
Joined: Wed Sep 05, 2012 5:57 am

Re: Naze32 hardware discussion thread

Post by ruffster »

I've got it connected to one of the esc bec - do I need to get it powered up before firing up the naze32? I'll give it a go tomorrow and check the tx/rx lines for continuity. Any other ideas as to other things to try would be much appreciated :)

User avatar
LeoWie
Posts: 70
Joined: Sun Aug 05, 2012 7:18 am
Location: Vienna
Contact:

Re: Naze32 hardware discussion thread

Post by LeoWie »

The 1st "Naze32 Micro GPS-Module + KeyCam(?) - Heavy Lifter" - Video:
http://www.youtube.com/watch?v=5CWISUnl2hA 8-)
Details: viewtopic.php?f=22&t=2387&start=90#p22426

a944734
Posts: 23
Joined: Mon Sep 03, 2012 9:09 pm

Re: Naze32 hardware discussion thread

Post by a944734 »

ruffster wrote:I've got it connected to one of the esc bec - do I need to get it powered up before firing up the naze32? I'll give it a go tomorrow and check the tx/rx lines for continuity. Any other ideas as to other things to try would be much appreciated :)


So there's three of us already, should be reason enough to get the inits working

Mine is taking 5 V from the receiver, just the same. It therefore starts the same time as the Naze. Works fine, sending data - but ONLY at 9600 baud in
type=0 and in type=2. Baud rate any higher = no worky
Definitely a problem with the inits in type 2 (type 0 does probably not send inits)

BrokenRotor
Posts: 9
Joined: Sat Mar 19, 2011 2:05 pm

Re: Naze32 hardware discussion thread

Post by BrokenRotor »

Hum, I have configured r209 with PWM and GPS. The weird thing is that if I do not map RTH in GUI I can arm the motors. If I map RTH under any AUX channel, the motors will not arm in the usual way, but if I select RTH active, the motors self arm?
All other channels and functions seem normal in the GUI. Using MultiWiiWin2.1 GUI.

Is this a code bug?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

MTK init sequences ARE sent with gps_type=2. I haven't tested if MTK3329 (that FMP04 module I got) accepts them or not, but according to the datasheet/protocol PDF, it should.

gps_type=0 is for modules t hat do NOT need any external configuraion and you KNOW thier baudrate ahead of time - i.e. module outputting at 38400 will need that rate to be specified for gps_baudrate or it will NOT get any data.

BrokenRotor: there are no code paths for something like this to be happening.

DrEvil
Posts: 17
Joined: Mon Sep 10, 2012 12:23 pm

Re: Naze32 hardware discussion thread

Post by DrEvil »

timecop wrote:MTK init sequences ARE sent with gps_type=2. I haven't tested if MTK3329 (that FMP04 module I got) accepts them or not, but according to the datasheet/protocol PDF, it should.

gps_type=0 is for modules t hat do NOT need any external configuraion and you KNOW thier baudrate ahead of time - i.e. module outputting at 38400 will need that rate to be specified for gps_baudrate or it will NOT get any data.

BrokenRotor: there are no code paths for something like this to be happening.


I have tested the Eagle Tree GPS V4 modul/dongle with the 209sw ang got it responding and giving data in MWIwin 2.1
Set it to gps_type=0 and 38400 in Cli.
It displayed a speed of 55kmt in my window post :roll: with 6 satelites.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

I believe gps speed shown is in cm/sec, and if you're expecting accurate speed values from a module that's not moving, well, ...

DrEvil
Posts: 17
Joined: Mon Sep 10, 2012 12:23 pm

Re: Naze32 hardware discussion thread

Post by DrEvil »

timecop wrote:I believe gps speed shown is in cm/sec, and if you're expecting accurate speed values from a module that's not moving, well, ...


Don't take it the wrong way TC, i was not expecting anything...
I just tought it was funny that the quadd was moving realy fast . . . . . in the windowpost..... LOL

At the moment i have no cloue about what to doe with gps and it's funktions, i hawe not been reading up on the subject.

Kai

Bhuwan
Posts: 17
Joined: Wed Sep 05, 2012 3:25 am

Re: Naze32 hardware discussion thread

Post by Bhuwan »

Finally back on here, I got my account reset (email wasn't working). Someone nearly convinced me to get the "AQ50d pro" FC, but I did my research on RCG and came across TC and, let's just say, i was enlightened (to not get it :D).

I'm going to pick up the Naze32 once the cover is available again, but i had one question - anyone know if it'll work with my DJI fLame Wheel? :mrgreen:

User avatar
LeoWie
Posts: 70
Joined: Sun Aug 05, 2012 7:18 am
Location: Vienna
Contact:

Naze32 Micro - Good Night Video

Post by LeoWie »


a944734
Posts: 23
Joined: Mon Sep 03, 2012 9:09 pm

Re: Naze32 hardware discussion thread

Post by a944734 »

timecop wrote:MTK init sequences ARE sent with gps_type=2. I haven't tested if MTK3329 (that FMP04 module I got) accepts them or not, but according to the datasheet/protocol PDF, it should.


May I suggest you do that test please, so we have facts

Just an idea - you are using pin 3 and 4 for GPS right ? Could one "listen" on pin 3 to see whats sent towards the GPS ?

BrokenRotor
Posts: 9
Joined: Sat Mar 19, 2011 2:05 pm

Re: Naze32 hardware discussion thread

Post by BrokenRotor »

timecop wrote:BrokenRotor: there are no code paths for something like this to be happening.


Can someone test GPS usage with PWM receiver? It makes no sense that checking RTH would fire up the motors, plus the loss of normal motor start. I used gps_type = 0, 115200 baud with 3339 GPS chip.

rotary65
Posts: 30
Joined: Mon Jun 25, 2012 11:27 am

Re: Naze32 hardware discussion thread

Post by rotary65 »

DrEvil wrote:I have tested the Eagle Tree GPS V4 modul/dongle with the 209sw ang got it responding and giving data in MWIwin 2.1
Set it to gps_type=0 and 38400 in Cli.
It displayed a speed of 55kmt in my window post :roll: with 6 satelites.


I am trying to get my Eagle Tree v4 GPS working with my Naze32 under 213. My Naze32 is running PPM. I set gps_baudrate=38400 and gps_type=0. I am running Multiwii Gui 2.1.

Which wires on the GPS did you use for TX and RX into the Naze (red, white, yellow, brown)? The pinout I found for the GPS cable was red=power, white=ground, yellow=tx (data to GPS), brown=rx (data from GPS).

A little bit more detail on what I'm attempting to do. I am splitting off the TX and RX from the GPS and have on set of TX/RX wires going to the Naze32 and the other set going to the V3 Logger (for the OSD). The GPS is being powered by the logger. This leaves two listeners (the logger and the Naze) and one talker (the V4 GPS)on the serial bus. The GPS is working fine with the logger/OSD. It may be that the output from the GPS can only effectively drive one listener.

Gruffy
Posts: 3
Joined: Sun Sep 09, 2012 8:26 am

Naze32 hardware discussion thread

Post by Gruffy »

BrokenRotor wrote:Hum, I have configured r209 with PWM and GPS. The weird thing is that if I do not map RTH in GUI I can arm the motors. If I map RTH under any AUX channel, the motors will not arm in the usual way, but if I select RTH active, the motors self arm?
All other channels and functions seem normal in the GUI. Using MultiWiiWin2.1 GUI.

Is this a code bug?

I saw that the function menus differ from MultiWii Configurator 2.1 and the MultiWii Gui. When you look into TC's code, you can see that the strings/names of the functions match the ones in MultiWii Configurator, but not in MultiWii Gui. My guess is that the MultiWii Gui does not read the strings properly, but instead they are hard coded to match the MultiWii 2.1 code. When I set the ALTHOLD in MultiWii Gui, this turned out to be MAG in the MultiWii Configurator. I am now using the MultiWii Gui for function mapping as that seems to be the correct info.
Maybe the RTH is ARM is one of these wrongly mapped functions in MultiWii Gui?

Ohh...an "Hi there" by the way. I just got here after getting a board from TC a few weeks ago. Quie new to the hobby, normally I fly single rotor helicopters and have a Logo 600 and a Protos 500. I do find this multilrotor thing very nice. Looking forward to flying/hacking with the Naze32 board!

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

Apparently, Gruffy is right.
MW-WinGui 2.1 uses hardcoded boxnames, so when I added angle/horizon modes, all boxes became shifted off by one.
Until EOSBandi fixes it, you can either use windows or android configs by nicodh or use the Java configurator.

DrEvil
Posts: 17
Joined: Mon Sep 10, 2012 12:23 pm

Re: Naze32 hardware discussion thread

Post by DrEvil »

rotary65 wrote:
I am trying to get my Eagle Tree v4 GPS working with my Naze32 under 213. My Naze32 is running PPM. I set gps_baudrate=38400 and gps_type=0. I am running Multiwii Gui 2.1.

Which wires on the GPS did you use for TX and RX into the Naze (red, white, yellow, brown)? The pinout I found for the GPS cable was red=power, white=ground, yellow=tx (data to GPS), brown=rx (data from GPS)..


I'm using Yellow kabel on pin 3 and Brown kabel on pin 4.
Power from free motor out pin's.

rotary65
Posts: 30
Joined: Mon Jun 25, 2012 11:27 am

Re: Naze32 hardware discussion thread

Post by rotary65 »

DrEvil wrote:I'm using Yellow kabel on pin 3 and Brown kabel on pin 4. Power from free motor out pin's.


@DrEvil: Thanks! That`s what I am using, but I wonder if the ET OSD Pro is sending initialization data that changes the output format. I`ll have to wait until I receive my USB-serial adapter to see.

@timecop: Nice job on the Naze32 manual update! Thank-you for all your work!

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

simonk sw

Post by brm »

hi tc,
i have a simple question.
in contrast to your suggestion not to fly a flamewheel i bought an f330.
the esc's are soldered to the bottom plate.
on real fast movements it seems i have a voltage drop and the esc
prob goes through a brown out.
question, do you know how it takes until the esc is back online?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

Then get a higher C battery, you need it for that heavy piece of junk. 20C, preferably 40C, should do the job. Nothing to do with naze32 however.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

Allright, MTK whiners rejoice. Found the problem and fixed it, confirmed working with my MTK GPS board.
Since I'm using interrupt-based uart code, I would write the buffer and start sending it at baudrate X, but CPU is too fast (not a problem in 8bitland), so while the buffer was still sending I'd already loop around to next baudrate and change to it, while there's some data left to transmit at previous baudrate. (was especially evident at 9600 baud). I guess 8bitland never hits this either because GPS uart is poll-based or maybe because it's just too slow the buffer makes it out before next configure loop iteration.

Here's how it looks. I added 30ms delays between each transmission as well, just to make sure.
Image

a944734
Posts: 23
Joined: Mon Sep 03, 2012 9:09 pm

Re: Naze32 hardware discussion thread

Post by a944734 »

On certain occasions some whining is quite in order to help find bugs ;)

Have now successfully connected my Flytron MTK GPS module using gps_type = 2 and gps_baudrate = 57600, receiving data and fix in GUI :D
Just to be very precise, in the meantime I had reflashed its firmware to 38400 / 5 Hz

No chance to test fly today, rain is pouring down

BTW - how much whining is needed to get an AfroOSD ?

BrokenRotor
Posts: 9
Joined: Sat Mar 19, 2011 2:05 pm

Re: Naze32 hardware discussion thread

Post by BrokenRotor »

timecop wrote:Apparently, Gruffy is right.
MW-WinGui 2.1 uses hardcoded boxnames, so when I added angle/horizon modes, all boxes became shifted off by one.
Until EOSBandi fixes it, you can either use windows or android configs by nicodh or use the Java configurator.

Thanks TC / Gruffy. I guess it's back to the java app for configurations.
BTW> what does the angle / horizon modes control?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

https://www.google.com/search?q=multiwi ... angle+mode

its something alex came up with months ago. angle = old acc. horizon = something new.

a944734
Posts: 23
Joined: Mon Sep 03, 2012 9:09 pm

Re: Naze32 hardware discussion thread

Post by a944734 »

Next little problem - feature GPS not "remembered"

Procedure as follows (feature GPS is set in CLI of course at the beginning)

- Power up Naze
- Connect to MultiWiiConf
- Open COM
- START
-> GPS data is received, compass blinks, sats are counting up
-> GPS BOX is NOT green, no GPS functionality e.g. no warning when switching to GPS HOLD before fix is achieved

Remedy as follows (Naze still powered on)
- MultiwiiConf Close COM
- Start Hercules, open COM
- type feature -GPS
-> feature GPS disabled
- type feature GPS
-> feature GPS enabled
- save (reboot)
- Close COM
- MultiwiiConf Open COM
- START
-> GPS data is received, compass blinks, sats are counting up
-> GPS BOX is NOW green, all GPS functionality available

As soon as NAZE is powered off / back on we start from point 1 unfortunately, no green GPS BOX

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

Are you power-cycling the GPS during that time as well?
GPS will be disabled if there's no valid nmea data within 1 second, I should probably increase that timeout, otherwise the sequence you describe makes no sense, enabling/disabling GPS has no effect on whether it will be found or not next time its enabled.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Naze32 hardware discussion thread

Post by brm »

timecop wrote:Then get a higher C battery, you need it for that heavy piece of junk. 20C, preferably 40C, should do the job. Nothing to do with naze32 however.


:o measering the voltage drop is an interesting sub-project.
in case of fast esc's you can create an electronic braking system which works against the throttle :mrgreen:

i have a 25c battery with 110 amps burst - have not yet tested with 30c
before flying smooth you should know why it is fyling smooth ;)

User avatar
LeoWie
Posts: 70
Joined: Sun Aug 05, 2012 7:18 am
Location: Vienna
Contact:

Connect GPS Modules

Post by LeoWie »

Hi,
I saw that TC modis 2 r's ago affect all gps-communication (gpsprint).
So I re-tested my GPS modules (indoor only) on development version r218.

Tests procedure:
mod settings in CLI, check in MultiWiiConf_2_1 GUI [GPS] button green or not (close + open GUI).
No sats visible in my urban canyon apartment, no flight test possible today: rain is pouring down.

GPS Modules:
a) Rabbit GPS (ublox NEO-6M-0-001, worked on a Rabbit FC before)
b) Crius CN-06 GPS Receiver Module (out of the box)

Connection :
GPS in PWM input mode.
GPS:Rx-FC:3:TX + GPS:Tx-FC:4:RX (not Tx-Tx + Rx-Rx).
Gnd, +5V from Naze32's free CH5 or 6

Test result:

Code: Select all

set gps_type = 1 (not 0 + 2)          
set gps_baudrate =
        a) Rabbit   b) Crius
        r212 r218   r212 r218   
 19200    ok   ok      -   ok
 38400    -    ok      -   ok
 57600    -    ok      -   ok
115200   -    ok      -   ok


Thx TC.

PS: a " MediaTek MTK3329 GPS Module 10hz GPS With Antenna APM ACM Identification" will arrive soon.
Attachments
2_ublox_test_640px.JPG
Last edited by LeoWie on Thu Sep 13, 2012 7:26 am, edited 4 times in total.

Gruffy
Posts: 3
Joined: Sun Sep 09, 2012 8:26 am

Re: Naze32 hardware discussion thread

Post by Gruffy »

I can confirm that the MTK3329 GPS with ArduPilot adapter (yes...I am sorry, but I own one of those as well...) works with baudrate=38400, type=2 (MTK) and I get the green "GPS" symbol. I did not wait for "locked position" in this test (indoor without reach of signals) but I have high hopes on this, will let you know more.
Powered from 5V (on motor pin headers), the UART TTL level out with this adapter board is still 3.3V hence works nice and easy to connect. This was done with PWM receiver (skipping channel 3&4 as per manual). Have ordered myself a PPM-DSM2 receiver for future tests.

a944734
Posts: 23
Joined: Mon Sep 03, 2012 9:09 pm

Re: Naze32 hardware discussion thread

Post by a944734 »

timecop wrote:Are you power-cycling the GPS during that time as well?
GPS will be disabled if there's no valid nmea data within 1 second, I should probably increase that timeout, otherwise the sequence you describe makes no sense, enabling/disabling GPS has no effect on whether it will be found or not next time its enabled.


I am not power-cycling the GPS. It is fed from the receiver and everything is on all the time.

I think increasing this timeout would be a good idea, have my doubts that the lame MTK GPS is able to send data within a single second from system start.
Obviously my remedy routine helps because there is a Naze reset in there - GPS being still powered it is ready to send even before Naze comes back up.

rotary65
Posts: 30
Joined: Mon Jun 25, 2012 11:27 am

Naze32 hardware discussion thread

Post by rotary65 »

With r213, I have the Naze32 and my Eagle Tree V3 Logger/OSD Pro successfully sharing the same Eagle Tree GPS V4. The brown Tx line from the GPS is split and connects to pin 4 on the RC Header on the Naze. I set gps_type=0, gps_baudrate=38400 and feature gps (I had missed this last step before). All is working well.

DrEvil
Posts: 17
Joined: Mon Sep 10, 2012 12:23 pm

Re: Naze32 hardware discussion thread

Post by DrEvil »

rotary65 wrote:With r213, I have the Naze32 and my Eagle Tree V3 Logger/OSD Pro successfully sharing the same Eagle Tree GPS V4. The brown Tx line from the GPS is split and connects to pin 4 on the RC Header on the Naze. I set gps_type=0, gps_baudrate=38400 and feature gps (I had missed this last step before). All is working well.


Nice to know you got the sharing of GPS data with ET-osd to work. :-)

Kai

Count
Posts: 18
Joined: Thu Feb 23, 2012 2:04 pm

Re: Naze32 hardware discussion thread

Post by Count »

Just one quick question before I waste more time on this:

Is the flying wing mixer fully functional?

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Naze32 hardware discussion thread

Post by timecop »

Should be.
If you feel you are wasting your time at any moment, may I direct you towards DJI products.

rotary65
Posts: 30
Joined: Mon Jun 25, 2012 11:27 am

Re: Naze32 hardware discussion thread

Post by rotary65 »

DrEvil wrote:
rotary65 wrote:With r213, I have the Naze32 and my Eagle Tree V3 Logger/OSD Pro successfully sharing the same Eagle Tree GPS V4. The brown Tx line from the GPS is split and connects to pin 4 on the RC Header on the Naze. I set gps_type=0, gps_baudrate=38400 and feature gps (I had missed this last step before). All is working well.


Nice to know you got the sharing of GPS data with ET-osd to work. :-)

Kai


Thanks for your help in confirming details Kai. I have also just changed from a FreeFlight board to timecop`s latest v4 Naze32 with the dev firmware. The new hardware and firmware is completely AWESOME! The new sensors on the v4 (MPU6050, MMA8452Q, MS5611) are so, so much better performing than the ones of the FreeFlight (MPU3050, BPM085, ADCL345). Now it`s just about fine tuning, not coarse adjustments with poor results as it was with the FreeFlight.

@Timecop: After checking around a bit, I really appreciate your approach with baseflight. You maintain enough control to ensure good quality while quickly porting over selected bits from the MWC trunk. Open, readily available (to those who don't need handholding) and supported (with good, quick updates and response to bugs and enhancements). Many Naze32 and baseflight extras. Very cool.

kipkool
Posts: 30
Joined: Mon Jun 25, 2012 9:21 am

Re: Naze32 hardware discussion thread

Post by kipkool »

Hi there.

Just for info guys, this dude has just ported OpenPilot to STM32F4 ( Discovery board ), and MPU6050 PiOS is done.

https://github.com/lilvinz/OpenPilot/wi ... s-is-about

What's difference do we have between STM32F3 and F4 ? I'm just giving a look on PiOS stuff to check what works involved for a simple port ( no baro + compass yet ). Seems too hardcore for me but who knows...

I don't have the new Naze32 rev, mine is still ADXL345 based and never could make it works correctly in level mode on my different frames, but I think I'll order TC a new one. All mpu6050 based units I've tested always worked really well here.

rotary65
Posts: 30
Joined: Mon Jun 25, 2012 11:27 am

Re: Naze32 hardware discussion thread

Post by rotary65 »

kipkool wrote:Hi there. Just for info guys, this dude has just ported OpenPilot to STM32F4 ( Discovery board ), and MPU6050 PiOS is done.


The OpenPilot project perspective on porting. In a nutshell, they rely on flight controller hardware sales to keep the project going. They write the code and they generally do not wish for it to be ported.

Post Reply