Naze32 hardware discussion thread

strips · Post by **strips** » Fri May 09, 2014 8:11 am

kaysee wrote:Hi guys. I have this one acronaze32 which only have the blue led lights up when powered.
It worked until i flashed it with latest firmware while forgetting to unplug the lipo from my quad. The flashing process started just fine, then i remember the lipo as the motors making some beeping sound and disconnect the battery. The process ended with stm32 timeout. and i no longer can connect to baseflight conf and only the blue led lights up once the board gets power. No initialization sequence.

What could be wrong? Can it be recover?

http://www.youtube.com/watch?v=cRE83-tmN-U

Just to confirm. Did you unplug the battery while the flashing was in progress? If so it sounds like recipe for disaster.

Have you tried re-flash with boot loader pins shorted? The procedure is covered in the manual.

kaysee · Post by **kaysee** » Fri May 09, 2014 8:17 am

strips wrote:
kaysee wrote:Hi guys. I have this one acronaze32 which only have the blue led lights up when powered.
It worked until i flashed it with latest firmware while forgetting to unplug the lipo from my quad. The flashing process started just fine, then i remember the lipo as the motors making some beeping sound and disconnect the battery. The process ended with stm32 timeout. and i no longer can connect to baseflight conf and only the blue led lights up once the board gets power. No initialization sequence.

What could be wrong? Can it be recover?

http://www.youtube.com/watch?v=cRE83-tmN-U

Just to confirm. Did you unplug the battery while the flashing was in progress? If so it sounds like recipe for disaster.

Have you tried re-flash with boot loader pins shorted? The procedure is covered in the manual.

Unfortunately, yes i did unplugged the bty while flashing. Tried re-flashed with the boot loader shorted with no success.

fancyfoam · Post by **fancyfoam** » Fri May 09, 2014 10:21 am

I have been fighting the GPS on my quad and finally figured it out. I got the GPS working and then to make the USB port easy to get to I rotated the board 90deg and set the align_board_yaw to match. It flew fine but would just do increasingly sized circles when in GPS_hold or go in the wrong direction in GPS_hold. I took several days to connect the dots but today I put the board back in the stock orientation and set the alignment to 0. Now the GPS features are working correctly again.
It appears that the GPS code is not paying attention to the board alignment in the CLI.
Is there a thread for possible bugs that I can submit this to?
Thanks.
Mike

e_lm_70 · Post by **e_lm_70** » Fri May 09, 2014 10:50 am

fancyfoam wrote:I have been fighting the GPS on my quad and finally figured it out. I got the GPS working and then to make the USB port easy to get to I rotated the board 90deg and set the align_board_yaw to match. It flew fine but would just do increasingly sized circles when in GPS_hold or go in the wrong direction in GPS_hold. I took several days to connect the dots but today I put the board back in the stock orientation and set the alignment to 0. Now the GPS features are working correctly again.
It appears that the GPS code is not paying attention to the board alignment in the CLI.
Is there a thread for possible bugs that I can submit this to?
Thanks.
Mike

This sound very very strange to me.

GPS code does use the heading information and not the raw data from the sensors .. as long the heading is reported correctly on the GUI (I use MultiWii Java 2.3 GUI, that is dummy proof) ... if don't see how it is possible to have such macro error in the firmware.

I suspect that you did only rotate the ACC-Gyro in the CLI but not the MAG ... and you possibly never check the GUI and never really used the MAG feature before.
If the heading after the Mag calibration is showing in the correct position (you need to know where is the real North) .. then the MAG has been properly set up on the CLI.

I'm using a custom 10DOF with a MAG in a different orientation then the ACC, compared to the Naze32 schematic ... if what you are saying is correct, I should fail my GPS experiments ... but ... I'm confident it will not happen.

fancyfoam · Post by **fancyfoam** » Fri May 09, 2014 12:10 pm

In baseflight they did away with the compass but thevmodel that repersents the quad faces away from me when the quad is pointed north. This is for either board orientation when the align_board_yaw is properly set. When i get home i will look through the cli set variables for a value related to the mag.
Mike

