Naze32 hardware discussion thread
Re: Naze32 hardware discussion thread
Sounds like you got a DJI frame
Re: Naze32 hardware discussion thread
Try setting a yawdeadband and deadband if your Tx can't hold 1500 when sticks are centered. As for the motors, check if they are balanced also... maybe some expo will help "smooth" out the Tx input.[/quote]
Thanks KC. I upped the deadbands but I haven't messed with the expo. I'll give that a shot.
The RCtimer motors came with bullet connectors so I'm using those instead of soldered joints. Any chance that cause some strange frequency issue with the FC or RX?
Thanks KC. I upped the deadbands but I haven't messed with the expo. I'll give that a shot.
The RCtimer motors came with bullet connectors so I'm using those instead of soldered joints. Any chance that cause some strange frequency issue with the FC or RX?
Re: Naze32 hardware discussion thread
The frame is a g10 cut from Steve's plans on untestedprototype.com
http://untestedprototype.com/2014/03/ha ... -0-manual/
http://untestedprototype.com/2014/03/ha ... -0-manual/
Re: Naze32 hardware discussion thread
Hi all, having an odd problem with my naze. When I originally set it up and tested it via USB w/ a satellite receiver everything was fine. But after changing some settings and rebooting, I'm having a very weird issue. When I look at the receiver input in baseflight configurator, the movement is very "choppy". That is, when I move the sticks on my Tx I don't see a smooth transition, it will just jump (after a small delay) to whatever value I end at. Any ideas what could be going on here?
Re: Naze32 hardware discussion thread
Browser problem?
Re: Naze32 hardware discussion thread
Unfortunately not. The motors act the same way. Lag, quick spin up, not smooth with a throttle up.
Re: Naze32 hardware discussion thread
I made a 20 second video which should clarify the problem I'm having. Note how smoothly the bars move when moving the quad by hand, but how choppy it is when taking Rx input. And yes, this translates into actual choppiness when running the motors.
http://youtu.be/LR5okJse8VE
Any suggestions would be much appreciated. I'm using a lemon-rx DSMX satellite receiver with the naze32 acro and a Turnigy 9RX. serialrx enabled, serialrx_type=1
http://youtu.be/LR5okJse8VE
Any suggestions would be much appreciated. I'm using a lemon-rx DSMX satellite receiver with the naze32 acro and a Turnigy 9RX. serialrx enabled, serialrx_type=1
-
- Posts: 7
- Joined: Wed Jul 16, 2014 2:08 am
Re: Naze32 hardware discussion thread
I have the telemetry to a Taranis on a D4R-II in PPM mode working perfectly to give me pack voltage via soft serial, however, I can not get working at all on the Fr Sky pins. I have followed the wiki exactly and tried multiple times. I need to get it working on the Fr Sky pins to free up pin 6 using the gimbal_flags=4 command for a lost model alarm on an aux switch. Can anyone think of anything in the CLI that would prevent the controller from switching over to 9600 baud on the UART after the USB / baseloader is unplugged and the controller is armed? Here is my current CLI dump. Baseloader sees the pack voltage perfectly when the usb is connected. Telemetry is also working as I am getting ESC voltage down. For some reason, Naze32, just won't start sending telemetry through FrSky pins.
# dump
Current Config: Copy everything below here...
aux 0 0
aux 1 2
aux 2 4
aux 3 0
aux 4 0
aux 5 0
aux 6 0
aux 7 0
aux 8 0
aux 9 0
aux 10 0
aux 11 0
aux 12 0
aux 13 0
aux 14 0
aux 15 0
aux 16 0
aux 17 0
aux 18 0
aux 19 0
aux 20 0
mixer QUADX
feature -PPM
feature -VBAT
feature -INFLIGHT_ACC_CAL
feature -SERIALRX
feature -MOTOR_STOP
feature -SERVO_TILT
feature -SOFTSERIAL
feature -LED_RING
feature -GPS
feature -FAILSAFE
feature -SONAR
feature -TELEMETRY
feature -POWERMETER
feature -VARIO
feature -3D
feature PPM
feature VBAT
feature MOTOR_STOP
feature TELEMETRY
map TAER1234
set looptime = 2800
set emf_avoidance = 0
set midrc = 1500
set minthrottle = 1050
set maxthrottle = 1850
set mincommand = 1050
set mincheck = 1100
set maxcheck = 1900
set deadband3d_low = 1406
set deadband3d_high = 1514
set neutral3d = 1460
set deadband3d_throttle = 50
set motor_pwm_rate = 400
set servo_pwm_rate = 50
set retarded_arm = 0
set flaps_speed = 0
set fixedwing_althold_dir = 1
set reboot_character = 82
set serial_baudrate = 115200
set softserial_baudrate = 9600
set softserial_1_inverted = 1
set softserial_2_inverted = 0
set gps_type = 0
set gps_baudrate = 0
set serialrx_type = 0
set telemetry_provider = 0
set telemetry_port = 0
set telemetry_switch = 0
set vbatscale = 110
set currentscale = 400
set currentoffset = 0
set multiwiicurrentoutput = 0
set vbatmaxcellvoltage = 4
set vbatmincellvoltage = 3
set power_adc_channel = 0
set align_gyro = 0
set align_acc = 0
set align_mag = 0
set align_board_roll = 0
set align_board_pitch = 0
set align_board_yaw = 0
set yaw_control_direction = 1
set acc_hardware = 0
set max_angle_inclination = 500
set moron_threshold = 32
set gyro_lpf = 42
set gyro_cmpf_factor = 600
set gyro_cmpfm_factor = 250
set pid_controller = 0
set deadband = 0
set yawdeadband = 0
set alt_hold_throttle_neutral = 40
set alt_hold_fast_change = 1
set throttle_correction_value = 0
set throttle_correction_angle = 800
set rc_rate = 125
set rc_expo = 75
set thr_mid = 65
set thr_expo = 0
set roll_pitch_rate = 40
set yaw_rate = 75
set tpa_rate = 10
set tpa_breakpoint = 1500
set failsafe_delay = 10
set failsafe_off_delay = 200
set failsafe_throttle = 1200
set failsafe_detect_threshold = 985
set rssi_aux_channel = 0
set yaw_direction = 1
set tri_unarmed_servo = 1
set gimbal_flags = 0
set acc_lpf_factor = 4
set accxy_deadband = 40
set accz_deadband = 40
set acc_unarmedcal = 1
set acc_trim_pitch = 44
set acc_trim_roll = -6
set baro_tab_size = 21
set baro_noise_lpf = 0.600
set baro_cf_vel = 0.985
set baro_cf_alt = 0.965
set mag_declination = 0
set gps_pos_p = 11
set gps_pos_i = 0
set gps_pos_d = 0
set gps_posr_p = 20
set gps_posr_i = 8
set gps_posr_d = 45
set gps_nav_p = 14
set gps_nav_i = 20
set gps_nav_d = 80
set gps_wp_radius = 200
set nav_controls_heading = 1
set nav_speed_min = 100
set nav_speed_max = 300
set nav_slew_rate = 30
set p_pitch = 30
set i_pitch = 45
set d_pitch = 23
set p_roll = 30
set i_roll = 45
set d_roll = 23
set p_yaw = 100
set i_yaw = 50
set d_yaw = 0
set p_alt = 50
set i_alt = 0
set d_alt = 0
set p_level = 90
set i_level = 10
set d_level = 100
set p_vel = 120
set i_vel = 45
set d_vel = 1
#
# dump
Current Config: Copy everything below here...
aux 0 0
aux 1 2
aux 2 4
aux 3 0
aux 4 0
aux 5 0
aux 6 0
aux 7 0
aux 8 0
aux 9 0
aux 10 0
aux 11 0
aux 12 0
aux 13 0
aux 14 0
aux 15 0
aux 16 0
aux 17 0
aux 18 0
aux 19 0
aux 20 0
mixer QUADX
feature -PPM
feature -VBAT
feature -INFLIGHT_ACC_CAL
feature -SERIALRX
feature -MOTOR_STOP
feature -SERVO_TILT
feature -SOFTSERIAL
feature -LED_RING
feature -GPS
feature -FAILSAFE
feature -SONAR
feature -TELEMETRY
feature -POWERMETER
feature -VARIO
feature -3D
feature PPM
feature VBAT
feature MOTOR_STOP
feature TELEMETRY
map TAER1234
set looptime = 2800
set emf_avoidance = 0
set midrc = 1500
set minthrottle = 1050
set maxthrottle = 1850
set mincommand = 1050
set mincheck = 1100
set maxcheck = 1900
set deadband3d_low = 1406
set deadband3d_high = 1514
set neutral3d = 1460
set deadband3d_throttle = 50
set motor_pwm_rate = 400
set servo_pwm_rate = 50
set retarded_arm = 0
set flaps_speed = 0
set fixedwing_althold_dir = 1
set reboot_character = 82
set serial_baudrate = 115200
set softserial_baudrate = 9600
set softserial_1_inverted = 1
set softserial_2_inverted = 0
set gps_type = 0
set gps_baudrate = 0
set serialrx_type = 0
set telemetry_provider = 0
set telemetry_port = 0
set telemetry_switch = 0
set vbatscale = 110
set currentscale = 400
set currentoffset = 0
set multiwiicurrentoutput = 0
set vbatmaxcellvoltage = 4
set vbatmincellvoltage = 3
set power_adc_channel = 0
set align_gyro = 0
set align_acc = 0
set align_mag = 0
set align_board_roll = 0
set align_board_pitch = 0
set align_board_yaw = 0
set yaw_control_direction = 1
set acc_hardware = 0
set max_angle_inclination = 500
set moron_threshold = 32
set gyro_lpf = 42
set gyro_cmpf_factor = 600
set gyro_cmpfm_factor = 250
set pid_controller = 0
set deadband = 0
set yawdeadband = 0
set alt_hold_throttle_neutral = 40
set alt_hold_fast_change = 1
set throttle_correction_value = 0
set throttle_correction_angle = 800
set rc_rate = 125
set rc_expo = 75
set thr_mid = 65
set thr_expo = 0
set roll_pitch_rate = 40
set yaw_rate = 75
set tpa_rate = 10
set tpa_breakpoint = 1500
set failsafe_delay = 10
set failsafe_off_delay = 200
set failsafe_throttle = 1200
set failsafe_detect_threshold = 985
set rssi_aux_channel = 0
set yaw_direction = 1
set tri_unarmed_servo = 1
set gimbal_flags = 0
set acc_lpf_factor = 4
set accxy_deadband = 40
set accz_deadband = 40
set acc_unarmedcal = 1
set acc_trim_pitch = 44
set acc_trim_roll = -6
set baro_tab_size = 21
set baro_noise_lpf = 0.600
set baro_cf_vel = 0.985
set baro_cf_alt = 0.965
set mag_declination = 0
set gps_pos_p = 11
set gps_pos_i = 0
set gps_pos_d = 0
set gps_posr_p = 20
set gps_posr_i = 8
set gps_posr_d = 45
set gps_nav_p = 14
set gps_nav_i = 20
set gps_nav_d = 80
set gps_wp_radius = 200
set nav_controls_heading = 1
set nav_speed_min = 100
set nav_speed_max = 300
set nav_slew_rate = 30
set p_pitch = 30
set i_pitch = 45
set d_pitch = 23
set p_roll = 30
set i_roll = 45
set d_roll = 23
set p_yaw = 100
set i_yaw = 50
set d_yaw = 0
set p_alt = 50
set i_alt = 0
set d_alt = 0
set p_level = 90
set i_level = 10
set d_level = 100
set p_vel = 120
set i_vel = 45
set d_vel = 1
#
Re: Naze32 hardware discussion thread
Fucking finally! fixed my problem. For anyone else that is experiencing "lagging" and choppy motor/receiver movements when using a OrangeRX transmitter and DSMX/DSM2 receiver, the solution is simple. Look at the blinking green light on your OrangeRX receiver:
single flash: 2048, 11ms DSM2
double flash: 1024 11ms DSMX
triple flash; 2048, 11ms DSMX
Pressing the bind button 3 times moves to the next mode. The lemon-rx DSMX receiver requires 2048 (11bit) 11ms DSMX, so click until you're in the triple flash mode.
This will happen if you bind your Tx to another receiver (say your nano qx) which has a different mode. Problem solved, now just waiting on the 5V downregulator I bought to replace the one I blew
single flash: 2048, 11ms DSM2
double flash: 1024 11ms DSMX
triple flash; 2048, 11ms DSMX
Pressing the bind button 3 times moves to the next mode. The lemon-rx DSMX receiver requires 2048 (11bit) 11ms DSMX, so click until you're in the triple flash mode.
This will happen if you bind your Tx to another receiver (say your nano qx) which has a different mode. Problem solved, now just waiting on the 5V downregulator I bought to replace the one I blew
Re: Naze32 hardware discussion thread
How to get frsky (FAS-100) telemetry into the naze32? (since naze32 outputs frsky telem)
Baseflight seem to have no reference to any code that attempts to read it,
though ive seen https://code.google.com/p/afrodevices/s ... /sensors.c
if only it was integrated into baseflight.. how do people get around it?
since the fas100 has no pwm output, no analogue output, have no way to get it into minimosd...
no good way to get the current measurement into minimosd AND back to the frsky tx...
Baseflight seem to have no reference to any code that attempts to read it,
though ive seen https://code.google.com/p/afrodevices/s ... /sensors.c
if only it was integrated into baseflight.. how do people get around it?
since the fas100 has no pwm output, no analogue output, have no way to get it into minimosd...
no good way to get the current measurement into minimosd AND back to the frsky tx...
Re: Naze32 hardware discussion thread
cherokee180c wrote:I have the telemetry to a Taranis on a D4R-II in PPM mode working perfectly to give me pack voltage via soft serial, however, I can not get working at all on the Fr Sky pins. I have followed the wiki exactly and tried multiple times. I need to get it working on the Fr Sky pins to free up pin 6 using the gimbal_flags=4 command for a lost model alarm on an aux switch. Can anyone think of anything in the CLI that would prevent the controller from switching over to 9600 baud on the UART after the USB / baseloader is unplugged and the controller is armed? Here is my current CLI dump. Baseloader sees the pack voltage perfectly when the usb is connected. Telemetry is also working as I am getting ESC voltage down. For some reason, Naze32, just won't start sending telemetry through FrSky pins.
# dump
Current Config: Copy everything below here...
aux 0 0
aux 1 2
aux 2 4
aux 3 0
aux 4 0
aux 5 0
aux 6 0
aux 7 0
aux 8 0
aux 9 0
aux 10 0
aux 11 0
aux 12 0
aux 13 0
aux 14 0
aux 15 0
aux 16 0
aux 17 0
aux 18 0
aux 19 0
aux 20 0
mixer QUADX
feature -PPM
feature -VBAT
feature -INFLIGHT_ACC_CAL
feature -SERIALRX
feature -MOTOR_STOP
feature -SERVO_TILT
feature -SOFTSERIAL
feature -LED_RING
feature -GPS
feature -FAILSAFE
feature -SONAR
feature -TELEMETRY
feature -POWERMETER
feature -VARIO
feature -3D
feature PPM
feature VBAT
feature MOTOR_STOP
feature TELEMETRY
map TAER1234
set looptime = 2800
set emf_avoidance = 0
set midrc = 1500
set minthrottle = 1050
set maxthrottle = 1850
set mincommand = 1050
set mincheck = 1100
set maxcheck = 1900
set deadband3d_low = 1406
set deadband3d_high = 1514
set neutral3d = 1460
set deadband3d_throttle = 50
set motor_pwm_rate = 400
set servo_pwm_rate = 50
set retarded_arm = 0
set flaps_speed = 0
set fixedwing_althold_dir = 1
set reboot_character = 82
set serial_baudrate = 115200
set softserial_baudrate = 9600
set softserial_1_inverted = 1
set softserial_2_inverted = 0
set gps_type = 0
set gps_baudrate = 0
set serialrx_type = 0
set telemetry_provider = 0
set telemetry_port = 0
set telemetry_switch = 0
set vbatscale = 110
set currentscale = 400
set currentoffset = 0
set multiwiicurrentoutput = 0
set vbatmaxcellvoltage = 4
set vbatmincellvoltage = 3
set power_adc_channel = 0
set align_gyro = 0
set align_acc = 0
set align_mag = 0
set align_board_roll = 0
set align_board_pitch = 0
set align_board_yaw = 0
set yaw_control_direction = 1
set acc_hardware = 0
set max_angle_inclination = 500
set moron_threshold = 32
set gyro_lpf = 42
set gyro_cmpf_factor = 600
set gyro_cmpfm_factor = 250
set pid_controller = 0
set deadband = 0
set yawdeadband = 0
set alt_hold_throttle_neutral = 40
set alt_hold_fast_change = 1
set throttle_correction_value = 0
set throttle_correction_angle = 800
set rc_rate = 125
set rc_expo = 75
set thr_mid = 65
set thr_expo = 0
set roll_pitch_rate = 40
set yaw_rate = 75
set tpa_rate = 10
set tpa_breakpoint = 1500
set failsafe_delay = 10
set failsafe_off_delay = 200
set failsafe_throttle = 1200
set failsafe_detect_threshold = 985
set rssi_aux_channel = 0
set yaw_direction = 1
set tri_unarmed_servo = 1
set gimbal_flags = 0
set acc_lpf_factor = 4
set accxy_deadband = 40
set accz_deadband = 40
set acc_unarmedcal = 1
set acc_trim_pitch = 44
set acc_trim_roll = -6
set baro_tab_size = 21
set baro_noise_lpf = 0.600
set baro_cf_vel = 0.985
set baro_cf_alt = 0.965
set mag_declination = 0
set gps_pos_p = 11
set gps_pos_i = 0
set gps_pos_d = 0
set gps_posr_p = 20
set gps_posr_i = 8
set gps_posr_d = 45
set gps_nav_p = 14
set gps_nav_i = 20
set gps_nav_d = 80
set gps_wp_radius = 200
set nav_controls_heading = 1
set nav_speed_min = 100
set nav_speed_max = 300
set nav_slew_rate = 30
set p_pitch = 30
set i_pitch = 45
set d_pitch = 23
set p_roll = 30
set i_roll = 45
set d_roll = 23
set p_yaw = 100
set i_yaw = 50
set d_yaw = 0
set p_alt = 50
set i_alt = 0
set d_alt = 0
set p_level = 90
set i_level = 10
set d_level = 100
set p_vel = 120
set i_vel = 45
set d_vel = 1
#
for pin 6 i believe you need;
set telemetry_port = 1
ref;
https://github.com/multiwii/baseflight/wiki/Telemetry
Re: Naze32 hardware discussion thread
AvengerIl wrote:How to get frsky (FAS-100) telemetry into the naze32? (since naze32 outputs frsky telem)
Baseflight seem to have no reference to any code that attempts to read it,
though ive seen https://code.google.com/p/afrodevices/s ... /sensors.c
if only it was integrated into baseflight.. how do people get around it?
since the fas100 has no pwm output, no analogue output, have no way to get it into minimosd...
no good way to get the current measurement into minimosd AND back to the frsky tx...
Yeah, I wrote fas100 driver for osdongs.
it works.
I think it would still work while baseflight is running, but you'd have to lose one full set of TIMx - RC_CH5-8 (TIM3) are probably the only choice... (which means no softserial/etc).
FAS100 PWM reading code uses masterslave capture config on the timer, and that means it's the only thing it can do on those pins..
Re: Naze32 hardware discussion thread
timecop wrote:AvengerIl wrote:How to get frsky (FAS-100) telemetry into the naze32? (since naze32 outputs frsky telem)
Baseflight seem to have no reference to any code that attempts to read it,
though ive seen https://code.google.com/p/afrodevices/s ... /sensors.c
if only it was integrated into baseflight.. how do people get around it?
since the fas100 has no pwm output, no analogue output, have no way to get it into minimosd...
no good way to get the current measurement into minimosd AND back to the frsky tx...
Yeah, I wrote fas100 driver for osdongs.
it works.
I think it would still work while baseflight is running, but you'd have to lose one full set of TIMx - RC_CH5-8 (TIM3) are probably the only choice... (which means no softserial/etc).
FAS100 PWM reading code uses masterslave capture config on the timer, and that means it's the only thing it can do on those pins..
Oh wow ok.. I code for a living but im still learning what others have done and how to wire it up into a working quad, no chance at this stage of intergrating that code myself for now..

