SMALL - espritmodel.com SMALL - Telemetry SMALL - Radio
Reply
Thread Tools
Old Mar 18, 2010, 07:21 PM
Registered User
Joined Mar 2009
295 Posts
This is the pre-release version of our two-way system protocol.
Sorry to say that our two-way system was delayed for couple of weeks, due to that we are doing backward compatibility to V8 receivers.
And the two-way system would be user upgradable.

Here we have to give many thanks to many persons for good suggestions.
Chase Wu is offline Find More Posts by Chase Wu
Reply With Quote
Sign up now
to remove ads between posts
Old Mar 18, 2010, 07:51 PM
Ready to fly MRs
Sid3ways's Avatar
Swanton, OH
Joined Jul 2007
5,050 Posts
Quote:
Originally Posted by Chase Wu View Post
This is the pre-release version of our two-way system protocol.
Sorry to say that our two-way system was delayed for couple of weeks, due to that we are doing backward compatibility to V8 receivers.
And the two-way system would be user upgradable.

Here we have to give many thanks to many persons for good suggestions.
Can't wait for it to come out. I'm ready to try one out. I do like the description of the unit on your website.

Quote:
FrSky is going to present a new 2.4GHz Two Way communication system which will make your hobby life rich and varied. It will provide you a reliable, funny experience of Duplex Communication.
Sid3ways is online now Find More Posts by Sid3ways
Reply With Quote
Old Mar 18, 2010, 09:31 PM
Registered User
Melbourne, Australia
Joined May 2006
6,407 Posts
Chase - great to see progress on the protocol. To make sure I understand the specification properly are the following statements correct?

1) All logical frames are 11 bytes long and consist of: [0x7E][9 payload bytes][0x7E]

2) Physical frames on the wire can theoretically be up to 20 bytes long since in the worst case, byte stuffing can double the number of payload bytes. In practice the longest frame would be a user-data frame containing 6 user values of 0x7E or 0x7D which would be expanded to 17 bytes due to byte stuffing.
kgfly is offline Find More Posts by kgfly
Reply With Quote
Old Mar 18, 2010, 09:57 PM
Registered User
Joined Mar 2009
295 Posts
Quote:
Originally Posted by kgfly View Post
Chase - great to see progress on the protocol. To make sure I understand the specification properly are the following statements correct?

1) All logical frames are 11 bytes long and consist of: [0x7E][9 payload bytes][0x7E]

2) Physical frames on the wire can theoretically be up to 20 bytes long since in the worst case, byte stuffing can double the number of payload bytes. In practice the longest frame would be a user-data frame containing 6 user values of 0x7E or 0x7D which would be expanded to 17 bytes due to byte stuffing.
kgfly, right as you discribed.
by byte stuff, the frame length is variable.
Chase Wu is offline Find More Posts by Chase Wu
Reply With Quote
Old Mar 18, 2010, 10:51 PM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,678 Posts
Quote:
Originally Posted by kgfly View Post
Chase - great to see progress on the protocol. To make sure I understand the specification properly are the following statements correct?

1) All logical frames are 11 bytes long and consist of: [0x7E][9 payload bytes][0x7E]

