I’ve reconfigured my com port to run out of com2 and I’ve gotten the best results yet. When power is applied to the ssc-32 the led comes on. When I then click “connect” it goes out. When I open the firmware window, it doesn’t find any currently installed firmware, but when I choose the correct one and click “begin update” I get about 0.25 seconds of led blinking before the software method error message. I’ve also tried the jumper method, which also fails.
Clarification on the jumper method though. I’m not entirely clear on how to power cycle a board. I’ve been disconnecting power, changing the jumpers, reapplying power and beginning the jumper update.
This blinking when commands are issued is the best result I’ve gotten, so I feel like I’m close. Any suggestions on how to get the rest of the way there?
It’s fine for you to try and communicate with the board as a test method. Use the VER statement to get the currently installed firmware version. However don’t try to update the firmware as a test method. If you flub up the firmware it might be a bit difficult to get it back…
well this is the first time I’ve ever used this board, so I’m following the instructions from here to set it up, which includes this firmware update. However, while data appears to be capable of transferring, nothing I try seems to succeed. Ver returns nothing, the firmware update fails. I have the baud rate on the board set at 115.2 and the software also at 115.2.
Do I need to change any of the other values in setup, like data bits, stop bits, flow control, etc?
It’s np, I just wanted you to know we need to get the communication working before we try and update the firmware. Have you looked at the serial port troubleshooting guide? It covers a lot of info for SSC-32 communication and Atom Programming, both of which requires a fast properly functioning serial port.
You ultimately will need to dig deeper into the PC to see what sort of serial port it has. PC’s can have all manor of crazy things that falls under “serial port”. I’ve seen VCP virtual com port controlled from USB drivers connected to a DB9 port. There may be settings in the device manager that can effect speed of communication. Check that the rx and tx buffers are the same, not one off by two (14/14 not 14/16). This is all in the link above, I’m just rewriting it…
Not working yet, but your suggestions did catch that rx and tx were off like you expected. Also, in the device manager, the bits per second for the com port was set to 9600 instead of 115.2, I’ve fixed that as well. I’m noticing now that I’m if I leave power supplied for ~15 seconds without the serial connected, the light eventually fades out. Maybe I just have a s#!$@ battery, I’m going out now to get something with more umph.
I still haven’t come close to my previous best with the flashing LED, hopefully I’ll get there in a few.
edit replaced the battery and I’m getting my good results again. One green flash for VER and Reg, 0.25 seconds of flashing for firmware update, but everything is still failing. VER hasn’t returned the firmware version yet. I’ve looked through the ssc-32 help you linked to but I can’t find what I’m looking for.
edit 2 the guy who hijacked this thread describes my problem exactly. Unfortunately, he attributed his fix to a miracle and posted no solution. The only difference, I am not using the usb-serial converter.
So I’ve tried everything I can think of, every setting and every wire looks to be exactly where it should be. Now I’m wondering…
When the bot was delivered, the largest chip on the ssc-32 had some yellowish residue around one of the top circles. I’ve been assuming that it is probably just from a sticker or packing material or some such, but I’m starting to wonder if the actual processing on the board is defective. It would explain why the serial connection seems to be operating and receiving commands but no action can be taken.
If the LED comes on, that means the chip is programmed correctly. It’s not a power light, but a status indicator, I.e. it is controlled from a pin on the SSC-32. If you have access to another PC you should try that first.
definitely trying to find another PC to test it, but haven’t been able to locate one with a serial port. I went ahead and ordered a serial/usb adapter for general portability, but it would be nice to understand what is wrong for future reference.
I wouldn’t typically assume defective, but the reason why I wonder is because its only the one chip that I noticed the discoloration. Would you happen to know if that chip (the largest on on the board) would be accessed for diagnostics but not for general communication?
Good news, my roommates old laptop had a serial port, moved the operation over there and I’ve successfully updated the firmware on the board. However, despite everything seemingly going well, I can’t move the legs. The next step in the tutorial is to hit the ‘All 1500’ button and they should go right into place, but I’m getting no feedback from any of the servos. I have the battery pack I described earlier attached.
This firmware up was just part of the initial setup as described in the Phoenix electronics tutorial.
For some reason my servos stopped responding again. I’m going to hold off on more testing until I can find a 6v battery instead of 7.2. I don’t know if its the problem, but I was noticing the “jitteryness” that was predicted.
Most servos are designed to operate on 4.8v-6v. I’d say that 80% of problems encountered are insufficient power. If the bot tries to move and the green LED on the ssc-32 lights up and stays on, then that is a dead give away. If one servo works and a bunch don’t is another clue.
The only time I ever caution against updating the firmware is when it’s done as a test for proper communications. If something is borderline it could hiccup in the middle of the update process, possibly corrupting the code. There are safer methods for testing communication.
Make sure you only have one application utilizing the serial port at a time. Windows will only allow one application to have “control” of the serial port at a time. This can be a source of much head scratching if suddenly things stop working.
