JohnVidler.co.uk

Text-Only Copyable Shopping Baskets

2025-11-26T00:00:00Z

I’ve been ordering a large number of things from ThePiHut lately, and the university procurement system needs quite a few details of each order line so they can actually make the purchase.

Unfortunately, ThePiHut’s website does not include an ‘export basket’ or other equivalent mechanism that I can use to send all these details to our procurement folks… so in the usual fasion of a developer faced with a code-based problem, I wrote a code-based solution.

I wrote a GreaseMonkey / TamperMonkey script that only runs on the basket page of ThePiHut, and pulls all the details of each item in your basket, dropping them all into a single text box with all the information a procurement department could want.

This simple script I’ve posted on Github as a Gist, which both systems can use as an install and update source (although I do consider this ‘complete’ so probably won’t change it much now). Or you can copy the frozen copy of this gist from the code box below this post.

Hopefully this won’t be needed forever as the folks at ThePiHut could easily add identical functionality into the website itself, but for now, it saves me a ton of time, and it might save you some too.

// ==UserScript==
// @name         ThePiHut Text Basket
// @namespace    https://johnvidler.co.uk/
// @website      https://johnvidler.co.uk/
// @source       https://gist.github.com/JohnVidler/e57b0009391e8582ae5cf2431372d85a
// @version      2025-11-26
// @description  Creates a simple copy/pasteable shopping cart to send to procurement departments for ThePiHut.com
// @author       John Vidler
// @match        https://thepihut.com/cart
// @icon         https://www.google.com/s2/favicons?sz=64&domain=thepihut.com
// @grant        none
// @require      https://code.jquery.com/jquery-3.7.1.min.js
// ==/UserScript==

// USAGE: Install Tampermonkey or Greasemonkey into your browser, create a new script and drop this file's contents into it. That's it!
//        When you next visit the basket page on ThePiHut you'll have an extra box under the cart total with a text-only copy of the current cart.

(function () {
    'use strict';

    let _copyableBOM = "";

    function copyToClipboard(){
        navigator.clipboard.writeText(_copyableBOM);
        alert( "Copied basket to clipboard" );
    }

    function addButton(text, onclick, cssObj) {
        cssObj = cssObj || {position: 'absolute', bottom: '7%', left:'4%', 'z-index': 3}
        let button = document.createElement('button'), btnStyle = button.style
        document.body.appendChild(button)
        button.innerHTML = text
        button.onclick = onclick
        Object.keys(cssObj).forEach(key => btnStyle[key] = cssObj[key])
        return button
    }

    function buildBOM(){
        const $ = window.jQuery;
        console.log("jQuery version:", $.fn.jquery);

        const lines = $('.line-item');

        const parts = [];
        let total = 0;
        for( var i=0; i<lines.length; i++ ) {
            const line = lines.get(i);
            const fPrice = parseFloat($(line).find('span.price--convertible').attr('data-base-amount'));
            parts.push({
                vendor: $(line).find('a.line-item-meta__vendor').text(),
                title: $(line).find('a.line-item-meta__title').text(),
                quantity: $(line).find('input.quantity-selector__input').val(),
                link: "https://thepihut.com" + $(line).find('a.line-item-meta__title').attr("href"),
                price: fPrice
            });

            total += fPrice;
        }

        let formattedOutput = parts.map( v => [
            `(${v.quantity}x) ${v.title}`,
            `\t - ${v.link}`,
            `\t - Vendor: ${v.vendor}`,
            `\t - £${v.price.toFixed(2)} Total (£${(v.price/v.quantity).toFixed(2)} each)`,
        ].join('\n') ).join("\n\n");

        formattedOutput += `\n\nTotal without shipping: £${total.toFixed(2)}\n`

        _copyableBOM = formattedOutput;

        const newHTML = [
            `<div class="cart-upsells" style='margin-top: 3rem;'>`,
            `<div class="o-container">`,
            `<h3 style='text-align:center;'><strong>Text-Only Basket</strong></h3>`,
            "<p>Copy &amp; Paste this to send to your procurement department, notes document, or anywhere else you might need a text-only copy of this basket.</p>",
            `<p><textarea style='width:100%; height:20rem; resize:none;' wrap=false>${formattedOutput}</textarea></p>`,
            "<p style='text-align: center; color: gray;'>A tiny utility by <a href='https://johnvidler.co.uk/' target='_blank'>John Vidler</a>. No association with ThePiHut implied</p>",
            `</div>`,
            `</div>`
        ];

        //$('div.cart__content').append( newHTML.join('') );
        $('safe-sticky.cart__aside-inner').append( newHTML.join('') );
    }

    // Delay slightly to allow for any lazy loading and/or net delays
    setTimeout( () => buildBOM(), 100 );
})();

KiCAD Footprints with Multiple Parts for PCBA

2025-10-10T00:00:00Z

The original symbol as defined in the official mikroBUS library

The process begins with an original component that consists of two physically independent connectors housed in a single package. This is a common scenario with certain types of board-to-board connectors or specialized interface headers where manufacturing constraints require separate physical components, but the electrical design treats them as a unified part.

To start the modification process, open the symbol in KiCAD’s symbol editor. Create two duplicate copies of this original symbol - one designated as the ‘left’ variant and another as the ‘right’ variant. The terms ‘left’ and ‘right’ here should be adjusted to match the actual geometry of your specific part, or whatever logical separation makes sense for your design. The key is establishing a clear distinction between the two physical components.

The new left-hand symbol

The new right-hand symbol

Once you have your duplicated symbols, begin editing the left variant by carefully deleting all the connector pins that correspond to the right physical connector. This is where attention to detail becomes critical: you must preserve the original pin numbers during this deletion process. The pin numbering must remain consistent with the original part datasheet, as this maintains the electrical connections when you eventually place both parts on your PCB. Repeat this process in reverse for the right symbol variant, removing all the left connector pins while again preserving the pin numbers.

With the symbols prepared, transition to KiCAD’s footprint editor and locate the corresponding footprint for your part. In my case, I started with a standard through-hole variant, but found it necessary to create a custom surface-mount variant using offset pin headers to meet the assembly requirements. The specific mounting style you choose will depend on your manufacturing process and board design constraints.

The original library-supplied footprint

My modified SMT footprint

The next crucial step involves establishing a clear division line on the footprint. Draw a ‘cut’ line that defines where the part will be split - I recommend using the F.fab layer for this purpose, as it’s intended for fabrication documentation. Critically, ensure this cut line is aligned to the editor grid, as this alignment will make reassembly in the PCB layout much cleaner and prevent any potential alignment issues during placement.

Following the same pattern used with the symbols, duplicate the footprint twice to create left and right variants corresponding to each physical component. On the left footprint, methodically remove all elements on the right side of your cut line - this includes pads, mounting holes, silkscreen markings, and any other footprint features. Then perform the inverse operation on the right footprint, removing all left-side elements. The result should be two footprints that, when placed together, perfectly reconstruct the original part geometry.

The two halves of the footprint, note that both have a common centerline aligned to the grid.

Return to your PCB layout editor where the payoff becomes apparent. Place both the left and right footprint variants on your board, carefully aligning them along the cut line you established earlier. When properly aligned, they should seamlessly rebuild the complete part as if it were never split. This alignment is why the grid-snapping during the cut line creation was so important.

The final configuration in the board render from KiCAD

The final benefit of this approach shows in your Bill of Materials. Instead of a single entry for the composite part, you now have two BOM entries. This separation allows you to specify two distinct physical parts for placement, which is exactly what PCBA (Printed Circuit Board Assembly) services require. This resolves the fundamental 1:1 part mapping issue where assembly systems expect each footprint to correspond to exactly one physical component, avoiding the confusion and potential errors that arise when a single BOM entry needs to map to multiple placement locations.

The generated BOM (in the JLCPCB plugin) showing two PCBA parts

3D Printable Accessibility Switches

2024-05-30T00:00:00Z

Two basic paddle switches fully assembled. My 3d printer needs some attention, so some of the detail is lost, but they function just fine.

Based around a low-profile keyboard keyswitch this was pretty much the simplest, lowest-profile paddle I could construct in time for the conference, so they’re a bit rough around the edges (especially on the lettering, and stringing on the curved surfaces) as I had little time to fine tune the design or deal with recalibrating my slightly aging 3D printer.
The filament I used was also ‘whatever was loaded into the printer’, so you get what you get. I fully suspect a better 3D printer, or better filament, or just using a 3D printing service would yield far better results.

Assembly Details

Step 0 - Parts and Soldering

Print the parts as many times as you need for however many switches you require.

The wiring is trivial, but may require some trial-and-error if your equipment differs from mine. In my case the tip and sleeve of the 3.5mm jack are the critical pins, and bridging them with the switch is what I need, but if you have other connections, I suggest getting ahold of the TRRS sockets, connecting them up in isolation then bridging pairs of contacts until you find the pair that work for you. In my case, the pins I needed were pins 2 and 4.

When soldering the switch and jack, keep in mind that you may not want much slack in the wires between the two, as this may interfere with the switch operation. To ensure I had the correct length, I used the base of the switch as both a template and a holder while soldering.

The soldered keyboard switch, and both halves of the paddle switch. The holes in the base are for hard-mounting to other equipment with screws.

Step 1 - Attaching the TRRS Socket