anything easier?
Re: Naze32 hardware discussion thread
AvengerIl wrote:timecop wrote:AvengerIl wrote:How to get frsky (FAS-100) telemetry into the naze32? (since naze32 outputs frsky telem)
Baseflight seem to have no reference to any code that attempts to read it,
though ive seen https://code.google.com/p/afrodevices/s ... /sensors.c
if only it was integrated into baseflight.. how do people get around it?
since the fas100 has no pwm output, no analogue output, have no way to get it into minimosd...
no good way to get the current measurement into minimosd AND back to the frsky tx...
Yeah, I wrote fas100 driver for osdongs.
it works.
I think it would still work while baseflight is running, but you'd have to lose one full set of TIMx - RC_CH5-8 (TIM3) are probably the only choice... (which means no softserial/etc).
FAS100 PWM reading code uses masterslave capture config on the timer, and that means it's the only thing it can do on those pins..
Oh wow ok.. I code for a living but im still learning what others have done and how to wire it up into a working quad, no chance at this stage of intergrating that code myself for now..
anything easier?
set power_adc_channel
Seems pin 8 pwm side can be used as analogue power consumption input... So perhaps a $3 arduino that converts s.port to analogue may be my simplest option for now. (with https://github.com/zendes/SPort). phew...
Re: Naze32 hardware discussion thread
Has anyone succeeded in getting accurate altitude readings from naze telemetry using d4rii receiver with softserial. I get vfas and acc info ok but alt on Taranis has large numbers that reduce when lifting quad.
I have searched extensively and not found info. Any advise is appreciated.
I have searched extensively and not found info. Any advise is appreciated.
-
- Posts: 7
- Joined: Wed Jul 16, 2014 2:08 am
Re: Naze32 hardware discussion thread
AvengerIl wrote:
for pin 6 i believe you need;
set telemetry_port = 1
ref;
https://github.com/multiwii/baseflight/wiki/Telemetry[/quote]
Thanks, I actually have it working fine using soft serial but I can't get working on the fr sky pins!
Re: Naze32 hardware discussion thread
TC, I'm looking at your AfroMini 32 and it looks like an awesome board. I just feel like there has to be some catch. Why isn't it more popular? Or are people just missing out? I want to buy one from your website but I'm hesitant to pull the trigger
Re: Naze32 hardware discussion thread
akcom wrote:TC, I'm looking at your AfroMini 32 and it looks like an awesome board. I just feel like there has to be some catch. Why isn't it more popular? Or are people just missing out? I want to buy one from your website but I'm hesitant to pull the trigger
The trick is you need to grow a full size Afro before you can fly with the Afro devices. Since you're hesitant to pull the trigger you probably do not belong with the Afro community.
Mind you, Robocop will be chasing your a$$ with a baton once you do have an Afro and you do pull the trigger.
Im fully Afro as of last night, I had a hover with my Quad in my living room. Too easy if you just stick to the basics. Ie Fly. Otherwise robocop will tell you go to hang with the DJI kids.
(Who do not have afro's and do not talk cool like us).
Pull the trigger with your finger!
Re: Naze32 hardware discussion thread
akcom wrote:TC, I'm looking at your AfroMini 32 and it looks like an awesome board. I just feel like there has to be some catch. Why isn't it more popular? Or are people just missing out? I want to buy one from your website but I'm hesitant to pull the trigger
Shhh... Its a secret.

Re: Naze32 hardware discussion thread
Guys,
Do I miss something in the initial settings, or why hovering the same config on 55% with Naze32 and on 45% with APM board???
Many thanks,
B
Do I miss something in the initial settings, or why hovering the same config on 55% with Naze32 and on 45% with APM board???
Many thanks,
B
Sv: Naze32 hardware discussion thread
bulesz wrote:Guys,
Do I miss something in the initial settings, or why hovering the same config on 55% with Naze32 and on 45% with APM board???
Many thanks,
B
Not sure I understand. But I think you are saying that you hover at 55% throttle on Naze32 and 45% throttle on APM?
Could be expo, different endpoints, ESC calibration, stick scaling or whatever you call it. Different FC might keep some reserve for stabilization.
Re: Naze32 hardware discussion thread
For anyone interested, FrSky telemetry output from Naze32 is a simple 9600baud protocol, Vario Sensor uses it also. The soft serial port on pin 5/serial1 can easily parse/read it. So pin 6 goes into data in of vario yellow wire and pin 5 takes data out yellow wire from vario and voila.
Frsky tx can receive telemetry from fas100/vario/naze32 and also output from fas100 through the vario can make it to the naze32 and hence through to minimosd..
Ill either publish the code or attempt to push it into github if it will take it..
Frsky tx can receive telemetry from fas100/vario/naze32 and also output from fas100 through the vario can make it to the naze32 and hence through to minimosd..
Ill either publish the code or attempt to push it into github if it will take it..
Last edited by AvengerIl on Mon Jul 28, 2014 2:39 pm, edited 1 time in total.
Re: Sv: Naze32 hardware discussion thread
strips wrote:bulesz wrote:Guys,
Do I miss something in the initial settings, or why hovering the same config on 55% with Naze32 and on 45% with APM board???
Many thanks,
B
Not sure I understand. But I think you are saying that you hover at 55% throttle on Naze32 and 45% throttle on APM?
Could be expo, different endpoints, ESC calibration, stick scaling or whatever you call it. Different FC might keep some reserve for stabilization.
Heyho,
Thanks for your reply, but I have figured it out. It was more simple: I had to change the MAX throttle to 1980 or close to my radio max and it was fixed it.
Sv: Naze32 hardware discussion thread
bulesz wrote:strips wrote:bulesz wrote:Guys,
Do I miss something in the initial settings, or why hovering the same config on 55% with Naze32 and on 45% with APM board???
Many thanks,
B
Not sure I understand. But I think you are saying that you hover at 55% throttle on Naze32 and 45% throttle on APM?
Could be expo, different endpoints, ESC calibration, stick scaling or whatever you call it. Different FC might keep some reserve for stabilization.
Heyho,
Thanks for your reply, but I have figured it out. It was more simple: I had to change the MAX throttle to 1980 or close to my radio max and it was fixed it.
That would do it as well. Many ways to Rome I've heard

Personally i prefer to set up my radio so endpoints match what Baseflight expects. This way there is less to set up if i reflash and don't want to restore backup.
Re: Naze32 hardware discussion thread
Yeye...
So my next lesson is playing with the PIDs and the RC and R/P rates... 


Re: Naze32 hardware discussion thread
timecop: Looking at the datasheet for the stm32 it seems like the receiver pins is not 5V tolerant, yet there is not mention of it in the manual and people seem to use 5V receivers. On the other hand it says that you have to use a 3.3V gps if you are using it on the receiver pins. Is there some voodoo going on or am I missing something?
Re: Naze32 hardware discussion thread
There are 1k series resistors on 8 rc inputs. Which, theoretically, might be enough. People manage to fry stm32s regardless if these were FT or not.
Re: Naze32 hardware discussion thread
Ok I think I've fried my board before I've even flown it...
When I plug in I get the usual disco, but then the Blue and Red lights stay on. Plus it won't arm?
Everything looks to be working in the Baseflight Configurator (BC) .
Any ideas anyone?
Last thing I was doing was calibrating the motors through the BC
Many thanks in advance
When I plug in I get the usual disco, but then the Blue and Red lights stay on. Plus it won't arm?
Everything looks to be working in the Baseflight Configurator (BC) .
Any ideas anyone?
Last thing I was doing was calibrating the motors through the BC
Many thanks in advance
Re: Naze32 hardware discussion thread
reset to defaults, try again?
Re: Naze32 hardware discussion thread
Sussed it. It was just me being thick. Turns out when I was messing about I was trying to add a mode channel, which is where the red light naff come from. Plus my rate switch had stopped it arming. Problem solved. Thanks for the reply though. Hopefully have time to try it tomorrow.
-
- Posts: 5
- Joined: Sat Jul 19, 2014 3:28 am
Re: Naze32 hardware discussion thread
Can sonar work while softserial is enabled? I'm attempting to run minimOSD up top, frsky telem off of pin 6, and use 7 & 8 for sonar, but it doesn't seem like sonar is working. The hc-sr04 seems alright when I run some sample scripts with it hooked up to an arduino, but nevertheless I can wave my hand under it while in baro at low alt and it seems like it couldn't care less.
Re: Naze32 hardware discussion thread
Hello!
My mini quad after falling from a meter hight with no reason starts to sound like this.... anybody could tell me the reason?
Here is the video:
http://youtu.be/8L-gm6u_2aA
My mini quad after falling from a meter hight with no reason starts to sound like this.... anybody could tell me the reason?
Here is the video:
http://youtu.be/8L-gm6u_2aA
Re: Naze32 hardware discussion thread
timecop wrote:ESC
thank you timecop!
I'm using BS 12A with simonk 5-15-13 and sunnysky x2204-2300kv motors. Please could you tell me what can I do to solve this?
Best Regards!
Re: Naze32 hardware discussion thread
timecop wrote:ESC
thank you timecop!
I'm using BS 12A with simonk 5-15-13 and sunnysky x2204-2300kv motors. Please could you tell me what can I do to solve this?
Best Regards!
Re: Naze32 hardware discussion thread
I have an issue w. two separate Naze boards.
(Abusemark) Full Naze32 issue: using full wire harness from FC to Spektrum AR8000Rx. I am using Spektrum Tx. So map TAER1234. On wire harness - first three go into throttle port on Rx. I follow it by 2,3,4 in the Al, Elev, Rud. The rest go into Aux channels (in order).
Tested all motors and then aux Rx config on Baseline - YAW is not working at all. It is stuck at 1500 mid-point, but does not move when I move the rudder. End points set at 125%.
On the Same rig, (Dronematters) Acro Naze32 issue: Wire harness appears to be working because YAW and all other channels work; however, none of my motors will start up on the Motor Test tab in Baseline AND I cannot arm the board via sticks or Aux 2 switch.
When I swap boards the Acro Naze32 from Dronematters, yaw works terrific. Motors have been tested through the rx and the full Naze and Tx sticks/YAW have been tested through the acro.
I have used Naze products in the past and do not feel it to be a soldering issue, but here are pics of the board front and back for review. I am using latest software. I’ve been told reflashing the board may help and I will try that tonight unless someone can give a better recommendation? Any help is greatly appreciated.


WOw! those pic came out obnoxiously big. Here are the links to them: http://i.imgur.com/Tm9VNfK.jpg & http://i.imgur.com/gmpAFWO.jpg
(Abusemark) Full Naze32 issue: using full wire harness from FC to Spektrum AR8000Rx. I am using Spektrum Tx. So map TAER1234. On wire harness - first three go into throttle port on Rx. I follow it by 2,3,4 in the Al, Elev, Rud. The rest go into Aux channels (in order).
Tested all motors and then aux Rx config on Baseline - YAW is not working at all. It is stuck at 1500 mid-point, but does not move when I move the rudder. End points set at 125%.
On the Same rig, (Dronematters) Acro Naze32 issue: Wire harness appears to be working because YAW and all other channels work; however, none of my motors will start up on the Motor Test tab in Baseline AND I cannot arm the board via sticks or Aux 2 switch.
When I swap boards the Acro Naze32 from Dronematters, yaw works terrific. Motors have been tested through the rx and the full Naze and Tx sticks/YAW have been tested through the acro.
I have used Naze products in the past and do not feel it to be a soldering issue, but here are pics of the board front and back for review. I am using latest software. I’ve been told reflashing the board may help and I will try that tonight unless someone can give a better recommendation? Any help is greatly appreciated.


WOw! those pic came out obnoxiously big. Here are the links to them: http://i.imgur.com/Tm9VNfK.jpg & http://i.imgur.com/gmpAFWO.jpg
Re: Naze32 hardware discussion thread
Nate0624 wrote:WOw! those pic came out obnoxiously big. Here are the links to them: * & http://i.imgur.com/gmpAFWO.jpg
Imgur will auto resize your images for you as you link to them. If you append 'l' just before the .jpg extension you'll link to a large (640) pixel image for posting on forums and such. Use 'h' for a huge (1024). Or 'm' for medium...

Re: Naze32 hardware discussion thread
creyc wrote:Nate0624 wrote:WOw! those pic came out obnoxiously big. Here are the links to them: * & http://i.imgur.com/gmpAFWO.jpg
Imgur will auto resize your images for you as you link to them. If you append 'l' just before the .jpg extension you'll link to a large (640) pixel image for posting on forums and such. Use 'h' for a huge (1024). Or 'm' for medium...
Awesome! thanks.
So, I hope my first post wasn't a big waste of time. By rereading I relaized that I never Mapped TAER to the new ACro board. That's what happens when you install two in a row at 1 am. I still have hte YAW issue on the full naze; but I think I know why motors in the acro may not be working.
I'll try that.
Re: Naze32 hardware discussion thread
Your soldering is pretty crap, maybe you lifted a pad (whichever one is for yaw, CH4? on spektrum). If you're using PWM i don't really see how channel map matters at all just swap the connectors around to follow default order. And if you did waste that pad by soldering, just map it out, i.e. if rc_ch4 (R in default map is dead), just do map AET4R123 - and skip connecting stuff to it.
Re: Naze32 hardware discussion thread
Hey guys. Just found out that Alt hold mode uses the "Vel" PIDs in baseflight. Is there any documentation on this? How does it relate to "ALT" in the PIDs? I've been trying to find info to tune it but no can find!!
Thanks
pjman
Thanks
pjman
Throttle midpoint and TPA
After a lot of searching I found that setting the Throttle midpoint in the config does nothing unless you also have Throttle expo....
very disappointing, but easily overcome with TX curves if you are lucky enough to have such...I prefer linear throttle "curves" on my minis
but my problem is that I have a "speedster" setup...250 CF miniquad with 5x4 props and 4s...over 2800 gr WOT thrust on a 350+g frame...it hauls
the issue is that it hovers at 28% throttle...easy fix with a throttle curve...but getting high enough PIDS for stable windy work AND using TPA to prevent punch out (or even uber high speed flight) shaking doesn't work...this is because the throttle pid attenuation curve starts at 1500us, and its hard coded and even independent of the internal Throttle Mid setting....so I can get it stable in wind at hover...and at WOT punch outs, but not in between....the TPA "breakpoint" is defined in the code and would be simple to change to be the same as the config.ThottleMid variable to avoid this...or its a simple define change in the code...but the toolchain and its setup has defied me so far, so I am stuck...my only option now is to cut PIDs, losing windy stablity in order to get marginal, but non-oscillating stability in uber fast forward flight...
EDIT: just discovered that tpa_breakpoint can be set in the CLI! should resolve my issue!
very disappointing, but easily overcome with TX curves if you are lucky enough to have such...I prefer linear throttle "curves" on my minis
but my problem is that I have a "speedster" setup...250 CF miniquad with 5x4 props and 4s...over 2800 gr WOT thrust on a 350+g frame...it hauls

the issue is that it hovers at 28% throttle...easy fix with a throttle curve...but getting high enough PIDS for stable windy work AND using TPA to prevent punch out (or even uber high speed flight) shaking doesn't work...this is because the throttle pid attenuation curve starts at 1500us, and its hard coded and even independent of the internal Throttle Mid setting....so I can get it stable in wind at hover...and at WOT punch outs, but not in between....the TPA "breakpoint" is defined in the code and would be simple to change to be the same as the config.ThottleMid variable to avoid this...or its a simple define change in the code...but the toolchain and its setup has defied me so far, so I am stuck...my only option now is to cut PIDs, losing windy stablity in order to get marginal, but non-oscillating stability in uber fast forward flight...
EDIT: just discovered that tpa_breakpoint can be set in the CLI! should resolve my issue!
Last edited by hwurzburg on Mon Aug 04, 2014 12:04 pm, edited 1 time in total.
Re: Naze32 hardware discussion thread
timecop wrote:Your soldering is pretty crap, maybe you lifted a pad (whichever one is for yaw, CH4? on spektrum). If you're using PWM i don't really see how channel map matters at all just swap the connectors around to follow default order. And if you did waste that pad by soldering, just map it out, i.e. if rc_ch4 (R in default map is dead), just do map AET4R123 - and skip connecting stuff to it.
Thanks TC. Granted - my soldering blows. I was able to map TAE4R123 (Spektrum) and got it to work w/ no problem.
If you recall pad 4 is inoperable. If I were to hook up the Spektrum satellite rx is it mandatory that I use pad 4? According to the wiki, they say use pad 4 only. http://www.netraam.eu/nazewiki/pmwiki.php?n=Howto.HookupASpektrumSatellite
Re: Naze32 hardware discussion thread
Hey Guys,
Just finished my naze32 breakout board.
Wanted to share, if anyone is interested I can provide pcb gerbers/pdfs.
To put all the things into the system that I wanted wiring was a nightmare, so this helps simplyfy a lot.
This board has:
Built in BEC,
VideoIn/Out KVOsd
FrSky Telemetry In/Out
GPS connector
3 Servos (Pan Tilt) out
Mavlink Telemetry (Pins 7/8 soft serial)
Second board takes CPPM and 8V, and turns it into 4x 12V out the relays, swithing on and off
depending on channel assignments (leds, nav lights etc)
Just finished my naze32 breakout board.
Wanted to share, if anyone is interested I can provide pcb gerbers/pdfs.
To put all the things into the system that I wanted wiring was a nightmare, so this helps simplyfy a lot.
This board has:
Built in BEC,
VideoIn/Out KVOsd
FrSky Telemetry In/Out
GPS connector
3 Servos (Pan Tilt) out
Mavlink Telemetry (Pins 7/8 soft serial)
Second board takes CPPM and 8V, and turns it into 4x 12V out the relays, swithing on and off
depending on channel assignments (leds, nav lights etc)
Re: Naze32 hardware discussion thread
Nate0624 wrote:timecop wrote:Your soldering is pretty crap, maybe you lifted a pad (whichever one is for yaw, CH4? on spektrum). If you're using PWM i don't really see how channel map matters at all just swap the connectors around to follow default order. And if you did waste that pad by soldering, just map it out, i.e. if rc_ch4 (R in default map is dead), just do map AET4R123 - and skip connecting stuff to it.
Thanks TC. Granted - my soldering blows. I was able to map TAE4R123 (Spektrum) and got it to work w/ no problem.
If you recall pad 4 is inoperable. If I were to hook up the Spektrum satellite rx is it mandatory that I use pad 4? According to the wiki, they say use pad 4 only. http://www.netraam.eu/nazewiki/pmwiki.php?n=Howto.HookupASpektrumSatellite
Hiya,
yep, only pad 4. And there aren't any good places to solder to it outside the pad, either.

Re: Naze32 hardware discussion thread
Perhaps its because my background is in medicine and not electrical engineering, but I'm always more convinced by empirical evidence than theory. So while I understand timecop (and others) displeasure with oneshot PWM, it's hard to ignore the people that have tried the exact same build with and without oneshot who notice a significant difference. That being said, timecop, if someone (such as myself) were to write the relevant oneshot code in the proper formatting, would you be willing to merge it into the baseflight repository?
Re: Naze32 hardware discussion thread
no, beacuse it serves no purpose.
As plushchi said, you want oneshot, set motor pwm to 400hz, set looptime to match, and done.
also would be very interested in a "review" of oneshot by someone who isn't
1) flyduino / viacopter shill
2) felix the creator
3) warthox the sellout
As plushchi said, you want oneshot, set motor pwm to 400hz, set looptime to match, and done.
also would be very interested in a "review" of oneshot by someone who isn't
1) flyduino / viacopter shill
2) felix the creator
3) warthox the sellout
I'm slightly confused regarding one shot, almost everybody that says it is great seem to do nothing but, hover the quad, give a bit of a wiggle and then fly backwards and forwards very fast and the off few do a flip or two.
Wartox seems to be the only person who does any real flying that recommends it.
I have no need of it with my flying skills but from what I have seen demonstrated it's the emperors new clothes syndrome (at the minute anyway)
Wartox seems to be the only person who does any real flying that recommends it.
I have no need of it with my flying skills but from what I have seen demonstrated it's the emperors new clothes syndrome (at the minute anyway)
Re: Naze32 hardware discussion thread
lost my first Naze yesterday
I have put about 50 packs through my Hex and decided to fly over water for the first time and chase a boat. About 30 seconds in it flipped and sank 14 meters down - I couldn't retrieve it 
So for those who haven't flown over water before - no matter how reliable your rig is - make sure its got some sort of floatation device - at least you will get something back.


