mamba F405 mini MK3.5 crazy radio failsafe

New to posting, is this right place?
Have this mamba F405 with expresslrs happymodel EX900TX/RX. Giving Radio Failsafe error message. It comes on and off constantly in a bit of a noise/random sequence. Possibly more failsafe on messages than failsafe cleared messages. My JumperT16 shows good RSS, I see on mission planner the radio switch positions. Channel 3 for throttle is shown to be above the FS_THR_VALUE=975usec value for detecting signal loss. Running 4.3.0 ardupilot which I think is what is recommended for mamba F405 to work.

What can be the problem?
I can get constant Radio Failsafe on messages with none cleared by increasing the FS_THR_VALUE value above my shown throttle value. But with low FS_THR_VALUE, the failsafe error comes on and off constantly in a random fashion.

Any help,

I saw the ardupilot documentation on mamba F405. Mamba Basic F405 Flight Controllers — Plane documentation
I had to change to UART 4 on the mamba and it works fine now. I could not find a separate SBUS pin for the RX as documentation says in subsection “RC Input”. Maybe its bit different with the mini MK3.5 version of the FC board that I have.
I never tried setting BRD_ALT_CONFIG = 1, who knows if that would have fixed it.

Again, it was a weird issue. Kicking on and sometimes off the radio failsafe, but at same time being able to do a radio calibration just fine. I wish I knew how to access ardupilot code and troubleshoot by looking at the function that makes the decision of radio failsafe. Its like something wasn’t synchronized, only at times randomly clearing the failsafe for a very short period of time. I even tried all the baud rate settings for SERIAL1 before moving to SERIAL4.
When I downloaded the ardupilot code for 4.3.0, the folder said like over 100MB, but in explorer I didn’t find any big files where the rest of the code should be. I’m a very bad programmer, I’m missing some details on how all of the file types associated with professional code like ardupilot work, and where the actual code is hidden. Anyway, any insights would be great. I’m curious to know what the software was actually seeing when it decided to continue this failsafe while still showing switch PWM values in the radio calibration screen. Would be nice to be able to see actual waveforms or bit stream data of the FC inputs and look at the outputs in real time. Take troubleshooting here to another level.