Infinitely Baffled

The box above took over three hours to print. It’s perfect in every way except one. I’m going to have to print it again. The problem is with the speaker fitting at the bottom of the box. The speaker fits into the circle and is supported by four pillars. But the pillars are too high.

You can see the problem here. If I put the speaker on top of the pillars there will be a gap between the speaker and the hole it fits in. This makes it sound awful. To understand why we have to learn about about how speakers work.

The cone in a speaker goes backwards and forwards, pushing the air in front of the speaker to make sound waves we can hear. We really don’t want to hear anything from the back of the speaker because, although it is also sound, it is going the “wrong way”. The sound term for this is “out of phase”. When air in front of the speaker is being pushed forwards, air at the back is being pulled. If sounds from the front and the back meet up they can interact in ways that don’t sound nice.

Some speakers use carefully designed boxes which take the out of phase sound from the back of the speaker and reflect it in some way to invert the phase so that it adds to the sound. Other speakers solve the problem by putting the speaker in a sealed box from which the sound from the rear of the speaker can’t escape. These are called “infinite baffle” speakers. If you call the thing that we put the speaker into a “baffle” (which sound people do) you can see that an infinitely large baffle would stop any sound from the back of the speaker getting to the listener.

I’m trying to make my device use the infinite baffle principle. That’s why I have the circle that the speaker fits into and seals against. However, if I have a gap between the front of the speaker and the baffle I get sound leakage from inside the box and the speaker sounds rubbish.

So that’s why I reduced the height of the pillars and printed the box again. It makes a surprising difference to the sound. As to why I got this wrong in the first place: I made all the pillars in the box the same height, then I increased the height of the pillars that support the PICO In the middle of the board and that made the speaker pillars higher too.

Update: It’s just occurred to me that I have a hole in the back in the form of the power cable entry. I might convert that into a socket (or add a seal) and see if that makes it sound even better.

Dead Cockroach Building for the win

It’s called the “Dead Cockroach” approach. The chip in the middle is the cockroach lying on its back, and you wire directly onto the pins. It’s a good idea if haven’t got the time or inclination to make a printed circuit board and you don’t mind fiddling around a bit. The device worked first time, which was nice. I’ll tell you what it is later..

Don't forget your internal pullups

Behind the magic

I’m wiring a big red button onto a PICO. Above you can see the work in progress. Wiring buttons is easy, you just wire the button switch between an input pin and one of the many ground pins on the PICO. It should just work . Unless you’ve used AI to write the code (like I did) and forgotten to tell the AI to enable the internal pullup on the input pin. “What’s an internal pullup?” I hear you ask (actually I don’t, but let’s keep moving forwards).

Well, the principle of the circuit is that when I press the button it connects the input pin to the ground level, causing the input to go low. But that pre-supposes that the input pin is set high before the button is pressed. One way to do this to is to fit a fairly high value resistor (perhaps a few thousand ohms) between the input pin and the power rail. That works, but it means you have to find a resistor and solder it in place. A better way is to use an “internal pullup”. This is a switched resistor inside the microcontroller which you can turn on to pull the pin high. They are terribly useful, but only if you enable them.

pin = machine.Pin(pin_number, machine.Pin.IN, machine.Pin.PULL_UP)

You request an internal pullup by adding machine.Pin.PULL_UP to the constructor for the pin. If you do have a pullup resistor on your board (some hardware makers do this) then you should turn off the internal pullup to stop the two of them fighting…

Self Solving Wordsearch

they only have one left at this price…

I happened across some cheap 16x16 led panels. So I thought I’d make a “self-solving” wordsearch. I’ll put a custom printed front panel over the leds and then use a Raspberry Pi PICO to turn on the pixels that make up the words. You’ll be able to enter your own words and then make a completely custom search. I’m also planning a clock that works the same way. It’s going to be fun.

I’ve got this far. A little Python program in FreeCAD takes in words, builds a wordsearch and then cuts the letter shapes out of a flat panel. The letters look the wrong way round because this is the back of the panel. The pixels will shine through the letters and the words will be read from the front of the device. Next thing is to integrate the panel into my box building code and then make a box for it. Such fun.

Using the PICO2 with the Arduino Framework on PlatformIO

The title says it all really. I’m working on my Connected Little Boxes and I really want to run the code on the Raspberry Pi PICO2. Annoyingly, this is not one of those things that “just works”. But it can be done. First you need to make sure that your PlatformIO installation is up to date. Navigate to the PlatformIO tab in the Visual Studio plugins. Then select New Terminal from the options. This will open up a terminal window. Now issue the following commands:

