Mavlink lost packets mystery

ArduCopter Copter 3.5
1

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.

2

Hi Eric, sadly there was no answer on your question here. May I kindly ask if you have had any success in solving this problem yet that you might be able to share? Thank you very much!

3

Hi career

Regretfully I never got to the bottom of this. I stopped worrying about "lost " packets and haven’t been back to look if it eventually sorted itself out.

Sorry I can’t help.
Eric

4

Hello,
Sorry to bug you. My names nate, and as a man who recently at 40 decided he wanted to learn about coding, am at the mercy and thanks of any help you can give me. BG. I am a long time EZUHF user who for the last few months has been on a mission to find a solution to the fact that myself as well as many others can’t use our ez ground stations and trackers because IRC, despite making a wonderful GS setup, turned around and made that A/C mounted hardware look and function like they were on a drug bender. So. Despite my lack of coding skill, my tenacity has kept me determined to solve this. Now the EZUHF source code was promised to be opened 5 years ago, but Sanders did what he always did to his customers and didn’t follow through, but that’s, a whole headache For later. As for the antenna tracker, it utilizes the gps module telemetry output, runs it through an DCA IC chip, and encrypts it into a analog signal that’s run out the vtx audio channel, received by the vrx, came type chip except now a to d decodes the packets into coordinates to follow the plane. Essentially audio fsk modem, 60 year old tech, but reliable. Now the only way to send telemetry is through their tiny telemetry module, which is a small convenient chip that probably never existed, because literally no one’s ever seen one. Or, you have to use the EZOSD, which when it came out was larger than the ET vector, same price, hideous, no flight control, and was barely even an OSD, I think it shows a very inaccurate altitude. Well even those are hard to find, and won’t even fit into most planes, I can barely squeeze it into a vas chimera.
Long story short. I’ve been on this sight for two weeks trying to teach myself as well as solve this. I’m gotten to the point where I think maybe (I’m sure I’m saying this wrong) it’s possible to soft patch an FC gps telemetry rx duplicate out to a serial port with the mavlink protocol?? Then encrypt it with an arduino teensy flashed with the Ezuhf telemetry protocol. Please don’t laugh at me, this is the best I could do based on what I learned in an arduino course for children I took with my 6 year old, where I was instructed by a cartoon cat on the computer….as a 40 yo man. So you can’t say I’m not trying lol. Oh, and after a hundred emails I did get one of the old employees to send me the entire code for the telemetry protocol. So. After I came across your post today, it seemed kinda close to what I’m conceptualizing, and maybe I haven’t wasted my time. So sir, please. With what I’ve told you, and I can send you the code. Is this feasible…… well if by something who actually k owns what they’re doing??

5

Hey Nate, thanks for a very interesting (and entertaining) message. I kinda have my hands full right now with another (similar) project, and just arrived home yesterday after 3 months traveling. But, sure, let’s look at the code. Maybe we can find some kind of workaround.

1 Like
6

I really appreciate that. I’m trying to learn but it’s hard to do without actually having someone to converse with. YouTube and forums have taken me to the crux in my learning curve, and I’m all ears with whatever advice you can give.