C3P0 can talk. R2D2 expresses what he's thinking with beeps and boops. What can you do with a Neo Trinkey?

 

How about.....Morse code? It's simple, and four neopixels is more than enough to say anything! Here's how I set about doing it.

The great thing about Circuit Python is you can just plug in a device and use any editor on the code, but I like to use thonny as my IDE. Thonny gives you easy access to the REPL and you can have plenty of print() statements for debugging.

Wippersnapper

For those not in the know, WipperSnapper is Adafruit's plug-and-play firmware, which runs on their IO (think IOT) platform, offering free* data history(feeds) with graphs, dashboards, and automatic actions/triggers (along with integrating with other platforms like IFTTT). There is a paid upgrade for longer history, unlimited devices, SMS alerts, etc.

I love it because it's super quick and easy to test a sensor works, and to just get some data recording quickly. 

Goto a web-page, flash over usb, add sensors via control panel (feeds + graphs are automatic), done.

Under the hood it's an arduino sketch, so adding additional sensors via github pull requests is surprisingly easy (I've added a few because it makes my future tasks easier).

For this project I'm testing the Sensirion SEN55, which senses Nitrous Oxides (NOx), Volatile Organic Compounds (VOCs), with temperature and relative humidty as a reference (uses SGP40/41 inside), and measures particle counts at <1.0 micron, <2.5, <4.0, and <10.0 micron. The other models of this sensor have less features (SEN54: no NOx, SEN50: no NOx/VOC/Relative Humidity+Temp - only Particulate Counts).

From the standard drivers(arduino/Pi) created by Sensirion we can retrieve the typical particle size, along with the raw particle counts (or in SI units ug/m3), the temperature and humidity, and then two indexes for NOx and VOC. 
The NOx index has a baseline of 1.0, and if you hide the sensor under an upside down saucepan and use a lighter under the saucepan before sealing it back up then you will see a rise in the NOx index and then a return to baseline (1).
The VOC index is instead based at 100. You can detect VOC events from many things, the human breath can even be a source. I tested mine with a jar of clear nail varnish, but anything which you can smell, or smells chemically, is probably going to affect the sensor.

Connectivity-wise, it uses I2C, or other methods (UART?) which are as yet unpublished. The connector requires a JST-GHR 1.25mm 6 Pin compatible cable. The development kits include such a cable, but are heavily marked up cost-wise, like an additional 150% (£50 for kit, £20 for bare sensor). I advise getting a bare version with an additional cable from elsewhere (coolcomponents have a cable under £2). There is also a Grove connector version from seeedstudio.

 

I love using the random library - it's a simple way to introduce variety into simple programs and here's one example, what I call "Spock on a Chip." Here's a link to the repository.

Copy the files to a NeoTrinkey, changing "spock.py" to "code.py" - when it runs, it occasionally blinks lights, but when you touch one of the pads, it will blink and then pick a random quote out of the "spock" file and print it. If REPL=True, you'll need to be in an editor like mu to see the text. IF you change REPL to be False, then it will use HID support to send the text as if typed on a keyboard! Just the way to jazz up your email! Edit the "spock" file to add your own favorite quotes from everyone's favorite Vulcan.

 

What's going on?

There are two functions that are used to deliver the quotes. len_file(filename),

def file_len(filename):
    with open(filename) as f:
        for i, _ in enumerate(f):
            pass
    return i + 1

 

and wisdom(file_name).

def wisdom(filename):

    qs = open(filename)
    for i in range(random.randrange(file_len(filename))+1):
        quote = qs.readline()
        quote = quote.rstrip()
    cmpthink()
    qs.close()
    return (quote.rstrip())

 

Give a file name, wisdom() calls len_file() to determine how big the file is, then uses random.randrange() to select the text - that means you can add or subtract from the "spock" file without needing to update the program.

 

The fun thing with this code is, it can be reused for other purposes. I've already used it to put together a "story" program that uses multiple source files (aliens, suns, planets, etc.) that can be drawn from to generate story lines. It could be used for a diceware style passphrase generator. And, of course, it doesn't have to be Spock on a chip - you can fill the "spock" file with any quotes you choose.

 

 

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