KC_703 · Post by **KC_703** » Fri May 09, 2014 5:33 pm

DId you re-calibrate the Mag after rotating the board? It could be confused.

fancyfoam · Post by **fancyfoam** » Fri May 09, 2014 7:16 pm

Yes, several times to make sure.
Mike

turdsurfer · Post by **turdsurfer** » Sat May 10, 2014 2:58 am

A quick question as I RTFM but couldn't FTFA:
Is it possible to attach an external magnetometer such as the HMC5983 to the Naze32 board (using sda scl pads) and if so, what do I need to do to disable the onboard magnetometer and do I need to change some lines in the source code too?
I'm asking this because I'm bound to get too much interference on the onboard magnetometer with the Naze32 so close to the PDB in my setup (and most setups).
I want to set my failsafe to GPS hold because where I fly (around rocks over water), it's especially important that it doesn't toilet bowl or go wonky if I get a failsafe.

e_lm_70 · Post by **e_lm_70** » Sat May 10, 2014 7:09 am

turdsurfer wrote:A quick question as I RTFM but couldn't FTFA:
Is it possible to attach an external magnetometer such as the HMC5983 to the Naze32 board (using sda scl pads) and if so, what do I need to do to disable the onboard magnetometer and do I need to change some lines in the source code too?
I'm asking this because I'm bound to get too much interference on the onboard magnetometer with the Naze32 so close to the PDB in my setup (and most setups).
I want to set my failsafe to GPS hold because where I fly (around rocks over water), it's especially important that it doesn't toilet bowl or go wonky if I get a failsafe.

It is looking more a baseflight question then not a Naze32 one

Baseflight support i2c soft, so even assuming the worst that on board 5883 can't be disabled, you can still use an external one over i2c soft without interferences (if 5883 is connected only via 6050, then it can be disabled by firmware)

About failsafe, again, this is baseflight issue, currently failsafe is quite poor in baseflight, weak failure detection, and weak engage of stability, slow descend and disarm

I would suggest to go in deep with the experts on the baseflight thread

timecop · Post by **timecop** » Sat May 10, 2014 8:01 am

External mag is not supported, this rig is not for pro commercial AP;
failsafe has been fixed in ~recent firmware and 'failsafe_threshold' or so should work as documented.

ABL · Post by **ABL** » Sat May 10, 2014 9:24 am

timecop wrote:External mag is not supported, this rig is not for pro commercial AP;

...and in case you want to go unsupported way: cut SDA trace on board and attach external mag. Done that several times, works fine. But unsupported - and you can easily kill your board while cutting thin traces...

turdsurfer · Post by **turdsurfer** » Sat May 10, 2014 4:03 pm

timecop wrote:External mag is not supported, this rig is not for pro commercial AP;
failsafe has been fixed in ~recent firmware and 'failsafe_threshold' or so should work as documented.

Thanks for the info. That's a pity, because I think a "pro commercial AP" pilot needs failsafe handling (GPS hold, or RTH) much less than a sport flyer like me that flies like crazy in the mountains, behind rocks and over water, sometimes accidently going out of LOS.

leocopter · Post by **leocopter** » Sat May 10, 2014 10:22 pm

ABL wrote:
timecop wrote:External mag is not supported, this rig is not for pro commercial AP;

...and in case you want to go unsupported way: cut SDA trace on board and attach external mag. Done that several times, works fine. But unsupported - and you can easily kill your board while cutting thin traces...

... or get an AcroNaze and solder your I2C sensors on it (sda and scl pads underneath the board. 3.3 V accessible on top). Then connect your external GPS+MAG board (and why not a BMP180 Baro ... not as good as the MS5611, but only 3$ ...).

theailer · Post by **theailer** » Sun May 11, 2014 12:03 am

