Originally Posted by wkf94025

I've only got a few minutes, and don't know half what @sh83 does on the Omnibus boards (and other HW), but here's what I know:


I have Omnibus F4 V3 and V5 boards. On the V3, there are solder pads one needs to jump to get SBus in. On the V5, no pads. Not sure what the method is there. F4Light HAL was auto-detecting SBus, obviating the need to dive deep on that then.


Kelly

Kelly this is contrary to my understanding ,AND how my own Omnibus F4 Pro V3 system is running....shorting to the SBUS pad for RX input instead of the PPM effectively eliminates the UART1 functionality for telemetry for Omnibus F4 V3 pro/non-pro boards....
and an Ominbus F4 non-pro (AIO) V5 board should need an entirely different hardware define and firmware since the RX is connected UART6 inverted input not the PIO pad for PPM or the UART1 inverted RX pin as in the Omnibus F4 Pro (or AIO non current sense version) V3

from the HWDEF file for the board
"# "PPM" solder pad/resistor should be soldered and "S-BUS" resistor/solder pad removed
# Overwise UART1 or UART6 or RCIN will not work"

fyi...this means the Airbot/GetFPV V5 AIO board should have issues....but the ReadyTo Fly Quads V5 board, which still has jumpers should be able to work with this board firmware....

the Omnibus board environment is really messy....but it is the cheapest solution still

@atx, I trust your knowledge here more than my own. I know that I soldered jumper pads on one of my earlier Omnibus F4 Pro [V2?] and that that was key to SBus in. But there are a number of variants on that FC, and the UART conflict is famous on many such boards.

Kelly

Originally Posted by Atx_Heli

Be absolutely sure that the min and max channel values for each OSD screen is really where the channel sits....and enable the switching and mode in the OSD parameters section

Also ensure OSD_SW_METHOD = 1 (0 means that it switches screen with any input change on the designated channel, 1 means honour the min/max pwm values you set for each OSD screen.

Originally Posted by wkf94025

@atx, I trust your knowledge here more than my own. I know that I soldered jumper pads on one of my earlier Omnibus F4 Pro [V2?] and that that was key to SBus in. But there are a number of variants on that FC, and the UART conflict is famous on many such boards.

Kelly

On the v3 board there is a jumper to solder (solder to the PPM side allowing SBUS to work on the first servo connector, and allowing UART1 to work for telemetry, disconnecting this port from non-inverted SBUS functionality - via soft-serial I believe) Its confusing that you solder the PPM jumper and this allows SBUS to work - this is because Ardupilot handles the port's protocol - the jumper set this way is just to free up the UART1 for telemetry.
On the v2 board, a resistor needs to be removed to disconnect SBUS from the UART1 port, again SBUS input on the first servo connector, and UART 1 available now for telemetry)

Did you have sdcard in fc?

Yes, I had an SD card. Fc OMNIBUS F4PRO V2 . Full login enabled. EKF disabled.

CHIBIOS 1 (2 min 21 sec)

I tested the ChiBios Ardupilot firmware w/OSD today. To save time, I loaded the saved parameters from my NG HAL Ardupilot version and verified everything was working on the ground...no problems.

Today was the 'maiden' flight and no issues in the flight control. GREAT!!!! The OSD (mostly) worked as expected...save the fact I have to manually covert metric to imperical...but I know that's in work. I did come across one issue with the OSD.

Towards the end of my flight I got a Low Bat and mAh used warning. I'll have to look into where I can adjust those settings in MP. Anyway, the issue was when the voltage and mAh warnings displayed the voltage and mAh readings in the OSD disappeared...and never came back. I tried changing OSD screens, but the missing info remained missing.

I remember a similar issue with iNav (I believe) that would hide readings after a warning was activated for that reading. There was a way to force it to remain displayed (forced blink or something like that). I'm curious if the disappearing readings has some sort of parameter setting fix or something in the OSD portion of the firmware itself. Below is my GS recording of the event.

I plan on trying the Terrain Following mode in my next flight test. So far everything is looking good. Thanks guys!!!!

OSD Issue (0 min 21 sec)

Originally Posted by Vantasstic

I tested the ChiBios Ardupilot firmware w/OSD today. To save time, I loaded the saved parameters from my NG HAL Ardupilot version and verified everything was working on the ground...no problems.