So for those who haven't flown over water before - no matter how reliable your rig is - make sure its got some sort of floatation device - at least you will get something back.
Re: Naze32 hardware discussion thread
Thank you, timecop, for having the foresight to put some bootloader pads on the board.
I was having some fun experimenting with some custom code, and somehow managed to stop the normal communication process from working. As this is way outside the scope of what most normal people would be doing, I was expecting to have to try to jerry-rig some kind of STM flashing rig, the equivalent of the old AVR 6 pin SPI interface.
However, once I'd reverted my changes, created a new binary, shorted the bootloader pads and powered up, the firmware flasher was able to get my naze32 operational again. This phrase:
was extremely reassuring earlier tonight
You make some great hardware, much appreciated
I was having some fun experimenting with some custom code, and somehow managed to stop the normal communication process from working. As this is way outside the scope of what most normal people would be doing, I was expecting to have to try to jerry-rig some kind of STM flashing rig, the equivalent of the old AVR 6 pin SPI interface.
However, once I'd reverted my changes, created a new binary, shorted the bootloader pads and powered up, the firmware flasher was able to get my naze32 operational again. This phrase:
This means that's not something a user can break/erase by uploading wrong data etc. If standard update fails, recovery always works as it goes directly to this bootloader.
was extremely reassuring earlier tonight

