Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Serial protocols for realtime control/telemetry with many channels

Status
Not open for further replies.

mtwieg

Advanced Member level 6
Joined
Jan 20, 2011
Messages
3,835
Helped
1,310
Reputation
2,626
Reaction score
1,404
Trophy points
1,393
Activity points
29,363
Hypothetically, let's say that I want to exchange data with many slave devices (say 128 for example) every 100us. Exchanged data is 8 bytes in both direction per channel. All 128 transactions have to be complete within each 100us window. Range is short (10m at most from host to slaves), either fiber optic or wireless, but not copper cables. Point to point, daisy chain, whatever. What sort of serial/radio protocols are good for this?

I'm trying to stick to things for which I can find OEM modules which can interface to common MCU ports (SPI, USART, MAC, parallel, etc). I've looked into ethernet, wifi (802.11n/ac), pci over fiber, rs232, and more, but most of what I've found is aimed towards bulk data transfer, and don't give a clear idea of what to expect with such small packet sizes and number of channels.

Any feedback would be appreciated.
 

Hi,

128 slaves,
8 bytes
8 bits
Every 100us
= 8.192Mbit/s

Now you need some additional bits and additional time...

Therefore daisy chaining is not an option I think.

Peer to peer Uarts...means that your master needs 128 Uarts...
The same is with I2C.

I doubt that WiFi or ethernet can handle this.

I have no solution.

Klaus
 

Having a separate serial port for each channel (or a group of channels) actually may not be out of the question.

The overall baud rate is well within the spec of ethernet and 802.11n. A mininum packet size for ethernet is 72 bytes (including preamble) plus 12 bytes of interpacket gap. For gigabit ethernet, that's less than 1us. But I'm worried that my MAC will be a bottleneck when sweeping through every channel.
 

You might want to take a look at latest CAN protocol implementations. About five years ago I utilized a CAN implementation over Bluetooth, I realize BT does not offer the throughput need to your specifications, however I seem to remember coming across CAN protocol implementations over other higher bandwidth wireless. During the five years that has passed, who knows what is available, the size of packet and lower overhead of the CAN protocol might be ideal for your task.


BigDog
 

Whatever the solution you chose for the physical layer, the most restrictive detail in this layout is the synchronization between all these devices in order to avoid collision and data loss, so that a simple system with neither resending protocol or local buffer for output, wont work; but this solution by itself would kill the implicit requirement to have a real-time reading. Better you consider the master receiving data from each channel upon its own request instead of having to deal with a huge unsynced data srtream.
 

Whatever the solution you chose for the physical layer, the most restrictive detail in this layout is the synchronization between all these devices in order to avoid collision and data loss, so that a simple system with neither resending protocol or local buffer for output, wont work; but this solution by itself would kill the implicit requirement to have a real-time reading. Better you consider the master receiving data from each channel upon its own request instead of having to deal with a huge unsynced data srtream.
If I were to combine a large number of channels onto one PHY, then yes I would likely use some sort of scheduled communication scheme to avoid collision. Or make it so that the slaves only send data when asked by the master. That's one of my concerns with an ethernet implementation. Is there such a way to implement such behavior with normal ethernet ports/modules?
 

Or make it so that the slaves only send data when asked by the master. That's one of my concerns with an ethernet implementation. Is there such a way to implement such behavior with normal ethernet ports/modules?

The amount of connected devices is quite restrictive, even with a 'lighter' protocol such as the UDP for example (with which losses would not be handled), considering antennas at different positions at locations with more or less obstacles, it would not be unlikely that consecutive requests would have the response sent to the same time therefore having colision. Your timing requirement is something that gives you little room for maneuver. Here, very close to my Wifi router, I can PING ( which is a even lighter protocol ) running with 54Mbps and it took 3-4ms, having only my Laptop connected. You have specified 0,1ms for each one of all 128 devices. I would say it is not feasible with the 802.11 standard wireless. Better to thing about a lightweighter communication standard with less runtime overhead, or even change your reuirements.
 

The best protocols for globalized transmission and its peripheral included in microcontroller is I2C and CAN
Both of these protocols support general call, which means every devices connected to the bus must listen to the data.
But make sure that the number of slaves / devices supports your application

UART is not recommended for point to multi-point communication unless ypu were sure about impedance matching of the communication lines, obviously its nearly impossible to communicate to 128 devices.

But here is the good news, Since you are not going to communicate with a hard wire you can some other options.

