Playing around with the DMX FeatherWing, a Particle Ethernet FeatherWing, an Adafruit Feather M0 Basic Proto, the official Nanoleaf DMX interface, and a Nanoleaf Aurora tile. The GUI on the iPad tells the Feather M0 which light program to run. The program output is sent via DMX-512 to the Nanoleaf setup.

This project uses an Adafruit Feather M0 Basic Proto board to control a group of Color Kinetics or other RGB light fixtures using the DMX-512 protocol. We’ll build a DMX-512 interface FeatherWing then connect it to the Feather M0 using a Particle Ethernet FeatherWing. Once the hardware is built and assembled, we’ll write software with a web-based GUI to generate RGB lighting effects and control the attached RGB lights using the DMX protocol. By modifying the software on the Feather M0, different effects can be generated and added to the web-based GUI.

Required Materials

The materials required for this project are:

• DMX FeatherWing board and parts. We’ll discuss ordering the board, the required parts, and the assembly in the next section.
• Adafruit Feather M0 Basic Proto
• Particle Ethernet FeatherWing
• Particle Ethernet FeatherWing PoE Adapter (optional). Note: The PoE adapter has been discontinued. If you want to make your own version, the Eagle design files are available here but the header sockets on the module need to be moved to align with the headers on the Ethernet FeatherWing board.

The DMX FeatherWing

The assembled DMX FeatherWing board. I fixed the location of the DIR silkscreen label in the Eagle design files and on the board order link at OSH Park.

The photo above shows the assembled DMX FeatherWing. The next few sections are dedicated to describing and building the DMX FeatherWing hardware.

Circuit Design and Schematic

DMX-512 FeatherWing schematic.

To make sure everything conformed to the FeatherWing form factor, I started with the Eagle design for the Adafruit Power Relay FeatherWing. I deleted everything from the schematic and board except for the FeatherWing symbol and dimension lines. The FeatherWing symbol includes the board outline layer and the holes for the 0.1″ pitch, 0.025″ square post headers that connect the FeatherWing to other boards. I saved this as a new file then started my design.

U1 is a Ti 3.3V differential transceiver. Its transmit data input is connected to the Feather’s transmit data output pin. Its receive data output is connected to the Feather’s receive data input. The direction line is connected to a GPIO pin. I only plan on transmitting data so I could have tied the direction pin high to permanently enable the transmitter and disable the receiver but connecting it to a GPIO allows me to control the direction in software and could be useful for future projects.

J1 is a plastic RJ-45 8P8C jack. It’s wired to connect to Philips Color Kinetics’ lights and controllers. Other DMX lights with RJ-45 jacks may use different pin outs. Typically pins 1 and 2 are swapped or the shield is on a different pin on these lights. R1 is the 120 ohm termination resistor required at the transmitter by the DMX specification. Another 120 ohm termination resistor should be placed at the last fixture in the chain of fixtures.

The rest of the parts are for decoupling, EMC compatibility, and ESD protection. C1 is a decoupling capacitor to filter voltage transients on the supply to the differential transceiver. C2 grounds high frequency noise on the shield line while preventing a DC current loop between the board and any connected light fixtures. This should help with EMC compatibility but still provide isolation between the hardware at either end of the DMX cable.

D1 and D2 provide additional ESD protection beyond the ESD protection built into the differential receiver. Their function is described in the TI application note Protecting RS-485 Interfaces Against Lethal Electrical Transients.

Board Design

DMX-512 FeatherWing board design.

Components were placed on the board to minimize the length of the signal traces. The differential data lines between J1 and U1 contain a small loop to equalize their lengths. The termination resistor and ESD components connect straight from these pins to the pins on the differential transceiver. C1 is located as close as possible to U1’s 3.3 V supply line. The direction, transmit data, and receive data lines are routed to the FeatherWing headers.

DMX-512 FeatherWing top side board render.

DMX-512 FeatherWing bottom side board render.

Once the board design was done, I uploaded the Gerber files to OSH Park and checked the renders to make sure everything looked OK. Once I was happy, I ordered the boards from OSH Park.

Ordering Boards

If you wish to use the board exactly as designed, you can order a blank board from OSH Park here. If not, you can download the Eagle design files from Github, make your desired modifications, create Gerbers, and order boards from your favorite PCB manufacturer. My top and bottom silkscreens are located on layers 121 and 122 respectively so you may need to alter your CAM processor script to output these layers to the silkscreen Gerber files.

Bill of Materials

The bill of materials is available in the Github repository as an Excel spreadsheet. It’s also reproduced below for your convenience. All the parts are available from Digi-Key.

DMX FeatherWing Assembly

To assemble the board, solder all the surface mount components first starting with U1. Once the surface mount components are soldered, solder the headers to the bottom of the board. It can be helpful to place the headers in a breadboard to hold them in place while soldering them to the DMX FeatherWing. This technique is described in detail on Adafruit’s website here. Finally, insert the RJ-45 connector into the top of the board, flip the board over, and solder the connector in place.

Assemble the Board Stack

The assembled stack of boards. Do not connect the PoE module at this time.

Once the DMX FeatherWing is assembled, it’s time to connect all three boards together. Holding the Particle Ethernet FeatherWing board with the Ethernet circuitry on my left, I placed the Adafruit Feather M0 Basic Proto in the middle of the board and the DMX FeatherWing on the right of the board. If you have the optional PoE module, do NOT install it at this time!

We’re going to be using the USB cable to power the stack of boards and download software to the ATSAMD21. Powering the boards from both the PoE supply and the USB cable can result in damage to your boards and/or your computer. Never use both the PoE module and the USB cable at the same time.

Install Software Environment and Libraries

This project uses the Arduino integrated development environment for the Adafruit Feather M0 Basic Proto. Follow the instructions on the Feather M0 Basic Proto tutorial page to install the Arduino IDE and additional boards manager URL. Once those are installed, install the libraries required for the Feather M0 boards and the ATSAMD21 as instructed on the next page of the same tutorial.

This project also uses the Arduino Ethernet and Timer libraries. Follow these instructions to install the Ethernet library. After installing the Ethernet library, install the Arduino Timer library. It’s the same process as for the Ethernet library except search for the arduino-timer library by Michael Contreras v2.0.1. Once you’ve found it in the GUI, install the library and perform one last restart of the Arduino IDE.

Test the Software Installation

I recommend testing the software installation by building and running the WebServer example for the Ethernet library. In the Arduino IDE, click Tools -> Board -> Adafruit Feather M0. Once the board is selected, click on File -> Examples -> Ethernet -> WebServer to open a new window with the example WebServer project. Be sure to pick Ethernet and not Ethernet2.

Now select File -> Save As to save a copy of the WebServer example in your Arduino projects directory. Find the IPAddress ip (…) line and change the IP address to a valid static IP address for your network. Finally uncomment the line Ethernet.init(10) to pick the correct chip select for the combination of the Particle Ethernet FeatherWing and Adafruit Feather M0 Basic Proto boards.

The boards set up to download and test the code.

Connect the RJ-45 Ethernet jack to an Ethernet switch on the same network as your computer. Make sure the optional PoE module is NOT installed then connect the micro USB connector on the Feather M0 board to a free USB port on the computer.

Go to Tools -> Port and select the COM port connected to the Feather M0. Now launch the serial monitor by selecting Tools -> Serial Monitor. Finally build the example and download the code to the board by selecting Sketch -> Upload in the Arduino IDE.

If everything is successful, you should see something similar to the following in the serial monitor window:

Build and download success!

Use your favorite web browser to navigate to the specified IP address. You may need to prepend http:// to the IP address for some browsers. You should get something similar to the following:

Web server test successful!

And the serial monitor will update with some debugging info every time the browser is refreshed:

The serial monitor after sending a web page to the web browser.

At this point, the test is successful and it’s time to try to control some lights with the real software.

Connect Some RGB DMX Lights

An inexpensive light like this one with a homemade RJ-45 to XLR 3-pin adapter cable makes a good fixture for testing the hardware and software.

Connect some RGB DMX lights to the DMX FeatherWing’s RJ-45 jack. The software in its default configuration controls 24 RGB lights using DMX channels 1 to 72. Make sure your connected lights are in this range and the red channels start with 1, 4, 7, etc.

Download and Run the DMX Controller Software

Download the DMX Controller Source Code from Github

My latest DMX controller software can be downloaded from Github here. Download these files into a new folder. This folder must be named dmx-controller and must be inside the Arduino projects folder. This is a constraint of the Arduino IDE.

Set the IP Address

Just like for the example WebServer project, the IP address must be set to a valid static IP address for your network. Find the IPAddress ip (…) line in the dmx-controller.ino file and set it to a suitable IP address.

Build and Download the Code to the Feather M0

If the serial monitor window is not already open, open it again by selecting Tools -> Serial Monitor. Now build and download the code by selecting Sketch -> Upload.

Using the Web Interface

Enter the IP address from above into your favorite web browser and you should get the following web page:

Opening page of the web-based GUI for controlling the attached lights.

Now click the Fixed Color tab. The web page will update to display this screen:

Fixed color tab.

Clicking on a color should change the color of the connected lights to the selected color. Once this is working, experiment with some of the other tabs and settings.

My living room wall washed in red light using the fixed color mode on the controller.

Congratulations if you’ve made it this far! At this point the project works. The following sections are for those who wish to dive deeper into the controller’s functionality or modify the software or hardware.

Software Details

Sending DMX Data with the ATSAMD21

To send DMX-512 data with the ATSAMD21 microcontroller, I used the LXSAMD21MDX library by Claude Heintz as a starting point. Unfortunately, this library sends DMX data continuously so as soon as a packet is done being sent, it immediately starts sending the next packet.

This causes a problem because there’s no way to guarantee that I won’t update the RGB values for a light in the middle of those values being sent. For example, if I were updating the RGB values for a light and the library sent the new red and new green values before I could update the blue value, this could cause a light to flash a wrong color for a brief instant.

Next I tried stopping the DMX transmission using the stop function in the library. Calling this function completely disabled the serial port and, as a result, the transmit data line was no longer driven. This caused a very long low / break signal to be transmitted between packets which is against the DMX-512 specification that requires the line to be held in the high / mark state between packets.

Screen capture from my scope. The yellow trace shows DMX packets being transmitted at 50 Hz (20 ms between the start of each packet). The transmit data line is held high between packets which is the idle state for the serial interface. The green trace was connected to a GPIO that was set upon entry to the SERCOM2 interrupt handler and cleared upon exit.

I decided to rewrite the DMX library and to use a double buffering scheme. The light levels are calculated and stored in an effects buffer. When it’s time to send a packet, the light levels are copied from the effects buffer to a transmit data buffer. The library is then called to transmit a single DMX packet using the values in the transmit data buffer.

