I recently purchased a Pololu Serial 16 Servo controller. I successfully assembled the kit. I applied power to the controller and the board LED’s turned on in the proper order. I also checked the power and I was getting a perfect clean voltage of 5.01 volts.
Using a radioshack USB-SER:
On powerup, the yellow LED turns on. I’m running in the Mini SSC II mode and set the baud rate to 9600. When I try sending a serial command to the controller, the D1 green LED starts to flash quickly and the D4 red LED turns on and stays on. I then reduce the baud rate to 2400 and I still get the same problem (turning on and off properly).
By connecting and disconnecting the power over and over again, I can sometimes get the controller to accept commands. Once the yellow goes off and the first green flickers briefly when commands are sent, it works until I shut it off (I was able to move servos as normal; worked well). Then I have to try over and over. It can take as many as 50 tries to get it to work. I’m using a terminal emulator program over the serial (and I’ve checked that its a straight-through cable). It seems to me that the firmware is coming up in the middle of the pulse and measuring the baud incorrectly…
Today, I could not get it to work at all. When I plug it in with a normal serial cable, all the LEDs light up and it will not accept input. Using the USB-SER cable, the only reaction we can get is solid red and flashing yellow.
I just spoke to you on the phone, so I’ll briefly summarize what I suggested. The serial adapter thinks the serial input is low; you should be able to verify that with your oscilloscope and find out if there is a short or bad solder joint on your board. Once you get back to getting some response from the servo controller, you can look at the serial signal right on the microcontroller pin and figure out what’s wrong with it. If the signal looks right to you, you can post a screenshot here for us to look at.
The input is indeed low. The O-scope is giving some strange readings so we’re looking around for a different power supply since that’s an easy thing to check. I took some pictures of our setup, posted below. Power supply image is a bit blurry.
The magnitude of the signal you see on the scope image is about 1.5V and 60 Hz frequency. It should just be interpreted as constant zeros. Why is it solid red with flashing yellow when not even 1 command has been sent (or before the serial is even connected).
If the scope is connected as shown in the picture when the device is powered on, all of the LEDs are lit until the scope is removed. When the scope is removed, it goes to the usual solid red, flashing yellow. If the scope is reattached nothing changes.
Well, that’s certainly not a nice signal you’ve got on the serial line, so it’s no surprise that the servo controller behaves erratically. However, I’m concerned about your basic setup and measuring techniques since the connection of the scope should not be affecting anything, and the 60 Hz frequency makes me think you’re just measuring the wall power. What does your power supply look like? You could also do your initial tests without the serial cable connected.
It’s hard to tell much else from the pictures, but are you sure the two TO-92 packages are in the correct places (regulator close to power input; NPN transistor closer to DB9 connector)?
The power supply is very clean (as measured with the scope).
Note that the ugly 60 Hz signal was measured as shown in the other picture (with the full view of the controller and all the voltage regulators). In the picture, the scope is attached to supply ground and the TTL serial-in. The clean signal image, lower down, was measured by connecting the scope directly to the serial output from the computer (after the cable).
With no serial connected, we tried shorting the ground to the TTL serial in and it properly turned on all LEDs. Is there a specific order we should connect things? i.e.,
turn on power supply
connect servo controller power
press connect on the emulator software
attempt to send commands
We’re pretty sure that the TO-92 packages are correct. Otherwise the unit would not have worked at all, whereas it has worked for us in the past in the this configuration.
On the terminal emulator, should handshaking be set to ‘none’ or ‘hardware’? We assumed ‘none’.
edit We can now consistently get signals transmitted and measure them with the scope off the TTL-IN. Not sure what changed… but once the lights are all on they stay on unless we manually short the TTL-IN to high which obviously makes it give low baud error. Picture from the scope below. No matter what we send it, (including #255#017#150), all the lights stay on.
With nothing plugged in but power, all LEDs are lit. By pulling the TTL-IN high manually, we can get just the yellow LED to turn on; this is the case even with the USB-SER cable plugged in (which makes sense since apparently it is being read as all 0’s anyhow. But the moment we try to send a signal it gives the low baud error.
Using the USB-SER:
reading the signal from the TTL-IN, we get .5V signal amplitude from the scope.
reading the signal from the serial pins directly, we get 12V amplitude. http://8enmann.googlepages.com/img060.jpg
With nothing but power connected, the logic-level input should be high (which causes the controller to light just the yellow LED). As soon as you are getting something else (e.g. the line is low), don’t connect more things to the controller. If anything, you want to remove as much as possible to simplify the setup in which the problem still appears. For instance, you could pull out the microcontroller to make sure there isn’t a problem with that.
In general, it looks like you have a short (or something close to it) from the serial input to ground. Forcing that input high by shorting to power is not a good move since you’ll potentially be setting up paths from power to ground that could cause something to break. There aren’t very many parts on that serial input node, so you should be able to trace it and find out why it’s getting pulled low.
We checked extensively and found all the wiring to be fine. There are no shorts as far as we can tell. We tried using signal right from the microcontroller using 1 sec delays between signals. For the 1 second, the board goes from all lit (typical power on state) to just yellow. As soon as it tries to send some data (255,0,150, for instance), we get solid yellow flashing red (fatal error?) at 2400 baud. At 9600 baud, it gives the sold red flashing green. What other information can we give you to aid this process? We’re going to have to give up and move on soon…
It doesn’t sound like you are following my advice.
Have you tried that?
I understand your frustration, but you’re really not helping yourself out with the way you are going about troubleshooting. We know there is a problem as soon as all the LEDs turn on upon power-up, and it’s a very specific problem (the serial line is low) that you are able to confirm through your measurements. Once that is the case, any additional details about what data you are trying to send are irrelevant. (It’s as if you had a long-distance phone call that wouldn’t go through, and you were trying to verify the number is correct when you don’t even have a dial tone.)
Can you provide more details about your extensive checking of the hardware? It’s obviously not fine. One thing you can do is to measure the serial pin and see how it changes as you connect it to 5V through a resistor of 1k-10k. That will give you some idea as to how hard your line is being pulled low. If you’re really certain that there are no direct mechanical shorts from the line to ground, you could also try taking out the transistor since that could be pulling the line low. If that turns out to be the problem, you can replace it with a general-purpose NPN transistor. And remember, all this should be done without the PIC microcontroller plugged in.
We appreciate your patience. I think there’s been a slight communication error. We did all the testing with nothing connected. We only connected the microcontroller afterwards in order to make sure that it wasn’t causing the problem (and it was primarily the scope that the microcontroller was connected to), but your analogy makes sense.
We will try the two tests you recommended (removing the transistor and checking the serial pin).