platformio pkg update -g
platformio platform update raspberrypi
platformio run -t clean

Once this has completed we can create a PlatformIO.ini entry for the PICO2 platform:

[platformio]
; uncomment the build that you want to select
;default_envs = rpipico
;default_envs = ESP32_DOIT
;default_envs = d1_mini
default_envs = rpipico2

; other environments go here...

[env:rpipico2]
platform = raspberrypi
board = rpipico2w
framework = arduino

; Use Philhower core (RP2040/RP2350 support)
platform_packages =
  framework-arduino-pico @ https://github.com/earlephilhower/arduino-pico.git
board_build.filesystem_size = 0.5m

This fetches the libraries from the Earle Phillhower site and configures the target device. The system will only have a half a megabyte of data storage, you can increase this size if you wish. When you have built the code you can find the firmware.uf2 file in the .pio/build/rpipico2 folder. Turn on your PICO with the BOOTSEL button pressed so that it pops up a storage device and then drag this file onto device.

upload_protocol = cmsis-dap
debug_tool = cmsis-dap

If you have a Raspberry Pi Debug probe you can add the above lines to the file so that the program will be deployed to the probe. If you want to deploy to the PICO2 (not the Wi-Fi version) just change the board to rpipico2

Super Secret Storage in a PICO

I wanted to do some more work on code I wrote in Micro Python. But I couldn’t find it. Turns out that the latest version was in the PICO2 device inside the light I’d made. This can be a problem when writing code on a device. You end up with the source on the device and nowhere else. Of course you could have a rigorous code management regime that ensures that you extract and store all the code you’ve written at the end of a programming session. Yes, I guess you could do that….

Anyhoo, I managed to get my code back off the PICO2 even though I’d subsequently re-flashed the device with a C++ program. It seems that flashing a C++ program into a device doesn’t overwrite the part of the EEPROM where Micro Python stores files. And installing Micro Python doesn’t wipe the EEPROM at all. So, if you want to store super secret data you can do this:

• Write a little Micro Python that takes your secret data, does a bit of encryption and drops it into a file on the device.

• Then reflash the device with a C++ program that does something different and put it into something around the house, perhaps a light.

• Now, if you want your super-secret data back you just have to load the Micro Python program that decrypts the data and run it.

Anyone who finds your device and takes a look at the EEPROM will just see random rubbish. They’d need to have your program (and maybe a key) to get it back. You could even use public/private key encryption so that you can send data to someone else inside a gadget you’ve made for them.

This technique is not restricted to PICO (although I’ve not tested it). It should work on ESP32 too. I’m sure that there are much better ways of hiding data than this, and I personally don’t have any top secret data to store (although this is of course what any superspy would say…)

PICO-W Background Wi-Fi Connection using beginNoBlock

If you’ve ever wanted to keep your lights flickering while your PICO-W connects to Wi-Fi this post is for you. For anyone else, just enjoy the picture.

The problem I had was that the WiFi.begin method in the Raspberry Pi PICO-W Arduino framework is blocking. In other words, when I call the method to connect to Wi-Fi execution returns after the connection has been made, blocking any other calls. And my lights stop flickering. Which I don’t like.

I spent lot of time with ChatGPT trying to write an asynchronous version of the begin method for PICO. I learned a lot and I was on the point of getting something working (probably) when I noticed a little method called beginNoBlock hidden in the PICO Wi-Fi library. Turns out that this does exactly what I want. All I had to do was call this method instead of begin and it all just worked. I’ve added this to the latest release of the framework at https://github.com/connected-little-boxes/HullOS-Z

HullOS-Z now available

Some software you release. Other stuff just seems to escape… HullOS-Z has now escaped onto GitHub. It’s the next version of the Connected Little Boxes software and the Hull Pixelbot controller, rolled into one enticing bunch and dropped onto the Raspberry Pi PICO W. Other versions will be coming along soon.

It’s definitely a work in progress and the initial focus is getting something to work with Robot Rugby. It is also the first step in integrating PythonIsh (and another surprise language) with Connected Little Boxes.

You are welcome to have a play with it and let me know what you think. In fact I’d love that. The repository has a uf2 file you can drop onto a Pico W or you can build the whole thing yourself using Platform IO.

How to Post a Page Without Posting

I love a good paradox. Things like "silent alarm", "virtual reality", and the developer favourite: "posting a page without actually posting it".

