Project Logs

Collapse

• Project Complete

  Tyler Ward (Scorpia) • 05/23/2021 at 01:47 • 0 comments

  Since the last post I have cleaned up some of the code and added a couple of missing features that slipped through before. The construction steps have been documented along with a few areas of the code that wern't documented. This means the project is now complete.

  The project build guide and data required to build and program the device have been added to the files section as well as to the releases of the respective github repositories. 

• Software

  Tyler Ward (Scorpia) • 05/16/2021 at 12:38 • 0 comments

  The software was created with two control methods, one for use with theatrical lighting systems and the other for use with other systems.

  Theatrical lighting systems use the DMX protocol to control lights. DMX transmits 512 channels of data that control aspects of lighting fixtures. DMX is usually sent over dedicated cables but can be sent over a network using the Artnet protocol. Within a DMX universe, lights can be detected and configured using the RDM protocol. While RDM is an optional component of DMX, adding support for this allows lighting consoles to automatically detect or edit the lights configuration, such as which channels within the DMX datastream it should use, without needing to use another configuration method.

  For both Artnet and RDM the protocols are published publicly and simple enough that they can be implemented from scratch, which is useful as there were no premade libraries that looked suitable. The basic implementation of these was created with the first prototype and refined through the later prototypes. The Artnet and RDM code blocks were also designed so that they could be reused later in a different project without needing to rewrite much of the code. The stack light is setup to use four DMX channels, one for setting the brightness of each of the three light segments and one for the buzzer.

  For use with things like status monitoring tools and to provide a user friendly configuration interface a web interface was used. The ESP32 has a good amount of available flash so a bootstrap template was used to create the user interface in order to provide a fairly nice looking user interface. A combination of static files and templated files were used to create the webpage. There isn't a templating library for the ESP32 so I created a basic one which replaces tags in the saved file with strings calculated by a separate function. Settings are set from the webpage via a series of API endpoints which accept post requests with the new settings and update the configuration as required.

  With these interfaces functional, the stack light is ready to be put to use. While writing the firmware I identified several future feature additions that could be added to improve the lights functionality. To avoid the project ending up in a state of continual feature creep these have been added to the issues list and marked as potential enhancements that can be added in the future if they become useful. The last step before This project will be marked as completed is to create a software release and instructions to allow others to build, this should be appearing here in the near future.

  The firmware for this project can be found on github.

• Hardware Designs

  Tyler Ward (Scorpia) • 05/09/2021 at 21:05 • 0 comments

  Following on from the second prototype a pcb design was created that merged the required components together. The only major addition from the prototype was the POE power supply hardware. The design is split into four major sections, the output stage, the POE power supply, the processor, and the network interface.

  The stack light takes a common 12v input with switched grounds for each light segment and the buzzer. A mosfet switch was used to control each of the channels with brightness controlled by pwm from the microcontroller. As provided the light has a voltage regulator based current limiter shared across all the illumination channels, this prevents multiple segments from being lit at full brightness simultaneously. This was resolved by bypassing the current limit inside the light with a jumper wire and then adding a copy of the current limiter circuit in the light to the board for each of the three led channels, giving them their own current limit.

  For the POE power input, a transformer setup rather than a switch mode design was used. The use of a transformer based design provides electrical isolation and allows other connections to be exposed without the risk of a short. The power over ethernet schematic is based off the MP8007 reference design. The catch with many of the reference designs for POE PD controllers is that the transformers used in them are not easily available, therefore, the transformer needed to be replaced with a more easily acquired Coil craft transformer requiring a change to many of the other components as well. A backup DC jack was also added in the event that something was wrong with the POE design.

  An integrated ESP32 wireless module was used for the main processor. As the module isn't needed for its wifi capabilities the ESP32 could have been added as a standalone chip, however, using the module simplifies the design as compared to using the ESP32 IC directly and the extra board space occupied wasn't an issue. The large voltage drop from the main 12v supply required for the light to the 3.3v supply needed for the control circuitry prevents use of a linear regulator as this would produce quite a lot of heat. Instead a stepdown switch mode power supply was used to provide the 3.3v supply. A USB to serial converter was included to facilitate easy programming and give the option for a serial console interface if wanted.

  The network interface uses the LAN8710A ethernet transceiver IC. This communicates to the ESP32 with the RMII protocol used for 100MB ethernet PHYs. In order to support the POE functionality an ethernet connector with internal magnetics that expose the centre taps of the cable side of the interface was chosen.

  With the design sorted the PCB could be laid out. The PCB was designed to fit into an off the shelf enclosure in order to minimise the mechanical complexity of the project. The design has several SMT components with underside ground pads so large vias were added under each of these ICS to give access to these pads and enable hand soldering of the board. Other than that it was a fairly standard PCB creation process.

  Once the boards arrived and the first unit assembled a couple of issues were discovered. The most problematic was that the POE transformer output was reversed which was fixed by soldering wires to the correct locations. In addition the ESP32 draws less power than the minimum to maintain powered over POE so an additional load resistor was added to draw the required power. The other notable problem is that the POE transformer has a high pitched wine when at low power which has yet to be solved. The board was otherwise functioning and worked with the firmware that has been used on the second prototype. The next stage is to complete the missing software features and then the project will be ready to use.
  

  For those interested the hardware designs can be found on github.

• Initial Concept and Development Stages

  Tyler Ward (Scorpia) • 05/02/2021 at 18:17 • 0 comments

  The idea for the project came when I was considering using power over ethernet (POE) for another project and wanted to understand how to implement it in something simpler beforehand. At around the same time I came across the affordable stack light units and thought it would be useful for a few applications so decided to merge the two and build a POE powered version. The two main application areas are either status reporting, for things like system availability monitoring, or continuous integration. The other application area is for use in theatrical lighting systems like those used in the Student Robotics competition or for my portable bridge setup for the game Artemis.
  

  The first iteration was a proof of concept largely consisting of off the shelf blocks. An Arduino with an ethernet shield were used as the control system and powered using A POE splitter. A prototype shield containing the transistors for switching the light was then mounted on top.
  With this setup the initial firmware was prototyped and got to a functioning state, however, the lack of flash and ram on the chip limited the amount of features that could be enabled at once. The other limitation of this version was that only one segment could be fully lit at a time due to a single current limiter built into the stack light. Despite this the prototype was useful so development was started on a customised board to control the light.

  Initial thoughts were to design the controller to fit into the base of the light. Trying to do this at the same time as fixing the issues with the first prototype proved time consuming and resulted in the project being shelved for a while. After the hiatus a new plan was created to reduce complexity and get the project moving again by focusing on its core goals. The integrated base idea was scrapped and instead the controller would be placed in an off the shelf enclosure in order to remove the mechanical design aspect of the project and reduce the size constraints on the PCB. The led control was simplified, rather than using a controlled current LED driver, the current limit in the light would instead be duplicated for each channel, this takes more board space, but without the limitation of fitting the design into the base this was no longer an issue. Finally the Arduino based control logic was swapped out with an ESP32 based system as this resolved the processor issues and simplified the network connectivity component of the design. In order to test these plans a simplified breadboard prototype was created with an ESP development board. Unlike the first design, this targeted testing the planned alterations and pinout combination would work before completing the PCB design. It also allowed for continued software development while the PCBs were being produced.
  

  With the design tested using the second prototype the PCB design was completed and ordered. After debugging a few issues with the board the software from the second prototype was able to be flashed onto the board and the work to complete the software could begin.

View all 4 project logs