how to send serial data along 1 channel

[loco_g]

Hi, i bought a 3 channel electric aeroplane half a year ago,
it had 2 proportional channels and a on/off switch for the motor, i got curious and took it all apart, found out it had a speed controller so i replaced the switch with a potentiometer so i got speed control.

now that i learned how to fly i want to use PIC chip or any micro to send serial data along that 3rd channel to control more things.

Would anyone know how to send serial bits along a single channel and how fast the bit rate could be? could 2400 baud be sent? what should i expect.. how could i encode and decode, only one way from radio to rx.

thanks.

[Ron van Sommeren]

"baud" is not bit rate. Baud is the numer of level changes per second. Say you have 4 levels/voltages, the bitrate will be twice as high as the Baud rate. For two levels (binary) the numbers are the same.

Groeten ;-) Ron

[Mr.RC-CAM]

If you were to take the output from the Rx's decoder chip (at the servo connector), then the best you would get is about 50 baud (bitrate). If you were to attempt to modulate the Tx's third channel at a faster rate, and demodulate before the Rx's decoder, then the limitations would depend on other factors outside your control. The performance would have to be determined by experimentation.

RC-CAM

[jperch]

Several years ago, RC Modeler had an article on how to build a circuit that would multiplex several channels onto a single Tx channel. The article included a way to demultiplex these signals at the receiver end. As I recall, it was pretty complicated. However, you could use this same method with your own scheme to multiplex several things onto that thrid channel. The major drawback is that this channel still only updates about 50 times per second. You would have to divide this rate by the number of items multiplexed onto the channel to get the update rate of each individual channel. Because of this, you would not want to use a multiplexed command for a flight control since the update rate would be too slow. But, it would be fine for things like gear doors, landing gear, maybe flaps.

Just an idea,
Joe

[loco_g]

hmm, thanks for the advice.. i suppose i will stick to 50Hz because its the easiest.
i found a link that uses a pic to control 8 servos through serial interface
it has a {channel|command} byte followed by {servo position} byte and optional digital output for switchng things through the command nibble.
http://www.digitalnemesis.com/ash/projects/picservo/default.htm

it could be updated 3 times a second if the bits were sent at 50Hz right?

[Mr.RC-CAM]

If you assigned one bit to each channel 3 servo frame, then you would get 2.5 updates per second (that includes start/stop bits). This assumes the PIC code was hacked to support your implementation (the linked PIC project is based on a common 2400 baud RS-232 format).

RC-CAM

[loco_g]

yes, after some thought i have an idea about the speed of refresh.
write some code for the tx pic to switch certain resistors into channel 3 instead of a pot, it would be like digital to analog conversion but it would be transmitted as different pulse widths, so i could compress however many bits into one frame and based on how wide the pulse is, measure it with the rx pic instead of rs-232 and extract the bit pattern, 2 to 4 bits could be reliably converted causing 4 to 16 possible pulse widths from minimum to maximum, that would speed up refresh rates 2-4 times depending on how many diferent pulse widths can be accurately converted back to a digital bit pattern, i hope u know what i mean, ive got a little bit of experience in writing progs for pics and motorola micros, it shouldnt be too hard

[deh6]

I've thought about multiplexing a channel, too. It is certainly feasible.

1. Synchronizing at the xmitter

Do you have a scheme in mind as far as synchonizing to the xmitter pulse/train, i.e. the reset pulse, at the xmitter (so that the micro at the xmitter knows when to step to the next bit(s))?

One way that minimizes hacking into the xmitter is to use a rcvr that picks up the xmitter. One of the rcvr channels feeds into the micro, etc. The only mod on the xmitter would be to run wires from, say the landing gear switch, to the "serial sender." For single bit per frame sending, the micro only needs to open/close with a fet, transistor, etc. A simple tuned circuit, diode detector, and wire close to the xmit antenna might be sufficient for the rcv function.

Obviously it would be cheaper to dig into the xmitter and find something that gives sync info--I don't know if it is even available on the newer xmitters.

