Sending serial data to many Teensy boards at once.

Status
Not open for further replies.

ZackM

Member
Hi all,

I'm working on a concept that involves controlling an array of stepper motors (up to 100 in a 10x10 grid) at the same time. The idea is that a master controller (could be a pc or another teensy) would send a serial message to be received by a teensy at each of the motor locations and then each teensy would do something with the motor based on the message it receives (they all receive the same message). Messages from the master only get sent every few seconds or longer. The grid spacing is 12in so the master could be around 20 feet away from the farthest teensy.

I'm wondering how I can effectively get the message to all 100 teensy boards reliably and without much delay. Any thoughts would be greatly appreciated.
 
This looks like a perfect candidate for CANbus. Every node gets a message and it is multi master so they can all talk together

As for length, you can do a kilometer if you want over 3 wire UTP :)
 
Did a something similar a long time ago and implemented a half-duplex RS-485 network with a max487 transceiver for every microcontroller.
The total length of the chain was about 30-40 meters
 
What Teensy is in use? Seems like messages would be short - a dozen bytes - or is there a unique 4-8 bytes of data for each Teensy in the 100 ?
With a few seconds between messages - how far in advance is the next command known?
Seems the data only goes one way? The slave Teensy never sends anything upstream?
With UART Serial distance and noise could limit connectivity - First Teensy could tell 2 others 1 foot away to propagate through the group. Cascades from :: 1>2>4>8>16>32>{last 36}
That would take 3 Uart ports and pins.
1 or 2 M Baud working would transmit 100* 8bytes * 10 bits in 8 ms or less ( at 1 M Baud ) - then data reduced by half to the next pass would take 6 transfer times - worst case would be 60 ms with 6 passes/hops of <10 ms to propagate?
How critical is timing? Would have to get a common clock/time base to base.
 
What Teensy is in use? Seems like messages would be short - a dozen bytes - or is there a unique 4-8 bytes of data for each Teensy in the 100 ?
With a few seconds between messages - how far in advance is the next command known?
Seems the data only goes one way? The slave Teensy never sends anything upstream?
With UART Serial distance and noise could limit connectivity - First Teensy could tell 2 others 1 foot away to propagate through the group. Cascades from :: 1>2>4>8>16>32>{last 36}
That would take 3 Uart ports and pins.
1 or 2 M Baud working would transmit 100* 8bytes * 10 bits in 8 ms or less ( at 1 M Baud ) - then data reduced by half to the next pass would take 6 transfer times - worst case would be 60 ms with 6 passes/hops of <10 ms to propagate?
How critical is timing? Would have to get a common clock/time base to base.

I've purchased a few Teensy 4.0s for testing, but nothing is set in stone with regards to which one will be used in the final build. Whatever will work, I suppose.

The messages will be fairly long. It will be a string of values with an ID tag for each value. Each of the nodes will have an ID that is set with a pair of rotary dip switches and will only use the value associated with their own ID.

The commands are sent as they're needed depending on various modes of interaction.

Data is one way. The nodes only ever receive, never send.

Timing is pretty critical because the intent is to create a dynamic visual through the motion of the motors. The cascade method you've described was my initial instinct, but I wasn't sure how reliable or fast it would be, and I thought the wiring might get a little convoluted.
 
Did a something similar a long time ago and implemented a half-duplex RS-485 network with a max487 transceiver for every microcontroller.
The total length of the chain was about 30-40 meters

From a physical wiring standpoint how does this work? Does each microcontroller have an input and an output that just get daisy chained from cell to cell? Is there a preferred connection/wire type?
 
Daisy chaining will work but is fault tolerant. If one node drops, you cut off a segment of the network. In canbus all nodes are wired in parallel, and if one goes offline, all other nodes remain working as programmed

Define critical? How much data? What type of speeds?
 
Daisy chaining will work but is fault tolerant. If one node drops, you cut off a segment of the network. In canbus all nodes are wired in parallel, and if one goes offline, all other nodes remain working as programmed

Define critical? How much data? What type of speeds?

If the pins for the input and output are connected to each other then the signal will just bypass the node if it goes bad, right? I'm thinking about it from a wire management standpoint. I'd prefer to have short runs from cell to cell rather than long runs back to a central hub.

I'll define critical as 10ish milliseconds, but it's difficult to say for sure. Up to a KB of data per message.
 
Data is one way. The nodes only ever receive, never send.

Timing is pretty critical because the intent is to create a dynamic visual through the motion of the motors. The cascade method you've described was my initial instinct, but I wasn't sure how reliable or fast it would be, and I thought the wiring might get a little convoluted.