Unscrew the nut on the TRRS socket almost all the way off, then snap the socket into the back of the paddle base. The ring on the socket should fit neatly into the slot and hold it with a satisfying click.

Optionally screw the nut back down onto the socket to secure it, although in my testing no nut is actually needed, but I kept mine on for the aesthetics.

Snapping the TRRS socket into the 3D printed base. It really is very satisfying how well this works!

Step 2 - Attaching the Keyboard Switch

Slot the keyboard switch into the square mounting; it should fit just so such that the bottom half of the switch neatly slides into the mounting, but the upper section is held at the correct height.

When you do this, ensure that the two wires from the switch are routed around to the cutout without pinching them. They should fit neatly under the body of the switch.

Mounting the switch. In theory this should work for deeper 'Cherry' style keyboard switches as well, but the cases may be too deep to fit in the current mounting, or the switch stem may be too long to neatly close. The low-profiles ones give a nice flat profile.

Step 3 - Attaching the Paddle

Take a length of printer filament (1.75mm diameter) and slide it into one of the holes in the hinges, then line the lid up with the protruding filament and push it all the way through the far hinge mounting.

Feeding the hinge filament through. This can be a little fiddly depending on the dimensional accuracy of your printer.

If you encounter resistance, try spinning the filament around to align better - I found that letting the natural curve of the filament go upwards was the best way, as it tended to guide through the center open section of the hinge.

The attached paddle with some spare filament.

Step 5 - Trim and Use!

Cut off any excess filament with some edge-cutters, optionally adding a dot of glue to one or both ends of the hinge to secure it, although I personally found that the curve of the filament and the minimal actual rotation when using the paddle meant that this was not required.

A completed paddle switch, ready for use!

The Access:bit - An Accessibility Addon for the Micro:bit

2024-05-27T00:00:00Z

For the past two years I have worked with the Micro:bit Educational Foundation and in that time I’ve developed several hardware prototypes to support our research at Lancaster University and towards the end of my tenure The Foundation comissioned a report on accessibility which included a speculative section on how to improve accessibility to the Micro:bit platform for folks with limited or different mobility.

The Accessibility Survey

Part of the internal report on Micro:bit hardware accessibility within The Foundation (reproduced with permission, May 2024)

One of the key points that was highlighted was that for educators in a special needs situation the additional workload involved with making the devices and software accessible was layered on top of the already high workload in incorporating the Micro:bit into the classroom for non-domain experts (non-CS specific teachers). While training and resources are readily available for the Micro:bit, quite how far we put teachers outside their comfort zone should not be underestimated as a barrier to using the platform.

Part of the internal report on Micro:bit hardware accessibility within The Foundation (reproduced with permission, May 2024)

To help with this, one of the suggestions from the report was to develop an addon for the Micro:bit that supported plugging directly into adaptive inputs (such as those used here for the XBox platform). These adaptive controls have settled on a de-facto standard based around 3.5mm audio jacks, of the sort commonly seen for ‘aux’ inputs in cars. These were picked for their general ubiquity and simple connection and disconnection action, as well as how robust they are.

The Initial Design

With this in mind, I set out to implement the ‘minimum viable board’ to achieve this with the specific goals in mind:

Expose the A and B buttons to adaptive switches
Expose the P0, P1, and P2 pins for input or output via adaptive interfaces
No code changes should be required for this to work
Manufacturing costs should be minimised

A super quick initial pass at reproducing the accessibility report sketches as a real PCB design. I really liked the little indents for each jack on this design, even if they were a pain to produce.

The above render is my first pass at achieving these goals; I simply connected each edge connector pin to the tip terminal on the jacks, connected the sleeve terminal to ground and labelled all the ports. This followed the design sketches from the report pretty closely, with the addition of indents around each jack socket to acommodate as many (potentially strangely shaped) jacks as possible.

This I sent for review to Jonny at The Foundation as a proof of concept, and while he liked it, he and I both felt that this was maybe too minimal, and that including some additional functionalty onto the board would be welcome.

I’ve previously implemented the power and signal conditioning circuits to support Jacdac on the Micro:bit for the Jac:stack, and my collegue Matt Oppenheim has previously designed hardware to interface with other accessibility devices, so it made a lot of sense to include this on the board as well.

It also occurred to me that should the Micro:bit prove to be particularly useful to someone using it with this board, they may want to hard-mount it somehow for semi-permanent installtion, so having some mounting holes would be useful too.

Jacdac you say? Well funny you should mention that...

One fairly quick re-spin of the original board, borrowing much of the circuitry from the Jac:stack resulted in the above, with two cable-type ports for Jacdac, and a redesigned silkscreen for the port labels (although I never did like the off-side labels of this design).

Meanwhile…

Meanwhile, Jonny had an idea and sent me this concept drawing, which I will forever mentally refer to as ‘the grin’ design:

From a short design review with Jonny at The Foundation, he suggested what I forever see as a big toothy grin variation of the board layout.

But tooth-related mental images aside, having a curved input edge makes a lot of sense, as the spread of connectors are far less likely to interfere with one another in this configuration, and the board shape gains a reasonable amount of surface area without expanding the overall board dimensions too much.

V3 - Curved Component Placement

I re-spun the board design again, this time with some angled inputs along a long curve:

Arcs in KiCAD are a bit... fun... to produce sometimes, but I managed an unrouted iteration to see how the layout would feel.

This version 3.0 design came close to being the final one; and I spent a little while getting some polish done on the silkscreen and layout, as well as adding a few ‘nice to have’ features that didn’t add too much to the overall complexity and cost.

An LED was added for each port, in-line with the jack
The port labels were moved to be in-line with the jacks and replicated on the back of the board for additional visibility
A silkscreen pictogram showing the connections required for the switches was added, to make the input self-documenting
The addition of the Lancaster University and Micro:bit Foundation logos

I even added the placeholder serial number location for my PCB fab house of choice JLCPCB so short of actually building the manufacturing files this board was now ‘complete’!

The v3 with activity LEDs on each pin, and a revised silkscreen

The rear of the v3, complete with a bit of self-documentation in the form of the silkscreen 3.5mm jack showing the connected pins.

Fabrication With No Budget

As this was just a side project I had no budget to actually have the boards fabricated, so I turned to another collegue, Prof. Steve Hodges who graciously provided the funds, and also helped with a final design review. He noted that I had not included any TVS diodes on the inputs, as I had so far been relying on the Micro:bit’s designed-in protection for its edge connector; but as the parts to add would only be extremely low cost, I patched these in, along with the new Devices Lab logo, and called it v4 - ready to fab!

The 'final' v4 revision after a design review with Steve Hodges, with the inclusion of some additional TVS diodes on the GPIO pins just in case.

The read of the v4; now with a devices-lab.org copper logo and the microbit.org accessibility pages URL

Three days plus expedited shipping later, I had one in my hands - a real board nearly complete! I elected to not include the large 40-pin Micro:bit connector, as JLCPCB don’t normally stock these, and it would have involved additional delays in them buying in the parts. Plus honestly with the aid of a cheap hot plate its very easy to get these soldered on by hand even without a solder stencil; a quick smear of low-temperature solder paste along the terminals and you can just drop the part onto the hot plate and 20 seconds later, you have a perfectly soldered connector. The only other remaining step was then to hand solder on the two connector mounting lugs on the back, the work again of only a few seconds.

The real thing, in glorious green FR4. I elected to not get JLCPCB to populate the large 40-pin microbit connector, as I would have to pay for them to stock this for me, and I do have a perfectly servicable hot plate setup...

One quick application of some low-temperature solder paste and about 20 seconds on the hot place and we're pretty much done. I just need to hand solder the rear support lugs as well for extra stability. I don't do this on the plate, as it would put solder in direct contact with the hot plate surface.

Ready To Ship!

I tested each port using my own 3D Printable Paddle Switch designs with all working perfectly (phew!)

At the time I only had one 3.5mm cable to hand (where the heck to these things hide?!?) but every port worked!

So after some quick 3D printing, soldering and packing up they are now winging their way down to Cambridge just in time to go along to the Blockly Summit '24, where if you go along in person, you can try these out at the Micro:bit table.

Ready to go! Just in time for the Blockly Summit '24

Docker 102

2023-12-04T00:00:00Z

Part of a (short) series on 'knowing enough to be dangerous' with Docker.

John discusses various aspects of Docker in this video, including networking within containers, Docker Compose, troubleshooting Docker Compose, passing environment variables, running containers using Docker Compose, mounting volumes, and security issues. They provide explanations, examples, and demonstrations to help viewers understand and apply these concepts. John also emphasizes the benefits of using Docker, such as simplifying the process of running multiple containers together and reducing administration overhead. They conclude by offering to answer any questions from the audience.

00:00:00 In this section, John discusses the basic concepts of Docker and gives an overview of containerization and images. They also touch on networking within containers, including different ways to configure networking and the concept of isolation. John mentions that there are ways to poke holes in containers, particularly through networking and storage devices. They then dive deeper into networking concepts, including options such as none, host mode, bridge mode, and overlay mode. The focus is primarily on bridge mode, which is used for a single host.

