Although last week we had some server admin certificate-wrangling, we dodged the PHPocalypse that caught many others this week. That’s mostly because the online platform for Museum in a Box is Python-based, and this site is static-files, so there’s less to be compromised. The Museum in a Box website is Wordpress, but we pay someone else to keep on top of that; I (Adrian here this week) checked up on it to confirm that they were on top of things, and as expected that was the case.

As with many connected devices, the Museum in a Box creates its own WiFi network so you can connect to it and tell it the details for the WiFi it should use to get online. It used to be that you’d connect your phone to the Box’s WiFi network and get a popup saying you needed to provide more information; and when you clicked that it would take you to the page to enter the details. More recent versions of Android (and quite possibly iOS) have changed this flow, making it much trickier to get your Box set up.

I’ve been digging into what’s going on to try to improve it. There are a handful of RFCs (the standards documents that define how lots of the Internet works under the hood) documenting some changes, so I’ve been poring over those. And some of those changes are available as options for the underlying operating system the Box uses.

However, enabling those options doesn’t seem to help; and from my reading of the standards, they seem tailored more towards your local café wanting you to agree to terms and conditions rather than configuring an IoT device. For example, you can provide the URL for the website to redirect to, but it has to be an HTTPS URL. For a device that’s not yet connected to the Internet, keeping a certificate valid and up-to-date for such security isn’t really an option.

So I think my next step is to watch what network traffic happens when a phone connects to the Box’s WiFi. On my laptop that’s quite easy, I’ve been using Wireshark for that sort of task since the 1990s; but I can’t run that on the Museum in a Box. However, there are some options for capturing the data to then inspect on Wireshark afterwards, so I’ve been exploring those.

In not-Museum in a Box news, I’ve been poking a bit at Auracast. It’s a fairly recent development in the Bluetooth world, which allows a device to do broadcast audio (rather than the current one-to-one audio options).

We’ve been tracking it for a while and have even done some initial investigations into what it would take to get it running on the ESP32C3 chips we use on My Bike’s Got LED. It would be a great addition to the options on those for sound-reactive lights.

It would also be a way to let us have even more bikes-with-soundsystems on our social group bike rides.

The off-the-shelf options are starting to show up in the shops now, but I think the bike group use case is different enough that I could do with something tailored to it. An external antenna for longer range would be handy, but the key thing I’ve not seen elsewhere is a visual indicator of signal strength on the receiver.

The best location for the transmitter would be in the centre of the pack of bikes, and that would mean that any bikes-with-speakers in front of that wouldn’t be able to easily modulate their speed to stay within range. For the point-to-point solution we currently use, I built an LED heart indicator to sit on top of the transmitter pole, and that’s enough for the chasing receiver to keep tabs on and make sure they don’t fall too far behind.

So I think a board that has some indicators of the signal would give the rider with the transmitter a way to keep an eye on things and prevent the front speakers from losing sound.

It’s early days, but I’ve got an nRF52 dev board broadcasting audio, and both an nRF53 dev board and a micro:bit v2 (which has an nRF52 chip as its processor) receiving it. Neither are playing it out of any speakers yet, so adding an I2S DAC headphone socket is the next step.

Chris has been helping with the last of the support for the new Living Knowledge Network rollout and posting out the next batch of boxes to new new customers. When he’s not been supporting customers he has been continuing to look at the web server code for Museum in a Box. Getting back to the discipline of writing weeknotes has made him focus on picking a more interesting issue to run at for next week.