TSO Jam PCB

Client

Friends, Family, etc.

Location

Pittsburgh, PA

Year

2024

Resources

I decided to create a significantly-enhanced version of my original Blinking PCB Christmas Ornament. This time, I'd include more LED colors, audio, and a light show. It's a far cry from the rudimentary PCB created just 2 years ago.

I decided to work with PCBWay to produce a beautiful UV-printed finish on this PCB, which is one of the coolest PCB finishes I've used and I'll absolutely use agan.

Check it out

PCBWAY

Thank you to PCBWay for sponsoring this project and helping me throughout the process! PCBWay is and always has been my preferred PCB manufacturer. I'm thrilled that we worked together to bring this project to life.

This 4-layer board is dense with quite a few unique components, so I was worried about the manufacturability and assembly yield of a 10-unit PCBA order. It also included a few strange assembly requests, like the speaker wiring and component orientations. PCBWay ensured all aspects of my boards were within their manufacturing processes and worked with me to adjust anything that wasn't.

They were also incredibly transparent with the assembly process. They always ensured that they understood exact assembly requirements and sent images of the assembled PCBs for my approval. I love their turnkey service - I simply sent them a BOM of components and they did the work of pricing & sourcing them.

PCBWay recently introduced a multi-color UV Printing service, allowing customers to have a color image printed on their PCB.

Source: Unlock Color PCB Printing with PCBWay

I'd never tried the UV printing service before, so I was hesitant to try it on these gift PCBs. However, I'm thrilled that I gave it a shot - the front finish is easily my favorite part of this project. The UV printing has a matte finish and looks spectacular. I'm impressed by the color definition, too.

PCBWay did a great job communicating with me about this service. They even tried out my image on a test board and made sure that the printing was up to my requirements.

I'm excited to work with PCBWay and use this service again in the future!

System Requirements

The STM32 Audio Panel that I made for Christmas 2023 was expensive and labor-intensive, so I chose something not requiring a ton of new circuitry, code, or an enclosure. Therefore, I chose to make a standalone PCB that would blink lights and play audio.

Specifically,

Tangible, Graphical, and Audial User Interface: The user-facing portion of the PCB must be pretty enough not to require an enclosure. There should be multiple colors of LEDs and a high-quality audio output of Wizards in Winter by the Trans-Siberian Orchestra.
Power: The PCBs must be powered by commonly available replaceable batteries. There should also be a low-battery indicator.
Reverse Polarity Protection: The PCBs must have protection against batteries inserted backwards.
LEDs: The user-facing LEDs must be able to be dimmed by using PWM.

System design

I use 3 series AA batteries to power the system. AA batteries are replaceable, can provide enough current to power a speaker, and are a household staple.

Design Reuse

I'm using the same audio clip memory and I2S amplifier structure as Beethoven Clock since I've already verified the circuits and written device drivers. There's no time to spin a Mk. II if this PCB is erroneous, so I erred on the side of caution. Therefore, only the colored parts of the diagram below are "new" circuits to me.

Power Circuitry

I can only fit 3 AA batteries on this board, so I can't afford the voltage drop of a series diode to serve as reverse-polarity protection. Therefore, I use a "backward" PMOS circuit above. SPICE simulations showed this circuit working as intended, but I DNSed a resistor in parallel to short around the PMOS if needed.

The low-battery indication circuit illuminates a red LED when the cell voltages fall below 1.2V * 3 = 3.6V, which is nearing the threshold below which the LDO might not output 3.3V reliably (assuming 0.3V dropout.) I tried to use a single NMOS to turn on when its gate voltage falls below a certain value, but manufacturers' NMOSs have a wide threshold voltage tolerance. Therefore, I elected to use a voltage supervisor IC with a much more precise threshold tolerance.

LED Circuitry

The below schematic was duplicated 4 times using Altium Designer's multi-channel design feature. Therefore, the design's 16 LEDs are segmented into 4 identical "banks."

Each LED on the PCB is mapped to one of the STM32G0's 16 pins on GPIO port B. This allows me to twiddle the state of all LEDs with one command (i.e. GPIOB->ODR = 0b1010101010101010.) This is important for speed of code execution, as will be seen in the firmware section.

