Best microcontroller electrical bus for high speed synchronized sampling from slaves

Question

I have an application which requires that I sample a dozen of sensors for each node and transmit the data to a master microcontroller in regular four second intervals. The surface area of the sensors for each node is one square metre with six adjacent nodes. What is the best electrical bus to use in such a case?

I have no experience with CAN. I have only used RS-485 in the past, so I am currently on a fence between these two. What are the advantages of CAN in such a setup over RS-485 and how involved is the hardware part?

Also, is there any other bus which is superior to both RS-485 and CAN for such a purpose?

I need to use fairly unobtrusive wiring in my application.

Answer 1

For a 0.25Hz sample rate, I think either bus should be fine. CAN has more "built in" features of message prioritization and arbitration and so on than RS-485. So you'd have a somewhat more complex but somewhat higher level protocol with CAN. The electrical signal and power supply requirements for wiring would be virtually identical for either case. You say "synchronized" sampling is required, but do not define what precision and accuracy and latency of "synchronization" is required.

If you had to have the sampling "simultaneous" within nanoseconds then you'd have some significant additional concerns relating to communications latency, wiring delays, etc. But I suspect that since you didn't define the requirement and are considering "relatively" low performance buses without mentioning any kind of triggering / clocking strobe for the sampling trigger, you may be happy enough with synchronization down to the level of several microseconds or longer. If that is the case either bus is probably potentially workable for you depending on the architecture of your system.

Do the nodes sample autonomously at the predetermined rate and sampling times? If so, that makes it easier so long as the sampling clocks on the nodes are maintained in sufficient synchronism. If the nodes each wait for a "sample now" command on the communications bus then you may want to consider what happens if the message reception is occasionally delayed or lost by one or more nodes. In such a case the synchronization of the sampling may be lost or the sampling point delayed.

How about the transmission order of the sampled data to the controller? If the nodes are sharing a common serial bus, one must send its result before the others, so there will be a chance for bus arbitration conflicts. Unless there are parallel independent buses going to each node, some nodes' data transmissions will be delayed by by virtue of being transmitted later than other nodes. How will the bus arbitration work? Will each node be polled in turn or speak in turn? How about message retransmission if acknowledgement is not received due to bus contention or transmission errors or other circumstances?

If the nodes have local clocks used to timestamp the sampling data and possibly determine the sampling times, how will the clock synchronization be maintained? So, you see, you end up with the same kinds of potential problems and potential solutions / architectures whatever bus you use. CAN provides some higher level protocol features to assist with structuring some aspects of bus contention, arbitration, prioritization, retransmission, error detection, etc. You can implement similar things in RS-485 with your own protocol. In the end the most important aspects of the communication network are the architectural decisions and requirements relating to things like fault tolerance, timing, synchronization, error detection, error handling, network design & wiring, etc.

One possibility you didn't mention is Ethernet which has been augmented in some embedded applications with PTP that helps to synchronize and timestamp events between distributed nodes. Typically the ICs and components are somewhat more expensive to implement Ethernet vs. CAN or RS-485, though that depends on your implementation choices, need for things like high levels of electrical isolation between the wiring and the nodes (possible with added circuitry in CAN, RS-485, or Ethernet, but only really expected as a baseline implementation approach in Ethernet). Ethernet gives you a possible standardized means to provide power to the nodes, though power is often run along with CAN or RS-485 too.

Answer 2

You mention serial comms and here are a pair of chips that work fine up to very high speed data rates. You don't have to put data thru at these high rates but you do need a minimum clock speed of 10MHz: -

It has ten digital inputs, then they are serialized for transmission over a high speed balanced twisted pair then the receiver (deserializer) has ten digital outputs that correspond to the ten inputs you fed into the serializer.

I've used these for combining sensor outputs several times and they work great for high speed and low speed jobs. Maxim do a pin-for-pin equaivalent but the transmitter does need a decent power reset or it doen't start up properly.

Without any fuss I've fed 10x 20Mbpsec serial data streams into the inputs and sent it down 25 metres of screened twisted pair. Deserialization was perfect and you get a recovered clock signal. XTALs at both ends don't need to be too tightly matched - I remember testing the setup with a signal generator at one end and we could vary the frequency about +/- 7% before the link broke. Cheap twisted pair (50 ohms) should be OK for a few metres but don't forget to terminate with 50R.

Do your sensors have serial data outputs? If not use ADCs with a serial output. If you require more IO then they also do larger ones but I've not used these larger ones so can't speak for them.