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.

Originally Posted by Chase Wu

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.

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.

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.

Originally Posted by kgfly

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.

Originally Posted by kgfly

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

Originally Posted by kgfly

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

Originally Posted by RENATOA

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..

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

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

Originally Posted by PLMS

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

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

Originally Posted by PLMS

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

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.

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).

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.

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

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.