Special custom commands over PCM

I understand that there may be receiver/transmitter pairs available which would allow a user to send custom command information to the receiver. Conceivably a small microprocessor onboard the aircraft would be able to decipher these commands and carry out special functions (turn on/off lights, landing gears up/down, trigger small digital cameras, deploy parachutes, etc.) Can anyone give me a lead on where I might find these devices? BTW I am and electronics guy and not an R/C pilot (at least not yet). Thanx.

Reply to
PogoStik
Loading thread data ...

| I understand that there may be receiver/transmitter pairs available | which would allow a user to send custom command information to the | receiver. Conceivably a small microprocessor onboard the aircraft would | be able to decipher these commands and carry out special functions | (turn on/off lights, landing gears up/down, trigger small digital | cameras, deploy parachutes, etc.) Can anyone give me a lead on where I | might find these devices? BTW I am and electronics guy and not an R/C | pilot (at least not yet). Thanx.

PCM is just a protocol between the TX and RX -- your devices will never see it. PPM is another (simpler) protocol that can be used instead. PCM is proprietary, and different for every vendor.

Your device will plug into a servo plug in most cases, and what it will see is a series of pulses that last between 1.0 and 2.0 ms. The length of these pulses corresponds to the position that the servo is supposed to move to -- 1.5 ms is the middle, and 1.0 ms is one extreme and 2.0 ms is the other extreme.

You certainly can decode this with a PIC or similar controller. For example, here --

formatting link
is a page that reads this signal and decodes it with a PIC to determine when to turn on a camera.

I suspect that you might have been wanting to send more complicated commands than what is basically a analog signal 50 times per second, but this is what you get unless make modifications to the TX and start making big changes.

Other possibly useful links include :

formatting link
formatting link
formatting link

Reply to
Doug McLaren

Doug, Thanks for the URL leads on what is available. You guessed it in your last paragraph. I am looking for a way to possibly "piggyback" (or modulate) a subchannel onto an existing RC channel... ideally with minimum modifications to both the receiver and transmitter. An alternative might be to just develop a receiver/transmitter pair on a separate public use RF band, sort of a separate telemetry channel. Still thinking further out of the box, making the channel two way would allow commands to be sent and results to be transmitted back.

Doug McLaren wrote:

Reply to
PogoStik

| Thanks for the URL leads on what is available. You guessed it in your | last paragraph. I am looking for a way to possibly "piggyback" (or | modulate) a subchannel onto an existing RC channel... ideally with | minimum modifications to both the receiver and transmitter. An | alternative might be to just develop a receiver/transmitter pair on a | separate public use RF band, sort of a separate telemetry channel. | Still thinking further out of the box, making the channel two way would | allow commands to be sent and results to be transmitted back.

Well, the list of things you described can all be done with the sort of thing I described and no changes made to your TX at all. The only limitation is that you'd have to use one channel for each item or each two items.

For example, if you have a three position switch, that will send a signal of either 1.0 ms, 1.5 ms or 2.0 ms. So you can have 1.5 ms do nothing, 1.0 ms toggle the lights and 2.0 ms take a picture. Or if you have a two position switch, 1.0 ms = lights on, 2.0 ms = lights off. Landing gears are often done with retract servos that are all or nothing -- they're not porportional at all.

You could also do this on an unused stick -- middle do nothing, up do one thing, down do another way.

With a few channels dedicated to this, you could do all the things you've described. But yes, it sounds like what you want might be easiest done with a completely seperate RF link. Do take lots of care to make sure any TX in your plane doesn't desense the 72 MHz RX!

| > | I understand that there may be receiver/transmitter pairs available | > | which would allow a user to send custom command information to the | > | receiver. Conceivably a small microprocessor onboard the aircraft would | > | be able to decipher these commands and carry out special functions | > | (turn on/off lights, landing gears up/down, trigger small digital | > | cameras, deploy parachutes, etc.)

Reply to
Doug McLaren

What is described here is available on the market (at least here in Europe) as an add-on to existing radio systems, and can also quite easily be built yourself if you are an electronics designer. What it basically does is multiplex various additional channels over one Tx channel by adding a simple multiplexer on the Tx side, and a demultiplexer that can be connected to a regular servo connector on the Rx. All leading european RC brands offer it.For more info refer to their websites.

Multiplex for example sells the 'multinaut' extension system for their RC systems. Robbe sells the same concept for their range of (Futaba make) RC sets: the 'Multi Prop Modul'.

Graupner offers it for their range of (JR make) RC sets: 'Nautic Multi Prop/Schalt Modul'.

Reply to
Bram

Thanks, Bram for your reply. I now see how it is done. The solution would require a transmitter mod, but it looks like the receiver end could be a plug breakout box type of device.

Is spread spectrum radio be> >I understand that there may be receiver/transmitter pairs available

Reply to
PogoStik

Where I live spread spectrum (2.4 GHz) radio is used for model car racing. Since a few months Graupner markets a 4 channel aircraft set targeted at the indoor RC aircraft market. The set features a dual receiver (i.e. two antennas & RF stages) for increased reliability of the transmission. For outdoor RC aircraft the range seems to be too limited.

Reply to
Bram

You should be able to encode a fairly large number of functions onto a single channel with a PIC on each end. You should easily be able to transmit and receive 16 different pulse widths, allowing for 4-bits to be encoded in each pulse. You could reserve one bit to make the beginning of a block, and one bit to alternate between high and low (so the receiver will know when the data has changed) and pass two bits of data in each framed chunk.

For example, if you want 6 on-off switches, you can simply send this block:

1 0 S1 S2 0 1 S3 S4 0 0 S5 S6

Notice how the first bit is set on the first block. That allows you to identify the first block. Notice how the second bit alternates. That allows you to know when you have a new block (otherwise you might not know of there are two blocks with the same value or one block with that value). The last two bits hold the data.

Each combination of 4 bits would be encoded as one of 16 pulse widths.

If you just need to send changes, you can reduce the latency with a protocol that consists of so many bits of data to indicate which control has changed and so many bits to indicate the new position. You can encode the beginning of the block and when there's new data the same way.

How much data do you need to send? How many signals and how many values for each signal? I can whip up an encoding scheme for you very easily.

You should try to confirm two things. First, what is the update rate with your receiver and transmitter? That is, how many pulses per second does it send (minimum and maximum, it may vary based on the input). Next, what is the resolution of your receiver. That is, how many distinct pulse widths can it reliably send? I believe most modern transmitters and receivers can handle at least 32 positions, so you should be able to get 16 reliably (with safety windows around each valid position to detect an invalid signal).

DS

Reply to
JoelKatz

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.