Raw level protocol
Raw level protocol
Hello,
I try to send simple Bytes from the D8R-IIplus to the DJT-Module.
9600baud like mentioned in the manual and what I receive at the TX-Module is obviously 9600baud but an endless stream of bytes.
My connections seem to be ok because only in one configuration I can receive something. I do receive something with 9600baud.
Is that a mysterious protocol which I have to decode?
Or is it, that I'm doing something wrong? I thought I just send a Byte to the receiver and it appears at the transmitter.
Obviously this does not work that simple?
Can anybody help me?
Best regards,
Norbert
I try to send simple Bytes from the D8R-IIplus to the DJT-Module.
9600baud like mentioned in the manual and what I receive at the TX-Module is obviously 9600baud but an endless stream of bytes.
My connections seem to be ok because only in one configuration I can receive something. I do receive something with 9600baud.
Is that a mysterious protocol which I have to decode?
Or is it, that I'm doing something wrong? I thought I just send a Byte to the receiver and it appears at the transmitter.
Obviously this does not work that simple?
Can anybody help me?
Best regards,
Norbert
Re: Raw level protocol
Frsky D receiver uses a "hub protocol".
Here more details on this protocol.
http://www.frsky-rc.com/download/view.p ... b%20System
Please have a look at this.
If you need more, please ask and I will try to explain.
Here more details on this protocol.
http://www.frsky-rc.com/download/view.p ... b%20System
Please have a look at this.
If you need more, please ask and I will try to explain.
Re: Raw level protocol
Hello,
I hoped for such a hint about the protocol.
But unfortunately, the link of the download gives me an "internal server error"
Could you upload it here?
Best regards,
Norbert
I hoped for such a hint about the protocol.
But unfortunately, the link of the download gives me an "internal server error"
Could you upload it here?
Best regards,
Norbert
Re: Raw level protocol
here the document.
- Attachments
-
- protocol_sensor_hub.pdf
- (47.91 KiB) Downloaded 431 times
Re: Raw level protocol
Hi,
thanks such a lot.
But where are the Bytes which I should be able to feed into the RX?
I'm afraid I have to misuse this protocol to transfer my data?
This would be the hard way, really.
Ok, I'll try it tomorrow.
Again, thanks for the file, without it I would have been lost!
Best regards,
Norbert
thanks such a lot.
But where are the Bytes which I should be able to feed into the RX?
I'm afraid I have to misuse this protocol to transfer my data?
This would be the hard way, really.
Ok, I'll try it tomorrow.
Again, thanks for the file, without it I would have been lost!
Best regards,
Norbert
Re: Raw level protocol
Can you explain a little which kind of data you want to send to Tx.
Normally the protocol is foreseen to send a frame that contains some data ID (one byte) and for each data ID then the value (2 bytes).
So you could split your data in pieces of 2 bytes.
Normally the protocol is foreseen to send a frame that contains some data ID (one byte) and for each data ID then the value (2 bytes).
So you could split your data in pieces of 2 bytes.
- MikeB
- 9x Developer
- Posts: 18000
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Raw level protocol
With the D8R-IIplus and a DJT, any data sent into the serial input of the receiver appears on the DJT serial output in "User Data" packets, along with a telemetry packet containing Rx and Tx RSSI values and A1 and A2 analog input values.
You have to decode the "User Data" packets to pick out the data you are sending in to the receiver.
Mike.
You have to decode the "User Data" packets to pick out the data you are sending in to the receiver.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Raw level protocol
Hi,
thanks guys. I think I understood. I have to use the protocol.
I'll get around with it. I think I'll use the protocol as it is intended to. That's straight away.
Thanks for your help!
Best regard,
Norbert
thanks guys. I think I understood. I have to use the protocol.
I'll get around with it. I think I'll use the protocol as it is intended to. That's straight away.
Thanks for your help!
Best regard,
Norbert
- MikeB
- 9x Developer
- Posts: 18000
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Raw level protocol
Code for decoding the telemetry and user packets is available in the firmware, so you might be able to use some of that to help you.
Mike.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Raw level protocol
here a link where you can find more infos about the user data frames.
http://www.rcgroups.com/forums/showthre ... 43&page=89
In attachement you have a document about user data frame (found following the link above).
http://www.rcgroups.com/forums/showthre ... 43&page=89
In attachement you have a document about user data frame (found following the link above).
- Attachments
-
- FrSky_Protocol_v1.pdf
- (99.25 KiB) Downloaded 371 times
Re: Raw level protocol
Hi,
now I start to understand it.
In a more simple form than all the collected information above (and to make sure that I got it right):
First thing, it's all inverted compared to UART, 3.3V. 9600baud but don't exceed a net rate of 1200 baud when sending data to the receiver.
The inverted thing was the reason why I've seen only bullshit at the Transmitter with my UART-USB converter in HTerm. I need a hardware inverter. Same for sending data to the RX or use an inverted Software Uart (I hate this).
0x5E starts and ends data.
The DataID is a byte after 0x5E which says "this is this or that".
Data itself can be of any length, LSB first.
Is this a correct summary so far?
Thanks again for your help. Without it I would have been lost.
I'll share this information with the german walkera community, when I got it running and of course here, if I notice something else.
Best regards,
Norbert
now I start to understand it.
In a more simple form than all the collected information above (and to make sure that I got it right):
First thing, it's all inverted compared to UART, 3.3V. 9600baud but don't exceed a net rate of 1200 baud when sending data to the receiver.
The inverted thing was the reason why I've seen only bullshit at the Transmitter with my UART-USB converter in HTerm. I need a hardware inverter. Same for sending data to the RX or use an inverted Software Uart (I hate this).
0x5E starts and ends data.
The DataID is a byte after 0x5E which says "this is this or that".
Data itself can be of any length, LSB first.
Is this a correct summary so far?
Thanks again for your help. Without it I would have been lost.
I'll share this information with the german walkera community, when I got it running and of course here, if I notice something else.
Best regards,
Norbert
- MikeB
- 9x Developer
- Posts: 18000
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Raw level protocol
The 0x5E and ID are part of the HUB protocol sent into the serial port of the receiver from the telemetry HUB. If you are sending raw data, then the 0x5E does not apply.
A user data packet looks like:
0x7E
0xFD
Length of valid bytes
Not used
byte1
byte2 to byte6
0x7E
And user data byte of 0x7E or 0x7D will also be "byte stuffed".
Mike.
A user data packet looks like:
0x7E
0xFD
Length of valid bytes
Not used
byte1
byte2 to byte6
0x7E
And user data byte of 0x7E or 0x7D will also be "byte stuffed".
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Raw level protocol
Hi,
ahh, so when I want to send user data I have to use 0x7E as start?
Can't I simply use the protocol of the HUB?
I would simply simulate my own HUB.
Best regards,
Norbert
ahh, so when I want to send user data I have to use 0x7E as start?
Can't I simply use the protocol of the HUB?
I would simply simulate my own HUB.
Best regards,
Norbert
- MikeB
- 9x Developer
- Posts: 18000
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Raw level protocol
No.Norbert wrote:ahh, so when I want to send user data I have to use 0x7E as start?
If you send a single byte, say 0x45, the DJT will output:
0x7E 0xFD 0x01 xx 0x45 xx xx xx xx xx 0x7E
Where xx represents a byte of unknown value.
If you send 2 bytes, say 0x45 and 0x46, the DJT will output either:
0x7E 0xFD 0x02 xx 0x45 0x46 xx xx xx xx 0x7E
or:
0x7E 0xFD 0x01 xx 0x45 xx xx xx xx xx 0x7E
0x7E 0xFD 0x01 xx 0x46 xx xx xx xx xx 0x7E
depending on the timing when the receiver received the bytes compared to sending them over the RF link.
If you send a single byte of 0x7E, the DJT will output:
0x7E 0xFD 0x01 xx 0x7D 0x5E xx xx xx xx xx 0x7E
The 0x7E inside the packet is "stuffed" as 2 bytes 0x7D 0x5E, to prevent a 7E appearing except at the start and end of the packet.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Raw level protocol
Hi,
oh, it made "click"!
My summary as I understand and tested it now:
I can send simple bytes to the RX.
The normal package I get at the TX is:
0x7E 0xFE "8 Bytes" 0x7E - I ignore this
If my user Data (in case of two bytes) is present I get:
0x7E 0xFD "No. of valid Bytes" "No. of Frame" "Valid Byte1" "Valid Byte2", xx, xx, xx, xx, 0x7E
Or as you wrote spreaded on two frames:
0x7E 0xFD "1" "No. of Frame" "Valid Byte1", xx xx, xx, xx, xx, 0x7E
0x7E 0xFD "1" "No. of Frame" "Valid Byte2", xx, xx, xx, xx, xx, 0x7E
Right so far?
So if I want to send my data stream, I have to take care about message IDs, start, stop and so on by myself?
Just throw the bytes to the RX and pick them out of the packets at the TX which start with 0x7E 0xFD.
Please tell me, that I got it now
Best regards,
Norbert
oh, it made "click"!
My summary as I understand and tested it now:
I can send simple bytes to the RX.
The normal package I get at the TX is:
0x7E 0xFE "8 Bytes" 0x7E - I ignore this
If my user Data (in case of two bytes) is present I get:
0x7E 0xFD "No. of valid Bytes" "No. of Frame" "Valid Byte1" "Valid Byte2", xx, xx, xx, xx, 0x7E
Or as you wrote spreaded on two frames:
0x7E 0xFD "1" "No. of Frame" "Valid Byte1", xx xx, xx, xx, xx, 0x7E
0x7E 0xFD "1" "No. of Frame" "Valid Byte2", xx, xx, xx, xx, xx, 0x7E
Right so far?
So if I want to send my data stream, I have to take care about message IDs, start, stop and so on by myself?
Just throw the bytes to the RX and pick them out of the packets at the TX which start with 0x7E 0xFD.
Please tell me, that I got it now
Best regards,
Norbert
Re: Raw level protocol
You are right.
I just noticed a minor type mistake in your post.
You wrote:
0x7E 0xFE "8 Bytes" 0x7E - I ignore this
It should be
0x7E 0xFD "8 Bytes" 0x7E - I ignore this.
I think that you have also to take care that when the delay between 2 bytes sent to RX is short, it could be that the 2 bytes would be merge into one single frame.
I do not know what "short" is but Mike know it probably.
I just noticed a minor type mistake in your post.
You wrote:
0x7E 0xFE "8 Bytes" 0x7E - I ignore this
It should be
0x7E 0xFD "8 Bytes" 0x7E - I ignore this.
I think that you have also to take care that when the delay between 2 bytes sent to RX is short, it could be that the 2 bytes would be merge into one single frame.
I do not know what "short" is but Mike know it probably.
Re: Raw level protocol
Hi,
I think it's the other way around.
0x7E 0xFE
is the standart frame, which I ignore.
0x7E 0xFD
is where I can see my Bytes which I have sent.
Am I wrong?
Best regards,
Norbert
I think it's the other way around.
0x7E 0xFE
is the standart frame, which I ignore.
0x7E 0xFD
is where I can see my Bytes which I have sent.
Am I wrong?
Best regards,
Norbert
Re: Raw level protocol
You are right.Norbert wrote:Hi,
I think it's the other way around.
0x7E 0xFE
is the standart frame, which I ignore.
0x7E 0xFD
is where I can see my Bytes which I have sent.
Am I wrong?
Best regards,
Norbert
I misunderstood your previous post. Sorry for the confusion.
Re: Raw level protocol
Hi,
I think I got it. Now my hardare is running with inverters and I can see the received data as described.
The byte stuffing is obviously not counted as two bytes, 0x7D 0x5E only counts as one byte.
So by the length of the frame one can distinguish between a byte stuffed 0x7E and normal data if 0x7D 0x5E appears.
To keep things simple, I'll just avoid 0x7E in my data.
Problem solved - thanks!
Best regards,
Norbert
I think I got it. Now my hardare is running with inverters and I can see the received data as described.
The byte stuffing is obviously not counted as two bytes, 0x7D 0x5E only counts as one byte.
So by the length of the frame one can distinguish between a byte stuffed 0x7E and normal data if 0x7D 0x5E appears.
To keep things simple, I'll just avoid 0x7E in my data.
Problem solved - thanks!
Best regards,
Norbert
- MikeB
- 9x Developer
- Posts: 18000
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Raw level protocol
You will need to avoid 0x7D as well as this is also byte stuffed, 0x7D is appears as 0x7D 0x5D.
Mike.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Raw level protocol
Hi,
oh, no problem, thanks for the hint.
Best regards,
Norbert
oh, no problem, thanks for the hint.
Best regards,
Norbert