00:05:00 In this section, John explains the differences between bridge mode and overlay mode in Docker networking. Bridge mode is the default mode, where containers have a connection to the host and can connect to the outside world through Network Address Translation (NAT). However, by default, connections cannot be initiated from the outside world to the container. To allow incoming connections, port forwarding can be used. Overlay mode, on the other hand, is used in container orchestrators like Swarm, where containers running on different hosts can communicate with each other as if they were in bridge mode. This mode is commonly used in web applications where multiple containers need to serve web pages or web sockets. To handle multiple containers on the same port, a reverse proxy like Nginx is used to translate incoming connections to the appropriate container. This pattern is becoming more common in small setups, replacing the need for separate VMs for each website. However, when using port forwarding, it is important to be cautious as it opens the container to all connections.

00:10:00 In this section, John discusses Docker compose, which is a tool used to describe the arrangement of containers and pass along configurations in a repeatable way. Docker compose is based on yaml files and John provides an example of a Docker compose file. The file includes a version at the top level and a Services block, which lists the containers to be run. John explains the different configurations for a container, such as the image, restart policy, and environment variables. Overall, Docker compose simplifies the process of running multiple containers together.

00:15:00 In this section, John explains how to set up another instance using Docker Compose for PHP my admin. They specify the container name, image, and restart setting. To allow external interface, they open the port and set an environment variable. They also add a “depends on” stanza to ensure that PHP my admin only starts if there is a database to connect to. John demonstrates how to run the Docker Compose command and explains that the PHP my admin container has a complex image with various web configurations. The process involves downloading and eventually completing the setup.

00:20:00 In this section, John and the audience members are troubleshooting issues with Docker Compose while trying to run a demo. They discuss possible solutions, such as checking file names and ensuring that Docker Compose is installed properly. The demo seems to be broken due to a typo in the Docker Compose file, causing the container to not start. Eventually, they discover that the root password needs to be modified for the MySQL container. Despite the challenges, they hope that the adjustments made will resolve the issues and allow for a successful demo.

00:25:00 In this section of the video, John discusses the progress of running the Docker containers and encountering some errors along the way. They mention the need to make some changes, such as adding quotes and being mindful of system updates and changes. Eventually, they are able to get the containers running successfully. They also explain how to check the running containers using the Docker PS command and note the mapping of ports. John then mentions the use of environment variables to pass parameters into the containers and explains the syntax and persistence of these variables. Finally, they highlight the need for a more streamlined and secure setup, suggesting the use of additional configuration options.

00:30:00 In this section, the video discusses how to pass environment variables to Docker containers using Docker Compose. By using the dollar bracket syntax in the YAML file, users can replace values with environment variables. This allows for flexibility and customization when running containers. In addition, the video explains how to set default values and error messages for environment variables. The example given shows how to replace a MySQL root password with an environment variable, ensuring that sensitive information is not exposed. The video also mentions the importance of securing containers by specifying the interface to listen to. Lastly, the video demonstrates how to specify environment variables for accessing PHPMyAdmin. Overall, this section provides useful information on how to manage environment variables in Docker Compose.

00:35:00 In this section of the video, John discusses how to run Docker compose commands to start containers and set passwords. They explain that running the containers in the background can be done by adding a “-d” flag to the command. They also mention the importance of binding the containers to only the host machine to prevent unauthorized access to the database. John then introduces the concept of mounting volumes to store data outside of the containers, specifically mentioning the ability to connect to remote stores like AWS. They explain that volumes can be set to read-only or read-write modes and provide an example of how to add a volume to the Docker compose file. Overall, this section focuses on the practical aspects of running and managing containers in Docker.

00:40:00 In this section, John discusses the different ways to mount volumes in Docker. They mention that bind mounts are the most common for development purposes since they allow connecting to files on the host machine. However, for orchestrated larger networks with multiple hosts, it is important to consult the hosts to see how they want volumes to be mounted. John also introduces the concept of Docker volumes, which are managed by Docker itself and can be shared between containers. They briefly touch on the benefits of using volumes and mention that they can be explored further at a later time. Finally, John provides instructions on how to set up a folder for data using Docker Compose and verifies that the data persists even after stopping and starting the containers. They encourage further exploration of Docker images on Docker Hub and recommend looking at the Docker Compose reference for more in-depth guidance.

00:45:00 In this section, John discusses security issues with outdated virtual machines (VMs) and the need for container templates for common configurations. They mention the goal of having a ready-made website integrated with gitlab, allowing users to easily copy a repository and have it built and deployed seamlessly. This approach is intended to reduce the administration overhead associated with VMs. John concludes by expressing gratitude for the audience’s attention and offering to answer any questions.

Summary text originally from summarize.tech with light post editing.

Docker 101

2023-12-03T00:00:00Z

Part of a (short) series on 'knowing enough to be dangerous' with Docker.

In this YouTube video titled “Docker 101,” John provides an introduction to Docker and its importance in simplifying the deployment process. They explain the concept of Docker containers, which are loosely isolated environments that contain all the necessary requirements for an application to run. John demonstrates how to build and run containers using Docker, using Python as an example. They also discuss the use of Docker Hub, a repository for Docker images, and explain the concept of Dockerfiles, which are recipes for creating Docker images. John then covers topics like exposing ports, running multiple containers using Docker Compose, and the option of uploading images to Docker Hub for sharing.

00:00:00 In this section, John is introducing himself and explaining the requirements for following along with the presentation. He also provides an overview of the topics that will be covered, including why Docker is important, example workflows, and the basics of Docker containers. John emphasizes the ability of Docker to isolate applications and simplify the deployment process. He also mentions that he will be discussing building custom Docker images and Dockerfile basics in later parts of the presentation. The section concludes with John sharing examples of traditional workflows and explaining how Docker can simplify the process by isolating dependencies.

00:05:00 In this section, John discusses the challenges of software distribution and the concept of dependency hell, where different libraries and systems have varying dependencies, leading to a nightmarish experience. John mentions workarounds like using virtual machines or packaging applications with their libraries. However, Docker provides a simpler solution by removing the need for host configuration and runtime requirements, without requiring a heavyweight virtual machine. Docker creates a Loosely isolated environment called a container, which contains all the necessary requirements for an application to run, making software distribution much easier and efficient.

00:10:00 In this section, the concept of containers is introduced. Containers are described as loosely isolated environments that are similar to virtual machines but much lighter. While virtual machines isolate every aspect of the hardware they are running on, containers only care about the necessary functionalities like network connections. Containers aim to keep instances isolated from the host environment to avoid interference. They are based on read-only templates called images, which serve as the initial state of a container. Images are built on top of one another, with the top layer usually representing the application. It is recommended to keep the stack of layers as short as possible to maintain a lightweight image. The difference between traditional virtual machines and containerized architectures is also explained, highlighting the shorter stack and minimal extras in containers. The goal is always to make containers thinner, with only the necessary components included.

00:15:00 In this section, John introduces the “play along at home” portion of the tutorial where they will demonstrate building web-based containers using Python. They mention that Python knowledge is not required as the necessary files have already been provided. John also suggests using other languages such as Perl or PHP if preferred. They explain that they will be building a container in Alpine Linux and highlight its small size, making it ideal for demos. John demonstrates running Alpine Linux in Docker and explains that they are operating as root since there are no users included in the image. They also mention that the Alpine Linux image is approximately 7MB in size. John asks for confirmation from the audience if they have successfully set up Docker and invites questions or comments. They explain the concept of the unique hash associated with each layer and that Docker builds containers by stacking these layers in order. They clarify that an internet connection is required to download the necessary Docker images.

00:20:00 In this section, John discusses the need to eliminate unnecessary Docker images in order to avoid storage issues. They explain how Docker maintains a cache of images, which can accumulate over time if not deleted. John also provides a demonstration of how to clean up Docker images. Additionally, John explains that Alpine Linux, which is used in Docker, is a minimal operating system that runs very few processes and requires less memory compared to other operating systems like Ubuntu. John also mentions the ability to configure Docker to utilize specific resources, such as a limited number of cores. Lastly, there is a brief discussion about running Docker on Windows and the recommendation to use CMD for Windows users.

00:25:00 In this section, John explains how to check if you are inside the Alpine Linux container and how to access your running containers. They mention that if you see the slash hash prompt, then you are inside Alpine. They also explain that the Docker PS command is equivalent to the PS command for Linux and it displays the running containers. John demonstrates how to exit the container and return to the host. They also mention that ending the container’s operation does not remove it, and you can use Docker PS -a to see both running and non-running containers. Finally, they discuss how to remove containers and images, and suggest using Docker system prune to clean up.

00:30:00 In this section of the video, John demonstrates how to manually remove a Docker container by using the Docker RM command followed by either the container ID or name. It is important to note that this command only removes the running instance of the container, not the container image itself. John also mentions the use of the Docker prune command to remove multiple containers at once. They advise using the “–RM” flag when running a container if it is meant to be temporary and should be deleted once it is stopped. John recommends being cautious when using the RM flag and suggests not relying on it for important tasks. They then move on to discussing how to run Python in a Docker container using different image variants and tags.

00:35:00 In this section of the video, John introduces Docker Hub, a repository for Docker images. They explain that by visiting hub.docca.com and navigating to the Python section, users can find various Python versions available for use. John notes that there are simple tags and variations of Python available, including different versions for different operating systems like Debian and Ubuntu. They mention that these images on Docker Hub are safe to use, as they are official Docker images. John also discusses the concept of Dockerfiles, which are recipes for creating Docker images. They explain that Dockerfiles contain a series of steps that configure the final image. John goes through a sample Dockerfile, explaining each directive and the order in which they are executed. They mention that the Dockerfile specifies the base image (in this case, Ubuntu) and sets the working directory. John concludes by emphasizing that Dockerfiles are used for the static parts of a container and not for runtime requirements.

