Most embedded projects are based upon the same concept, of reading out a sensor and/or controlling an end device.

I started the Xnorduino project, in an attempt of limiting the amount of repetitive rework in-between multiple unrelated projects. A Master-Slave communication bus setup was used, in order to accomplish this goal.

I2C communication was chosen, as most microcontrollers have this integrated by default. This keeps price low, with the downside that I2C is limited to short distances. There is however a solution in using differential I2C conversion IC's.

The PCA9615 IC extends our bus signalling distance up to 30 meters (or even 100 meters using slower clock speeds).

However, the addition of this conversion IC increases the price. I therefore opted for a hybrid approach, where an intermediate module could convert differential-I2C and normal-I2C. This limits the amount of conversion IC's required in larger setups.

This way simple FPC cables can be used for shorter cable runs, whilst cat5 (or better) can be used for longer cables. This concept can be seen in the image underneath.

Converting I2C to a deferential signal, doubles the required amount of wires from two to four cables. As can be seen in the snippet underneath from the IC's datasheet.

Our ethernet cable has 4 pairs (or 8 wires), meaning half of it is available for power delivery. I finally decided to dedicate the remaining 4 cables as follow:

• GND
• GND
• 5V
• 24V.

More explanation about this decision will be provided further down this documentation.

The bus master is the bridge / gateway between our bus communication and a standardized USB port. This means that this parts functionality, has to be fairly extensive in it's capabilities. A short summary of it's requirements are:

• USB communication with an (embedded) computer
• 5V and 24V bus power delivery
• Power-monitoring (Over-current measurement and shutdown)
• Bus interruption detection
• Optional: Wireless communication

All these functions where implemented as follow:

The systems is programmed in such way, that the 24V power-supply is only passed through the ethernet cable if:

• The termination brick is connected
• No over-current is being detected

A “smart” termination brick is implemented, in order to detect bus interruptions. This termination-brick contains termination resistors and a small microcontroller.

The termination brick power-consumption is extremely low, meaning that our 5V power-rail suffices as it's power source on even longer cable runs. The Bus-master reads an “heartbeat” from this termination brick in a 20 ms interval. The 24V power-rail gets enabled, whenever the termination brick is successfully detected by the master. The master disables the 24V power-rail within 50 ms, whenever the termination-brick gets disconnected. This feature functions fully automatically, without any human intervention.

This feature was implemented, to prevent accidentally inserting 24V on standardized network equipment. Which could potentially cause damage on certain devices.

Additionally, the termination brick measures temperature and the voltages of both power rails (as can be seen in the image underneath).

Our 24V power-rail has a maximum current that depends on the utilized cat-cable. I therefore implemented a digital current-sense IC on the master, which disables the 24V power-rail pro-grammatically whenever our current draw surpasses a certain pre-configured value. For safety reasons, any over-current detection disables the 24V rail permanently, until human intervention resets the system by clicking the “reset” button (visible in image at the right). A red LED will indicate the over-current trigger on the PCB itself.

Additionally the power-monitor IC reads the 24V rail voltage at the beginning of the communication bus. The Termination-brick measures the 24V rail at the end of the bus, meaning we can calculate the voltage drop across our bus by subtracting these two.

Many slave devices have been designed, that link to the bus-master. However some of these slave devices fall under NDA and their functionality and/or purpose cannot be further explained.

Below are some (approved) example images of various slave devices.

• PWM Fan controller
• Current and voltage sense
• 16 bit ADC modules
• Humidity and temperature module
• Weather station module
• LED driver modules
• etc …

A python-flask project was created, in order to preview and configure the Xnorduino bus-devices easily.

Note: Every I2C to differential-I2C convertor board, is shown as an additional subdevision downwards. See example in image below, ID: 20 …

For testing end debugging purposes, I decided to utilize the XnorDuino system for home automation.

A small mounting module was 3D printed, in order to install the Master module inside an Raspberry pi din-rail enclosure. Some example pictures are provided below.