how to control 30 servos with long cables? SSc32u

Hello. I’m a tech artist and I’m trying to make bigger installations. I am looking for help to be able to handle 30 mg996r servos at a great distance. As the picture shows, they would be long cables. I have calculated and they are 7 and 4 meters. I have done tests with ssc32u and with 7 long cable servos it starts to fail.

What do you think is the solution? use more ssc32u and distribute the amps? the supply i am using is a 600w atx with 5v just out connected to vs, vl and vl1 (no jumpers). another solution can be to feed the servos independently and from ssc only pwm?

I hope you can help me. Thank you

Image does not show up.

However, just based on the text of what you describe, a far better approach is to use a single long transmission cable from the host device to the SSC32U that is located near the servos, running multiple long lengths of servo cables. Or just use a BlueTooth Bee at each end, if the total distance is within 10 meters. If the total distance is greater then 10 meters, then use RF transeavers instead of a bluetooth connection.

Since the SSC32U is a small interface card, it can very easily be stashed and hidden within a base place or mounted in an out of the way location.

The reason for the relocation and the shorter wires is, “Electronic Impedance”. In very basic terms it means that the longer the length of copper that electrons have to travel thru a wire, the more resistance they encounter along the way. Servo cables are just copper wire, and the control signal that travels thru the wire are just pulses of electricity in a very fast pattern. Every wire has impedance and is one reason circuit traces on PCBs tend to be as short as possible, between one component and another. The longer the distance, the more impedance, until there comes a point where total signal loss occurs. So having long lengths of wires from a servo controller to the actual servo introduces more and more signal loss, the longer the pulse has to travel. At the atoms level, billions of free electrons are changing places with electrons of the copper (aka current is flowing with each pulse). If there are more copper electrons then free electrons, the free ones get attached and trapped by copper atoms and do not have enough energy to push another electron off to travel to the next atom, along the way. Think of it as a Relay Race where a runner (copper atom) is handing off the baton (a free electron) to another runner (next copper atom). The electrons do not flow like water, they in a sense, enter the area of the copper atom and it grabs the free electron but since it then has one too many electrons, the electron with the most amount of energy breaks free, on to then be snagged by the next copper atom. And so on and so on, down the line. Now with each breakaway to freedom, that electron looses a bit of energy (which converts to heat) and after awhile, one very long lengths of wire, there is no longer enough available energy (free electrons) and there is no signal or voltage at the other end…or if there is, it is sporadic and unreliable. Also known as dropouts or brownouts.

So, to correct this you have to boost the energy at times along the way, such as with every 15 feet of USB cable, you have to have a power adapter or that signal is impeded into an unreliable signal. OR, you adjust the overall design and use one signal wire for the longer length, relocate the SSC32U near the servos where Impedance is no long a factor and you only have to deal with one instance of signal wire if its a hardwire setup, or if BT/RF, the distance each is capable of traversing without signal degradation.

So based on what you described in text, the relocation of the servo controller board over to the servers would be the better option and just manage the TX/RX pair signal wire from the host device to the SSC32U.

Here at Acigan, our design rule is less wire as possible, so based on that, and the total distance from host to controller, it would be Bluetooth if < 10m or RF if > 10m, then WiFi, then 5G. The only wires would be from the SSC32U to the servos themselves, and even then, as short as possible within the design, and hide the controller or integrate it into the overall visual design.

Hope this helps!

Acigan International
Research and Design Division

Thank you very much. I will try the following; Each 5 servos one ssc32 with independent power supply (transformer at 5v), This will be a module, I will use 5 equal modules and distributed around the rapu. The control signal comes from a rapu (brookshire soft. The signal cable can be 4 meters) will it lose strength? Would it work if I make 4 branched cables that emit the same signal to different ssc32? rapu rs232 output. Thanks for your help

