SSC-32U USB, XBEE, More analog and digital I/O!

Here is a preview of the new SSC-32U.

We have completed the draft design for the USB version of the SSC-32. Here are the changes to note:

  • SMT processor (ATmega328) and EEPROM.
  • USB mini-B connector and FT232RL chip.
  • Support for bit-bang programming of fuses and bootloader over the USB port.
  • XBEE socket, with antenna hanging off the right edge of the board (as specified in the datasheet). 3.3V regulator and level shifter to communicate reliably with the 5V processor.
  • TTL level TX/RX header.
  • Series resistors on XBEE and TTL RX, so the USB port will dominate if connected.
  • 6 LEDs in 0603 packages (1/4 the size of the LEDs used in SSC-32 and Botboard). PWR in lower left corner, USB TX/RX in upper right corner, XBEE RSSI (Received Signal Strength Indicator) in lower right corner, and general A/B status LEDs next to the crystal.
  • “Baud” button near the A/B LEDs. Used to select baud rate, and to keep the processor in the bootloader on reset. This replaces the Baud jumpers on the old SSC-32.
  • It is possible to reset the processor and keep it in the bootloader using the USB connections. This can be an enhancement to the firmware loading process.
  • 8 analog input pins (A-H) on 3-pin headers. 2 are analog input only, the other 6 can also do digital I/O.
  • 2 of the analog input pins can be I2C with software-selectable pullups.
  • Larger terminals (same as BBduino).
  • SMT regulator, the same one as used in the BBduino. Lower dropout voltage than the one previously used on the SSC-32.
  • Pads for 440uF capacitance on logic power to help with brownout.
  • Schottky diodes from Vservo1 and Vlogic to logic power to make the capacitors effective. These act as a best-battery select between Vservo1 and Vlogic. The VS=VL jumper bypasses the diode if the user doesn’t want the diode drop, but makes the capacitors less effective.
  • An extra 5V/GND header in the upper right corner. This can be used for anything, but one of the things I was thinking was to connect a large capacitor to help with brownouts.

Note that there is no provision for the board to be powered by USB. That would have been much more difficult with (I think) minimal benefit. USB is not sufficient to power servos in a real application, and if servo power is applied, it will power the processor.

Nice design!

the FTDI chip is bigger then the '328!

“Baud button” is an interesting addition! I assume once baud rate is changed, it is stored in EEPROM (FLASH) of '328?

Ever consider a pair of DC servo drivers?

Alan KM6VV

Looks Great!
When can we get one?

Will probably have more questions later like:
a) is the XBee connected to USART? If so do I need to unplug it to use USB?..
b) will there be other fun things I can try, like use TTL from BotBoarduino to talk to it and some maybe someone connect up to use an XBee plugged into it? (Probably not, but…)
C) any thoughts about voltage divider circuits optionally hookups? Might also be nice, could potentially add commands, like shut off servos if voltage goes below x…

Kurt

More info from Mike D…

The A/B LEDs are on solid at power-up. The first received byte turns them off. Each valid received byte causes the green LED to flash. Invalid bytes cause the red LED to flash.

If you press the button, both LEDs will blink briefly, show the Baud rate for a couple of seconds, and then blink again to show they are going back to normal mode. They are at half brightness when showing the Baud rate. The encoding is:
OFF,OFF = 9600
OFF,ON = 19200
ON,OFF = 38400
ON,ON = 115200

I thought 19200 would be more useful than 2400, but that is easily changed if you want it to be just like the SSC-32.

To change the Baud rate, hold the button for a few seconds until the LEDs start blinking back and forth. Then let up and the LEDs will indicate the current Baud rate. Press the button to cycle through Baud rates. After a few seconds without a press, it will store the new Baud rate and turn both LEDs on solid (just like after power-up).

Register R4 can be used to set non-standard Baud rates, but the button will always override and set back to a standard rate.

Supported commands right now are:

  • VER
  • #, P, S, T (e.g. #0P1500S1000#1P2000T10000)
  • PO
  • Register read/write
  • GOBOOT

Right now the register values can be read and written, but for the most part they don’t do anything yet. I am adding that capability now. After fully supporting registers, I will add the query commands. Then I will work through the remaining commands.

The bootloader is on version 3. (The “v” command returns 3.) The previous bootloader was version 2. This can be used to prevent flashing firmware on the wrong board. Otherwise the bootloader works identically to the previous SSC-32 boards.

The procedure to recover from a bad app has changed. On the SSC-32, you put the Baud jumper across the pins and cycle power. On the SSC-32U, you hold the button while cycling power.

The VER command will return “SSC32U” as the first characters in the version name.

On the hardware side, the VS=VL jumper is now optional. There is a diode circuit that provides VL based on the higher of those voltages. If you install the jumper, then the diodes are bypassed and it works exactly like the SSC-32. I used Schottky diodes to minimize the voltage drop, and have those 2 large capacitors to (I hope) reduce the potential for resets due to voltage dips.

The blue LED is always on when the board is powered.

I like it the USB will be a welcome edition to those of us using labtops :mrgreen:

The USB, XBEE, and TTL inputs are all connected to the UART. I used resistors to protect against multiple sources being connected at once. Here is the logic:

  • If USB is active, it wins no matter what else is connected. You don’t have to remove the XBEE or disconnect the TTL. (But be aware that whatever gets sent over USB will also be transmitted over the other ports.)
  • If USB is not active, then either XBEE or TTL may be used, but not both. If XBEE and TTL are connected at the same time, they will interfere with each other (but the resistors will prevent hardware damage).

