Shop our Airplanes Products Drone Products Sales
Thread Tools
Old Mar 08, 2010, 08:16 AM
renatoa is online now
Find More Posts by renatoa
Registered User
$ and CRLF are part of the GPS stream, they are not added by FrSky. If instead GPS we plug there other device sending other stream, I guess they arrive at transmitter OK.
How are interleaved? I don't know yet, probably as Martin suggested, see #34 upper in this page, as a FF FD user data frame.
Sign up now
to remove ads between posts
Old Mar 08, 2010, 08:39 AM
Iflyj3 is offline
Find More Posts by Iflyj3
Dan Thompson (MP8K developer)
Iflyj3's Avatar

Transparent binary.


If it will influence any. Here are flowcharts of the transparent binary mode I have used for years. Feel free to use them.

If all data was framed as such, all data could be sent down the line and parsing would be easy.

You will notice the simularity to the SDLC and HDLC protocols. However this was around before those methods.
Old Mar 08, 2010, 06:48 PM
Chase Wu is offline
Find More Posts by Chase Wu
Registered User
Quote:
Originally Posted by lazy-b View Post
Chase wu,

here is another suggestion hope there is a TRANSPARENT MODE, this means I can send any Serial data into the receiver and it will output to the Transmitter modules. with this I do not need a special controller to attach it to computer.

With the Transparent mode, No need to develop special program for PC, you can just use Hyperterminal to capture the data files, then the capture data files can easily import to EXCEL spreadsheets for data analysis.
Lazy-b, I will deliver your point to our engineer, thanks for your always attention & good suggestion.
Old Mar 08, 2010, 10:14 PM
kgfly is offline
Find More Posts by kgfly
Registered User
Iflyj3 - It looks like your solution uses the DLE character (0x10) as an 'escape' character to identify that the following octet should be used as-is and not interpreted as having special meaning. I don't get the action description that says "Send DLE + Char+1". What is the "+1" ? Does it mean that you send a three-octet sequence: 0x10 <char> 0x01 ?

[edit]Ah now I see from the examples, you meant "Send DLE + (Char+1)", that is, increment the value of the character following the escape character. Any particular reason you didn't keep the rule uniform and instead have a special case for DLE (where you send 0x10 x10 instead of 0x10 0x11) ?
Last edited by kgfly; Mar 08, 2010 at 10:22 PM.
Old Mar 09, 2010, 05:09 AM
Iflyj3 is offline
Find More Posts by Iflyj3
Dan Thompson (MP8K developer)
Iflyj3's Avatar
Quote:
Originally Posted by kgfly View Post
Iflyj3 - It looks like your solution uses the DLE character (0x10) as an 'escape' character to identify that the following octet should be used as-is and not interpreted as having special meaning. I don't get the action description that says "Send DLE + Char+1". What is the "+1" ? Does it mean that you send a three-octet sequence: 0x10 <char> 0x01 ?

[edit]Ah now I see from the examples, you meant "Send DLE + (Char+1)", that is, increment the value of the character following the escape character. Any particular reason you didn't keep the rule uniform and instead have a special case for DLE (where you send 0x10 x10 instead of 0x10 0x11) ?
Good point about the DLE DLE. I didn't invent the method, just used it many times over the last 40+ years. The only answer I have is the current method reduces the transmit and receive routines by at least one instruction each.
Old Mar 09, 2010, 06:56 AM
kgfly is offline
Find More Posts by kgfly
Registered User
Fair enough, thanks for the clarification. Seems to me the code would be simpler if uniform. Something like this:

Tx: if <char> == (CR or LF or DLE) then { send(0x10); send (<char> + 1); }
Rx: if <char> == DLE then { discard; offset = -1; } else { <char> += offset; offset = 0 }
Old Mar 09, 2010, 07:08 AM
Iflyj3 is offline
Find More Posts by Iflyj3
Dan Thompson (MP8K developer)
Iflyj3's Avatar
Quote:
Originally Posted by kgfly View Post
Fair enough, thanks for the clarification. Seems to me the code would be simpler if uniform. Something like this:

Tx: if <char> == (CR or LF or DLE) then { send(0x10); send (<char> + 1); }
Rx: if <char> == DLE then { discard; offset = -1; } else { <char> += offset; offset = 0 }
No problem with a change. I think the important thing is for some kind of uniform protocol be used so we users/programmers/decoders can easily use the telemetry data. That is why I offered the method I have used.