The guidelines established by paragraph 3.1 of the RS-232-C standard recommends limiting the cable length to 50 feet or less (15.24 meters). The standard does allow the cable length to exceed 50 feet, provided that its total capacitance is less than 2500 pF. No specific cable construction type is recommended in the EIA specification.

Based on the standard as described, the 4 meters (13.1234 feet) would be within spec.

RS232 can not be “branched” without the use of a multiplexer if you are referring to just connecting all the wire pairs together. However, if there are enough free ports at the Rapu host, and each signal line is addressed independently (the Rapu is multiplexing) then all should be fine.

Alternatively, if there are not enough free ports at the Rapu host to control all the RS232 lines, but it has 1 RS232 port and 3 available pins free. This multiplexer would work:

The using the 3 pins as HIGH or LOW, you control which of the eight serial ports on the multiplexer is to receive the single signal being issued from the host comm port. The multiplexer then routes that signal to the device attached to the selected port. So you would have up to eight comm ports at the target location but only 5 wires running from the Rapu host to the target location. TX, RX, ADDR1, ADDR2, ADDR3. The multiplexer would be close to the SSC32 array, not the host, so that those signal lines remain short, from it to each SSC and the servo lines from each SSC to the servos. Only the Host to the multiplexer lines are the long ones.

Understand?

Also, be very clear as to RS232 or TTL. Both are commonly called Serial Ports since they use the Serial Protocol, but there are voltage differences between them. True RS232 is 12v signals. TTL serial is 5v.

If the 4 meter signal line is to be true RS232, there will need to be a RS232-to-TTL converter just in front of the multiplexer. It is a TTL device and true RS232 at 12v will fry it.

Always be very clear in using the term RS232 because of the generic way that the term “serial communications port” is used.

Thank you very much for your recommendations, unfortunately in the link you send me the product is not available, I have looked for where to buy it and I cannot find any online store that sells it. Do you think that with this multiplexer I could solve it?

Thanks for the help!!

No. That is a multiplexer for the I2C bus, not the UART bus.
Amazon does sell them but may be filtering the item based on your location.

Use the direct link to the company website.

on the site, click the SEARCH icon and type in EXPANDER and press enter.
The multiplexer will show up.
Saves ya from searching thru all of their other devices manually, unless you are into that kinda thing.

To give an example of how here at Acigan this exact expander is used —

Prototype Platform C.1, nickname Charr Unum
ESP32 WRover B sends command to SSC32U to set the A/B/C pins on or off. These are connected to the multiplexer address lines. The uProcessor has the UART-1 port wired to the device. At plexer adderss 1 is a GD3300B voice module. At multiplexer address 2 is a sonic ranger, wired for continuous poling and range output to the UART.

When the AIUnit needs to say something, the uProcessor flips the address to 1, and outputs it thru UART-1 of the ESP32. If the AIUnit reguires a realtime ranging reading, it flips the address to 2 and reads the data at the very same UART-1 comm port. Since the ultra sonic ranger is in automatic it is always sending the realtime data out its comm port, but the port is only seen when the address is 2. There is no polling or issuing of commands, it just toggles to port 2 and reads the data when done it flips the multiplexer to 0. There is nothing attached to that port on this prototype. It is used to ensure there is not data flowing into the ESP32 that is not wanted. The voice module also has data feedback that can be queried and polled. So by using one of the ports on the multiplexer as a blank one, it is just an assurance there is no unwanted data in or outbound that is not wanted. There is also an ENABLE address for the same purpose. It would require another signal line and connection but the zero address trick also works and saves adding another wire.

You would be doing a similar toggle of the address so that you can select exactly which SSC board you want to address using pins and the Address Control Lines shown in the diagram posted earlier instead of how the addressing to the multiplexer is being done on the Acigan prototype Charr Unum. She is wired differently because our host is remote and she is autonomous, so she controls all her own addressing of the multiplexer onboard her platform.

Hopefully this explanation how the multiplexer is to be controlled with the addressing will provide you with an idea of how to wire your setup up and then control it.