I've busted a whole lotta nazes recently, and the one thing I can think of that's fracking them up is that I'm powering them from my rx.
Would it be possible to destroy them this way ? Some nazes lost signal out on random motor outputs, and the last one worked but all of a sudden all control went crazy and then the leds on the board died.
Have one afro mini that worked perfect on the computer with ftdi, but when I connected it to my rx it got hot and now I can't even connect to it.

timecop · Post by **timecop** » Sun May 11, 2014 5:23 am

You're powering somethin up with 5V before naze gets power, that/'s a no-no.

theailer · Post by **theailer** » Sun May 11, 2014 9:13 am

Ah crap. Wish I knew that before

I've seen others having problems with it but never really reflected upon it. Damn..

theailer · Post by **theailer** » Sun May 11, 2014 11:10 am

Smoked another one. Guessing that my bec outputting 5.3V has something to do with it

HFMan · Post by **HFMan** » Mon May 12, 2014 2:36 pm

BEC output of 5.3V shouldn't cause it- my BEC outputs 5.5V and no issues- the regulator on the Naze32 should easily be able to handle that.

Are you powering anything off the Naze32 3.3V rail? Are you using 5V devices on the I2C bus? Any 5V inputs on the 3.3V GPIO pad or 3.3V ADC pad?

e_lm_70 · Post by **e_lm_70** » Mon May 12, 2014 3:56 pm

HFMan wrote:BEC output of 5.3V shouldn't cause it- my BEC outputs 5.5V and no issues- the regulator on the Naze32 should easily be able to handle that.

Are you powering anything off the Naze32 3.3V rail? Are you using 5V devices on the I2C bus? Any 5V inputs on the 3.3V GPIO pad or 3.3V ADC pad?

Differently then other "MultiWii" boards, on Naze32 everything run at 3.3v ... there is a voltage regulator that convert a "wide" range of input voltage into 3.3v for feed sensors and CPU.

The big risk is to expose 5v to any of the PIN of the STM32 that are not 5v tolerant.

On ATmega MutlWii baord ... the sensors runs at 3.3v but normally the CPU is running at 5v.

I2C bus must have 3.3v pull up, and not 5v .. else it could be quite dangerous (@ 5v it does depend from the pull up resistance used, but still , it is an unnecessary gamble to use 5v i2c)
External i2c sensors should be power at 3.3v only.

rank · Post by **rank** » Mon May 12, 2014 4:18 pm

I vote for external mag option, no idea why the developer is so stubborn, why to fight with the customers?!

bicycle · Post by **bicycle** » Mon May 12, 2014 4:30 pm

Look no further than DJI NAZA v2, the external mag has proven reliability in all situations.

theailer · Post by **theailer** » Mon May 12, 2014 4:42 pm

HFMan wrote:BEC output of 5.3V shouldn't cause it- my BEC outputs 5.5V and no issues- the regulator on the Naze32 should easily be able to handle that.

Are you powering anything off the Naze32 3.3V rail? Are you using 5V devices on the I2C bus? Any 5V inputs on the 3.3V GPIO pad or 3.3V ADC pad?

I have a ublox GPS connected to channel 3 and 4 and a mininosd to tx and Rx pins, could it be the GPS that's messing it up? I'm powering both the minim and the GPS of a seperate bec.

timecop · Post by **timecop** » Mon May 12, 2014 4:46 pm

uh, yes...
serial pins on minim are 5V, right? and if that shit powers up before 3.3V power to naze, there will be smoke

e_lm_70 · Post by **e_lm_70** » Mon May 12, 2014 5:08 pm

rank wrote:I vote for external mag option, no idea why the developer is so stubborn, why to fight with the customers?!

Baseflight the firmware used by Naze32 has already soft i2c implementation inside ... that means even if the mag is on board and in the i2c bus ... still using PPM you have enough free pin for use soft i2c from baseflight for support an external mag.

If you push (nicely) this requirement in the Baseflight thread, this may happen faster.

But the fact that Baseflight has already the i2c soft .. should say everything opposite about be "stubborn"

