This article describes an Ethernet-connected subsystem of a larger modular sensor system designed for industrial or smart home sensing and monitoring. We will discuss a custom sensor subsystem developed for this application.

Creating custom sensor solutions for home or automation typically requires a great deal of customization. A variety of sensors from perhaps several manufacturers are collected on a circuit board, firmware must be engineered, and a user interface or dashboard created. It isn’t overwhelmingly difficult work—but it can be rather tedious and time-consuming. The customization aspect may also make it cost-prohibitive in many use cases.

The idea behind this project was to create a “Super Simple Sensor System” that allows a wide variety of input and output nodes to be linked together with a common protocol with the fewest number of wires possible and low upgrade/replacement cost. This subsystem will hopefully spark creativity in your designs but it is not a market-ready product.

The inspiration came from the wonderfully designed Makeblock Neuron line of children’s educational toys. Multiple sensors and inputs (temperature, humidity, joystick, buttons, etc.) are connected with a variety of outputs and interfaces (LED display, buzzer, etc.) and all of the devices connect via magnetic spring-loaded pogo-pin connectors.


Project overview: Each node connects to its neighboring node with power, ground, and two UART connections. Click to enlarge.


Choosing a Communication Protocol

Each node in my project has an inexpensive microcontroller built in. Sensor or mechanical input data is sent to the microcontroller through the interface appropriate for the sensor (SPI, I2C, CAN, 4-20mA, etc.) and the microcontroller then converts the data to a common interface (UART, USB, etc.) for transmission to neighboring nodes.

In this case, I chose UART as the common bus protocol. Data is read from the neighboring node on the left, data from the current sensor is added to the stream, and then all of the data is passed to the neighboring node on the right.

Each input node adds to the datastream, perhaps with a byte identifying data length, a node identification byte, and the data. Designers who wish to augment the system need only design a single node; this retains modularity of design and allows a catalog of devices to be connected quickly and easily.



Data is continually passed in daisy-chain fashion from one node to the next until it reaches an output node. There the output devices (flashing alarms, LCD displays, buzzers, etc.) read the datastream for information that pertains to them and act accordingly—passing the data along the entire time.

This would work well enough for a three-wire interface (VDD, GND, Data) with one UART bus, but would require that all input nodes be placed before output nodes. By adding a second UART bus, bidirectional information can be passed and nodes can be added in any configuration. Alternatively, the second line might be used for microcontroller software updates, as a heartbeat monitor, or reserved for future use.

You can make life easier by using magnetic pogo-pin connectors in your design.


Image of magnetic pogo pin connectors courtesy of Shenzhen Like Hardware Electronics, Co. LTD.


As indicated above in the block diagram, the Tx/Rx lines (for both UART0 and UART1) extend to opposite sides of the board. This is for several reasons.

First, and perhaps most important, this allows simultaneous programming/debugging and use. The microcontroller programming interface shares pins with UART0 (i.e., the programming signal and the UART signal are both routed to the same physical pin), so testing a receive and transmit sequence, which happens on opposite sides of the board, while connected to the debugger, requires that one of the two data pins from UART1 be on either side of the board.

Second, it allows a single UART bus to be utilized in a three-wire configuration (i.e., power, ground, Tx on one side and power, ground, Rx on the other side).

Lastly, it might simplify the firmware by allowing data to be received and transmitted using the same bus instead of being copied from a receive bus to a separate transmit bus each time it enters a node.


Designing with Industrial Communications in Mind: About the Subsystem

Sensors and displays on a factory floor tend to be ignored over time. Data must be moved from the factory floor to a central location in the building, or perhaps across town to a monitoring location. To satisfy that requirement, I chose to use a wired Ethernet connection. Cat5 and Cat6 wiring, usually already installed at a location, can transmit data over long distances in a LAN, and when connected to WAN, can move data anywhere in the world. The MQTT protocol is designed for M2M (machine-to-machine) communication, and an MQTT broker can easily be established to move the data from interface node to interface node, all the while being secured with TLS1.3.

Once the data reaches its destination in the LAN, or the Internet, a programmer can capture the data to create a graphical user interface, sometimes referred to as a “dashboard,” that managers and controllers can view. Unfortunately, those displays tend to gradually be ignored over time as well. The current trend in automation is to create automated texts, emails, or other alerts that can be sent directly to workers, and then if the worker does not correct the errant situation in a timely fashion, notify the employee’s direct supervisor.

