Naze32 hardware discussion thread

timecop · Post by **timecop** » Sat Jul 12, 2014 9:45 am

acroboard will always drift yaw, there's no temperature or bias calibration in firmware.
if you reconnect it after letting it warm up, the drift will be lessened.

garbungel · Post by **garbungel** » Sat Jul 12, 2014 9:58 am

Hi timecop,

Is anyone going to implement the oneshot code into naze32 like multiwii did?

Regards,
Boris

timecop · Post by **timecop** » Sat Jul 12, 2014 11:30 am

Why don't you spend like 10 fucking seconds searching the thread, to find the reasons why there is absolutely no chance eurohype will be implemented? what's next, you're gonna ask when afroesc/simonk will support "active freewheeling"???

edit: i'll do the work for you:
viewtopic.php?f=23&t=1947&p=46598&hilit=oneshot#p46588
here's the best debunking of oneshot and any possible "benefits" it could ever provide from a non-involved 3rd party.

garbungel · Post by **garbungel** » Sat Jul 12, 2014 11:37 am

timecop wrote:Why don't you spend like 10 fucking seconds searching the thread, to find the reasons why there is absolutely no chance eurohype will be implemented? what's next, you're gonna ask when afroesc/simonk will support "active freewheeling"???

This thread is huge, but will try to check out why you see it as "eurohype".
I saw the code for multiwii and it's no big deal to put it in.
I guess there is this thought that it doesn't make any difference at the end.

Thanks for the quick answer anyway.

EDIT:
Thanks for the link. That explanation is excellent!

theailer · Post by **theailer** » Sat Jul 12, 2014 1:08 pm

timecop wrote:acroboard will always drift yaw, there's no temperature or bias calibration in firmware.
if you reconnect it after letting it warm up, the drift will be lessened.

Crap. It isn't the first time I forget it's a acroboard...

Gaijin · Post by **Gaijin** » Sat Jul 12, 2014 8:13 pm

TC, a couple of questions if you don't mind

First I assume the Naze32Pro is 16v tolerant like the latest naze32's as I ended up with the 6v v3 lite afro escs , also will I need a find DFU cable to hook up ublox GPS which also has a dfu or should I use the usual_Pins 3 & 4? (I thought I saw that in a picture whilst trawling the web the other day)

I haven't had a chance to unpack it yet but everything arrived today, thanks again

treym · Post by **treym** » Sat Jul 12, 2014 8:18 pm

Gaijin wrote:Naze32Pro [..] hook up ublox GPS which also has a dfu or should I use the usual_Pins 3 & 4

hello

naze32Pro as in stm32f303 ? dfu , you mean the jst-zh connector marked as flex port ?

Gaijin · Post by **Gaijin** » Sat Jul 12, 2014 8:41 pm

Ah, yes thats the one, my mistake.
So assuming I can hook anything to it then I need a short cable to connect a crius v3.1 gps, I can't crimp my own micro connectors yet, it's still on my to do list as far as tooling goes

treym · Post by **treym** » Sat Jul 12, 2014 9:04 pm

Gaijin wrote:to hook up ublox GPS should I use the usual_Pins 3 & 4

by default the gps is on the rx/tx pin

if you have FEATURE telemetry in use the gps will use the flex port

if you have the flex port in use ( with some FEATURE spektrum sat or serial rx ) gps will use the rc pin 2 &3

If you configure the gps to ublox , you need a rx/tx serial
if you configure the gps to nmea , you only need rx serial

flex port is actually rx only .. to accommodate ublox gps the code will use rc pin 2 &3 and just ignore the flex port for those that dont use a sekpSat and use ubx gps and telemetry

the code will chose the pin to use as described in https://bitbucket.org/treymarc/baseflig ... ter#cl-101

Gaijin · Post by **Gaijin** » Sat Jul 12, 2014 9:49 pm

Excellent, very helpful, thanks