Acigan International
Development Division

Thank you for your comment and help, honestly I am not a programmer and I cannot achieve this solution that you give me… thank you very much for your help.

On the other hand, I have managed to multiplex the rs232 signal by branching the cables (similar to a multiple socket) and it works for the control of 2 units of ssc32. I think that since ssc32 does not send anything through rs232, it only receives a signal… it sends both ssc32

musku,

To be blatantly honest here, the manor of your connections will never work. As stated previously, RS232 can not be connected together in the manor you are doing. Here is the technical reason why —

The TX and RX lines produce HIGH and LOW signals. When the TX goes HIGH, the RX line sees the change and starts to read in a bit, not a Byte, a BIT. It takes eight bits to make up a single byte of data. So when you group them together what happens is that one or two see the bit within the window of time the TX has the line held HIGH, but there is a very good chance that not all of the RX’s in the group see the line being held high. Reason is, the RX side of things is being controlled by its own system clock, not the clock on the TX device. So when the timeslice ends at the RX side, the line is then pulled LOW and that may not be the proper time, meaning not all of the bits are in the buffer. Only some of them. The buffer is then “completed” with zero bits instead, because the line is now LOW and a low line is 0, not a 1. So what happens is the TX is sending, lets say 11111111 and one of the devices sees 11100000 and another sees 00001111 and another sees 1001001x meaning x is not a 1 or a 0, its a ERR in the data stream.

Because both the TX device and the RX devices controls their own clocks, there will not be a point where all the clock ticks are in perfect sync. In addition to just the TX and RX lines, there are also the CTS and RTS lines toggling HIGH and LOW. Those lines are Clear To Send and Request To Send. So now you have multiple RX devices all toggling those two lines HIGH and LOW because each device is indicating it is ready to receive data…all at different times.

This is the reason for Multiplexer Devices. So that each receiving device can be selected, the TX sends the bits, the RX receives all the 8 bits, makes the Byte or Bytes and places them in the Receive Data queue. Then when transmission is complete, the next device on the multiplexer is selected and TX then does the same thing. If all the receiving devices are to have the same data at the same time, the TX device transmits it N-Number of times that there are Receiving Devices. Meaning if there are 5 SSC cards to act in unison, then the TX Data is sent to the first, switch, send to second, switch, send to third, switch, send to fourth, switch, send to fifth. Since the speeds are faster then humans can perceive, it appears to us that all five are working simultaneously, but in reality, they are just a few nano or micro seconds difference between them. You will see an actual delay if a lot of devices are multiplex together where it requires more then a second to send the exact same data to all of them.

RS232 does not function like a Power Rail, where you can plug in things and they all draw current at the same time.

In your post you indicated that it seems to work, then stops. The reason for this is all the different system clocks are ticking at different nanoseconds, and not in unison.

So No, you can not group the signal lines. you have to multiplex them and address each device separately and ensure that no other device is “hearing” the signal at the same time. To come onto any Forum and request assistance and then reject the freely given assistance from people that deal with IT everyday and understand how things work, and do what you think may work without knowing something such as the RS232 Protocol in how devices communicate, is not the way a forum operates.

When a person elects to take on a Project, they need to first understand each of the smaller tasks that make up the greater whole of the Project. If they dont, they can ask the advise of others that are willing to assist, but to then ignore that assistance and do it in a manor that violates standards, or protocols or even basic electronics, they should not be taking on projects.

In your case, you can not hub out RS232 signals in a group connections. They can be in a hub, yes, but the center of the hub would have five different Comm Ports or one comm port and a multiplexer somewhere in the design to select each receiving device…if not, the hub will never function, because the RS232 Protocol does NOT function in that manor.

With that all being said, Good Luck on your project and please do not ask for any more assistance on it since the manor in which you are connecting is flawed, according to RS232 Standards, and there is nothing anyone can do for you if you do not want to listen to HOW to connect your devices up correctly. This has nothing to do with “programming”. This is just how RS232 functions.

