Overview

A local production company is working on filming the first of a three-part sci-fi movie and needed a piece of scientific equipment for a laboratory scene. The executive producer/director found an obsolete flow cytometer analyzer in a government surplus sale, winning the bid for US$12. The device had the potential to look like a working DNA synthesizer with the addition of lighting and a bit of animation.

In its day, the analyzer was a high-quality device that was robustly built to provide exceptional mechanical stability for its sensitive optical components. It was therefore quite heavy in spite of its size, requiring at least two persons to lift and position, which would increase the challenge to modify for use in the film. It was not a typical theatrical prop made from foam and balsa wood, for certain.

I was tasked with installing color lighting to enhance the device’s operational appearance for its brief appearance on-screen. To achieve this, I devised a plan to incorporate several NeoPixel LED strips, which would be controlled by a CircuitPython-based microcontroller, such as the Adafruit M4 Express Feather. The multi-colored NeoPixel LEDs could be strategically positioned both within and outside the device, thereby providing ambient illumination and symbolizing various functions, including sample loading and the incubation process.

Given that the initial device employed industrial-grade servos (specifically, three IMS MDI-17 Drive Plus Motion Control motors) for sample positioning and operating the sample fluid “sipper” needle, there was a preliminary aspiration to incorporate robotic physical movements beyond the lighting sequence. However, this objective was deferred due to the imminent project deadline, so a short puppetry cable would likely be attached to the sample positioning cam to animate movement of the test tube rack.

This note describes a method to output Eurorack CV (control voltage) signals from CircuitPython synthio using the PCM510x I2S DAC.

Rather than employing CV-like object controls such as Envelope and LFO to only adjust the parameters of other synthio objects, it would be useful to also control physically external devices such as the CV inputs of Eurorack modules. To do that we'll need to configure the synthio.Note object to ignore its typical behavior as an oscillator. Oh, and it would be handy to have an I2S DAC on-hand with a DC-coupled output that's capable of positive and negative output voltage that can be connected to a Eurorack module.

Here's the test setup:

1. Create a Note.waveform (wave shape table) object containing the maximum wave value (16-bit signed). This is an array filled with a single value that acts like a fixed DC voltage.
2. Set the Note wave shape oscillator frequency to an arbitrary value such as 440Hz. The frequency value is unimportant since the oscillator waveform output will simply be a fixed value.
3. Define a synthio.LFO object to output the LFO signal. If outputting an ADSR envelope is desired, define a synthio.Envelope object.
4. Create a synthio.Note object where the amplitude parameter is controlled by the ADSR envelope or LFO.
5. "Press" the note to output the ADSR envelope or LFO signal from the I2S DAC.

Instead of the I2S DAC, CV output signals can be created in this manner using audiopwmio and audioio to use PWM or analog DAC output pins. Boards like the QT PY RP2040 and Grand Central M4 Express could be used for PWM or analog DAC outputs. Keep in mind that, unlike the 0 volt baseline of the I2S DAC, the baseline of a PWM or analog DAC signal is biased to approximately +1.65 volts.

I2S DAC Output

Deadline: We need it tonight

We have just eight hours until our classic rock band rehearsal session tonight, and we need some pre-recorded sound effects for three songs. The required sound effects (SFX) playback machine should be super easy to use, powered by a battery, and have a stereo output for the band’s PA system. Sound quality is important, but since the sound effect recordings aren’t actual music, we can be flexible with the bit rate to save space on the storage.