Let’s say you’re building a mini web editor — a neat little HTML page with a <textarea> where people can type important things like novel chapters, shopping lists, or which biscuits they have in the cupboard.

The natural instinct is to wrap it in a <form> and let the browser do its thing when the user hits “Send”. Which works… but also reloads the page and clears the form — along with your carefully curated biscuit list.

Enter JavaScript: the Form Whisperer

What you want is a way to grab the form submission event before it fires off into the great unknown. Something like this:

document.getElementById("editorForm").addEventListener("submit", function(event) {
  event.preventDefault(); // Stop the page from reloading

  const text = document.getElementById("editor").value;

  fetch("/save", {
    method: "POST",
    headers: { "Content-Type": "text/plain" },
    body: text
  })
  .then(response => {
    if (!response.ok) throw new Error("Network error");
    return response.text();
  })
  .then(data => {
    console.log("Saved!", data);
  })
  .catch(error => {
    alert("Couldn't save your work: " + error.message);
  });
});

Binding the Save Event

That first line is the key:

document.getElementById("editorForm").addEventListener("submit", function(event) { ... });

It hooks into the form with the ID editorForm and listens for a submit event — i.e., when the user clicks the button. Then it politely stops the browser from doing its reload dance with event.preventDefault() and takes control of the situation.

Meanwhile, the text from the <textarea> with the ID editor is posted using fetch(), but the page doesn’t move an inch. It’s like sending a message by owl: invisible, efficient, and highly magical.

Minimal HTML Example

Here’s the whole thing in one slice:

<form id="editorForm">
  <textarea id="editor">Type your genius here...</textarea><br>
  <button type="submit">Send</button>
</form>

No Page Refresh. No Lost Content. No Panic.

You can even flash up a little error message if something breaks. Because nothing ruins creativity like silent failure. Well, except maybe stale biscuits.

Thanks to ChatGPT for help writing this.

"Star Power" for embedded devices

You can see the two “Stars”. They have blue heat shrink tubing on them

I’m building a large led panel. No idea why. Mainly to see if I can. Anyhoo, I’ve got six 8x8 panels that are linked to a Raspberry Pi PICO. One way to link the power signals for the panels is to “daisy chain” them, i.e. connect the power output of one panel to the power input of the next one. This makes the wiring a bit tidier, but it does mean that the power to the last panel in the chain has to make its way through five other panels before it gets there. This can cause the supply voltage to drop and the later panels end up looking dimmer. I know this for a fact because I daisy chained the panels from my PICO and the panels further away from the supply were dimmer.

So I’ve changed the wiring to “star”. A single wire from the power supply is split six ways and sent to each of the boards. There are no chains and the panels all get the same voltage. With the result that all the panels now look the same.

Pretty in pink

I think things were made a bit worse because I was using super-thin wire wrap cable which doesn’t transfer power very well. If you are finding that things don’t look the same as each other it is worth looking into the power supply side.

Big Led Panel Incoming

Perlin noise for the win!

I mentioned a while back that you could get 3 8x8 neopixel panels from Amazon for nine quid. You still can (at least until I’ve bought them all). I’ve started building a 24*8 pixel panel with them. I’ve got the box printed and wired up one panel.

Excuse my soldering

I’ve got it working and it turns out that you can get over 30fps driving all the panels flat out. This means that smooth fades are very doable. The next step is to buy six more panels and see how fast I can drive them in a 16*24 array. The plan is to use separate processor output pins to drive each panel which should make for super-smooth updates too. Such fun.

I’m doing this for an article I’m writing for Raspberry Pi Magazine. The article is about device setting storage. I thought I’d make a device which needs setting storage and it seems to have got a bit out of hand……..

PICO Musicbox

Say hello to the PICO Musicbox. It contains a Raspberry Pi PICO and uses an M5 Stack Synth module to make the sounds. There’s also an OLED display in the mix along with a rotary encoder. And of course some neopixels. You can see inside the box here. I’ve spent the last couple of days dropping out Circuit Python to make it all work together. If you fancy building one I’ll have the circuit diagram and software available soon, along with the STL files for the case.

It works

Well, that was fun.

PICO MIDI CheeseBox Version 3

I’ve spent the last day or so writing code. Which has been great fun. The focus of all the effort has been my PICO MIDI Cheesebox which has had something of a makeover. I’ve now got a PCB based version which has an OLED screen in the middle. I’ve added messaging so that you see what you are doing when you press a button. I’ve also added full setting save and restore so that you can create a pattern and store it in the device. And this afternoon I spent some time making an arpeggiator. Such fun. I’ll put it on on GitHub once it works.

