HobbyKing.com New Products Flash Sale
Reply
Thread Tools
Old Mar 06, 2010, 04:04 PM
Registered User
Melbourne, Australia
Joined May 2006
6,407 Posts
I am not sure, I had understood that the frames were fixed length (10 octets). If that is not so and they are variable length then the frame design needs more work. The historical solution to this problem (from way back in SDLC/HDLC days) is a technique called byte-stuffing. With byte stuffing the framing sequence can only ever occur once per frame. If the frame payload contains the sequence it is modified with extra tokens inserted to mark the special values.
Quote:
Asynchronous framing
When using asynchronous serial communication such as standard RS-232 serial ports, bits are sent in groups of 8, and bit-stuffing is inconvenient. Instead they use "control-octet transparency", also called "byte stuffing" or "octet stuffing". The frame boundary octet is 01111110, (7E in hexadecimal notation). A "control escape octet", has the bit sequence '01111101', (7D hexadecimal). If either of these two octets appears in the transmitted data, an escape octet is sent, followed by the original data octet with bit 5 inverted. For example, the data sequence "01111110" (7E hex) would be transmitted as "01111101 01011110" ("7D 5E" hex). Other reserved octet values (such as XON or XOFF) can be escaped in the same way if necessary.
Adopting this well proven and very simple to code technique would avoid problems with false framing, data dropouts, false alarms etc. The only downside is that the raw data is slightly less human-readable and that the average frame size goes up slightly, depending upon the frequency of occurrence of the framing token in the payload data.

If a decision is made to change to this approach I would advocate using the standard HDLC framing token 0x7E rather than the two-octet token 0xFFFE since it allows the encode and decode logic to remain purely byte-oriented and hence much simpler.
kgfly is online now Find More Posts by kgfly
Reply With Quote
Sign up now
to remove ads between posts
Old Mar 06, 2010, 04:41 PM
Dan Thompson (MP8K developer)
Iflyj3's Avatar
USA, KY, Paris
Joined Dec 2002
329 Posts
We used to call that transparent binary in asychronous mode.
Iflyj3 is offline Find More Posts by Iflyj3
Reply With Quote
Old Mar 07, 2010, 02:16 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
14,673 Posts
Quote:
Originally Posted by MGeo View Post
Chase,

The two way feature opens many possibilities. I would like to take you up on your offer. Could you please post the source code for the software?

Thanks,
MGeo
Anyone got these?
renatoa is online now Find More Posts by renatoa
Reply With Quote
Old Mar 07, 2010, 06:33 AM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,683 Posts
Quote:
Originally Posted by RENATOA View Post
Isn't the NMEA GPS data coming mixed with ADC data in the same stream ?
How can you maintain this sync in this case ?
My take on the document was that the inbuilt telemetry was framed by FFFE and the last five bytes are alway 00h. The RS232 data feed is sent in a separate frame FFFD with a byte count and then data. That would mean the local end needs to differentiate two frame headers and keep byte counts...

I'm closer to getting back on the this topic hardware wise, a couple more days to fight clear of other commitments.
I'll hook up my Garmin Etrex to the RX serial port, and capture the local end stream for you all to view.

Martin

PS. KGFLY - Great info on the stateful parser, I think even I can follow it. If I'm clever enough to write the PIC code I'm not so sure.
PLMS is offline Find More Posts by PLMS
Last edited by PLMS; Mar 07, 2010 at 06:39 AM.
Reply With Quote
Old Mar 07, 2010, 06:34 AM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,683 Posts
Quote:
Originally Posted by RENATOA View Post
Anyone got these?
No, not me but I didn't ask Chase for the source code. Did anyone ask for the files ?

Martin
PLMS is offline Find More Posts by PLMS
Reply With Quote
Old Mar 07, 2010, 07:21 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
14,673 Posts
Quote:
Originally Posted by PLMS View Post
No, not me but I didn't ask Chase for the source code. Did anyone ask for the files ?

Martin
Me, one week ago.
renatoa is online now Find More Posts by renatoa
Reply With Quote
Old Mar 07, 2010, 11:39 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
14,673 Posts
Chase, while the protocol is not yet frozen for production, I want to share here, some points that others telemetry system lacks, making them not so useful as could be, and customers angry
Please, consider to add a special frame with a receiver identifier, allowing this way to implement some kind of "model match".
Purpose: let assume you have several planes powered from various packs, 2s, 3s, 4s, not talking about LiFe (A123). How will be switched the alarm levels when you switch model ? Manually ? Is the shortest way to mistake, and why not disaster, imo...
The obvious right solution is to identify the receiver/plane and have stored a list of models on the display unit, with their features (pack, alarms, etc), and select it automaticaly.
BTQ, I hope the receiver features updatable firmware, isn't it ? I guess the GPS port can be used for this purpose, using an update application via COM line and/or an USB to COM adapter.
renatoa is online now Find More Posts by renatoa
Reply With Quote
Old Mar 07, 2010, 04:25 PM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,683 Posts
Quote:
Originally Posted by RENATOA View Post
Please, consider to add a special frame with a receiver identifier, allowing this way to implement some kind of "model match".
Purpose: let assume you have several planes powered from various packs, 2s, 3s, 4s, not talking about LiFe (A123). How will be switched the alarm levels when you switch model ? Manually ? Is the shortest way to mistake, and why not disaster, imo...
Yes, very good point that. Further to that idea, if the last five bytes of the telemetry frame are unused yet, one or more bytes could be used for that purpose. That's only if my interpretation of the protocol doco is right of course...

