Problems with FPort byte stuffing

Electronic projects that are either related to the firmwares for the 9x, or simply great for radio control applications.
Post Reply
cps
Posts: 5
Joined: Tue Mar 15, 2022 10:52 pm
Country: -

Problems with FPort byte stuffing

Post by cps »

I have a Jumper R1F receiver with FPort which I want to use with a RP2040 processor for my RC models. To understand FPort I first hooked up the Fport of my receiver with a double inverter (2 transistors and some resistors) to a serial to USB converter which is plugged into my linux PC. I wrote a small c-programme to analyse the control channel and to send back some telemetry data to the RC sender (Radiomaster TX16S).
Almost everything works nicely: I see the values of the channels connected to the sticks on the PC and I can send telemetry data back to the Radiomaster where I discover successfully the software generated "sensors" and I see the values I send...except for 2:
When I send the values 7E or 7D I need to do byte-stuffing (i.e. send 7D 5E, or 7D 5D). I understand that the length in the data packet is calculated BEFORE byte stuffing and also the checksum is computed BEFORE byte stuffing.

However, on my Radiomaster the values 7D and 7E never arrive. (All others do.)

I attach the small c-program I am using for debugging (it's a hack for debugging !).

The output of the program prints out the received control channels (stick values) and what it sends to the Fport as telemetry packets. I send a VFAS sensor and increment the east significant byte always by one (a counter). The values 125 and 126 (hex 7d and 7e: byte stuffing required) never arrive at the Radiomaster, but all other values do.

Here what my programme spits out for the critical values (and one before and after):

...
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
send 08 81 10 10 02 7c 00 00 00 d7
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
send 08 81 10 10 02 7d 5d 00 00 00 d6
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
send 08 81 10 10 02 7d 5e 00 00 00 d5
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
send 08 81 10 10 02 7f 00 00 00 d4
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
send 08 81 10 10 02 80 00 00 00 d3
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
Chan 0 : 172 1 : 997 2 : 990 3 : 992
...

If you find a flaw in this setup or have any hint I would be delighted to know it.

Thanks a lot and best wishes! (And hopefully somebody finds the c-programme useful for other hacks...)
Attachments
serial.c
(7.08 KiB) Downloaded 95 times

User avatar
MikeB
9x Developer
Posts: 17990
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Problems with FPort byte stuffing

Post by MikeB »

If the telemetry data doesn't need a leading 0x7E, then I would think you don't need the byte stuffing. That would only be needed to make a leading 0x7E unique.

Mike
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
cps
Posts: 5
Joined: Tue Mar 15, 2022 10:52 pm
Country: -

Re: Problems with FPort byte stuffing

Post by cps »

Thanks Mike, indeed the telemetry packet on Fport is NOT "framed into 0x7e... I will try to simply drop the stuffing and report back! Thanks ! (I thought to have seen in the opentx source code that they always try to "unstuff" the s- and f-port telemetry packets... but I might be wrong...)
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: Problems with FPort byte stuffing

Post by Kilrah »

cps wrote: Sun Jun 12, 2022 5:37 am(I thought to have seen in the opentx source code that they always try to "unstuff" the s- and f-port telemetry packets... but I might be wrong...)
Yes because F-port is purely a receiver-side thing, it's not involved in the radio-side communications.
cps
Posts: 5
Joined: Tue Mar 15, 2022 10:52 pm
Country: -

Re: Problems with FPort byte stuffing

Post by cps »

So, I tested once more without byte-stuffing and (as implied by the remark of Kirah, thank you!) the bytes 7e and 7d do come through either...
Anyway thanks for your comments !

Post Reply

Return to “General RC Electronic Projects and Discussion”