While the DMX packet is being sent, the effects generation code is called to generate the next set of light levels and store them in the effects data buffer. This happens at a 50 Hz rate and completely prevents partially modified data from being sent to the lights. I used a scope to verify the packet rate, the DMX-512 break period, and the bit rate on the interface.

The DMX packet starts with a break of 100 us (yellow trace). This is much longer than a normal 250,000 bps break character. The scope was set to trigger on a negative pulse with a pulse width greater than 80.0 us. The green trace was connected to a GPIO that was set upon entry to the SERCOM2 interrupt handler and cleared upon exit.

While I was prototyping the project, I left the microcontroller’s receive data pin unconnected. This resulted in the microcontroller receiving errored characters and generating both receive character and error interrupts. Since I wasn’t expecting or handling these interrupts, this resulted in the microcontroller being stuck in the interrupt handler.

I traced the cause of this behavior to the begin method in the Arduino Uart class which enables the receive character and error interrupts. I disabled these interrupts by adding the following code immediately after calling the Uart class’s begin method and everything started working:

     SERCOM2->USART.INTENCLR.reg = SERCOM_USART_INTENCLR_RXC | 
                                 SERCOM_USART_INTENCLR_ERROR;

This likely isn’t an issue with the real hardware because the receive data pin is not left floating. I’m not using the receive portion of the USART, however, so I might as well disable the interrupts to avoid any chance of them causing problems in the future. I could probably even disable the USART’s receiver altogether if I wanted.

Modifying the Built-In Effects or Adding New Effects

Adding a new effect to the code requires defining a new mode, adding some HTML to display the options for the mode, parsing the HTTP request to get the options for the mode, and adding code to run the mode.

effects.ino

The effects.ino file contains code to run the effects and change options associated with each effect. This file requires several additions to create a new mode.

1. The enum at the very top of the effects.ino file defines the available modes. To add a mode, add another definition to this enum.
2. Scroll down the file a bit and look for the global variables starting with the effects_ prefix. Add any variables to store options associated with the new mode here.
3. Inside the effects_Init function, add code to initialize the options associated with the new mode to reasonable default values.
4. Inside the effects_Run function, add another case statement to the switch block to call a new function to generate the mode’s effects.
5. Under the EFFECTS GENERATORS heading, add a new function to generate the effect. This function should be named the same as the function added in step 4 above. This function will be called once every 20 ms and should use the effects_ global variables added in step 2 to calculate the next step in the effect. The RGB values should then be written to the effects_data array. This array contains DMX_SLOTS values which corresponds to DMX_SLOTS / 3 RGB lighting fixtures.
6. Under the COMMANDS FROM UI heading, add any functions that will be called by the HTTP request parsing code to modify the effects_ global variables.

dmx-controller.ino

The dmx-controller.ino file contains the code to parse the HTTP GET request from the web browser. The HTTP GET request is parsed by the ParseRequest function.

1. Add any new key value pairs to the long if-else block about half way through this code.
2. Add code to call the functions defined in step 6 in the previous section to modify the effects_ global variables under the Set Parameters comment.

html.ino

The html.ino file contains C/C++ code that emits HTML to the web browser to permit the user to change the mode and configure any options associated with the mode. The function SendHtmlPage is the function that is called to emit the HTML.

1. Add an additional call to the Tab function with the mode number and name in SendHtmlPage. This creates an additional tab pane for the options for the new mode.
2. Add a case statement to the switch block in SendHtmlPage with a call to a function to generate the HTML that fills the options tab for the new mode.
3. Add the function called in step 2 above to generate the HTML to the bottom of the file.

 style.ino

If you need additional CSS style code, add C code to generate it in the style.ino file.

samd21dmx.cpp and samd21dmx.h

These files send the DMX packets. If you have more than 24 RGB lights or need more than 72 DMX channels, adjust the DMX_SLOTS define in samd21dmx.h.

Next Steps

Here are some ideas for future enhancements to the project.

Use PoE

Once the software is debugged, the USB cable can be disconnected and the boards powered using the optional PoE module.

If you have the PoE module for the Particle Ethernet FeatherWing, now would be a good time to try it out. Disconnect both the USB cable and Ethernet cable from the stack of boards. Install the PoE module then connect the Ethernet cable. Do not connect the USB cable.

After a brief handshake with the Ethernet switch the board should power up and function just like when it was powered using the USB connection to the computer. Just remember never to connect the Feather M0 to a computer using the USB cable while the PoE module is installed.

Add Art-Net Receive

This functionality is left as an exercise to the reader. Since this project has both Ethernet and DMX, it would be possible to re-purpose the project as an Art-Net to DMX converter. In my proposed implementation, the board would send its own internally generated DMX data and packets until it received an Art-Net packet. Each time an Art-Net packet was received, it would output the levels in the Art-Net packet over DMX. After a timeout of around 30 to 60 seconds, the controller would revert back to sending its own DMX data and packets.

Custom Board and Enclosure Design

Render of the board design which integrates the functionality of all three boards used in this project.

My personal next step for this project is to build a board that encompasses all the functionality of the three board stack and make it small enough to fit in a Hammond Manufacturing 1455C801 50 mm x 80 mm extruded aluminum enclosure. The render above shows an almost final version of the proposed circuit board. The renders below show the finished enclosure with the board mounted inside.

Board mounted inside Hammond Manufacturing 1455C801 extruded aluminum enclosure.

Board mounted inside Hammond Manufacturing 1455C801 extruded aluminum enclosure.

Questions or Comments

If you have any questions or comments about this project, I can be reached on Twitter. In the meantime, stay tuned for updates on the integrated version of this project.

Philip Color Kinetics ColorBurst 4 10 watt RGB LED flood light controlled and powered over the network.

Time for another PoE project! This project uses a Silvertel 802.3at Ag5300 PoE+ module with a built-in isolated 24 V DC/DC converter to power  a 10 W ColorKinetics ColorBurst 4 RGB LED floodlight. The Ethernet cable and light plug into a small power / control board and PoE+ powers the floodlight and Art-Net UDP packets control the light. If this were a real product, the power / control board would be integrated into the fixture and the Ethernet cable would then plug directly into the back of the light.

The Silvertel Ag5300 PoE+ Module

Silvertel Ag5324 PoE PD module with integrated isolated 24 V DC/DC converter.

My previous PoE projects here and here used a discrete Texas Instruments TPS2378 PoE+ classification IC and a Molex Ethernet jack with integrated magnetics and PoE+ classification circuitry. The TI TPS2378 is the lowest cost solution. The downside is it requires quite a other components to operate. The Molex jack is the highest cost solution but requires very few external components to operate.

Three different isolated PoE PD designs. The top left design uses a Molex Ethernet jack with integrated magnetics and PoE PD classification circuitry. The bottom design uses an Ethernet jack, separate magnetics, and a TI PoE PD classification IC. The top right design, which is the design used in this project, uses an Ethernet jack, separate magnetics, and a Silvertel PoE module. The Silvertel module lies somewhere in the middle in terms of complexity. In the two more complicated designs, the transformer and Bob Smith termination network could be replaced with an Ethernet jack with integrated magnetics.

The Silvertel module sits somewhere in the middle of these other two solutions. It still requires a jack, magnetics, two bridge rectifiers, and a transient suppressor like the discrete TI solution, but, unlike the TI and Molex solutions, it includes an isolated 12 V or 24 V DC/DC converter. The integrated DC/DC converter can be a big cost savings and help to reduce the overall parts count.

The Plan

I have a box of Color Kinetics ColorBurst 4 lights sitting in my basement. These lights run from 24 volts, draw a maximum of 10 watts, and use a funky 24 volt version of the DMX-512 protocol. I tore down a larger ColorBurst 6 fixture a few years ago which is very similar in design and operation to the ColorBurst 4.

A Color Kinetics PDS-150e power data supply next to a single ColorBurst 4 fixture.

These lights are normally powered and controlled using a Color Kinetics power data supply like the PDS-150e shown in the photograph above. The PDS-150e contains a 24 volt, 150 watt DC power supply powered from the AC mains and a microprocessor that can control the lights using a Color Kinetics proprietary Ethernet-based protocol or DMX-512. This power data supply can power and control up to 12 ColorBurst 4 lights.

With enough of these fixtures in a row, they’re almost like giant Neopixels!

For this project, I’m going to replace the PDS-150e with a small power / control board that can directly power and control a single 10 watt ColorBurst 4 fixture from any 802.3at / PoE+ capable switch and an industry-standard Art-Net controller sitting anywhere on the network. I’ll use Synthe-FX’s Luminair 3 software running on an iPad Mini to send Art-Net packets to the board and control the light.

A Silvertel PoE module will handle the 802.3at classification and supply a regulated and isolated 24 volts for powering the fixture. A PIC18F67J60 will handle the data side of the project by accepting Art-Net packets and converting them to a serial DMX-512 stream to control the light. Finally, the project will use a line driver to step up the inverted 3.3 volt DMX-512 serial bitstream to a 24 volt version that is compatible with the fixture.

The Schematic

Schematic page one.

Page one of the schematic is shown above. It’s basically the same as page one of the schematic for the Ethernet-powered pixels project except the Texas Instrument PoE classification IC and the Cui 5 volt DC/DC converter have been replaced by the Silvertel Ag5324 PoE module.

Schematic page two.

Page two of the schematic is shown above. It’s basically the same as page two of the schematic for the Ethernet-powered pixels project except the WS2812 5 volt level shifter and ESD protection circuitry has been removed. In its place is a circuit reverse engineered from a Color Kinetics PDS-60 24 volt power supply to drive the 24 volt inverted DMX protocol to the ColorBurst 4 fixture from the microcontrollers’ 3.3 volt output.

If you have questions about the parts used on this project, I highly recommend reviewing the Ethernet-powered pixels project. It goes in-depth on the selection of parts used for that project, most of which are also used on this project.

The Board Layout

Finished board layout.

After finishing the schematic, I designed the circuit board. I attempted to place the components a bit closer together on this project versus the Ethernet-powered pixels project.

A primary concern while designing this board was to maintain at least 50 to 60 mils separation between the PoE power circuitry and the microcontroller circuitry. I don’t have the equipment to test whether this board layout successfully passes the 802.3 isolation requirements but with this separation, it at least stands a chance.

I ordered the boards from OSH Park and put together a bill-of-materials with their corresponding Digi-Key part numbers. Once I received notification that the boards had shipped from OSH Park, I ordered the parts from Digi-Key. This way I’d get the boards and the parts around the same time.