00:40:00 In this section, John explains the use of the “copy” and “expose” directives in a Dockerfile. The “copy” directive is used to copy files from the host to the image, and it can be used to copy between different containers as well. The “expose” directive is used to specify which ports the image will listen on when it is run as a container. John also mentions that the “expose” directive is often used by management interfaces to determine the ports on which the container is running.

00:45:00 In this section of the video, John discusses various aspects of Docker, including exposing ports and running containers. They explain that when running a container, it is important to specify the correct ports so that communication is possible. They also mention that the “work directory” can be customized, allowing the user to switch between different directories as needed. John emphasizes the recommended way of creating commands in Docker, which involves using arrays or lists. They demonstrate how to build a container using the Docker build command and explain the significance of the dot (.) in the command, which indicates that the build should occur in the current folder. John also highlights the importance of the order in which dependencies are specified in the Docker file, as it can significantly impact the build time. They mention that if one of the dependencies is large, it is best to include it early in the file to optimize the build process. Towards the end, John explains how to run a container and open the necessary ports to access a web interface. They provide instructions on connecting to the container using a web browser and show a simple Python web page that can be accessed. Finally, they mention that in the next part of the video, they will discuss accessing host files and transferring files to and from the container during runtime.

00:50:00 In this section, John discusses Docker compose and how it can be used to run multiple containers simultaneously, which is the first step in container orchestration. They mention examples such as running a MySQL server, PHP MySQL admin, and a web interface together. John also mentions the option of uploading images to Docker Hub for sharing, or sharing it through Source by having it on GitHub. They briefly mention the possibility of doing multi-arch images in part four and hint at discussing cloud deployment in part three. John wraps up by acknowledging that the access log is almost complete and invites any questions from the audience.

Summary text originally from summarize.tech with light post editing.

Federated Web Rings and Link Sharing

2023-09-12T00:00:00Z

Historically I have struggled to maintain a decent list of bookmarks in any browser - for some reason putting them in the browser just means that I immediately forget that they exist at all, making the whole exercise rather pointless. So on the previous iteration of my website, I instead managed a list of links to resources that I commonly enough used, but did so infrequently enough that I would forget they existed before needing them again.

All your links are belong to me; collecting a link's link-list to make more links in our list! Alternatively 'its links all the way down'...

This works well enough for me and could act as a bit of a directory for others, but I thought “wouldn’t it be neat if we could all work on a big curated list of links we individually found interesting, then have them automatically joined together for indexing and searching?” - and yes slightly younger me, it would indeed. The mechanics for this to work are pretty simple too; if we know where a ‘far’ site keeps its list, and we agree on a format, we can wander that list as well, then; using that list we can wander the new links, and so forth until we have a complete list, or get bored following links.

This results in a kind of ‘federated link directory’ with hand picked links that folks have discovered over time, and from wherever you enter the graph from, you get only URLs that are federated from another peer, and so get slightly different resultant list views. With the addition of a few ‘core’ peers acting as master-ish lists, you can also get a pretty complete view of the whole network.

Around and around, individual sites may link to one another, and back again, so some sensible 'do not duplicate' rules are needed when spidering, but otherwise there shouldn't be much problem with recursion.

So I set out to implement this on my site here, so starting with a JSON object, where each key is a link at the top level; we end up with the simplest implementation like so:

{
    "https://example.co.uk": {}
}

The file should exist at /webgraph.json (by convention) but can be overridden by setting the webgraph property for a link entry.

As each link is an object, we can then add optional metadata to each one, allowing us to refine the entry, so a more complex example for a single site might look like this:

{
    "https://example.com": {
        "title": "An example website",
        "tags": [ "example", "web", "testing" ],
        "description": "This is just an example website, used mostly for testing",
        "webgraph": "my-cool-webgraph.json"
    }
}

The individual properties and their types are described below.

The entries in this object can then be used in a couple of ways:

The ‘local’ site can use this to generate a links page, to just have a public set of bookmarks without spidering at all; this is the simplest case.
Any WebGraph spider that gets linked to the JSON can now add the links to its directory, and also follow them if they’re defined as having additional graph files.
A WebGraph spider can use the data here to build a more interactive, searchable list of links for a bigger directory.

I’ve implemented a proof-of-concept spider over at the WebGraph page on this site which will attempt to check the graph periodically and update a simple directory list of links. In the future I’d like to expand this to include search functions, but for now it just presents everything in a flat list.

Optional Properties

"webgraph": "/webgraph.json" A site-local path; the WebGraph URL. If omitted this site is not wandered to build the link graph.

Its worth noting that this does not have to be a bare .json file, but could just as easily be any other valid URL that returns a JSON object. For smaller sites I envisage that the authors would maintain their own .json file and just serve this, parsing it to generate their own link lists on their local site, but for larger indexes this could easily be pulled from a database, or autogenerated from crawling internal pages for external links, for example.

I realise that this could theoretically become extremely large, especially if there are any consolidating sites that rebuild their webgraph data as they spider, however I’m leaving this problem for ‘future John’ for now, as I’d like to see if this experiment works at all first. The graph could fairly easily be paginated however, with the addition of some kind of GET arg like ?p=2 for ‘page 2’ for example, although this would also require that the API exposed had some way of defining an upper limit for how many pages it could serve (unless we just pull until the request fails, but that feels bad to me).

"title": "The Homepage of Cool Mc'Dude" A string. The title string, otherwise the URL should be used in place of a title.

I might scrape this from the link URL later if this property is missing, but this will override that behaviour in any case. Note that right now the spider on this site will use the lexographically-ordered first-found entry for a given site, and drop any other subsequent duplicates. In the future I expect I’ll collect them all then pick the ‘best’ (for various definitions of best) value for these to display, but this behaviour is entirely up to the spider. If you don’t like the behaviour seen here, then do feel free to implement your spider however you like!

"tags": [ "friends", "cool", "dude" ] A flat string array. This is just a simple list of free-form tags, which are later collated by the spider to build tagged link groups.

This can be used in any number of ways to group links together; perhaps by country, language or region (indeed, many of my own so far have ISO country code tags), or perhaps by topic or ‘#hashtag’ maybe? I leave the specific uses of the tags for the network itself to resolve, and that they merely act as a loose way to group links together.

"description": "Some cool person's site!" A free-form string, providing a description for this URL. My spider on this site will attempt to display this if it is present, although it will filter the content if it is excessively long (actual max length to be defined) or contains bad characters (already filtered for all common ones).

Properties Subject to Change

"feed": "/feed.xml" A site-local path. This can be an rss feed, or sitemap.xml or equivalent schema, wandered to populate sub-page lists if present, or skipped if omitted.
I’m a little on the fence about this one, and it may well change to individual typed definitions, with a distinct sitemap and rss options for those types. Perhaps I should include this as sub-property of the larger object for a site, maybe under a meta key, to prevent namespace pollution.

Feel free to tell me I’m wrong in the comments below.

More on Mastodon Comments

2023-08-24T00:00:00Z

This post uses interactive code blocks! Feel free to edit and experiment with the code. All code listings here are MIT licensed with no warranty.

In my previous post, I demonstrated Mastodon comments being used for in-page discussions on this website, but didn’t explain how it worked. (Honestly, the post was barely a post and just demonstrated the concept)

So how does it work?

The Mastodon API has an extremely handy function context for a given status, with which we can ask a Mastodon instance to give us all the ancestors and descendants for a specific status.

By taking the public post URL, we can split out the domain and comment id:

URL    = https://fediscience.org/@johnvidler/110921679945683327
Domain = ^^^^^^^^^^^^^^^^^^^^^^^
UID    =                                     ^^^^^^^^^^^^^^^^^^

Somewhat strangely, we don’t need the username… but anyway, we can then reconstruct this into a REST API address like so:

REST URL = https://fediscience.org/api/v1/statuses/110921679945683327/context
Domain   = ^^^^^^^^^^^^^^^^^^^^^^^
UID      =                                         ^^^^^^^^^^^^^^^^^^

An in-browser demonstration for the previous post’s comments is shown here; click ‘Run’ to see the data.

Unfortunately, the statuses are returned in a flat list (in time order), and ideally we’d like to be able to do comment threading where the parent comment has its replies as part of the parent context, so we can recursively render the reply list and get the nested comments seen on the previous post.

To do this, I threw together the treeifyComments which recursively wanders a tree structure looking for where the status property in_reply_to_id matches a node, and adds the status to the node’s replies list, with a few fallbacks for cases where no mapping can be found.

The following code is an annotated version of this function, and if you click ‘Run’ it will populate the root object with a nested set of comments.

With this structure loaded (and cached by my static build system to keep requests infrequent!) we can now render this into a series of nested <div>s and style it to our hearts content.

Taa-daa!

If you have questions, do reach out via the links below.

Mastodon Comments

2023-08-19T00:00:00Z

I’ve been continuing to rework my site lately, and have just thrown together a basic integration with Mastodon for post comments. Hopefully if you reply to this status, it should be picked up on the website on the next check (usually every 24hrs)

If it works, your comments should show up down below!

Makecode Block Annotations

2023-08-13T00:00:00Z

