Data Sent, Servos not moving

I will try to be clear and concise as that seems to be an issue here when people ask for help.
I am connecting an ssc32 to an FPGA via direct serial.
I have connected the grounds between the two boards and have also connected the RX and TX pins(viewtopic.php?f=2&t=5440)
The board is being powered by a 9v battery and is isolated from the servo power.
The packs are supplying 6-7v across the first rail(when i multimeter the pinouts for servos, they read at apx the pack voltage. This seems correct.)
I have servos connected to ports 0 and 1.
The baud rate for the fpga has been set to 115200.

Here is a image of the board setup:
i.imgur.com/trLpm.jpg

Now that the setup is out of the way, I will talk about the problem.

When i initially turn on the ssc-32, the green LED illuminates.
It remains on untill i give it a command. At this point it goes out(i assume it flickers to fast for me to see it) or flickers slightly.
After this occurs, none of the servos move.
As a test, i looped the serial output of the fpga. When i constantly send strings, the LED on the ssc-32 flickers.
This is the string i am sending:

#1 P1000 T500

I do not have a usc-serial connector so I am unable to connect the system to the computer directly to test it. I was just curious if anyone here had any ideas before i spend the next couple days waiting for the cable to i can trouble shoot. I am on a relatively tight schedule.

So whats an FPGA?

Female Professional Golfers Association :smiling_imp:

An FPGA is a Field Programmable Gate Array.
It allows parallel processing in real time.
For the purposes of the question, just think of it as a microcontroller.

Without a computer with a serial port, not much else available to do some testing.

I’m curious why you have the DB9 cable plugged in and why you have one of the DB9 enable jumpers installed. Because the data normally goes through a level shifter (max 232) I believe you need to invert the data send from the FPGA. We invert the data when talking to the SSC-32 from an Atom.

Because the LED is blinking this means the SSC-32 is receiving data. Baud rate is not the issue. So it’s got to be the data format.

I assumed that the ssc23 was still handshaking with the other board when receiving data. Do i only need to use the RX pin then? I was also under the impression that since I am not sending any data i can simply bridge the TX pins. It was so i wouldn’t loose the bridge component because it is tiny.

I am also curious if you know what the maximum application frequency of commands is for the ssc32.
for example: could i send it 10ms commands every 10ms?

Whooooosh! That’s the sound of that entire paragraph going right over my head… In other words. What? :open_mouth: What other board?

The SSC-32 generates the servo pulses every 20mS. Because of the advanced method of setting up the servo commands using either Speed or Timed options. There’s really no advantage to sending pulses more than, say 30mS. I mean why send commands faster than the SSC-32 can respond to them. :wink: I believe RIOS sends commands to the SSC-32 every 33mS.

Sorry. By other board, I meant the FPGA. I am not pulling any data from the ssc-32 so I assumed that the TX pin on it could just be bridged.

For the second part, you answered my question perfectly. Thank you.

Ok I think I got it now. So the FPGA is sending TTL data to the SSC-32 via ground and RX. No need for anything to be connected to the DB9. Normally when TTL data is selected (non DB9 mode) both jumpers are removed. So yes the SSC-32 does not need to talk to the host unless the host asks for data.

The exception is when you want to read the version number from the SSC-32, or wait for a move completed response. Some of the code around here waits for this response.

Alan KM6VV

Same thing. :unamused: :laughing:

Alright. I bought a serial-usb adapter and am able to control the servos using lynxterminal so the ssc-32 is working properly. Any ideas with why the FPGA is not correcty communicating?

Hook it up to a terminal, and see what it’s sending!

Got a CR/LF on the end of the lines?

Alan KM6VV

You never really acknowledged my comments on data inversion… “We invert the data when talking to the SSC-32 from an Atom.”

I am unsure what you mean by “inverting data”.
I attached the serial out on the FPGA and took at the data in lynxterm. Here is an image of 3 consecutive commands which were output by the FPGA and read by the computer.

The spacing of the commands received on the lynxterm screen indicates that there are a lot of bytes possibly being sent that aren’t ascii viewable characters (assuming you didn’t type spaces and enters on your keyboard). You might download the free PortMon program to run on the computer along with lynxterm to see what is being sent. Set portmon to show the sent bytes as hex instead of ascii so you can see all the bytes.

It looks to me like you probably are not outputting any CR characters to the SSC-32, but instead out outputting several LF characters.

I am not sure what types of commands you use on the FPGA to output lines. If you are using some form of command like in VB of WriteLine, you may need to configure what the New line character is. Alternatively you may try to do the simple equivalent of a Write statement where you pass it a buffer and length and manually make sure you output the CR character. I sometimes do this in VB for example.

Kurt

Nah, he’s just getting a couple of LF (line feed) characters out, and none of the CR (carriage return) characters.

Data is OK, no “inversion” problem.

Put in some CR characters!

Alan KM6VV

You are right, looks like ~4 line feeds on the end of the command.