Simple Network – Will it Work?

[For The Popcorn]

I have a need to monitor several sensor nodes, all within a couple meters, with small polled data readings (a few bytes) at low sample rates.

Rather than implementing something like an RS-485 network, I think this simple network will work. Each sensor node will have a PIC18F micro. Each sensor node UART Tx line would be paralleled via tri-state buffers, and connected to the host Rx. The host Tx line would be connected in parallel with all the sensor node Rx lines.

The host would send a message "node 1 send data". Node 1 would enable its tri-state buffer, communicate as needed, and disable its buffer. Other nodes would respond when queried. No data is sent by a node until requested, so no data sync problems. The nodes only see data send by the host, so no need to strain through a large stream of data looking for commands, nor the possibility of misinterpreting data streams as a command. 9600 baud is fine for this app.

Any problems with this idea?

 

[Tony Stewart]

You have yet to define the ESD and latchup protection.

 

[danadak]

Cheap wireless network ?

ESP-MESH with ESP32 and ESP8266: Getting Started | Random Nerd Tutorials

Build a mesh network with ESP-MESH protocol using the ESP32 and ESP8266 NodeMCU boards. ESP-MESH allows multiple devices (nodes) to communicate with each other.

randomnerdtutorials.com

ESP-NOW: Receive Data from Multiple ESP8266 Boards (many-to-one) | Random Nerd Tutorials

Setup an ESP8266 NodeMCU board to receive data from multiple ESP8266 boards via ESP-NOW communication protocol (many-to-one configuration) with Arduino IDE.

randomnerdtutorials.com

Regards, Dana.

 

[For The Popcorn]

You have yet to define the ESD and latchup protection.

A buffer like SN74HCS126DR on all I/O lines should give me sufficient protection?

Cheap wireless network ?

Wireless doesn't really do much for me in this app, as I need to provide power to each node anyway, and all the nodes are close together.

 

[AnalogKid]

Any problems with this idea?

No.

There will be lotsa opinions about part selection, environment mitigation, power and ground management, programming techniques, completely different approaches, more complex methods, more expensive methods , , , , , . . . But -

The *idea* of a software controlled, polled data acquisition system with distributed node multiplexing is sound, and has been around for decades.

ak

 

[Pommie]

I vaguely remember that enableing the receiver automatically enabled the transmitter so tristating may not work. It was a long time ago so a little vague. Think I only wanted to receive and use the transmit pin for something else. Of course the chips are much more flexible now so you can probably switch the transmit pin to nowhere using PPS.

Mike.

 

[For The Popcorn]

I vaguely remember that enableing the receiver automatically enabled the transmitter so tristating may not work.

It may be possible to accomplish this in the PIC, but I'm going to use a separate tri-state buffer.

Actually, thanks to Tony Stewart 's comment, I'll use a quad buffer to get some degree of ESD protection and add a /RESET line from host to each node's /MCLR pin so I can reset all the nodes if they become unresponsive.

 

[rjenkinsgb]

A common similar but simpler method is just to "Diode /OR" all the TX pins - any device sending data will pull the host RX line low. One Schottky diode per node and a pull-up resistor.

However:
With the complexity you have in the drawing - extra driver IC & transmit control - you are already up to the complexity of RS422 or RS485, other than the link wires?
Using one of those standards gives you far better ESD protection and tolerance for wiring voltage drops and ground offsets.

If you are going to add ICs, I'd go with ones made for the job?

(And you can then use the same node design for remote ones in the future).

 

[Beau Schwabe]

From experience, word of advice ... implement some kind of CRC with your data packets. My particular favorite is MODBUS <-- just for the CRC implementation, not necessarily the protocol

 

[Nigel Goodwin]

An even simpler system would be PICAXE from Dontronics (Don McKenzie) - NOT the later PICAXE which was a PIC containing a BASIC interpreter, but Don's original one.

