Naze32 hardware discussion thread

bassmission · Post by **bassmission** » Wed Sep 17, 2014 1:48 pm

MassiveOverkill wrote:
bassmission wrote:I appear to have damaged the CPPM input on channel 1 of my acro naze r5 board - is there any way to use a CPPM input on one of the other channels (2-8)?

Damaged as in tore the trace off?

Damaged by accidentally touching a live ESC trace on the PDB. Everything appears to be working correctly when I connect to Baseflight but it no longer registers any input from the receiver.
Thought there was a slim chance I could use one of the other inputs for the CPPM signal but can't find any way to configure it...(eg. set PPM channel = 2)

MassiveOverkill · Post by **MassiveOverkill** » Wed Sep 17, 2014 3:12 pm

That sucks. I've had one board that I thought was toast but turned out to be a cold solder joint (hard to believe when you have a 5-6mm strip of solder going along the trace.)

Choppermcfly · Post by **Choppermcfly** » Wed Sep 17, 2014 7:39 pm

Hi Im new to this board Naze 32 still waiting for parts for quad but started to configure the boad I connected to baseflight enabled cppm and no ploblems and could see radio inputs set end points in my radio. I have a Bluetooth modual so I thought I would hook it up changed serial baudrate to 9600 to match Bluetooth and connected using Naze 32 configuator ver. 1.49 that is old has not been updated in a year. Everything seemed to work went to cli and had a Java scriped error so I rebooted still can see every thing working in app but cant use cli. But now when i try to use on baseflight I can connect but once I power board with receiver everything locks up. I reflashed 2.3 but still same unable to power up receiver and see inputs to board.

:?:

Can someone here help me where should I look serial port or something.

Vertigo · Post by **Vertigo** » Wed Sep 17, 2014 9:18 pm

DO you guys figure its possible to damage, without destroying, the gyro's in a crash? I already explainedI had one quad that would violently overcorrect in acro mode. that seems to have been solved by installing another naze controller and another firmware, havent yet figured out which of both actually cured it, but now Im inclined to think its the board that was damaged. Bear with me:

Both quads fly okay in angle and horizon mode. Thats the weid part. Its only in acro (manual/gyro/). Now after a crash (I assume, cant think of anything else that changed), the second quad will pitch significantly for no reason. Much more slowly than the first quad, on this one, its over a period of a few seconds, so you can counter it, but to keep the nose in position, at times I need to apply almost full forward stick. While flying forward, If I center the stick, it will very frequently pitch back towards level, then beyond level, then to level again. Its baffling, almost as if its in some horizon like flight mode (its not).

I did a quick sanity check of the gyro outputs in baseflight, and it appeared normal, though I may have to look more closely later. The fact my first quad showed the same symptons, only much more violently, and it was cured by swapping out the board (and another firmware, but that may not have had any influence, dont know yet), leads to me believe I actually damaged two 2 naze controllers in a similar way that only affects the gyro's. Is that realistic? Are gyro's used at all in angle mode?

TO be clear:
- its not a rx/tx issue, or trimming issue, I double and triple checked that.
- Its not a PID issue, I did a factory reset, and tried P values from 2 to 6, everything changes, but the semi random pitching remains.
- Its not a vibration issue
- CG is spot on.

brm · Post by **brm** » Wed Sep 17, 2014 10:16 pm

Vertigo wrote:DO you guys figure its possible to damage, without destroying, the gyro's in a crash? I already explainedI had one quad that would violently overcorrect in acro mode. that seems to have been solved by installing another naze controller and another firmware, havent yet figured out which of both actually cured it, but now Im inclined to think its the board that was damaged. Bear with me:

Both quads fly okay in angle and horizon mode. Thats the weid part. Its only in acro (manual/gyro/). Now after a crash (I assume, cant think of anything else that changed), the second quad will pitch significantly for no reason. Much more slowly than the first quad, on this one, its over a period of a few seconds, so you can counter it, but to keep the nose in position, at times I need to apply almost full forward stick. While flying forward, If I center the stick, it will very frequently pitch back towards level, then beyond level, then to level again. Its baffling, almost as if its in some horizon like flight mode (its not).

