I had another moment to play. While this is all fairly basic electronics for most of us I thought it worth posting up, so guy's with less experience with this sort of thing can get across it step by step from the start.

I set up two trim pots across ground and the 3.3V pins on the two RX A/D ports. The pot wiper to the AD1 and AD2 pins. So I could drive the A/D full range and see how they tick. See photo. They've setup the pins nicely so servo cable colours work well for sensor connections.

At the TX end I now used an old copy of Hexterm that has been modified by somebody to do a CR & LF at every FF hex byte read in. I just stumbled on it in my old file collection.
This helps heaps as the frames now line up down the RHS of the screen on the laptop. I've attached the old Hexterm file in a zip.

First note.
The AD1 and AD2 have a range of 00h to FFh (as they quote).

Second note.
AD1 is NOT the third byte, it's the fourth. AD2 is on byte three. So the frame is FF FE AD2 AD1 BER 00 00 00 00 00 . Either an error in the pin diagram for the RX or a mistake in the frame protocol note. I think the pin diagram...

Third note.
There is a bit of a potential issue with the FF FE header at the local end (and others I guess). Because the AD1 and AD2 range includes FF it's possible to have those two bytes containing FF FE as valid AD voltages. That becomes a problem if you are parsing the incoming frames by looking for the header of FF FE... It's possible you will get data corruption became your serial routine just happens to capture the data from byte three and four (starting at 1, not 0) and thinks this is the start of the frame, not the real one in the first and second bytes.

So anybody got an idea on a simple way to avoid the remote possibility of corruption if the AD1 & AD2 data just happens to be FF FE, please post the thought here ?

Originally Posted by PLMS

Any VB guy's listening on the thread ?
...
Can anyone do this, or know of an existing app ?

Here you are...
Obviously, tests were minimal, not owning the hardware.

Another thing to ponder is how we can use the two A/D inputs.

Since full scale is 3300mV for FF or about 13mV per step, we'd need about a 7.6:1 voltage divider on the input from say a 6S flight pack to get it down to less than 3.3V at full charge. If you use 7.6:1 then the step resolution of the AD input is now only about 100mV per step. That's OK for alarm points, but maybe not enough for high accuracy battery volt measurements.

For 3S flight packs we should be able to get about 50mV resolution per step. Which is probably not too bad to display or record on an external display etc.

To get more resolution, an external AD converter with digital output is needed (and convert to serial data @ 4800b etc), or FrSky could see if the FrSky's Two-Way RX's AD inputs could be easily boosted to 10 bits instead of 8 bits. Chase ?

PS. If my math is wrong just tell me, I'm not thin skinned

No need for such precision, 8 bits give you 0.4% which is "industrial" by many standards.
Precision always refer to the whole scale, if you are interested in a limited range only, like 3.5-4.2V / cell, then use a reference voltage and measure the difference with an OP-AMP. Wondering where you will easily find resistor more precise than 1% to use for the op-amp gain

Originally Posted by RENATOA

No need for such precision, 8 bits give you 0.4% which is "industrial" by many standards.
Precision always refer to the whole scale, if you are interested in a limited range only, like 3.5-4.2V / cell, then use a reference voltage and measure the difference with an OP-AMP. Wondering where you will easily find resistor more precise than 1% to use for the op-amp gain

Fair comment, keep them coming.

I guess we could use the 10bit PIC's if high resolution is needed for current shunts etc, with serial output.

I used some MAX6675 thermocouple chips long ago on another project, those chips digitize K-type probes to SPI output, so it would be a cinch to read via a PIC at the remote end and serial the data out at 4800b. Cylinder head temperatures etc ?

I'm not sure what to do next. Make an LCD display for the inbuilt measurements, or see how the host end programming is done.
The latter is more useful to me, as I could fly the system in my 500 size heli and get the inbuilt FrSky telemetry to warn me when the flight pack is low. But I need to change the Host end set points too...

Originally Posted by RENATOA

Here you are...
Obviously, tests were minimal, not owning the hardware.

Hey great going.
I missed the post earlier. I'll see how it goes.
Martin

Martin, I'd deliberately not posted the Frsky docs because mine are watermarked 'confidential', I wonder, did you check with Frsky that its ok to post them?
Phil

Originally Posted by PLMS

Third note.
There is a bit of a potential issue with the FF FE header at the local end (and others I guess). Because the AD1 and AD2 range includes FF it's possible to have those two bytes containing FF FE as valid AD voltages. That becomes a problem if you are parsing the incoming frames by looking for the header of FF FE... It's possible you will get data corruption became your serial routine just happens to capture the data from byte three and four (starting at 1, not 0) and thinks this is the start of the frame, not the real one in the first and second bytes.

