openrcforums

Please help me to get things clear with FrSky's telemetry data transfer protocol.

Here's two packets: I can tell that second packet sends command 0x1b (latitude value after decimal separator ("."))
So the command is 0x1b and the value is 0xD07 (decimal 3452) and everything's clear.

But what about this first packet? I can tell that first packet sends command of 0x13 (latitude value before decimal separator) and it should send value of 0x1619 (decimal 5657). I can see that this values low byte (0x19) is located in first packet but somehow high byte (0x16) is sent via second packet... What's the trick? What about those two 0x5e in first packet? How's everything connected, I just don't get it. Protocol's description in FrSky-rc.com tells nothing about this: http://www.frsky-rc.com/uploadfile/2010 ... 837352.pdf
I'm stuck, please help me.

Are you sure you have the correct FrSky protocol document? If you are attempting to "talk" directly to the input port on a FrSky telemetry Rx, then the telemetry hub frame protocol document is the one I used in a DiY telemetry project.
http://www.frsky-rc.com/uploadfile/2012 ... 254960.pdf

- Thomas

I have connected my "usb to uart" device direct to my radio (tx module is removed from radio) and sending in raw data (simulating receipt from rx)

My FrSky project used the Rx hub communication protocol, but I don't have any experience with the 9x host communication. However, I looked at the protocol info you provided and have some comments:
1. The first example's byte #6 appears to be an unwanted repeat of the user data header command.
2. The first example's user data is stated to be valid for only 4 bytes long, but it appears this is a mistake since there is some user data in the higher bytes.
3. The first example is missing the 0x5e tail byte.
4. BTW, the protocol doc states that byte #4 is not used. But I think it is used as a simple packet counter (sequences from 0x00 to 0x1F).

From what I can tell, the first example would be similar to this for latitude before "." :
0x7e 0xfd 0x05 0x0b 0x5e 0x13 0x19 0x1b 0x5e 0x00 0x7e

And the second example would probably be similar to this for latitude after ".":
0x7e 0xfd 0x05 0x0c 0x5e 0x1b 0x7C 0x0d 0x5e 0x00 0x7e

But no doubt the experts will come and straighten us both out.

- Thomas

The problem is that those two packets are completely valid, I can send them both in and I will get valid latitude decimal number displayed in telemetry screen.

Just curious, do my two packets examples work for you?

- Thomas

Looks all OK to me. First packet:
0x7e 0xfd 0x04 0x0b 0x5e 0x5e 0x13 0x19 0x1b 0x7b 0x7e
Has 4 user bytes :
0x5e 0x5e 0x13 0x19
Second packet has 6 user bytes:
0x16 0x5e 0x1b 0x7C 0x0d 0x5e

Put together:
0x5e 0x5e 0x13 0x19 0x16 0x5e 0x1b 0x7C 0x0d 0x5e

So you have a 5E that is probably the last 5E from previous data.
Then 0x5e 0x13 0x19 0x16 0x5e is item 0x13, value 0x1619
Then 0x1b 0x7C 0x0d 0x5e is item 0x1b value 0x0D7C.

With byte stuffing, you never get a value of 0x5E in the user data, You should be prepared to accept 2 0x5Es together as one could be the end delimiter from one sequence and the second the first delimeter from the next sequence.
Never expect to get user data packets filled with 6 bytes always. Each one contains the number of bytes it says it does.

Mike.

I had the same fight and questions when I made the NMEA version with arduino (where I do not use FrSky hardware for the telemetry), emulating the FrSky protocol.
For the FrSky firmware in the radio to work, every data has to be packed into a 'Userdata package'.
The format of the Userdata package is:
7E FD len 00 5E id xx xx 5E 7E and the next package is again 7E FD len ......... 5E 7E

len is the number of bytes from 5E to 5E (inclusive)
xx xx are the two bytes of the value and may be low byte first or low byte last, depending on the data that is transferred.

And you must use byte stuffing in case of 5D or 5E values.

Reinhard

You should be prepared to accept 2 0x5Es together as one could be the end delimiter from one sequence and the second the first delimiter from the next sequence.

Good stuff to know, I would never have expected that. But it makes sense.

It would certainly be more tidy to provide the user data's start/end delimiters all in the same packet; There appears to be plenty of room in the 11 byte string to accomplish that. I know computers don't care about tidy data, and easily create the more compact data structures, but things like this often make the human observers scratch their heads.

Remember, this user data stream comes from the Hub (normally), and to the receiver it is just a stream of data bytes. As the data arrives on the serial port, the receiver buffers them, then puts them in a user data packet and sends it down to the Tx. It doesn't wait for a full user data packet, it doesn't know anything about the user data, and doesn't know if more bytes are going to arrive, so if it only has 4 bytes buffered, it just sends 4 bytes.

The hub protocol describes a number of hub packets, each of the form:
5E id xx xx 5E id xx xx 5e id xx xx . . . . . 5e id xx xx 5E

As you can see, each of these starts and ends with 5E, so at the end of one of these packets and the beginning of the next you will get two 5E bytes together.

Mike.

I am familiar with the format of the Rx's hub data (have created a couple DiY FrSky hub projects). But my experience ended there. So this was a good lesson on the stuff that happens on the 9x/host side. Glad I poked my head in here.

- Thomas

thomas9x wrote:Just curious, do my two packets examples work for you?

- Thomas

You'r two packets produces 6937.3452

MikeB wrote:Looks all OK to me. First packet:
0x7e 0xfd 0x04 0x0b 0x5e 0x5e 0x13 0x19 0x1b 0x7b 0x7e
Has 4 user bytes :
0x5e 0x5e 0x13 0x19
Second packet has 6 user bytes:
0x16 0x5e 0x1b 0x7C 0x0d 0x5e

Put together:
0x5e 0x5e 0x13 0x19 0x16 0x5e 0x1b 0x7C 0x0d 0x5e

So you have a 5E that is probably the last 5E from previous data.
Then 0x5e 0x13 0x19 0x16 0x5e is item 0x13, value 0x1619
Then 0x1b 0x7C 0x0d 0x5e is item 0x1b value 0x0D7C.

With byte stuffing, you never get a value of 0x5E in the user data, You should be prepared to accept 2 0x5Es together as one could be the end delimiter from one sequence and the second the first delimeter from the next sequence.
Never expect to get user data packets filled with 6 bytes always. Each one contains the number of bytes it says it does.

Mike.

This totally makes sense now! Thank you very much.

That's a relief -- The final decimal value matches the hex data (1b19 and 0d7c) used in my examples. Thanks for checking.

- Thomas