SSC32U to Raspbian Communication (UART)

Hi!

I’ve been working on a trivial example (as shown by the guide provided here):

I am able to get the controller to receive commands from the Raspberry Pi. It will blink synchronously with the commands sent via the python example.

However, when I send commands via the Raspberry Pi to the servo controller… It doesn’t seem to want to budge.

#5P1500S750<cr>

The code I implemented is the following:

import time
import serial

ser = serial.Serial(
    port='/dev/ttyS0',
    baudrate = 115200,
    parity=serial.PARITY_NONE,
    stopbits=serial.STOPBITS_ONE,
    bytesize=serial.EIGHTBITS,
    timeout=1
)
counter=0

while 1:
    ser.write("#5P1500S750<cr>")
    print "Output=" + ser.readline()
    time.sleep(1)
    counter += 1

I made sure the Baud rate was correct (as provided in the PDF guide).
Thank you in advance! :slight_smile:

1 Like

Also I can confirm it works in LynxTerm so the issue is isolated with UART communication serialization.

1 Like

@scharette, just pinging you in case you didn’t see this! :slight_smile:

1 Like

Just in case - did you physically change the baud rate on the SSC-32U via the button to match the baud rate set in your code?

1 Like

Yes, I did it manually by clicking the button labelled “baud”.

1 Like

I am using a Raspberry Pi 3.
I connected the UART pins to 8 and 10 as specified in this guide here.

1 Like

It may just be the code, but to be certain, you might want to include clear photos showing all connections between the boards.

1 Like

Hey @itschriscates,

Lets go over a few details to make sure I get a good grasp of your situation.

I assume this was done by using the USB port of the SSC-32U? Or did you mean something else?

Over UART?

Assuming you mean a connect RC servomotor to the board is not moving?

What did you do to confirm it functions? Move a RC servomotor using slider?
Also, did you try typing “VER” followed by [return] in the Lynxterm terminal window and see if the SSC-32U replies with its firmware version?

I assume then that if you power the SSC-32U and press the baud button once you get both green and red LED to blink quickly for a few seconds (indicating 115200 baud)?

Might want to be careful when using this guide since while it does mention twice in the article something about logic levels (3.3 V DC vs 5.0 V DC) and needing a logic level converter (such as RB-SPA-879), it does not seem to place much emphasis on it.

See below from the guide you linked:

Now, of course, the main question is: Did you use a logic level converter for connecting the SSC-32U direct UART port (TX/RX/GND) - which is a 5.0 V DC device - to your RPi’s gentle 3.3 V DC GPIO?
This could very well be causing two issue:

  1. Why it doesn’t work, since 3.3 V DC may not register properly to a 5.0 V DC interface, especially at higher baud rates
  2. The 5.0 V DC output (TX) from the SSC-32U can (and most certainly will/already has) damage the RPi’s RX pin since it cannot accept more than 3.3 V DC and has no protection for use with / against accidental higher voltages.

As a general note, it should be noted that the Broadcom chips used in the RPi started their lives and main embedded MCU for smart TVs and as such as no protection for circuits that are hand wired to its exposed pins/interfaces. Extreme care is required when connecting anything to a RPi (or similar SBC’s exposed GPIOs).

If you did have 5 V DC going directly to one or more GPIOs of the RPi, it is quite possible you damaged it and from then own it should be considered in an “unknown state”, whereas anything could be wrong from a single pin or to the full UART interface it was connected with to anything else related to this peripheral inside the SoC.

You should definitely show us some pictures of your setup, making sure to clearly show all components (RPi, SSC-32U, wires, cables, power sources, etc.). You can annotate the pictures as required.

I await your reply to the points above to further assist you.

Sincerely,

Oh gosh…
Just realized…

Fortunately it’s an undervoltage and not an overvoltage so it’s no big deal.

In this case… I’ll just stick to serial USB connection (for now). But I will need to transfer it over UART when I use a PiZero to host the app instead.

Thanks for clarifying!
I just realized that part of the tutorial and was negligent on my part for not realizing the voltages between the controllers were different.

I’ll confirm tomorrow once I make sure it’s properly serialized with uSB.

Please do note that the SSC-32U would be holding the TX line high at 5 V DC, therefore it is both and under voltage and an over voltage.

In TTL UART communication, each transmitter is responsible for holding the line to a “high” when idle (in most systems, anyways). Therefore the TX from the RPi would be at 3.3 V DC (therefore probably being misread by the SSC-32U as it is too low) and the SSC-32U’s TX would be at 5.0 V DC (and thus over the safety limit for the RPi’s RX line).

Hopefully this makes more sense now.

I personally use this product quite a bit for my own projects. It is cheap and it works great. Simple to setup and even supports bi-directional I2C (not all converters do). I recommend you look into that for when you wish to switch to UART instead of USB.

Please do note that the SSC-32U would be holding the TX line high at 5 V DC, therefore it is both and under voltage and an over voltage.

This is the great thing about Raspberry Pis. It will have a voltage regulator for GPIO to protect the board from overvoltage. I know there is an absolute limit to overvoltage. But generally, PWM and Pulse based signal processing do not use high voltage DC.

Let me get these PoC going. After. I will buy a few of those and then purchase this:

Of course, the Agent 390 will be used for a more serious industrial use case.

1 Like

I’m not sure how familiar you are with electronics, but I sense there might be some misunderstandings here.
First off, the over voltage issue is from the SSC-32U’s TX line (5 V DC) going into the RPi’s UART RX line. That GPIO would end up connected directly to it and would not like that one bit, no matter that it is powered at 3.3 V DC internally.
You can look at this post on the official forum for more details on how to protect pins from over voltage: https://www.raspberrypi.org/forums/viewtopic.php?t=76080

The secondary issue for GPIOs used as output pins (such as PWM and other digital pulses) is that they cannot provide much power. Therefore, it is usually best to opto-isolate them or add an amplifier between the GPIO output pin and the destination to provide the current required. Unless you are 100% certain of what you are doing circuit-wise, I’d refrain from connecting GPIOs to anything without either a reference circuit from a known - working - example or with some form of interface (such as opto-isolation) between the GPIO and its destination.

As a final note, a voltage regulator takes a voltage source on one end and provide a stable( r ) output at a fixed voltage (within specs) at the other, sometimes with support components and other times fully contained. It has no effect on protecting what is using it. At best, it may end up filtering some noise from the upstream power source (like a wall wart), but that’s about it. It cannot prevent overvoltage on devices powered by it (such as the RPi’s SoC and its GPIOs).

Sincerely,

1 Like

Wow, this is actually very informative.
This is actually also very important (for obvious reasons).

Thank you! I need to watch a few videos on this to understand it better.

1 Like

Maybe look at something like this: https://pimylifeup.com/raspberry-pi-gpio/
Seems like a decent guide.

1 Like