I wonder if FrSky are already working on 'model match' for this system ?
Chase ?
PLMS is offline Find More Posts by PLMS
Reply With Quote
Old Mar 07, 2010, 04:33 PM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,683 Posts
Quote:
Originally Posted by RENATOA View Post
Me, one week ago.
Oh. OK, did anyone else get hold of it ?
I have a need for a modified version.

I'd like the 'chart recorder' window scroll speed to be user variable. I'd like it slowed down so I can get a driven range test done all on one screen. We're talking about 3 minutes across the screen I think.

Also it would be good if there was a 'Log to File' function. Even better would be that plus the ability to 'replay' the files back on the screens, and freeze them at any point.
This will help me testing and development a lot.

Chase can we have the source code please ?
If FrSky has just reconsidered that idea of open source code, please let us know (I have no problem with that if you have changed your minds).

Martin
PLMS is offline Find More Posts by PLMS
Reply With Quote
Old Mar 07, 2010, 06:36 PM
Registered User
Joined Mar 2009
295 Posts
Quote:
Originally Posted by kgfly View Post
I am not sure, I had understood that the frames were fixed length (10 octets). If that is not so and they are variable length then the frame design needs more work. The historical solution to this problem (from way back in SDLC/HDLC days) is a technique called byte-stuffing. With byte stuffing the framing sequence can only ever occur once per frame. If the frame payload contains the sequence it is modified with extra tokens inserted to mark the special values.Adopting this well proven and very simple to code technique would avoid problems with false framing, data dropouts, false alarms etc. The only downside is that the raw data is slightly less human-readable and that the average frame size goes up slightly, depending upon the frequency of occurrence of the framing token in the payload data.

If a decision is made to change to this approach I would advocate using the standard HDLC framing token 0x7E rather than the two-octet token 0xFFFE since it allows the encode and decode logic to remain purely byte-oriented and hence much simpler.
Thanks, kgfly, good point of that, we would add these changes to the releasing protocol.
Chase Wu is offline Find More Posts by Chase Wu
Reply With Quote
Old Mar 07, 2010, 06:51 PM
Registered User
Joined Mar 2009
295 Posts
Attached is the source code of our trial verion, designed in QT.
It is free and no license needed, any one wants to do something is free to download.

RENATOA, so, I think you could download the source code here.
and thanks to your kind suggestion, we will do "model matches" in release version.

Martin, here is the first publication of our source code, I am anticipating it would be any help.
Chase Wu is offline Find More Posts by Chase Wu
Last edited by Chase Wu; Mar 07, 2010 at 07:56 PM.
Reply With Quote
Old Mar 08, 2010, 05:50 AM
Registered User
Manila, Philippines
Joined Jul 2004
1,203 Posts
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 is offline Find More Posts by lazy-b
Reply With Quote
Old Mar 08, 2010, 06:30 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
14,673 Posts
This is the way how the serial line of the receiver works.
It is not a dedicated GPS line, it just sends and receive GPS stream "transparent" to/from transmitter module.
renatoa is online now Find More Posts by renatoa
Reply With Quote
Old Mar 08, 2010, 06:49 AM
Dan Thompson (MP8K developer)
Iflyj3's Avatar
USA, KY, Paris
Joined Dec 2002
329 Posts
Quote:
Originally Posted by RENATOA View Post
This is the way how the serial line of the receiver works.
It is not a dedicated GPS line, it just sends and receive GPS stream "transparent" to/from transmitter module.
IIRC the GPS string begins with a "$" sign and is terminated with a CR & LF.
The string is ASCII and not binary as the voltage messages from the receiver appear to be. How does the system intermix these messages? If it does intermix these, decoding will be next to impossible.
Iflyj3 is offline Find More Posts by Iflyj3
Reply With Quote
Old Mar 08, 2010, 07:14 AM
Registered User
Joined Oct 2009
29 Posts
Quote:
Originally Posted by lazy-b View Post

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.
I would like both my serial data & the in-built data, so, if there is a switch, it would be ok.
RobertWing is offline Find More Posts by RobertWing
Last edited by RobertWing; Mar 08, 2010 at 07:22 AM.
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 12783 Today 11:33 AM
Discussion New Audio Modem Protocol For FPV Telemetry MelihK FPV Talk 138 Dec 31, 2011 09:24 AM
New Product FrSky 2.4GHz radio system jonathan-FrSky Australia 70 Apr 28, 2011 04:22 PM
Cool TWIN 2.4GHz new RFHSS system from CZ, with or w/o Telemetry alex.guzun Radios 5 Jan 18, 2010 02:24 PM
Mini-Review The video for FrSky 2.4Ghz Chase Wu Radios 0 Dec 16, 2009 01:18 AM