Power Supply Bring Up

The PoE-powered RGB LED floodlight controller with the PoE and power supply circuitry populated.

After receiving the boards back from OSH Park, I brought up the PoE and power supply circuitry first. Since I learned on the Ethernet-powered pixels project not to put an LED across the rectified power from the Ethernet transformer, this board came up immediately. I used a DMM to verify the output of the Silvertel PoE module was 24 volts and I verified the board showed up as an unknown 802.3at / PoE+ device on my switch port.

Microcontroller Bring Up

The fully populated PoE-powered RGB LED floodlight controller board.

My parts order for the rest of the board arrived a bit late but I had enough parts on hand to populate the 3.3 volt power supply and the PIC18F67J60 microcontroller. I did not have the parts for the Ethernet signals or the 25 MHz oscillator so the Ethernet bring up would have to wait for later.

I created a new XC8 project in MPLAB X IDE that used the internal oscillator on the PIC to blink the four LEDs slowly in succession. This was enough software to verify the microcontroller could be programmed and debugged. I downloaded the software and the lights blinked exactly as expected.

Once the rest of the parts arrived, I populated the remainder of the board including the Ethernet circuitry, the SiTime MEMS 25 MHz oscillator, the EUI-48 serial EEPROM, and the 3.3 volt inverted serial to 24 volt inverted serial driver.

To verify the Ethernet circuitry worked, I downloaded the build of the software for the Ethernet-powered pixels project to this board. This build could not control the ColorBurst 4 LED floodlight but it would attempt to get an IP address using DHCP from my router which was enough functionality to verify the Ethernet circuitry functioned correctly.

When I plugged the board into my switch, the board powered up and received an IP address from my router. I noted that a new MAC address had appeared on my network and this MAC address was the same MAC address as the one programmed in the EUI-48. The Ethernet circuitry works!

The next step was to clone the software for the Ethernet-powered pixels project to a new project and modify the Art-Net UDP receive routine to send the first three channels of level data to the ColorBurst 4 fixture as DMX data. I wrote the quick DMX send routine shown below then downloaded the code to the board.

        INTERRUPT_GlobalInterruptDisable();
        INTERRUPT_PeripheralInterruptDisable();
        
        // send break
        TRISCbits.TRISC6 = 0;
        LATCbits.LATC6 = 0;
        RCSTA1bits.SPEN = 0;

        __delay_us (88);

        // send mark after break
        RCSTA1bits.SPEN = 1;

        __delay_us (8);
        
        // send 0x00 followed by three art-net data bytes
        EUSART1_Write (0x00);
        EUSART1_Write (giantR);
        EUSART1_Write (giantG);
        EUSART1_Write (giantB);
        
        INTERRUPT_GlobalInterruptEnable();
        INTERRUPT_PeripheralInterruptEnable();

I used an oscilloscope to verify the serial data ranged from 0 to 24 volts and the baud rate was correct. After that, I connected the ColorBurst 4 fixture to the board. The light powered up but did not respond to the levels set on my Art-Net controller. Using the scope I could see DMX packets being sent to the light with transmitted levels corresponding to the levels set by the Art-Net controller but the light did not respond.

Finally, I looked at the DMX-512 spec again. It requires two stop bits. The PIC18F67J60 doesn’t support two stop bits but it does support a 9-bit data transmission mode. I enabled the mode and set the 9th bit to always be a ‘1’. That generates a signal identical to a signal with two stop bits.

        // enable 9 bit mode
        TXSTA1bits.TX9 = 1;
        TXSTA1bits.TX9D = 1;

I downloaded the code to the board again and this time, success! The ColorBurst 4 responded as I varied the level sliders on my Art-Net controller software.

Putting It All Together

The RGB LED floodlight being powered and controlled over the network. I’m using Luminair 3 by Synthe-FX on an iPad mini to send the Art-Net packets and control the LED fixture.

This project was successful. I could use software running on my iPad Mini to control the brightness and color of the light emitted by the ColorBurst 4 LED fixture and the fixture was powered using 802.3at PoE+ from my Ethernet switch.

A possible future iteration of this project might be to build my own RGB LED fixture, integrate the PoE+ power supply and Art-Net control circuitry in to the fixture, and design an enclosure to hold and cool everything. The enclosure would need to have a means for aiming it and securing it in position, a transparent or frosted window for the light, and an Ethernet jack on the back or bottom for powering and controlling the light.

Color Kinetics C200 RGB LED track fixtures hacked to be usable without the track.

Another thought would be to replace the control board in one of the older style Color Kinetics C-200 fixtures shown above with a board of my own design that includes PoE and controller functionality then cut a new rear panel for the light with just an opening for an Ethernet jack on it. This could be tricky depending on the amount of space available in the fixture.

Design Files

The design files for this project are on Github. You can reach me about any missing files or other questions on Twitter @bikerglen.

The completed and assembled PoE-powered vintage VFD tube clock.

This is a vintage VFD tube clock that uses Ethernet for both power and data. The power is provided using 802.3at PoE+ and a Molex PD Jack that contains both integrated magnetics and a PoE Type 2 PD controller. The IP stack runs on a Microchip PIC18F67J60 microcontroller that has an integrated Ethernet MAC and PHY. The IP stack includes DHCP, DNS, NTP, and LLDP functionality.

The clock powers up and receives its IP address and a DNS server address via DHCP. LLDP is used to negotiate 7.5 Watts of power. The clock performs a DNS lookup to get an NTP server address from pool.ntp.org. Once the clock has the address of an NTP server, it uses NTP to set the date and time. With the date and time set, the clock displays the time using the 6 VFD tubes and three MIcrochip HV5812 high-voltage display drivers. Once an hour, the clock corrects any drift using NTP.

Vacuum Fluorescent Displays

A modern vacuum fluorescent dot matrix character display module circa 2008.

Vacuum fluorescent displays occupy a niche in history between their high-voltage Nixie predecessors and their expensive-at-the-time LED successors. They can be identified by their relatively fast response times, wide viewing angles, and characteristic blue-green glow.

The dual-axis inclinometer photo above shows a relatively modern vacuum fluorescent display. This display is a drop-in replacement for a character LCD module. It’s visible at night, in bright sunlight, and from any angle unlike the LCD it replaced. This display module is circa 2008. Thisinclinometer was built to show the pitch and roll of my Jeep long before vehicles included this features in their instrument clusters.

An IV-11 VFD tube from 1989 on the left and an IV-12 VFD tube from 1992 on the right.

This clock project uses even older VFD tubes. The tubes are available in a variety of formats. In the photo above are two styles of VFD tubes. The tube on the left is an IV-11 display tube from 1989. The tube on the right is an IV-12 display tube from 1991. The only real difference between these tubes is the IV-11 on the left has a right-hand decimal point and wire leads while the IV-12 tube on the right lacks a decimal point altogether and has pins to mount the tube in a socket.

A Nixie tube requires 170 V DC to drive the tube’s anode. Vacuum fluorescent display tubes only require 25 V DC. As a result, they’re much easier to drive. Both tubes have a grid, a heater, and an anode per display segment. The electrical requirements for each are displayed in the table below:

With six tubes, the worst case heater current consumption is 6 tubes * 1.5 V * 0.110 A = 0.99 W. With six tubes, the worst case grid power consumption is 6 tubes * 25 V * 0.017 A = 2.55 W. With six tubes, the worst case segment power consumption is 6 tubes * 7 segments * 25 V * 0.005 A = 5.25 W. A six digit clock is then going to need a 1.5 V power supply capable of supplying 0.99 Watts and a 25 V power supply capable of supplying 7.8 Watts.

I decided to use the IV-12 tubes with the pins for sockets on their base. In the event of a mistake on one of my PCBs, I could unplug the tubes and re-use them on a corrected board. In the event of a failed tube, I could swap tubes on the project without significant PCB rework.

VFD Tube PCB Footprint

This is the only IV-12 tube diagram I could find showing the positions of the pins on the bottom of the tube.

After deciding on a tube to use for the clock project, the next step was to generate a schematic symbol and PCB footprint for the tube. I had a very hard time finding the diameter and spacing of the tube’s pins. I finally found a single low resolution image (reproduced above) on an eBay listing for the tubes. Of course, it doesn’t say if that’s a top or bottom view of the tube or which direction the front of the tube faces.

IV-12 VFD tube schematic symbol. I have no idea which anode pin corresponds to which display segment but I will be able to remap them in software so it doesn’t really matter.

I created a schematic symbol for the VFD tube. The left pin is the grid anode, the bottom two pins are the heater pins, and the top seven pins are the segment anodes.

After creating the schematic symbol, I created a PCB footprint for the part. I used the geometry from the data sheet and visual inspection of the base of the tube to create a Matlab / Octave script that creates an Eagle script to place the 11 pins and label them with their pin numbers. Here’s the Matlab / Octave code:

first = -(180-(360-306)/2);
increment = +34;
count = 10;
radius = 11.9 / 2;
text_radius = radius - 2;
drill = 1.95;

fprintf (1, 'grid mm;\n');
fprintf (1, 'change align bottom-center;\n');
fprintf (1, 'change size 32mil;\n');
fprintf (1, 'change font vector;\n');
fprintf (1, 'change ratio 16;\n');
fprintf (1, 'change drill %5.2f;\n', drill);

for i=1:count
  angle = first + (i-1) * increment;
  x = cos (angle / 180 * pi);
  y = sin (angle / 180 * pi);
  xp = x * radius;
  yp = y * radius;
  xt = x * text_radius;
  yt = y * text_radius;
  at = 90 + angle;
  %fprintf (1, "%4d %8.4f %8.4f\n", angle, x, y);
  fprintf (1, "pad '%d' round 0 (%8.4f %8.4f);\n", i, xp, yp);
  if (angle >= 0) 
    fprintf (1, "text '%d' sr%d (%8.4f %8.4f);\n", i, round(at), xt, yt);
  else
    fprintf (1, "text '%d' r%d (%8.4f %8.4f);\n", i, round(at), xt, yt);
  endif
endfor

Running this code produces the following Eagle script:

