Hi all,
First up my relevant hardware and its configuration. The radio is a Jumper T12 TX connected to a TGY-IA6B receiver (configured with PPM/SBUS output and no pulse failsafe). The SBUS output of this RX is wired to the SBUS input of a RFD900x telemetry module. The air side RFD900x has its SBUS output (configured as either SBUS or SBUS_NoFail) wired to the SBUS input of a pixhawk 4. All devices are running the latest available stable firmwares as of 14th Jan 21.
The connection is tested to work and it does so rock solid when working, however the TX, RX and ground side telemetry radio must all be powered up first in order for it to do so. Starting up the pixhawk with the radio off results in 0 radio channels being detected and it doesn’t matter how you reset the radios it will not pick it up until you power cycle (or “reboot” command) the pixhawk.
I’m wondering why the PX4 isn’t able to find the radio connection unless initially present. Given (presumably?) PX4 is able to recover from a radio dropout what is different about the powerup conditions that prevent it from doing the same there? I’d understand a first run situation as it determines the available hardware etc but its doing it every time, not just that first configuration.
Hoping someone else has had this same pain, thanks in advance for any assistance that might be available.
Alrighty, having spent the morning testing everything relentlessly it appears I’ve found the problem and solution.
I removed the telemetry SBUS forwarding to test that the standard radio link still worked… and it didn’t. Which was odd because thats what I’d done initially and it had worked fine. With that in mind I tested all manner of things and found it kept playing up sporadically, no longer anything to do with having the link up prior to booting.
At some point I realised that on power cycles (note power, not soft reboots) where radio connection failed initially, even if I managed to establish the radio link, the outputs would fail also and could not be recovered. That really had me puzzled but I ended up blaming it on the custom mix I had. When I ran “DMESG” the mixer was unable to load my mix and I assumed I’d simply made a mistake somewhere there… Until eventually I went back and read everything properly and discovered that there was a whole swag of px4io errors getting thrown up at random each boot.
Long story short I remembered a note I’d seen somewhere about px4io not always updating if the boards ran really old firmware, these boards were 3 years old (but brand new) so I guess they had the old firmware because every few reboots there would be a warning about how flashing px4io had failed etc.
Reflashing the board from bootloader mode has, atleast for now, rectified the issues I was facing.
So as a further update to my issue, reflashing did not permanently fix the issue: the exact same fault reappeared. Reflashing the board fixed it for the first few power cycles but it’s the same old same old.
Flashing ardupilot results in a rock solid radio link no matter how I do it so I guess I’ll be sticking with that.