So anybody got an idea on a simple way to avoid the remote possibility of corruption if the AD1 & AD2 data just happens to be FF FE, please post the thought here ?

Martin, we can parsing the frames by FE F*, in conjunction with a counter.

Originally Posted by phil_g

Martin, I'd deliberately not posted the Frsky docs because mine are watermarked 'confidential', I wonder, did you check with Frsky that its ok to post them?
Phil

Hi Phil_g,

Martin had got our pernit to post this docs few days ago, we just plan to open this docs of 2-way system at that time. Currently everyone can download this documents from our website. We are gathering idea from some one genius at this area like you guys(such as Bruce, Martin etc...) Really Thank you all.

Meantime, we hereby would like to public, we will release our finished 2-way system, DIY module on March, our distributors are accepting pre-order.

Thanks for your always attention.

Have a nice day
Chase Wu

Hello,

Welcome to download the software for our 2-way system from our website.

This software's interface with note as below,



We also could offer Source Code of this software if you need

Originally Posted by Chase Wu

Hello,

Welcome to download the software for our 2-way system from our website.

Here's the link to the software
http://www.frsky-rc.com/download/fdd...al-version.rar

I made a quick video of it working on my set of Two-way system. Not the RS232 yet, just the inbuilt telemetry readings. Will post it up soonish.
Martin

Pictures work better than words, video even better (usually) so here they are.

The first shows the two AD channels and alarms in action.
The second shows the signal quality channel working and the error alarm.

The data is coming straight out of the FrSky TX modules serial port. The alarm beeps are generated by the modules own alarm settings. The RX again has a couple of trim pots fitted to the two analogue channels to show them working.

Can somebody who has been sent these test units please try the software monitor while reading say an NMEA GPS plugged into the receiver serial input.
I can, but not for a few days or so :-)

FrSky software monitor program (2 min 25 sec)

FrSky monitor program part 2 (1 min 23 sec)

Originally Posted by Chase Wu

We also could offer Source Code of this software if you need

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

So anybody got an idea on a simple way to avoid the remote possibility of corruption if the AD1 & AD2 data just happens to be FF FE, please post the thought here ?

The solution is to use a stateful parser. Since the frames are known to be fixed size, the parser can use that extra information to ensure it has the framing right. Something like this:

Stateful framing algorithm for FrSky telemetry byte-stream
==========================================================
kgfly, 06 Mar 2010

Frames (fixed length = 10 octets):
  FF FE xx xx xx xx xx xx xx xx  (where xx might include FE and FF)

Concept:
  Wait for receipt of two valid sequential frames before entering
  the Synchronised state. Maintain synch by checking for the FF FE 
  pattern at the expected octet position in every subsequent frame
  by keeping count of received octets.

Variables:
  State      (initialise to Idle)
  ByteCount  (initialise to 0)


State table:
  The state machine is driven by the arrival of a frame octet.

------------	-------------		------------------------
State		Event			Next state (action)
------------	-------------		------------------------
Idle		Rx != FF		Idle   (ByteCount = 0)
		Rx == FF		HdrA2  (ByteCount = 1)
------------	-------------		------------------------
HdrA2		Rx != FE		Idle   (ByteCount = 0)
		Rx == FE		BodyA  (ByteCount = 2)
------------	-------------		------------------------
BodyA		ByteCount < 9		BodyA  (ByteCount += 1)
		ByteCount == 9		HdrB1  (ByteCount = 0)
------------	-------------		------------------------
HdrB1		Rx != FF		Idle   (ByteCount = 0)
		Rx == FF		HdrB2  (ByteCount = 1)
------------	-------------		------------------------
HdrB2		Rx != FE		Idle   (ByteCount = 0)
		Rx == FE		BodyB  (ByteCount = 2)
------------	-------------		------------------------
BodyB		ByteCount < 9		BodyB  (ByteCount += 1)
		ByteCount == 9		Sync1  (ByteCount = 0)
------------	-------------		------------------------
Sync1		Rx != FF		Idle   (ByteCount = 0)
		Rx == FF		Sync2  (ByteCount = 1)
------------	-------------		------------------------
Sync2		Rx != FE		Idle   (ByteCount = 0)
		Rx == FE		Sync3  (ByteCount = 2)
------------	-------------		------------------------
Sync3		ByteCount < 9		Sync3  (ByteCount += 1)
		ByteCount == 9		Sync1  (ByteCount = 0)
					       (Process valid frame)
------------	-------------		------------------------

There is a weakness with the above algortihm if the frame data is not changing. In the case where the sequence "FF FE" appears in the frame payload and is not changing it is possible to achieve a false lock that is offset into the frame payload. I cannot see a way to avoid this unless more behaviour is defined for the frame format.

Isn't the NMEA GPS data coming mixed with ADC data in the same stream ?
How can you maintain this sync in this case ?