flex port is actually rx only .. to accommodate ublox gps the code will use rc pin 2 &3 and just ignore the flex port for those that dont use a sekpSat and use ubx gps and telemetry

That's pretty much my usage case you describe there, ublox GPS, PPMSum and MWiiOSD
So assuming the Tx / RX are for the telemetry out to osd, the PPM signal is to the usual pins or can I use the flex for that too?

treym · Post by **treym** » Sun Jul 13, 2014 6:17 am

ppm signal will be the usual rc pin 1

flex port is actually only use for spektrum sat rx ie USART3_RX , it can also be a capture/output timer TIM2_CH4

i will test that once i get a ppm rx

timecop · Post by **timecop** » Sun Jul 13, 2014 11:55 am

Yes, flex could do PPM (theoretically) since it has a timer AF on it.

Gaijin · Post by **Gaijin** » Sun Jul 13, 2014 5:50 pm

timecop wrote:Yes, flex could do PPM (theoretically) since it has a timer AF on it.

I will watch for that in the future then, and the regulator, is it the 16v capable version?

By the way is the flashing routine any different for the Pro, it doesn't seem to show in flash loader, am I still okay to use the chrome based configurator
It lists the pro but is there a regularly released F3 port of baseflight yet or should I stick to what's pre-flashed for now, don't wanna brick it fresh from the packet

Finally, to summarise,with PPMSUM on pin1 (SET PPM) , MWiiOSD on rx/tx (FEATURE telemetry) do I still need to enable (FEATURE serilarx) to shift GPS on pins 2&3 and will the board still recognise my PPM input and not expect a serial input instead

Sorry for all the questions, but there isn't much info out there to find out for myself just yet

treym · Post by **treym** » Sun Jul 13, 2014 6:16 pm

Maybe we should start a NazePro thread

Gaijin wrote: is there a regularly released F3 port of baseflight yet or should I stick to what's pre-flashed for now, don't wanna brick it fresh from the packet

As far as i know , there is no regularly released F3 port of baseflight yet , it is to be build from Source

to flash the nazePro with USB and chromeconfigurator you need to create a DFU image, aside that dfu file generation step, flashing is strictly identical than a naze.
to flash the nazePro with SWD you need to create a HEX image , strictly identical than a naze.

Gaijin wrote:Finally, to summarise,with PPMSUM on pin1 (SET PPM) , MWiiOSD on rx/tx (FEATURE telemetry) do I still need to enable (FEATURE serilarx) to shift GPS on pins 2&3 and will the board still recognise my PPM input and not expect a serial input instead

if the gps is ubx type : with FEATURE telemetry and PPM the board will shift GPS on pins 2&3 (bcause we need a rx/tx)

if the gps is nmea type : with FEATURE telemetry and PPM the board will seet the GPS on the flex port ( since w need rx only)

Thorvald · Post by **Thorvald** » Mon Jul 14, 2014 4:42 am

Loving this flight controller but having a strange problem with my new Rev 5 Naze32 Funfly (Full version).

Background: I normally run a Rev 5 Naze32Acro (Afro32 CLI version 2.2 May 8 2014 / 22:05:34) in my Blackout Mini H Quad and love it. Only fly in acro mode now and this thing is on rails. Decided I wanted to see the altitude on my KVteam minimOSD as well for kicks so I picked up a Rev 5 Naze32.

Setup:
- Blackout Mini H Quad with stock RTF setup (Blackout T-Motors 2300kv's and BS 12amp SimonK ESC's)
- 5x3 Gemfan Props
- 3S 1500 Battery
- MinimOSD with KVTeam firmware 2.3
- EZUHF 4 Channel Rx v1.50
- Taranis Radio (JR Module) with OpenTx 2.05

Steps:
- Flashed it to the latest version at the time (Afro32 CLI version 2.2 Jul 12 2014 / 09:03:13) with Baseflight 0.45 (now use 0.46 as I can now see the bearing to prove compass is good).
- Cleared all settings using Defaults cli command
- Entered all my PID, Aux and CLI settings from my Acro board and confirmed the two CLI dumps match using diff.
- Calibrated Acc, Gyro and Magnetometer without any issues.