This is a slowly growing list of annotations for blocks in Makecode, mostly to document these for myself whenever I need to write another extensions.

Working Annotations

These are annotations that I have seen work in practice.

Namespace Properties

//% color="#BC986A" icon="\uf0ea"
Change the colour and icon for the namespace - the icon appears to be most valid unicode characters…

Basic Block Properties

Block Body Text
//% block="block text here"
This will replace the default generated block text with the supplied text.

Menu Groups
//% group="Buttons"
This does not require that the groups be predefined in the namespace.

Place Parameters in the Body Text
//% block="on ClipBit button $button pressed"
Replace $-prefix words with their parameter from the function.
Note that enums will be rendered as their names, rather than their values.

Advanced Blocks - Menu UI
//% advanced="true"
Move the block to the more section below the main section in the extension menu.

Parameter Render Options

Boolean Switches
//% on.shadow="toggleOnOff"
Sets the parameter ‘on’ to use the toggle on/off UI rather an a variable slot

Expandable Blocks (Hidden Parameters)
//% block="set ClipBit $display display to $value || as $style"
The double-bar || indicates the point that the block UI will be split, and replaced with an expander + icon.

Properties for Event Handlers

Allow Dragging of Parameters
//% draggableParameters="reporter"

Moving Between Languages

Shims
//% shim=ClipBit::sendLogViaSerial
Map the exported function annotated with this to the C++ call defined in the shim. Note that this doesn’t make a block by itself, and just exposes the call to Typescript.
If the function in Typescript has a body, this will be used in the sim.

Non-working Annotations

These are annotations that don’t seem to work correctly for Makecode extensions

Grid Picker

//% name.fieldEditor="gridpicker"
//% name.fieldOptions.columns=4
//% name.fieldOptions.tooltips="false"
//% name.fieldOptions.width="250"

This (as seen in pxt-microbit here) seems to enumerate enum values and generate a grid of buttons rather than the usual dropdown, except that it doesn’t work for extensions? Specifying these paramters will result in the block not having any parameter for the user to select at all!

Updated 5/2/2024

If you don’t actually want to have a block show up, but need the c++ shim to be generated, the correct way now seems to be to include //% as a comment before the methods you want to export.

With no directives, this just generates the shims and makes the compiler happy again.

Bee Photography

2023-08-03T00:00:00Z

I don’t have any decent cameras, just my mobile phone (Currently a Google Pixel 5), but sometimes I do manage to get a half-decent shot or two, and apparently the one thing that this phone is particularly good at is macro photos.

A close up photograph of a bee!

There are a rather large number of bees buzzing around the flowers outside my office right now, so I took the opportunity and managed a few decent shots.

Another bee, stepping from flower to flower

A bee face-deep into a flower

A bee about to be face-deep into a flower

A bee investigating small clusters of flowers

Chicago Photography

2023-07-26T00:00:00Z

I don’t have any decent cameras, just my mobile phone (Currently a Google Pixel 5), but sometimes I do manage to get a half-decent shot or two. In this case, these are all from my trip to IDC’23 from wandering around the city after the presentations.

Coming from Lancaster, where there aren't many tall buildings, what struck me in particular was the sheer number of floors on every building.

One of the things that I found a bit disconcerting was how often you’ll be at the foot of very tall buildings all around you, which has a very similar feeling as to being at the bottom of a deep valley. I’m a bit more used to open spaces, so the overall effect was a bit claustrophobic, something which I’m not normally afflicted with.

The classic panorama shot, showing the buildings river and boats. Taken from the railings on the river just outside the Apple store at the riverside.

Another classic shot of the overhead metro.

Lots of boat trips on the river in Chicago. The conference organisers actually organised one that I could have gone on, but the costs were a bit prohibitive, unfortunately.

In the plazas near the riverside there are quite a few statues. Unfortunately I didn't have time to read the plaque about this one, only having enough time to snap a photo or two and dash off.

We wandered out of the city a little midway through the trip, going to one of the restaurants in an area known for amazing Mexican food (it was!) but it also exposed us to a little of the behind the scenes.

A little behind the scenes; an alleyway stretching off into the distance

“Manjaro Linux on the Yoga Book”

2023-06-08T00:00:00Z

It works (mostly) out of the box now!

I unfortunately managed to update the pure Arch Linux kernel on the laptop right in the middle of an update that broke support for the chipset that it used; perfectly timed to mean it fails to boot, so was generally unrecoverable.

Thankfully, I had only installed Linux on the uSD card at this point, so I could reboot into Windows if I had needed a working machine, and it had all my driver and configuration tweaks saved too.

Experimentally, I had another go with Manjaro Linux with the Gnome/Wayland front end - I had tried this previously, but without the machine booting at all; so you can imagine my surprise when the whole system fired up all the way into the graphical interface.

Everything that had worked before on Arch, including some surprises with auto screen rotation working out of the box too. Apparently Manjaro include iio-proxy by default, surfacing almost all the sensors properly so Gnome could use them.
Naturally an exception was the keyboard, which only came up as a giant touchpad, as was the case for Arch as well, but I hardly expected that it would just work, as its quite the exotic bit of kit; and unfortunately the cameras (front and rear) and the sound card still don’t work, and still come up as a dummy output and dummy input on PulseAudio.

This is great progress, however! It means I don’t need to work to bring a system up from a bare frame buffer state, and can start with most of my work done for me. Being Arch-based, the software I wrote for the keyboard worked out of the box too, so in the space of a couple of hours, I went from a completely dead machine to the same state that I reached before, except with a stable, normal kernel, rather than the mainline one I had to use for Arch.

Speech Development (Part 2)

2023-06-01T00:00:00Z

This is a follow up to a previous article

So! It wasn’t me!

I probably shouldn’t be happy about this, but knowing that by teaching my daughter sign language I haven’t actually set her back on normal speech development is a significant weight off my shoulders.

Instead, through some more testing with the fantastic folks at the child hearing clinic near here, we’ve established that she’s hearing everything about 2-3 times more quiet than normal, and that the problem seems to be continued ‘glue ear’ in her middle ear. When she was tested with a bone conduction speaker (and thus, one that avoids exciting the middle ear, but shortcuts directly via the bones in her head) it turned out that her hearing was totally normal, just nothing was getting through because of a middle ear blockage.

So this leads on to ‘what next?’ for this particular saga; naturally I don’t want her to slowly get behind with speech development as right now she’s propping herself up with the rest of her age group through just being a smart cookie, but that won’t last forever - but the only options right now are either (minor) surgery or having a hearing aid (amplification type, no surgery).

The NICE^[1] guidelines for the type of surgery that would be required now stipulate that the operation should only normally be done twice over the course of an individuals lifetime, to minimise the scar tissue involved becoming more of a problem, and with my daughter being quite small still (she’s only three!) there’s a good chance that the operation will need to be repeated at a later stage to re-apply the fix pretty soon after the first one fails. So instead of surgery, we’re going down the hearing aid route.

As a computer scientist this is deeply interesting to me as well; the miniaturisation of these devices has been fantastic of late, what with all the battery technology advances, but as a resident of the UK, I do now need to arrange for these to be sorted for her through… The NHS^[2]

For all its facets, good and bad, the NHS has generally done me and my family pretty well so far; but this is a whole new game with multiple disconnected departments talking to one another via snail mail right in the middle of the largest industrial action seen in recent times^[3]. I have all the sympathy for the plight of junior doctors but at the same time I’m not relishing the prospect of navigating the complexities of the NHS.

Wish us luck!

The jac:stack - An Addon for the Micro:bit

2023-05-30T00:00:00Z

The original whiteboard design for the jac:stack. Ultimately I dropped the left-hand Jacdac connector due to space concerns, but the overall design made it all the way to production.

This is the second iteration of an idea to present GPS support to the Micro:bit, but rather than the previous version which was more of a dedicated GPS logger board, this one presents the much more flexible Jacdac interface to two ports for screw terminals, or one wire-to-board connection on the right.

The passthrough module in all its glory - Note that although the GPS _is_ connected to I2C, the firmware on the Adafruit modules makes no use of I2C, and in fact interferes with the normal operation of other I2C peripherals, necessitating me cutting the SDA line to the GPS module

Jacdac Support

Jacdac is both an electrical and protocol specification for connecting devices to sensors with as low friction as possible. This is achieved by way of a 3-pin interface (ground is duplicated to make a 4-standoff variant for bolted-on modules) that can be driven with a slightly modified UART in half-duplex mode, and a software stack able to automatically identify connected devices and present a common interface up to higher-level code. The upshot of this complexity is a kind of microcontroller USB.

Jacdac is developed by Microsoft Research, and the pages for which can be found at the project website over on github.io.

I elected to support this protocol here as it opens up a wide range of sensors already developed, and vastly increases the flexibility of the Micro:bit as a sensor platform.

My development module, including the lovely airwire link between the UART transmit pin and P0, as I accidentally destroyed the solder jumper on the back of the board. Also featuring a Kittenbot Magnet Sensor board on the right-hand Jacdac port

Adafruit “Ultimate GPS” Support

Having had no luck whatsoever with GPS modules on the previous design, I chose to pick as close to a ‘fully integrated’ module as I could, and costs therein be damned. Consequently, this board uses the Adafruit Ultimate GPS Module; a reasonably small, but very capable module that should just work^TM.