Still another scheme worthy of investigation is to step the serial bits out to the xmitter at a rate slightly faster, or slower, than the xmit frame rate, i.e. 50 Hz, and at the rcv get periodic errors (which can be rejected if error checking is included), e.g. every second a bit would be in error (either skipped, or duplicated, depending on whether the rate is faster, or slower, than xmit rate). This method would eliminate the need to get sync info from the xmitter.

2. Bit rate

As far as getting more bits per pulse, discriminating 16 pulse widths sounds about the limit. I don't have a feel for what the rcv'd pulse train looks like when the plane is getting near the range limit. One gets a sense of this by the chatter of the servos in the usual range check.

One could also use more of the unused channels. It is my understanding that the chip used at the xmitter is based on a 8 pulse frame (with one used for reset?), which means that 3 channel rigs have 4 unused pulsed positions. This may not be true for the newer computer controlled xmitters since they can do it software.

3. Byte & Frame sync

There needs to be a scheme for determining which bit in the serial stream is the start-of-byte (or whatever grouping you choose), and which byte is the start-of-frame if more than one byte, or group, is sent. The HDLC scheme is well suited for this and used in amateur radio packet (http://www.tapr.org probably should have some info on it).

4. What is the need?

Could you share with us some of your ideas as to how the serial data stream might be used?

I've thought about the "uplink data channel" as a means for doing in-flight experiments, such as CG shifting, as well has providing a nearly endless number of low-speed on/off channels.

Error checking can be included in the scheme. I don't know how useful it would be to have some airplane ID code in the stream, but with it one could reject and do "something" (e.g. shut down the engine? Deploy a chute?...) when a signal other than your xmitter is rcvd. (I believe FMA has a rcvr that takes a "signature" of the pulse widths, polarities, etc., and uses that to verify the correct xmit signal is rcv'd.)

A lot of interesting possiblities.

Don

[deh6]

Additional item:

Refresh rate

There two kinds of refresh--servo and data. The servos are driven by the PIC and can be refreshed at any rate you choose since that is controlled by the PIC software. (Since they are designed for 50 Hz, use 50 hz.) The rcv'd data is updated at the rate determined by rcv'd rate, which of course is slower.