grid mm;
change align bottom-center;
change size 32mil;
change font vector;
change ratio 16;
change drill  1.95;
pad '1' round 0 ( -5.3015  -2.7012);
text '1' r-63 ( -3.5195  -1.7933);
pad '2' round 0 ( -2.8846  -5.2040);
text '2' r-29 ( -1.9150  -3.4547);
pad '3' round 0 (  0.5186  -5.9274);
text '3' r5 (  0.3443  -3.9350);
pad '4' round 0 (  3.7445  -4.6240);
text '4' r39 (  2.4858  -3.0697);
pad '5' round 0 (  5.6900  -1.7396);
text '5' r73 (  3.7774  -1.1549);
pad '6' round 0 (  5.6900   1.7396);
text '6' sr107 (  3.7774   1.1549);
pad '7' round 0 (  3.7445   4.6240);
text '7' sr141 (  2.4858   3.0697);
pad '8' round 0 (  0.5186   5.9274);
text '8' sr175 (  0.3443   3.9350);
pad '9' round 0 ( -2.8846   5.2040);
text '9' sr209 ( -1.9150   3.4547);
pad '10' round 0 ( -5.3015   2.7012);
text '10' sr243 ( -3.5195   1.7933);

Running this script in the Eagle PCB library editor produced the bulk of the following footprint:

Finished IV-12 VFD tube PCB footprint.

After running the script,  I added an outline of the tube, labeled the front, and added some notes about which pins should be connected to which supplies. While researching this project, I came across one note that said the displays appeared brighter when 1.5 V is connected to pin 2 and ground is connected to pin 3 rather than the other way around. I did not verify that guidance but decided to follow it anyway.

The drills for the pads are 1.95 or 2.00 mm in diameter. These holes accommodate Harwin H3161-01 pin sockets for 1 mm pins. These are press fit into the holes in the PCB then soldered into place. The tube pins are 1 mm in diameter and fit in these pins easily. I used 1.95 mm drills on the clock but would use 2.00 mm drills on future versions.

VFD Tube Socket Test Board

Test board to verify the placement of the sockets and how well the tube fits in the sockets.

After designing the schematic symbol and PCB footprint, I created a small test board to verify the placement of the sockets and how well the tube fits in the sockets. I powered on a segment on the tube to verify the location of the ground, heater, grid, and segment pins. Everything fit so I knew I had a good PCB footprint to use on the final clock board.

I included a Microchip HV5812 high-voltage display driver and Texas Instruments SN74LVC8T245 level shifter on the test board to test my circuit for controlling the tube but ultimately skipped testing the circuit before releasing the real boards.

Designing the Clock

Mechanical Design

My six tube IN-18 Nixie tube clock from 2018.

With the ground work out of the way, it was time to start designing the clock. I wanted to give it a similar aesthetic to the six-digit IN-18 Nixie tube clock shown above that I designed in 2018. The IN-18 clock uses a CNC’d anodized aluminum enclosure with some extruded aluminum profiles on either end to hold everything together. The dimensions of the end profiles are shown in the diagram below.

Front Panel Express enclosure profile #1 dimensions.

The “A” slots in the profiles are designed to hold 1.6 mm thick circuit boards. I wanted to decrease the depth and width of the VFD clock versus the Nixie clock. This would require using the slots in the profiles to hold the circuit board versus using screws through the top panel like I did on the Nixie clock. You can see the four screws to be eliminated on the top panel in the photo of the Nixie clock above.

Electrical Design

Next I turned my attention to the electrical hardware. The clock would require a microcontroller with Ethernet capable of using NTP to set the date and time, a display driver capable of sourcing 25 Volts, a bunch of power supplies, and use 802.3af/at for PoE/PoE+ for power.

Microcontroller

PIC18F67J60 minimal Ethernet circuit.

I decided to use the Microchip PIC18F67J60 for a microcontroller. The Microchip PIC18F67J60 includes both an internal Ethernet MAC and PHY and the Microchip Code Configurator includes software libraries for NTP. Most importantly, I had good luck with this microcontroller on my Ethernet-Powered Pixels project. This microcontroller requires a 3.3 V supply.

Display Segment Driver

HV5812 high-voltage output configuration.

To drive the segments on the VFD tubes, I used a Microchip HV5812 20-channel serial-input display driver. These display drivers have full totem-pole outputs and are rated for 80 V. The data sheet implies each output is capable of sourcing at least 25 mA. Since each segment requires only 3 to 5 mA at 25 V, these parts are more than adequate for driving the VFD tube segments. One HV5812 would be used for every two tubes.

The only downside is these parts require a 5 V supply and their inputs are referenced to this supply. If these parts were capable of running from 3.3 V, that would have eliminated the need for a 5 V power supply and level translator in this design.

Power Supplies

This design requires four power supply voltages. The tubes require 25 V and 1.5 V, the HV5812 drivers require 5 V, and the microcontroller requires 3.3 V. The 1.5 V, 3.3 V, and 5 V supplies will be powered from the 25 V supply. The 25 V supply will be powered from the 37 to 57 volt PoE supply.

I used CUI point-of-load, non-isolated DC/DC converters for the 1.5 V, 3.3 V, and 5 V supplies. The 3.3 V supply is a through-hole V7805-500 module. For the 1.5 V and 5 V supplies, I needed a shorter package than the V780x-500 and V780x-1000 modules so that the modules could fit between two boards separated by 11 mm. I used a V78E01-1000-SMT and V7805-500-SMT for the 1.5 V and 5 V supplies respectively. These are only 8.25 mm tall so they’ll easily fit between the two boards.

For the 25 V supply, I used a CUI PDQE20-Q48-S24-D isolated DC/DC converter. This module is a 24 V, 20 W converter and has a wide input voltage range of 18 to 75 V that will work with the PoE supply voltage of 37 to 57 V. This supply also has an adjustment input for fine tuning the voltage output. I ran through the math on the data sheet and figured with a resistor somewhere in the range of 55k, I could adjust the voltage output up to 25 V.

 802.3af PoE / 802.3at PoE+ Power

A bunch of different PoE+ PD components including two Molex PD jacks, two TI TPS2378 ICs, a TI TPS2378 evaluation board, and a Silvertel PoE+ PD 24 VDC module.

For this project, I decided to use a Molex 85791-4020 PD Jack for the 802.3at / PoE+ functionality. This Ethernet jack contains both integrated magnetics and Type 2 / Class 4 PoE+ classification circuitry. This one jack, shown on the left in the photo above, replaces most of the components on the evaluation board shown in the top-right of the photo.

Molex 85791-x020 PD Jack block diagram.

The jack, in addition to the integrated Ethernet magnetics, contains all the circuitry required to perform 802.3at / PoE+ classification. This includes the bridge rectifiers, transient suppression diodes, detection capacitance, detection resistance, and an integrated Microchip PD70200 PoE classification IC. The block diagram from the datasheet is shown above. These jacks are bulky and expensive but for a one-off, hand-built prototype like this VFD clock, the reduction in parts count and assembly time was worth it to me.

Power / Control Board Function Split

Block diagram of the clock project. The power / controller board contains the functions left of the dotted line. The tube / driver board contains the functions right of the dotted line.

Based on my experience designing the Nixie IN-18 clock, I knew the tube sockets, segment drivers, microcontroller, and power supplies would not fit on a single board and a two board stack would be required to hold all the components.

I decided to place the PoE and microcontroller circuitry and the 25 V and 3.3 V power supplies on a power / controller board and the level translator, segment drivers, tube sockets, and 1.5 V and 5 V power supplies on a tube / driver board. The boards are connected together using headers. The headers supply 25 V, a SPI interface, and the reference voltage for the SPI interface from the power / controller board to the tube / driver board.

This split would prove advantageous during board bring up because the power / controller board contains everything needed to run the microcontroller and the tube / driver board contains everything needed to power and control the tubes with a single 25 V supply and a SPI interface.

Tube / Driver Board Design

Schematic

Schematic of the tube / driver board.

The schematic for the tube / driver board is shown above. It consists of three main sections: power input, data input, and the tubes and drivers.

The main power input is 25 VDC on J1. This voltage feeds the 1.5 V and 5 V converters to generate the voltages needed for the tubes’ heaters and the display drivers.

The data input on J2 consists of clock, data, latch, and blank signals. The logic levels of these signals are referenced to the voltage on J2-6 which can range from 1.8 to 5 V. In the case of our design, this is 3.3 V. This board could be used unmodified with a 5 V output microcontroller like the one on an Arduino by connecting J2-6 to +5 V instead of +3.3 V.

The tube drivers are Microchip HV5812 serial input high-voltage display drivers. The data signals are daisy chained between the three parts while the clock, latch, and blank signals are connected in parallel to all the parts. The tubes use the tube library symbol and footprint previously designed and tested on the tube socket test board.

Board

Finished tube / driver board layout.

Once the schematic was done, I designed a board in Eagle PCB. The tube pin sockets are located on the bottom of the board and the tubes extend into the screen with their fronts facing toward the bottom of the screen. The power supplies, display drivers, connectors and passives are located on the top of the board. After the design was done, the board’s width was extended to mount the board in the slots on the extruded aluminum profiles that form the sides of the enclosure.

Tube board top.

I uploaded the design files to OSH Park and checked the board renders. Above is a render of the top side of the board.

Tube board bottom.

Above is a render of the bottom side of the board. Once I was happy with the renders and had verified the boards and their components fit in the enclosure using Fusion 360, I placed an order for the boards at OSH Park.

A Complication and Another Test Board

Open-drain, active-low power good to open-drain, active-low converter disable test board. Rated for 60 V operation.

One wrinkle to be solved before designing the power / control board was how to connect the Molex PD jack’s open-drain, active-low power good signal to the 24 V DC/DC converter’s active-low converter disable input.

The PD jack pulls its power good output low to indicate that the power is good and the external DC/DC converter should be enabled. The DC/DC converter has a converter disable input that disables the converter when it is pulled low.

I needed a circuit that will hold the converter disable input low while the power good signal is not pulled low and will release the converter disable input when the power good signal is pulled low. And the only power supply rail available is the 37 to 57 V PoE power.

Open-drain, active-low power good to open-drain, active-low converter disable test board schematic. Rated for 60 V operation.

I solved this problem by designing the circuit shown in the schematic above. Ignore R1, D1, C1, D3, and R4. When /PGOOD is open, it’s pulled high by R2. Zener diode D2 limits the voltage when /PGOOD is pulled high to 5.1 V so as not exceed Q1’s maximum VGS. In this case, Q1 conducts and connects the /CDB output to ground thus disabling the DC/DC converter. When /PGOOD is pulled low, the gate of Q1 is pulled low and Q1 stops conducting. The allows the /CDB output to float high and enables the DC/DC converter.

To test the circuit, I built a small test board. Only D2, R2, R3, and Q1 were stuffed on the test board. I connected the V+ and V- rails on the test board (TP1 and TP3 respectively) to a bench power supply set for 60 V. I connected the power outputs (TP4 and TP6) to the converter’s DC input and the /CDB output (TP5) to the converter’s converter disable input.