How many matrix panels can you use with the Matrix Portal S3?  Theoretically, around 50, however the more panels you add the greater the travel distance and signal degradation. Degraded signals can have effects of pixel artifacts/glitching and visible scan lines that are very hard on the eyes. 

The bit depth (amount of possible colors) is also very important. 12 panels cannot stream more than a bit depth of 4 without significant artifacts.  Normally with Circuit Python, images are 8-bit indexed BMP's but matrix panels can only display a maximum of 6-bit color. A TFT can support up to 24-bit so do not make the mistake of treating a matrix display like a TFT. It will still process 8-bit indexed BMP's with some image quality loss due to the nature of RGB LED's in a matrix panel.

For this project I'm using 12x 5mm pitch matrix panels. The pitch denotes the physical distance between pixels. A 3mm pitch panel will be much smaller physically than a 6mm pitch for example.

Panel Arrangement

The serpentine arrangement of the panels matters.  If you get it wrong you'll end up re-arranging the entire matrix until you get it right. The RGB Matrix library expects the controller (Matrix Portal S3) to be in the top right of any arrangement regardless of post-processing rotation in the code. The library expects each 2nd row to have the panels flipped 180 degrees as shown below. You can have each row or column with as many panels as you want so long as the rules of the serpentine arrangement are adhered to.

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

3D files and (lack of) code

You can find the 3D files for the modified HAL parts, as well as the case for the QT Py on Printables. The wiring is pretty basic; in addition to the wiring from the learn guide, I wired one of the RP2040 Feather's UARTs to the headphone (TX, RX, GND) jack, and the other to a 4-pin JST connector (5V, GND, TX, RX) with a few inches of wire. A corresponding JST connector is soldered on to the QT Py, with the 5V and GND wires connected to the battery power pads on the bottom of the board, and the TX/RX wires connected to the corresponding RX/TX pins.

I did not post any code for this as it is highly specific to my situation, however, to be honest, none of the code is particularly special. I used the CircuitPython MQTT learn guide to figure out how to get connected to my local MQTT network, and the CircuitPython essentials guide to work out how to use the UART (for communication) and PWM (for animating the LED).

Overview

I love this make of HAL-9000 from the Ruiz Bros:

Playing animated GIFs was added to CircuitPython in early 2023 and I had successfully had them running on TFT displays and even to a monitor via HDMI. I recently setup my MatrixPortal and two 64x32 matrices that I had been using to show animated GIFs. But the MatrixPortal was running Arduino code.

Time for an update and to take the code from Using Animated GIF Files in CircuitPython and Creating Projects with-the CircuitPython MatrixPortal Library and smush them together to play animated GIFs on a MatrixPortal with CircuitPython. Both guides do a great job of explaining the details of their own area and the code here combines them both.

The first half of the code sets up the matrix on DisplayIO and the second half uses OnDiskGif from the gifio module to display the animated GIF.

The code displays all GIFs found in the /gifs/ directory on the MatrixPortal. Each animated GIF will display for 30 seconds before moving to the next animation.

One major difference from the Animated GIF guide: for speed, the code in the guide sends the raw bitmap data directly to an attached display. In theory that is possible to do on the MatrixPortal but it is more complicated and likely would be slower then using DisplayIO. This is because the matrices have fewer pixels then most screens and the speed of the protomatter library that powers the matrix display.

Part one : Where's the mic? 

"Breaker breaker , any takers? This is the the one and only Delchi hunting for bear on I-95 South , keeping that double nickel and keeping the sunny side up & the greasy side down! We gone!" ¹

I was looking for some new gaming frontiers when I came across truck simulators! All the skill & thrill of a big rig from your PC. As with all simulators there are button boxes and realistic cockpits to buy, but one thing I didn't see was a CB radio mic! They expect us to use desktop mics, headsets or some other hoo-haw instead of the ol jabberjaw microphone! A little deeper digging showed that you can buy adapters, but they ranged from $180 to $300! ( Granted the $300 one is an awesome button box and has a lot of realistic controls along with the mCB mic.) 