For skilled people owning a hot air soldering gun (I have no skills, but I got my "hot gun" for 59$ shipped from china) ... remove the 5883 on board , and connect an external 5883 module (less then 2$ from eBay) .. it is quite simple. I did manage with my limited skills and my un-steady hands to remove a 328 chip from a useless board, and place it on my defected OpenLRS TX module ... now my OpenLRS module is back fully functional

... remove a SMD component with a "hot gun" is very very easy ... still I do suggest only to people that love to take the extra risk.

e_lm_70 · Post by **e_lm_70** » Mon May 12, 2014 5:14 pm

timecop wrote:uh, yes...
serial pins on minim are 5V, right? and if that shit powers up before 3.3V power to naze, there will be smoke

I have a dummy question ...

Normally GPS module have a core that internally work at 3.3v or even less. So normally 5v GPS modules have a voltage regulator down to 3.3v.

Do you know if these GPS module (in general, like the cheap NEO6 from eBay for 16$) have some voltage converter for speak with external world over the 5v serial interface ?
Sometime it is just enough some resistor in line with TX and RX ... and 3.3v serial speak nicely with another 5.v serial

Just for be on safe side ... 3.3v GPS module are less common ... still I have one somewhere in my mess ... so .. possibly I will use this one for my "Naze32" experiments.

Thanks

HFMan · Post by **HFMan** » Mon May 12, 2014 5:18 pm

timecop wrote:uh, yes...
serial pins on minim are 5V, right? and if that shit powers up before 3.3V power to naze, there will be smoke

Yes- this is an interesting question. How is it that the Naze32 doesn't smoke if they are powered up at the same time? The serial output is still 5V on the minimOSD, right?

KC_703 · Post by **KC_703** » Mon May 12, 2014 6:31 pm

e_lm_70 wrote:
timecop wrote:uh, yes...
serial pins on minim are 5V, right? and if that shit powers up before 3.3V power to naze, there will be smoke

I have a dummy question ...

Normally GPS module have a core that internally work at 3.3v or even less. So normally 5v GPS modules have a voltage regulator down to 3.3v.

Do you know if these GPS module (in general, like the cheap NEO6 from eBay for 16$) have some voltage converter for speak with external world over the 5v serial interface ?
Sometime it is just enough some resistor in line with TX and RX ... and 3.3v serial speak nicely with another 5.v serial

Just for be on safe side ... 3.3v GPS module are less common ... still I have one somewhere in my mess ... so .. possibly I will use this one for my "Naze32" experiments.

Thanks

The ublox 6M (RTFQ house) I have takes 5V on the Vcc, but there is also a lead for 3.3v. So there probably is a voltage converter somewhere.

Not sure of the eBay items, but if its not specifically mentioned, it would be a gamble.

theailer · Post by **theailer** » Mon May 12, 2014 7:48 pm

Ok, i measured 3v across the esc's signal and ground. Is that normal ? None of my other esc's do that.

deleted · Post by **deleted** » Tue May 13, 2014 12:23 am

I am after some help getting my Naze32 acro rev 5 board to connect to baseflight configurator and flash the firmware. This is my 4th Naze32 board so im not sure why this one is giving me grief.

On Timecop's advice I have unchecked the Auto-connect in Baseflight Configurator, shorted the bootloader pins on the board, connected USB, then checked no reboot sequence and clicked on flash firmware.
The board boots with a blue led (when shorted) and when I click flash firmware I get a error message instantly saying "STM32 - Timed out, programming : FAILED".

I have the VCP drivers installed correctly as my other rev5 board connects fine to baseflight configurator.

I have also tried the old method of using the ST Flash loader and get a message saying "Unrecognised device, please reset your device and try again".

Any suggestions?

Thanks

deleted · Post by **deleted** » Tue May 13, 2014 12:38 am

Hmm I think I might have worked out what the problem is. There is a blob of solder on the legs of the STM32 chip (top side of board).

I'm not at home at the moment to test if cleaning this up will fix up the issue or if the board is toast now.

timecop · Post by **timecop** » Tue May 13, 2014 1:01 am