The band retired six years ago and, at the time, it didn’t seem like there would be a reunion tour. So, I stripped the old sound effects machine (the FXM-8 shown above) for parts and gave it a new life. The old unit used a special SFX board (Adafruit #2220) with .ogg sound files stored on-board. It worked and sounded good, but it was a pain to update the files. The simple and obvious FXM-8 tactile interface was also pretty cool in hindsight.

And of course, the band’s plans changed. They asked us to come out of retirement and play one more gig.

So, we’re going to need a new SFX machine.

Project Objective

I have an Adafruit IO (AIO)-connected corrosion monitoring system in my remote laboratory (the workshop bench in the garage) to keep an eye on the temperature and humidity inside and outside the lab. It uses CircuitPython to monitor the temperature and humidity, and it also uses AIO Plus to connect it to the weather outside. But here’s the thing: the temperature and humidity sensor can’t tell if a door or window is left open. It takes way too long to notice the change. I wish it could “see” if a small area inside the workshop has a different temperature than the rest of the space. It would also be great if it could detect human motion in the workshop or if the soldering iron was left on.

Requirements

1. Periodically capture and upload a thermal image of a critical portion of the workshop.
2. Monitor for temperature extremes and upload an image when exceeded.
3. Detect human motion and upload an image.
4. Provide a local color display with automatic brightness control.
5. Continuously update the local display image at least twice a second to quickly detect motion and respond to thermal events.
6. Upload the captured thermal image on a remotely accessible AIO dashboard page via the local WiFi network.
7. Upload bitmap image payload to AIO in less than 10 seconds.
8. Power from a USB 5-volt wall wart.

Future and Nice-to-Have

1. Blank the screen when motion has not been detected for a preset amount of time (screen saver).
2. SD Card storage of images and temperature statistics with historical view UI.
3. Trigger AIO notification events related to motion or alarm settings.
4. Upload minimum, average, maximum temperature values with image; display on dashboard.
5. Interface to Apple HomeKit.
6. Capture local audio.
7. Live MEMENTO photo overlay.

To speed up prototyping and algorithm development, CircuitPython was the choice for the software side of things. Besides, the code needed for creating images with a thermal camera and for reliable communication with AIO already exists in other projects that I've recently developed.

System Components

The thermal camera components consist of:

• ESP32-S3 4Mb/2Mb Feather.
• 2.4" TFT FeatherWing (optionally wired for display brightness control and an ambient light sensor).
• AMG8833 Thermal Camera Breakout, connected to the ESP32 Feather with a 100mm STEMMA-QT cable.
• An optional ALS-PT19 Analog Light Sensor Breakout connected to the TFT FeatherWing's +3V, GND, and A3 pads. The light sensor is used to automatically control display brightness in proportion to the ambient light level.

If display brightness control is needed, the TFT FeatherWing will require a short jumper wire soldered to connect the TX pin and LITE pads to allow PWM control of the display backlight brightness. (See photo.)

For automatic display brightness control, connect the ALS-PT19 light sensor output to the A3 GPIO pin pad. Also connect the sensor's power and ground to the FeatherWing's 3V and GND pads. For the prototype, three Dupont Cable 20cm Soft Silicon wires were cut in half and with the wire end soldered to the sensor breakout and the Dupont pin end inserted into the outer row of the Feather socket as shown in the wiring photos.

The OM Weather Display periodically updates and displays the following local weather conditions:

• Day, date, and time (AM/PM)
• Tomorrow's sunrise and sunset times
• Temperature
• Relative Humidity
• Wind speed and direction
• Wind gust speed
• Condition description and graphic icon

Location, time zone, and measurement units settings are stored in the settings.toml file. Either "METRIC" or "IMPERIAL" measurement units can be specified.

Weather condition query and internet clock refresh interval rates are set by parameters in the code.py module. The default interval for updating weather conditions is 5 minutes. The local time is updated from the Adafruit Network Time Protocol (NTP) server hourly.

The CircuitPython code runs on an ESP32-S3 4MB/2MB Feather attached to a 2.4-inch TFT FeatherWing. An optional ALS-PT19 ambient light sensor can be used to automatically adjust display brightness.

CircuitPython Code

The Weather Display's CIRCUITPY root directory contains the following files and folders.

• files:
  • settings.toml -- Wi-Fi and location parameters
  • om_query.py -- OM API URL query string builder
  • who_to_map_icon.py -- parses the WMO weather code for descriptions and icons
  • code.py -- the primary code module
• folders:
  • fonts -- contains the font files
  • icons_160x160 -- the weather icon bitmap graphics files
  • lib -- the CircuitPython library modules
  • sd -- a placeholder for the unused SD storage drive

A downloadable bundle of code files and folders can be found in the OM Weather Display GitHub repository.

Overview

The initial version of the weather system architecture, known as the Display AIO Local Weather Conditions: MatrixWeather System, exhibited satisfactory performance. However, its reliability was compromised when multiple transmitter and receiver devices competed for access to the Adafruit IO (AIO) feeds. To mitigate access collisions, each independent device was meticulously designed to transmit or receive data at predetermined rates, which remained well below the AIO+ subscription rate limit of 60 data point transactions per minute. Nevertheless, due to the autonomous operation of each device, instances arose where two transactions would heterodyne, straining the limit and resulting in feed failures.

To address the reliability issue, the new architecture design transitioned from utilizing MQTT to the HTTP protocol. While MQTT facilitates relatively straightforward “subscription” to AIO feeds, HTTP offers greater control granularity, including a recently introduced feature enabling independent devices to monitor feed access activity. Collisions can be mitigated by monitoring the number of data point transactions remaining and waiting until a sufficient number are available for the queued transaction event.

The primary architectural modification was the incorporation of throttling. A secondary objective was to reduce the number of devices in the system by combining the existing Corrosion Monitor sensor with the REPEATER device, resulting in the creation of the novel Weather SOURCE device. The Weather SOURCE extracts local weather conditions from AIO+ Weather and integrates them with the local sensor’s temperature, humidity, dew point, and corrosion detection data. Subsequently, the Weather SOURCE publishes this information to a collection of standard AIO feeds.

The other devices within the system comprise displays that extract data from the AIO feeds. One display replaces the previously existing Workshop Corrosion LCARS Monitor (PyPortal M4), which was situated in the workshop, and is now designated as the Workshop Corrosion Monitor Display. The second display is the Living Room MatrixWeather Display (upgraded from a Matrix Portal M4 to the S3 version). Given that AIO feed access rates are monitored, it will be feasible to create additional task-specific displays, potentially for the studio or kitchen.

An advantage of the new architecture is that certain display devices will not require substantial PSRAM for retaining the extensive JSON file provided by AIO+ Weather, with the exception of a Matrix Portal. The singular Source device, equipped with a large PSRAM, extracts solely the essential information required by the displays and stores the extraction within the AIO feeds.

Weather Source

The primary source of AIO+ Weather and the local workstation temperature/humidity sensor employed for corrosion detection are the primary sources of data. These sensors transmit weather and local workstation conditions to AIO feeds in the client’s account, which are subsequently retrieved by display devices.

A new version of the Weather Source, the Nuevo Combined Weather Source device, will replace this version by late 2025.

CircuitPython code can be found in the Weather_Source/bundle folder of the CedarGrove Weather System repository.

The MAX98357A 3-watt I2S amplifier is wonderful way to output tunes from CircuitPython synthio, but because it produces a balanced Class-D output that only works with speakers, it doesn't interface well with standard unbalanced audio inputs on guitar amplifiers or a workstation's DAW (Digital Audio Workstation). After a couple of somewhat successful attempts to reintegrate the digital speaker signal with special analog amplifiers, it became obvious that what was really needed was an I2S stereo DAC like the discontinued Adafruit UDA1334A DAC (PID#3678).

A search of in-stock and active I2S DAC chips yielded the Texas Instruments PDM510xA family of I2S audio DACs that could meet the overarching project requirements of:

1. Provide an unbalanced ground-centered stereo line-level audio output using a single power supply.
2. A direct pin-for-pin compatible breakout stackable/replacement for the MAX98357A amplifier including shutdown capability (SD).
3. Approximately the same size as the UDA1334A breakout.

The PDM510xA family does not require a master sample clock as the internal phase-locked-loop (PLL) extracts the master clock from the bit clock (BCLK) input. Also, the ground-centered audio output is achieved with an on-chip negative voltage charge pump, eliminating the need for bandwidth-limiting DC blocking capacitors on the DAC output pins.

Assembly of the PCB (YouTube):

The CG-35 is a CircuitPython emulation of the Hewlett Packard HP-35 Scientific Reverse-Polish Notation (RPN) calculator designed for the Adafruit ESP32-S3 Feather and 3.5-inch TFT FeatherWing capacitive touch display. The calculator consists of a 10-digit LED-like display backed-up with 20-digit internal calculation precision.

This emulation reproduces the HP-35 calculator's v2.0 firmware where the change sign (CHS) key is active only after digit entry has begun. And because of the udecimal and utrig classes, calculation accuracy of monadic, dyadic, and trigonometric functions was improved. As an added bonus not present on the original calculator, a status message will appear just below the primary display when a calculation error is encountered.

The calculator's graphical layout was designed to mimic the aspect ratio of the original calculator -- that's why the left and right sides of the display screen were left empty. However, to provide a more reliable touch screen experience, the keys are somewhat proportionally larger than the original.

This project was inspired by Jeff Epler's DIY Desktop Calculator with CircuitPython project and Jeff's work to create CircuitPython versions of udecimal and utrig. Thank you Jeff!

GitHub Repository: https://github.com/CedarGroveStudios/CG-35_Calculator

Primary Code Module

The primary code module cg_35_calculator.py, imported by code.py, instantiates the display, plots the calculator case and buttons, and implements all calculator operational processes. This module uses a state machine design with the following named states:

• IDLE -- Display results or wait for input
• C_ENTRY -- Coefficient entry (keys: 0-9, ., CHS, EEX)
• E_ENTRY -- Exponent entry (keys: 0-9, ., CHS)
• STACK -- Stack management (keys: ENTER, CLR, CLX, STO, RCL, R, x<>y, π)
• MONADIC -- Monadic calculator functions (keys: LOG, LN, e^x, √x, ARC, SIN, COS,TAN, 1/x)
• DYADIC -- Dyadic calculator functions (keys: x^y, -, +, *, ÷)
• ERROR -- Calculation error

The calculator's display precision and internal calculation precision are specified using the variables DISPLAY_PRECISION and INTERNAL_PRECISION. Although the internal precision exceeds that of the original HP-35 calculator, it is recommended to keep the existing default settings of 10 digits and 20 digits, respectively, to avoid rounding errors.

The variable DEBUG can be use to provide additional internal register status via the REPL. This boolean variable defaults to False (no additional register status).

 

The objective of this project is to replace the existing WeatherMatrix project's MatrixPortal M4 display with a newer version that uses weather data provided by Adafruit IO Plus (AIO+) instead of the openweathermap.org web API. The requirements include:

• Implement with CircuitPython for ease of development and prototyping.
• Duplicate the existing 64x32 LED matrix display layout including label colors and icons.
• Develop an architecture to support multiple autonomous displays and local data feed devices (new).
• Utilize a weather data source that accurately aggregates station information that closely matches local conditions.
• Weather data updated approximately 3 times per hour and is reliably available.
• Service subscription is free or reasonably priced.
• Include data elements for wind gusts and local workshop temperature (new).
• Display a progress bar to indicate data time since last update (new).
• If possible, use the existing MatrixPortal M4 hardware; upgrade to MatrixPortal S3 only if necessary.

Special Acknowledgements

Thank you to John Park for the initial weather display design concept (see Weather Display Matrix) that inspired this project. Also, the work of Trevor Beaton was instrumental in creating the updated display design with a clearer and simpler coding approach (see itsaSNAP Daily Weather Forecast Board).

Choose a Weather Observation Source

Three options for sourcing weather data were considered. Here are some pros and cons of each.

openweathermap.org:

• utilizes the existing or similar web API; minimal code changes will be needed
• weather station aggregation often doesn't always match local conditions
• data retrieval throttling is reasonable with a consistent service level
• free service was phased out; will eventually require paying for the service

weather.gov:

• a moderately well-documented web API; moderate code changes will be needed
• weather station data is not aggregated and closely matches local conditions
• single weather station data is not reliably available, sometime for hours at a stretch
• data retrieval throttling is currently reasonable, but without a guaranteed service level
• a free service

AIO+ Weather (Apple WeatherKit):

• moderately well-documented CircuitPython library approach; major code changes will be needed
• weather station data is aggregated and matches local and iPhone conditions
• data retrieval throttling is reasonable with a consistent service level
• weather data and workshop conditions can be combined and viewed on a web-based IO dashboard
• requires a paid subscription to AIO+ for access to its Weather Service

The choice to use AIO+ Weather was an easy one since my existing weather tracking and corrosion monitoring projects require a subscription to AIO+. We'll need a new system design and a major rewrite of the existing MatrixWeather project code to make this happen, providing ample opportunities to improve performance and reliability. The next step was to redesign the overarching weather system architecture.

See weather.gov: A Truly Free Weather API and AIO+ Weather: A Premium Alternative for Local Observations for a detailed discussion of each alternative.

The weather API of openweathermap.org has been a trusted source of local weather, reliably feeding my projects for quite a few years. Their API design is very complete and easy to understand, not to mention that it interfaces nicely with CircuitPython.

They recently changed the API service model for openweathermap.org. Although there is a "free" service tier, a credit card is required just in case the usage exceeds the free use threshold. My projects only need a single query response every 20 minutes, clearly falling in to the lower portion of the lowest tier, but I didn't like having to share a credit card number when no money would need to change hands. Call me old-fashioned, I guess. I started looking for better alternatives.

The National Weather Service API

After reviewing many of the free-ish weather API offerings, I stumbled on the mythological metrological holy grail, the NOAA National Weather Service (NWS) API Web Service. The NWS API provides free access to alerts, observations, and forecasts without the need for a user account or API key. I was pretty excited to find that NOAA's NWS data was available to the general public since I assumed that other weather APIs use NOAA NWS as an essential data source for their services.

 

The NWS API incorporates the entire national network of NWS offices and stations. A large range of services are available through the API including alerts, forecasts, aviation weather advisories, and summary report products. For my projects, I'm primarily interested in obtaining current local weather observations such as temperature, humidity, and wind speed/direction. We'll focus on that limited data scope for this Playground Note.

Queries are requested with a simple URL call to https://api.weather.gov, such as

 https://api.weather.gov/stations/KSEA/observations/latest

to see the latest weather values for the Seattle-Tacoma airport in Washington state. You can test the query by pasting the URL into your browser.

This is the second chapter in the "Finding an openweathermap Alternative," my latest choose-an-adventure saga exploring the weather API wilderness. The first chapter,  weather.gov: A Truly Free Weather API, looked at the completely-free NOAA NWS API Web Service as a replacement for openweathermap.org's API. The next area in our search is the weather power-up module of the premium (not-free but affordable) Adafruit IO Plus (AIO+) service and its CircuitPython interface.

 

We all know about AIO's ability to collect and display sensor data as well as its integration with messaging and control protocols such as MQTT, IFTTT, and Zapier. But did you realize that, besides increasing throughput and feed limits, AIO+ also adds SMS and Apple WeatherKit services to the mix?

My Workshop Corrosion Monitor project needs 12 AIO feeds; 5 for locally connected sensors and 7 for external weather observations. The monitor can reliably detect a corrosion condition in real time by using its attached sensors. To predict when future corrosion events may happen, the monitor needs to know what's going on with the weather outside of the workshop. Rather than installing dedicated external weather sensors (requiring holes in the wall and reliable weather-proofing), openweathermap.org's API was initially used to obtain the outside weather conditions and trends. The API was an excellent implementation up until they served notice that a credit card would be required for the "free" tier of the service. That's when I started looking for alternatives.

The large number of AIO feeds for this project had already caused me to upgrade to AIO+. At the time, I didn't realize Apple WeatherKit was included in the premium service. Now I know. Replacing the openweathermap.org API service with AIO+ weather was therefore a no-new-cost alternative for the monitor project. Besides, if I'm going to be paying for a premium service, I'd rather be sending the money to Adafruit who is committed to openly describing and supporting reliable service levels, providing tutorials, and other efforts to assure product longevity.

The Weather Chimes project fills that need. It connects to the Adafruit NTP service for network time and to OpenWeatherMap.org for wind speed data. The wind speed data is retrieved every twenty minutes and is used to adjust wind chime playback in a pseudo random pattern. The chime voice synthesizer is provided by the CircuitPython_Chimes class and for this project, is sent to an Adafruit MAX98357A I2S amplifier driving an Adafruit 40mm 4-ohm 3-watt speaker. Although an Unexpected Maker Feather S2 was used for this project, the code should work on just about any ESP32 device that's capable of running CircuitPython.

The Weather Chimes project consists of two primary code files, weather_chimes_code.py and weather_chimes_wifi.py. The weather_chimes_code.py code is imported via the default code.py file contained in the Feather S2's root directory. This code contains the primary non-wifi device definitions and the master while... loop that plays the chimes. It also imports the WeatherChimesWiFi class from weather_chimes_wifi.py.

The WeatherChimesWiFi class takes care of all the networking details for connecting and retrieving data from the internet. It also provide helpers for updating and retrieving time and weather as well as properties for including the local time and wind speed. The WiFi class uses the settings.toml file for connecting to a home WiFi router as well as parameters needed for Adafruit NTP and the OpenWeatherMap.org API.

A fictional settings.toml file:

A CircuitPython project for indoor "windless" garden chimes that play along with the outdoor wind speed.

Weather_Chimes GitHub repository

BNo055 Sensor CircuitPython Driver GitHub:

https://github.com/adafruit/Adafruit_CircuitPython_BNO055

BNo055 Sensor ReadTheDocs:

https://docs.circuitpython.org/projects/bno055/en/latest/

Nunchuck CircuitPython Driver:

https://github.com/adafruit/Adafruit_CircuitPython_Nunchuk/blob/main/adafruit_nunchuk.py

Nunchuck ReadTheDocs:

https://docs.circuitpython.org/projects/nunchuk/en/latest/api.html#implementation-notes

Overview

The TV Backlight illuminates the wall behind the TV display to reduce eye strain. The backlight extends the background of the screen image by watching the color near an edge of the display. To reduce distraction, the color and brightness are integrated over time to avoid sudden changes.

The project's CircuitPython code reads the AS7341 spectrometer sensor's eight visible light channels to determine the backlight target color. Using a Euclidean "color distance" comparison, the backlight color is slowly changed to match the target color, within a specified tolerance.

The spectrometer sensor settings are adjusted for relatively low display light levels. The sensor's internal amplifier gain is set to maximum and the integration step and time values are adjusted to maintain a moderately fast conversion rate. Also, rather than just analyzing red, green, and blue components, all eight visible light channels are used to increase the accuracy and resolution of color measurements.

In this configuration, just one of the sensor's channels can reach a count value of near 13k, producing a composite 8-channel resolution that approaches 8x10³² color combinations, much larger than the 17x10⁶ (24-bit) color resolution of the NeoPixel strip. A color count to RGB converter helper reads the three primary color sensor channels, scales the count, and produces an RGB888 (24-bit) color value that's compatible with NeoPixels.

To assist in finding a position near the TV screen for the sensor, the Feather M4's on-board NeoPixel mimics the readings in real-time, albeit at a slightly lower brightness than the illumination strip NeoPixels.

Documents

Test video: https://youtu.be/yFqbalF0FGw

Next Steps

• Build a camouflaged enclosure and vertical mounting wands for the NeoPixel strips.
• Investigate animating the NeoPixel strip color change.
• For home security, enable the NotFlix (Fake TV) code when the TV display is dark for 5 minutes or more.

CircuitPython Code

In the process of learning to use CircuitPython synthio, it was a challenge to understand the myriad of possible connections between modules. As a result, project design notes and sketches became a rat's nest of entangled symbols and wiring. Although simple single-voice designs without filters or LFOs were easy to deploy and document, it became clear that there was more to discover inside the extensive versatility of synthio.

Perhaps a set of symbols with consistent notation (and color-coded arrows, of course) would be useful to further learn about synthio and to develop project conceptual diagrams.

Here's the beginning of some symbols for synthio objects with class properties and methods together with data types. Essential tools such as audiomixer and audiobusio are also included.

Attribution: Patch Symbols from PATCH & TWEAK by Kim Bjørn and Chris Meyer, published by Bjooks, are licensed under Creative Commons CC BY-ND 4.0. Some Patch Symbols were modified to create the synthio symbols BlockInput, MixerVoice, Note, Synthesizer, sample, and voice.

WaveViz is a CircuitPython class to create a positionable displayio.TileGrid graphics widget from a synthio.waveformwave table or synthio.Envelope object (or any one-dimensional list for that matter). The class also makes the underlying bitmap and palette objects available for other uses such as saving the widget to an image file.

The long-term objective is to be able to save and import sounds and ADSR envelopes from a library of synthio wave table files and envelope objects. The first step in the process is to create a visualizer to help characterize the sounds graphically. We'll worry about saving and retrieving waveform and envelope objects sometime in the future (watch for a new class, WaveStore to appear soon). For now, let's work on getting images of wave tables and envelopes.