SMALL - espritmodel.com SMALL - Telemetry SMALL - Radio
Reply
Thread Tools
Old Feb 28, 2010, 02:13 AM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,686 Posts
AD inputs

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 ?
PLMS is offline Find More Posts by PLMS
Reply With Quote
Sign up now
to remove ads between posts
Old Feb 28, 2010, 02:30 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
14,960 Posts
Quote:
Originally Posted by PLMS View Post
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.
renatoa is offline Find More Posts by renatoa
Reply With Quote
Old Feb 28, 2010, 02:36 AM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,686 Posts
A/D resolution

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
PLMS is offline Find More Posts by PLMS
Reply With Quote
Old Feb 28, 2010, 02:40 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
14,960 Posts
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
renatoa is offline Find More Posts by renatoa
Reply With Quote
Old Feb 28, 2010, 03:13 AM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,686 Posts
Quote:
Originally Posted by RENATOA View Post
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...
PLMS is offline Find More Posts by PLMS
Reply With Quote
Old Feb 28, 2010, 03:20 AM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,686 Posts
Quote:
Originally Posted by RENATOA View Post
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
PLMS is offline Find More Posts by PLMS
Reply With Quote
Old Feb 28, 2010, 06:57 PM
Who let the dogs out?
phil_g's Avatar
Pontefract, Yorkshire, UK
Joined Jul 2007
1,086 Posts
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
phil_g is online now Find More Posts by phil_g
Reply With Quote
Old Feb 28, 2010, 07:10 PM
Registered User
Joined Oct 2009
29 Posts
Quote:
Originally Posted by PLMS View Post
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.
RobertWing is offline Find More Posts by RobertWing
Reply With Quote
Old Mar 01, 2010, 12:31 AM
Registered User
Joined Mar 2009
297 Posts
Quote:
Originally Posted by phil_g View Post
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
Chase Wu is offline Find More Posts by Chase Wu
Reply With Quote
Old Mar 01, 2010, 01:36 AM
Registered User
Joined Mar 2009
297 Posts
Hello,

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

This software's interface with note as below,

Name: Frsky 2 way.jpg
Views: 1225
Size: 62.7 KB
Description:

We also could offer Source Code of this software if you need
Chase Wu is offline Find More Posts by Chase Wu
Last edited by Chase Wu; Mar 01, 2010 at 01:49 AM.
Reply With Quote
Old Mar 01, 2010, 03:42 AM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,686 Posts
Quote:
Originally Posted by Chase Wu View Post
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
PLMS is offline Find More Posts by PLMS
Reply With Quote
Old Mar 01, 2010, 06:42 AM
Martin - AKA mr.sneezy
PLMS's Avatar
Adelaide, Australia
Joined May 2004
1,686 Posts
Video of the monitor software app

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)
PLMS is offline Find More Posts by PLMS
Last edited by PLMS; Mar 01, 2010 at 06:48 AM.
Reply With Quote
Old Mar 06, 2010, 05:32 AM
Registered User
MGeo's Avatar
New York
Joined Nov 2003
509 Posts
Quote:
Originally Posted by Chase Wu View Post
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
MGeo is offline Find More Posts by MGeo
Last edited by MGeo; Mar 06, 2010 at 01:12 PM.
Reply With Quote
Old Mar 06, 2010, 09:25 AM
Registered User
Melbourne, Australia
Joined May 2006
6,407 Posts
Quote:
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:
Code:
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.
kgfly is online now Find More Posts by kgfly
Last edited by kgfly; Mar 06, 2010 at 04:08 PM.
Reply With Quote
Old Mar 06, 2010, 10:00 AM
Registered User
Romania, Dolj, Craiova
Joined Sep 2007
14,960 Posts
Isn't the NMEA GPS data coming mixed with ADC data in the same stream ?
How can you maintain this sync in this case ?
renatoa is offline Find More Posts by renatoa
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 12913 Today 04:21 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