The critical parts of this project require that I have two independent UART buses and one Ethernet interface. For the Ethernet interface, I chose the WizNET W5500. This highly integrated IC implements the TCP/IP stack, the 10/100 Ethernet MAC (media access control), and the PHY (physical layer). I don’t have much experience with the TCP/IP stack, UDP, ARP, ICMP, etc., and this IC allows me to use up to 8 sockets over SPI—a protocol I am familiar with.  

I selected the MSP430FR2633 as the microcontroller. While the MSP430FR2433 would also be able to control the W5500, I knew I would have some unused GPIO pins, and I liked the option of creating a low-cost capacitive-touch control panel in the future. The 2433 does not support capacitive touch, so I opted for the 2633. All other ICs used in the project support the W5500 and the MSP430FR2633.



Each node in the system shares a common 5VDC rail.  The 5V supply is generated by one board that serves as the power source for the entire network, and then each board uses two TLV757P LDOs to regulate the 5V rail to 3.3V for analog circuitry and 3.3V for digital circuitry.  This is a four-layer board, with the top and bottom layers used for signals and layers 2 and 3 for AVDD and GND, respectively.


The schematic diagram of the power section


Routing of the AVDD and DVDD lines provided a challenge on this 4-layer board. AVDD (shown in magenta below) was chosen as the power-plane net because this arrangement seemed to result in easier, cleaner routing. DVDD had to move between layers 1, 2, and 4, which is not ideal. At each transition, multiple vias were used to minimize the impedance.


Shown above is the physical PCB, followed by layers 1-4 of the layout. Layer 2 (AVDD) is shown in magenta, and DVDD is shown in orange.


Ethernet Connectivity

Almost all devices that are hard-wired to the Internet have an 8P8C RJ45 jack. Either built into the jack or very close to the jack there is a pulse transformer. The pulse transformer galvanically isolates the integrated circuit from the cable. The isolation provides protection from DC fault conditions and eliminates problems associated with differences in the ground potentials of the transmitter and receiver. The transformer also functions as a differential receiver that suppresses common-mode noise, such as electromagnetic interference that is generated from high-power equipment and coupled equally into two tightly twisted signal wires.  

The two options for circuit integration are an RJ45 jack with an external pulse transformer, or an RJ45 jack with integrated pulse transformer. The integrated option is often called a “MagJack” and is generally easier to use, but a tad more expensive. You only need to access two of the four pairs of wires for 10/100 communication. The other two pairs are not used at all! When I was selecting parts for this project, this thought didn’t occur to me, and I rejected several proposed MagJacks because they only provided access to two pairs of wires and had six-pin footprints—I needed an 8P8C jack, with two LEDs (each LED has separate anode and cathode pins), so I was searching for twelve-pin footprints or greater. Woops! Only four of the eight conductors are used. The moral of the story is this: If you’re not going to use all eight conductors, don’t pay for magnetics for the other two pairs of wires—the RJ45 jack will be the same size and perhaps a bit cheaper.

As you can see below, R7-R10 are damping resistors. I estimated their values based on other reference designs. They are necessary to prevent overshoot and ringing in the circuit. Testing would have to reveal if the lines are over/under/critically damped and the values adjusted accordingly. The transmit pair are pulled up to DVDD through 49.9Ω resistors, and the center tap is connected to DVDD through a 10Ω resistor and decoupled with a 22nF capacitor to ground. The receive pair passes through the damping resistors where it encounters two capacitors. The pair are tied through two 49.9Ω resistors to a 0.01 µF decoupling capacitor per manufacturer recommendation—they are further pulled up to DVDD through the center tap of the transformer winding.


The MagJack circuit for my WizNet W5500 implementation.


Wiznet W5500

From a hardware perspective, the WizNet W5500 is a pretty straightforward addition to the circuit. An external crystal oscillator must be included and a half-dozen or so analog decoupling capacitors are needed—one for every AVDD pin. Pins 43-45 are used to select the network mode. I included pads for solder bridges should it be necessary to use something other than the default configuration (as it turned out I didn’t need to change the mode).

The crystal oscillator manufacturer recommended the removal of copper from directly underneath the crystal. And I used ground pours to attempt to isolate the crystal’s output from the W5500 SCLK input line, although it was likely not necessary.


WizNet W5500 schematic shown above.



