Adrian here again this week, as Arthur is having the week off.

We started the week with another day working on the WWII teleprinter. We've got a handle now on most of how the mechanicals work, and the key parts have been stripped down, cleaned and reassembled.

With progress being made on that side, we've started looking at the electricals too. That had seemed an area where we'd need more care, given that the signalling is done at +/-80V and the motor wants a not-very-common-these-days (I have no idea if it was more common in the 1940s but...) 110V DC.

One of the benefits of being part of the DoES Liverpool community is the wealth of expertise and more specialised tools that can be brought to bear on a problem. That's provided a number of possiblie approaches to powering the motor, and that's something we'll have to bite the bullet on soon enough.

In the meantime, as we've learnt more about the operation of the machine, we've also worked out that we likely don't need to find 80V for the signalling. The 80V from the spec is to allow for a sizeable voltage drop across the long runs of cable when your teleprinters are miles apart. We won't be running them over such long distances, and are aiming to build some sort of local interface that will bridge the connections to a computer or, via a computer/microcontroller, to the Internet. That will let us run much more sensible voltages—possibly as low as 6V, but more likely something like 12V or 24V.

There's a new episode in our video diary showing what we got up to...

The new pen-plotter project started to pick up speed. After a call with the client to discuss what I'd found in my intitial investigations, we've decided on the direction for the rest of the work and can now crack on with it. I've looked at available CNC machines and ordered one, together with a pen attachment (which will, hopefully, save me having to design one).

Next up is working on the software to drive it—the previous generation used an Electron app, but a change in libraries that we're using; the amount the Electron ecosystem has moved on in the intervening years; and a browser being somewhat overkill for the UI required means I'm considering a swtich. Now looking at Python options (as that's the language used by the new library choice). It needs to run on Windows (with Linux a bonus for easier development); suggestions welcome!

On the My Baby's Got LED front, I've been working on a jig to make programming and testing the boards easier. Automating that process will make board production quicker (or at least less labour-intensive) and more reproducible.

So far it's an Ansible script to build the software subsystems on a Raspberry Pi which will do the probramming, and I can build the software ready to upload. That will get some basic circuitry to interface with the board (via some pogo-pins), allowing the Pi to power it on, "press" the reset button, etc. and then we'll use OpenFixture to build the physical jig to hold the board in place. The first milestone will be when it can program the boards, and then we'll add more automated testing as required.

Finally, not much of the ongoing two-days-a-week contract at Aeternum makes it into the weeknotes, but the air quality sensor work there continues ticking onwards.

One of the background tasks there is thinking about how we can use the illuminated LED logo (powered by a My Baby's Got LED board, naturally) on the office wall as an information radiator to give a low-level awareness of the data being gathered by our sensors.

We can easily bring up much more detailed graphs of what's going on, but having a visualisation that's "part of the furniture" gives an ambient awareness of what's going on that you don't get from reports or looking at graphs; the real-time nature of the display pairs well with our brains' predisposition for pattern-matching to spot when things "don't look right". Then we can investigate further, or make a note of local conditions: weather, events, what-have-you, to help us better understand what affects the air quality.

Initially the logo was showing the PM1, PM2.5 and PM10 for one of our sensors, with the value mapped onto a colour from green through yellow to red. We've switched recently to just PM2.5—as they mostly all go up and down together—which let us show results from a cluster of four sensors and get a feel for how things vary across the city.

It uses the development version of our API to source its data, so on occasion the API is down for one or two of the sensors. That wasn't making it through to the display, which meant at times we'd think the air quality was good, or bad, and actually it was stale information. I've now extended the logic to spot the API failures, and use the blue channel of colours to make that visible. The longer the API is down, the brighter the blue gets and then the animated aspect gets faster. Hopefully that will make us aware of any problems and have the display become more insistent the longer the issue persists.

It's good to have a concrete example of using the capabilities of the My Baby's Got LED board to let me try out approaches to see what works.