I need advice for designing an interactive art installation. Regarding communication protocol

Question

I'm a mechanical engineer with minimal electronics experience (yeah dangerous). I'd like to create an interactive art installation for my local community. I need help to find what direction I should focus my study on so I can pull this off.

The grand (and general) idea is to create an interactive display with up to 1000's of inputs (4-20ma or 0-10V sensors). These inputs are relayed back to a central controller and used to change a lighting and sound display. Each input location will have 2 to 3 types of sensors for different inputs. Criteria:

• time from input to display change should be perceived as instantaneous
• This is a DIY job without any real funding or chance of return on investment. So minimal costs.

My thought is that each "input location" has the 2 - 3 sensors connected to an Arduino Nano. Each Arduino Nano is connected to the closest one to it using a daisy chained Modbus RTU communication. That RTU communication comes back to a raspberry Pi (or similar) which is programmed for the display changes. The communication distance could be as great as 2000 ft. of wire in this daisy chain configuration.

I need the following suggestions:

• What is a better choice than the Arduino Nano? Is there a simpler option that is designed for RS485?
• Is Modbus RTU the right protocol to research? Or should I try to do this in a hub and spoke style design with a different protocol altogether?

Thanks for all the help. I look forward to seeing what kind of ideas are put forward. I'm always looking for a way to learn something new.

Answer 1

I think you are underestimating this project a bit, but it's a great learning opportunity!

However you only ask if RS-485 is suitable for this, and it can be.
When slow enough and properly driven using the right cables RS-485 can span distances. Careful with common mode if you have multiple power sources, you may need galvanic isolators.

RS-485 cannot be run in passive star-topology, you will need active hubs for that.
It competes with CAN bus, which also can't run star. But depending on other application constraints this may be more suitable. (they are electrically similar)

The protocol used is up to you, modbus-rtu is single master so your RPI will have to ask every node for it's status. However it's relatively lightweight and can run on your suggested Arduino Nano for example. (given proper software)

CAN bus could make it slightly easier for the embedded software where each node just yells it's status whenever there is free time on the bus, it will also defer some other error checking and repeats to hardware. I would use CAN bus.
Proprietary can-usb tranceivers may be required. (eg: kvaser)

Regardless of choice, each node would need some address/id offset, for example with dipswitches or solder jumpers.

Another protocol can be ethernet or wifi. It raises the cost of the initial modules, but you will not have to implement your own transceivers and protocols. You could use an ESP32 based Arduino board for example, with properly setup dedicated WiFi AP's this can save a lot of cable, and cable is expensive.

Since it's artwork, it doesn't sound critical.

Jeff Geerling has blogpost setting up one of mr beasts game show setups, learn from his difficulties.

Answer 2

Somebody mentioned DMX512, which is intended for distributing data from a central point to many destinations (typically stage lighting instruments).

But given the general physical robustness of DMX512 equipment and cables, that got my imagination going about a possible "reverse-DMX512" protocol. The general idea is that you would daisy-chain nodes using their UART ports, and each node would append its data on the fly to a growing DMX512 packet.

Suppose you use something like an ATtiny1616 MCU for the sensor nodes. Each one of these could accept up to 12 analog inputs, which it would turn into 12 bytes of 8-bit data (or 15 bytes of 10-bit data if you want the extra resolution). The links between these nodes would be point-to-point (i.e., separate input and output — RS-422 — not a physical bus like RS-485). Each node would listen for a DMX-512 packet on its input. When that occurs, it forwards the packet immediately and then appends its own data to it.

32 such nodes in each chain would produce 32 × 12 = 384 channels of sensor data at the last output (384 or 480 bytes). At 250 kbits/second, this could easily support a packet rate of 50 Hz or so (20 ms frame period). Eight such chains would support up to 3072 sensors altogether. So now you need 8 UART receivers to capture all of this data. These could be connected directly to the central controller, or an external concentrator box could collect this data and then forward it to the central controller. The aggregate data rate would be 50 × 3072 = 153600 channels (153.6 or 184.32 kbytes) per second.

A startup protocol is required to coordinate the nodes on each chain. The first node in each chain would have nothing connected to its UART input, which is what makes it unique. So at power-up, each node should send a packet and then listen on its input for an incoming packet for 2× the frame period (40 ms). If it receives nothing, it must be the first node on the chain, so then it just starts sending out packets at the frame rate. Otherwise, it just appends its data to incoming packets as described above.