The brightness of each bank is controlled by a PWM signal fed to an NMOS in series with each individual ON/OFF NMOS. Hardware timer outputs from the STM32 generate these PWM signals.

PCB Layout + Routing

Since I knew I'd have an image printed on the front of the PCB with PCBWay's UV printing service, I used the Christmas tree clipart to inform the PCB outline. All components are on the back except for the light show LEDs, power switch, and jam button. The back is a bit cramped, but it fits.

Front

Back

The front looks ugly in the render, but looks great once it's UV printed upon. The two holes in the star serve as punctures through which the ribbon is passed so this can be hung on a tree.

As usual, I included assembly drawings to ensure crystal-clear communication with the manufacturer + assembler.

This includes silkscreen indicator clarifications and tidbits about what is acceptable.

The PCBs arrived looking + working great. No mistakes have been detected to date. I'd expect nothing less from PCBWay.

Firmware

I was able to use much of my code from Beethoven Clock by changing some hardware-specific pin mappings and using the same flash memory and amplifier drivers.

Once everything is initialized, the main loop just waits for an interrupt from a button press to trigger the audio + light show. Most of the audio data transfer is taken care of by DMA, so the CPU is just in charge of setting the LEDs.

I set a hardware timer to generate an interrupt 4 times per song measure. The song is 148 BPM, so the timer goes off 148 BPM * 4 = 592 times per minute, or about a 10Hz frequency. Since I have lots of flash storage on the STM32, I store the 16 LED outputs for each timer interrupt in one position of an array of 16-bit values. Every time the timer interrupt triggers, I simply write the next value in the array to the output data register of GPIO port B (i.e. GPIOB->ODR = 0xabcd,) taking up minimal processor resources.

I use 2 hardware timers to generate the PWM signals that control the static brightness of the 4 LED banks, which operate at about 250 Hz.

To perform LED dimming, the compare registers of the timers generating the PWM signals must be changed quickly enough to look continuous. I use yet another timer to achieve this. When this timer generates an interrupt, it updates the compare registers(s) of the proper PWM timer(s) with a value from another array of percent duty cycles. This timer also operates at about 250Hz to make LED pulsing effects look continuous.

The above functionality is captured in a main thread and one ISR. I biased towards making the CPU do as little processing and decision-making as possible to avoid over-utilization of resources and perhaps producing a choppy audio stream.

The audio clip is almost 2 minutes long and needs to be reasonably high fidelity across the entire spectrum. Though I have one speaker, I2S requires stereo audio input.

I could compress the audio into a file format like .mp3 to minimize the size of the flash memory chip. I'm not using a terribly fast or powerful MCU, so uncompressing this data would require a more powerful MCU or an external chip, the additional costs of which would far overshadow those saved by using a smaller memory chip. Therefore, I'm sticking to an uncompressed WAV file.

A 3:00 stereo audio clip is 31.7MB, requiring a 32 MB flash memory chip (based on available memory sizes.) Stereo audio is unnecessary because I only have one speaker, so I store a mono audio file on the flash memory chip. This cuts the audio file size to 15.9MB, only requiring a (much cheaper) 16MB flash memory chip. The I2S amplifier requires a stereo audio stream, but I have enough processor resources to interleave zeroes in between data chunks and can tell my amplifier to pay attention to only the channel with the non-zero data.

The SPI interface only receives 8 bits of data per RX cycle, but the I2S interface requires 16-bit samples. Therefore, I'm using the CPU to concatenate 8-bit chunks into 16-bit samples and insert zero half-words after every data half-word. I'm using two DMA streams to double-buffer data transfer to provide a constant stream of audio and offload data transfers from the CPU so it has enough time to process data. One stream ping-pongs between filling two buffers with new data from the SPI interface and another continuously loops through pushing processed data from another buffer to the I2S interface:

Testing, debugging, & Integration

I've found PCBWay's manufacturing and assembly service to be incredibly reliable, so I didn't find any copper or soldering errors in any of my boards. Aside from replacing a few dead LEDs, I staked the battery holders with hot glue, bolted the speakers, added hanging ribbon, flashed, and verified all 10 boards.

Once again - thank you very much to PCBWay for sponsoring this project. I'm definitely going to work with them again in the future!