Naze32 hardware discussion thread

QAV400 · Post by **QAV400** » Wed Jan 22, 2014 9:12 am

If there is a more appropriate thread for this ? then pls direct me to it

I could not find any way of contacting who ever makes the Baseflight App

Does anyone know if you can roll back the Chrome app Baseflight, as it just updated itself (not sure how to turn this off) now it wont read my pids all the time (have to click that page many times also the firt intial page will not show the board moving in the little box picture, Rx page reads. It was all perfect then baseflighht app updates then wont work

Im running baseflight r363 on the rev4 board and I didnt really want to update it, or do i now have to now?

Is there any other GUI's out there i could use

teslahed · Post by **teslahed** » Wed Jan 22, 2014 2:46 pm

I am using a minimOSD with my naze32 and i have been having a few issues the last few days.

If i enter the CLI using the chrome app when my minimOSD is hooked up and everything is powered by a lipo i get a load of gibberish along these lines;

http://i.imgur.com/XJNYR9P.png

Also the radio bars on the chrome app update REALLY slowly even though my radio responds normally in flight.

If i disconnect RX and TX between the minimOSD and the naze32 i don't have any issues.

It used to be the case (a few days ago) that the minimOSD wouldn't get sent any data until after i armed my Naze32. Now i get all data including the artificial horizon showing as soon as i plug everything in to power. I don't know why this has changed but i wonder if it relates to the gibberish i'm seeing in the CLI. It was suggested in IRC chat that as USB and the MinimOSD share the same seriel port this could be the cause of the problem.

Any suggestions?

Has something changed recently in the firmware (i did update a few days ago) to alter the way the minimOSD is sent data before arming?

hinkel · Post by **hinkel** » Thu Jan 23, 2014 12:59 am

IMHO you can not use minimosd and USB at the same time !

QAV400 · Post by **QAV400** » Thu Jan 23, 2014 1:04 am

teslahed wrote:I am using a minimOSD with my naze32 and i have been having a few issues the last few days.

If i enter the CLI using the chrome app when my minimOSD is hooked up and everything is powered by a lipo i get a load of gibberish along these lines;

http://i.imgur.com/XJNYR9P.png

Also the radio bars on the chrome app update REALLY slowly even though my radio responds normally in flight.

If i disconnect RX and TX between the minimOSD and the naze32 i don't have any issues.

It used to be the case (a few days ago) that the minimOSD wouldn't get sent any data until after i armed my Naze32. Now i get all data including the artificial horizon showing as soon as i plug everything in to power. I don't know why this has changed but i wonder if it relates to the gibberish i'm seeing in the CLI. It was suggested in IRC chat that as USB and the MinimOSD share the same seriel port this could be the cause of the problem.

Any suggestions?

Has something changed recently in the firmware (i did update a few days ago) to alter the way the minimOSD is sent data before arming?

Im almost 100% certain its nothing to do with the OSD, Its just random.

As mine was also doing this same cli jargon characters also(and other stuff was not working also, intermittent no pids page for example), its all since the Chrome baseflight App Updated it self, I can not for the life of me figure out how to stop it updating itself automaticly).
I fixed all my issues by updating the baseflight firmware on the board, The latest version of the Chrome app did not seem to like my older baseflight r363 september 2013

Annoying as hell as Once my craft is flying all good I really dont want to have to update or change things, but i was forced to in this case, if I wanting to continue to use the Chrome App

timecop · Post by **timecop** » Thu Jan 23, 2014 2:06 am

QAV400 wrote:If there is a more appropriate thread for this ? then pls direct me to it
I could not find any way of contacting who ever makes the Baseflight App

