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

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

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 intype=0 and in type=2. Baud rate any higher = no workyDefinitely a problem with the inits in type 2 (type 0 does probably not send inits)

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.

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.

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.1Set it to gps_type=0 and 38400 in Cli.It displayed a speed of 55kmt in my window post with 6 satelites.

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

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?

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.1Set it to gps_type=0 and 38400 in Cli.It displayed a speed of 55kmt in my window post 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.

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!

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.

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.

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 escprob goes through a brown out.question, do you know how it takes until the esc is back online?

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.

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

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?

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

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

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.

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.

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.

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.

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.

kipkool wrote: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.

high acc_lpf, fixed loop time at 3000 or so, should be fine on defaults without too much vibration.

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.

Can I please have a version with this timeout increased ? Maybe you want to make this a CLI variable, so I could find out how much is needed for the Flytron version. Might also come in handy when other MTKs come into use.

timeout is not really a solution since it owuld affect other gps users.I'll think of some proper way to detect GPS, as well as handle disconnection of GPS mid-flight which mwc currently fails it.this will fix the autodetect part as well.

The OpenPilot project perspective on porting.[/url] 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.

Seems they're a little bit more flexible now, the STM32F4 + mpu6050 patch is in review for Git merge.They just don't want company to make buisness with OP code, but hobby port is not forbidden.

high acc_lpf, fixed loop time at 3000 or so, should be fine on defaults without too much vibration.

I 've not touched my naze32 since May ( was playing with OP, and have to say I love the software ), so didn't followed latest baseflight evolution There was no looptime tuning yet if I remember. Will check that thanks.I'm actually building a new test frame for it and giving a look to baseflightplus code.

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

No thanks, I am perfectly pleased with how my Naze boards perform in my copters.I just tried to install one them in one of my planes (a flying wing) and could not seem to get the setup right.I needed to reverse the servo directions and alter the mix, because one servo arm is pointing up and the other one down.With the default flying wing mixer this gets me parallel elevon movement with roll and opposit movement with pitch and the Naze board was correcting in the wrong wayFirst I set wing left max to 1050 and min to 2000. This caused the left elevon to go to the negative endpoint and stay there, only moving with full right roll input.I then saw the pitch and roll reverse settings. I set the min max values back to default and altered one reverse setting (can´t remember which). This also caused one elevon to move to the endpoint. For some reason the elevon did not move back to the middle position after I set the value to default again.Only setting the Naze board to defaults got it working again.

Ok, here results of first flight test with Flytron MTK GPS working and active.Conditions fine, small breeze

Attempt 1 (waited for full GPS fix with 7 satellites)Started in mode man -> fine as everSwitched to mode angle -> fine as ever, well trimmedSwitched to GPS Hold -> nothing bad, quad is visibly trying weakly to stay on the spot. Bringing it back to the spot by gently nudging sticksHowever after about 20 seconds in GPS hold, quad flips violently to the left - lands upside down on tarmac - two motors running full blast. No reaction to TX commands, had to unplug power. No major damage, just a blade tip

Attempt 2 (again after fix with 6 satellites)Start in mode man -> no problemSwitche to mode angle -> no problem, stableSwitching to GPS Hold -> same behaviour, trying to hold position. Again after 30 seconds, snap into 90 degree angle to rear/left, crash again - this time into grass. Two motors again running WOT, no reaction to TX - needed to unplug power. This time all blades gone

Don't get me wrong, am not moaning here. This is my heavy metal beater quad - crashing is part of beta testing, no sweat

What IS bothering me is the fact that TX control was lost both times immediately and totally. Be assured I was expecting things, fingers on the switch. Within split seconds I had throttle off and switched back to MAN - it did not react at all even before it was on ground. The FC was totally frozen until I unplugged