Quad flew fine until fast forward flight while pulling back slightly on elevator stick caused the quad to pitch way back (almost standing on its tail) and had to be forced back down with full elevator in the opposite direction.

Re-installed Acro board, flew perfect again, no issues.

Reflashed, recleared, reset all pids settings cli etc, matched Acro perfectly (except for the new lines for current sensor added in the new firmware) and same problem, quad will pitch back when pulling elevator stick back randomly (seems to be in forward flight mostly).

Sample video below showing both OSD and HD video of the issue (Always in Acro mode):

[youtube]https://www.youtube.com/watch?v=CeZbasl0DIQ[/youtube]
https://www.youtube.com/watch?v=CeZbasl0DIQ

Incidents occur at:
00:10 OSD (00:26 HD)
00:39 OSD (01:12 HD)
00:50 OSD (01:23 HD)
00:58 OSD (01:31 HD)

Edit: forgot to add that it also does this at stock/default Pids on the full Naze32 only. Acro is fine.

---

Dump Below:

# dump
Current Config: Copy everything below here...
aux 0 0
aux 1 0
aux 2 8
aux 3 32
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 2048
aux 14 0
aux 15 0
aux 16 0
aux 17 0
aux 18 0
aux 19 4
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
map RETA1234
set looptime = 2500
set emf_avoidance = 1
set midrc = 1500
set minthrottle = 1150
set maxthrottle = 1850
set mincommand = 1000
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 = 0
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 = 43
set vbatmincellvoltage = 33
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 = 90
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 = 6
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 = 90
set rc_expo = 65
set thr_mid = 50
set thr_expo = 0
set roll_pitch_rate = 50
set yaw_rate = 75
set tpa_rate = 40
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 = 3
set yaw_direction = 1
set tri_unarmed_servo = 1
set gimbal_flags = 1
set acc_lpf_factor = 4
set accxy_deadband = 40
set accz_deadband = 40
set acc_unarmedcal = 1
set acc_trim_pitch = 0
set acc_trim_roll = 0
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 = 46
set i_pitch = 55
set d_pitch = 30
set p_roll = 40
set i_roll = 45
set d_roll = 25
set p_yaw = 90
set i_yaw = 50
set d_yaw = 8
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

---

Since I can easily re-produce the issue, is there a way to log everything in flight to help track the cause down?

EDIT: As was suggested by a few people to try the same firmware level as my Acro, I simply didn't know where the hex files were archived. Once I found that, flashed to May 8 2014 / 22:05:34 version and sure enough, it flies good now. So something must have changed in a later firmware, time to dig.

Thanks
Tim

wolfeyes · Post by **wolfeyes** » Mon Jul 14, 2014 10:55 am

Hi, So I have a problem with the Yaw. When I connect the FC to Baseflight the part that shows you the live direction of the FC it just spins very fast on the yaw axis. I then hooked everything up with props and went to take off and again it just wants to spin around and around. I have checked over everything and starting to think that I might have a broken FC. Any help Thanks.

timecop · Post by **timecop** » Mon Jul 14, 2014 11:08 am

define "very fast"?
It will spin < degree/few seconds on yaw axis in the graph.
for sure, your RC inputs are centered at 1500 or midrc, right?

lunithy · Post by **lunithy** » Mon Jul 14, 2014 12:05 pm

wolfeyes wrote:Hi, So I have a problem with the Yaw. When I connect the FC to Baseflight the part that shows you the live direction of the FC it just spins very fast on the yaw axis. I then hooked everything up with props and went to take off and again it just wants to spin around and around. I have checked over everything and starting to think that I might have a broken FC. Any help Thanks.

When mine did this it was the prop rotation! every one was opposite to instructions :oops:

you could revers yaw or revers every prop

.
OH and Timecop I need some new boards and there are none in AU mate pls.

