Speed control(pwm1)…Elevator servo (pwm3) … single aileron ( either pwm4 or 5 ) work fine…no response on pwm6…checked with scope signal is at 5v constant.
Servos powered from ESC on a separate bus with common ground and individual servo signal lines back to the controller.
Servos all tested and working fine.
Tried now on 2 different flight controllers (both Omnibus F4 Pro) …exact same result.
Ok…I’ll try that then.
Had been following a tutorial by Painless360 where he said to use ( and seemed logical given it is for an aircraft) arduplane_with_bl hex
Have read most of what applies to the board but didn’t see mention of using this particular bootloader you recommend.
Then again there is a lot and might have missed it. Thanks
I would suggest using DFU-UTIL to flash the bootloader 1st and then Mission Planner to flash Arduplane. It’s described here on the Omnibus page: Flash the bootloader 1st.
The problem with anything called Omnibus is it can be a mystery what actual hardware version it is no matter what it’s called.
That is the one i used.
Have tried on 3 boards now with the same end result …no servo movement on 6 (rudder)
Might end up in the too hard basket as none of these boards are really supported anymore I’d imagine.
Was a way of using what I have here and you would be the only answer I have received.
Might have another attempt next weekend although the street appears to be still a dead end.
Cheers Jorgo
Ok…will look at that then as it seems only way out of the “dead end street” …cheers Jorgo
Is this “DFU_UTIL” on the same web page of somewhere else???
Edit: Clicked on the “DFU UTIL” highlighted in the omnibus page, it flickered and did nothing…looking below in the task bar it was supposed to link to sourceforge.net but no…
The manner of flashing is irrelevant if the board boots properly (which it appears to). Once the ChibiOS bootloader is present (which it appears to be), Mission Planner can handle flashing updates or alternate targets.
This outcome doesn’t make much sense, so long as you are using the correct firmware. Provide a parameter file or LOG_DISARMED .bin log for analysis.
I do tend to agree with Dave that many (or even all) of these F4 autopilots are poorly suited to recent versions of ArduPilot. It’s probably an unpopular opinion, but I would advocate for deprecating support (probably a separate topic, so let’s not get too derailed with opinion here).
From Michael Oborne on Discord just now - Mission Planner should support DFU mode flashing as well (something I did not know).
Direct quote:
open MP.
goto fw screen.
connect board.
click load custom FW.
select a .hex;.bin;*.dfu file
go
On the “connect board” step, you’d obviously connect in DFU mode. And you’d certainly want to choose a file with “_bl” in the name.
If it fails, you may need to install libusb. MP does not include it during its own install, and it is a requisite for DFU mode flashing within MP. Michael said he’ll look into packaging it as part of the MP installer.
Support for .dfu, .hex, and .bin flashing in DFU mode was added 2 years ago:
Nevermind what I said above about sharing logs. It’s the wrong firmware. I missed the part about the config error. I don’t know which target to recommend.
Can you tell which barometer chip is in use by looking at the silkscreened part numbers?
It fails. Packaging into MP would be a good idea as many users will stumble at this step. Even with the Libusb device driver installed for the STM32 Bootloader it fails.
And that driver hosed up the Betaflight Configurator.