I did a quick sanity check of the gyro outputs in baseflight, and it appeared normal, though I may have to look more closely later. The fact my first quad showed the same symptons, only much more violently, and it was cured by swapping out the board (and another firmware, but that may not have had any influence, dont know yet), leads to me believe I actually damaged two 2 naze controllers in a similar way that only affects the gyro's. Is that realistic? Are gyro's used at all in angle mode?

TO be clear:
- its not a rx/tx issue, or trimming issue, I double and triple checked that.
- Its not a PID issue, I did a factory reset, and tried P values from 2 to 6, everything changes, but the semi random pitching remains.
- Its not a vibration issue
- CG is spot on.

do you have a larger quad?
then install the faulty fc in that quad.
I assume it flies ok.

I measured the gyro & accel variance on various production runs. this differs - in the last production run it is higher.
This is one part of the puzzle.

Spotter6 · Post by **Spotter6** » Thu Sep 18, 2014 4:04 am

@brm, I'm new here. Just offering my experience: MEMS gyros have to be handled with care in production and post production. Collision of packages and ceramic boards during production can compromise silicon beams inside gyros and accelerometers.

Vertigo · Post by **Vertigo** » Thu Sep 18, 2014 8:49 am

Im looking at the raw sensor data tab right now. The X axis is showing a steady 0. The Y axis (which responds to pitch on my quad), is alternating quickly between -0.24 and 0. The Z axis is a steady -0.24. Does that sound about normal? 0.24 degree per second doesnt sound like it would cause problems to me, but what do I know.

WHile moving the quad, the graphs are smooth and while difficult to interpret, they look normal to me.

scrat · Post by **scrat** » Thu Sep 18, 2014 10:48 am

Vertigo wrote:Im looking at the raw sensor data tab right now. The X axis is showing a steady 0. The Y axis (which responds to pitch on my quad), is alternating quickly between -0.24 and 0. The Z axis is a steady -0.24. Does that sound about normal? 0.24 degree per second doesnt sound like it would cause problems to me, but what do I know.

WHile moving the quad, the graphs are smooth and while difficult to interpret, they look normal to me.

I have the same numbers on both of my Naze's.

Spotter6 · Post by **Spotter6** » Thu Sep 18, 2014 12:43 pm

My full Naze wanders too many feet then drifted downwind in GPS Hold mode. I'm trying to make PID adjustment so that it'd hold XY position better. My GPS page shows 7-9 sats inside my house, pretty good reception.

Can you guys confirm which parameters would help it to hold XY position (POS, PosR, not NavR, etc.) ?

Thx in advance.

brm · Post by **brm** » Thu Sep 18, 2014 6:08 pm

Spotter6 wrote:@brm, I'm new here. Just offering my experience: MEMS gyros have to be handled with care in production and post production. Collision of packages and ceramic boards during production can compromise silicon beams inside gyros and accelerometers.

this also what i am told.
i made the experience that the internal lpf filtering works against the outer filtering.
plus on smaller quads the noise on the gyro IS an issue.
for the higher lpf filter settings did work out on my quad.
if not... then it is worser ... might be that board was not handled with the propper care.

Vertigo · Post by **Vertigo** » Thu Sep 18, 2014 7:21 pm

As it turns out, my gyro's are fine. I did another testflight today, with different firmware (cleanflight), different props (5x4 instead of 5x3) and higher Integral values for pitch. And the result was a near flawless quad. Ive not yet determined which of those factors contributed most, but I do notice that each time I switched from baseflight to cleanflight, the problem went away. Ill try to test the same props and PIDs on baseflight later to make sure.

BennyG · Post by **BennyG** » Thu Sep 18, 2014 11:32 pm

Got myself an AfroMini 32 for my first venture into MultiWii. Flown / setup KK2.0 and APM no problems, decided to convert one of my tricopters to see if I like the way it flies better than what I have.

Can't get my servo based tilt gimbal working using tricopter mxing on the Afromini using baseflight.

If I set the mixing to either form of quad, it works fine. If I set the mixing to tri, the options disappear from the servos tab in baseflight and the gimbal no longer works.

I like to fly FPV between the trees; I use a tilt only servo based gimbal so I don't end up looking at the ground and the sky all the time when making aggressive manoevers. I don't want a full gimbal, waaaaay too cumbersome and fragile for a compact high speed tri.

Is this a known issue, or have I missed something? Are servo gimbals supported for tricopters as well as quads?

timecop · Post by **timecop** » Fri Sep 19, 2014 12:49 pm

