Sending "data" over R/C Tx/Rx servo output

[Skimask]

Fly R/C model airplanes in my "spare" time.  Want to add a handful of lights/etc to one of my planes, maybe a pilot head that moves around.  Not nearly enough channels and I'm using a Futaba 8channel Tx/Rx.
Channel 7 & 8 are pot's on the Tx.  Thinking maybe I could hack into those, use a couple digital pot's driven by an external/hacked mcu & keypad or something, to replace the mechanical ones, to send "SPI" data to an mcu on the plane controlling whatever, albeit at a very slow data rate.

First thought was to use Ch7 as data, Ch8 as clock/enable, more like a one direction SPI interface.
Ch8 = 1000us (+/- a fudge factor for all numbers shown) = data line disable
Ch8 = 1500us = data line enable / clock low
Ch8 = 2000us = data line enable / clock high
Ch7 = < 1500us = data low
Ch7 = > 1500us = data high

If the Ch8 output is around 1000us, anything coming across Ch7 is ignored, byte counters reset, etc.
If Ch8 output is around 1500us or 2000us, the "clock" output would go low or high respectively, and clock in whatever "data" would be on Ch7.

Obviously you wouldn't be able to transmit very fast at all, maybe 50 bps at the very most assuming a servo update rate of 50Hz, probably more like 1/3 of whatever update is at the Rx output, just call it 16 bps for this thought-experiment.  That's 2 bytes per second.  Plenty of time/data to be turning on/off lights, moving non-critical stuff (like the pilot head I mentioned earlier), etc.

Anything...

[Psi]

SPI is a bad choice for a communications medium where bit loss is common. It will forever be getting out of sync.

I would recommend designing your own simple protocol that uses the analog aspect of the servo signal for a higher bitrate.
The higher you can get the bitrate the more error-checking and correcting you can build on top of it.

Perhaps divide the servo range into 64 levels (i think RC rx/tx are often 10bit, so 64 levels in a 1024 level system gives you plenty of room for analog-digital conversion errors)
Every clock tick you can send a number 0-63, so 6 bits. (Although 4 or 8bit per clock would be easier to code)


You can buy RC RX/TX with telemetry links if you don't want to build it yourself. It essentially does exactly what you want but internal to the RX/TX unit so much faster speed and it may have its own error checking, i cant remember.

[Skimask]

"SPI...(snip)...bad choice...(snip)...bit loss..."
At least I wasn't suggesting using this for flight control!
Ya, I realize this sort of R/C comm's would be dicey at best, hence the reason why it's only for lights and such.....nothing more than stupid little pet tricks to put on a plane and make it heavier.

Utilizing the analog aspect...to gain more bitrate...
Yep, that's in my thoughts as well, but later on after a "single-bit method" could be tested and found workable.

Telemetry - Yep, got a couple of those systems, and they're not all that expensive either, easy to set up, easy to use, etc.  Basically looking to reuse some of my older stuff without spending $$$ on newer stuff.

Still working on it...

[Psi]

It shouldn't be dicey if you keep the clock and bitrate low and have error cheking in the protocol. Should be quite reliable.

[Skimask]

meh..."dicey" is probably the wrong word for it then.
Haven't hacked in to my TX yet, but the hardware simulation I've got going is working pretty good.  One PIC providing what would be the 2 channels coming out of the Rx, another PIC doing the decoding work/etc.
Once I dig into the TX and hook up a digital pot in place of the knobs, I'll see just how much resolution and repeatable (repeatable being the key) results I can get at the RX's servo outputs, and therefore, figure out how many baud (as opposed to bps) I can shoot over RF.

[amyk]

How about regular async serial (like RS-232)? You're basically using FM, which should be enough for the bitrates you're aiming at.

[fcb]

yes, of course it will work.

1. Data rate - unless you have access to the transmit timing you will not be able to run at 50Hz update rate, you seem to have made an adjustment down to 16Hz to cope with this.

2. There may also be some sort of slew rate control on the inputs, so going from min. to max. quickly is unlikely.

3. You maybe able to come up with a coding system that gives you a much higher overall data rate, perhaps 256 levels per sample using the pwm on a microcontroller.

4. Probably worth looking into the sort of coding used in low bit rate radio comms, you could code each bit of data as a relative to the last, so perhaps start with key value of 50%, then for a one goto 51% or zero goto 49%. so 1110 would be 50,51,52,53,52 percent.

Fun project.

[Skimask]

1. Yep, that's what I was thinking.  I might change the bit in the middle of an update, and do it again next cycle, and miss a bit here and there.  Slowing it down to 16Hz (almost effectively 3x oversampling for lack of a better phrase) for the initial trials seems to have mitigated this at the RX end of things.

2.  Slew rate.  I didn't think of this, but it doesn't seem to be a problem...yet.  Still haven't hacked the TX yet, but that's a good thought.  Might be the case that the TX won't allow the output to go from 0% to 100% travel in the space of one cycle, or maybe at least it won't allow it on some channels (e.g. the main normal flight control channels).  I'll find out when I get there.