I then turned on the bench power supply and verified the converter’s output was disabled. After placing a jumper between /PGOOD (TP2) and V- (TP3), I verified the converter’s output was enabled. I disconnected and connected the jumper a few more times to verified the converter’s output was on only when the /PGOOD signal was connected to V-.

Power / Controller Board Design

Schematic

First page of the schematic for the power / control board.

After designing the tube board and verifying the converter enable/disable circuit, I designed the schematic for the power / control board. Page 1 of the schematic is shown above and page 2 of the schematic is shown below.

Second page of the schematic for the power / control board.

This is basically the same circuit that I used for the Ethernet-powered pixels project but with the following changes:

1. Ethernet jack, magnetics, and PoE classification circuitry have been replaced by the Molex PD Jack.
2. The addition of the /PGOOD to /CDB active-low, open-drain inverter circuit.
3. The 5 V, 20 W converter is now a 24 V, 20 W converter and its adjustment pin is connected to a variable resistor to permit adjustment of the output voltage up to 25 V.
4. The 25 V and 3.3 V power rails, the SPI data and clock, and two GPIO signals are routed to header sockets that connect to the tube / driver board.

After the schematic was complete I moved on to designing the board.

Board

Finished control board layout.

On the initial revision of the board, I had the power supply circuitry next to the Ethernet jack and the microcontroller on the right hand side of the board. I decided the Ethernet traces between the jack and the microcontroller were too long so I moved the microcontroller to the center of the board and moved the power supply circuitry to the right-hand side of the board.

The thick dashed white line is a 56 mil isolation gap between the PoE power circuitry and the isolated microcontroller circuitry. This board is less wide than the tube / driver board because it needs to fit between the extruded aluminum side profiles rather in the slots on the profiles.

Controller board top.

I uploaded the design files to OSH Park and checked the board renders. Above is a render of the top side of the board.

Controller board bottom.

Above is a render of the bottom side of the board. Once I was happy with the renders and had verified the boards and their components fit in the enclosure using Fusion 360, I placed an order for the boards at OSH Park.

Enclosure Design

Rear view of the PoE-powered VFD tube clock enclosure.

The enclosure was designed using Front Panel Express’s software, their enclosure design manual, and the side profile enclosure macros built into the software. Once the enclosure was designed, I exported DXF files from their software and imported them into Fusion 360.

Inside Fusion 360, I extruded the shapes in the DXF files into bodies with their actual thicknesses and assembled the enclosure. I used Eagle PCB’s integration with Fusion 360 to import my empty circuit boards into Fusion 360 and placed the boards in the enclosure. Rather than model all the components on the board, I placed only the larger components that I thought might cause interference with the boards or the enclosure.

Enclosure design showing boards and their position in the enclosure.

Above is an image captured in Fusion 360 showing the enclosure, the placement of the boards inside the enclosure, and the placement of the lager components on the boards. Once I was happy with the enclosure design, I ordered the panels from Front Panel Express.

Enclosure Test Fit

Test fit of the enclosure panels, boards, and Ethernet jack.

After what seemed like an eternity, my enclosure panels and circuit boards arrived. I assembled the enclosure but left the front panel off then bolted the two boards together using M3 x 11 mm spacers and placed the Ethernet jack in its footprint on the power / control board. I slid the boards into the top slot of the enclosure and the Ethernet jack aligned perfectly with the cut out in the rear panel.

I failed to account for the tabs that OSH Park uses to panelize their customers’ boards together though. I had to use a file to file down the tabs to get a smooth edge on all the boards for them to fit in the enclosure. Next time I would bring each of the two long edges in 0.25 mm (0.5 mm narrower total) to cut down on the amount of filing I had to do and account for OSH Park’s manufacturing tolerances.

Tube / Driver Board Bring Up

I decided to stuff and bring up the tube / driver board first. I populated the ICs, followed by the DC/DC converters, passives, and pin headers. While soldering these, I taped off the pin socket holes so I wouldn’t accidentally drag the iron across them and fill any of the holes with solder. Cleaning them out well enough to insert the socket pins would be difficult.

Once all the other parts were soldered on the board, I pushed the 60 pin sockets through the holes on the board. I had to use a make shift tool (broken chopstick) and some force to seat them in their holes. Next time, I’d use at least a 2.00 mm drill instead of a 1.95 mm drill for the holes to make inserting the pin sockets easier. Lastly, I soldered the pins in place.

To bring up and test the board, I used my Keysight bench power supply and a Particle Photon board. I set the bench power supply to supply 25 V at 100 mA and 5 V at 350 mA. I connected the 25 V to the power header on the tube / driver board and the 5 V to the micro USB connector on the Particle Photon.

I then connected the ground, SPI clock and data lines, and two GPIOs from the Particle Photon to the data connector on the tube board. I also connected the Particle Photon’s 3.3 V output to the 3.3 V input on the data connector to supply the input side of the level translator IC on the tube / driver board.

With the hardware connections complete, I turned to writing some software to permit the display of numeric strings on the tubes. The hardest part of this was mapping the 64 bits sent using the SPI interface to the 42 segments of the VFD tubes.

After figuring out the mapping, I wrote a function to display a numeric string on the tubes and registered it with the Particle Cloud. I could then use the Particle Console to send a string like “123456,” “——,” or “******” to display on the tubes. Any character place with a ‘*’ shows the spinning segments animation. The result of this effort is shown in the video above. Success!

Power Supply Bring Up and Adjustment

Power supply bring up successful!

After bringing up the tube / driver board successfully, I decided it was time to focus on the PoE and power supply circuitry. I stuffed the PoE and power supply components on the power / control board and attached a DMM to the +24 V and ground test points.

I connected the board to my Ethernet switch. After a second or two, the LEDs lit indicating the 24 V and 3.3 V supplies were operating. I used a small screwdriver to adjust the 25-turn variable resistor until the DMM read 25 volts. I then moved the DMM to the +3.3 V test point and verified the 3.3 V supply was really 3.3 volts.

Power / Control Board Bring Up

Power / control board microcontroller bring up successful!

Finally it was time to stuff the microcontroller and Ethernet parts on the power / control board. This is a tedious process because of the sheer number of passives. To aid in the process, I put the reference designators from the schematic in the customer data field when placing my Digi-Key order. This way each of the bags of passives was labeled with where they went on the circuit board. Genius.

After stuffing the board, I connected my MPLAB REAL ICE programmer and a 3.3 V serial cable to the board and downloaded the software from the Ethernet-powered pixels project to the board. I watched on the serial console as the board booted and obtained an IP address via DHCP from my router.

This was enough to prove almost all of the hardware worked. I connected the boards together and placed them inside the enclosure. I left the front of the enclosure off so that the serial cable and debugger could stay connected. It was all software now.

The Software

I used the Microchip Code Configurator to build a new project for the PIC18F67J60 microcontroller. I enabled all the Ethernet protocols this time: DHCP, DNS, UDP, TCP, NTP, and LLDP. To make the code that handles the interaction between the display tubes and the IP protocols easier to follow, I moved some of the higher-level code that deals with the sequencing of DHCP, DNS, NTP, and LLDP operations out of the network_manage function and in to the main function.

At boot, the software initializes the microcontroller’s peripherals, turns all the VFD tube segments off, and reads its Ethernet MAC address from a Microchip 25AA02E48 serial EEPROM with built-in globally unique Ethernet MAC address. After initialization is complete, the software spins the segments on the tubes until an IP address and DNS server IP address are assigned to the clock using DHCP. The software then displays the IP address twice and the DNS server IP address twice. The video above shows an early version of the software that gets an IP address for the clock via DHCP and displays it three times.

While the IP addresses are scrolling, the software is performing a DNS query to pool.ntp.org to get the IP address of an NTP time server. Once received, the NTP server IP adresss is displayed and the NTP server is queried for the current date and time. The received date and time is set then updated once per second using the 25 MHz SiTime MEMS oscillator for the time base.

The software applies time zone and daylight savings time correction to the received time and scrolls that across the tubes. After two scrolls of the date and time, the clock goes into “be a clock” mode where it displays the current TZ and DST corrected time on the tubes until the next reboot. Once an hour, a new NTP server is requested from pool.ntp.org and the time is re-synchronized.

The Finished Clock

Finished and assembled clock. Front view.

Front view of the finished clock with the Ethernet cable connected.

Finished and assembled clock. Rear view.

Rear view of the finished clock with the Ethernet cable connected.

Internal view of the clock with the debugger and serial console cable still connected.

Interior view of the finished clock with the Ethernet cable connected.

Ideas for the Future

I’m thinking about upgrading the power / control board to use an ATSAMD21 with the Wiznet W5500 Ethernet PHY/MAC. This processor would have enough power to allow the clock to make RESTful queries to NOAA and the NWS to display the current temperature or forecast temperatures in addition to the time. The PIC18F67J60 could make these queries too but the XML formatted responses might be tough to parse with the limited memory on the PIC18.

Design Files

The design files for this project are on Github. You can reach me about any missing files or other questions on Twitter @bikerglen.

Motivation

Philips Color Kinetics iColor Flex LMX setup with the AC power data supply, proprietary leader cable, and 50 pixels.

A few weeks ago, I wrote a post where I reversed engineered some Philips Color Kinetics iColor Flex RGB LED string lights. These lights require an AC power data supply that supplies 24 volts to power the pixels and transforms DMX or UDP packets of pixel data into the protocol used by the pixels. In addition to the power supply, the pixels require a proprietary leader cable to connect them to the power supply.

In a typical setup, you have to run AC mains power and Ethernet data to the power supply then run the leader cable to the pixels. To avoid having a large stack of power data supplies in larger setups, Color Kinetics makes a rack mount power supply that can power up to eight strings of lights. This rack mount power supply still requires a leader cable for each string of lights.

I’ve been wanting to build an 802.3af/at/bt Power over Ethernet design for a few years now and have always come up short on ideas and then it hit me, what if the Ethernet cable could connect closer to the pixels in the photo above? With a small box of electronics between the Ethernet cable and the connector on the end of the pixels, the pixels could receive both power and data from the Ethernet switch. No more AC mains wiring and no more proprietary leader cables.

802.3af/at/bt Power over Ethernet

Many Power over Ethernet schemes involve connecting the spare pairs in an Ethernet cable to an always-on 12 VDC or 24 VDC power supply. At the other end of the Ethernet wiring, the spare pairs are connected to a DC/DC converter that generates the voltages required by the device. This is fraught with problems and is not real Power over Ethernet!

802.3af/at/bt Power over Ethernet only supplies power to a device once a device detection and classification process completes. This process is a hardware handshake between the power sourcing equipment (PSE) and the powered device (PD). During the handshake, the PSE communicates its power sourcing capabilities to the PD and the PD communicates its power requirements to the PSE. If the PSE is capable of supplying the amount of power required by the PD, power is connected to the PD.

