I'm trying new build with Matek F722-SE and newest inav 2.1-RC1.
All works well when using Oneshot125/42, but when switching to DSOT 150/300/600, when arming motors start, but ~1s later stop. Since then I can disarm/arm multiple times and motors won't start again. Moreover, when entering the motors tab in configurator they don't spin. Before first arm the motors tab work perfectly ok in DSHOT.
I'm using Holybro Tekko32 35A BLHeli_32 ESCs (https://www.banggood.com/4X-Holybro-Tekko32-35A-BLHeli_32-ESC-Dshot1200-2-6S-Build-In-Current-Sensor-For-RC-Drone-FPV-Racing-p-1244743.html?rmmds=myorder&cur_warehouse=CN).
I thought it could be ESC issue, but would all of them stop working exactly in the same moment?
I'm observing the issue on the bench, without props, without load.
My diff:
# diff
# version
# INAV/MATEKF722SE 2.1.0 Jan 9 2019 / 19:36:32 (32fa702b8)
# GCC-7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]
# resources
# mixer
mmix 0 1.000 -1.000 1.000 -1.000
mmix 1 1.000 -1.000 -1.000 1.000
mmix 2 1.000 1.000 1.000 1.000
mmix 3 1.000 1.000 -1.000 -1.000
# servo mix
# servo
# feature
feature -TX_PROF_SEL
feature SOFTSERIAL
feature GPS
feature LED_STRIP
feature BLACKBOX
feature PWM_OUTPUT_ENABLE
# beeper
beeper -ON_USB
# map
# serial
serial 2 2 115200 115200 0 115200
serial 3 4096 115200 115200 0 115200
serial 30 16 115200 115200 57600 115200
# led
# color
# mode_color
# aux
aux 0 0 5 1500 2100
aux 1 2 1 900 1200
aux 2 20 1 1200 1400
aux 3 4 1 900 1075
aux 4 9 0 1250 1500
aux 5 8 0 1500 2100
aux 6 11 1 1500 2100
aux 7 12 2 1700 2100
aux 8 32 2 1300 1700
aux 9 33 2 1700 2100
# adjrange
# rxrange
rxrange 0 1019 2019
rxrange 1 1019 2019
rxrange 2 1019 2019
# osd_layout
osd_layout 0 0 9 1 V
osd_layout 0 1 2 11 V
osd_layout 0 2 0 0 V
osd_layout 0 3 8 6 H
osd_layout 0 4 8 6 H
osd_layout 0 7 15 12 V
osd_layout 0 9 24 0 V
osd_layout 0 11 25 1 V
osd_layout 0 12 9 12 V
osd_layout 0 13 25 5 V
osd_layout 0 14 0 1 V
osd_layout 0 15 1 6 V
osd_layout 0 19 25 2 V
osd_layout 0 20 16 14 H
osd_layout 0 21 4 14 H
osd_layout 0 22 14 1 V
osd_layout 0 23 16 1 V
osd_layout 0 28 21 12 V
osd_layout 0 29 24 1 H
osd_layout 0 30 1 10 V
osd_layout 0 31 0 0 V
osd_layout 0 34 10 1 H
osd_layout 0 40 0 2 V
osd_layout 0 41 0 5 H
osd_layout 0 53 1 14 H
osd_layout 0 54 2 12 V
osd_layout 0 76 1 2 H
osd_layout 0 85 25 6 V
osd_layout 0 87 24 7 H
osd_layout 1 1 22 11 V
osd_layout 1 20 2 9 V
osd_layout 1 21 2 8 V
osd_layout 1 23 2 11 V
osd_layout 1 28 22 9 V
# master
set acc_hardware = MPU6000
set acczero_x = 31
set acczero_y = 8
set acczero_z = -10
set accgain_x = 4108
set accgain_y = 4086
set accgain_z = 4038
set align_mag = CW90FLIP
set mag_hardware = HMC5883
set magzero_x = 99
set magzero_y = -137
set magzero_z = 76
set baro_hardware = BMP280
set pitot_hardware = NONE
set rssi_channel = 9
set motor_pwm_rate = 4000
set motor_pwm_protocol = DSHOT150
set failsafe_procedure = RTH
set current_meter_scale = 179
set model_preview_type = 3
set gps_sbas_mode = AUTO
set deadband = 0
set yaw_deadband = 0
set nav_extra_arming_safety = OFF
set nav_user_control_mode = CRUISE
set osd_video_system = NTSC
set name = KM
set stats = ON
set stats_total_time = 153
set stats_total_dist = 5
set stats_total_energy = 1362
# profile
profile 1
set heading_hold_rate_limit = 50
set thr_mid = 35
set thr_expo = 30
set rc_expo = 60
set rc_yaw_expo = 60
set roll_rate = 85
set pitch_rate = 85
set yaw_rate = 85
# battery_profile
battery_profile 1
@krzysztofmatula Highly suggest not using DSHOT, especially with the F7. Use Multishot instead as it's in many cases faster (as if you can tell) and VASTLY more reliable.
@teckel12 Thanks for the warning. I'm aware of the potential problems with DSHOT.
@krzysztofmatula Great! Use multishot as it's faster than all but DSHOT 1200 and RELIABLE, unlike DSHOT which is an accident waiting to happen.
@krzysztofmatula @teckel12 I just tested on a bench my build with Matek F722-SE with 2.1 RC-1 with following scenarios:
In all those cases motors were spinning on a bench for a least 15 seconds on various throttle levels. There were no propellers tho.
diff for 4kHz DSHOT150:
# diff
# version
# INAV/MATEKF722SE 2.1.0 Jan 9 2019 / 09:13:14 (f8de2e6a3)
# GCC-7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
# resources
# mixer
mmix 0 1.000 -1.000 1.000 -1.000
mmix 1 1.000 -1.000 -1.000 1.000
mmix 2 1.000 1.000 1.000 1.000
mmix 3 1.000 1.000 -1.000 -1.000
# servo mix
# servo
# feature
feature BLACKBOX
feature PWM_OUTPUT_ENABLE
# beeper
# map
# serial
serial 20 1 115200 57600 0 115200
serial 0 32 115200 57600 0 115200
serial 1 64 115200 57600 0 115200
serial 2 0 115200 57600 0 115200
serial 3 0 115200 57600 0 115200
serial 5 0 115200 57600 0 115200
# led
# color
# mode_color
# aux
aux 0 0 2 1300 2100
# adjrange
# rxrange
# osd_layout
# master
set looptime = 250
set gyro_hardware_lpf = 256HZ
set acc_hardware = MPU6000
set acczero_x = 92
set acczero_y = 7
set acczero_z = -105
set accgain_x = 4067
set accgain_y = 4092
set accgain_z = 3983
set mag_hardware = NONE
set baro_hardware = BMP280
set pitot_hardware = NONE
set motor_pwm_rate = 4000
set motor_pwm_protocol = DSHOT150
set model_preview_type = 3
# profile
profile 1
# battery_profile
battery_profile 1
So I suspect this is not software but hardware problem after all
Then, just to be on the same side, I also tested with gyro lpf 42Hz, looptime 500Hz, LEDstrip enabled, Blackbox enabled, SoftwareSerial enabled. In all scenarios, it was working
I'll also test with a minimal config later today.
What's interesting, once it happened that I had no issue, despite multiple tries I did. I even thought it could be related to ESC calibration I did in the mean time. But later on the issue started to manifest again.
I'm not really needing DSHOT, but I'm curious what can be happening.
Tried once again and DSHOT150 worked well. I did multiple arm/disarm cycles.
Power-cycling the quad and... motors don't spin at all, even from the motors tab...
It's something completely random...
I'm getting this same issue now on my F722-SE. After the quad fell out of the sky 30 seconds into the first attempt at running DSHOT600, I switched back to MultiShot again, and flew out an entire pack with no problem. Then, I thought I'd give DSHOT150 a try. Flew out an entire pack on that with no failure (but I did have noticeable oscillation on hard throttle punchouts). Thought this might be because P gains were too high on Pitch and Roll, so I reduced them, and attempted another flight. Motors would not spin on arming. Switched back to Multishot, and the motors would spin. Switched back to DSHOT150, and sometimes arming didn't sound like it completed, and motors wouldn't spin, and sometimes arming would proceed normally and the motors would spin on arming, sometimes they'd spin for a second or two and quit.
I have Spedix 25A BLheli_S ESC's, and they were shipped to me without the signal capacitors installed. I visually verified all four of them. They're flashed with BLheli_S 16.7 with defaults (except the ones attached to motors 2 and 3 are reversed so they spin CCW).
This is probably not relevant, but I also swapped out the FrSky X4RSB and installed a Crossfire Diversity Nano RX.
I just flashed BetaFlight 3.5.5 to my F722-SE, and selected DSHOT300. Motors spin on arming (and man they purr like happy kitties). Plugged and unplugged the battery in ten times, and they spin right up on arming every time. Haven't tested in the air, but I think this verifies there's an issue with the iNAV target and DSHOT for this board.
@Nihilistic Others with the same target have no issues. Probably your ESCs. Honestly, just use multishot and stop the persistent rants. DSHOT is a half-baked protocol even when working.
@teckel12
And yet, this thread was started by another person with the same target as mine, and is having the same issue. Probably more are, but don't care to participate in github, because they get tired of the hassle.
The whole point of reporting issues is to try to drill down on bugs in iNAV and squash them, is it not? We don't post issues as personal attacks on the devs and contributors. I'm putting my own expensive models at risk as a tester, and reporting the results as clearly and concisely as I can to try to help sort shit out.
Your strategy is "hey I'm just gonna use multishot for a year and let everyone else take the hits". Which, I can totally see the sense of, and I'm sure others will do the same. But, that won't help iNAV move forward. Neither will sweeping issues under the rug.
If it's my ESC's, then why do they work fine with BetaFlight? I was flying them on DSHOT600 without a hitch for dozens of flights, and that was before I replaced the old F3 Omnibus with what I was hoping was a leap frog forward.
This is the first time I've actually tested DSHOT on the F722-SE in BetaFlight. And after a dozen armings, the motors spin every time. I thought that might be helpful information. I went to the trouble of loading and configuring BetaFlight to see what would happen, and reported my results here. And what I get for my trouble is told I'm ranting....LOL.
Just because one guy loads up iNAV on the bench, and tests once or twice and DSHOT spins the motors ok, doesn't mean there isn't a problem. I was able to fly a whole pack on DSHOT150 without issue, and the next battery, the motors wouldn't spin at all on arming. It's something intermittent.
Frankly, I have very little interest in DSHOT. Issues related to DSHOT are of low priority to me. I added DSHOT support because a lot of people wanted it. It's there, it's working for me and a bunch of other people. My response to all DSHOT-related issues so far was and probably will be - don't use it, it's unreliable by design.
And the lesson here is...never early adopt a flight controller that relies on this lot to write software for it.
@Nihilistic there is no "lot", there is just a bunch of people interested in hacking this software and making it better. While we try to fulfill users wishes, there is no obligation for us to do so. And comments like your last one reduce our incentive to look into DSHOT issues even further.
Hey, I was never among the crowd that was crying for DSHOT in the first place. I just figured that if you went to the trouble of adding DSHOT, you'd want to get it right. Now we know getting it right doesn't matter to you, which explains a lot.
I'd just like to actually gain something from this $50 purchase. What I got was a processor that's apparently slower than an F4, that can't run DSHOT, and has some weird issue with the barometer. Is the board inherently flawed, or is it the code? And could the code be made right, so that Matek's new baby isn't a dud?
F7 processor support is not perfect in INAV, but it's getting there. F4 is better polished because of much more user exposure. Unfortunately there is no perfect F7 board yet. I won't be surprised if there is some bug in the code that messes up timer DMA on F7 (this will totally break DSHOT & LEDSTRIP).
Drawback of MATEKF722xx boards is that baro is on I2C bus which is inherently slow, hence the feeling of board being "slower". And indeed, high looptimes are impossible on those boards with baro enabled. What's the baro issue you are referring to? Do we have an issue opened for it?
Will comment there
Fixed by #4235
I m also using f722-se with stock setting and dshot300 with blheli32 35a ex鈥檚 on the bench everything is ok and spinning but on fly I tested hovering first about 5鈥漟rom the ground after 10sec of hovering quad fall and wax led off when I checked esc burned then I order 4 more and same thing happened twice I m very upset
@arsalan78m
Per release notes:
Be advised that DSHOT is not well tested on INAV and because of being digital protocol can totally fail on setups with high electrical noise without giving any sign of degradation or motor stuttering.