SSC03A unable to control :(


I am trying to talk to a SSC03A micro serial servo controller, from an AVR uC.
I have tried using my code, ruby’s array.pack, and also the pololu serial transmitter using Mono (through the usbavr in a straight USB-Serial mode from LUFA) all without success.
Whenever I send any command, the servo controller flashes its red light forever, and keeps the yellow one on.
The datasheet leaves me none the wiser as to the meaning of that, other than it is some kind of error.

Monitoring the serial output line, I get 0x80 back when this happens, but again the datasheet fails to explain any of the serial response codes.

An example command I am trying to send (jumper off - pololu mode) is
0x80 (start), 0x01 (device ID 1), 0x00 (set config), 0x01 (servo id), 0x4f (turn on this servo, leave other settings at defaults)

In the Mini SSC II mode, If I send something like 0xFF,0x01,0xAA then a servo twitches initially, but then I get the same error condition and no more response until I reset it.

I have tried both serial inputs. The inverted one gives me a baud rate error as I would expect, as it doesn’t see it’s 0x80 start byte.

I am running Linux, but I don’t see why that should be a problem. I have the serial port set up at 9600 baud, 8 bits no parity, no flow control etc. Plus the official app seems to work under mono, i.e. it does send data to the serial port.

Any ideas?

Ok, it’s not dead at least. It works using the pololu program under mono, when connected directly to my PC’s UART (via the RS232 input).
Still don’t know why it doesn’t like the usbavr though…

Still not working with th AVR…
It has occurred to me that the datasheet for this does specify 5V as the logic level, although the datasheet for the PIC on which it is based says it should be happy with 3.3V as a logic high.
Does anyone know if 3.3V logic is a problem with the SSC?


The 3.3V levels could be the problem, though I doubt it. You should be able to verify that relatively easily by buffering your 3.3V signal to 5V and seeing if the results change. Usually, the problem is that the serial data is not what you think it is. Can you look at what you are sending with an oscilloscope?

- Jan