The MSP430FR2633 is the latest microcontroller that I’ve been working with and I’ve used it for a few projects now (including this capacitive touch project). If you have trouble using it, I've found that the Texas Instruments is supportive of engineers in their E2E forums, where application engineers respond to most questions/requests.  

The MCU is programmed with the MSP-FET programmer and debugger through GCC, IAR, or Code Composer Studio. One of the reasons I enjoy working with this MCU is because it has dedicated capacitive touch input pins. This means that buttons/switches/sliders can be added to a control panel for only the cost of the additional PCB, or at no cost if the capacitive-touch elements, the MCU, and the other required components are incorporated into a single PCB. See my other article on the MSP430FR2633 for more details.


The MSP430FR2633 schematic with debounced reset circuit is shown above.


The MCU implementation on a PCB is rather simple—just a few decoupling capacitors and a reset circuit are all that is needed. The debounce circuit on the reset switch follows the datasheet recommendation.


Voltage Level Converters

While not strictly necessary, I added two logic-level converters to the UART datalines that come off of the MSP430. Since the supply voltage coming into the board is 5V, I chose to make the dataline signals 5V, as well. This is a somewhat arbitrary choice and a very good argument could be made for keeping them at 3.3V (which is the supply voltage used by the MCU).


Part Placement

With the exception of the MagJack and power LED, all parts were placed on the top of the board. The MagJack sits away from other components, and the copper underneath the MagJack has been removed from all layers of the board so that the magnetics inside the jack will not influence any other parts of the circuit. Differential pairs are routed outside the footprint of the device in as little distance as possible.

The Wiznet W5500 is located in the center of the board along with all of its support circuitry, and the three unused solder-bridge pads can be seen just above and to the left of the silkscreen table. The MSP430FR2633 is to the right of the WizNet along with header J2—which provides four capacitive touch pins, one DVDD pin, and three GPIO pins. These are for a future user interface panel that holds four capacitive-touch pads and three LEDs. Test pads are provided for every digital signal line with the exception of the differential traces.


Project PCB. Click to enlarge.


See the video below for more information.


This subsystem demonstrates how to potentially integrate a large number of sensors and displays in a factory or home and collect data over long distances using MQTT.

We create projects that hopefully inspire ideas in your designs.  If there is anything you’d like us to consider making, please leave a comment below.




  • brianrho 2018-09-18

    Looks neat. How do you handle distance between nodes though, regarding power and UART comms?

    • Mark Hughes 2018-09-18

      Hi Brian,
          It would depend on your application—and your distances.  If you stayed true to this design (sticking with UART), you might incorporate the HC12 transmitters, and put a new power-node at the remote location.  The power could be anything really, battery, wallwort, etc….  You could also abandon UART completely and go with a different interface.  We don’t sell our designs—we just put them out there to give people ideas.
          If you have a specific need, please post in the forums and I’ll see if I can’t wrangle up a few contributors to help you out.
      Take care!

      • brianrho 2018-09-28

        Regarding power, I was referring to the way you power all the nodes from one source. Assuming it’s 5V or something, I’d expect the voltage would drop to unusable after a few meters. Regarding comms though, RS-485 could be used between nodes. The HC12 would require a lot of work in software to make it reliably support multiple nodes talking at the same time.

        • Mark Hughes 2018-09-28

          Hi @brianrho,
              In my vision of this project, the input nodes and output nodes would be immediately next to one another with no separation between them.  You are absolutely correct that if any substantial distance between the nodes, that protocol and power are a huge issue.  Imagine the nodes side by side.  If you need nodes in different locations, instead of trying to extend the connections, put a Ethernet node (like the one described in this article) to bridge the gap.

          I think you and I are on the same page about many aspects of this design except for one:  You are extending the original design past what I envisioned….which you are of course welcome to do.  I’d be happy to discuss your particular use case in our forums if you like.  Take care!

          I haven’t tried the HC12 in a situation such as this, but I would imagine that if the channels were sufficiently staggered (perhaps 1, 6, 11, 16, 21, etc…), you might be able to squeeze 18-20 transmitters in the same band.

  • jspitaels 2018-09-28

    Hello, how does this compare to RS-485?

    • Mark Hughes 2018-09-28

          Do I understand that you want to compare RS-232 to RS-485?  If so, RS-485 is able to transfer data over longer distances and at greater speeds over those distances compared to RS-232.  However, it is a slightly more complicated physical layer….which starts to increase the project complexity.  is that what you meant?  Or were you trying to ask a different question.  Let me know.