The module boasts quite the set of features (list taken from the Adafruit product page):

-165 dBm sensitivity, 10 Hz updates, 66 channels
Ultra low power usage: 20mA current draw while tracking
3.3V operation,
RTC battery-compatible
Built-in datalogging
PPS output on fix
We have received reports that it works up to ~32Km altitude (the GPS theoretically does not have a limit until 40Km)
Internal patch antenna + connection for optional external active antenna
Fix status output
Ultra small size: only 16mm x 16mm x 5mm and 4 grams

But what was most interesting to me in this case was the inclusion of both UART and I2C peripheral pins; and as the Clip:bit input board exclusively uses I2C to not content with any other peripherals, perhaps I could wrangle this module into working without using any more pins on the Micro:bit, freeing them for other, more fun stuff.

Unfortunately, the default firmware seems to have no way to set the module to send data over I2C, so instead I had to fall back to using P0 for serial data. Thankfully for the work I’m doing with this module we aren’t using anything connected to P0, so this proved to not be a major issue.

NMEA Data

With the hardware completed, I also needed to write software for the Micro:bit and Makecode which would present the positional and time data to the user without having to deal with raw NMEA strings.

To this end, I produced a set of blocks for Makecode which let users simply pull in a latitude or longitude block to get their location.

Taken from the module datasheet; note the multiplexed I2C pins as well as the usual UART pins

GPS Logging

Throwing this new extension in with the Micro:bit v2 Data Logger extension provides all the tools to do some basic GPS path logging, with the device periodically sampling its location and writing that to flash (along with any relevant sensor data). Further augmenting the functionality with the addition of the Clip:bit gives a powerful survey platorm that can both log

https://github.com/JohnVidler/pxt-jac-stack
https://github.com/JohnVidler/pxt-mock-gps

The clip:bit - An Addon for the Micro:bit

2023-05-20T00:00:00Z

I’m still writing this article, expect missing content! -John

This work was published at IDC’23!^[1]
See the paper and poster here:

Supporting fieldwork for primary education with computing – micro:bit, clip:bit and game controllers.^[2]

Introducing Classroom Cloudlet: a mobile, tangible, and transparent approach to Internet of Things education.^[3]

Dear reader, please be kind to me on this one. For whatever reason, many of the components on this design have been particularly impacted by the ongoing (mid-2023) chip/parts shortage, and it caused me to have to replace rather a lot of the ones I wanted to use with nearly-alike alternatives, which does rather leave the board in a state which might look a bit strange to those of you in the design game.

…

A purple clip:bit, in all its slightly incomplete glory. The through-hole parts were manually added later, to speed up the manufacturing at JLCPCB.

A complete clip:bit in (nearly) Lancaster University Red. Don't come after me marketing team... I only had the base FR4 colours to choose from!

Circle Intersection is a Pain!

This wasn’t very painful, but getting a contiguous line along a series of arcs in KiCAD takes a certain amount of finesse; an amount that I did not have at the start of this work, and resulted in some messing around to get the circle paths to line up in such a way that I could make KiCAD snap the arc segments together for a smooth cloud shape.

The clip:bit logo, showing all the construction circles I used to get the alignment just so.

The trick, should anyone want to replicate this in their own work; is to enable grid snapping for your circle templates on a user# layer, then turn all snapping off to trace over the templates where you actually want your silkscreen/edge cut lines to be, otherwise KiCAD will do everything in its power to try and snap you to stuff you don’t want. The grid, pads, other lines, the center mark, horizontal/vertical alignment points… resulting in not-quite-perfectly-joined paths that will make the DRC hate you.

Better Routing Decisions

There are several places on the board where rushed decisions caused more trouble than they should - here for example I should have rotated the driver chip for the 7-segment displays 90 degrees left OR right, then routed out the side of the chip rather than resorting to the slightly ugly traces under the chip.

The left-hand display traces on the clip:bit v3. This is a dumb way of routing these!

The rotation would have caused the LEDs mappings for each segment to change, but as these would be defined in software anyway, this is a non-problem and should have been corrected at the design stages.

Oh well… it does work, and in some senses protects the traces from damage by moving them closer to the center of the board, rather than having to be right at the left-hand edge.

I don’t miss placing all those resistors though! Yeesh!

The Power Switch

Another issue was with the side-actuated power switch, again added at the end of the design process, and I was forced to pick a part that I could actually find stock of (at the time of writing, the chip/component shortage is still a very real annoyance). Unfortunately a combination of slightly too thin mounting pads, and poor mechanical construction of the switches results in many of them being damaged by users.

Added right at the end of the design process, this switch (SW13) proved totally inadequate

One option that I should have perhaps explored further is to toggle the power through the insersion/removal of the micro:bit itself - there are additional traces for power, so routing through a set of pads on the edge connector is possible, but in this design would have resulted in some long power traces running up the back-side of the board to support this. At the time, I thought that this was too risky as long traces on a surface that could be placed on rock, or other abrasive surfaces would likely just be a recipie for disaster, but for v4 I’m absolutely moving to that design to remove the switch!

pxt-clip-bit^[4]
pxt-paged-data-log^[5]

ACM Interaction Design and Children (IDC) Conference; 2023 - https://idc.acm.org/2023/ ↩︎
Elizabeth Edwards, John Edward Vidler, Lorraine Underwood, Elisa Rubegni, and Joe Finney. 2023. Supporting fieldwork for primary education with computing – micro:bit, clip:bit and game controllers. In Proceedings of the 22nd Annual ACM Interaction Design and Children Conference (IDC ’23). Association for Computing Machinery, New York, NY, USA, 553–557. https://doi.org/10.1145/3585088.3593897 ↩︎
Lorraine Underwood, Elizabeth Edwards, John Edward Vidler, Elisa Rubegni, and Joe Finney. 2023. Introducing Classroom Cloudlet: a mobile, tangible, and transparent approach to Internet of Things education. In Proceedings of the 22nd Annual ACM Interaction Design and Children Conference (IDC ’23). Association for Computing Machinery, New York, NY, USA, 740–744. https://doi.org/10.1145/3585088.3594487 ↩︎
The Clip:bit extension for MakeCode ↩︎
The Paged Data extension for MakeCode ↩︎

The Micro:bit - GPS Logger Prototype

2023-05-10T00:00:00Z

This module is rather unimaginably named the ‘Micro:bit GPS Logger Prototype’ as it never really worked well enough to warrant a proper, snappy name.
Unfortunately despite the module I selected communicating beautifully over i2c pretty much immediately, I failed to correctly account for the ground plane requirements for the GPS antenna to function, resulting in a great looking, but ultimately functionless module.

An auxillary power connector (JST)

Its a power connector!

No, really, its not really all that interesting for this one; I included this to present battery backup power to the GPS module, even when the Micro:bit is in deep sleep or power-off modes, keeping the last set of satellite fixes in memory until they’re needed again.

I threw on some protection diodes as well, such that powering the board through the Micro:bit USB connector, the Micro:bit JST battery connector and using this connector, even all at once should be fine, without any power supply trying to back-feed power into a battery with all the potentially firey consequences that would have. The diodes introduce a little bit of a voltage drop, but as this was intended for something like a set of AA cells (or bigger) they would have the voltage overhead to not matter.

A ‘push-push’ type micro-SD card slot.

Micro-SD cards have a really handy SPI mode, and can be hooked directly into any 3v3 microcontroller that can support SPI. You still need some software capable of reading the filesystem on the card (or just treat it all as a giant EMMC and deal with such nonsense as ‘reading’ the data on a computer later), but electrically this is extremely simple.

The connector itself is a nice push-push type with a little bi-stable spring to eject the card. This allows the user to just press the card into the slot until a very satisfying click is heard, then simply press it again to have it pop pleasingly out far enough to comfortably grab. This plus a little milling out around the edge of the PCB to make grabbing the card easier finishes this off.

Unfortunately, as this function wasn’t the main focus of the work at the time, the software to drive the card remains incomplete, although there is every chance I’ll revisit this at a later time when I need larger long-term storage on a micro:bit… perhaps for long-term datalogging in hard-to-access places; such as being deployed in a forest for environmental monitoring duties.

A CAM-M8C-0 GPS module

In theory this should have been a great little module - its expensive, but is very capable, and can communicate over i2c, so no pin sacrifice would be required to use the module - we can just simply pass the i2c connections through from one Micro:bit connector to the other, and tap into them for communication to the GPS module. The Micro:bit even has the requisite pullups for i2c already on-board, so this board could skip the two extra resistors normally required.

Unfortunately, it would transpire the this particular module is particularly sensitive to the shape and placement of the module relative to the PCB groundplane.
I had accounted for the required cutout on the underside where the module is soldered to the PCB, but to function at all it seems that this little GPS needs to effectively use some of its carrier PCB groundplane as part of its own antenna. Not knowing this (As I’ve not used this particular module before, and missed it on the datasheet) I didn’t leave enough free space around the module for the antenna to function, so while we get some perfect NMEA strings back from it - the total number of satellite fixes never goes above zero, even in otherwise ideal conditions.

In hindsight, perhaps I should have also broken out the antenna trace to a u.FL connection, so that an external antenna could be used, but that would require planning! Perhaps someday I’ll revisit this module in this design, and do this, but for now its relegated to the archive while work progresses in other directions.

Software

