i wanted to know if the ssc servo controllers are compatible with any microcontrollers. so, for instance, if i wanted to use the servo controller with my robot to sequence a set of movements, like an arm or claw movement, would there be a way to connect the servo controller to the existing microcontroller or would i have to buy an atom controller and turn my robot into a remote controlled version rather than an autonomous one?
thanks,
daniel skinner
Hey Daniel,
Welcome to the Lynxmotion forums!
The SSC-32 can be controlled by pretty much any microcontroller as long as it can send data via a serial port. Connect the Rx/Tx of the micro to the SSC and you should be able to communicate. I might be wrong as I haven’t worked with a SSC-32 in a year.
Cheers,
-robodude666
ok. thanks a lot. i was hoping i didnt have to change my whole robot setup because that would take forever… 
The SSC-32 is compatible with any microcontroller or computer that has can send ASCII text commands out a serial port. The SSC-32 has a standard DB9 female serial port connector.
You can use any language for any microcontroller or computer to make sequences with. The SEQ software only creates sequences compatible with the Basic Atom microcontroller (and maybe the Atom PRO) though. You would be on your own to make sequences for other languages, but it might be possible to do a certain amount of translation from the sequences generated by the SEQ software. It would be the same as translating code from any language to any other language. You could copy the SSC-32 commands direct, and maybe translate the algorithms from the SEQ sequences. You would have to convert all this into whatever langauge you program your chosen microcontroller in.
The easiest route would be to get an Atom chip and mini Atom Bot Board and use SEQ to generate your sequences directly for the microcontroller. In any case, your robot does not need to be just remote controlled. It can still be very much autonomous and react according to your programming.
My current robot, WALTER, runs with the Basic Atom at present, and the experience has been completely good, but it has outgrown the memory capacity. I have run very close to the limits of what I can stuff into the 16Kb memory of the Basic Atom, so will be moving to a much more powerful controller. If you decide to go with a Basic Atom, you might even find some of my code useful, since it is all mostly in subroutines.
8-Dale
Hi Daniel, Dale,
Dale’s got it right, any uP and language can be used. A little harder in ASM! If you already know another language (Pascal, ‘C’, Java or whatever), then you’ll find that the BASIC code generated for the Atom BASIC (Hexapod robot) by PowerPod is not that hard to understand and translate. That’s actually what I’m doing now, translating it to ‘C’ so that I can run it on my PIC uP.
The sequencer program generates sequences which are useful for animation displays. It also appears to be useful for developing canned routines like “Attack” and “Fly”. For moving an arm or legged robot, you’ll want to do IK (Inverse kinematics). “Introduction to Robotics” by John J. Craig is a place to start, or study the code generated for the hexapod (and other LM robots?).
Want to discuss it further?
Alan KM6VV
The replies are correct, but they skipped over a simple point. The SSC-32 does not require a serial port. It can be connected to most microcontrollers I/O pins using TTL serial data communication. You didn’t mention what you are currently using in your robot.
Hi Jim,
I beg to differ! It DOES require a serial port, just NOT the RS-232 level converters! The jumper block to allow either operation is a great idea, especially on a 'Bot!
The SSC-32 makes few responses, so a “receive” line need not be connected to the SSC-32.
SO IF your uP board has a similar provision, or you can tap off a raw TTL level serial line, then you can unplug the RS-232 converters on both ends, and save some power. Not recommended, of course if you have a considerable distance to transverse back to a PC (which typically has level converters anyway)!
Alan KM6VV
Naw, the basic stamps and basic atoms send commands to the SSC-32 using a bit banged serial port, not a true serial port. Yes I know the Atom Pro has real hardware serial ports…
Hi Jim,
Perhaps I misunderstood you the first time. The SSC-32 USES a serial port. It still must talk to a serial port, whether it is “bit-banged” or not.
I was surprised that the BASIC Stamp (16F876; is it?) didn’t just go ahead and use the hardware serial port. I suspect its hardware is dedicated to the serial control option (vs. PS2)? I’ve been tempted to bit-bang a “back channel” serial port so that I can dump (debug) commentary back to the PC when I’m working my way through the code. The alternative is seeing if I can send “comments”, and let the SSC32 see (and ignore) them. I use an “eavesdrop” cable in the XMIT line to the SSC32 (RS-232) so that a terminal program on my PC can view what the SSC32 sees.
EDIT:
The SSC-32 seems to ignore statements that DO NOT start with a ‘#’ sign, is that true? Or is there a defined way to “exclude” data from the SSC-32’s perusal?
If at all possible on a 'Bot controller, I’d go with hardware for the com port connection to an SSC32, and to the PS2 (SPI) as well. Much better (if you have it) to use the hardware, and reduce the overhead! But that’s just me.
But no arguments from me! The BASIC Atom / SSC32 IS obviously a very well working combination.
Alan KM6VV
My original reply was geared more to Linuxguys reply.
Where he inadvertently defines a serial port as a device with a standard DB9 connector. I should have said a true serial port is not required, and that bitbanged communication is possible by moving some jumpers. No harm no foul. 
Whats a serial port? 
I was thinking in terms of a PC serial port, and that was too narrow of a definition.
8-Dale
hi, i’m trying to use a hitachi ucontroller to send data to the ssc 32. from the above discussion, i figure i can do this is 2 ways - connecting the two with a true serial cable, or connecting the tx to rx and the gnds between the two. is that correct?
i’m using c to program the ucontroller but am unsure of how to program it to send serial data 
Hi, can u pl explain the ‘bit banging’ concept and how it is achieved for the basic stamp/atom? I want to use a simple i/o port of an h8/300h to achieve the same.
hope that u can help
cheers
“bit-bang” is a cute and fuzzy name for making a serial port using software and meeting the timing requirements by counting instructions cycles between edges of the output signal. the benefit is you can use just about any port pin for a serial port. the serin and serout commands on the basic atom are examples. a hardware serial port requires a hardware device within the micro and is normally only available on a few select port pins.
for example, 9600 baud rate is 9600 bits per second. this means each bit is 1/9600 = 104.6 uS in duration. If you have a 1 MHz instruction rate (usually your crystal frequency over some divider) then each instruction takes 1 to 3 uS to execute depending on the instruction. So you write an assembly language routine where you create the serial output waveform on the port pin and then count the instruction cycles for each state to reach 104uS per bit. (note I rounded off to 104, this makes 9615 baud which is less than a 0.2% error and generally not detectable)
here is an example from some code I wrote probably 10 years ago for a PIC micro that did not have an actual UART. This is transmit only.
; bit bang serial tx for Microchip PIC16C505
; Allocate registers ( memory )
temp equ 0x10 ; variable used by Xmit
cntr equ 0x11 ; variable used by Xmit
; constant to set bit delay timing
baudiv equ 0x0a ; divisor for 9600 @ 1.8432 MHz
;
Xmit bcf PORTC, TXD_C ; start the start bit
call bdelay ; wait for the bit to complete
movlw 0x0a ; get 8 bits + 1
movwf temp
bsf STATUS, C
xmitlp decfsz temp, F ; dec bit count, skip goto if zero
goto bsend ; go send the next bit
nop ; wait for msb to complete
nop
nop
nop
nop
bsf PORTC, TXD_C ; start the stop bit
call bdelay ; wait for the bit to complete
nop
nop
nop
nop
nop
retlw 0
bsend rrf sdata, F ; rotate lsb into CF
btfss STATUS, C ; skip jump if set
goto bclr ; go send a zero
nop
bsf PORTC, TXD_C ; send a one
call bdelay ; wait for the bit to complete
nop
goto xmitlp ; go for next bit
bclr bcf PORTC, TXD_C ; send a zero
call bdelay ; wait for the bit to complete
nop
goto xmitlp ; go for next bit
bdelay movlw baudiv ; waste a few microseconds
movwf cntr
bdlp decfsz cntr, F
goto bdlp
nop
nop
retlw 0 ; and returnTo test something like this, with the MPLAB simulator you can use the stopwatch window and determine how many uS between bits. It is important to try many combinations of bit sequences as I remember one point in development where there was a “short” bit if a particular sequence occurred.
good luck on writing a version for your h8/300 controller. 
So Eddie, this means there are three types of communication? RS232, TTL, and Bit-Bang?
RS-232 and TTL define only the voltages used in serial comms. UART or bitbanged comms can use RS-232 levels or TTL levels.
Slightly different, but you can also include RS-485 (industrial control) in that group of choices.
Then there’s full duplex, and half duplex. And I’m sure there’s more ways as well!
Alan KM6VV
com’on guys, I know it is funny but you are going to confuse the smoke out of some poor newbie trying to figure out how to connect an ssc-32 to an abb without reading the tutorial first.
uart = hardware serial port
bit-bang = software serial port
those have absolutely NOTHING to do with TTL, RS-232, RS-422, or RS-485 which are (communication) standards defining voltages and wiring.
full-duplex = can send and receive at same time
half-duplex = can send OR receive, but not at the same time
single-ended = signal is single-wire and referenced to ground
differential = signal requires two wires, normally twisted, and are not always referenced to ground
TTL = signal level used to connect serial ports, single-ended, usually configured full duplex
RS232 = signal level used to connect serial ports, single-ended, usually configured full duplex
RS422 = signal level used to connect serial ports, differential, usually configured full duplex
RS-485 = signal level used to connect serial ports, differential, half duplex ONLY
TTL, RS-422, and RS-485 all have similar voltage levels and use the convention 0 volts is low (logical 0) and more than about 2 volts is high (logical 1)
These signals usually range from 0 to 5 volts with respect to ground (0 volts.)
RS-232 uses much higher and negative voltages and is logically inverted (1=0, 0=1) so that below 3 volts is considered high and above 3 volts is considered low.
RS-232 signals can go as low as -15V with respect to ground (0 volts.)
Eddie is the master… 8) 
That was actually very helpfull information. Thanks!