Overview:
Hell Lighting is controlled by a MEGA ADK mounted at one end of the hallway, adjacent to purgatory, where the power supply is stored. This is a custom "shield" to sit on top of the mega and provide IO terminals as well as basic control elements for the system. This pcb replaces the prototype unit used during Hell Lighting's trial period and, with the new pattern system now online, represents the last component required for us to declare the system fully operational.
Although this shield is primarily intended as a control board for Hell Lighting provisions were made for it to act as a generic pattern controller. With that in mind, the board can run up to 670 LEDs, split between the four outputs, directly off of the power input terminals. For more information about independent operation and system current limits see the testing section below.
Note: Although this board is installed and working there are two required reworks in order to use the board with the interrupt based version of our firmware. In particular it is necessary to connect Pin 15 to Pin 19 and Pin 16 to Pin 18 all effected pins should be set to inputs.
Features:
- Pattern Switching: One encoder to switch between patterns, with a built in button for resetting the current pattern.
- Pattern Control: One potentiometer connected to an ADC input, and a button connected to an interrupt pin.
- Screw Terminals: Four terminals for connecting patterns (GND, DATA, 5V), and one power input terminal (GND, 5V).
- Display: One monochrome 8 bit bar graph for displaying the current pattern or debug info, and a power indicator LED.
- Sensors: I2C temperature sensor with 1 degree accuracy and 12 bits of precision, front mounted.
- System Control: Reset button, programing jumpers to issolate the arduino from power and ground.
New board right before installation/cleaning.
The old board... We don't talk about the old board.
Firmware:
Although this board is mostly just a cleaner version of the V0.1 board we were already using. There were a few features which needed to be enabled in firmware. A brief description of how each of these was handled can be found below. If you want additional details, please don't hesitate to reach out.
All the best things come in parts bags.
Encoder:
The encoder is responsible for controlling pattern changes, and is handled by an interrupt triggered on it's "B" pin. Each interrupt determines the direction the encoder is moving by comparing the values on A and B, then records a CW move if they are the same and a CCW move if they are different.
Even with hardware de-bouncing it is worth implementing some kind of bounce management in software. I found it sufficient to wait 80ms before allowing another tick to be recorded. 80ms is fairly responsive, but tends to give false direction reversals. To combat that, I set the wait time before registering a change in direction to 100ms which seems to have pretty much eliminated the issue.
Interrupt time on a 2560 running Hell Lighting is at something of a premium since interrupts must be disabled when writing to LED strips with a 3 wire bus. With that in mind, I found that using the interrupt to record, but not act on, pattern change requests and then updating the pattern at the end of each frame worked far better than directly updating the pattern in the ISR the way we did when pattern change was handled by button.
Pattern Output:
One of the new features this board incorporates is an LED bar graph to show the current pattern number. Since there were no conveniently located digital IO pins I connected it to port K on the atmega2560. This port can be set to output using the DDRK register. The correct values can then be written to those pins using the PORTK register.
Note that the design decision was made only to connect the graph only to the K register. This means that although it is a 10 piece bar graph we are only able to support 256 distinct patterns. At time of writing, we have roughly 16, so I do not anticipate this being an issue in the near term. Never the less it will likely be modified in the next rev.
Temperature Sensor:
The temperature sensor for V0.1 is the backed by two classes. One is a generic Temperature Sensor class, and the other is specific to the TMP175. These will form the first two classes in the new HAL for hell lighting. The TMP175 is an I2C device, but none of our end users will ever need to know that. A (very) abbreviated breakdown of the two classes can be found below:
SensorTemp - The high level temperature sensor class is responsible for keeping track of the last read temperature as well as the minimum and maximum possible temperatures for that sensor. It also exposes a set of functions to return the current (read new) and previous (return last) temperature in a variety of common formats.
TMP175 - The TMP175 class fully implements the chip's features, including: variable read precision, low power mode, and extreme temperature interrupts. It also overwrites a function from the SensorTemp class to actually get data from the device and invisibly handle setting OS when the device is in low power mode.
Verification:
For the most part when it comes to PCB specs I am pretty happy to take board houses at face value (plus or minus a generous safety margin of course). That said, when it comes to questions like "Will this catch fire" I really prefer to do actual testing whenever possible. With that in mind, I decided to destructively test main power traces on the PCB by connecting the control board to a variable powers supply and slowly increasing the current until a failure point was reached. Temperature data was gathered with an IR thermometer (calibrated at 24c).
Conclusion: Ultimately, the board "failed' at 21A when the board reached 165C and the solder melted. In order to keep temperature rise to a more reasonable 80 degree increase I would suggest limiting current through the on board power distribution buss to 17A (this limit has no bearing on systems like Hell Lighting that have external LED power).