Well, that would allow to just connect the UART RX pins to one TX pin. This could be done with TX to 10 MAX3232 TX drivers (5 chips containing 2 TX drivers each) and each output connected to the 10 MAX3232 receivers of 10 controllers. The MAX3232 driver output is strong enough to bridge longer cable distance and to feed 10 inputs.
An other approach could be TORX optical receiver on each controller and the complete fiber bundle connected to a LED with a strong driver.

Then all endpoints receive the same message at the same time.
 
A more Arduino-like optuion could be to use a SN65HVD230 on each slave node and on the master.
These could be connected as star or line topology. If you do not use CAN functionality, tie Rs to GND on the master and to 3v3 on the slave units. This would allow a very flexible wiring and still provide the same message at the same time to all slaves. Just be sure to terminate each line.
 
So if I go the RS485 route, can I start testing with a USB to RS485 from my computer to a RS485 to UART at my microcontroller? Does the connection from the RS485 transmitter to the RS485 receiver need to include a ground wire?
 
So if I go the RS485 route, can I start testing with a USB to RS485 from my computer to a RS485 to UART at my microcontroller? Does the connection from the RS485 transmitter to the RS485 receiver need to include a ground wire?
No ground wire needed. Just 2 wires.
From a physical wiring standpoint how does this work? Does each microcontroller have an input and an output that just get daisy chained from cell to cell? Is there a preferred connection/wire type?
All RS485 nodes are wired in parallel. As for the wire, I used ordinary hook up wire.
If the pins for the input and output are connected to each other then the signal will just bypass the node if it goes bad, right? I'm thinking about it from a wire management standpoint. I'd prefer to have short runs from cell to cell rather than long runs back to a central hub.
Yes, you basically run the 2 wires from node to node.
I'll define critical as 10ish milliseconds, but it's difficult to say for sure. Up to a KB of data per message.
Both SN65HVD82 and max487 have a max data rate of 250kbps which is rather slow but makes them less prone to interference and cabling problems.
If I used the SN65HVD82 I would need to use a Teensy that has 5v tolerant serial pins, correct?
Not necessarily, you can interface your 3v teensy to the 5V transceiver with a Schottky diode and a resistor.
Have a look at paragraph 9.1.5 of the datasheet.
http://www.ti.com/lit/ds/symlink/sn65hvd82.pdf
 
Generally speaking, do the RS485 transceivers connect directly to the 3.3v/GND/Tx/Rx pins on the Teensy and the A/B wires from the master, or are there other components that need to be integrated to make it function properly (resistors/capacitors/diodes,etc)?
 
Here a link to about 5000 rs485 receivers/drivers. https://octopart.com/electronic-parts/integrated-circuits-ics/interface-ics/rs-232-rs-422-rs-485-interface-ics

The table is very well organized, you can filter by the properties you need (Voltage, transmission speed, availability in your part of the world etc.) Open one of the attached datasheets and read. Most of them have very detailed information about suggested bus topology, requirements for termination, schematics driving capabilities etc. Or wait, if you are lucky somebody is doing that work for you....
 
Generally speaking, do the RS485 transceivers connect directly to the 3.3v/GND/Tx/Rx pins on the Teensy and the A/B wires from the master, or are there other components that need to be integrated to make it function properly (resistors/capacitors/diodes,etc)?
paragraph 9.1.5
With RS485 do I need to include an extra node at the end of the chain that has a termination resistor?

I don't want to sound rude but the answers to all those questions can be found in the datasheet linked in the third post by luni.

Anyways, I dug up the schematic and some pictures from the project I mentioned earlier. They might give you some hints.
semaphore_schematic.jpg
semaphore_01.jpg
semaphore_02.jpg
 
I don't want to sound rude but the answers to all those questions can be found in the datasheet linked in the third post by luni.

Not rude at all. I'm asking because the example layout in the datasheet shows the transceiver being complimented by a handful of other components, but I've come across images/sketches/videos of people using the transceivers without any compliment of components. As I'm not an Electrical Engineer, some of the language in the datasheet doesn't always make the usage cases perfectly clear for me. Ideally, that's why a place like this forum is particularly helpful. Communicating with real people that understand the technical details of these components and datasheets better than I do allows me to learn how to make more sense of the datasheets now and in the future. And thus far, the answers in this thread have been very helpful. At a minimum, I have some direction for focusing my research and testing, which is more than I had two days ago.
 
Status
Not open for further replies.
Back
Top