FPVGump · Post by **FPVGump** » Mon Jul 14, 2014 6:47 pm

Great FC TC.
I'm new to this forum so I hope I don't sound too stupid.
1) I've seen some mini's with the FC mounted forward of the CG or forward of the cross section of the motors and I'd like to mount mine that way too. Is it ok to just mount it that way or are there any parameters I need to change in the CLI to let it know about the position relative to the CG and if so where can I find them? I've seen the options to change orientation but not forward of CG.
2) I want to mount one in a Hunter 'V' tail but it apperantly isn't an option right? I see how to mount to a 'Y' but not a 'V'. Is it possible to mount in a 'V'?
Thanks.

Thorvald · Post by **Thorvald** » Mon Jul 14, 2014 11:03 pm

As was suggested by a few people to try the same firmware level as my Acro, I simply didn't know where the hex files were archived. Once I found that, flashed to May 8 2014 / 22:05:34 version and sure enough, it flies good now (thanks guys!). So something must have changed in a later firmware, time to dig.

washout · Post by **washout** » Mon Jul 14, 2014 11:29 pm

I appear to have fried something on the board as it won't power up via ESC connections but will via USB. I have rigged a cable to pass power round the board but wondered if there is a simple and more appropriate fix? I'm guessing a regulator is dead but have no idea what I should test and have limited soldering equipment to make repairs with.

FPVGump · Post by **FPVGump** » Tue Jul 15, 2014 1:05 am

Were you using 12a afro ESC's from HK? TC posted that HK installe 6V ESC chips instead of 5V. If you conected your FC with these you probably fried something.

washout · Post by **washout** » Tue Jul 15, 2014 9:03 pm

Yep, afro 12s. It didn't fry immediately, got a few flights in so don't know if maybe it was on the edge of the magic smoke then just gave up when luckily it was on the bench and not in the air. Still want a better fix than my current fudge.

cherokee180c · Post by **cherokee180c** » Wed Jul 16, 2014 2:33 am

I am trying to troubleshoot a problem with the AcroNaze32 telemetry connection to a Taranis running the new OpenTx 2.0.5 and a D4R-II reciever. I am trying to get pack voltage through the telemetry. Here is a summary of my status:
PPM enabled, Vbat enabled, Telemetry enabled, Telemetry_provider=0, Telemetry_port=0

Verified the following:

1. Wired correctly. Baseloader is seeing the pack voltage correctly through the voltage monitoring pins.
2. No telemetry through the Fr Sky pins at all.
3. D4R-II telemetry verified working through softserial connection as I can see accelerometer values changing in realtime. However, I still can not locate the pack voltage signal in this configuration.

I would like to get the pack voltage working through the dedicated FrSky pins as I want to set gimbal_flags=4 to allow the use of a lost model alarm on Channel 6. I believe from reading that the USB port uses the same physical UART as the FrSky pins use, however the board is supposed to switch to 9600 baud from 115200 after disconnect, and since baseloader is working fine, I assume my UART is working fine.

Questions:
1. Which variable should the pack voltage show up under on the Taranis / OpenTx 2.0.5? I would like to verify that this works under the SOFTSERIAL setup option.
2. What if anything could prevent the FrSky pins from working correctly? Is there any settings I need to re-verify? I reset the entire board and followed the wiki again to the letter and still no telemetry on these pins.

I just got the board a week ago, so running V2.3

Thanks

timecop · Post by **timecop** » Wed Jul 16, 2014 2:45 am

The pack voltage value we're sending is for the FLVS cell data.
on FLD-02 screen, its the last page (that only shows up after a few seconds of arming since data is not sent continuously).
The "main screen" voltage value comes from ADC on the receivers itself - and D4R doesn't have that

FPVGump · Post by **FPVGump** » Wed Jul 16, 2014 2:47 am

timecop wrote:Quick naze32 setup instructions:
1) Put in center of quad
2) Plug stuff in
3) Arm, check motors spinning correct directions, swap if not
4) Put on props
5) go fly