Well the first thing I did was say "Belgium" to that, and pulled Rolling Thunder across the room to my workbench and got to work. This was going to be a project that would work with Truck simulators, sub simulators and more! Grab that soldering iron, the wire clippers and that drill over there! It's time to start making! 

 

Notes : 

1. CB radio jargon was around long before IRC , and was its own language designed to obfuscate communication and have a grand ol time. "Handles" were common, and yes CB radio handles are where the hacking community got the term handles for hacker aliases! 

Translation? Why not ? 

• "Breaker breaker , any takers?"
  • In cb radio ( less formal than ham radio ) it was common to ask permission before talking on an open channel. Calling for a "break" was like requesting permission to chime in , and was normally answered with "Go ahead breaker"
• "This is the the one and only Delchi"
  • Handles were a point of pride and very often unique, but when they did collide they politely adjusted to be like "The New Orleans Joker " vs "The Chicago Joker" and so on.
• "hunting for bear on I-95 South"
  • Truckers took great lengths to avoid being caught by the police in speed traps. "Smokey Bear" referred to the Smokey The Bear hat most often worn by police patrolling the interstates. If you were hunting for bear that meant you were on the lookout for police, and sometimes were asking for a "Smokey report" if anyone had seen any police.  You usually followed this with the interstate you were on and the direction you were traveling and sometimes the mile marker you had passed most recently.
• "keeping that double nickel"
  • This referred to the speed limit of 55 miles per hour that was enforced back then. Sadly there is no clever phrase for the 65 mph speed limit.
• "keeping the sunny side up & the greasy side down!"
  • Multiple meanings here, but for the most part this meant keeping your truck upright ( sunny side was the cabin, greasy side was the road ). It was like wishing someone safe travels and no accidents. 
• "We gone!"
  • When a conversation ended people would signal this with a number of phrases like "we gone" , or "On the side". Sometimes it also included the "10-code" messages such as "10-10 Till I see you again"

Related Links : 

• Truck Simulator
  • https://americantrucksimulator.com/
• Button Box
  • https://www.simpanel.com/ats
• 10- Code & other jargon
  • https://www.rightchannelradios.com/blogs/newsletters/cb-radio-slang-and-10-codes

 

Part Two : Requirements

So then at the workbench with graph paper and pencil in hand ( or Lucidchart if you will ) let's determine what we need to make this CB mic project roll down the road : 

• Utilizing a CB Microphone
  • Be able to attach the microphone to the computer
  • Be able to use the button on the microphone to activate the  PTT ( Push to talk ) feature on the computer / in game
  • Make it look realistic! 
  • Make it as clean as possible ( minimum number of wires / software / configuration )

 

Circuit Diagram

The diagram below provides a general visual reference for wiring of the components once you get to the Assembly page. This diagram was created using the software package Fritzing. Note that we will be using all available GPIO pads on the QT Py, so there will be a good bit of soldering involved.

Overview

Modern electronics are capable of incredible things. Even the simplest gadgets now have clocks, gyroscopes, radios, GPS, touch screens, literally anything you can imagine, built right in. Sometimes though, the devices that are capable of doing several things don't do all of them particularly well. Touch screens are often bolted onto things that really don't benefit from them, or even worse, detract from the experience. Anyone who has accidentally grazed the touch panel on an Apple TV remote while grasping for it in the dark knows exactly what I'm talking about. Sometimes I just want to have a remote with a few simple buttons I can press to make things happen, and that's it!