How did it make it on there? Because non-flashable board would have been noticed when I was flashing it, and solder (if any) removed.

deleted · Post by **deleted** » Tue May 13, 2014 1:05 am

timecop wrote:How did it make it on there? Because non-flashable board would have been noticed when I was flashing it, and solder (if any) removed.

Not sure mate but I accept it could have somehow got there when I was soldering the pins to the board. I will try and remove the solder tonight and see if the board survives. Else I will have to order a new one. Thanks for your help.

Truglodite · Post by **Truglodite** » Tue May 13, 2014 6:24 am

e_lm_70 wrote:
rank wrote:For skilled people owning a hot air soldering gun (I have no skills, but I got my "hot gun" for 59$ shipped from china) ... remove the 5883 on board , and connect an external 5883 module (less then 2$ from eBay) .. it is quite simple. I did manage with my limited skills and my un-steady hands to remove a 328 chip from a useless board, and place it on my defected OpenLRS TX module ... now my OpenLRS module is back fully functional ... remove a SMD component with a "hot gun" is very very easy ... still I do suggest only to people that love to take the extra risk.

On installs that require it, I usually just cut the SDA trace to disable onboard 5883s (can be done on many popular FCs). However I haven't had to do that on my Naze32s, yet. I'm guessing with v5 it would go something like this, no?

compassDisable.jpg: (47.09 KiB) Not downloaded yet

Now I love reworking and have replaced dead 328's and even 7456's, but slicing the trace is so much easier... and cutting those traces preserves the 5883's until I get an old toaster oven to prebake stuff.

Kev

rank · Post by **rank** » Tue May 13, 2014 6:54 am

Truglodite wrote:
e_lm_70 wrote:
rank wrote:For skilled people owning a hot air soldering gun (I have no skills, but I got my "hot gun" for 59$ shipped from china) ... remove the 5883 on board , and connect an external 5883 module (less then 2$ from eBay) .. it is quite simple. I did manage with my limited skills and my un-steady hands to remove a 328 chip from a useless board, and place it on my defected OpenLRS TX module ... now my OpenLRS module is back fully functional ... remove a SMD component with a "hot gun" is very very easy ... still I do suggest only to people that love to take the extra risk.

On installs that require it, I usually just cut the SDA trace to disable onboard 5883s (can be done on many popular FCs). However I haven't had to do that on my Naze32s, yet. I'm guessing with v5 it would go something like this, no?
compassDisable.jpg

Now I love reworking and have replaced dead 328's and even 7456's, but slicing the trace is so much easier... and cutting those traces preserves the 5883's until I get an old toaster oven to prebake stuff.

Kev

Would be great if someone with the knowledge could do a small guide, from cutting the trace to modifying the code and enabling the external mag. To all those folks with "Go get Naza" attitude, I have one on my quad, but this will be used on my large tricopter.

e_lm_70 · Post by **e_lm_70** » Tue May 13, 2014 7:56 am

Truglodite wrote:
e_lm_70 wrote:
rank wrote:For skilled people owning a hot air soldering gun (I have no skills, but I got my "hot gun" for 59$ shipped from china) ... remove the 5883 on board , and connect an external 5883 module (less then 2$ from eBay) .. it is quite simple. I did manage with my limited skills and my un-steady hands to remove a 328 chip from a useless board, and place it on my defected OpenLRS TX module ... now my OpenLRS module is back fully functional ... remove a SMD component with a "hot gun" is very very easy ... still I do suggest only to people that love to take the extra risk.

On installs that require it, I usually just cut the SDA trace to disable onboard 5883s (can be done on many popular FCs). However I haven't had to do that on my Naze32s, yet. I'm guessing with v5 it would go something like this, no?
compassDisable.jpg

Now I love reworking and have replaced dead 328's and even 7456's, but slicing the trace is so much easier... and cutting those traces preserves the 5883's until I get an old toaster oven to prebake stuff.

Kev

Strange approach.

