Hello, my name is Erin St Blaine and I love making things that light up.

When I'm not writing tutorials for the Adafruit Learning System, I spend my time creating beautiful things, and exploring the meeting of art and technology whenever I get the chance. Over the last several years I've been focusing on creating larger scale LED artwork, home decor and chandeliers. I started out using Arduino with FastLED and learned to code the hard way, but nowadays there are so many software packages out there that I've been learning and exploring them. This article is about my experience of LED mapping my newest chandelier commission using WLED, PixelBlaze and LEDLabs.

What is Pixel Mapping?

Pixel mapping is a technique used to control and program individual LEDs or pixels within a lighting display, allowing each light to be addressed and manipulated independently. By mapping out the exact location of each pixel in a 2D or 3D space, artists and designers can create intricate patterns, animations, and effects that synchronize with the physical layout of the lights. This method is essential for creating dynamic, visually stunning displays, as it enables precise control over color, intensity, and timing across complex setups like LED walls, chandeliers, and sculptures.

A pixel map is needed when the LED layout is not precisely rectangular. Basically, a pixel map forces a non-rectangular shape into a rectangle that can be divided into rows and columns so the animations lay out correctly in the physical space.

My first foray into pixel mapping was making an LED Festival Coat using WLED. This was a fairly straightforward map -- the layout was generally rectangular, with just a few "holes" in the rectangle to account for -- I needed the map to fill in the arm hole areas so that my animations would look even across the whole coat. I used WLED for this, and found it to be a little mind-bending and tricky even with a simple map. 

After the success of that project I decided to give mapping my chandelier a try. The chandelier is shaped like a hot-air balloon with eight spokes and no rectangles at all. This looked to be a challenge but I knew the end result could be absolutely stunning if I succeeded.

For hundreds of years, the clockwork orrery has been a way to demonstrate the movement of planets around the sun - as Wikipedia describes them: "An orrery is a mechanical model of the Solar System that illustrates or predicts the relative positions and motions of the planets and moons, usually according to the heliocentric model. "

It occurred to me that, the circular display of ten neopixels on the Circuit Playground might be a way to make a different kind of orrery... so I did. My programs are in this repository and consist of three programs:

• orrery.js - Javascript/Makecode version for the Circuit Playground (https://makecode.com/_EHeh61h4Dcvo for the Makecode IDE version)

• orrery.py - Circuit Python version for the Circuit Playground (copy to code.py on the device)

• neo-orrery.py - Circuit Python version for the NeoTrinkey  - again, copy to code.py on the device (you didn't think I'd leave the NeoTrinkey out did you?)

I opted to just do Mercury, Venus, Earth and Mars - adding more planets was too cluttered, plus the relative speeds of the inner planets are easier to see.

All versions start by showing Mercury (pale white), Venus (yellow), Earth (green) and Mars (red) as neo pixels moving at their relative speeds around the sun - from Mercury the fastest to Mars the slowest.

Each can switch to a random setting, changing the color and speeds of the four planets.

Makecode version: "A" stops/starts motion, "B" sets up a random solar system, and "Shake" resets to defaults.

Circuit Python Playground version: "B" sets up a random solar system and "A" resets to defaults

Circuit Python NeoTrinkey version: Touch pad #2 to get a random solar system and pad #1 to reset to defaults

NOTE:

The mechanics of the simulation are simple. Each program has a loop that increments a counter for each "planet."  There is a table of periods for each planet, an integer that is 100 times the length of the planet year, so, for example, Mercury's period is 22 and Earth's is 100. When a planet's counter reaches the value of its period, the counter is cleared and the planet's position is advanced one position.

This clock project uses USB gamepad input to control its time setting menu. The display uses TileGrid sprites that I made in Krita. The code demonstrates how to use timers and a state machine to build an event loop with gamepad input, I2C real time clock IO, and display updates.

Overview and Context

This clock is a step along the way on my quest towards learning how to build little games and apps in CircuitPython. The look for the display theme is about digital watches and alarm clocks from the 80's and 90's.

Some of the technical bits and pieces from this project that you might be able to reuse in your own projects include:

• Menu system for manually setting time and date

• USB gamepad input system with edge-triggered button press events and repeating timer-triggered button hold events

• Data-watch style display theme with three display areas: 20 ASCII characters at the top, an eight digit 7-segment clock display in the middle, and another 20 ASCII character display at the bottom

• Main event loop with gamepad button polling, real time clock polling, state machine updates and display updates

Recently I've been experimenting with Apple Shortcuts to interface with the new itsaSnap app. This app lets you interface with Adafruit IO feeds on your phone. With Apple Shortcuts, you can get data from your phone to Adafruit IO. You can, for example, send health data, weather data, even encoded photos.

One topic that comes up in Apple Shortcuts is not being able to easily create an automated Shortcut that loops. For example, having data be sent every 30 minutes. There is a time automation, but you have to setup an automation instance for every time you need the Shortcut to run.

I wanted to figure out a way to do this and found a helpful post on the Apple Shortcuts subreddit that describes using alarms as a workaround. I normally avoid Reddit but that particular subreddit has had very helpful posts with folks sharing their Shortcuts and tips for folks to accomplish what they're looking for.

Flow Chart

I've adapted the suggested Shortcut from the subreddit post a bit. I've found that wrapping my head around the logic can be a little tricky, so here is a visual explainer before we get into building out the Shortcuts.

Along the way I learned a few things:

• How to take an Adafruit PCB design in Eagle format and import the board outline all the way into FreeCAD for locating dimensions and features
• How to make my code robust against transient errors like network errors
• How to make my code deep sleep for the right length of time

There are also a few things this code demonstrates that are less common knowledge:

• Using fonts from the font bundle
• Using the datetime module for arithmetic on dates & times
• Increasing reliability by re-trying operations that can fail
• Reducing battery usage by deep sleeping and avoiding connecting to WiFi

This project uses FreeCAD & KiCAD, both of which are Open Source software that are free to download & use.

Parts Needed

Code & Installation

I recommend using Adafruit circup to install the needed libraries for projects. Here's what you need to do:

• Install circup on your desktop computer
• Enable the "fonts bundle" by running this command (just once, circup remembers this setting):

  circup bundle-add adafruit/circuitpython-fonts

• Copy code.py to your CIRCUITPY drive (Download it via the "raw" link at https://gist.github.com/jepler/b2c020a6caa65a31297053b7216fcc15)
• Run the following command to auto-install required libraries:

  circup install -a

You'll also want to configure wifi on your device using settings.toml. For lower power usage, configure WIFI_SSID and WIFI_PASSWORD options. For web workflow but higher power usage, configure CIRCUITPY_WIFI_SSID and CIRCUITPY_WIFI_PASSWORD options.

Several years ago Solder Party released the Keyboard Featherwing, a PCB that combines a Blackberry keyboard, a 320x240 TFT resistive touchscreen display, a 5-input DPAD, 4 tactile buttons, a microSD card reader, and more, all driven by an Adafruit Feather board of your choice. Eventually these were discontinued, I'm assuming because of the difficulty of sourcing the increasingly rare Blackberry keyboards. I didn't know what I wanted to do with them at the time, but I knew I was gonna want to do something with them at some point, so I ordered several of them before the stock was depleted.

One popular use for the Keyboard Featherwing has been to pair them with LoRa radio transceivers, to create a set of "Doomsday Messengers". These are devices that are able to send short text messages to each other using radio signals, sort of like walkie-talkies, but for text messaging. This makes sense: with the tactile keyboard, huge display, and instant compatibility with the Feather ecosystem (including the ability to use rechargable LiPo batteries), the Keyboard Featherwing practically seems designed for the use case!

I hacked together a quick demo a few years ago allowing for very basic communication between the devices, and then promptly lost interest. I wanted to write firmware that allowed for robust, reliable communication between the devices, but I also wanted something offering some of the affordances of a modern smartphone UI. If you've ever worked on UI for microcontrollers, you probably realize there are a lot of challenges. One of those challenges can be figuring out how to write a custom, complex UI with just the basic drawing functions provided by the commonly available drawing libraries. While possible, it can be really cumbersome once you start to want more modern UI features, such as widgets, scrolling, animation, multi-screen interfaces, and so on. Another challenge is implementing all of that in a performant way, given the limited speed and memory of most microcontrollers. At the time, I wasn't sure how I was to accomplish this without pulling my out my hair, so the project was put on the back burner.

Recently I decided to dig these up and give it another shot. I still wasn't sure exactly how I was going to do it, but I did have a concrete feature set in mind:

• The ability to send encrypted, reliable messages between two paired devices using LoRa technology
• The ability to pair each device with any other device using the same hardware and firmware, via a settings screen (i.e., no re-compilation needed to pair devices)
• The ability to modify and persist device settings and a small message history across power cycles
• Granular battery monitoring; specifically the ability to see the percentage of battery life remaining at any given time
• Heavy focus on physical controls, using the touchscreen to supplement the UI only where practical and/or necessary (if you aren't familiar with any of my previous projects, I'm a huge fan of physical controls)

Which Feather?

This is a game about skeletons, pumpkins, and a catapult having a Spooky experience under the full moon. If you've thought about making a game in CircuitPython but aren't sure where to start, this project might be a useful source of ideas.

Charging a Pumpkin

This is how it looks when you hold the USB gamepad's A button to charge up a pumpkin.

I was looking to try out my new Adafruit Feather RP2350 and I remembered I had the Solder Party Keyboard Featherwing.

The Keyboard Featherwing is a handy device: it is about the same size as a BlackBerry phone with the same alphanumeric keyboard and a 2.6" 320x240 color display. Plug in a Feather board as the "brains" and you have a portable system.

Alas, one has to program the Feather, preferably with CircuitPython, to use the keyboard, display, and other features. Solder Party has example code snippets for those features. But what about something more holistic, more like a computer with input and output?

I found two solutions that were perfect: PyDOS and Beryllium OS. Both are built on top of CircuitPython.

PyDOS emulates MS-DOS commands used on PC compatible computers. And Beryllium OS, formerly ljinux, acts as a Linux-like computer. Neither are binary compatible (they cannot run native DOS or Linux binaries) but their commands and interactions emulate those operating systems.

This Playground Note will show you how I built my PyDOS handheld in short order.

There are two videos, one from Adafruit Show and Tell and another for Tom's Hardware The PiCast.

Preparing the Feather

Solder male pin headers onto the Feather RP2350. You could use long pin stacking headers to add a FeatherWing, but that would create quite a stack on the back.

See this guide page for soldering details:

I am a big fan of "being able to code whenever/wherever I am." That's why I bought a wireless keyboard for my iPhone, when I realized I could edit CircuitPython programs using my phone. It's one of my favorite things about the Micro:Bit - the App lets you write and upload code from your phone.

But I didn't think I could do that with makecode.adafruit.com programs for the Circuit Playground. I was wrong, in fact it's pretty easy. I just needed a lightning-to-USB adapter so I could download the code!

First - load your code in your browser (like the picture above).

Next - click the download icon in the lower left.

Then, click the file link above, to "open in a new tab."

Program your device

Installing CircuitPython environment

1. Download .uf2 file here:
   • https://circuitpython.org/board/raspberry_pi_pico/
2. Plug in USB cable from PC to RP2040 board while holding the BOOTSEL button.
   • A new drive should get mounted on your system.
3. Drag/drop downloaded .uf2 file onto newly mounted drive (RPI-RP2).

Installing libraries and project code

From "CircuitPython Library Bundle" (download here):

1. Copy from bundle .zip file to the microcontroller [drive:]\lib\ folder:
   • adafruit_hid

From the PCMediaRemote release page (download here):

1. Download and unzip the "Source code (zip)" file from the "Assets" section.
2. Copy the "unzipped" custom project code to microcontroller [drive:]:
   • [PCMediaRemote folder]\lib_cktpy\* => [drive:]\lib\
   • [PCMediaRemote folder]\pkg_install\MediaRemote_RP2040\*.py => [drive:]\

NOTE: Feel free to check for newer versions of PCMediaRemote on the releases page. Code from the main branch might also be functional, but explicit releases are less likely to have issues.

Customizing your solution

You can directly modify the main.py file on the [drive:]\ folder. Every time you save the file, CircuitPython will restart with the updates applied.

Note that if the file gets corrupted for some reason, your changes will be lost. It is recommended to work from a folder on your PC, and manually upload (ex: drag/drop) the changes to the CircuitPython drive.

Overview

A media remote receiver for your PC/MAC/thing supporting keyboard media keys.

• Also works with many smart TVs and phones.
• Flexible CircuitPython-based solution can easily be adapted to other microcontrollers/IR remotes.
• Built-in IR signal decoder utility on serial monitor output.
• An easy, inexpensive, solderless build! (if desired)

If you grew up with a Nintendo Entertainment System, you probably remember playing games like Duck Hunt that used the Nintendo Zapper "light gun". The Zapper used a clever technique that depended on the game being displayed on a Cathode Ray Tube, or CRT television. These days, CRTs are rare, and are often prized collectors items among retro gaming enthusiasts. Since these Zappers don't work on modern TVs, most people don't have much use for them anymore. So, why not convert it into a toy/prop that lights up and plays sounds?

Overview

This project uses a Prop-Maker Feather RP2040 to repurpose the the Zapper's iconic shell and clicky trigger mechanism into a prop/toy that uses a NeoPixel for a "muzzle flash", a speaker to play sound effects, and 3D printed parts to contain the electronics. The code is written in CircuitPython, and sounds can be changed or added by dragging and dropping files with no code changes required!

I'm almost ashamed to admit I had a Raspberry Pi 400 that went unappreciated for the longest time. My Dad got it for me as a gift, and it was sitting in a box of spare parts for months. Once I finally got to open it up and take a good look at it, I really wanted to do something cool with it. The Pi 400 was great enough by itself, having a built-in keyboard which you would only need to add a monitor to have a complete computer setup. However, I wanted to have an "all-in-one" setup, with even less wires to plug in. And since I was in a "Fallout" kinda mood, having recently watched the TV series and played one of their games, I decided to model this all-in-one casing based off of the terminal featured in the Fallout game series.

The general idea was to build a plastic casing to house all the pieces, and extend the Pi 400's ports with panel mount cables. First things first, I needed a monitor. It took me a while to find a monitor that I liked, but in the end, the one pictured above was what I settled on. However, I realized much too late that the monitor in question turned out to be a 12V monitor, and I was trying to have all the pieces be consistently 5V. I needed to adapt my strategy if I wanted to have a system powered by only one adapter. So, I bought a power adapter that output 12V and 5A, which I would use to power the monitor first, then bring the remaining power down to 5V via a buck converter.

Overview

This note presents a few different ways of building an microcontroller-based IR receiver. It is meant as a complement to the "PC media remote" note.

The idea is to somewhat parallel "Software design patterns" -- only for physical hardware builds. The note provides a variety of implementation examples for an IR receiver project. Juxtaposition is used to compare various different mechanical/mounting systems that provide structure, and also different practical connectivity solutions. Hopefully these options will make builds feel a bit more approachable, and possibly inspire new ideas.

Regarding the overall design philosophy: Attempts were made not to solder everything together in one monolithic block. Design often involves making mistakes, so having a way to easily re-configure your solution as it develops really helps.  More specifically, I find that building "blocks" in a somewhat modular/generic fashion is preferable to building something that is completely "application-specific".  As a bonus, if your blocks don't quite work out the way you want, they can more likely be re-purposed in later projects.

A good way to improve on the original "PC media remote" breadboard example is to use the IR receiver module (#5939). The build pictured above makes use of the STEMMA-QT port from a PiCowbell protoboard, and mounts all components to a 5x5 Adafruit swirly grid. Overall, this build should be a little more robust than what can be obtained with the breadboard solution, yet still be achievable without any soldering (if using Pico board with pre-soldered headers).

Some things to keep in mind:

• Need a custom 4-pin JST-SH to 3-pin JST-PH cable.
• Make sure the pin order is correct to avoid damaging the circuits (especially power/gnd).

Connecting the 2 boards in this fashion requires modifying a pre-built JST-SH cable (this one, for example). Crimping JST-SH connectors can be a bit difficult due to the small size, but removing the 4th (yellow) wire from a 4-pin connector is a bit more manageable. A hobby knife can be used to ⚠️carefully lift the plastic tab to release the pin/wire. Once that's done, JST-PH pins can be crimped to the other end of the cable, which in turn snap into the 3-pin JST-PH connector needed for the IR receiver terminal.

I replaced the electronics (which had died) in this product from Now and Zen.  Original Product 

Here is a link to the video where I talk about it.  Video

Due to severe RSS, I coded all of this with Talon Voice. There are lots of things I would do to clean up this code (remove globals, clean up use of enums), and given how hard it is to code with my voice, I'm going to leave it as is.

Overview

The MyState library delivers a framework to simplify configuration and control of appliance-like devices. MyState makes it quick-and-easy to define device state that is readily controllable from the outside world.

Writing code to control state and react to sensor inputs is time consuming. Why not (mostly) solve the problem once, and re-use that infrastructure to build up your next project faster?

Features

• Route raw sensed input signals through custom signal-generating filters, and provide a solid, uniform user-interface experience.
• Load custom device configuration/controlled state on startup by calling ListenerRoot.script_load().
  • A good way to "recall presets" at the press of a button when manual configuration is a bit of a pain.
• Let anyone control your device using SigLink interface (by means of a serial/other IO connection).
  • Ex: Let a PC control your device using MyState "signals" sent across the USB/serial connection.
  • Configure your device using a custom-built GUI or web interface.
• Applies more formalized (hopefully readable) patterns of "filtering" input/sense signals, and applying a "reactive paradigm" to respond accordingly.
• Aspires to enable a future of composable, modular devices where extension/customization is the norm. Getting our products to cooperate should not be a constant battle requiring mounds of ugly hacks.

✨Highlights

• Call SigLink.process_signals() to enable quick-and-easy device control via serial/IO connection.

Details

The framework provides access to device state using something the author calls a "Model-React-Controller" (MRC) -- analogous to a Model-View-Controller.

Code Repository

• Development repository on github: MyState.
• Project examples (self contained): HomeLights_Wired. --- Download:v0.1.

SampleProj: HomeLights_Wired