2) Physical frames on the wire can theoretically be up to 20 bytes long since in the worst case, byte stuffing can double the number of payload bytes. In practice the longest frame would be a user-data frame containing 6 user values of 0x7E or 0x7D which would be expanded to 17 bytes due to byte stuffing.
Kgfly, you seem to be the SME (Subject Matter Expert) for the protocol discussion on behalf of the group. (I hope you don't mind that, but somebody needs to be the guru for us).
What would be good now is a firm 'Yes, that will do FrSky', or 'No, maybe it should be...' type statement from you (or Iflyj3). I know that put's you on the spot so to speak.

That way FrSky can be sure they have what we want, and we can go off and starting coding up apps and hardware for it.

What do you think ?
(BTW I think it looks fine, but I'm not an SME )
Thanks,
Martin
PLMS is offline Find More Posts by PLMS
Reply With Quote
Old Mar 19, 2010, 12:22 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
14,513 Posts
Quote:
Originally Posted by kgfly View Post
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.
In Hitec Aurora thread, quoted from a Brazilian Hitec sales rep, seems fake to me, but looks good
Hitec claims having a system not obeying any known antenna laws, as perfect omni directional reception with single antenna, so what matters one more physics laws break
renatoa is offline Find More Posts by renatoa
Reply With Quote
Old Mar 19, 2010, 01:11 AM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,678 Posts
Quote:
Originally Posted by RENATOA View Post
In Hitec Aurora thread, quoted from a Brazilian Hitec sales rep, seems fake to me, but looks good
Hitec claims having a system not obeying any known antenna laws, as perfect omni directional reception with single antenna, so what matters one more physics laws break
"perfect omni directional reception with single antenna"
Ha haaaaaa haa haaa... ROTFLMAO

Perfect, next they'll have a TX that absorbs power from unknown cosmic sources too so it doesn't need batteries..
PLMS is offline Find More Posts by PLMS
Reply With Quote
Old Mar 19, 2010, 01:42 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
14,513 Posts
The thread is here:
http://www.rcgroups.com/forums/showthread.php?t=1150136

I seen kgfly posted there, so he must be aware.
Please, be gentle with them
renatoa is offline Find More Posts by renatoa
Last edited by renatoa; Mar 19, 2010 at 01:54 AM.
Reply With Quote
Old Mar 19, 2010, 01:51 AM
Registered User
Melbourne, Australia
Joined May 2006
6,407 Posts
Martin I think the solution is a good one and will allow the transparent data transfer that we were hoping to have available.

It is a good choice as it is very simple to code and test. That means folks writing their own tools to process the frames should find it very straight forward to do so.

IMO it's full steam ahead

Quote:
Originally Posted by PLMS View Post
Kgfly, you seem to be the SME (Subject Matter Expert) for the protocol discussion on behalf of the group. (I hope you don't mind that, but somebody needs to be the guru for us).
What would be good now is a firm 'Yes, that will do FrSky', or 'No, maybe it should be...' type statement from you (or Iflyj3). I know that put's you on the spot so to speak.

That way FrSky can be sure they have what we want, and we can go off and starting coding up apps and hardware for it.

What do you think ?
(BTW I think it looks fine, but I'm not an SME )
Thanks,
Martin
kgfly is offline Find More Posts by kgfly
Reply With Quote
Old Mar 19, 2010, 03:53 AM
Dan Thompson (MP8K developer)
Iflyj3's Avatar
USA, KY, Paris
Joined Dec 2002
329 Posts
I like the solution. However, If I read the manual correctly, the user data is limited to a 11 byte frame also.

0x7E, 0xFD, Length of valid bytes, Not used, byte1, byte2 to byte6, 0x7E

This means all user data is limited to 6 bytes each frame. That is not a problem for what I want to do. But, this means in order to hook a device that sends a variable frame length, you would have to have a translator of some kind between the device and the FrSky receiver to reformat the data.

KGFLY, did I read the manual correctly? Or should the above read as below?

0x7E, 0xFD, Length of valid bytes, Not used, byte1, byte2 to byten, 0x7E

Otherwise, the length of valid bytes is not needed.

Dan


Quote:
Originally Posted by PLMS View Post
Kgfly, you seem to be the SME (Subject Matter Expert) for the protocol discussion on behalf of the group. (I hope you don't mind that, but somebody needs to be the guru for us).
What would be good now is a firm 'Yes, that will do FrSky', or 'No, maybe it should be...' type statement from you (or Iflyj3). I know that put's you on the spot so to speak.

That way FrSky can be sure they have what we want, and we can go off and starting coding up apps and hardware for it.

What do you think ?
(BTW I think it looks fine, but I'm not an SME )
Thanks,
Martin
Iflyj3 is offline Find More Posts by Iflyj3
Reply With Quote
Old Mar 19, 2010, 04:17 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
14,513 Posts
Indeed, how will you send a NMEA GPS string of xx, maybe 1xx bytes, with this protocol?
Cut in pieces? hmmm ... not so nice to reassembly.
Also, be aware that I have in progress discussions with people interested to design an extender of this system, a hub allowing up to 8 ADC, temperatures, RPM, possible more, that will be hooked on serial line, and need a simple, transparent and fast path to the ground.
I would rather think to an approach where the two ADC values are converted to pure ASCII, and packed in a custom string having a syntax close to NMEA, which I want to adopt for the above hub/extender.
renatoa is offline Find More Posts by renatoa
Reply With Quote
Old Mar 19, 2010, 06:33 AM
Registered User
Melbourne, Australia
Joined May 2006
6,407 Posts
My understanding is that the protocol as currently defined will indeed require segmenting the user data into 6-byte blocks to be delivered. Until we know the achievable maximum sustained frame rate it is hard to say what the user throughput will be.

As I read it the "Host end" is the Tx and the "remote end" is the Rx. The input to the Rx from sensors is indeed a naked byte stream. I presume that the Rx segments and encodes the user data into the UserData frames and sends them to the Tx where they appear on the serial output port.

So the end-user application will simply have to decode the frames received from the Rx via the Tx and reassemble the byte stream, which should be quite simple to do. In order to support setting/getting alarm thresholds and monitoring of built in sensor values the end-user application will also have to be able to encode query frames according to the protocol and interpret the other output frame types (as identified by the value of the Head2 byte).
kgfly is offline Find More Posts by kgfly
Reply With Quote
Old Mar 19, 2010, 06:37 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
14,513 Posts
But is a lot of overhead ! Will halve practically the transmitting speed...
For what ?! Why these packets, and why sending binary data, when serial comm is almost ASCII, that's why hyperterminal exists...

My proposal is the following:
- because at ground there is required a NMEA parser anyway...
- represent the two ADC ports as ascii chars of the hexa values, i.e. 0x00-0xff = "00"-"FF"
- pack them into a string having the NMEA syntax, i.e $Gxxx <FrSky string here> CRLF
- interlace the frsky strings with NMEA strings when GPS is hooked, using the logic: if any serial data present, let it pass transparently to the ground, watching for CRLF, end of sentence. Then, insert your FrSky sentence, while buffering the incoming serial stream, if any. An old type 1Hz GPS will load a 4800bauds line about 25%, so there will be a lot of gaps to insert the FrSky packets. However, for a modern 5Hz GPS - today they are the norm, no more 1Hz units - 4800baud is not enough, it requires at least 9600baud, so I suggest this speed as default, all today GPS units understand it. Even 9600 is at the edge, the OSD I know jump at 38400baud after some negotiation between GPS and OSD. This is quite common in today OSDs initialization.

Any future custom device that will connect at receiver serial port should comply with NMEA syntax.
This way will have a consistent handling of all present and future streams, imo.

This is the way how remzibi OSD communicates with ArduPilot, and seems very effective.
renatoa is offline Find More Posts by renatoa
Last edited by renatoa; Mar 19, 2010 at 06:59 AM.
Reply With Quote
Old Mar 19, 2010, 06:58 AM
Dan Thompson (MP8K developer)
Iflyj3's Avatar
USA, KY, Paris
Joined Dec 2002
329 Posts
The one item we do not know is how the Rx transmits data to the Host end. I do know that most 2.4 transmissions are not a continuous data stream. Therefore, maybe only time slices long enough to send 11 bytes is available.

As KGFLY says, If the user data to the RX port is naked and the Rx and Host put it into frames and them strip it out to hand the user at the host end naked data, that will work. Yes, it is possible that the effective data speed may take longer and them again it may not.

Dan
Iflyj3 is offline Find More Posts by Iflyj3
Reply With Quote
Old Mar 19, 2010, 07:07 AM
Registered User
Melbourne, Australia
Joined May 2006
6,407 Posts
Well that is true, it is not bandwidth efficient, but whether that matters depends upon the bandwidth needed and the total available. Can you estimate the volume of data you would like to send per second ? Potentially the back channel from the Rx to the Tx could be tens to hundreds of kilobits/s.

Let's say you have 8 sensors sampled once per second which need 16 bytes each plus a GPS frame which is 100 bytes (just guessing for argument sake) then you have around 228 user bytes to send. Call it 40 frames at 12 octets each (allowing for one byte stuff per frame on average) = 3840 bits per second. I would hope the back channel can support quite a bit more than that, possibly ten times more. If that is the case then the inefficiency doesn't really matter.
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 12772 Yesterday 09: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