In the name of saving a 5883 chip that has 1$ value ... you would cut a trace of a board that cost 50$. There it no way to fix back a trace that get a cut, at least, not in a easy way ... not without some "nano soldering skills"

Dilbert66 · Post by **Dilbert66** » Tue May 13, 2014 10:55 am

e_lm_70 is correct, the 5883 can be disabled in firmware by turning off the 6050 i2c bypass in drv_6050.c here by removing the I2C_BYPASS_EN bit control and recompiling. I assume that Its not a cli control option cause I don't know anyone else that needs to do this on the fly so noone wanted to waste time doing it. I guess this is not an option for those that can't compile their own code but it's definitively a possibility.

i2cWrite(MPU6050_ADDRESS, MPU_RA_INT_PIN_CFG, 0 << 7 | 0 << 6 | 0 << 5 | 0 << 4 | 0 << 3 | 0 << 2 | 1 << 1 | 0 << 0); // INT_PIN_CFG -- INT_LEVEL_HIGH, INT_OPEN_DIS, LATCH_INT_DIS, INT_RD_CLEAR_DIS, FSYNC_INT_LEVEL_HIGH, FSYNC_INT_DIS, I2C_BYPASS_EN, CLOCK_DIS

e_lm_70 · Post by **e_lm_70** » Tue May 13, 2014 12:22 pm

Dilbert66 wrote:e_lm_70 is correct, the 5883 can be disabled in firmware by turning off the 6050 i2c bypass in drv_6050.c here by removing the I2C_BYPASS_EN bit control and recompiling. I assume that Its not a cli control option cause I don't know anyone else that needs to do this on the fly so noone wanted to waste time doing it. I guess this is not an option for those that can't compile their own code but it's definitively a possibility.

i2cWrite(MPU6050_ADDRESS, MPU_RA_INT_PIN_CFG, 0 << 7 | 0 << 6 | 0 << 5 | 0 << 4 | 0 << 3 | 0 << 2 | 1 << 1 | 0 << 0); // INT_PIN_CFG -- INT_LEVEL_HIGH, INT_OPEN_DIS, LATCH_INT_DIS, INT_RD_CLEAR_DIS, FSYNC_INT_LEVEL_HIGH, FSYNC_INT_DIS, I2C_BYPASS_EN, CLOCK_DIS

Thanks Dilbert66

I know that some boards have 5883 connected only to the 6050, but some other have the 5883 on the main i2c bus.
Good to know that Naze32 has the "clean" design, with the 5883 connected only to the 6050,so it can be disable by firmware.

For my experience it is not enough to just remove the 6050 i2ci bypass command at boot up, since the last previous configuration is stored in the 6050. So it is needed to tell the 6050 to disable the i2c bypass, only once ... then on next power up this configuration will be known already by the 6050

Baseflight as anyhow the i2c soft option (under development if I got it right) ... this can be another solution.

deleted · Post by **deleted** » Tue May 13, 2014 12:28 pm

deleted wrote:
timecop wrote:How did it make it on there? Because non-flashable board would have been noticed when I was flashing it, and solder (if any) removed.

Not sure mate but I accept it could have somehow got there when I was soldering the pins to the board. I will try and remove the solder tonight and see if the board survives. Else I will have to order a new one. Thanks for your help.

After cleaning the STM32 chip up it looks to be connecting fine! The flashing of the firmware still only works if I short the boot loader pins but at least it is now flashed and connects to baseflight configurator. The gyros and the acc seem to be displaying correctly in the Raw Sensor Data so hopefully it is all good now.

timecop · Post by **timecop** » Tue May 13, 2014 1:59 pm

Dilbert66 wrote:e_lm_70 is correct, the 5883 can be disabled in firmware by turning off the 6050 i2c bypass in drv_6050.c here by removing the I2C_BYPASS_EN bit control and recompiling. I assume that Its not a cli control option cause I don't know anyone else that needs to do this on the fly so noone wanted to waste time doing it. I guess this is not an option for those that can't compile their own code but it's definitively a possibility.