Does anyone know if you can roll back the Chrome app Baseflight, as it just updated itself (not sure how to turn this off) now it wont read my pids all the time (have to click that page many times also the firt intial page will not show the board moving in the little box picture, Rx page reads. It was all perfect then baseflighht app updates then wont work

Im running baseflight r363 on the rev4 board and I didnt really want to update it, or do i now have to now?

Is there any other GUI's out there i could use

are you on old firmware or old chrome or something?
it should always work with newest firmware, newest chrome.
Update all of the above if problems.

QAV400 · Post by **QAV400** » Thu Jan 23, 2014 2:18 am

Latest Chrome
On the rev4 Board was Baseflight firmware - baseflight-20130719.zip

Once the Chrome Baseflight applictaion updated it self (it told me it updated)
then after that had all the issues.

I have now updated to the newer firmware on the board and it all seems fine now

Was wondering tho if i wanted to stick with my Rev 4 white board for years and years etc would this be a problem agian in the future? or will the newer baseflight firmware always be backwards compatible with old rev's of the board?

timecop · Post by **timecop** » Thu Jan 23, 2014 2:24 am

new firmware always supports all boards from rev0 to latest.

QAV400 · Post by **QAV400** » Thu Jan 23, 2014 2:41 am

Thanks , you the man....

sentinel · Post by **sentinel** » Thu Jan 23, 2014 9:36 am

I'm trying to better understand what some of the settings will yield. Can someone please give a brief description for the following settings that I see in Baseflight app config:

RC Rate
RC Expo
Roll & Pitch rate
TPA
Yaw Rate

I understand what most of those achieve on a general level but looking for a direct explanation of how these will affect my flight.

Mainly, I'm trying to create a flight experience that is snappy enough to do quick turns/u-turns without it being too squirrelly or sensitive. Should I be focusing on TX expos to decrease this sensitivity instead? Thanks in advance for any insight.

treym · Post by **treym** » Thu Jan 23, 2014 9:53 pm

sentinel wrote:I'm trying to better understand what some of the settings will yield.

RC Rate
RC Expo
Roll & Pitch rate
TPA
Yaw Rate

looking for a direct explanation of how these will affect my flight.

www.multiwii.com/wiki/index.php?title=Main_Page

Mochaboy · Post by **Mochaboy** » Fri Jan 24, 2014 10:19 pm

So some good news elmtree.

I'm going to stop short of saying the pink one's fixed until I've had a chance to install it in a quad and verify motor outputs but the surgery was at least up to this point a success.

* VCC trace as well as a GND trace blew up, so I had to scrape back the enamel and solder in hook up wire to restore them
* The STM32 did indeed get hot when plugged in over usb, replacing that was a bit of a chore, but nothing a lot of solder braid and flux couldn't fix.
* the boot pins/configurator didn't work for me - got some generic error message. I used my F4 discovery board + ST-Link to load the latest build of baseflight.hex Once I figured out what the pin assignments were (thank you timecop for thoughtfully marking pin 1's) - the firmware load went off without a hitch and the board connected to the configurator on the first try.

Leaving this here as a reference in case any other hardware hackers decide to give this a go.

* The 10 pin SWD connector - pin 1 is marked by an arrow. the rest of the assignments go like this:

1 2
3 4
5 6
7 8
9 10

Pin 3 or 5 are GND
Pin 2 is SWIO
Pin 4 is SWCLK

Those mate to the SWD port on the F4 Discovery board:
1 (pin on top - nearest edge of board)
2 - SWCLK
3 - GND
4 - SWIO
5
6

I didn't have a 10 pin connector so I soldered the wires directly to the pads.

Apart from a lot of bridging on the STM32 - it was fairly straightforward, just took longer to clean than normal. I connected to the board over the configurator and calibrated the sensors then checked to see that the sensors were still sending raw data which they are.

I'm still not sure what caused this issue ... but we should trade notes before you hook in your telemetry again. I'm out of time for today for the orange board, but I'll get to that when I get another free moment.

timecop · Post by **timecop** » Sat Jan 25, 2014 1:07 am

Not sure if pin1 stuff was a jab at something, the 10pin debug connector is standard Cortex-M Debug Port connector pinout:
http://infocenter.arm.com/help/topic/co ... ectors.pdf

Mochaboy · Post by **Mochaboy** » Sat Jan 25, 2014 2:13 am

timecop wrote:Not sure if pin1 stuff was a jab at something, the 10pin debug connector is standard Cortex-M Debug Port connector pinout:
http://infocenter.arm.com/help/topic/co ... ectors.pdf

