padcom
commented
6 years ago Closed padcom closed 6 years ago
padcom
commented
6 years ago padcom
commented
6 years ago What is even more interesting there are 2 solder pads on the board - both fitted originally with 0 Ohm resistors. In some of the issues I found for iNav it is recommended to remove one of those to get SBUS and PPM working. I find that hard to understand why that is the case especially that other receivers work flawlessly.
It'd be absolutely great to get to the bottom of the problem.
I am well aware that it might be and issue with OpenLRSng in how it outputs the PPM and SBUS signals. Can we at least confirm that?
padcom
commented
6 years ago SBUS with OrangeRX tested (using an SBUS inverter) and sort of works. Channels 1-4 work great but the rest of channels just doesn't get the full range. Might be because of low quality SBUS inverter but not sure. Regardless using the same inverter (just for the sake of it) doesn't make PPM work.
padcom
commented
6 years ago SUMD protocol works flawlessly with the simple inverter I built (https://oscarliang.com/ctt/uploads/2015/12/sbus-inverter-diagram-schematics.jpg). Telemetry is also working well using the FrSky protocol on the same serial port as the receiver.
PPM still not working :(
digitalentity
commented
6 years ago Ok, so it's about non-working PPM. On OMNIBUS boards you need to change the jumper to switch between PPM and SBUS (or other serial protocol).
padcom
commented
6 years ago See that is the point. Other PPM receivers work without removing that jumper do your statement isn’t quite correct.
padcom
commented
6 years ago I wonder what is so different between the cheap DIY receiver, OrangeRX'es R610 v2 and OrangeRX LRS receivers. Both seem to have the exact same signal when observed on the oscilloscope. The only difference is that the OrangeRX receiver is a tiny tiny bit less perfect whereas the DIY modules produces a rock-solid logical 1. They are both on the exact same logical level (way more than 3V in both cases) and the polarity of both signals is the same.
What is even more interesting SUMD from OrangeRS LRS receiver seems to be the only protocol fully supported without any modifications when connected to UART1. This isn't all that bad since TX on that port can be used to feed telemetry data back to the transmitter. And that combo works very well.
Even though it might seem irrational I checked the inverted PPM signal and it still didn't do anything to make the PPM work. No surprise there.
I think if we'd be able to solve the mystery of PPM not getting through it would help a lot of users of the popular flight controller set things up.
padcom
commented
6 years ago Just thinking out loud here... If the problem would be about inverting the PPM signal it would be possible to invert it in software (PPM being a software-controlled protocol an everything).
padcom
commented
6 years ago Well, I have full success!
Even though it requires intervention with the soldering iron I am happy to report that the problem is with the receiver itself (OrangeRX LRS RX) and NOT with iNAV or the OMNIBUS F4 v2.
Long story short on the ORX LRS RX between pins and the MCU there are 1k resistors. On Wolfbox RX there are no resistors. Once the one on channel 6 (PWM5) is bridged effectively removing that resistor the PPM signal goes through properly to the flight controller!I presume one could replace that 1k resistor with some smaller value to limit the current but for now this will do fine.
If done right (with a piece of very thin wire) the modification is completely reversible.
Maybe it'd make sense to put this information somewhere on the wiki?
I am closing this issue.
digitalentity
commented
6 years ago @padcom great finding! Please create a wiki page describing this hardware hack so the information won't get lost. Thanks!
padcom
commented
6 years ago 
DzikuVx
commented
6 years ago @padcom we were kind of hoping you would create w wiki page in INAV repo :)
padcom
commented
6 years ago Done.
DzikuVx
commented
6 years ago Thank you
Board and Version
Omnibus F4v2 (Banggood clone) iNAV 1.9.1 Firmware (stock)
Behavior
I am using 3 setups:
a) FrSky Taranis with L9R and 8XR receivers outputting SBUS and 2 D8 receivers for testing the PPM output
b) OrangeRX 2.4GHz link with DSM2 transmitter and 9ch full range receiver for SBUS testing and R610 V2 for testing C/PPM
c) the OrangeRX OpenLRS transmitter with OrangeRX LRS 9ch receiver and latest OpenLRSng (3.8.8)
In all cases but the last one with OrangeRX LRS everything works fine. With OrangeRX I get PWM output on pins (a servo moves as expected) but no PPM nor SBUS. The funny thing is I can see the PPM on channel 5 using an oscilloscope but it has a tendency to "move around" - can't actually describe it better. Please see attached 2 screens (first is from the tiny PPM receiver that works, second is from the OrangeRX OpenLRS receiver's PPM output.
Steps needed to reproduce the problem
Use OMNIBUS F4 v2 board
Updated firmware to 1.9.1
Configure the receiver to output PPM on channel 6 (described on the board as channel 5 because on channel 1 there's the RSSI output)
Connect the OrangeRX OpenLRS TX and RX
Make sure the OrangeRX link emits PPM on the designated pin using an osciloscope
Open iNAV
Ensure no serial receivers are configured on the ports tab
Ensure the receiver is set to PPM
Navigate to "receiver" tab and see the bars not moving at all
Expected Results OrangeRX PPM and SBUS signals should be properly decoded.
Actual Results OrangeRX PPM and SBUS signals are not recognized.
To be blunt about it I don't really care much for SBUS. I am flying a plane so fast responses don't really matter as much as nice wiring. That's the reason I have primarily chosen PPM. It works with all other receivers, outputs PPM on OrangeRX LRS RX too but iNAV (and betaflight for that matter) don't interpret that as valid signal.