Today was the 'maiden' flight and no issues in the flight control. GREAT!!!! The OSD (mostly) worked as expected...save the fact I have to manually covert metric to imperical...but I know that's in work. I did come across one issue with the OSD.

Towards the end of my flight I got a Low Bat and mAh used warning. I'll have to look into where I can adjust those settings in MP. Anyway, the issue was when the voltage and mAh warnings displayed the voltage and mAh readings in the OSD disappeared...and never came back. I tried changing OSD screens, but the missing info remained missing.

I remember a similar issue with iNav (I believe) that would hide readings after a warning was activated for that reading. There was a way to force it to remain displayed (forced blink or something like that). I'm curious if the disappearing readings has some sort of parameter setting fix or something in the OSD portion of the firmware itself. Below is my GS recording of the event.

I plan on trying the Terrain Following mode in my next flight test. So far everything is looking good. Thanks guys!!!!

https://youtu.be/LzhW3fYrMJE

Van, look at the Batt_low_x and Batt_crt_x parameters....those are being used now to flash voltage and mah, I think....
Also, the dev team is now aware of the flash issue and is considering moving to software blink vs the hardware blink (a known issue in Inav which was fixed with optional software blink capability)
Rssi is hard coded to blink below 5% but that will eventually be programmable also, I think...

Originally Posted by Atx_Heli

Van, look at the Batt_low_x and Batt_crt_x parameters....those are being used now to flash voltage and mah, I think....
Also, the dev team is now aware of the flash issue and is considering moving to software blink vs the hardware blink (a known issue in Inav which was fixed with optional software blink capability)
Rssi is hard coded to blink below 5% but that will eventually be programmable also, I think...

I checked those settings. I had my low bat set for 14v...the warning didn't kick in until 13.6v (I think) The Batt_crt parameter(s) were set to 0...so should of been disabled. Maybe the battery lowalso triggered the consumed amps at the same time...even though the consumed amps setting was disabled. All part of the development curve. I can't program anything, but I can bring up things that look like may be issues.

@sh83 made more good progress yesterday. Pending PR for imperial units and some other refinements. This thing is getting pretty dialed in. Attached are notes on the PR, and sample image from test firmware built this morning. The flashing warnings for user-specified limits on vbatt, RxRSSI and nSats is cool. Brief video here.

Kelly

Edit: Double Post

Originally Posted by wkf94025

@sh83 made more good progress yesterday. Pending PR for imperial units and some other refinements. This thing is getting pretty dialed in. Attached are notes on the PR, and sample image from test firmware built this morning. The flashing warnings for user-specified limits on vbatt, RxRSSI and nSats is cool. Brief video here.

Kelly

Awesome. Thanks for all the work!!!!

I flashed the latest firmware with BT on my Omnibus F4 v2 pro. This is the error I get:

Check BRD_TYPE: Baro: unable to initialise driver
Initialising APM
airbotf4 0032002E 3136510F 34373332
ChibiOS: e7b6334c
ArduPlane V3.10.0-dev (5c4b5c78)
Check BRD_TYPE: Baro: unable to initialise driver

Tryed with the Airbot and Omnibus firmware, but get the same error. Before I had the 4flight firmware and that didn't had this error.
Does anyone know how to solve this problem?

Originally Posted by WimNL

I flashed the latest firmware with BT on my Omnibus F4 v2 pro. This is the error I get:

Check BRD_TYPE: Baro: unable to initialise driver
Initialising APM
airbotf4 0032002E 3136510F 34373332
ChibiOS: e7b6334c
ArduPlane V3.10.0-dev (5c4b5c78)
Check BRD_TYPE: Baro: unable to initialise driver

Tryed with the Airbot and Omnibus firmware, but get the same error. Before I had the 4flight firmware and that didn't had this error.
Does anyone know how to solve this problem?

Try loading betaflight or cleanflight on it and check to be sure your baro hasnt died....

Originally Posted by Atx_Heli

Try loading betaflight or cleanflight on it and check to be sure your baro hasnt died....

Flashed it again with dfu util and 4flight. Everything is working, also baro and gps.
I bought the omnibus / airbot grom the original airbot shop. Was Not cheap, but had some bad F4’s from Banggood. So i’m not sure if its a V2 or V3. But its a pro for sure

Could you please take a macro photo of the baro with marking visible