3/4.  All still in the works.  A number of different options once I get the TX hacked.  Lots of different things to try.

[fcb]

2.  Slew rate.  I didn't think of this, but it doesn't seem to be a problem...yet.  Still haven't hacked the TX yet, but that's a good thought.  Might be the case that the TX won't allow the output to go from 0% to 100% travel in the space of one cycle, or maybe at least it won't allow it on some channels (e.g. the main normal flight control channels).  I'll find out when I get there.

You won't need to go from 0-100% per bit.
The likelyhood is that the value is digitised to somewhere between 8 and 12 bits resolution in the controller each cycle.  Perhaps you'll only need 1-2% change, however in practice you'll probably go with the bigger difference if your just sending slow data.  Although I would be tempted to code with at least 5 levels - a start bit and a dibit.

[Psi]

With regard to massively reducing your data rate under the carriers date rate to improve the problem of occasional errors..
It's easy code-wise and better to send identical data multiple times at a faster clock rather (vs slowing the clock and sending it once).

With a crc/checksum in the packet you get free error correction because the Rx mcu only needs 1 packet to come through intact.

Obviously a full-on error correction system will get you better throughput than repeating packets but that's also much more complicated.

[Skimask]

Ya know, then again, it's not like I'll be switching a thousand LEDs on and off!...although that would be kinda cool to see an R/C plane doing double duty as an advertising machine with a big ol' LED matrix on the underside of the wings.

[fcb]

I wouldn't bother with error correction/protection/CRC/checksum's or anything like that.

The link is already encoded by the transmitter and if it starts getting corrupted to that extent you have other problems (out of control RC!), anyhow another packet will be along shortly...

Nice project to play with, let us know how you get on.

[Niklas]

I think some of the RC speed controllers are using some higher transfer speed protocol over the signal wire for setup and bootloader. One idea that is similar to yours is to use channel 7 and 8 as nibbles or complete bytes. You will have a sync edge and then measure the actual pulse length. Jitter could not be that bad otherwise the servos would also jitter and you could improve it even more with fixed bit length intervals on the sampling.

[Skimask]

Ok, the TX is an 8UAF...old school...analog...nothing digital about it except the 'programming' at the TX end.  Nothing digital about the receiver.  Nothing digital about the servos.  No bootloaders, no nibbles, no bytes, nothing, other than what I'm adding.  No error checking going from the TX to the RX, or from RX to TX.  Nothing.

[Niklas]

I did not say that you should implement a bootloader or anything like that. What I meant was that you could use the concept in some way. How about adding a digital pot in the transmitter instead of the mechanical pot on channel 7 and have a small micro to translate your data to the pot? On the receiver end you have more freedom to fit whatever you like to decode the data stream.
In at least one old Futaba receiver I had there was a CMOS 4017 IC (1 of 10 Johnson counter) to decode the pulse train out of the RF part into servo pulses. Each input pulse stepped the output to the next and the interval between the pulses set the servo pulse width. Bad reception could cause extra pulses and wrong servo pulse lengths.

[Skimask]

How about adding a digital pot in the transmitter instead of the mechanical pot on channel 7 and have a small micro to translate your data to the pot? On the receiver end you have more freedom to fit whatever you like to decode the data stream.

See post # 1

[Psi]

My rangelink RC receiver has a led which flashes every time it receives a valid packet. Even under ideal conditions you notice the occasional interruption to the regular flashing pattern, meaning a missing packet.

It has little to no effect on control of the model because the packet rate is many many times a second. If one packet is lost the servo position is just static until the next packet arrives a few milliseconds later.

But for sending text over a serial link this delay will cause errors unless your data rate is slow enough to not see the lag.

[Skimask]

Again, not sending flight control type data...
Lights, maybe a few non-flight control moving "thingies".
But ya, I get what you're saying.  And yes, the MCU that I'm going to hack into the TX will send all relevant data continuously.
So, let's say I'm sending a single byte,no checksums, no nothing, just 8 bits.  Assume I get 16 bps.  2 bytes per second (wicked fast eh?).
We'll just assume at the RX end, at the MCU doing the decoding, I have to get 2 bytes in a row that match before anything changes...nah, let's go with 3 in a row.
The first byte gets screwed up.  The 2nd, 3rd and 4th byte all match up...something changes.  Maybe a 2 second delay before something happens...and so on and so on.
Good enough for me.
Now, obviously, if I was dealing with flight controls, or landing gear or something, I'd whip up something quite a bit more robust.  I'm not.  Not gonna use up time on making it 100%.

[Psi]

yeah, If you're happy for things to trigger randomly.

[Skimask]

Well of course I won't be happy if things trigger randomly...  Point is if they do trigger on or off randomly, ain't nothing gonna get wrecked because of it.