SMALL - espritmodel.com SMALL - Telemetry SMALL - Radio
Reply
Thread Tools
Old Mar 08, 2010, 08:16 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
15,208 Posts
$ 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.
renatoa is online now Find More Posts by renatoa
Reply With Quote
Sign up now
to remove ads between posts
Old Mar 08, 2010, 08:39 AM
Dan Thompson (MP8K developer)
Iflyj3's Avatar
USA, KY, Paris
Joined Dec 2002
329 Posts
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.
Iflyj3 is offline Find More Posts by Iflyj3
Reply With Quote
Old Mar 08, 2010, 06:48 PM
Registered User
Joined Mar 2009
297 Posts
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.
Chase Wu is offline Find More Posts by Chase Wu
Reply With Quote
Old Mar 08, 2010, 10:14 PM
Registered User
Melbourne, Australia
Joined May 2006
6,407 Posts
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) ?
kgfly is offline Find More Posts by kgfly
Last edited by kgfly; Mar 08, 2010 at 10:22 PM.
Reply With Quote
Old Mar 09, 2010, 05:09 AM
Dan Thompson (MP8K developer)
Iflyj3's Avatar
USA, KY, Paris
Joined Dec 2002
329 Posts
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.
Iflyj3 is offline Find More Posts by Iflyj3
Reply With Quote
Old Mar 09, 2010, 06:56 AM
Registered User
Melbourne, Australia
Joined May 2006
6,407 Posts
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 }
kgfly is offline Find More Posts by kgfly
Reply With Quote
Old Mar 09, 2010, 07:08 AM
Dan Thompson (MP8K developer)
Iflyj3's Avatar
USA, KY, Paris
Joined Dec 2002
329 Posts
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.
Iflyj3 is offline Find More Posts by Iflyj3
Reply With Quote
Old Mar 09, 2010, 07:28 AM
Registered User
Melbourne, Australia
Joined May 2006
6,407 Posts
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).
kgfly is offline Find More Posts by kgfly
Reply With Quote
Old Mar 10, 2010, 07:33 PM
Registered User
Joined Mar 2009
297 Posts
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.
Chase Wu is offline Find More Posts by Chase Wu
Reply With Quote
Old Mar 10, 2010, 08:16 PM
Registered User
Melbourne, Australia
Joined May 2006
6,407 Posts
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
kgfly is offline Find More Posts by kgfly
Reply With Quote
Old Mar 10, 2010, 10:07 PM
Dan Thompson (MP8K developer)
Iflyj3's Avatar
USA, KY, Paris
Joined Dec 2002
329 Posts
Very good and I am looking forward to your communications design document and hardware.
Iflyj3 is offline Find More Posts by Iflyj3
Reply With Quote
Old Mar 11, 2010, 04:26 AM
Registered User
Joined Mar 2007
73 Posts
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/
bray is offline Find More Posts by bray
Reply With Quote
Old Mar 11, 2010, 08:49 AM
Dan Thompson (MP8K developer)
Iflyj3's Avatar
USA, KY, Paris
Joined Dec 2002
329 Posts
Here are my flowcharts for transparent binary with the change suggested by KGFLY.
Iflyj3 is offline Find More Posts by Iflyj3
Reply With Quote
Old Mar 18, 2010, 08:17 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
15,208 Posts
Hurry, hurry, with those modules, we want to have this before Hitec, right ?
renatoa is online now Find More Posts by renatoa
Reply With Quote
Old Mar 18, 2010, 06:39 PM
Registered User
Melbourne, Australia
Joined May 2006
6,407 Posts
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.
kgfly is offline Find More Posts by kgfly
Reply With Quote
Reply


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Mini-Review FrSky 2.4ghz - looking good so far! BrumBob Radios 12927 Today 05:16 PM
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
Cool TWIN 2.4GHz new RFHSS system from CZ, with or w/o Telemetry alex.guzun Radios 5 Jan 18, 2010 03:24 PM
Mini-Review The video for FrSky 2.4Ghz Chase Wu Radios 0 Dec 16, 2009 02:18 AM