transceiver servo control

bnikkel

Hi everyone, So i have a 2.4ghz controller ive built. basically one prop sends through a transceiver to another transceiver then into a second prop and finally to a bunch of servos. im wondering if there is anyway to get rid of the second prop and have the transceiver connected directly to the servo? i can change the baud rate on the transceiver (currently at 9600) any thoughts or ideas about this would be appreciated.

Phil Pilgrim (PhiPi)

Instead of sending serial data, you could send a stream of servo pulses, which any 2.4GHz RC receiver could demultiplex.

-Phil

bnikkel

i ran a simple ide servo program that directly controls a servo and put two transceivers between the data line, both transceivers showed sending and receiving information but the servo only stuttered. i was thinking maybe i need something between the receiving transceiver and the servo?

Phil Pilgrim (PhiPi)

If the servo is designed to respond to 1-2ms servo pulses, but you're sending it 9600-baud serial data instead, yes, it will stutter. Do your transceivers require sending serial data, or will they work with any pulse pattern?

-Phil

bnikkel

im using the hs-lc12s transceiver, its uart and i believe they do require sending serial data.

Phil Pilgrim (PhiPi)

Can you set the baudrate to anything, or do you have a fixed list of permissible settings?

-Phil

bnikkel

its a fixed list 600, 1200, 2400, 4800, 9600, 19200, 38400

Phil Pilgrim (PhiPi)

In that case, you will need either a micro on the receiving end or serial-bus servos.

-Phil

Wingineer19

If I downloaded the correct manual, it looks like the radio will support the following baud rates:

600, 1200, 2400, 4800, 9600, 19200, 38400 and selectable via an AT command.

Unfortunately the radio doesn't support hardware handshaking, otherwise you could have tried bitbanging the RTS or DTR lines to get the pulse stream on the other end as Phil mentioned.

Have you tried Phil's suggestion and used a different baud rate?

You've established that 9600 doesn't work. Give the others a try just to see what happens.

The manual is unclear but I assume that it only supports 8 data bits, no parity, and one stop bit.

If it lets you change at least the data bit size and parity, you could try experimenting with those as well.

But the key is what type of serial or bit stream does your particular servo expect? Can you post any info on that? From there it could be determined if the UART approach will even work under any settings.

kwinn

In theory you could add a small capacitor to the receiving end as a low pass filter and send specific data bytes at a high baud rate to simulate servo pulses. That would work for a single servo. For controlling multiple servos over an RF link serial data and a micro at the receiving end is the way to go. Even sending actual pulses rather than ascii commands would be difficult.

Phil Pilgrim (PhiPi)

kwinn wrote:

In theory you could add a small capacitor to the receiving end as a low pass filter and send specific data bytes at a high baud rate to simulate servo pulses. That would work for a single servo.

That's an intriguing thought! Putting the filter ahead of a Schmitt-triggered inverter would be the thing to do, since you want a normal-low input to the servo. But by the time you get done calibrating everything, you could've just used a micro instead. Parallax's FLiP module is small, inexpensive, and drop-dead easy to integrate into a project such as this.

-Phil

kwinn

I have not tried this with high baud rates, but did find that it could be done at 2400 baud, but there were only a few speeds available. IIRC the limitation was due to the speed at which the 8080 could reload the data to the uart chip. Used the idea for testing servos with an 8080.

bnikkel

I am wanting to control gates, track switches, and some animated scenery on a train layout, 30 plus servos. with the price of the transceiver being around $2 and not having to run anything but power this would be ideal. one transceiver per servo. my trains and some cars are already radio control. I will try the capacitor idea and different baud rates.

bnikkel

so i have gotten a lot of movement but most of it is erratic and unreliable.

Phil Pilgrim (PhiPi)

What data are you sending to the servos? What you need to do is simulate a servo pulse by modulating the serial data and transmission time. You can't just send the kind of data you've been sending. Also, unless you've included a Schmitt-triggered inverter (e.g. 74HCT14) after the filter, it will not work.

Do you understand what a serial data transmission looks like, for example, on an oscilloscope screen?

IOW, a scattershot approach will not work here. You have to do the math and figure out which data sequences are going to translate into the pulse widths you need after they've been filtered.

-Phil

Phil Pilgrim (PhiPi)

Here's an experiment I did to convert serial data to a programmable pulse. I hooked up this circuit, which was driven by a Propeller chip:



I used this program to drive it:

CON

  _clkmode      = xtal1 + pll16x
  _xinfreq      = 5_000_000

OBJ

  ser:  "FullDuplexSerial"

PUB start

  ser.start(1, 0, 0, 38400)
  repeat
    ser.tx($00)
    ser.tx($00)
    ser.tx($00)
    ser.tx($51)
    waitcnt(cnt + clkfreq / 50) 

Here is the output I got on my scope:



The yellow trace is the serial output from the Propeller chip; the cyan trace, the filtered output that's input to the Schmitt inverter; the magenta trace, the output from the inverter, which could be fed to a servo.

Note the modulation near the end of the serial data. This is done to finesse the position of the inverter's falling edge. You will have to experiment with different data values to determine how each affects the timing and build a table that relates desired pulse widths to to the data sent.

But here's the rub: you have to repeat this sequence every 20 ms for each servo. There is not enough time in 20 ms to address and pulse 30 servos with one transmitter. You could use multiple transmitters, but that starts to get pretty unwieldy. It would be much better to have a micro at each receiver that continuously pulses each servo based upon the serial data it receives.

I consider what I've shown above to be no more than an academic exercise and of little value for your application.

Go with the receive micros!

-Phil

kwinn

I agree 100% with what Phil says. There is no way to control more than one servo with this method. This basically comes down to 3 possible choices:

1 - use a single receiver and a propeller that has one pin wired to each servo
2 - use 30 small cheap micros and wire the receiver data line to all the micros
3 - use X receivers and Y micros to control Y groups of servos

Number 1 would be the most economical and simplest way. There is software to control 32 servos in the OBEX to get things started.

bnikkel

thank you Phil Pilgrim for the info. i dont have a scope but i will see what i can do with the info you've showed me, im sure it will prove very difficult doing it blind without a scope haha. i am hoping to have one receiving transceiver control only one servo, say open/close a gate and then not receive any pulses. the servos wont have any resistance applied to them after they have moved so they wont have to constantly try and hold their position. the transceivers have over 100 channels and are network capable so i can change the transmitting side to talk to the desired receiving servo.