While the PD is powered, the PSE continuously monitors the current draw of the PD. If the current draw drops too low for too long, the PSE assumes the PD was disconnected and shuts down power to the PD. This process ensures power is only supplied to standards-compliant devices and only while those devices are connected.

In addition to the hardware handshake, Power over Ethernet can use Link Layer Discovery Protocol (LLDP) to communicate a PD’s power requirement to the PSE with greater resolution than permitted by the hardware handshake. For example, a device could complete the handshake indicating it is an 802.3at PoE+ compliant device but use LLDP to tell the connected switch it only requires 20 watts instead of the maximum 25.5 watts. This can potentially reduce the number of Ethernet switches required in large installations if the switches do not need to assume every device will always consume its maximum power.

The table above is copied from the Wikipedia page on Power over Ethernet. It shows the 4 main types of Power over Ethernet and the amount of power each is capable of delivering to a PD. Also shown are the voltages a PD will see at its Ethernet jack based on the voltage supplied by the PSE, the maximum current draw of the PD, and the maximum resistance in 100 meters of Cat 3 (Type 1) or Cat 5 (Type 2 to 4) Ethernet cabling.

Type 1 and Type 2 PoE can use either the 10/100 Mbps data pairs or the 10/100 Mbps spare pairs for supplying power. It’s up to the switch to decide which set of pairs so the powered device must support using either set. Type 3 and Type 4 PoE use all four pairs for supplying power. All four PoE types work with all speeds of Ethernet, 10/100 Mbps as well as 1/2.5/5/10 Gbps.

For more information on Power over Ethernet, I highly recommend the Power over Ethernet Wikipedia page, section 7.4.1 of the Texas Instruments TPS2378 IEEE 802.3at PoE+ Interface data sheet (PDF), and the Silicon Labs Si3404/06x PoE-PD Controller Design Guide (PDF).

Feasibility and Scaling Back Ambitions

Artist’s depiction of two Ethernet to iColor Flex PoE power data supplies.

Getting back to my design, I pictured a small box with a waterproof Ethernet connector on one end and an Amphenol LTW waterproof connector for the pixels on the other end like the boxes in the artist’s rendering above. Inside the box would be 802.3af/at/bt classification circuitry, a power supply capable of delivering 62 watts at 24 volts, a microcontroller with Ethernet, and an FPGA to generate the Chromasic protocol data for the lights.

Referring to the chart of PoE capabilities in the previous section on standards-compliant Power over Ethernet, supplying 62 watts to the iColor Flex lights would require using 802.3bt Type 4 PoE and having an efficiency exceeding 87%. I felt this was certainly technically feasible but a bit too ambitious for my first PoE design. I also do not have an 802.3bt capable Ethernet switch yet. Time to scale back my ambitions a bit.

The next thought was to scale back to using iColor Flex MX pixels that require 22.5 watts at 7.5 volts. This could be powered using 802.3at PoE which is capable of delivering 25.5 watts to the powered device. This would require being over 88% efficient and I’d have to design a 7.5 volt wide input range buck converter too. I still felt this was a bit too ambitious.

A string of 50 RGB pixels on the left and a strip of 60 RGB pixels on the right.

The next step down in power consumption and complexity were the ubiquitous WS2812 RGB LEDs. Adafruit sells these in one meter strips of 60 RGB LEDs and Light-O-Rama sells these as five meter strings of 50 RGB pixels. Both of these consume 60 mA per bulb at 5 volts which is 0.3 watt per LED. A strip of 60 Neopixels consumes 18 watts maximum. The string of 50 from Light-O-Rama consumes 15 watts maximum.

15 and 18 watts easily falls within the 25.5 watt maximum for 802.3at PoE+. In addition, the WS2812 LEDs have significantly relaxed timing requirements compared to the iColor Flex LEDs. This allows the pixels to be controlled in software and eliminates the requirement for an FPGA to drive the pixels. Finally, the pixels run from 5 VDC. Since 5 VDC isolated switching DC/DC converter modules are common, I will not need to design a custom power supply as part of the project.

Over the course of a few hours, I talked myself down from building an 802.3bt 62 watt PD with an FPGA in a waterproof enclosure to building a much simpler proof-of-concept that uses 802.3at PoE+ for power and controls up to 60 WS2812 pixels in software. WS2812 pixels will be a great starting point for a project that can both power and control a string or strip of lights over Ethernet.

Electrical Isolation

The 802.3af/at/bt PoE standards require electrical isolation between the power interface and all user-accessible conductors including the frame ground. In a large commercial building, there could be 100 meters of Ethernet cable between the switch and the powered device with the result that the grounds at each end of the Ethernet cable have a large voltage difference between them. Without isolation, current would flow over the Ethernet cable which is both a safety issue and an electrical noise issue.

A lot of designs like PoE-enabled network cameras, Wi-Fi access points with internal antennas, and ceiling troffer LED lights have no user accessible conductors and therefore can use a non-isolated design. In this case, the enclosure and the lack of user-accessible conductors acts as the isolation required by the standard.

Other designs like Wi-Fi access points with external antenna connectors or building access controls with connections for locks and card readers require an isolated design. My design is going to have a connector for the WS2812 pixels so technically it requires an isolated design.

For both isolated and non-isolated designs, the 802.3 Ethernet standards require a transformer between the Ethernet jack and the Ethernet PHY. For isolated PoE designs, isolation is also required in the board layout, in the feedback loop in the power supply circuit, and in any status indicators between the PoE classification circuitry and the microcontroller. Isolated designs are therefore more complicated and more expensive than non-isolated designs.

Isolated designs do have an advantage during development and testing though. Programmers, debuggers, logic analyzers, oscilloscopes, and other test equipment can be connected to the isolated portions of the design without risk to the user or equipment. With a non-isolated design (or to debug the power interface side of an isolated design), you might need a battery-powered laptop to connect the debugger to the microcontroller, high-voltage differential probes for an oscilloscope, or a handheld oscilloscope with isolated input channels.

Design Requirements

Taking into account the selected pixels and the need for an isolated PoE design, here’s the basic list of requirements for my design:

• Use standards-compliant 802.3at PoE+ classification circuitry.
• Use less than 25.5 watts total power to stay within the 802.3at PoE+ power envelope.
• Use an isolated power supply design capable of supplying 20 watts at 5 volts. 15 to 18 watts will be available for the WS2812 pixels. Two watts will be available for the support circuitry including the microcontroller.
• Use transformers, optocouplers, and appropriate trace spacing to maintain isolation between the power interface circuitry and the remainder of the device.
• Use an Ethernet-capable microcontroller to reduce parts count and design complexity.
• Use easy to hand-solder SMD packages with no inaccessible pins, leads, or pads. One of these days, I’ll have to learn to solder/reflow DFN/QFN packages with exposed thermal pads, but I’m not there yet.

Selecting the PoE Controller

A bunch of different PoE+ PD components including two Molex PD jacks, two TI TPS2378 ICs, a TI TPS2378 evaluation board, and a Silvertel PoE+ PD 24 VDC module.

The 802.3af PoE standard was ratified in 2003 and the 802.3at PoE+ standard was ratified in 2009. The relative age of the standards means there’s tons of great PoE/PoE+ silicon and modules on the market.

Texas Instruments, Analog Devices, Microchip Technology, and Silicon Labs all make PoE PD controller silicon. All these chips handle classification. Many of these chips include integrated transistor switches to control power to the user’s circuitry. Some of these chips even include switch mode power supply controllers to step down the incoming voltage to the user’s required voltage.

Silvertel makes complete PoE modules capable of delivering from 13W to 99W to a PD. These modules handle classification, isolation, and include a DC/DC converter to step the input voltage down to a more usable 12 or 24 volts. Molex even makes Ethernet jacks with integrated magnetics and PoE/PoE+ classification circuitry. These jacks use the Microchip / Microsemi PD70200 controller.

802.3at PoE+ powered device controller and classification circuit.

After reading datasheets for what felt like weeks, I settled on the TI TPS2378 802.3at PoE+ PD controller. It performs PoE+ detection and classification, includes an internal pass MOSFET with inrush current limiting, comes in a relatively easy to solder SOIC-8 package with an exposed thermal pad, and requires minimum external components.

The schematic above shows the basic circuit. Bridge rectifiers BR1 and BR2 rectify the voltage from the Ethernet jack since the input voltage is of unknown polarity. C1, L1, and L2 are an EMI/EMC filter. Zener diode D1 provides transient protection. C2 provides the minimum load capacitance required by the PoE specifications. R1 and R2 set the detection current and classification current respectively.

TI TPS2378 startup sequence from the datasheet.

Figure 19 from section 7.4.3 of the TPS2378 datasheet (reproduced above) shows the detection, classification, inrush current limiting, and startup sequence. When the input voltage is between 1.4 and 10.9 volts, the TPS2378 generates a detection signature. Once the PSE sees the detection signature, the PSE supplies a voltage between 10.9 and 22 volts. This is the classification phase and the TPS2378 generates a classification current between 36 and 44 mA to indicate it is a 802.3at PoE+ Type 2 / Class 4 device. For 802.3at this step is performed twice with a mandatory return to the detection current between each classification pulse.

Once classification is complete, the PSE supplies full power to the PD and the TPS2378 turns on the internal pass MOSFET but in an inrush current limiting mode. This limits the input current to about 140 mA and allows the bulk capacitors in the downstream power supply circuit to charge. Once the current through the pass MOSFET drops below 125 mA, inrush current limiting is turned off, the converter disable pin is de-asserted, and the user’s circuitry can run.

If 802.3at/PoE+ classification was successful, the T2P pin will be asserted and the user’s circuitry can run at full power. If 802.3at/PoE+ classification was not successful, the T2P pin will be de-asserted and the user’s circuitry must stay within the 802.3af PoE power envelope.

Selecting the Power Supplies

Isolated wide-input range to 5 VDC switching power supply module (top) and 3.3 VDC non-isolated switching power supply module (bottom).

The next step was to select an isolated DC/DC converter that has an input range of 37 to 57 VDC, a 5 VDC output, and a 20 watt power rating. The CUI PDQE20-Q48-S5-D meets these specifications. It has a nominal input voltage of 48 volts but works with a range from 18 to 75 volts. It is rated for 20 watts, is isolated, and has an efficiency of 90%. It comes in a 1″ by 1″ form factor module. The converter requires a 100 uF input capacitor and a 100 uF output capacitor for stable operation. It also has an active-low disable input that can be connected directly to the TPS2378’s CDB pin to keep the converter disabled until the bulk input capacitor is charged.