Lol no jab (you get enough), I was thanking you for marking pin 1's clearly, some designs just assume it and they leave the markings off. The cortex debugger isn't something I've used and sure enough instead of 1-5 going down one side, it alternates. I realize that's trivial for anyone that's worked with it, but that was a first time for me.

I'm just glad the swd interface worked otherwise I would have been sunk. I just finished working on the second board which went much faster and cleaner than the first.

elmtree · Post by **elmtree** » Sat Jan 25, 2014 3:14 am

Well damn, that's awesome!

I'm glad that it was able to be fixed after all I'd done to it. Hope the motor pins are working!

Good luck with the next board, hopefully it's a bit less work to fix...

Thanks again

Mochaboy · Post by **Mochaboy** » Sat Jan 25, 2014 3:34 am

Was too excited to wait.

Orange one's fixed too now. Pink took 3 hours, Orange took ~45 minutes. Everything appears to be working. I'm going to throw these in the micro quad this weekend and make sure the motors actually spin up - if everything works out these should be on their way back to you next week.

I'm also concerned about the telemetry thing having issues with 5v signal levels. Have some reading to do on the datasheets to verify which pins are affected. No one on the fpvlab board has run into these issues with the kvteam boards all the way down to v0.1 minimosd boards so I'm not sure what happened there. My biggest concern is that you plug everything in the same way you did the first time and then something burns out again, I just have no way of troubleshooting that without the telemetry gear.

More soon.

elmtree · Post by **elmtree** » Sat Jan 25, 2014 5:35 am

Damn, you've got this down.

I posted in the KV OSD thread at FPVLab asking if anyone had used the whitespy OSD with the Naze32 and no one seemed to respond so I'm a bit paranoid about actually plugging the OSD back in.

Mochaboy · Post by **Mochaboy** » Sat Jan 25, 2014 8:22 pm

Just a quick update.

Both boards spun up the micro quad, and I did a quick hover test to make sure it was stable which it is, so going to call this one a win.

QAV400 · Post by **QAV400** » Sun Jan 26, 2014 10:11 am

Is there a dangerously low "P" value that one should not go under? or I or D etc...

As a few weeks ago i was messing with pids with some pretty radical settings and it hovered ok but when I throttled up hard it went bezerk and lost all control crashing badly
so im just trying to avoid this again while tuning
Cheers

BlackRock · Post by **BlackRock** » Mon Jan 27, 2014 2:56 am

Ok, don't shoot me if this is a dumb question, but how do I test the mag and baro? I have a brand new rev 5 (Caution Cone Orange) Full Naze32 board but when connected in Baseflight Configurator they are red... I'm probably just doing something wrong or don't have something set up or connected properly for them to work. Help appreciated.

Here is where I am at:

-I've loaded Chrome and Baseflight Configurator on my Mac
-Installed the Silab's driver and forced my Mac to see it with: sudo ln -s /dev/tty.SLAB_USBtoUART /dev/tty.usbserial
-Started up the firmware flash utility and flashed it with what I think is the latest firmware: baseflight 20130719 firmware
-Then I connect the device successfully but only Gyro and Accel are green.

In the CLI I've rotated the board 90* and mapped my controls to match my Rx successfully. I probably don't even need the baro or mag but I got the full board to play with them. Heck, I don't even see the barometer on the board. I've read it's on the bottom of the board and metal with two holes? I have NOTHING on the bottom of my board and nothing that should look like a barometer. Maybe I was sent an Acro Naze32 instead??? Anyway to tell the difference? I sure paid the full price for it...

timecop · Post by **timecop** » Mon Jan 27, 2014 2:59 am

Then you have the acro board?

BlackRock · Post by **BlackRock** » Mon Jan 27, 2014 3:09 am

Yes and no, I purchased the full board that was supposed to have: Sensors: MPU6050, HMC5883L, MS5611 but it looks like they sent me the Acro board instead.

I think I just found a picture of a pink rev 5 board with the baro on it and looking at my board I'm missing the baro along with a few surrounding pieces. I got the board at Multirotor Superstore just a couple weeks ago when they came in stock for a brief moment in time.

