I’m hoping someone can help solve this mystery for me. On the ezWifibroadcast group over on rcgroups, some good work is being done (by Rodizio and others) to deliver HD video over WiFi UDP. A secondary objective is to channel telemetry both ways (duplex) over the link, for GCS support as well as OSD and/or trackers. Various protocols are supported, including Mavlink.
Using APM 3.5.5 in a Pixhawk, via 3 (short) wire serial to a Raspberry Pi B3, then via WiFi UDP to an identical Rpi on the ground, then using the Rpi Wifi hotspot to a laptop running Mission Planner, we get lots of lost frames and a signal quality of around 66% using the Link Stats on MP.
Strangely, using the PX4 Pro firmware and everything else the same we get 100% signal quality reported by link stats in MP.
Looking at the MP code, frames are reported lost when sequence numbers are missed. So, possibly, parsing for the 0xFE start-of-frame flag is going out of sync, dropping frames or part of frames. The code is data content agnostic. It does not look at the content of frames, other than headers.
At one time we thought that mavlink libraries in the C parsing code running on the Rpi might be different (between APM and PX4). I wrote some simple code for a free-standing STM32, using mavlink libraries, to test the theory, but APM libraries or px4 libaries made no difference. Both produce missing sequence numbers and poor signal quality in link stats.
Next I looked at mavesp8266. Using the same kit, but with the mavesp8266 plugged into the same Pixhawk port, Mission Planner on the laptop reports 100% signal quality. Ok, maybe to be expected.
So then I tried Sik radios on 433 MHz, same good result. 100% signal quality. Also expected.
Then I tried a 6 wire direct serial ribbon cable 2m long between the Pixhawk running APM and an FT232RL USB/serial bridge plugged into the laptop. Same problem! 66% signal quality. Huh? Note: The RTS/CTS flow control wires did not help.
Everything is running at 57600 b/s. Since the 2m long cable could be introducing inductive/capacitive/noise problems I tried a 3 wire cable a few inches long between Pixhawk and the FT232RL. Signal quality was still around 66%.
Just to be sure, I then tried a USB cable directly between the Pixhawk and the laptop. As expect: 100% signal quality.
So what could it be? I’m starting to suspect that, without some form of flow-control, bursts of asynchronous messages overcome the ability of the transmission chain to deal with them in time. Even when the transmission chain is just a short link into an FT232 based bridge.
I’m assuming that the USB cable works because it incorporates RTS/CTS. I know that the Pixhawk ports supports hardware flow control. I also know that Arduino boards, and STM32 boards do not support hardware flow control without explicit setting of UART registers. Right now I don’t know how to do that.
Looking at the mavesp8266 code, the mavlink packets are buffered up to 60 at a time, and the consumption of the large input buffer is monitored. I could not see any manipulation of the ESP8266 UART registers.
I’m assuming the the Sik radios might use a similar strategy to smooth out the message rate.
Sorry for the long-winded story. I won’t blame you if you click past this one, but I’m sure that there are plenty of people out there who know much more about this that I do. Any help would be humbly accepted.