I can suggest Beaconing protocols.
One best thing you can afford is Bluetooth Beacon. You can use your microcontroller's UART port to communicate to the Beacon peripheral
 

Hi,

The best protocols for globalized transmission and its peripheral included in microcontroller is I2C and CAN
I2C is absolutely not suitable.
Because of:
* limited count of devices
* limited bus load
* limited bus length
* speed (I doubt it safely can manage the data transfer for just one slave)

***
UART is not recommended for point to multi-point communication unless ypu were sure about impedance matching of the communication lines, obviously its nearly impossible to communicate to 128 devices.
UART is only a part of an interface. It doesn´t tell what signals levels to use.
UART in combination with RS422/RS485 is used many times in the industry.
Profibus for example.
A UART based interface is way more suitable than I2C for this application. But you need several interfaces to handle the ammount of data.

****
I don´t have a soultion, but i think about a full duplex soultion. Maybe SPI style but with RS485 signal lines.
* Hardware addressing (CS) is faster then addressing via protocol (can be single ended)
* all slaves may be to connected to a single MOSI data pair
* all slaves may be to connected to a single MISO data pair
* all slaves may be to connected to a single SCK clock pair
* only the addressed slave enables it´s RS485 driver (MISO)
* transmit of 8 bytes of data takes place in parallel to receive 8 bytes of data. (full duplex, no data overhead = data efficient)

But even with this topolgy I doubt that this is a useful solution because of the high effort in wiring - especially the 128 individual CS lines.

Klaus
 

The amount of connected devices is quite restrictive, even with a 'lighter' protocol such as the UDP for example (with which losses would not be handled), considering antennas at different positions at locations with more or less obstacles, it would not be unlikely that consecutive requests would have the response sent to the same time therefore having colision. Your timing requirement is something that gives you little room for maneuver. Here, very close to my Wifi router, I can PING ( which is a even lighter protocol ) running with 54Mbps and it took 3-4ms, having only my Laptop connected. You have specified 0,1ms for each one of all 128 devices. I would say it is not feasible with the 802.11 standard wireless. Better to thing about a lightweighter communication standard with less runtime overhead, or even change your reuirements.
I assume that the vast majority of that ping is in your OS, and in the TCP stack. For our implementation the slaves will be MCUs (which will devote most of their resources to keeping communication latency low as possible) and the master will be a custom pxie module with the necessary transceivers, again devoting all resources to communications.

I agree though that standard wifi probably isn't feasible at that spec. What about 80 bytes every 1ms? Or 800 bytes every 10ms?
 

What about 80 bytes every 1ms? Or 800 bytes every 10ms?

For each one of the 128 slaves ? As said, the speed by itself is not the main issue, but rather the time allocation for each transmission of all devices.
 

For each one of the 128 slaves ? As said, the speed by itself is not the main issue, but rather the time allocation for each transmission of all devices.
Right, and by using larger packets less frequently, I should reduce overhead for channel switching. I'd be shocked if 10ms isn't enough with optimized MAC drivers.

- - - Updated - - -

UART is only a part of an interface. It doesn´t tell what signals levels to use.
UART in combination with RS422/RS485 is used many times in the industry.
Profibus for example.
A UART based interface is way more suitable than I2C for this application. But you need several interfaces to handle the ammount of data.
Glad you drew my attention to Profibus, it's at least good to see that there are some good industrial control protocols which can be implemented with UART and still get decent speed.

This also led me to reading about Profinet IRT and Ethercat, which both sound like excellent candidates, except that they require ASICs which would cost around the same as my MCU...
****
I don´t have a soultion, but i think about a full duplex soultion. Maybe SPI style but with RS485 signal lines.
* Hardware addressing (CS) is faster then addressing via protocol (can be single ended)
* all slaves may be to connected to a single MOSI data pair
* all slaves may be to connected to a single MISO data pair
* all slaves may be to connected to a single SCK clock pair
* only the addressed slave enables it´s RS485 driver (MISO)
* transmit of 8 bytes of data takes place in parallel to receive 8 bytes of data. (full duplex, no data overhead = data efficient)

But even with this topolgy I doubt that this is a useful solution because of the high effort in wiring - especially the 128 individual CS lines.

Klaus
Using SPI would definitely be too much wiring. If I could use copper interconnects, a large number of RS485 busses (maybe Profibus) with 4-8 slaves each would likely work okay. But with fiber, I might as well use a protocol with full duplex (not Profibus).
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top