Acigan International.

musku,

Here is a publication that explains the protocol being referred to. About midway down the page you will see that the number of total Master Devices is one, and the total number of Slave Devices is also just one. The only means of communicating with more then one slave device under the protocol standards is to trick it, using a multiplexer device that is flipping the signal lines between all the slave devices, but at the multiplexer it is still a single slave. The multiplexer just picks which of the single slaves it is to route the signals to. But it is still a single transmission to the slave device.

So in order to do what you desire for your Project, a multiplexer is required for the RS232. Period. Because the Protocol Specification are not going to change for your project.

Read the publication so you have a better understanding.

UART: A Hardware Communication Protocol Understanding Universal Asynchronous Receiver/Transmitter | Analog Devices.

Acigan International

Here at Acigan, it is pretty clear as to what your Project is based on everything we do for Clients.
But on a wild guess, let’s just go with it being a Laser Controller for Rave Parties.
This is based on the RAPU and the setup desired.
So based on that, here is a non-Programmer-DJ-Way of implementing.

Obtain the Multiplexer that was posted. Obtain 3 toggle switches, one battery case that holds 3 AA batteries. Wire the batteries in Series, meaning they all touch one another back to back. This will produce 4.5 volts. That should be enough for the Address Lines. Or use a 5v adaptor. The purpose is to provide between 3v and 5v to the Multiplexer.

Install the switches and batteries into a small box.

To control which SSC the RAPU is to send the Sequencer to, you toggle the switches on or off to generate a binary number at the Multiplexer ADDR connections, between 0 to 7. This gives you up to 8 SSCs that can be controlled.

As each SSC receives its Sequence command, you toggle the switches on or off in order to flip to the next SSC to control. No programming involved. The DJ would be controlling them manually.

Understand?

Greetings Acigan, first of all I would like to apologize to you if my procedure bothered you. You have been very attentive and patient with me and you have taken the time to explain things to me, something that I am very grateful for, I did not mean to disrespect you and I ask you for my most sincere apologies. I have acquired the multiplexer that you recommended and I will make the connections as you say, I am very sorry that my experiment bothered you, I am sincerely sorry. I don’t want to leave the forum and I want to continue learning from people like you. I hope that we can continue to move forward after this small inconvenience, it affected me a lot to read your annoyance and I did not want to get angry after your help, attention and patience explaining how to connect correctly, it is important for me since it is expanding my knowledge with altruistic people like you. Once again I apologize and I hope we can continue chatting. A hug

Altruistic? Now that is one word that has never been said in this direction before. There has been many words and phrases aimed in this direction both verbally and in written form but that adjective was never one of them. So thank you for the compliment.

Something to always keep in mind when reading posts or chat is that it lacks the tone of the party sending it. One reads the words and the mind tries to fill in the gaps with something that if feels is lacking, based on how humans communicate. With that being said, there was not any annoyance or disrespect taken. Nor was any “bother” or inconvenience perceived from this side of the conversation. In fact, if some of the written word hit a nerve with you, it was meant as such. Meaning, you can not change the way some things work in physics or electronics. By that, the Protocol Standard for RS232 is set in stone in devices over all the years it has been implemented. Sure, it has its drawbacks, but on the flip side, it is an established method to make two devices communicate with each other. The protocol was designed way back in the day when just getting one device to communicate to another was magic. That is the reason for the Master/Slave relationship embedded in the Protocol. That was later expanded on by the use of the CTS/RTS lines (two more signals) so that bi-directional communications could be performed from either end simply by each device notifying each other via the Clear To Send and Request To Send signals back and forth. There are also CTS and RTS bytes that can transmitted, so the expanded functionality could be implemented via software at both ends, when it was not feasible to run a second pair of wires again, over extended distances. That is the purpose of the ASCII values below Decimal 30, they are the software versions of the control signals, with CTS and RTS taking on defined values to notify the other end when data is safe to be transported across the TX and RX lines. This then pseudo-removed the hardware limitations of a Master/Slave relationship, and permitted either end to be the Master or Slave device, as long as both ends understood their roles at the time. But the point being, it was still a dual-role-Master-Slave relationship, since the Protocol specs are set in stone for it.