There is only the one serial port, so you can’t chain boards. The hardware has I2C support, so it might eventually be possible to do something interesting with that. But the initial effort is to simply duplicate the existing SSC-32 functionality. Maybe you can help define what the I2C capability should be.

The board hardware has no voltage divider built in for battery voltage measurements. One could create a cable to go from an unused servo port to an analog input, where the cable contains the necessary divider. Then there could be configurations to cause actions to occur (like shutting off the servos) based on voltage thresholds. Again, chime in on how it should work.

You will have yours next week… :smiley:

A very interesting upgrade of the SSC-32!

The VS1 - VS2 jumper appears to have four pins, two sets of two. What is the second set for?

You may have inadvertantly solved one of my major frustrations with earlier boards - trying to jam 12 pounds of stranded battery wire into a 10 pound VS socket. Am I right in thinking that so long as VS1 and VS2 are set to the same source by the jumper, one could substitute a higher gauge (thinner) battery wire but connect it to the board at both VS sockets? Or does setting the jumper take one of the sockets out of the circut?

In any case, I applaud the move to the longer sockets which provide a sturdier mount to the PCB.

Thank you,

Thank you for reminding me again about your extreme dislike for the screw terminals. As you can see it is a big job making improvements to existing boards. The SSC-32 specifically has been incredibly difficult as feature creep tortured the design cycle several times before. This one is almost done!..

The VS=VL pins are exactly the same as the current SSC-32. Two of them increase the current capacity.

Hi Robot Dude,

Please don’t misunderstand my intent. My comment was not meant as a criticism but as a major “Thank You.” I can appreciate that you are constantly faced with the problem of supplying sufficient power (P=EI) for multiple current hungry servos (thus heavy gauge wire) and having to do it through standardized PCB mount sockets. I also appreciate(envy) that most of your clients seem to take this all in stride with no apparent difficulty.

So clearly if I am to remain in the hobby, it is my responsibility to adapt to your designs and not yours to redesign everything to suit me. (Although that would be nice. :stuck_out_tongue: ) Anyway, I stayed in railroading with my diminishing eyesight and arthritic fingers (cue violins here) by going to the relatively hugh G-scale trains in my garden instead of the HO models I used to build. I can’t afford a similar 6400% increase in the volume of my robots, so I’ll stick with Lynxmotion because I like your erector set approach best.

You gave me advice before on working with the power leads which did help me a lot. This new VS1 - VS2 design, though intended for other reasons, appears to give me another route to adapt.

Have I won over your sympathy yet, or do I have to cue the violins again?

No need to cue the violins. I’ve got an orchestra playing here buddy… :wink:

I powered my ssc-32 via usb for a year or two and found it to be quite handy with my laptop. I just jumpered from the usb/serial adapter +5v to a +5v pin on the ssc-32. It was sufficient to power an unloaded small servo for movement testing. On this board one might make a temporary wire jumper from the usb connector +5v pad to the adjacent +5v pin to do the same thing.

I’d be sure to add the stop command, the current position query command, and the analog pin input voltage query. These add some significant functionality to the ssc-32.

Also I would also make the reference voltage pin jumpered (if possible with this chip) so any number of reference voltages could be used to have full range reading of input voltages on the ssc-32 analog input pins. I did this with my ssc-32 and found it to be useful.

I haven’t thought it through, but what if you had compare routines for input pins, such that they could be set up to compare for an analog value, or a digital value, and either return a value or perhaps set a pin to a level. You get the idea, download simple “watch” functions to the SSC32U.

You’d call a function to set them up. Like can be done on the “processor” boards.

Alan KM6VV

This Mike, the SSC-32(U) developer. I’ll try to follow this thread and answer questions. Starting with these.

The baud rate entered using the button is stored in register R4. You can change the rate using R4, and can change it to any supported rate, but the button will always allow it to be changed back to one of the standard rates. R4 is actually the baud divisor used by the processor (rather than the actual baud rate), so the relationship is
Baud = 921600/(R4+1)
R4 = (921600/Baud) - 1

The USB 5V is not brought to a pin, but might be available on a via. I’ll have to check.

The processor does support a Vref input, but I didn’t bring it to a pin. That is one of the things that fell off due to the tight layout, trying to fit everything onto a 2-layer board. I believe Vref is available at a via.

Mike

I would really suggest that you allow the logic be powered via usb. That way you don’t need to worry about hooking up a battery to test the board or update the firmware…

Oops, forgot to mention one more thing. The processor has an internal 1.1V reference that could be enabled for precision measurements of low voltages. This could be controlled with a register bit.

And another thing. I am planning to add “decimal” versions of the query and analog voltage commands: QPD, VAD, VBD, …, VHD. These will return full precision. QPD will return ASCII strings “500” to “2500”. VAD-VHD will return ASCII strings "0’ to “1023”. This will increase the resolution of voltage measurements from 8-bit (for the current VA-VD commands) to 10-bit. This should help with A/D resolution issues.

Mike

I like it!

To keep the comments focused and helpful, please keep in mind we are not going to make any hardware changes to the board at this stage of the process.

Hi all,

Did these ever get put on sale? Can’t seem to find them anywhere.

Cheers

The SSC-32 V2 prototypes were made, and will be refined in the coming months.

I suggest you allow an option for powering the board logic via the usb connection. In the past the designers of the new board said it would be “too dangerous”, yada, yada, yada. Without the USB power option, I think the new board may be DOA.