Most of the lights in my apartment are WiFi-connected, and offer MQTT capability. I took advantage of this and set up a local MQTT broker (https://mosquitto.org/) on a Raspberry Pi 4 wired to an old Apple Airport router/hub I had lying around (my internet provider makes me use their router for my internet). Now, it's easier than ever to control my lights...from a browser. Or some phone interface. Or an app. Wait a second...each of those still requires multiple steps just to get me to the point where I can actually control anything. And I probably still have to use a touch screen. Leading me back to my original point, and thus the motivation for the imaginatively named:

WiFi Matrix Keypad Remote

I've been a DIY remote control enthusiast for almost as long as I've been hacking around with microcontrollers (at least a few years now). One thing that I've found really hard to source as a hobbyist is good, pre-made button panels intended to be mounted into a small space, such as a remote control. So far, one of my favorite sources for a dense panel of decent quality, inexpensive buttons are these old-school 3x4 matrix keypads:

I recently released another retrocomputer miniature that incorporates a handful of Adafruit boards so I thought that I'd share the details here.

The original Connection Machines were built in the late 80s and early 90s to provide a few thousand hyper-connected processors which at the time was rather unique. If you're interested, here's a wikipedia page about them.

My Patreon supporters vote for which miniatures I make and I was pretty happy when the Connection Machine was chosen. I was also happy to find that Adafruit sells pretty much exactly what I needed to make the blinking light panels:

• QT Py ESP32-S3 x1
• Red LED matrix x4
• Matrix driver board x4
• Stemma QT cable x4

Assembly requires me to solder the four matrix driver boards to the four LED matrix boards and then plugging in the Stemma QT cables between the QT Py and a chain of the driver boards.

Then I assemble these printed parts. The little C shaped parts on the lower left of this photo are what hold the two-board sandwich of the LED maxtrix board and the driver board.

Then I install CircuitPython on the QT Py and then load it with my code from Codeberg. There you'll find the default blinkenlights script but also a script that uses the network to fetch the time and then turn the Connection Machine into a clock. It took a bit of work to figure it all out so hopefully the code will be a handy starting point for similar projects.

Once everything is assembled I box it up and put it on my gumroad store.

I post pretty much every day about what I'm working on over on Mastodon at @[email protected] and for maker-y types of conversations I like that place much more than the other social media sites. Maybe I'll see you there!

The first step is to get BrickLink Studio 2.0. This CAD program is intuitive to use, includes almost all bricks available, and features to test your model strength, render 3D visuals of it, view what parts you use and even generate instructions on how to build your model. This is not a guide on how to use Studio 2.0, but it includes a built in tutorial that makes getting started a breeze.

John Park wrote an excellent guide Lego Set Lighting. I used this guide to light up the LEGO Christmas Tree (set #40573) making the candles flicker away. My problem was how do I hide the electronics running everything.

I had the idea to design and build a LEGO model in the shape of a present, but the question was how.

It turns out there is an easily accessible CAD program and method of ordering parts (maybe too easy!).

This project was a personal desire to put Adafruit IO through it's paces, and see how far I could go in recreating a project designed for ESPHome + Home Assistant. Traditionally I would have assumed it was too complex for the Actions and Dashboard of Adafruit IO if I used a Wippersnapper device, instead relying on Node-RED to string things together, but now that I work on the WipperSnapper project I was curious how far it had come / could go.

The basic idea was to take a £60 "dumb" air purifier with a 3-speed dial (£70 with carbon filter) and add a WiFi micro-controller, so that it can be switched on and the speed controlled according to the values sent from a separate Air Quality sensor (Particulate Matter <2.5µm), and a user-adjustable control panel hosted as an Adafruit IO Dashboard.

Is this another silly idea / tribute to insanity, by needlessly bolting the internet and a subscription service to a device, which usually degrades performance and adds built-in obsolescence (not to mention a 22second boot-time)?

Well maybe, or maybe it's just a way of providing people with alternatives, but either way it involves Adafruit IO as an alternative to Home-Assistant / Node-RED or the official IKEA smart-hub + smart devices, and Adafruit's open-source IOT firmware called WipperSnapper as an alternative to ESPHome.

It's possible to use on the free-plan on Adafruit IO (you do NOT need IO+), or offline with a little coding, so I don't feel bad about suggesting it...

Here's a demo video of it in action: (Adafruit IO Dashboard on left, WipperSnapper device page on right, Speed dial of Air Purifier + Wind Sock on Picture-in-Picture video)