Found my answer

pjman · Post by **pjman** » Wed Jul 16, 2014 10:59 am

Well I got my Acro Naze32 last week and its amazingly easy to setup and flies really well out of the box. Had a few good flights with it already but its still wobbling a little bit as you can see in the video - its just not a smooth as others.

https://www.youtube.com/watch?v=5X323EY ... jAJjj1fAIQ
https://www.youtube.com/watch?v=p8jhpN1 ... jAJjj1fAIQ

Today the full board arrived so I put that on. I covered the baro and am really happy that it responds well to alt changes but if I blow on it there is little change. Below is a vid of the alt hold. It is holding the altitude within a reasonable amount however the reactions are pretty severe rather than smooth - this makes it a bit jumpy. I have been trying to find info on how to tune the alt hold but it seems a bit of a black art. With the multiwii I was playing with I think D was the accelerometer, P wasa teh Baro and I was for battery voltage. Is it the same on the Naze? The default PIDS I had were P=5, I=0 and D=0 I took a quick vid tonight but its hard to see the jumping - you can hear it more than see it. Planning to screen capture the graphs tomorrow to see if you guys think the vibrations are low enough.

Any help would be good. I'll go back to searching and trying to find the info myself - Damn you Timecop - the Naze is too good out of the box so no one needs to make tune vids!!!!!!!!

https://www.youtube.com/watch?v=3iuS2gg ... e=youtu.be

cherokee180c · Post by **cherokee180c** » Wed Jul 16, 2014 11:23 am

PID tuning has nothing to do with the variables you quote. Do some reading on the effects of each. There are plenty of sources and even videos on youtube for quads. In general if you are getting too much correction, lower the P value and until corrections are smoother. Then you may need to raise the I value only a very small amount at a time to tune the response. Someone who has turned Altitude hold may be able to give you a good starting point.

strips · Post by **strips** » Wed Jul 16, 2014 11:43 am

pjman wrote:Well I got my Acro Naze32 last week and its amazingly easy to setup and flies really well out of the box. Had a few good flights with it already but its still wobbling a little bit as you can see in the video - its just not a smooth as others.

https://www.youtube.com/watch?v=5X323EY ... jAJjj1fAIQ
https://www.youtube.com/watch?v=p8jhpN1 ... jAJjj1fAIQ

Today the full board arrived so I put that on. I covered the baro and am really happy that it responds well to alt changes but if I blow on it there is little change. Below is a vid of the alt hold. It is holding the altitude within a reasonable amount however the reactions are pretty severe rather than smooth - this makes it a bit jumpy. I have been trying to find info on how to tune the alt hold but it seems a bit of a black art. With the multiwii I was playing with I think D was the accelerometer, P wasa teh Baro and I was for battery voltage. Is it the same on the Naze? The default PIDS I had were P=5, I=0 and D=0 I took a quick vid tonight but its hard to see the jumping - you can hear it more than see it. Planning to screen capture the graphs tomorrow to see if you guys think the vibrations are low enough.

Any help would be good. I'll go back to searching and trying to find the info myself - Damn you Timecop - the Naze is too good out of the box so no one needs to make tune vids!!!!!!!!

https://www.youtube.com/watch?v=3iuS2gg ... e=youtu.be

Yup. Listen to cherokee. You need to read up on general PID algorithms to get a grip what they are. Then you'll get the bits and pieces together.

Basically PID algorithms are for applying/adjusting power in some way. Every function needed to be controlled has its own PID-settings. There is not just one of each P, I and D.

But i totally agree with you, timecop has made some awsome hardware and software for us

cherokee180c wrote:PID tuning has nothing to do with the variables you quote. Do some reading on the effects of each. There are plenty of sources and even videos on youtube for quads. In general if you are getting too much correction, lower the P value and until corrections are smoother. Then you may need to raise the I value only a very small amount at a time to tune the response. Someone who has turned Altitude hold may be able to give you a good starting point.