i2cWrite(MPU6050_ADDRESS, MPU_RA_INT_PIN_CFG, 0 << 7 | 0 << 6 | 0 << 5 | 0 << 4 | 0 << 3 | 0 << 2 | 1 << 1 | 0 << 0); // INT_PIN_CFG -- INT_LEVEL_HIGH, INT_OPEN_DIS, LATCH_INT_DIS, INT_RD_CLEAR_DIS, FSYNC_INT_LEVEL_HIGH, FSYNC_INT_DIS, I2C_BYPASS_EN, CLOCK_DIS

compass is not behind i2c_bypass of mpu6050, no idea where you got that from.

e_lm_70 · Post by **e_lm_70** » Tue May 13, 2014 2:14 pm

timecop wrote:
Dilbert66 wrote:e_lm_70 is correct, the 5883 can be disabled in firmware by turning off the 6050 i2c bypass in drv_6050.c here by removing the I2C_BYPASS_EN bit control and recompiling. I assume that Its not a cli control option cause I don't know anyone else that needs to do this on the fly so noone wanted to waste time doing it. I guess this is not an option for those that can't compile their own code but it's definitively a possibility.

i2cWrite(MPU6050_ADDRESS, MPU_RA_INT_PIN_CFG, 0 << 7 | 0 << 6 | 0 << 5 | 0 << 4 | 0 << 3 | 0 << 2 | 1 << 1 | 0 << 0); // INT_PIN_CFG -- INT_LEVEL_HIGH, INT_OPEN_DIS, LATCH_INT_DIS, INT_RD_CLEAR_DIS, FSYNC_INT_LEVEL_HIGH, FSYNC_INT_DIS, I2C_BYPASS_EN, CLOCK_DIS

compass is not behind i2c_bypass of mpu6050, no idea where you got that from.

I was about to come here ... for comment that per the schema of rev4 ... it is clear that the secondary i2c line of 6050 it is not used, so 5883 is in the main i2c bus.
But I see you have been faster then me.

Still soft i2c option is or can be available ... baseflight has "something" already about it.

ps: Why for rev5 there is no schema available ? Cloners will not have much problem to analyze a rev5 board and the source code, for make a clone.

disq · Post by **disq** » Tue May 13, 2014 2:19 pm

e_lm_70 wrote:ps: Why for rev5 there is no schema available ? Cloners will not have much problem to analyze a rev5 board and the source code, for make a clone.

Our cloners are lazy. Smart ones don't clone cheap stuff in the first place anyway

Dilbert66 · Post by **Dilbert66** » Tue May 13, 2014 2:30 pm

timecop wrote:
Dilbert66 wrote:e_lm_70 is correct, the 5883 can be disabled in firmware by turning off the 6050 i2c bypass in drv_6050.c here by removing the I2C_BYPASS_EN bit control and recompiling. I assume that Its not a cli control option cause I don't know anyone else that needs to do this on the fly so noone wanted to waste time doing it. I guess this is not an option for those that can't compile their own code but it's definitively a possibility.

i2cWrite(MPU6050_ADDRESS, MPU_RA_INT_PIN_CFG, 0 << 7 | 0 << 6 | 0 << 5 | 0 << 4 | 0 << 3 | 0 << 2 | 1 << 1 | 0 << 0); // INT_PIN_CFG -- INT_LEVEL_HIGH, INT_OPEN_DIS, LATCH_INT_DIS, INT_RD_CLEAR_DIS, FSYNC_INT_LEVEL_HIGH, FSYNC_INT_DIS, I2C_BYPASS_EN, CLOCK_DIS

compass is not behind i2c_bypass of mpu6050, no idea where you got that from.

Whups, my bad I got naze confused with the gy86 that I've been playing with which is setup that way. Posted before I looked at the rev4 sche.atic. My mistake

scrat · Post by **scrat** » Tue May 13, 2014 4:38 pm

theailer wrote:
HFMan wrote:BEC output of 5.3V shouldn't cause it- my BEC outputs 5.5V and no issues- the regulator on the Naze32 should easily be able to handle that.

