Communicating microcontrollers over bell wire

Question

I found some old wiring in my house I want to put to new use. In the cable there are four bell wires and it runs in the wall along the full height of the house. For me (utter non-expert) the cable could be similar to CAT3 cables.

I had the idea that I could use two of these wires to provide 3.3V and use the other two for interconnect. From end to end the cable is about 30 meters.

Is there some kind of easy to obtain and implement communication technology I can use?

I only have theoretic knowledge and I mostly only know Ethernet. In theory 10 and 100 MBit Ethernet do use CSMA/CD and have a half-duplex mode of operations which only requires one circuit, i.e. 2 wires, to work.

In a "sophisticated" setup there would be a central hub and each device would be directly connected to that hub. As the hub has no intelligence whatsoever, it might be possible to forget about the hub and just use one wire to connect all pin1 and use the other wire to connect all pin2, effectively creating a bus. I guess I have to solder some resistors at the ends, but this is definitely the least problem of the whole idea. With all the intelligence in the endpoints a working Ethernet seems possible.

There are 10Base2 and 10Base5. I would look at something like 10BaseBell. Of course outside of every standard and it would not quite perform as well as 10Base2. But can it work? Has anybody ever tried and documented things like this with recent microcontrollers that have a 10/100 Ethernet interface?

Or is there something else ready to use over these poor wires? This would be just some fun free time project, so no real requirements, yet a working TCP connection between a few microcontrollers would be awesome!

I don't even know if this is the correct site for such an idea but I figured people with knowledge about electrical engineering could know such things ...

Answer 1

Modern-day Ethernet, as you are correct in suspecting, is designed for structured networks, not hanging random devices off random runs of cable -- the XBaseT family of physical layers are point-to-point, with all the collision detection done in a central hub IC (or not, if you have a switched network, which is the norm these days). Given that you aren't trying to go all that fast, however, other physical layers designed for multidrop applications are much more practical for your application.

Two in particular stand out from the rest: the Controller Area Network (CAN) and RS-485. They use differential data transmission (somewhat like modern Ethernet), but are multidrop (unlike twisted-pair Ethernet), and can support modest data rates (100kBits/s to 1MBit/s or more) over long cables (30m is no sweat for either one).

However, RS-485 is only a physical layer (transceiver specification) that leaves users to provide their own data-link layer (such as a special UART with some extra features), while CAN provides the data-link layer as well -- a wide variety of microcontrollers can be found with onboard CAN support (everything from ATmega parts such as the AT90CAN32 related to the Arduino's ATmega328 up to beefy 32-bit ARMs using Cortex-M4 or M7 cores, as well as automotive Systems on Chip with integrated CAN controllers), and standalone CAN controller ICs are available as well (the MCP2515 is one that is designed for simple microcontroller interfacing).

Furthermore, IP over CAN is possible and documented, and CAN cards are available for PCs (including Linux support, although it looks like if you want to do IP over CAN on Linux, you'll have to do a bit of kernel plumbing).

Last but not least, CAN generally is done using 3 wires -- two differential data lines, and a common ground to all nodes. Isolation is accomplished at each node using optocouplers or digital isolators between the CAN transceiver and the CAN controller. You can use the fourth wire to run say 12 or 24V power if desired, although I wouldn't run more than an amp over it.