Schrodinger's Pico Bluetooth Keyboard

I’m trying to get Bluetooth working on a Raspberry Pi PICO using MicroPython. I want to make a keyboard that you can pair with a computer and then use without further connection hassles. ChatGPT is being very encouraging and upbeat about the task, but I’m not sure whether it is possible or not. I think I’ll only know that it can be done once I’ve got it working….

Update: I’m pretty sure this is impossible. The aioble library for MicroPython doesn’t support bonding and, although ChatGPT came up with all kinds of fictional ways of making this work, none of them are any good in the real world. Oh well. You learn as much from your failures as you do your successes……

Return of the PICO MIDI CheeseBox

this passes for a tidy desktop in my house

I invented the PICO Midi Cheesebox a while back. It was great fun to make. It performs as a mini-sequencer keyboard, powered by a PICO and using a 12 pixel ring and 12 buttons to control it. A Python program inside gives you a three track sequencer with keyboard input.

The cheesebox is designed to be used as a MIDI input device, it doesn’t have any sound generation built-in. It works really well with my Chocolate Synthbox which contains a Raspberry Pi running a Pure Data synthesizer program.

Then, just before Christmas, Brian put me onto a new device from M5Stack. The Unit Synth contains an SAM2695 audio synthesizer and responds to General Midi commands to make sounds via a tiny built in speaker. I got one to play with and one as a present for number one son. It works really well, although the speaker is a bit weedy.

I did some more digging and discovered the Unit MIDI which contains the same synthesizer chip, replaces the speaker with a 3.5mm stereo jack socket and adds a couple of proper MIDI connections. So I got one of those as well. the aim now is to make a super-cheesebox which contains a Unit MIDI and some proper speakers. I’ve got the cheesebox controlling the synth, next thing to do is package it and then tidy up the software a bit.

The OLED screen doesn’t work at the moment.

I’m going to be using one of the CheeseBox PCBs I had made a while back, fitted into a newly designed case. This means more surface mounting shenanigans. Such fun.

Agile Octopus Display Updates

When the price is negative it means you are being paid to use electricity

New Year, new you. Newly broken Agile Octopus Display. We’ve been on the Octopus Agile Tariff for a while now. The price of our electricity changes every half hour. If we plan our power use a bit we can save money. Every now and then, when the weather is warm and windy, we can even get paid for using electricity, as you can see above. We’re not saving a huge amount of money (although sometimes we get to drive the car for free) but we are having fun.

To make managing our power use a bit easier I made a little display that lives in the kitchen. It gives you the current price and future price trend for the day. It’s been working fine for ages but in the new year it broke. I assumed it was something in my code (it usually is) but this time the fault is down to Octopus re-arranging their tariffs and changing the web address of the service that dishes out the price values.

I’ve made a new version of the tariff display code which uses the updated links. I’ve also taken the opportunity to tidy a few things up. You can find out more about it here.

Connected Little Boxes RFID sensor

The drinks manager device that we used for the Hull CS50 celebrations is mutating into an article for MagPi magazine. Today I got the finished device wired up and working. I’m adding an RFID sensor to the Connected Little Boxes framework so that you can create a device that will respond to different cards. It’s great fun.

LittleFS filename conventions

LittleFS is a great way to store files on your PICO or ESP powered embedded system. But it does have its foibles. Particularly when you switch from one platform to another. One thing that can trip you up is that on the ESP8266 and the PICO LittleFS the name method provided by a file object delivers the name of the file in the folder(test) but on the ESP32 LittleFS it delivers the file path to the file (\start\test).

I just discovered this while migrating the Connected Little Box code to the PICO. I’m putting this here so that I can find it again when I hit the same problem in a couple of years time.

PICO Probe in PlatformIO

I probably shouldn’t be quite so surprised when something just works, but I must admit to being slightly shocked when I managed to deploy a C++ application into a PICO using the Raspberry Pi debug probe the first time I tried.

Debugging just works too. I’ve now got a new PC (replacing my 8 year old one with something a bit more sprightly) and the build and deploy cycle is now pleasingly short. This really is a great way to work. I’ve now got the Connected Little Boxes core running on a PICO as well as ESP32 and ESP8266 and I’ve re-factored the code so that it is now easy to manage the feature set assembled into the code. This makes it much easier to remove features that won’t fit on the ESP8266. Great fun.