You make some great hardware, much appreciated

Last edited by nebbian on Wed Aug 06, 2014 3:50 pm, edited 1 time in total.
Re: Naze32 hardware discussion thread
Related to my earlier post is this issue:
I'm trying to get sonar working by using the PWM pins 5 and 6, and I only have a traditional non-ppm receiver.
In the code exists this case statement:
Which leads me to believe that it should be possible to get sonar working with motor pins 5 and 6 (which are free on my quad).
However, in main.c we have these lines:
Is it still the case that sonar only works when PPM is enabled, even if we use the motor pins for the sonar data instead of the rx pins?
I don't understand why this is
Perhaps those pins use the same timer as the motor PWM output or something?
Has anyone gotten sonar working, by using the PWM pins 5 and 6? I'd appreciate any hints
I'm trying to get sonar working by using the PWM pins 5 and 6, and I only have a traditional non-ppm receiver.
In the code exists this case statement:
Code: Select all
switch (config) {
case sonar_pwm56:
trigger_pin = Pin_8; // PWM5 (PB8) - 5v tolerant
echo_pin = Pin_9; // PWM6 (PB9) - 5v tolerant
exti_line = EXTI_Line9;
exti_pin_source = GPIO_PinSource9;
exti_irqn = EXTI9_5_IRQn;
break;
case sonar_rc78:
trigger_pin = Pin_0; // RX7 (PB0) - only 3.3v ( add a 1K Ohms resistor )
echo_pin = Pin_1; // RX8 (PB1) - only 3.3v ( add a 1K Ohms resistor )
exti_line = EXTI_Line1;
exti_pin_source = GPIO_PinSource1;
exti_irqn = EXTI1_IRQn;
break;
}
Which leads me to believe that it should be possible to get sonar working with motor pins 5 and 6 (which are free on my quad).
However, in main.c we have these lines:
Code: Select all
// sonar stuff only works with PPM
if (feature(FEATURE_PPM)) {
if (feature(FEATURE_SONAR))
Sonar_init();
}
Is it still the case that sonar only works when PPM is enabled, even if we use the motor pins for the sonar data instead of the rx pins?
I don't understand why this is

Has anyone gotten sonar working, by using the PWM pins 5 and 6? I'd appreciate any hints