The microcontroller requires 3.3 VDC at about 250 mA. to operate. This is supplied by a CUI V7803-500 non-isolated switching regulator. It has an input range from 4.75 to 28 VDC and is connected to the output of the 5 VDC isolated converter. It requires a few capacitors to operate as well. I included a few LEDs to indicate the 5 VDC and 3.3 VDC power supplies are operational.

Selecting the Ethernet Microcontroller

PIC18F67J60 minimal Ethernet circuit. Pay particular attention to Note 4 for Power over Ethernet applications.

The next step was to select a microcontroller to receive Art-Net UDP packets of pixel data and output the pixel data to the WS2812 LEDs. Most Ethernet microcontrollers only include Ethernet MAC functionality and require an external Ethernet PHY. The Microchip PIC18F67J60 microcontroller includes both an internal Ethernet MAC and PHY. This reduces the parts count and board area needed by the design.

The basic schematic from the data sheet is shown in the schematic above. I added some ESD protection circuitry as shown in the Microchip Ethernet of Everything reference design (PDF). The PIC18F67J60 is limited to 10 Mbps Ethernet but sixty 24-bit WS2812 pixels updated at 40 Hz only require 57,600 bits per second of data to operate.

Other Circuitry of Note

Here’s a brief examination of some of the other circuitry in the design.

Optically Isolated AT Classification Indicator

T2P flag isolation circuitry.

The TPS2378 asserts T2P low if 802.3at/PoE+ classification is successful. An optoisolator is used to isolate this signal and make it available to the microcontroller. When ISO_T2P is asserted low indicating the PD can draw up to 25.5 watts of power, the microcontroller can enable the WS2812 pixels.

3.3 VDC to 5 VDC Level Translator for WS2812 LEDs

The 3.3 VDC to 5 VDC level translator and transient protection circuitry used to drive the WS2812 LEDs.

The microcontroller has 3.3 VDC outputs but the WS2812 LEDs have inputs referenced to 5 VDC. These generally work ok from 3.3 VDC but I added a Texas Instruments Little Logic single gate buffer to translate the 3.3 VDC output from the microcontroller up to 5 VDC. The resistor and diode array protect the microcontroller and buffer from transients on the WS2812 data line.

SiTime MEMS Oscillator

I’m using a SiTime MEMS oscillator to generate the 25 MHz clock for the microcontroller. This oscillator comes in a small but still easy-to-solder SOT23-5 package. Digi-Key programs them to the purchaser’s needed frequency on demand or you can buy a stock of blank parts and use the SiTime programmer to program them as needed.

Globally Unique MAC Address

Purchasing a block of MAC addresses for maker projects is not feasible. Instead I’m using a Microchip EUI-48 serial EEPROM that contains a pre-provisioned, globally-unique, and write-protected MAC address. The alternative for devices that will not be used outside your local network is to use a locally administered address from one of the locally administered address pools.

Finished Schematic

Here is the finished schematic. It’s two pages. Page 1:

Finished schematic, page one.

Page 2:

Finished schematic, page two.

Finished Board

The finished board.

The image above shows the finished board. The thick dashed line shows the 56 mil space required to isolate the power interface circuitry on the left of the line from the user circuitry on the right of the line. The only components crossing the line are a filter capacitor rated for 2000 volts, the Ethernet magnetics, the T2P optocoupler, and the isolated DC/DC converter. All these parts provide DC isolation between the two halves of the board.

The next step was to upload the boards to OSH Park, check the renders, and order the boards.

OSH Park render of the top of the board.

The image above is an OSH Park render of the top of the board.

OSH Park render of the bottom of the board.

The image above is an OSH Park render of the bottom of the board.

Future Board Revisions

While these boards were being manufactured, a helpful Twitter user pointed out some revisions I could make to improve the EMI/EMC performance and some other minor changes to the board. Here’s the list of changes for future board versions:

• Change PIC18 ground traces to vias to 9 mil width.
• Change all other ground traces to vias to 20 mil width.
• Change the 3.3 V bridges between 3.3 V fills to 20 mil width.
• Change PIC18 pin 10 (VDDCORE) and 9 (GND) traces to 9 mil width.
• Move PIC18 pin 9 (GND) via to far side of capacitor. Make the trace 20 mil wide.
• Change TD_CT / filtered 3.3 V traces to 8 mil width between caps and PIC18.
• Changed 5V trace to a pour / fill.
• Increase separation of VPPIN to RTN to 25 mil per section 7.3.9 of TPS2378 data sheet.
• More vias on thermal pad.
• Use schottky diodes instead of bridge rectifiers for greater efficiency.
• Investigate routing 3.3 V power on top layer and adding a ground fill / pour on the top layer stitched to the bottom layer.
• Use jack with integrated magnetics or integrated magnetics and PD circuitry.
• Improve isolation / spacing between power interface circuitry and frame ground.

Software Development

The Olimex PIC-WEB board I used for software development while waiting for my boards.

While the boards were being manufactured, I started software development using an Olimex PIC WEB development board. The Ethernet hardware and software on this board is functionally identical to the Ethernet hardware and software on my board so it was a good platform to use for software development until my boards were available.

Microchip Code Configurator

I created a new PIC18F67J60 project in the MPLAB X IDE then used the Microchip Code Configurator (MCC) to generate the basic timer, EUSART, and TCP/IP Ethernet code for the project.

In the system tab, I enabled TMR1 interrupts, assigned the EUSART1 TX1 and RX1 pins, and configured an external 25 MHz clock on the primary OSC pins. In the libraries tab, I added the TCP/IP Lite library and enabled the UDP, DHCP, IPV4, ICMP, and ARP protocols. In the MAC tab, I selected ETHxxJ6x since I’m using the Ethernet MAC built into the device. I also configured a locally administered MAC address until I had an opportunity to enable the EUI-48 serial EEPROM. I added the TMR1 and EUSART1 peripherals then enabled the TMR1 interrupt to occur every 40 ms and the callback function to be called once per second. The EUSART was configured for 9600 bps and STDIO was redirected to USART. I clicked the generate tab to generate the initial code base.

Once the code was generated, I opened up main.c, removed the comments to enable interrupts, and added a call to Network_Manage () inside the while loop inside the main function. I built the project and downloaded it to the PIC-WEB board. It started running and eventually grabbed an IP address from my DHCP server. At this point I could ping the board but that’s about it.

Adding Art-Net UDP Receive

Next I added code to receive Art-Net packets over the network to the project. I created a udp_rx_artnet.h file with the following code:

#ifndef _UDP_RX_ARTNET_H
#define _UDP_RX_ARTNET_H

void UdpRxArtNetInit (void);
void UdpRxArtNetRecv (int16_t length);

#endif    //_UDP_DEMO_H

Then I created a udp_rx_artnet.c file with the following code:

#include <stdint.h>
#include "udp_rx_artnet.h"
#include "ws2812b.h"
#include "mcc_generated_files/TCPIPLibrary/udpv4.h"
#include "mcc_generated_files/TCPIPLibrary/tcpip_config.h"
#include "mcc_generated_files/pin_manager.h"


void UdpRxArtNetInit (void)
{
    // nothing to do here
}


void UdpRxArtNetRecv (int16_t length)
{
    uint8_t i;
    uint8_t leds;
    uint8_t r, g, b;
    
    if (length >= 18) {
        for (i = 0; i < 18; i++) {
            UDP_Read8 ();
        }
        
        length = length - 18;
        if (length > NUM_CHANS) {
            length = NUM_CHANS;
        }
        leds = length / 3;
        length = 3 * leds;
        
        for (i = 0; i < length; i+=3) {
            r = UDP_Read8 ();
            g = UDP_Read8 ();
            b = UDP_Read8 ();
            ledData[i+0] = gamma8[g];
            ledData[i+1] = gamma8[r];
            ledData[i+2] = gamma8[b];
            
        }
        
        for (; i < 150; i++) {
            ledData[i] = 0;
        }
        
        WS2812b_Write ();
        printf ("+");
        LATEbits.LATE4 = ~LATEbits.LATE4;
    }
}

It’s not the world’s most robust Art-Net receive code but it’ll work for proof of concept purposes. Next I added the UdpRxArtNetRecv function to the UDP callback table in MCC_Generated_Files/TCPIPLibrary/udpv4_port_handler_table.c:

const udp_handler_t UDP_CallBackTable[] = \
{    
    {68, DHCP_Handler},     
    {0x1936, UdpRxArtNetRecv},
};

Then inside main.c I added a call to UdpRxArtNetInit () to initialize the Art-Net receiver. I rebuilt the project and downloaded the code. (The first version of the code called printf’s to display the first few bytes of received RGB data rather than calling WS2812b_Write as shown in the listing above.) I then used my PC to generate Art-Net packets with 60 LEDs (180 channels) of data and send those to the PIC-WEB board. The printf’s showed the sent levels and it was time to move on to controlling the pixels.

Controlling the Pixels

In the past, I’ve used an FPGA to generate perfect WS2812 LED pixel timing. I did not use an FPGA on this project and instead used software to bit bang the protocol to the LEDs. Fortunately, the LEDs are quite tolerant to deviations from the timing specified in the data sheet and I had no issues controlling them.

The ws2812b.h header file:

#ifndef WS2812B_H
#define    WS2812B_H

#ifdef    __cplusplus
extern "C" {
#endif

#define NUM_LEDS 60
#define NUM_CHANS (3*NUM_LEDS)
    
#define WS2812b_LAT LATBbits.LB2
#define WS2812b_TRIS TRISBbits.TRISB2

void WS2812b_Init (void);
void WS2812b_Write (void);

extern uint8_t ledData[NUM_CHANS];
extern const uint8_t gamma8[256];

#ifdef    __cplusplus
}
#endif

#endif    /* WS2812B_H */

The ws2812b.c source file:

#include <stdint.h>
#include "mcc_generated_files/mcc.h"
#include "ws2812b.h"