Tricopter + gimbal is not supported, there's not enough timers to do it.
This is mentioned in the manual, I believe.

BennyG · Post by **BennyG** » Sat Sep 20, 2014 5:45 am

timecop wrote:Tricopter + gimbal is not supported, there's not enough timers to do it.
This is mentioned in the manual, I believe.

Hey, thanks for the quick reply. Re the manual, this is what made me think it might be possible:-

naze32_rev3.pdf wrote:In addition to standalone stabilization, camera outputs can also be enabled when used as a standard multirotor controller. In case of standard receiver, this limits to Quad mixer. In case of CPPM receiver, up to Octo can be supported while still allowing for camera control. Channels AUX3/AUX4 can be assigned to tilt/roll the camera mount in addition to stabilization. See “Serial Console” chapter for more details.

I also noted a conflict on the S1 connection in this bit:-

naze32_rev3.pdf wrote:NOTE In Tri-copter mode, tail tilt servo connects to S1, and motors M1..M3 as shown in Fig 3. Motor connections on the previous page. When camera stabilization is enabled, gimbal pitch/roll servos connect to S1/S2, and motor connectors shift as well.

Maybe I missed the relevant part, but that's all I could find.

The "serial consol" mentions the "cmix" command for "special" layouts. Would it be possible to create a custom mix to get a tilt only gimbal working? One axis only...

I don't care about controlling the camera from my TX, I'm a pilot not a voyeur. Just want the camera to look up / forward when I tilt right over to accelerate hard. If you think there's hope there, any tips on where to learn more about the "cmix" command would be appreciated.

Also curious why a tricopter mix uses more timers than a quad. Am a software developer by day, if I had more understanding of the problem maybe I could contribite to a solution. Do the Atmel processors have more timers? Or did they hack the camera stabilization on tricopter mixing on the KK and APM / do it another way?

minim · Post by **minim** » Sat Sep 20, 2014 6:02 pm

Has anyone seen this bug before? This is with 2.3 firmware. If needed I can get version info from CLI also. The controller is a Naze 32 Acro.

The weird thing is that if I put "ARM" command at centre (1500) of AUX2 both end points are showing correct but the centre is not hitting 1500 like it should. If I remove "ARM" command from centre of AUX2 the centre is showing 1500 each time. If I put "ARM" command at AUX1 it is exactly the same. Sometimes this also locks baseflight so that I just have to disconnect and when I then try to connect again it will not connect before I set the switch away from the "arm" command.

As the youtube link won't work here's a url to youtube directly.
https://www.youtube.com/watch?v=oZ6YMssmI-g

[youtube]https://www.youtube.com/watch?v=oZ6YMssmI-g[/youtube]

timecop · Post by **timecop** » Sun Sep 21, 2014 8:22 am

minim wrote:Has anyone seen this bug before? This is with 2.3 firmware. If needed I can get version info from CLI also. The controller is a Naze 32 Acro.

The weird thing is that if I put "ARM" command at centre (1500) of AUX2 both end points are showing correct but the centre is not hitting 1500 like it should. If I remove "ARM" command from centre of AUX2 the centre is showing 1500 each time. If I put "ARM" command at AUX1 it is exactly the same. Sometimes this also locks baseflight so that I just have to disconnect and when I then try to connect again it will not connect before I set the switch away from the "arm" command.

As the youtube link won't work here's a url to youtube directly.
https://www.youtube.com/watch?v=oZ6YMssmI-g

[youtube]https://www.youtube.com/watch?v=oZ6YMssmI-g[/youtube]

viewtopic.php?f=23&t=5555

timecop · Post by **timecop** » Sun Sep 21, 2014 8:25 am

BennyG wrote:Hey, thanks for the quick reply. Re the manual, this is what made me think it might be possible:-
naze32_rev3.pdf wrote:In addition to standalone stabilization, camera outputs can also be enabled when used as a standard multirotor controller. In case of standard receiver, this limits to Quad mixer. In case of CPPM receiver, up to Octo can be supported while still allowing for camera control. Channels AUX3/AUX4 can be assigned to tilt/roll the camera mount in addition to stabilization. See “Serial Console” chapter for more details.

Yes, tricopter is not mentioned there, because it doesn't work, and

