Maximum Rate for servo demands

Lynxmotion Electronics & Software
1

I’m trying to use the lynxmotion to operate four servos with commands being sent at 50Hz (every 20ms).

I’ve noticed that the lynxmotion seems to be buffering the demands, so the code stops running but the servos keep moving for several seconds.

So I have two questions - 1: Can the buffer be disabled? 2: what’s the maximum rate I can send demands?

2

Hello @jimbomenzingo !

Welcome to the forum! What lynxmotion product are you using?

1 Like
3

lynx motion ssc32u. In the end I upped the baud rate and got the commands going out fast enough. I’d still be interested to know more about the buffer. In this application I do not want the servos to remember any demands, only to respond to what I last sent them.

1 Like
5

Hi,

I’m glad to hear you solved the problem. I couldn’t tell you, what do you think about this @scharette ?

1 Like
6

Hey @jimbomenzingo,

Welcome to the RobotShop community!

Two important points here:

  1. Most if not nearly all RC servomotors go limp if they do not continuously receive a RC PWM signal indicating a valid position, typically @ 50 Hz (but there’s some leeway there).
  2. The SSC-32U has all channels outputting P0 by default (effectively a digital “low”). If you send a P command for a channel (ex: #15P1500), that channel (#15) will now output a 1500 µs pulse @ ~50 Hz forever unless told to do otherwise (or the board is power cycled, powered off, etc.).

With that in mind, I did some quick tests with my SSC-32U and my logic analyzer (love that thing! so helpful for embedded development), monitoring the TX/RX pins and channel #15. I did ~10 tests @ 9600 and @ 115200 baud rates, in both cases measuring the transition time between a P0 or P65535 signal and the last character of the command ( \r ).

I expected to get a delay between the command been received and the output changing of about 20 ms (or 1 iteration of the 32 channels being updated with a rate of 50 Hz / period of 20 ms). Here are the results I obtained from my tests:

@9600 baud rate I noticed signal change withing ~16-24 ms, which is about what I expected. See below:

image
image1391×1076 34 KB

@115200 baud rate I obtained similar results, but they were much closer to 20 ms (± 0.3).
This is most likely due to the processing time required for lower baud rates. @ 9600 a character is about 1.0416 ms long whereas @ 115200 characters are about 12 times shorter!

Therefore, the SSC-32U seem to do the very bare-bone minimum buffering required to transfer your requested signal from UART to the proper channel. It wouldn’t be realistic to expect the update to be faster than the rate of the signal (50 Hz, period of 20 ms).

Also, from previous tests, we know the SSC-32U’s outputs are ±1 µs of accuracy, which is pretty good considering it is generating 32 simultaneously while doing all the other stuff it can do, too.

Let me know if you have any other questions.

Sincerely,

1 Like