As part of developing this board, I also quickly threw together this little MakeCode^[1] extension, pxt-mock-gps^[2], which uses a preloaded set of coordinates and a timer to passively ‘wander around’ the Lancaster University campus over time, allowing my colleagues to experiment with code that used location data in their code sketches.

Speech Development

2023-03-03T00:00:00Z

I recently found out from the preschool that my daughter isn’t keeping up with the other kids with her speech development.
This came as quite a surprise, as although her speech is a bit garbled, due in part to being a kid, but also as she currently has a case of ‘glue ear’ so she’s not hearing things quite correctly; she is normally quite a chatterbox at home, and her talking away has been noted by both sets of grandparents.

The preshcool folks have apparently seen her talking to other kids, but she doesn’t chat with them.

So the options, as far as I can see here are:

With all the other kids at preschool, she’s just not as clear as a quiet home environment.
She’s a quiet kid at ‘school’, so simply doesn’t want to talk to everyone
Something else, developmental or hearing related.

…or even worse: Its my/our fault …somehow.

I’ve been learning British Sign Language (BSL) since she was very small, as we had been using Makaton sign with her since before she could speak at all.
Part of me wonders if this is actually slowing her down now.
She signs very well for a 2.5 year old, as far as I can tell as a learner myself - she keeps up with me at full speed at least, and responds in kind, but is that just that she’s focussing on this because its what we do rather than her speech itself?

Have I slowed her speech development?

Its probably nothing.
Probably.
But I have to assume the worst because anything else might be a disservice to her later down the line; so now we’re actively encouraging her to speak up, speak clearly and to talk with her ‘teachers’ at the preschool.

They’re working with her too, doing 1:1 sessions, reading with her, and so forth to see how she responds.

But for now; I think I’m going to put this into the ‘deep dark fears’ pile.

She’s my first (and currently only) kiddo, so all of this is entirely new to me, so everything is doubly terrifying whenever anything going wrong.
I’d love to be the kind of chilled-out parent that can just float through doing all the right things at all the right times, but I’m also nearly convinced that they don’t actually exist.

Finally a word of advice for new parents - don’t take the books to heart; I’m entirely convinced that the people who write those things are essentially outliers with specific problems, rather than the average case.
That isn’t to say that the books are useless, just that you need to take everything they say with a pinch of fiction; every kid is different, so the books are going to only be of passing relevance.
Maybe some parts map perfectly onto what you’re seeing with your kids, but that doesn’t mean everything they say will be correct.

Arch Linux on the Yoga Book

2023-01-02T00:00:00Z

I have a Yoga Book - the only laptop that I’ve actively wanted at launch - and with its release now in the dim and distant past of 2016 its really showing the age of its hardware, so I’ve decided after some deliberation to attempt to get a working Linux stack running on it.

There were two versions of the laptop at launch, one running Windows 10 and the other running Android, and while they may appear similer externally, they are very different internally.
Mine is the Windows 10 edition, so runs a fairly normal EFI boot configuration and can run USB ISOs, and has the following specification:

Feature	Details
Operating System	Windows 10 Anniversary Edition
CPU	1.44GHz Intel Atom x5-Z8550 (quad-core, 2MB cache, up to 2.4GHz with Turbo Boost)
Graphics	Intel HD Graphics 400
RAM	4GB (LPDDR3)
Screen	10.1-inch FHD (1,920 x 1,200 resolution), IPS touchscreen
Storage	64GB flash storage (expandable by up to 128GB via microSD)
Ports	microUSB, microHDMI, 3.5mm audio jack
Battery	8,500mAh
Connectivity	802.11ac Wi-Fi (2.4 & 5GHz), optional 4G radio, Bluetooth 4.0
Camera	2MP front-facing webcam with fixed focus; 8MP rear camera with auto-focus
Weight	1.52 pounds (690g)
Size	10.1 x 6.72 x 0.38-inches (256.6 x 170.8 x 0.96mm; W x D x H)

Its ludicrously slim as compared to laptops of the time, and performed well enough that I used to present my lectures directly from the thing, plugging in via a micro-HDMI port to connect up to a projector.

Its just so thin! Its thinner than its own pen! Its barely tall enough to have a 3.5mm audio jack; but also 'Boo' at Lenovo for not making the version I have use USB-C (Image credit: Lenovo)

It has the usual touch screen input, which is handy for when you’re using it in ‘tablet mode’ with the keyboard folded all the way back, but the truly odd thing about the hardware is the keyboard/touchpad/digitizer combination input area.
This is placed where the keyboard would be on a traditional laptop, but instead is a full-size touch panel, with electroluminescent^[1] (EL) lines and glyphs to indicate the virtual key areas.
It also has a mode switch (also a sort of touch keypad) which toggles the EL panel off, and converts the entire area to a Wacom^[2] style digitizer, compatible with any electromagnetic resonance (EMR)^[3] pen as an input.

However, provided that I can get this machine to boot, I should be OK on the hardware otherwise, as it uses fairly common components for everyhing except the input layer.

Booting!

So, armed with a Manjaro Linux^[4] bootable USB I attempted to get past the EFI loader aaand… nothing. Zip. Zero.
Just a black screen, not even the legendary blinking cursor of death for GRUB-based boot systems.

Undeterred, I threw Alpine Linux[^5] at it, aaaand nothing.

At this point I was beginning to think that I’d need some kind of magic to get into a bootloader, but then I tried Puppy Linux[^6], knowing that it is famously light on resources and runs on a wide variety of older hardware just fine; and success! Kinda!

Err, Puppy Linux...? Are you OK?

Well, its running at least!

I could get past the GRUB stage, and get the kernel loaded. Early boot messages seemed to be scrolling, and then it dropped to this mess.
So this is promising, as it shows that Linux in some variation is capable of booting into some form of runtime.

Puppy linux has a ‘safe mode’ terminal-only boot mode, and I figured, why not give it a go, as I could read the GRUB prompt just fine, so I can toy with linux boot args and get to a terminal-only framebuffer maybe?

Puppy Linux... you might have some video issues there...

From prodding a USB attached keyboard (actually a USB-OTG adapter to a USB hub with built-in ethernet, because this thing has no ports whatsoever!) I could see that I was getting characters on a terminal, and the right kind of output vaguely presented itself on the screen.
Typing ping 8.8.8.8 resulted in the usual 1 line per second return, so I was pretty confident that the system was booted, and running Bash, but the video config was horribly mangled.

At this point I was pretty disappointed, as I had expected to see something for a bare framebuffer boot, but after some thought I figured it would be worth trying bare Arch Linux (from which Manjaro is based) and slowly bringing components up bit by bit.

It worked! Arch ran out of the box just fine - and I was presented with the usual install/recovery environment on the live USB, allowing me to finally install a full system onto the micro-SD card I had in the laptop.
While I had a running system, I took a prod around to see what devices actually came up as, and they’re listed here for the curious:

[john@yoga-book ~]$ lspci -tv
-[0000:00]-+-00.0  Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SoC Transaction Register
           +-02.0  Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller
           +-03.0  Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Imaging Unit
           +-0a.0  Intel Corporation Device 22d8
           +-0b.0  Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power Management Controller
           +-14.0  Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller
           +-1a.0  Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine
           +-1c.0-[01]----00.0  Broadcom Inc. and subsidiaries BCM4356 802.11ac Wireless Network Adapter
           \-1f.0  Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCU

[john@yoga-book ~]$ lsusb -tv
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/7p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub

[john@yoga-book ~]$ hwinfo --short
cpu:                                                            
                       Intel(R) Atom(TM) x5-Z8550  CPU @ 1.44GHz, 2400 MHz
                       Intel(R) Atom(TM) x5-Z8550  CPU @ 1.44GHz, 2400 MHz
                       Intel(R) Atom(TM) x5-Z8550  CPU @ 1.44GHz, 2400 MHz
                       Intel(R) Atom(TM) x5-Z8550  CPU @ 1.44GHz, 2400 MHz
mouse:
  /dev/input/mice      HDP0001:00 2ABB:8102
  /dev/input/mice      Goodix Capacitive TouchScreen
graphics card:
                       Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller
network:
  wlp1s0               Broadcom BCM4356 802.11ac Wireless Network Adapter
network interface:
  wlp1s0               Ethernet network interface
  lo                   Loopback network interface
disk:
  /dev/mmcblk0         Disk
  /dev/mmcblk0boot0    Disk
  /dev/mmcblk1         Disk
  /dev/mmcblk0boot1    Disk
partition:
  /dev/mmcblk0p1       Partition
  /dev/mmcblk0p2       Partition
  /dev/mmcblk0p3       Partition
  /dev/mmcblk0p4       Partition
  /dev/mmcblk1p1       Partition
  /dev/mmcblk1p2       Partition
usb controller:
                       Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller
bios:
                       BIOS
bridge:
                       Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Express Port #1
                       Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCU
                       Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SoC Transaction Register
hub:
                       Linux Foundation 2.0 root hub
                       Linux Foundation 3.0 root hub
memory:
                       Main Memory
unknown:
                       FPU
                       DMA controller
                       PIC
                       Keyboard controller
                       Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Imaging Unit
                       Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine
                       Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power Management Controller
                       Intel Unclassified device
                       Serial controller

Arch Linux installing to the micro-SD card in the Yoga Book

The keyboard area all lit up! It changes modes by default, but will not work as a keyboard without further work

