I love to work on lighting projects, and having done my fair share of NeoPixel/WS2812b-based installations, I can tell you from experience that sometimes it can be really tricky nailing down a fully comprehensive design that "just works" when it's deployed.
One of the things that I see most often overlooked when integrating pixels of any chipset into staging, decor or other applications is the attention needed to properly route the required data and power wiring to where it's needed.
Batteries and Bluetooth don't cut it for large scale installations, and conversely, the wiring needed to support multiple pixel groups can quickly become cumbersome and expensive when you consider the high power requirements of lighting.
With this in mind, we can appreciate the PixPoE project from Glen Akins, a professionally designed hardware project aimed at simplifying the installation of pixel-based lighting projects!
Networked pixel controllers are a popular project, but I'm going to take a look at what really makes the PixPoE such an interesting design for me It's integrated PoE power supply, something I've often been found wishing for!
PixPoE is comprised of two main functional blocks;
- A PIC18F67J60-based Ethernet controller
- A fully compliant 802.3at Type 2 "PoE+"-powered device implementation, capable of negotiating 25W of power from a PoE source!
Together, they allow you to send both data (in this case, Ethernet networking) and power (25W!) down the same Cat5 cable, a scheme known as PoE, or Power over Ethernet. This means you can vastly simplify your installation wiring, and even make use of existing Cat5 infrastructure, if it is available.
I couldn't help but dive into the Git repo that Akins has made available, and I was really pleased to see the clear and professional design effort that he has made with his schematics.
His PoE implimentation makes for a really beautifully drawn reference design for anyone looking to impliment PoE functionality in their projects. Let's take a look at some of the design choices he's made...
What's it all good for, anyway?
Akins has chosen to implement the 802.3at Type 2 device class, also known as "PoE+."
This class specifies a power delivery capability of 25W, which is nothing to sniff at. That's 5V at 5A in a perfect world, more than enough for even a few metrers of NeoPixels!
You've got to ask for it...
To successfully get the PoE PSE (Power Sourcing Equipment (e.g. a PoE injector, or powered switch) to deliver the full power specified by the Type 2 Device Class, we need to communicate with the PoE PSE to tell it, "It's ok, we're good for it!"
Those of you who have read up on USB-C Power Delivery will notice a similarity to the PD capability negotiation process, and it's conceptually not too dissimilar!
You can drop down a dedicated IC for this specific purpose, which removes all the overhead of having to design that functionality yourself. In this design, Akins has chosen the TPS2378 from TI that takes care of business with nothing more than a PowerPAD SOIC-8 package. Neat!
Bridging over the issue of AC/DC supplies...
PoE delivers its power over unused Cat5 pairs, doing so by feeding 48VAC down them. It's then down to the receiving equipment to rectify this 48VAC down to something more appropriate, and we can see that this is handled by a mixture of bridge rectification and finally a chunky isolated PDQE20-Q48-S5-D DC/DC converter, rated to output 5V at 4A. This converter capable of delivering what's left of the rectified 25W PoE input, once the efficiency of the circuit is taken into consideration!
I think we need some space...
When using PoE, it makes sense to be safe about it. With the risk of things wiring faults, or faulty PoE PSE equipment, we need to look at ways to protect our circuit from potentially life threatening voltages that might occour on the PoE bus.
If safety is the game, then isolation is the name! It's always good to consider safety with power circuitry, and there are some really good tips to be taken from this design.
It's clear that isolation has been taken into consideration, not only from the component choices in the power supply circuit, but in the layout as well. We can see careful attention paid to things like the restriction of ground planes, something that can be critical when trying to meet isolation requirements!
If we look at this part of the schematic, we notice a blue dotted line, running it's way across the page, accompianied by the words ISOLATION BARRIER.
This barrier is more than just a graphic line, however, and if we look at the board layout, we can clearly see a gap tracing its way through both copper layers.
This physical seperation of the parts of the circuit connected to the PoE bus means that we need to look at ways to safely pass our data and power across the barrier, and to do so, we use a number of different devices.
The Ethernet pairs of the cable are magnetically isolated at entry to the board, through use of a TG110 Ethernet magnetic isolator, providing up to 1.5kV of isolation against things like cable faults and excessive transients due to EMI.
While internal Ethernet PHY of the PIC18F67J60 is isolated by the TG110, the PoE power supply circuit still sits at the same potential as the Cat5 pairs that supply it, so we need a way to decouple our power rail from the PoE bus.
We can see how Akins has chosen to use an isloated DC/DC converter to not only regulate the rectified PoE voltage down to 5V, but to do so safely without comprimsing the required isolation from the PoE bus, and an optocoupler (phototransistor pair) provides a way to safely signal back from the isolated side of the circuit.
Other notable design features can be picked out from the processor schematic page, and can also serve as handy reminders on how to get some solid performance out in the field.
The circuit block that caught my eye deals with the clock source for the PIC18F67J60. While we might normally jump for a crystal oscillator and think nothing more of it, the network controller of the PIC has some rather strict waveform conditions that must be met when supplying the required 25MHz clock input to the device.
A throwaway comment in the datasheet reads:
A frequency tolerance is specified, likely excluding the use of ceramic resonators.
It's a known behavior of crystals to exhibit a change in frequency output in response to temperature (30-50ppm can be a common shift), and with this board rated to convert and deliver 25W, we can see that there might be some self-heating taking place.
A less commonly seen way to clock a circuit is to do so with a digital MEMS oscillator. These devices usually feature a tuning fork MEMS structure, and driving electronics that allow it to compensate for changes in temperature. The result is a comparatively rock-solid frequency output, with minimal drift. Perfect for this application, and perhaps the reasoning behind Atkins choice of the SiTime SiT2024B device, shown implemented below.
One last point that deseves a mention is the tried, tested and true method for getting your WS281xx pixels to respond reliably to a 3.3V controller. Although it seems too simple to mention, many things do in hindsight, and I still see a lot of projects forgetting to use something like a simple SN74LV1T125 buffer to provide a well formed data signal.
We also see some good practice with some series resistance on the driver output, and some protection against ringing data lines with a TVS clamp diode (DRTR5V0U2SR, Diodes Inc) shown at D9.
That about wraps it up for this dive into Akins' PixPoE project. This one is going in my bookmarks as a solid reference for anyone looking to implement a PoE+-powered device, with some well thought out design choices to refer to throughout the project.