FrSky could use a preamble to identify what the record type follows and this protocol would allow that without any problem. To continue like they apparently are now will render the user RS232 interface basically unusable if the FrSky analog and voltage readings are interspersed.

Of course, I am judging this based on no detailed manual that explains the FrSky communications.
Old Mar 09, 2010, 07:28 AM
kgfly is offline
Find More Posts by kgfly
Registered User
I agree completely. For this two-way system to be successful as an open platform FrSky need to adopt a clean and well defined protocol for sending a transparent octet stream and then define a well structured frame format to make it easy to identify the data types.

For the protocol, basic HDLC (0x7E as frame start/end, byte-stuffing to escape 0x7E in the data), your protocol or my variant of yours would all do the job well, are simple to write and cost little in codespace or performance.

For the frame definition, even a one-octet frame-type code might be enough. This would allow the decoder to distinguish amongst Analog values, Alarm alerts and user-data.

The mechanism for handling user serial data needs a little thought as well. If the channel is a transparent octet stream then how does the Rx know when to send a frame? Options include: whenever a certain number of octets have been buffered (eg 16, 32, 64 etc), whenever a CR is received or whenever the buffered data is more than a certain age (ie it has been 500ms since the last octet was buffered).
Old Mar 10, 2010, 07:33 PM
Chase Wu is offline
Find More Posts by Chase Wu
Registered User
This is the message from our engineers
Quote:
The FFF* header introduced is intended to minimize the complexity of the frame decoder, but the question araised because the AD1 & AD2 may also generate the same pattern.
Both Iflyj3 & kgfly's solution are OK, and the choise is kgfly's, so, the protocol would be changed, and the new protocol would be released soon. Give my respect to Iflyj3 too.
Thank you.
Old Mar 10, 2010, 08:16 PM
kgfly is offline
Find More Posts by kgfly
Registered User
My compliments to the FrSky team for being open to feedback and considering our ideas and suggestions. I am not sure whether you engineer chose the HDLC style protocol or the modified version of Iflyj3's protocol but either way I think it is a good decision which will greatly improve the product at very little engineering cost and only a small increase in complexity.

We look forward to a clear document defining the new protocol and frame format
Old Mar 10, 2010, 10:07 PM
Iflyj3 is offline
Find More Posts by Iflyj3
Dan Thompson (MP8K developer)
Iflyj3's Avatar
Very good and I am looking forward to your communications design document and hardware.
Old Mar 11, 2010, 04:26 AM
bray is offline
Find More Posts by bray
Registered User

terminal program


Finally open protocol for feed back data. Good job FrSky!
This is my com port debugging tool if anyone interested...

http://sites.google.com/site/terminalbpp/
Old Mar 11, 2010, 08:49 AM
Iflyj3 is offline
Find More Posts by Iflyj3
Dan Thompson (MP8K developer)
Iflyj3's Avatar
Here are my flowcharts for transparent binary with the change suggested by KGFLY.
Old Mar 18, 2010, 08:17 AM
renatoa is online now
Find More Posts by renatoa
Registered User
Hurry, hurry, with those modules, we want to have this before Hitec, right ?
Old Mar 18, 2010, 06:39 PM
kgfly is offline
Find More Posts by kgfly
Registered User
Where did you find that ?

I wonder about the wisdom of having an iPhone with its metal backplate mounted between the antenna and the model ! Seems to me it would create a significant shadow in the radiated pattern.


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Mini-Review FrSky 2.4ghz - looking good so far! BrumBob Radios 13362 Sep 26, 2016 04:03 AM
Cool TWIN 2.4GHz new RFHSS system from CZ, with or w/o Telemetry alex.guzun Radios 6 Jul 31, 2016 11:41 AM
Discussion New Audio Modem Protocol For FPV Telemetry MelihK FPV Talk 138 Dec 31, 2011 10:24 AM
New Product FrSky 2.4GHz radio system jonathan-FrSky Australia 70 Apr 28, 2011 05:22 PM
Mini-Review The video for FrSky 2.4Ghz Chase Wu Radios 0 Dec 16, 2009 02:18 AM