Here is an image of a rev5 board I found online. Assuming my rev5 orange board is supposed to be the same I am in fact missing the baro along with the chip immediately to the right of it. I take it from this pic, the baro is on the bottom middle of the board with 2 holes in it. My other guess is the magnometer is the larger chip just left of the arrow. All of which is missing from the "full Naze32" I paid for...

scrat · Post by **scrat** » Mon Jan 27, 2014 6:03 pm

The you have been ...I will not say what

eBoon · Post by **eBoon** » Mon Jan 27, 2014 6:15 pm

thebgrian wrote:If you haven't tried already set looptime = 3000 and set acc_lpf = 100 or more. This should help with the acc and horizon mode.

I am just setting up a new V-Tail - first time using this board (it's the Acro version). My version is 2.2 Nov 26. Is changing acc_lpf_factor and looptime still the best practice for getting horizon mode to work properly? Do these values affect the other flight modes as well? My current values for acc_lpf_factor and looptime are 4 and 3500 respectively.
Should these be changed to 100 and 3000?

Thanks for your help!

Tom

BlackRock · Post by **BlackRock** » Tue Jan 28, 2014 12:34 am

Ok, so I confirmed that I've got an Acro Naze32, but not to worry. I emailed the guys at Multi Rotor Superstore and they were on it. Thanks guys!

I've got a full Naze32 on it's way. When it comes in I'll take some nice shots of both and post up pics. I think it would be nice to get some updated photos of the cards directly in this thread. Had I known what I was looking for I might have spotted the wrong card sooner, but there are few if any pics of current revs anywhere. The manual doesn't have a real pic and the computer image doesn't show or label where the sensors are making it a guessing game as to what I've got.

Thanks guys!

QAV400 · Post by **QAV400** » Tue Jan 28, 2014 1:51 am

QAV400 wrote:Is there a dangerously low "P" value that one should not go under? or I or D etc...

As a few weeks ago i was messing with pids with some pretty radical settings and it hovered ok but when I throttled up hard it went bezerk and lost all control crashing badly
so im just trying to avoid this again while tuning
Cheers

anyone in the know?

Also I have a acro verion of the Naze32 so I was wondering how does the GUI little box picture know when i turn the board etc , like it knows front back up down etc but i thought it needed a mag sensor to know this?

wuudogg · Post by **wuudogg** » Thu Jan 30, 2014 2:47 pm

Mpu60xx is a gyro accelerometer... That's how.

kaysee · Post by **kaysee** » Sat Feb 01, 2014 7:42 pm

Hi TC. Need help. I'm just starting to enjoy my acronaze32 on my new diy mini h-quad when i had a mishap this morning with a tree. Afterward, the buzzer starts to beep every second, leds - blue is on, green and red alternately switching on n off. What might be wrong here?
I tried to re flash the firmware but failed. Can't seem to enter the bootloader mode with hercules. With the boot shorted method i just got the blue led lights up.

timecop · Post by **timecop** » Sun Feb 02, 2014 1:19 am

Gyro is dead, you probably damaged/snapped the pcb or trashed some I2C-related trace on it. Check carefully for any cuts/etc in traces or try to re-reflow the gyro if you have hot air equipment, otherwise toss it. Not much else to do.

kaysee · Post by **kaysee** » Sun Feb 02, 2014 2:42 am

Ouch! Thanx man.

sentinel · Post by **sentinel** » Sun Feb 02, 2014 4:07 am

Anyone know of a good place to order cases for their Naze32? Or some rectangular plastic cases that can be fashioned into one...

timecop · Post by **timecop** » Sun Feb 02, 2014 4:08 am

sentinel wrote:Anyone know of a good place to order cases for their Naze32? Or some rectangular plastic cases that can be fashioned into one...

If you know someone with a 3d printer, there's a thing on thingiverse...
http://www.thingiverse.com/thing:175442
Or maybe you can download the data and order through shapeways etc.

sentinel · Post by **sentinel** » Sun Feb 02, 2014 4:09 am

Awesome, thanks for the quick reply. That'll work.

scrat · Post by **scrat** » Mon Feb 03, 2014 6:52 am

My friend makes cases for Naze32 if you need.

Invid · Post by **Invid** » Mon Feb 03, 2014 10:04 am

scrat wrote:My friend makes cases for Naze32 if you need.

I have one of his cases and they're pretty nice. A tittle tall, but supports the pins well and includes foam for the baro on a full house board.

sentinel · Post by **sentinel** » Mon Feb 03, 2014 8:13 pm

I also found this case: http://www.shapeways.com/model/1357730/ ... terialId=6

One more thing- I understand the angle and horizon modes only use gyro and accel sensors. Can someone please confirm that the Acro Naze32 supports these flight modes? I imagine so, just looking for confirmation before I order a bunch of them.

Is there any reason for the Acro Naze32 to be shielded from light? I'm considering making a case that has a clear plastic top where light will obviously come through.

mmon77 · Post by **mmon77** » Mon Feb 03, 2014 10:00 pm

The acro naze supports angle and horizon.

There's no need to shield it from light. It has no baro sensor on it.

iacopo · Post by **iacopo** » Wed Feb 05, 2014 9:52 am

Hi everybody,
I've had no problems in getting frsky telemetry from my naze, and before having set telemetry, I used to use bluetooth to interface it with the baseflight configurator.
I have frsky telemetry connected to the frsky pins, and bluetooth connected to the tx/rx pins (the ones in the middle of the board), I found out if I connect via bluetooth, the telemetry won't work, I know you have to chose between telemetry or bluetooth, but I was wondering: wouldn't it be possible to enable bluetooth when disarmed and switch to telemetry when armed?
If the naze does this already, then I'm sorry, but I couldn't get it to work!

timecop · Post by **timecop** » Wed Feb 05, 2014 12:49 pm

It *should* work.
Bluetooth might spew out crap when armed (due to 9600 baud/telemetry) but it should work. Does it not?

iacopo · Post by **iacopo** » Wed Feb 05, 2014 1:36 pm

timecop wrote:It *should* work.
Bluetooth might spew out crap when armed (due to 9600 baud/telemetry) but it should work. Does it not?

Sorry, probably my bad then. Last time I tried it didn't work, but I didn't spend any time troubleshooting, I'll take a better look at it tonight.

edit: just checked and indeed it works, I don't know what went wrong last time I tried!

This is one thing I found: if I connect to baseflight - configurator via bluetooth, and then arm the quad while still connected, the quad stays armed and spins the motors for a second or two, then stops the motors, ESCs make a sound (probably no PWM is sent) and every LED on the naze is on. I then have to power cycle it to arm motors again.
If I disable telemetry the bluetooth works fine even when naze is armed.

No problem with this behavior if it's by design, I'm just acknowledging it.

whakahere · Post by **whakahere** » Wed Feb 05, 2014 11:00 pm

Is there anyway to add a current sensor (tbs 100amp) to a naze acro and minimosd (kvosd board)?

I have some kypom battery that hold there voltage right to the end. It means watching the volts isn't very effective.

teslahed · Post by **teslahed** » Sat Feb 08, 2014 4:08 pm

Timecop will love this question :lol:

Short answer - no. Long answer - if someone else can come up with a suggestion here i'm all ears.

A work around solution;

I am using a minimOSD running the team KV OSD firmware with my Naze32. You can use a current sensor directly with the minimOSD if you mod the pins correctly. The next firmware update (2.3) for the team KV OSD will include new features that will make the current sensor work much better, or so i hear.

https://code.google.com/p/rush-osd-development/

So if you want the current sensor for FPV flights ignore the Naze and go straight to the minimOSD. It'll be easier.

ccsj · Post by **ccsj** » Sat Feb 08, 2014 7:00 pm

I've been flying my NAZE32 rev5 for a month and it's been working fine for me. Yesterday, it just stopped working. When I try to turn it on (USB to computer or flight pack), only the blue LED turns on and it did not go through the unual LED/buzzer sequence. I measured and verified that 3.3v on the board is still there. I tried shorting bootload pins and flashing baseflight fw and baseflight confirms that the flashing was done successfully. However, it did not fix the problem. Is my board dead or is there anything else I should try?

timecop · Post by **timecop** » Sun Feb 09, 2014 3:52 am

You fried the stm32, nothing else to do about it.

ccsj · Post by **ccsj** » Sun Feb 09, 2014 4:24 am

Fried in a month. That's disappointing. I hope that this is an isolated case and my new one doesn't get fried in a month as well. I put my new acro naze into the same hex. Is there anything I should check to make sure it's not my set up that caused it to fry?

timecop · Post by **timecop** » Sun Feb 09, 2014 4:37 am

I still have no idea what does it - I have yet to fry any of my boards but there's a steady stream of people managing to fuck it up. My guess is that they somehow manage to get 5V into non-5V-tolerant pins - which fries the mcu.

The only way that can really happen is if something gets powered before the FC - like receiver running off separate BEC or something, but there's resistor arrays to protect against this crap in rev5, so I have no idea what people do.

What is your setup and what did you do when it stopped working?

ccsj · Post by **ccsj** » Sun Feb 09, 2014 5:11 am

Yes. Looks like I’m one of those fuckers who manages to fuck up the Naze. It got fried the night I added the HK EOSD to the hex. My FPV gear runs of the filter output. I simply solder additional connector onto the LC filter to accommodate the OSD. After I’m done with OSD installation, I plug flight battery and that’s when I notice no start up sequence beeping. This was my old OSD that works before. I tried plugging in my spare acro naze to USB and that starts up fine so I swap out the fucked up NAZE32 with ACRO NAZE and it starts up with flight battery. Then I proceed to configure the ACRO NAZE and now it flies fine with it. I don’t use BEC in my set up. I noticed thought that on the day before it fried, the telemetry VBAT was giving bogus value intermitently (<10V) - that's why I added the OSD back in. With ACRO NAZE set up, so far OSD is solid. I turned off telemetry warning.

Blackout mini hex
SS2204 2300KV motors
12A ESC simonk 9-30-12
Single 3S battery set up
Frsky D4RII PPM
buzzer
Naze had PPM enabled, VBAT, telemetry, HEX6X, gimbal flag = 4, all PIDs, throttle setting left at default
SC2000 PZ camera
LC filter
808#16D
600mw immersion vtx

rortega · Post by **rortega** » Sun Feb 09, 2014 10:13 am

Timecop, I have a question about developing. Doy you use Keil uVision IDE or Eclipse itself, or eclipse with the plugin for working with uvproj projects? I need the PSN serial number of a product to get the license needed to be able to compile more than 32kb from uVision IDE. What kind of product? One ARM procesor for example?

I know how to compile from command line or eclipse with GNU tool chains for ARM (I'm a Linux user, but the baseflight master repository in github is commited as a uvproject, so every thing would be easier if I have a fully functional keil uVision IDE.

Any suggestion? Thanks.

timecop · Post by **timecop** » Sun Feb 09, 2014 10:24 am

I use non-demo keil. the makefile is for building from command line, you can use it to create a "makefile-based" eclipse project and bulid this way.

cheapest keil lic around $3k, you probably don't want to do that for hobby development.

you might be able to have out-of-the-box debugging using coocox IDE and the bundled makefile.

Adicakes · Post by **Adicakes** » Sun Feb 09, 2014 11:00 am

Hi everyone,

Having some troubles with channel forwarding and an RX-controlled switch.

I'm using CPPM and Naze32 on a tricopter. I've got gimbal_flags=4 set, and a receiver-controlled switch (for a headlamp) with its signal line connected to the pin for channel 6 when forwarding is enabled. The transmitter side is setup properly and if I flick the switch position, I can see the signal level for Aux2 change in the Baseflight "Receiver" tab. However, the lamp is stuck on and the switch has no effect.

I've tried this setup on two quadcopters before and it worked fine, so I suspect it might be something to do with the Naze32 being in servo mode (tricopter). Any ideas?

Cheers,
A.

timecop · Post by **timecop** » Sun Feb 09, 2014 11:34 am

are you running latest fw.
there was some servo offset fix lately.
but I think that was for planes only.