I also noted a conflict on the S1 connection in this bit:-
naze32_rev3.pdf wrote:NOTE In Tri-copter mode, tail tilt servo connects to S1, and motors M1..M3 as shown in Fig 3. Motor connections on the previous page. When camera stabilization is enabled, gimbal pitch/roll servos connect to S1/S2, and motor connectors shift as well.

Maybe I missed the relevant part, but that's all I could find.

That is the relevant part. S1/S2 are used as servos for camstab, but in tricopter mode S1 is used for tail servo.

The "serial consol" mentions the "cmix" command for "special" layouts. Would it be possible to create a custom mix to get a tilt only gimbal working? One axis only...

This is for motor mix only.

I don't care about controlling the camera from my TX, I'm a pilot not a voyeur. Just want the camera to look up / forward when I tilt right over to accelerate hard. If you think there's hope there, any tips on where to learn more about the "cmix" command would be appreciated.

Also curious why a tricopter mix uses more timers than a quad. Am a software developer by day, if I had more understanding of the problem maybe I could contribite to a solution. Do the Atmel processors have more timers? Or did they hack the camera stabilization on tricopter mixing on the KK and APM / do it another way?

Camera stab on tarduino is done with software PWM. Sorry, not going to happen here.
You can hack S2 to output camera roll or tilt stuff in tricopter mode.
Patches welcome.

minim · Post by **minim** » Sun Sep 21, 2014 11:30 pm

timecop wrote:
minim wrote:Has anyone seen this bug before? This is with 2.3 firmware. If needed I can get version info from CLI also. The controller is a Naze 32 Acro.

The weird thing is that if I put "ARM" command at centre (1500) of AUX2 both end points are showing correct but the centre is not hitting 1500 like it should. If I remove "ARM" command from centre of AUX2 the centre is showing 1500 each time. If I put "ARM" command at AUX1 it is exactly the same. Sometimes this also locks baseflight so that I just have to disconnect and when I then try to connect again it will not connect before I set the switch away from the "arm" command.

As the youtube link won't work here's a url to youtube directly.
https://www.youtube.com/watch?v=oZ6YMssmI-g

[youtube]https://www.youtube.com/watch?v=oZ6YMssmI-g[/youtube]

viewtopic.php?f=23&t=5555

Oh, I assume it's fixed then, great

Sorry for the post..

Sidenote.. It would be great if there was something showing what firmware version that is current so it was easy to know if you needed a update or not. I was in the menu with firmware updating yesterday when I had these problems but I did not want to uprade at that time since I was going to fly today and I was not sure if I had to do all my settings over again after a update. Tried to google for what the current firmware version was but I had no luck. When I got time to update the firmware I will test the arm problem again but for now I'm just arming with the sticks ^^

kilby · Post by **kilby** » Sun Sep 21, 2014 11:49 pm

But there is something that shows you what the latest version is.

Go onto the chrome baseflight configuration tool, firmware flasher

Choose Load Firmware [Online], that will show you the latest official and the date it was released

Unfortunately it is in the retarded American date format

timecop · Post by **timecop** » Mon Sep 22, 2014 12:44 am

Or jut type "version" in CLI as the linked post says...

kilby · Post by **kilby** » Mon Sep 22, 2014 8:17 am

He couldn't work out what the current version was

scrat · Post by **scrat** » Mon Sep 22, 2014 9:26 am

kilby wrote:
Unfortunately it is in the retarded American date format

+1

timecop · Post by **timecop** » Mon Sep 22, 2014 9:29 am

MDY is the one and only date format.

41south · Post by **41south** » Mon Sep 22, 2014 9:50 am

timecop wrote:MDY is the one and only date format.

And there are those who say you don't have a sense of humor 8-)

kilby · Post by **kilby** » Mon Sep 22, 2014 10:00 am

timecop wrote:MDY is the one and only date format.

Oh great now there's a fake timecop on the board

uvlight · Post by **uvlight** » Mon Sep 22, 2014 12:08 pm

Just wanna report back, after upgrade to latest firmware (from 2014-08-03 to 2014-08-05) the random pitch that was haunting me is gone. Thanks.

minim · Post by **minim** » Mon Sep 22, 2014 12:38 pm

kilby wrote:But there is something that shows you what the latest version is.

Go onto the chrome baseflight configuration tool, firmware flasher

Choose Load Firmware [Online], that will show you the latest official and the date it was released

Unfortunately it is in the retarded American date format

