Nice description Kurte!
Hereās a little more info.
Hi Dustin,
Hereās some notes I got from some conversations with Mike:
also check out Mikeās Circuit Cellar article on the SSC32 in the 2006 Robotics Issue.
Alan KM6VV
Well, trying to reverse engineer the SSC-32 eh 
From Mike explaination, when 2 pulses are closer to each other, the minimum pulse time between them is 1.49us? So the resolution of 1us is not correct when 2 or more pulses are close to each other?
Thatās the way Iād read it. Perhaps Mike can explain more. Or the newer 168 code may have improved specs. I failed to mention that this is from a year or two ago (previous AVR)
Alan KM6VV
Most of the problem (and challenge) for high resolution PWM is when there are 2 or more pulses very close to each other. Imagine 8 pulses which are very close to each other, we will have error of 4us. But still, that is very impressive.
It has been my understanding that the the programming code for the ssc-32 is open source and available to those that have an interest.
Pretty good description for not being the best person to ask. 
This not what I expected however. Given that each shift register is, in effect, managing one servo I expected each output pin to be emitting a PWM signal. It sounds like this is not the case though. Does that mean that the Atmega is updating the shift registers multiple times per second?
Hi Alan. Thanks for the info but I have to admit that, at least for the moment, it is a little above my head. Iām sure it will make more sense as learn more though.
Pretty much 
According to the following page the SSC-32 is open source: lynxmotion.com/images/html/proj078.htm
Though itās not explicitly stated in the docs I presume itās also open hardware given that the schematics have been provided.
I didnāt know that SSC-32 is an open source project. Iām not even aware of such electronic component as shift register. I first saw the pulse out signal of SSC-32 from someone in this forum, was really impress with it. Couldnāt figure out how it was done.
If I have know it earlierā¦ Anyway, I peaked inside the source code, looked so alien to me.
Edit: It looks like my previous reply got completely mess up at the server so I will try a quick retry:
I am a software guy, but I did have a few electronics and microprocessor design classes back in college, but that was a long long time ago.
About 4 years ago I built the Seattle Robotics Society workshop robot, including level 2 and level 3. They had an add on board that I assembled (which was the first time I soldered SMT type components). This board had two sets of shift registers. 2 were of the type that we are discussing and the other two were used to bring inputs back from a set of buttons and the like. I then wrote the code for an Atmega32 that used SPI to interface to all of the components on this board. So I have had some experience with this chip.
Each of these shift registers do control 8 servo outputs. For example: U4ās outputs (QA-QH) connect up to the external connectors on J1-A and J2-A and handle the servos 0-7.
The SPI interface can easily update the latches many times a second. The SPI can change the state of the clk line as fast as every 2 clock cycles, so a full byte can be output in 32 clocks which if the processor runs at 16mhz or so it can do quite a few outputs.
On the SSC-32 the code calculates the start and stop times of each pulse and then when the transistion times come up it simply updates the byte associated with that servo. The code can be pretty accurate as it could send down the next transistion byte ahead of time and then when the next transisition time comes it simply has to toggle the chip select on the appropriate byte and then calculate which byte will need to be updated next and down load itā¦
Kurt
P.S. - I hope this one takes
is it just my computer or does this thread look messed up? 
It sure did. I got some type of server error when I posted earlier. I deleted the one post and I think it looks better!
Anyway, I like your explanation Kurt! I did not know what on earth a shift register was either. 
BTW what is that other chip near the RS-232 connector on the SSC-32?
That is the TTL to RS232 signal level changerā¦
IE that is what takes the RS232 level signals that come from the host and converts it to TTL level (0 and 5v) that the microprocessor (ATMega) uses. In other threads you will see mention of other chips that do this like a MAX232ā¦
Kurt
Wow! A lot of responses to this thread. The SSC32 (at least the 1st version) is open source. Youāll need a CodeView compiler to compile it.
Itās a very complex program, that works in layers. Very tightly coded, and ātweakedā to get the best response times. Not code for a first project, or the timid. It would be difficult to port to another processor. Update algorithms closely tied to the Atmel timer architecture.
SPI and the shift registers can easily work at 10 mHz, although theyāre not running that fast here.
Alan KM6VV
The SSC-32 firmware was made open source in an effort to allow users to make and share different āflavorsā of firmware for the hardware we sell. The hardware has never been open source and copying it is strictly forbidden. We do not promote, encourage, or allow people to copy the hardware or cross the firmware to other processors. Hope this clears up any questions concerning the SSC-32 hardware and firmware.
Kurt:
Thanks for the info that really helps. Just to be sure I understand let me plug this into the bigger picture. Correct me if I go astray.
Ultimately our goal is to control servos. If we were to interface a servo directly with our microcontroller then we would generate a square wave by pulling the logic pin high for a period of time and then low for a period of time. The amount of time it is high relative to how long it is low directs the servo to move a specific position.
The number of servos we can directly interface with our microcontroller is limited by the number of GPIO pins available (or is the limitation a result of the number of pins that can do digital out?). Placing the serial-in/parallel-out shift register into the circuit allows the microcontroller to interface with additional servos. The microcontroller still generates the square wave for each servo but instead of sending it directly to the servo it loads it into the shift register memory and instructs the shift register to change the state of itās output pins (i.e. move the data from memory to the output pins) at the appropriate time. The fact that weāre working at such a rapid pace has the added benefit that different square waves can be generated for different servos simultaneously.
For anyone else trying understand this there is an article on interfacing a shift register with an Arduino on the Arduino site: arduino.cc/en/Tutorial/ShiftOut
Obviously my assumption as to why the circuit design is in the manual was wrong. Iām curious as to why itās there (please donāt take this the wrong way I am new to the electronics world and am truly curious). I have to say I find this position surprising given the success of open platforms like the arduino but then I think the SSC-32 has been around longer so it kind of makes sense. Ultimately thatās your business decision, I donāt mean to question it Iām just taken back. You donāt need to worry about me copying the design as I am only interested in it from an academic perspective as I originally stated.
No offense intended Jim. Which is why I never thought of asking any question of SSC-32 architecture. If I need the SSC-32, it is only fair if I bought it directly, the credit should go to LM. The cost of self-prototyping isnāt worth it also, even with the schematic and source code available.
Arduino is only a dummy circuit, like some demo, starter, prototyping kit for developers. There isnāt any logic and source code available for something as complex and succesful as SSC-32.
The truth is I paid dearly for the complete development of the SSC-32. It was designed exactly to my specifications. Everything from the group move command down to the GP sequencer and 12 servo hexapod sequencer. It was decided to make the firmware open source but with the exceptions listed. It never went anywhere. At this point I question why we continue to make the source code available. All itās truly done is make me look like an ass when I tell people they canāt port my code to their processor, or make their own SSC-32.
We give away so much information, and we have done our best to promote robotics and educate new and old robot builders alike. Hell I can remember even 5 years ago when I was searching the net for IK solutions for the arms and legs. There was nothing available, period. Now we have three unique solutions in our projects section alone, plus Laurent and Jeroenās Atom Pro code is all available on a silver platter for anyone looking. I have paid for them as well, but give them away freely.
The schematic for the SSC-32 is included so people can see what is going on under the hood. Itās a courtesy to our customers. If it answers questions then the phone may not ring as much. I hope this explains a bit as to why things are the way they are.
And being the repository of code and designs and SES parts etc. Draws customers.
They may start out wanting to simply experiment with the SSC32 on their own processor, but before you know it, theyāre buying a Thousand dollars worth of parts! Good for business, I think.
There STILL isnāt a similar controller targeted EXACTLY at what is needed to control a mass of R/C servos the way the SSC32 does! Maybe something at well over $100, but itās not competitive, or as complete.
I was introduced to IK on this list, Iād only done CNC machine controllers before. And I probably wouldnāt have thought to try IK without the introduction to a solution to be found on this list.
I wouldnāt worry too much about others copying your products. Theyāve all been out for a while, and no one has a solution that even comes close!
Idea: You might think about how you could provide a ācustom bracketā shop. Iāll bet others might be able to dream up a bracket, but canāt make it. I donāt know how viable a service it could be, just an idea.
And with the development of SES parts to replace the plastic, well, Iām hooked!
Alan KM6VV
I really donāt know much about the engineer behind the ssc-32, but I know that the output compare register in the Atmega chips is OCCR not TCCR. OCCR is up to Out put compare register while TCCR is for Timer control register.
Youāre correcting a typo in a 5-year old quote from the software engineer who wrote the fine code in the SSC-32?
I studied the code 5 years ago, compiled it, ran it, etc. Itās still top of itās game!
Alan KM6VV