XFCE4 seems to want to run rotated 90 degrees...

Forcing the rotation over seems to work, but the rotation sensors aren't talking to me right now.

Device Status

The following is just a kind of checklist for me to keep track of what is working, and what still needs attention.

[x] Boot (EFI)
- [x] From USB
- [x] From uSD
- [ ] From SSD
[x] WiFi
[ ] Bluetooth
Audio
- [ ] Speakers
- [ ] 3.5mm Jack
- [ ] HDMI Output
Video
- [x] Terminal shells
- [x] X11
  - [x] Screen Rotation
  - [ ] Display Brightness
- [ ] uHDMI Output
Input
- [ ] Trackpad
- [ ] Keyboard (virtual)
- [x] Touch Screen
[x] USB
- [x] USB-OTG
- [x] USB Ethernet

EL panel tech link ↩︎
The Wacom homepage ↩︎
EMR tech link ↩︎
Manjaro Linux, based on Arch Linux under the hood - Manjaro ↩︎

Sleep

2022-12-24T00:00:00Z

I’ve always struggled with sleep, even from a very early age; my mother will gladly regale anyone who asks that as a toddler, she would leave me to sleep whenever or wherever I fell asleep, as she could never get me down for a nap otherwise.
Since I’ve discovered that I have some form of frontal lobe brain issue, I’ve put my sleep issues down as part of it and just deal with the battle each night.

Put simply, I don’t seem to have much of a “being sleepy” phase… I’m either awake, or asleep, with nothing in between.
I do get tired but it doesn’t make me want to sleep.
I couldn’t count the number of times I’ve been jammed awake, completely exhausted but entirely unable to sleep.

Now I have a daughter.

Well, I’ve had one for a while really. At the time in writing this she’s about 2.5 years old, and just beginning to sleep on her own, in a separate bed (we did the whole co-sleeping thing to begin with) and getting her to sleep is nightmare.

She’s definitely a “high energy” child at the best of times, and we both love her energy must of the time, but when it comes to bedtime she’s all over the place, bouncing (sometimes literally) off the walls; getting up in bed, shuffling around, and so on.
At this point this should sound a bit familiar… And I dearly hope I’m wrong, but…

… what if she’s just like me?

It’s a bit of a “deep dark” fear for me.

I wouldn’t wish my sleep issues on my greatest enemy, let alone my own children and I don’t have any great coping strategies applicable to a toddler.
I’ve been able to drop off by listening to audio plays, books and the like. I have a set of Goon Show tapes, originally recorded by my father when the episodes were broadcast live on the BBC that used to be played extensively when I was still living with my parents, and I’ve since transitioned to Audible books and a Bluetooth speaker sleep mask^[1]; neither of which is likely to be particularly affective with a small child.

At this point I feel like we’ve tried everything to get her to drift off.
Warm milk, quiet wind down time, darkened rooms as we get her ready to sleep, a consistent routine, sleeping with teddy, sleeping without teddy, lying down next to her until she goes, rubbing her back to sooth her… The list could go on endlessly.
Nothing in particular works, save for pushing through the inevitable tired-baby-tantrum and getting out the other side to exhaustion so she actually sleeps.

So for now, we struggle through bedtimes through brute force and chaos energy, and each time I hope I can hit on something that works for my daughter, and hope she grows out of it as
she gets bigger.

Heck; I’m still going I grow out of it too.

Part of the 500 words challenge I’ve set myself. This doesn’t quite make it, with just 456 words. Oh well.

I highly recommend this to anyone hard-of-sleeping like me, as they block out light and sound! ↩︎

500 Words

2022-12-22T00:00:00Z

I’m terrible at writing at length.

I have a PhD, and as part of this I, like many others before me, had to write up my work in a thesis, and it was absolute hell.

The act of just sitting and writing is something that I’ve found extremely difficult for as long as I can remember.
In school when essays were handed out as homework every time without fail I would think “Not this time. Not again. I’m going to be better. Start early, and make a good job of this”, but every single time it ended up with me staring at a blank page for hours on end without any tangible idea for how to make it any less blank.

Late on, I would discover that I have some (or all?) of the traits of ADHD, but back in the ‘bad old days’ ™ we didn’t have these things, and I certainly hadn’t been diagnosed with anything, so I bumbled on through until the latter stages of high school wondering why I found it so extremely difficult to write.

Still, even armed with a diagnosis I had little in the way of coping strategies to deal with this long into my higher education, and consequently I spent hours (probably literally days) in the university library just throwing time at the thesis; bludgeoning it and my wayward brain into submission to get it done.

Ultimately it got one, and here I am, doctorate in-hand, and with what seems to be more and more of a mild phobia-like reaction to writing longer pieces of work - somewhat of a problem when you work in academia and are required to write at length on complex topics periodically, either to teach or to submit work to conferences and journals.

So here I am, writing on here instead in an attempt to reset my brain and let it know that yes, you can indeed write at length, and it isn’t anything to be afraid of, and that no papers are going to jump out at you from around the corner or under the bed.

The plan - such that it is - is to attempt to write about 1 page of standard A4 on some topic or other semi-regularly, for as long as I can manage.

I’m definitely going to fail to do this, but that’s not the point - the point is to try.

So. The rules:

Write 500 words per article (minimum)
Words only count on a ‘blog’ style post
Words only count if they’re published to this website.
Formatting marks (as this is written in markdown) and titles, captions, quotes, etc. don’t count.
Don’t be stressed about missing 500 words or a deadline, just publish.

Lets see how well this works, especially with No. 5…

Total words: 465

Micro:bit Disco Demo

2022-06-20T00:00:00Z

I’ve thrown together a little demo to show off the micro:bit v2’s microphone functions, mostly to demonstrate the update rate (its very high!).

Here’s a video of the board listening to my laptop play back some drum and bass (always good for tech demos!) and it updates its lighting to match the beat… mostly!

My version of the classic Disco Lights demo, running in CODAL on a Micro:bit v2

Once I remember, I’ll post the code to do this in CODAL/C++ and MakeCode, if folks are interested.

Prototype Robot Controller

2022-05-19T00:00:00Z

In a fit of buying interesting hardware a while ago, I picked up two of these joystick modules, each has a nice bezel, and two potentiometers on the back for sensing position; but mostly I picked them up becuase they have a really really nice feel to their movement, and the extended stick length is fantastic.

The sticks are much more like the length of a professional radio control handset than say, an games controller.

A back, interior view of the controller, with only one button and switch installed. All are laying on the print bed from a 3d printer

Naturally, these had to go into a suitable case, and therefore I just kinda… did nothing, while I psyched myself up to actually design something.

After a little bit of mental back-and-forth, I ended up on this prototype front cover design, which incorporates:

Both 2-axis joysticks (Model: JH-D202X-R4)
6 momentary push buttons
6 toggle switches
A 3.2 inch resistive touchscreen HMI from Nextion
A USB-micro-B connector for programming and/or joystick mode for PC

A close-up photograph of the interior of the controller, no components wired up

My initial plan with all of this was to simply make this a slightly exotic form of HOTAS (Hand On Throttle And Stick) controller, designed to essentially be a fancy joystick/joypad for PC games, but the more I’ve been designing the case, the more I’m inclined to actually make this an extensible, field-reconfigurable radio control handset instead.

… with joystick functionality if plugged in, of course!

A front-on photograph of the controller, hardware all populated, and showing many fingerprints on the screen

To support all of this, I had intended to go with the Teensy 4.0 or Teensy 4.1 boards, as both have software support for joysticks with amusingly large numbers of inputs, but now that I’m planning to build this as a proper RC controller, I now wonder if I should go with one of the Micromedia ‘Smart Display’ devices as the company supplies many different radio add-on ‘Click’ boards so the controller could support a wide range of protocols, software willing.

Image from www.mikroe.com, showing the stm32-m4 smart display platform

Screenshot from www.mikroe.com, showing the extension board with two click boards populated

Still, I’m very happy with the overall feel of this prototype, and once I’ve decided on a route to take with the controller, I’ll re-print the casing in a higher resolution with some minor fixes included.

Watch this space 😃

Reading RS485 Data From The BMS

2021-06-10T00:00:00Z

… I think I need more smarts in my BMS. There are some fun cold-start edge cases for my EV motorbike whereby the system needs to turn on enough to handle charging the rest of the system, and the BMS just isn’t clever enough to deal with this, so it requires a bit of a bodge via the vehicle management unit (VMU) to kick it into gear.

No problem, just use the CAN bus or RS485 to talk to the BMS and change its modes.

But in a frustrating turn of events, it appears that my Battery Management System (BMS) for the EV motorbike does not support CANBus (which is fine, I guess) but also does not support RS485 in the same set of speed ranges as my PLC (which is not!).

This means that, while my PLC has a native RS485 port, the serial interface it uses for that port cannot be set the locked-in bus frequency for the BMS, so despite them being really close they’re just different enough data rates to just see mangled data from one another.

A terrible video of the console-only interface I've written for the REC BMS, running over RS485.

My ‘fix’ for this, is a dedicated TTL serial to RS485 board, which takes a normal UART and translates it back and forth from RS485 levels. As this board has a more forgiving crystal, and can change speed between the UART one one side and the RS485 bus on the other, it finally lets the PLC talk to the BMS!

If you have a REC Battery Management System, and want to have a go with my open source software for them, you can find the code over at github.