As technology progressed, and Users demanded more and more devices to communicate then just one, the transmission speeds increased and the invention of the Multiplexer came about, not to change all the hardware that was already created and running, but to enhance it to meet the demands of Users. The multiplexers sits in front of the Masters/Slaves and act as gatekeepers as to who is getting this packet of data, since that packet only is for one Slave. So the multiplexer is the new Slave device, the Master is unaware, and the signal lines are flipped to route to the actual slave device.

In your case, it is one Master, the RAPU and multiple Slaves, the older SSC cards. So a Multiplexer is inserted in the signal path between the single Master/Slave relationship to fool (expand) the Protocol and the Master still has one Slave device (Multiplexer) and that device routes the signals to the real Slave (SSC) since the Specifications mandate there can only be a single Slave device. So the manual switches are just informing the Multiplexer which of the SSC cards to route the signal to, based on what Address is present at the three Address connections of the Multiplexer. It then logically flips its internal circuitry to route the single signal to that selected SSC.

Microcontrollers, even today are still doing the same thing, they can have built in multiplexers that control the UART ports and we as humans have come to believe they have multiple Comm Ports. Unless there is actual multiple UART hardware chips installed, they can not. There can be a single UART Port and a software multiplexer that is flipping the signal across all the different pins.

It is for this very reason that same microcontrollers ONLY permit transmissions using exact pins, where TX and RX are set in stone for that uProcessor. Its hardware is a single UART and it has no logical multiplexer that a programmer or OS can control.

So based on Technological History, that is not ever going to change for UART devices, one must either scrap the hardware for something more advanced, like the I2C Protocol for example, that does allow for multiple Slaves all wired together, or fool the Protocol into thinking there is just a single device at the other end, with that being the Multiplexer (slave) that the Master device is in communication with.

When you stated you did not have programming experience, the only other option is to control the multiplexer manually. That is what the hardwired switches will do. Since you are obtaining that multiplexer that was recommended, make sure you download and fully understand its manual in how to set the binary addresses to indicate which port to use. In the manual they list all the binary values and you will have to manually set each of the switches to ON or OFF in order to generate the binary number the device wants to see at the Address terminals. Microprocessors would be setting their Address Pins High or Low to do this, but since this will be manual, a human will be setting them to their proper states.

Here at Acigan, the device is used when Clients desire similar functionality of a single Master but multiple Slave devices on a UART port. It is a simple hardware device to implement and control and it also has built in LEDs on each of the 8 output ports to indicate exactly which port is currently active at the device. Just remember as a non-programmer, that there are 8 ports and they are addressed as 0 through 7 (binary) and not as 1 through 8 (human), and everything else will be managed between all the hardware devices.

Now if you placed any type of “tone” into any of the above text, that is on you. The text is just being presented in a format that is understandable to any that read it. It is not posted in any other way, shape or form and is a primary reason for in-person consultations performed with Acigan clients. Because only then can a human actual understand there is no other between-the-lines meanings when technical information is being shared or explained. If the person being explained to, feels otherwise, that is all on them. Tech data can be overwhelming at times and humans do not want to appear to other humans as inferior to each other. A human flaw for sure, but once you understand that anything presented to you, whether it is verbal in person, or in written form, and go with it, the better off as a human you yourself will become over time. As a human, one must make it a goal each and every day to learn something new, that they did not know before. Only then will we all together, grow and reach are true potential.

So if you have learned anything from this particular forum thread, good for you. You will wake up tomorrow, better then you did as a human, yesterday. This is why machines will never rule our world.

Acigan International