const uint8_t gamma8[] = {
    0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
    0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  1,  1,  1,  1,
    1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  2,  2,  2,  2,  2,  2,
    2,  3,  3,  3,  3,  3,  3,  3,  4,  4,  4,  4,  4,  5,  5,  5,
    5,  6,  6,  6,  6,  7,  7,  7,  7,  8,  8,  8,  9,  9,  9, 10,
   10, 10, 11, 11, 11, 12, 12, 13, 13, 13, 14, 14, 15, 15, 16, 16,
   17, 17, 18, 18, 19, 19, 20, 20, 21, 21, 22, 22, 23, 24, 24, 25,
   25, 26, 27, 27, 28, 29, 29, 30, 31, 32, 32, 33, 34, 35, 35, 36,
   37, 38, 39, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 50,
   51, 52, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 66, 67, 68,
   69, 70, 72, 73, 74, 75, 77, 78, 79, 81, 82, 83, 85, 86, 87, 89,
   90, 92, 93, 95, 96, 98, 99,101,102,104,105,107,109,110,112,114,
  115,117,119,120,122,124,126,127,129,131,133,135,137,138,140,142,
  144,146,148,150,152,154,156,158,160,162,164,167,169,171,173,175,
  177,180,182,184,186,189,191,193,196,198,200,203,205,208,210,213,
  215,218,220,223,225,228,231,233,236,239,241,244,247,249,252,255 };

uint8_t ledData[NUM_CHANS];


void WS2812b_Init (void)
{
    WS2812b_LAT = 0;
    WS2812b_TRIS = 0;
}


void WS2812b_Write (void)
{
    uint8_t i, j, a;
    
    INTERRUPT_GlobalInterruptDisable();
    INTERRUPT_PeripheralInterruptDisable();

    for (i = 0; i < NUM_CHANS; i++) {
        a = ledData[i];

        // 7
        if (a & 0x80) {
            WS2812b_LAT = 1;
            NOP();
            NOP();
            NOP();
            NOP();
        } else {
            WS2812b_LAT = 1;
            NOP();
        }
        WS2812b_LAT = 0;

        // 6
        if (a & 0x40) {
            WS2812b_LAT = 1;
            NOP();
            NOP();
            NOP();
            NOP();
        } else {
            WS2812b_LAT = 1;
            NOP();
        }
        WS2812b_LAT = 0;

        // 5
        if (a & 0x20) {
            WS2812b_LAT = 1;
            NOP();
            NOP();
            NOP();
            NOP();
        } else {
            WS2812b_LAT = 1;
            NOP();
        }
        WS2812b_LAT = 0;

        // 4
        if (a & 0x10) {
            WS2812b_LAT = 1;
            NOP();
            NOP();
            NOP();
            NOP();
        } else {
            WS2812b_LAT = 1;
            NOP();
        }
        WS2812b_LAT = 0;

        // 3
        if (a & 0x08) {
            WS2812b_LAT = 1;
            NOP();
            NOP();
            NOP();
            NOP();
        } else {
            WS2812b_LAT = 1;
            NOP();
        }
        WS2812b_LAT = 0;

        // 2
        if (a & 0x04) {
            WS2812b_LAT = 1;
            NOP();
            NOP();
            NOP();
            NOP();
        } else {
            WS2812b_LAT = 1;
            NOP();
        }
        WS2812b_LAT = 0;

        // 1
        if (a & 0x02) {
            WS2812b_LAT = 1;
            NOP();
            NOP();
            NOP();
            NOP();
        } else {
            WS2812b_LAT = 1;
            NOP();
        }
        WS2812b_LAT = 0;

        // 0
        if (a & 0x01) {
            WS2812b_LAT = 1;
            NOP();
            NOP();
            NOP();
            NOP();
        } else {
            WS2812b_LAT = 1;
            NOP();
        }
        WS2812b_LAT = 0;
    }

    INTERRUPT_GlobalInterruptEnable();
    INTERRUPT_PeripheralInterruptEnable();
}

I placed the call to WS2812b_Write inside the Art-Net UDP receive function and a call to WS2812b_Init inside my main function. The lights did not work quite right on the first try. This code required an oscilloscope and a few tries to get the timing good enough to reliably control the LEDs. Eventually though, I could reliably control the LED colors and brightness from Art-Net UDP packets sent from either my PC or my iPad.

Serial EEPROM and MAC Address

The PIC-WEB board does not have an EUI-48 serial EEPROM so I had to use a locally administered MAC address for the initial software development. Once I got my boards back, I wrote some SPI code to read the MAC address from the serial EEPROM and use this address instead of the MAC address configured in the MCC generated header file.

spi1.h:

#ifndef SPI1_H
#define    SPI1_H

#ifdef    __cplusplus
extern "C" {
#endif

void spi1_Init (void);
uint8_t spi1_ExchangeByte (uint8_t in);

#ifdef    __cplusplus
}
#endif

#endif    /* SPI1_H */

spi1.c:

#include <xc.h>
#include <stdint.h>
#include <stdio.h>
#include "spi1.h"

void spi1_Init (void)
{
    SSP1CON1bits.SSPEN1 = 0;

    TRISBbits.TRISB4 = 0; // e48 csb - output
    LATBbits.LATB4   = 1; // e48 csb - set to high / not asserted
    TRISCbits.TRISC3 = 0; // sck     - output
    TRISCbits.TRISC4 = 1; // miso    - input
    TRISCbits.TRISC5 = 0; // mosi    - output

    SSP1STATbits.CKE = 1;
    SSP1STATbits.SMP = 1;    
    SSP1CON1 = 0x02;
    SSP1CON2 = 0x00;
    SSP1CON1bits.SSPEN = 1;
}

uint8_t spi1_ExchangeByte (uint8_t data )
{
    SSP1BUF = data;
    while(!PIR1bits.SSP1IF);
    PIR1bits.SSP1IF = 0;
    return SSP1BUF;
}

Finally the code to read the MAC address from the serial EEPROM.

mac_eeprom.h:

#ifndef MAC_EEPROM_H
#define    MAC_EEPROM_H

#ifdef    __cplusplus
extern "C" {
#endif

#define MAC_ADDR_48                 0xFA
#define MAC_ADDR_64                 0xF8

/***************** 25AA02E48 Instruction Set Summary *********************/
#define MAC_EE_READ     0x03
#define MAC_EE_WRITE    0x02
#define MAC_EE_WRDI     0x04
#define MAC_EE_WREN     0x06
#define MAC_EE_RDSR     0x05
#define MAC_EE_WRSR     0x01

void e48_read_mac(uint8_t *mac);

#ifdef    __cplusplus
}
#endif

#endif    /* MAC_EEPROM_H */

mac_eeprom.c:

#include <xc.h>
#include <stdint.h>
#include <stdio.h>
#include "spi1.h"
#include "mac_eeprom.h"

// e48_Csb on RB4
// SCK on SCK1/RC3
// MISO on SDI1/RC4
// MOSI on SDO1/RC5

void e48_read_mac(uint8_t *mac)
{
    uint8_t i;
    
    // set cs low
    LATBbits.LATB4   = 0;
    
    spi1_ExchangeByte (MAC_EE_READ);
    spi1_ExchangeByte (MAC_ADDR_48);
    
    for (i = 0; i < 6; i++) {
        mac[i] = spi1_ExchangeByte (0x00);
    }
    
    // set high low
    LATBbits.LATB4   = 1;
    
    // printf("macAddr:%.2X:%.2X:%.2X:%.2X:%.2X:%.2X \r\n", mac[0],mac[1],mac[2],mac[3],mac[4],mac[5]);
}

That’s a brief summary of the code I have written for this project to date. Eventually, I will need to add LLDP to specify the power requirements of my board with a bit more granularity. A follow on project may require HTTP requests and NTP as well.

Bring Up and Testing

Bringing up the PoE+ PD circuitry and power supplies.

Once the boards arrived, I mounted the components required for PoE+ classification and the power supplies to the board as shown in the photo above. Initially the PoE classification failed every time. The switch would try twice about every three seconds. Some LEDs on the board would light briefly but classification would fail and the power supplies would not be turned on.

Eventually I traced the problem to a resistor and an LED I put across the output of the bridge rectifiers to try to indicate when the switch was supplying power to the board. This does not work. The current consumed by the LED in parallel with the detection and classification currents is not within the specs required for the detection and classification currents.

I removed the resistor and LED then detection and classification completed successfully. The 802.3at / PoE+ T2P LED lit then the 5 VDC and 3.3 VDC power supply LEDs lit. I used a multimeter to measure the 5 VDC and 3.3 VDC outputs. They were in spec so I proceeded to mount the microcontroller and the rest of the components.

My switch indicating the board is receiving power and has a valid IP address. This was before I was using the EUI-48 serial EEPROM to configure a MAC address.

Once the rest of the components were mounted, I downloaded the software I developed using the Olimex PIC-WEB board to my board. Everything more or less worked perfectly! My network switch indicated the power advertised by the board, the power consumed by the board, and the IP address assigned to the board by the DHCP server.

There were some small tweaks to the software that came later like adding code to get a real MAC address from the serial EEPROM and adding code to turn LEDs on and off to indicate the status of the DHCP client and when an Art-Net packet was received.

Completed board with a one meter strip of 60 WS2812 LEDs connected.

The photograph above shows the finished board driving a strip of 60 WS2812 LEDs. The power for the LEDs is delivered from an 802.3at / PoE+ capable network switch. The data for the LEDs comes from Art-Net packets generated by my PC.

Photograph of the top of the completed board.

Above is a close up photo of the top of the finished board.

Photograph of the bottom of the completed board.

Above is a close up photo of the bottom of the finished board.

Decorating the Tree

A circuit board in a (fake) pine tree.

I initially used the one meter strip of sixty WS2812 pixels rather than the string of 50 pixels because the strip fit entirely on my desk and it was very easy to look and see if the pixels were displaying the patterns from my PC properly or not. Once the code was running properly, it was time to go bigger!

I grabbed the five meter string of 50 pixels and a cheap $20 fake tree from Michael’s and proceeded to string the lights on the tree. I stuffed the board in the tree then shot the quick video at the top of this post. I’m pretty sure the tree is not an ESD-safe location for the circuit board.

The decorated tree.

Above is a thumbnail from the video showing the decorated tree in my home office.

Future Power over Ethernet Projects

Philip Color Kinetics ColorBurst 4 10 watt RGB LED flood light controlled and powered over the network.

I have two more Power over Ethernet projects in progress. The first one is almost complete. It uses a Silvertel 24 volt isolated PoE+ module to power a Philips Color Kinetics ColorBurst 4 10-watt RGB LED flood light. Control data for the light comes from Synthe-Fx’s Luminair 3 software running on an iPad.

Rear view of the PoE-powered VFD tube clock enclosure.

The second project is an IV-12 VFD tube display that gets both power and time or other data for display over the network. This second project uses one of the Molex Ethernet jacks with integrated magnetics and 802.3at PoE+ classification circuitry. This project is in progress. I’ve ordered the aluminum panels for the enclosure shown above but am waiting on my VFD tubes to arrive before ordering the circuit boards for the project.

Design Files

Design files for this project are in the PixPoE repository in my github account. If anything’s missing or you have a question about something, you can find me on Twitter @bikerglen.