You simply daisy chained the serial ports together, and sent packets of data, with each packet having an address, and each PIC having it's own unique address. So the first PIC received the data, checked the address, and if wasn't the correct address passed it on the next PIC - which did the same. Once a PIC found it's own address, it processes the command, and doesn't pass it on.

To send a reply it simply sends a command with the address of the host controller.

An obvious issue is if the chain is broken, but that applies to any system really.

Just another variation on a theme - but it was used successfully for all kinds of control systems - and Don sold a PICAXE board specifically for the purpose.

Unfortunately Dontronics has closed now.

 

[tumbleweed]

Some thoughts...

Depending on the environment, at 9600 baud (~100us/bit) you could probably get away with a simple open-drain bus for the slave outputs. Most modern 18F's have an open-drain IO pin mode, and let you invert the TX data if you're using an external OD mosfet instead. Put a stiff pullup on the master side.

Using 9-bit uart mode allows you to "address" each device.

Be careful with adding a RESET line to the MCLR pins... that can make things more susceptible to noise on that line.

You can use a serial BREAK condition to reset them, or running your "RESET" into a slave INTR pin is a little more flexible... you may not really want the slave to reset right at that moment (writing to eeprom, I2C transactions, etc) and you can software filter it for noise, etc.

It's not as "100% foolproof" as having a hardware /MCLR reset, but it doesn't have the other issues associated with it.

 

[Tony Stewart]

You only have thousands of choices for ;

- error & fault detection/ protection/ correction/ testability/ calibration, hot-swap pluggability, capacity, gofundme-interest, expandability and cost

Reinvent the wheel or just make a simpler version of existing ones.

Wikiwand - OSI model

The Open Systems Interconnection model is a reference model from the International Organization for Standardization (ISO) that "provides a common basis for the coordination of standards development for the purpose of systems interconnection." In the OSI reference model, the communications...

www.wikiwand.com

Wikiwand - LAPB

Link Access Procedure, Balanced (LAPB) implements the data link layer as defined in the X.25 protocol suite. LAPB is a bit-oriented protocol derived from HDLC that ensures that frames are error free and in the correct sequence. LAPB is specified in ITU-T Recommendation X.25 and ISO/IEC 7776. It...

www.wikiwand.com

 

[Nigel Goodwin]

You only have thousands of choices for ;

- error & fault detection/ protection/ correction/ testability/ calibration, hot-swap pluggability, capacity, gofundme-interest, expandability and cost

Reinvent the wheel or just make a simpler version of existing ones.

Wikiwand - OSI model

The Open Systems Interconnection model is a reference model from the International Organization for Standardization (ISO) that "provides a common basis for the coordination of standards development for the purpose of systems interconnection." In the OSI reference model, the communications...

www.wikiwand.com

Wikiwand - LAPB

Link Access Procedure, Balanced (LAPB) implements the data link layer as defined in the X.25 protocol suite. LAPB is a bit-oriented protocol derived from HDLC that ensures that frames are error free and in the correct sequence. LAPB is specified in ITU-T Recommendation X.25 and ISO/IEC 7776. It...

www.wikiwand.com

All of which is fairly irrelevant for his very low requirements, a couple of metres at low speed is no big deal.

 

[For The Popcorn]

All of which is fairly irrelevant for his very low requirements, a couple of metres at low speed is no big deal.

Exactly. Short cables, low baud rate and data rate, a handful of nodes for a non-critical monitoring system.

 

[Nigel Goodwin]

Exactly. Short cables, low baud rate and data rate, a handful of nodes for a non-critical monitoring system.

I'm all for your technique - always let the host request data, and the slaves never initiate contact on their own at all - no collision problems then

In my case I did it wirelessly though, using HC-12 serial modules (so gives a really good range, and a simple RS232 type interface), and individually addressed slave modules.

 

[AnalogKid]

Back in the 80's I did something similar over 60 feet of ribbon cable, collecting data from a string of response panels.

ak