Are you powering anything off the Naze32 3.3V rail? Are you using 5V devices on the I2C bus? Any 5V inputs on the 3.3V GPIO pad or 3.3V ADC pad?

I have a ublox GPS connected to channel 3 and 4 and a mininosd to tx and Rx pins, could it be the GPS that's messing it up? I'm powering both the minim and the GPS of a seperate bec.

I have GPS connected to channel 3 and 4 and I'm powering GPS from 6th motor pin and from 5th motor pin I'm powering minimosd. No problem at all. So throw away external BEC if you're using quadcopter.

theailer · Post by **theailer** » Tue May 13, 2014 6:39 pm

It's on a plank. I had a servo gone bad so I'm hoping that was the culprit, can a servo brick a naze if it's only connected to it with the signal pin?

cosmic2112 · Post by **cosmic2112** » Thu May 15, 2014 1:25 pm

Quick question:-

when are you expecting more of the Acro Naze 32 in stock?

thanks

scrat · Post by **scrat** » Thu May 15, 2014 1:37 pm

OUT OF STOCK, ETA 05/19/2014

- http://abusemark.com/store/index.php?ma ... 3ejo9v51p4

cosmic2112 · Post by **cosmic2112** » Thu May 15, 2014 2:18 pm

scrat wrote:OUT OF STOCK, ETA 05/19/2014

- http://abusemark.com/store/index.php?ma ... 3ejo9v51p4

Thanks, doh! I see it now..

Servicehans · Post by **Servicehans** » Fri May 16, 2014 12:48 am

Hello,

I have a problem with my new rev5 acro naze. When i plug the usb cable in, the naze shows a solid blue light(power). There is no initialization (blinking of other leds). Its a brand-new Naze. All I have done was soldering the pinheaders.
When i tried updating the firmware via baseflight gui it said: "STM32 timed out, programming : FAILED.
I have tried pushing new firmware onto the naze with Flash Loader Demo, but it said: "cannot find device in bootloader mode" or something similar.
Shorting the Bootloader Pin does not change anything, only the blue led stays on.

It seems like everything it does is power the blue led. Anyone have an idea? Thanks
JP

deleted · Post by **deleted** » Fri May 16, 2014 12:54 am

Servicehans wrote:Hello,

I have a problem with my new rev5 acro naze. When i plug the usb cable in, the naze shows a solid blue light(power). There is no initialization (blinking of other leds). Its a brand-new Naze. All I have done was soldering the pinheaders.
When i tried updating the firmware via baseflight gui it said: "STM32 timed out, programming : FAILED.
I have tried pushing new firmware onto the naze with Flash Loader Demo, but it said: "cannot find device in bootloader mode" or something similar.
Shorting the Bootloader Pin does not change anything, only the blue led stays on.

It seems like everything it does is power the blue led. Anyone have an idea? Thanks
JP

I had the same issue (see a few post earlier). My issue turned out to be a bit of solder on the STM32 pins. You should try shorting out the bootloader pins and flashing the firmware first.

"On Timecop's advice I have unchecked the Auto-connect in Baseflight Configurator, shorted the bootloader pins on the board, connected USB, then checked no reboot sequence and clicked on flash firmware. "

Good luck!

Servicehans · Post by **Servicehans** » Fri May 16, 2014 10:43 pm

I had the same issue (see a few post earlier). My issue turned out to be a bit of solder on the STM32 pins. You should try shorting out the bootloader pins and flashing the firmware first.

"On Timecop's advice I have unchecked the Auto-connect in Baseflight Configurator, shorted the bootloader pins on the board, connected USB, then checked no reboot sequence and clicked on flash firmware. "

Good luck!

It worked. After the 20th time trying to get the bootloader pins shorted it worked. it seems a 2 pinheaders and a bind plug do not make a good connection. Thanks anyways.
One last thing. In the baseflight configurator(google chrome) the initial setup and the motor/servo page stay blank. On my rev3 naze it works? Is it a problem with the rev5?

JP