hi guys. i figured out my program but now it seems to register that im sending to it but servo will not move. i have the Tx of my micro attached to the Rx of the servo board and the groung pin attached… do i need to supply vdd? i know its recieving correct info as i had it sending strings to the terminal of my computer. it works with the db9 plugged in and using the lynx terminal. but when i plug the tx of the comps serial cable to the rx pin on the headers (not the db9 connector) and gnd,then it then wont do anything.why…
Are you saying you’re connecting to the microcontrollers TTL TX and RX pins to the SSC-32’s TTL TX and RX pins? If so then you need to invert the serial data being sent to the SSC-32. It would be helpfull if you could post that section of your C code.
Even more helpful would be a picture of your setup (if you’re camera is good enough for that) or a drawing of it.
We talked before about the two jumpers that cover the TX and RX pins.
Have you removed them?
They must be removed in order to disable the DB9 connector and enable TTL.
And, as I said before… I can’t remember whether or not you need to share Vdd.
I don’t think so, but I might be wrong.
TX of one should go to the RX of the other and vice versa.
Make sure that your micro’s UART is working at the same “baud rate” (I’m told that it’s actually a data transfer rate and that baud is an improper term, but that’s going off-topic…) as the SSC-32 (the SSC-32 defaults to 115200, but your manual will show you which jumper setups = which baud rates).
I’ve run out of ideas.
If you can get us a picture/drawing, we can probably spot any obvious booboos.
oki here goes. purple wire(looks blue) is the TX on micro red is ground on micro board. 9v batt sor ssc and 5v batt for servos. 9600 baud jumper.
k here are 2 pics. this is with the phone on my camera as i dropped my cannon 8.1mp cam last weak… >.< DOH. but u can still see pretty clear
when i figure out how to send them on here… bugger.
ne wayz here is the code:
// USART initialization: 9600,8N1 @ 8MHz
#include <avr/io.h>
#include <util/delay.h>
void USART_TxString(const char *strptr);
void USART_TxChar(const char sendbyte);
int main (void)
{
DDRC = 0x00;
UCSRA = 0x00;
UCSRB = 0x18;
UCSRC = 0x86;
UBRRH = 0x00;
UBRRL = 0x33;
USART_TxString("#0 P1792 T1000 cr");
}
void USART_TxString(const char *strptr)
{
while (*strptr != 0x00)
USART_TxChar(*(strptr++));
}
void USART_TxChar(const char sendbyte)
{
while (!(UCSRA & (1 << UDRE)));
UDR = sendbyte;
}
USART_TxString("#0 P1792 T1000\r\n");
There’s been some uncertainty on the forums here whether it requires both the carriage return and/or the line feed.
Perhaps you can resolve this once and for all.
either way i have tried both… in many possible ways.
i even took the tx pin of the db9 cable from my PC and connected it to the rxd pin for controller and grounded it… but all i get is the light taunting me as it flickers. but yet it works when i plug the db9 cable in the ssc board and put thos 2 jumpers back on 
I think I was unclear. The problem is your string termination. The “CR” at the end of your string isn’t meant to be interpreted literally, rather it’s a placeholder for a Carriage Return and/or a Line Feed characters.
change
USART_TxString("#0 P1792 T1000 cr");to
USART_TxString("#0 P1792 T1000\r\n");If that solves your problem, then try just the \r or just the \n and establish once and for all what the thing is looking for.
changed it to that and still no luck… they rx doesnet have to present does it?
cant see anything in the manual about like needing an opening command or anything… usually u send a device number
Ok this is really annoying me now lol… to make things worse i wake up when most of u guys go to bed. and visa versa. but ne how i have been trying all day to get the controller to recognise my commands and it just wont.i send them to the hyper terminal and they are fine… they now comeout just like the lynx terminal puts them out. its driving me insane. does any one use a micro to control this board? 
(the life of the programmer) >.< i dont see why the tx and gnd from the pc plugged into where im attempting to plug the micro in wont work either yet it will when its in the adapter.
now im going to try and stay awake till u guys start answering so i can get this figured out quickly… now wheres that coffee 
Hrm…
Do you have a logic analyser?
Dan Albert (the head of CJRG and SJRG) used one to test my WiPort when it wouldn’t work with the SSC-32.
He was able to confirm that the WiPort was recieving the instructions that my PC sent it, but not relaying the instructions to the SSC-32.
no i unfortunately only have a cheap ocsiloscope. 
Do you have anything else that you could hook your micro up to to test the UART output?
Perhaps an LED?
ahh yeah. the PC’s hyper terminal and yeah i own an LED.
Any luck yet Dan? How does the LED test work?
yeah it flashes briefly as the data is transmitted
Lol, my bad!
I actually meant “LCD”, but mis-typed.
The LED flashed, eh?
Hrm…
Well, I’m not at all experienced with data sending…
But it seems like that’d be a pretty slow data rate if you could actually see the LED flashing.
Are you sure you’ve got your microcontroller sending at a 115200bps data rate (assuming that you’ve got a mi
If it goes on when you send a lot and then goes off afterwards, that might makes sense.
But if you send it a string of characters all at once (use the LynxTerm to send a new position to every servo) and see more than one flash, I’d be suspicious…
At least we know that your micro is outputting something, whether or not it’s what the SSC-32 wants to see.
Ahhh!
That reminds me.
Try this:
Power down your SSC-32.
Power it back up.
Have the micro do it’s thing.
Then check to see if the SSC-32’s green LED has gone out.
If it’s recieving something, even if it’s garbled, it’ll go out.
This might also be part of the problem. Serial runs as two very different voltage levels. The PC uses RS232 voltage levels which if connected to a TTL (0-5V or 0-3.3V) may fry the electronics on the TTL side. The AVR is working with TTL levels. If you try to connect a TTL TX to a RS232 RX the nothing will be damaged, but it won’t work either. On the SSC32, there are both levels exposed of the same serial port. The DB9 connector is the RS232 level port and there is a 3 pin TTL port elsewhere. These cannot be interchanged. If you had connected the PC to the TTL port, there’s a chance that the SSC32 has been damaged in the process.
As an aid to debugging, there is an LED on the SSC32 that blinks when it recieves data.
yeah led test works no worries. but how does that determine what its sending? 
I’m not sure what else to suggest here… I haven’t gone through all your settings to double check the AVR baud rate and the like, I assume you’ve double checked them.
I’ve not looked at the schematic but it seems likely that the LED could flash independently of the SSC32s AVR IO pins being damaged via RS232 voltages if you had connected the PC to the TTL port.
The termination that I discussed above is definitely A problem, if not the only problem. So make sure you do the rest of your testing with the string I suggested.