It doesn't say if it's version 2.2 or 2.3 or whatever it just states a date. If it said "Firmware is out of date" or it said the date of the current firmware it would help a lot. Maybe I'm just dump that can't figure it out tho that's quite possible

timecop wrote:Or jut type "version" in CLI as the linked post says...

At the time I made the video this was the version output of CLI.
# version
Afro32 CLI version 2.2 Apr 23 2014 / 09:51:45

I then updated the firmware now and the version output of CLI gives me following.

# version
Afro32 CLI version 2.2 Aug 3 2014 / 21:51:54

Tested and got the same problems as before when I use "arm". A dump of my settings can be found here http://pastebin.com/hLCFnSu1

Hardware setup is;
Naze 32 Acro rev.5 board
Frsky D4R-II flashed with the latest 27mS CPPM firmware from frsky.com
Frsky Taranis radio

Let me know if you need anything else.

timecop · Post by **timecop** » Mon Sep 22, 2014 1:14 pm

Never tested 27ms firmware, so no idea.
Without scope or logic analyzer there's nothing else you can help with.

strips · Post by **strips** » Mon Sep 22, 2014 1:34 pm

minim wrote:
kilby wrote:But there is something that shows you what the latest version is.

Go onto the chrome baseflight configuration tool, firmware flasher

Choose Load Firmware [Online], that will show you the latest official and the date it was released

Unfortunately it is in the retarded American date format

It doesn't say if it's version 2.2 or 2.3 or whatever it just states a date. If it said "Firmware is out of date" or it said the date of the current firmware it would help a lot. Maybe I'm just dump that can't figure it out tho that's quite possible

timecop wrote:Or jut type "version" in CLI as the linked post says...

At the time I made the video this was the version output of CLI.
# version
Afro32 CLI version 2.2 Apr 23 2014 / 09:51:45

I then updated the firmware now and the version output of CLI gives me following.

# version
Afro32 CLI version 2.2 Aug 3 2014 / 21:51:54

Tested and got the same problems as before when I use "arm". A dump of my settings can be found here http://pastebin.com/hLCFnSu1

Hardware setup is;
Naze 32 Acro rev.5 board
Frsky D4R-II flashed with the latest 27mS CPPM firmware from frsky.com
Frsky Taranis radio

Let me know if you need anything else.

You got the weirdest bug/issue I have seen in a while

Tried other RX? I have used D8R-XP and D4R-II both with 27ms and have not had any problems. But I do not think I have put arm on "high" only middle setting on a 3-way switch.

For the fun of it. Try Cleanflight and/or Harakiri and see what happens.

minim · Post by **minim** » Mon Sep 22, 2014 1:45 pm

timecop wrote:Never tested 27ms firmware, so no idea.
Without scope or logic analyzer there's nothing else you can help with.

Not sure if that's related to the TX at all to be honest since it's working without a flaw as long as "arm" is not enabled. All 8 channels are giving the correct values as long as "arm" is not hooked off. This leads me to belive that there is no problem with the CCPM and that it is software related. It's not a big deal for me as I'm using stick arming but I just found this bug when I was testing. I can connect a D8R-II Plus with PWM and see if I get the same error with that if you want.

Edit:
Hooked up D8R-IIPlus with all eight channels connected and everything is working until "Arm" is enabled then I have the same error as in the video with baseflight either locking up or showing the wrong value. So the problem isn't ccpm/pwm/27mS related as far as I can tell.

Edit2: Hmm, with this latest firmware baseflight locks up when I arm with the sticks also. Didn't think of checking this with the firmware I had.. Looks like the arming itself works but baseflight is locking up.

strips · Post by **strips** » Mon Sep 22, 2014 2:23 pm

minim wrote:
timecop wrote:Never tested 27ms firmware, so no idea.
Without scope or logic analyzer there's nothing else you can help with.

Not sure if that's related to the TX at all to be honest since it's working without a flaw as long as "arm" is not enabled. All 8 channels are giving the correct values as long as "arm" is not hooked off. This leads me to belive that there is no problem with the CCPM and that it is software related. It's not a big deal for me as I'm using stick arming but I just found this bug when I was testing. I can connect a D8R-II Plus with PWM and see if I get the same error with that if you want.

Edit:
Hooked up D8R-IIPlus with all eight channels connected and everything is working until "Arm" is enabled then I have the same error as in the video with baseflight either locking up or showing the wrong value. So the problem isn't ccpm/pwm/27mS related as far as I can tell.