pjman · Post by **pjman** » Wed Jul 16, 2014 11:55 am

I should have been a bit more clear. I have tuned PIDS on multiwii but always started at Zero on I and D and went from there. I'll do as you say and start lowering rather then increasing values.

The values I was talking about are referring to Alt hold in Multiwii

I changed the default P of 5 from 0 to 100 and couldn't see any difference.

timmytron · Post by **timmytron** » Thu Jul 17, 2014 1:31 am

Quick one blokes.

Naze Acro takes 5.5v max.

The ESCs I'm using are the Afro 12a Lite's, the batch that has the 6v BEC. ZzZzz

With a diode on them, the voltage is reading at 5.65v with a multimeter.

Does the voltage input bare any tolerance? Should I add another diode to step it down further or is 5.65v close enough? (that'll do donkey).

Also, if I was to just leave the BECs as is and run 6v into the Acro, what is the expected long term behavior, would it just eventually kill itself or would it start causing random, hard to explain glitches and faults?

timecop · Post by **timecop** » Thu Jul 17, 2014 1:39 am

Add another one. absolute max is 5.5V.

Thorvald · Post by **Thorvald** » Thu Jul 17, 2014 1:41 am

Thorvald wrote:As was suggested by a few people to try the same firmware level as my Acro, I simply didn't know where the hex files were archived. Once I found that, flashed to May 8 2014 / 22:05:34 version and sure enough, it flies good now (thanks guys!). So something must have changed in a later firmware, time to dig.

Thanks TC, this is fixed in the July 16 2014 firmware.

Cheers
Tim

pjman · Post by **pjman** » Thu Jul 17, 2014 4:30 pm

Can someone please confirm that PID tuning for Naze is exactly the same as Multiwii 2.3 for setting other then pitch/roll/yaw?

Thanks

Brenden

ArrogantDuck · Post by **ArrogantDuck** » Thu Jul 17, 2014 6:16 pm

I've used the multiwii documentation for my tuning and it is rock solid as a method for tuning a Naze32.

friesianflyer · Post by **friesianflyer** » Thu Jul 17, 2014 10:21 pm

Hi everyone, have a few naze32s that are working perfectly - thanks TC.....

I have just built a 250 sized quad with a frsky d4r-ii rx, and am using the soft serial connection to send telemetry to my Taranis.

My question is, what data is being sent by the naze? I have battery voltage and barometer altitude working fine, but wondered if there are any other parameters available? eg: current estimation, heading .......

Thanks in advance for any help.

pilotxj · Post by **pilotxj** » Fri Jul 18, 2014 2:24 am

treym wrote:
Gaijin wrote:to hook up ublox GPS should I use the usual_Pins 3 & 4

by default the gps is on the rx/tx pin

if you have FEATURE telemetry in use the gps will use the flex port

if you have the flex port in use ( with some FEATURE spektrum sat or serial rx ) gps will use the rc pin 2 &3

If you configure the gps to ublox , you need a rx/tx serial
if you configure the gps to nmea , you only need rx serial

flex port is actually rx only .. to accommodate ublox gps the code will use rc pin 2 &3 and just ignore the flex port for those that dont use a sekpSat and use ubx gps and telemetry

the code will chose the pin to use as described in https://bitbucket.org/treymarc/baseflig ... ter#cl-101

Hi treym. I have a spek sat and a ublox gps. I have feature serialrx, GPS, and telemetry in use. I tried putting my gps on 2 and 3 but it doesn't seem to work. The gps is confirmed as working by turning off serialrx and using 3 and 4. Am I missing something? Thanks for your time.

timecop · Post by **timecop** » Fri Jul 18, 2014 2:24 am

Of course it won't work. How do you expect serialrx and GPS on same port to be usable?

pilotxj · Post by **pilotxj** » Fri Jul 18, 2014 2:30 am

timecop wrote:Of course it won't work. How do you expect serialrx and GPS on same port to be usable?

Treym suggested that the code would shift gps to pins 2 and 3 in his post. I read further back where you said it wouldn't work, and accepted that. Then I saw treym's post, so I had to try it. Thanks for the response tc, and thanks for a great board.

treym · Post by **treym** » Fri Jul 18, 2014 2:43 am

that was for the nazePro ..

If you want serialrx and GPS on the naze , you can use softserial , see https://github.com/multiwii/baseflight/pull/108

pilotxj · Post by **pilotxj** » Fri Jul 18, 2014 2:55 am

treym wrote:that was for the nazePro ..

If you want serialrx and GPS on the naze , you can use softserial , see https://github.com/multiwii/baseflight/pull/108

Ah that explains it. Thank you sir.

servili007 · Post by **servili007** » Sat Jul 19, 2014 3:32 am

I did some searching but don't seem to be finding info on the correct/accepted way to set up sonar on the naze. Hopefully I didn't miss anything obvious, but basically I want to know if I should use pins 7&8 with 1k resistors like others have stated in the past, or if there's some other setup available (since the only reference to sonar in the manual is to a pad on the bottom of the board). Thanks.

timecop · Post by **timecop** » Sat Jul 19, 2014 3:40 am

The code hasn't been updated to allow using GPIOFT pin. So yeah, for now all you can do is pins 7/8.

servili007 · Post by **servili007** » Sat Jul 19, 2014 4:06 am

timecop wrote:The code hasn't been updated to allow using GPIOFT pin. So yeah, for now all you can do is pins 7/8.

Roger, thanks for the heads up! The board is excellent and very well designed, I'm really enjoying it.

JWnsb · Post by **JWnsb** » Sat Jul 19, 2014 6:00 pm

Hello,
Great thread and I love the acro naze. I'm having a problem that I can't figure out and I'm hoping for some help. i've searched for 3 weeks on every thread and google search imaginable and posted the issue on 2 other threads. I'm stumped. Somewhat of a noob here and so it may be simple. I don't care if I get berated- I've hit the wall :mrgreen:

The problem is a twitch in the receiver and motors. It hovers ok but it's fighting the to stay level and will yaw clockwise randomly, sometimes severely. Battery doesn't last as long and gets a little warm.
In the receiver tab in baseflight, once powered up, the midpoints on all channels jump around by a few digits (midpointrc is set at 1500)
In the motor tab, when i test the motors with the slider it's smooth (ESCs calibrated), but when I arm the board and throttle with the tx the motors jump around all crazy.
Here is a video of what it looks like in Baseflight:
http://youtu.be/qxwFr6gfY7k

here's my set up:
250mm hammer frame
12a ice blue esc with sk (witespy says they're optimized for sunnysky motors, so no desync)
RCtimer 1806 2300kv motors
acro naze rev5
1300-1500 3s 30c lipo
Frsky v8fr-II rx
9XR tx with Frsky DJT module

I orininally built this with rcx motors and ESCs and didn't have this issue. I wanted more thrust for my FPV gear and mobius so I switched to RCtimer motors and ESCs and that's when the problem started.

Here's what I've tried already to fix the issue:
made sure baseflight is updated
reflashed firmware. reset to default. reclibrated everything . shorted the bootloader and started from scratch. I even purchased a new acro naze. same problem.
seems like an rx/tx issue, but i tried an entirely different rx/tx combo that is working perfect on another quad with similar components. same problem
I swapped ESCs from RCtimer to the witespy ESCs and resoldered everything. same
I've tested 7 different batteries. same
switched back to rcx motors. same

I'm not using a distro board- I soldered my own wiring harness. But those joints are solid. Plus the motors spin perfect with the slider in baseflight so it seems like that can't be the issue.

What am i missing or doing wrong? :shock:

Thanks in advance!
Jason

strips · Post by **strips** » Sat Jul 19, 2014 9:18 pm

JWnsb wrote:Hello,
Great thread and I love the acro naze. I'm having a problem that I can't figure out and I'm hoping for some help. i've searched for 3 weeks on every thread and google search imaginable and posted the issue on 2 other threads. I'm stumped. Somewhat of a noob here and so it may be simple. I don't care if I get berated- I've hit the wall

The problem is a twitch in the receiver and motors. It hovers ok but it's fighting the to stay level and will yaw clockwise randomly, sometimes severely. Battery doesn't last as long and gets a little warm.
In the receiver tab in baseflight, once powered up, the midpoints on all channels jump around by a few digits (midpointrc is set at 1500)
In the motor tab, when i test the motors with the slider it's smooth (ESCs calibrated), but when I arm the board and throttle with the tx the motors jump around all crazy.
Here is a video of what it looks like in Baseflight:
http://youtu.be/qxwFr6gfY7k

here's my set up:
250mm hammer frame
12a ice blue esc with sk (witespy says they're optimized for sunnysky motors, so no desync)
RCtimer 1806 2300kv motors
acro naze rev5
1300-1500 3s 30c lipo
Frsky v8fr-II rx
9XR tx with Frsky DJT module

I orininally built this with rcx motors and ESCs and didn't have this issue. I wanted more thrust for my FPV gear and mobius so I switched to RCtimer motors and ESCs and that's when the problem started.

Here's what I've tried already to fix the issue:
made sure baseflight is updated
reflashed firmware. reset to default. reclibrated everything . shorted the bootloader and started from scratch. I even purchased a new acro naze. same problem.
seems like an rx/tx issue, but i tried an entirely different rx/tx combo that is working perfect on another quad with similar components. same problem
I swapped ESCs from RCtimer to the witespy ESCs and resoldered everything. same
I've tested 7 different batteries. same
switched back to rcx motors. same

I'm not using a distro board- I soldered my own wiring harness. But those joints are solid. Plus the motors spin perfect with the slider in baseflight so it seems like that can't be the issue.

What am i missing or doing wrong?

Thanks in advance!
Jason

I've had strange twitching and random yaw when I tried som off balanced props. Vibrations can cause this. Test one motor with prop at a time in Baseflight Configurator and hold the frame. There should be moderate vibrations from any of them. Just be careful when throttling the motors so you don't cut yourself!

JWnsb · Post by **JWnsb** » Sat Jul 19, 2014 9:52 pm

thanks for the reply Strips.

That makes sense, and I've thought about prop balance, but it doesn't explain the twitch in the receiver or the motors when the props are off. Plus the motors spin smooth when I check using the slider in baseflight. They are only twitchy when I throttle with the tx whether the props are on or off.

strips · Post by **strips** » Sat Jul 19, 2014 11:32 pm

JWnsb wrote:thanks for the reply Strips.

That makes sense, and I've thought about prop balance, but it doesn't explain the twitch in the receiver or the motors when the props are off. Plus the motors spin smooth when I check using the slider in baseflight. They are only twitchy when I throttle with the tx whether the props are on or off.

Have you calibrated the tx sticks? Sounds like this would be better asked in a dedicated forum for your tx/rx.

KC_703 · Post by **KC_703** » Sun Jul 20, 2014 3:29 am

JWnsb wrote:Hello,
The problem is a twitch in the receiver and motors. It hovers ok but it's fighting the to stay level and will yaw clockwise randomly, sometimes severely. Battery doesn't last as long and gets a little warm.
In the receiver tab in baseflight, once powered up, the midpoints on all channels jump around by a few digits (midpointrc is set at 1500)
In the motor tab, when i test the motors with the slider it's smooth (ESCs calibrated), but when I arm the board and throttle with the tx the motors jump around all crazy.

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.

JWnsb · Post by **JWnsb** » Sun Jul 20, 2014 3:51 am

Have you calibrated the tx sticks? Sounds like this would be better asked in a dedicated forum for your tx/rx.[/quote]

Yep sticks are calibrated. In the other forum they said they same, but about the FC