Radio sending 1500usec with f.port, but mission planner shows 1495usec? -5 usec offset across whole range

I’ve got a TX16s that is showing channels at 1500usec. It’s sending to an FrSky RXSR receiver, which is talking F.port to a Matek H743 wing v2.

In mission planner if I connect to the flight controller and go to the “radio calibration” page, it reports the channels as centered at 1495usec for both sticks and switches. The endpoints are also offset by 5 usec, so it appears to be a constant offset across the whole range.

Where is this offset coming from? It’s digital all the way along, so it should presumably be perfect, no?

Nothing is perfect…

1% error,…

If it were analog I’d agree, but it’s a digital signal from the TX to the RX to the flight controller. And every channel is absolutely identical.

I’ve noticed this at times as well, and it’s of little concern. There may be a rounding error or display resolution artifact at one end or the other.

just make sure you set a ‘deadband’ of about 7, then it’s of no concern. :slightly_smiling_face:

Just for fun I flashed my board with Betaflight, and the values it reported matched perfectly with what the radio was reporting in the channel monitor.

So there’s something going on with Arduplane where it’s mis-interpreting the f.port signals from my frsky receiver, added a constant -5 offset to it all across the entire range.

If it’s consistent, then it’s truly no concern. Calibrate the radio (the purpose of which is to account for scenarios like this), tune the airplane, and fly.

1 Like

I intend to fly it.

But it seems to me that it’s clearly a software bug, and it’s always possible that a bug that shows up in one case may behave differently under different circumstances.

You might check the data flash log to determine whether it’s a GCS software display inconsistency or actually reported differently than the radio by the autopilot itself.

The log file shows that it’s actually a -6 offset in the min/max values, but the steady-state is definitely 1495 if I zoom into the graph.

Ok, that confirms one end. You’d need an oscilloscope or serial monitor to determine whether the values coming in are reflected accurately in firmware before raising a bug report.