Edit2: Hmm, with this latest firmware baseflight locks up when I arm with the sticks also. Didn't think of checking this with the firmware I had.. Looks like the arming itself works but baseflight is locking up.

Have you tried to reflash and erase?

timecop · Post by **timecop** » Mon Sep 22, 2014 2:35 pm

Did you do something dumb like enable feature TELEMETRY.
edit: according to your dump, you did.
So wtf do you expect?
When you arm, port switches to frsky telemtry mode.

minim · Post by **minim** » Mon Sep 22, 2014 3:14 pm

timecop wrote:Did you do something dumb like enable feature TELEMETRY.
edit: according to your dump, you did.
So wtf do you expect?
When you arm, port switches to frsky telemtry mode.

Ofcourse I did

I didn't think about the shared UART device, moved it to soft serial at pin6 now and it works like a charm. Thanks!

BennyG · Post by **BennyG** » Tue Sep 23, 2014 2:16 am

timecop wrote:Camera stab on tarduino is done with software PWM. Sorry, not going to happen here.
You can hack S2 to output camera roll or tilt stuff in tricopter mode.
Patches welcome.

So I will have to make a software change to make it happen, and I should use the existing hardware based PWM to do it, not introduce software PWM.

No promises today (and no more questions :-)

), but at least I know if I like the way it flies enough I CAN make it work.

Thanks TC.

nonlineofsight · Post by **nonlineofsight** » Tue Sep 23, 2014 4:13 pm

Hi, Does anyone know if i can use this Bluetooth module with the naze32

http://www.multiwiicopter.com/products/bluetooth-paris

Cheers

Steban Jigs · Post by **Steban Jigs** » Tue Sep 23, 2014 8:33 pm

Hey guys, did some searching and haven't come across any answers on this and I know it's might not be a supported issue since it deals with gps lock but thought I would ask. I have a ublox 6m which has been working fine for a while now with the naze32 full board, but recently after installing a 5.8ghz fpv kit there seems to be intermittent loss of gps lock with the 5.8ghz transmitter plugged in (through a seperate 5v ubec) and with it not powered all is fine as normal. Could this possibly be solved by switching to emf_avoidance to 1 and how much of a difference is found with pid stability or changes needed after doing this as this overclocks the board slightly afaik?

Other than that the board has been pretty slick for the price.

rubadub · Post by **rubadub** » Wed Sep 24, 2014 3:52 am

sorry if this has been asked before, but, other than removing the chip itself, is there any way to easily disable the onboard mag sensor on the afro naze32? I'm assuming there isn't but figured I'd check just in case...

strips · Post by **strips** » Wed Sep 24, 2014 7:40 am

rubadub wrote:sorry if this has been asked before, but, other than removing the chip itself, is there any way to easily disable the onboard mag sensor on the afro naze32? I'm assuming there isn't but figured I'd check just in case...

Short answer. No.

For the equipped and knowledgeable it's simple. Just remove the whole chip

You need hot air and know how. Thingking of doing this my self but I I'm afraid I'll ruin the board.

strips · Post by **strips** » Wed Sep 24, 2014 7:43 am

Steban Jigs wrote:Hey guys, did some searching and haven't come across any answers on this and I know it's might not be a supported issue since it deals with gps lock but thought I would ask. I have a ublox 6m which has been working fine for a while now with the naze32 full board, but recently after installing a 5.8ghz fpv kit there seems to be intermittent loss of gps lock with the 5.8ghz transmitter plugged in (through a seperate 5v ubec) and with it not powered all is fine as normal. Could this possibly be solved by switching to emf_avoidance to 1 and how much of a difference is found with pid stability or changes needed after doing this as this overclocks the board slightly afaik?

Other than that the board has been pretty slick for the price.

The emf_avoidance is to prevent 433Mhz harmonics mess up the Naze32. Or was it the other way around...

nonlineofsight · Post by **nonlineofsight** » Wed Sep 24, 2014 10:10 am

nonlineofsight wrote:Hi, Does anyone know if i can use this Bluetooth module with the naze32

http://www.multiwiicopter.com/products/bluetooth-paris

Cheers

Okay, got this one from banggood

1 x MWC Multiwii Bluetooth Parameter Debugging Programmer Module (SKU090653) €7.19. Have seen others succeed with it.

