I have 2 Omnibus boards, an F4-pro and an F4-V3 by Eachine. In the documentation the instruction can be found that with all receiver types, DSM, PPM or SBUS, the solderpads for type selection should be selected for PPM in which case ardupilot will autoselect the correct type. With the F4-pro this works, however with the F4-V3-Eachine it behaves unexpectedly.
When the PPM (or SBUS) solderpads are connected at boot the board hangs in initializing phase (repeated entries in the log). When NONE of the solder pads are connected it boots completely but the board does not repond to the receiver. It starts responding to the receiver commands AFTER the PPM pads are connected AFTER the boot proces is completed.
Of course this can be solved by adding a hardware switch to the solderpads but I’d prefer if the receiver type is autodetected.
BTW I’ve tested it with 4.1.3 and 4.2 versions, behaviour is the same.
Try BRD_ALT_CONFIG to 3 or 4 and configure one of the URTS for RC Input?
@dkmxr, thanks for taking the effort to reply!
I’m still quite new to the ardupilot ecosystem and cannot fully translate your advise into action. I’ve found the BRD_ALT_CONFIG and I understand that, reading hwdef.dat, that this should reroute some functions to PA0 and PA1 (when I select alt 3). But the definition of PB8, the original RCIN, is completely different. So I’m a bit puzzled which other configuraton parameters I should alter to have my RCIN connected to PA1. Is there any place where I could read about the anatomy of hwdef.dat and the syntax used?
Hi Mike- After monkeying around with some Omnibus boards and still one flying with a Nano V6 I’m not much of a fan of Airbot but try this:
BRD_ALT_CONFIG 3
RCIN on PA1 as you state. From the Hwdef (PA1 UART4_RX UART4 ALT(3))
So from Wiki: SERIAL4 = GPS2 = UART4
Then set: SERIAL4_PROTOCOL to 23
Kind of winging it here but it seems logical 
I’m not sure if inversion is requiered. That’s the annoying thing about F4’s, can’t do it in firmware. Buy an H7!!
Youre quite right @dkemxr, the boards have their limitations (and flaws), but due to their price they are a good point to start with some experiments.
I have now tested various options without succes:
- your suggested settings (experimented with the serial4 options (inverted, pulldown) on AP 4.1.3
- and other settings with recompliled 4.2 firmwares, creating two new ALT settings:
PA1 TIM2_CH2 TIM2 RCININT PULLDOWN LOW ALT(5)
PA1 UART4_RX UART4 RCININT PULLDOWN LOW ALT(6)
But none of both options made the flightcontroller listen to RC-signals on PWM5 pin. Do I still miss options or are there options I could try?
In the documentation it is also suggested to desolder a resister associated with the SBUS channel. Could this resistor, I have not desoldered any resistor as yet as I do not know where to find this one, be the target? How can I determine which resistor this could be?
Those options won’t work on an F4 processor, they are not firmware configurable. That’s why I suggested buying an H7 based FC. The documentation from Airbot is so poor that who knows how that F4-V3 is configured.
Advise well taken, @dkemxr! The problem is I want to stick with low power consumption (it’s meant for a mini octo, mostly as experiment) and of course sufficient ram to load ardupilot. I have not found any F7 which runs on 2S with 1M of flash. So still it would be great to get this F4 working. Actually this version is Eachine, not Airbot, but from documentation perspective there seems to be little difference between these companies. Weared thing is that I do also have an airbot omnibusf4pro which actually has no problem at all with the recognition of the receiver.
I’m still not sure if the symptoms are a result of the hardware design of the board or if it is due to some defective components on the board.
The actual case is that when I boot the board (with reciever powered but not connected) and plug in the receiver signal line after boot is complete, it works fine. Otherwise it hangs in an ‘initializing ardupilot’ loop. So would it be possible to activate the PB8 pin some seconds later, just by changing parameters in the ardupilot MP configuration or by adding some lines to hwdef.dat without having to dive too deep into the actual
This is bizar. Today tried, with the newly compiled default 4.2 omnibusf4 firmware but now with an SDcard in the slot. Now it works correctly. I have no clue, but problem seems to be solved. Does not increase my confidence in the reliability of these FCs…
Forget the F7! The Matek H743-Mini runs on 2S. I flew a sub250g 5" on a Li-ion 2S for awhile. It’s on 3S Lipo now but no problem then.
@mbosschaert did you set anything extra for f4v3s and SBUS? i have the same problem, my SBUS is not working.
Sorry, actually cannot remember exactly which settings I used, but I think I did not solder the SBUS pad as indicated in the manual. I had to quit the project as I blew all of my f4v3s boards during the experiments, sadly.
Thanks for reply, i solved problem. I solder the pad to PPM according to the manual. When i connecting SBUS recivier i also have GPS on port UART6 and only GPS working, when I disconnect GPS from UART6 SBUS working. Finally i changed BRD_ALT_CONFIG to 3 and I use port PWM5 an RSSI to my GPS on UART4 and I left SBUS on UART6.