I did some experiments with a Futaba S3003. Generally speaking the refresh rate was a secondary effect on the response speed. 50 Hz gave the best response, somewhat to my surprise. (Also surprising was that the servo response was virtually bang-on to spec, contrary to what I've seen reported.)

Don

[loco_g]

the main purpose is i really want to add more functionality wihout the cost of a new unit, like camera switch on and off and pan and tilt and a few other experimental things, i got a really nice tiny 2.4ghz tx and rx that transmits video and stereo audio but its only 100m range and a little b&w cmos camera the size of a sugar cube just waiting to be used for this, i like the idea of sending in digital because to me it is far more useful for tinkering in the future

the reset and resync could just be one frame of a certain width that is different to the other 16 widths, every second or whatever.

as for sync with the micro to the tx frames i dont know of any good way to do that
and as i imagine it the refresh is limited by the speed of information to the rx pic and from that to the servo it just repeats what it last got at 50Hz

[deh6]

The idea to use a "17th width" pulse for frame sync is a good idea. It should be as wide as possible so that the chance that noise that extends the 16th width pulse is less likely to be counted as a beginning-of-frame pulse.

Since the idea is a lot of slow channels, you could send only the channel that has changed, doing this by sending a group of bits that has the channel number (e.g. 4 bits giving 16 channels) followed by the channel value (e.g. 10 bits) and maybe a couple bits for a checksum. Sixteen bits at 4 bits per xmitted pulse, plus a start bit would take 250ms, so you could update one channel (of 10 bits) 4 times per second. The micro at the xmitter would compare all of its inputs and and send updates only for those channels with "significant change" (for analog inputs it might require some software logic to take care of the case where the A/D converter is flipping back and forth on the LSB).

It certainly looks practical.

Don

[loco_g]

yeah, the only hitch is getting the tx pic sending frames in sync with the tx radio, to not do conversions in between frames or something, i wouldnt know where to look for any clues in my radio, it all goes to one chip with the part number sanded off.

if you know of any advice on that it would be really helpful.

[deh6]

1. Opps--I swapped Hz and ms on the prev post. Five pulses would take 5 x 20 ms = 100ms. Ten per second. That appears fast enough.

2. Xmit syncing

I'd be inclined to experiment with stepping the xmit PIC through the data at a rate slightly faster than the 20ms per xmitter frame, figuring that periodically the xmit PIC would step twice during one xmit frame, and sometimes step at the time the xmit "reads" the channel input. If the xmit PIC was 2% faster than the xmitter, then every 50 pulses the PIC would have drifted one pulse, so that every second one of the data frames would be in error.

The scheme would rely upon the check bits to reject the bad data (might want to include more check bits...). The big advantage is that it avoids digging into the xmitter to find sync pulse, or expense of adding a rcvr to pick it up off the air.

Since there are intentionally occassional errors some scheme of repeating the data is needed, e.g. one could send the data twice...lot's of ways to do it.

Don

[Mr.RC-CAM]

If you expect to use the existing Tx encoder to read the new control data at a particular channel timeslot, then the syncing will be more difficult than is mentioned in the ongoing dialog. The main 50Hz framerate is for a full pulse train of channel data.

But, you would need to sync to the start of when the encoder (NE5044 or MCU based) reads the input of the channel you are injecting the special data into. That creates sort of a sub-framerate that is governed by the number of encoded channels. You could just blast the data away, but if there are long data strings then it will not be efficient.

But, this is really not a big deal. Just connect a shift register to the encoder's output and treat it like a hard wired R/C Rx. On your three channel system, the first two channels' outputs can be used to indicate the sync'd state.

Keep in mind that the design is getting sufficiently difficult and perhaps an entirely new custom encoder is what would be best. That way you have more control over the critical timing and sub-letting a channel's timeslot will be in your full control.

RC-CAM

[deh6]

I checked the frame rate with a 'scope on my Futaba T6XAS xmitter and R127DF rcvr. On a scope the frame rate remains constant as the controls are moved, i.e. the pulse widths appear not to affect the overall frame duration. The relative position of the pulses do change as the controls change.

It's been awhile since I looked at the NE5044, but my recollection is that the frame duration is a function of the widths of the individual channel pulses. If so, then the scheme of clocking out bits without sync may not be so good, though one might be able to get around that with a error correcting coding scheme that handles dropped/duplicate bits (which adds more complexity to the software). Clearly picking up the sync simplifies things.

On my scope the frame duration was 18 ms. The difference from 20 ms could be calibration, but I'm left suspicious that the frame rate may vary +/- 10 pct or more between xmitters.

Futaba uses a BU4015B dual 4 bit shift register to clock out the pulses on the rcvr. There is also a BU4051B (8 ch analog mux) on the xmitter so I presume it is used to sequence the channels.

I did a little tracing of the rcvr circuit--slow going--on the board that holds the header (where the servos plug in) there is an 8 pin IC that doesn't have any readable numbers. It appears to take the signal from the rcvr board and come out with pulses that drive the shift register. Anyone know the IC make/number?

Another surprise--there is a 3 volt regulator that supplies the rcvr board and part of the unknown IC. There are a couple of 100mfd 10v electrolytics, so it looks like battery voltage above 10v is danger zone (the shift reg is rated for 18v).

Don

[loco_g]

this is gonna be harder than i thought :(

[Acetronics]

Just Have a look to E.P.E.
In 1998, there was someting called DIGISERV : 10 on/off switches with 1 Channel ...

Alain

[MartinFVS]

It shouldn’t be hard to find the pulse train between encoder and modulator in the TX to use to synchronise a PIC. Then use an 8 bit digital pot to replace a TX control.

So that’s only two chips at the TX end so far. Just connect switches and pots to the PIC for encoding.

Don’t Multiplex do something like this already call the MULTINAUT system. If we knew how it worked that would take care of the RX end.