-nlos

Andyjones · Post by **Andyjones** » Wed Sep 24, 2014 3:35 pm

nebbian wrote:
Andyjones wrote:Hey guys, I just wanted to first thank you all for makings such a cool piece of tech. I was wondering if I can use this Sonar I got from radioshack for one of my kids projects on this board?

http://www.ebay.com/itm/like/400714787400?lpid=82

The one Im seeing people use on here (h somehitng or other) has 4 pins and this one has 3 so this may be a stupid question but that has never stopped me before. Thanks again

I think you should be able to use it if you connect the echo pin on your naze to the signal pin on the sonar unit, then put a diode between the trigger pin on the naze to the same signal pin on the unit.

That's assuming that you trigger the unit by pulling the signal pin high, and then it sends back a high pulse when it detects the ground.

Please note that the default baseflight code only allows the use of sonar if you also have a barometer on board. If you want to use sonar with an acro board, then you'll have to do some compiling yourself. Here's some code I wrote to allow this to happen, it creates another flight mode that you can select with aux switches:
https://github.com/nebbian/cleanflight/commit/66fce423bbe75f60c813319e07b120798f0b4a0d

\

Holy crap, Im sorry I didnt respond earlier, not used to responsive forum communities. Thank you so much for this . I got it going " highlighted green in baseflight" now time for some more dumb questions. I can only get it to enable in PPM mode, assuming this is a pin config reason. First question is can I get the sonar to work without PPM turned on?> Second is if not, how does one set up a PPM receiver? Do I need specific equipment? I have a Spektrum DX6i and I scoured the internets and I cant really find any info on setting it to PPM. Im prolly searching for the wrong terms I am very new to all this.

timecop · Post by **timecop** » Wed Sep 24, 2014 3:55 pm

If youre using spektrum why not just use spektrum sat on RC4 pin... or something. Or I tihnk one of cheap LemonRX spektrum clones has PPM out.

Andyjones · Post by **Andyjones** » Wed Sep 24, 2014 4:13 pm

ahhh yes , thats what i needed. Thank you. Ill be grabbing one of those.

Andyjones · Post by **Andyjones** » Wed Sep 24, 2014 4:42 pm

well as long as Im asking dumb questions, is there anyway of putting the trigger and echo out to other pins with the non-ppm setup?

markab · Post by **markab** » Wed Sep 24, 2014 7:03 pm

Got my 270 size flying pretty good but having an issue when I enable the MAG, after a turn and into forward flight I get a pretty quick yaw to the left anywhere between 5 and 45 degrees, its a quick snap and not a drift. Mag is calibrated and gives sensible numbers in base flight.

Should also say I don't think I had the problem with the board in the default rotation, possibly it started when I rotated the board 90 degrees to get side access to the usb.

Any ideas?

Hoppsan_84 · Post by **Hoppsan_84** » Wed Sep 24, 2014 7:05 pm

Powerlines to Close to the mag?

markab · Post by **markab** » Wed Sep 24, 2014 7:07 pm

Don't think so, don't seem to have a problem for example sitting in a hover and going full throttle up, heading holds fine.

kilby · Post by **kilby** » Wed Sep 24, 2014 9:46 pm

Have you got the COG correct, if you are tail heavy (battery sitting towards the rear) accelerating or coming out of a turn will result in the tail continuing to turn and quads don't have much yaw authority so the flight controller will have problems regaining control

markab · Post by **markab** » Thu Sep 25, 2014 12:06 am

kilby wrote:Have you got the COG correct, if you are tail heavy (battery sitting towards the rear) accelerating or coming out of a turn will result in the tail continuing to turn and quads don't have much yaw authority so the flight controller will have problems regaining control

COG is bang in the middle along with the naze32.

timecop · Post by **timecop** » Thu Sep 25, 2014 1:12 am

markab wrote:Got my 270 size flying pretty good but having an issue when I enable the MAG, after a turn and into forward flight I get a pretty quick yaw to the left anywhere between 5 and 45 degrees, its a quick snap and not a drift. Mag is calibrated and gives sensible numbers in base flight.

Should also say I don't think I had the problem with the board in the default rotation, possibly it started when I rotated the board 90 degrees to get side access to the usb.

Any ideas?

board_align has only been tested for acro. I wouldn't be surprised if it completely breaks mag.