mikecoats.com

Stop the WANPTEK/NANKADF power supply's beeps

2025-03-30T13:37:00+00:00

The Nankadf (aka Wanptek) WPS3010H power supply is an excellent piece of test equipment to have on the bench. It's cheap, reliable and it's got a wide range for both voltage and current output.

Problem

It does have one fatal flaw; out of the box it beeps on every interaction.

Turn it on? *beep* Reduce the current limit by 0.1 A? *beep* Nudge the voltage up by 0.01 V? *beep*

Solution 1 - Turn off the beeps in the menu

According to the manual for this range of PSUs, we can dive in to the system settings and stop the beeps.

System settings

Press and hold the Output button for 5 seconds to enter the system setting function. According to the needs of use, the machine can be set by default.

The system default setting items include:

[...]

Buzzer switch.

[...]

After entering the system settings, turn the voltage encoding switch to change the default parameters of the current project; press the voltage encoding switch to switch to the next item, if you have switched to the last item (item 6), click the voltage encoding switch again, the machine will Save the parameters and exit the setting state.

Changing the setting for item 4 from 1 to 0, should turn off the beeps.

This works for all of the beeps except for one. The power supply still beeps on start up. Unfortunately, this beep is the longest, and seemingly loudest, noise it makes.

Solution 2 - Remove the beeper from the PSU

Do you really own anything if you don't modify it?

Luckily for us buzzers and beepers are usually large, obvious, and simple to desolder once you find them. Let's tear the power supply down and remove that buzzer!

Start by pulling off the two knobs from the voltage and current selectors, then undo the screws holding the metal cover to the body of the supply. You don't need to pay too much attention to which screw came from where, just be aware of the different threads for screwing in to metal vs. plastic.

Once inside, be careful around the circuit boards, particularly the capacitors, since they could still hold enough energy to give you a jolt. Remove two screws from the bottom of the front panel and one from the cross brace and then front panel is loose enough to move around.

Disconnect the two ribbon cables from the back of the PCB and the five screws circled in white. The control panel PCB can then be removed from the front casing.

A quick look around the board reveals BUZ1 over by the rotary encoders used for setting the voltage and current. Luckily for us it's a big through-hole part, so desoldering takes just a couple of seconds with a decent iron and a solder sucker.

Re-assembly is just the teardown in reverse! Power it up, test it still works, then bask in the silent bliss of a land without beepers or buzzers.

Low Tech Prototyping

2025-03-22T13:37:00+00:00

In my earlier VanSpoof prototyping posts I was working with circuit boards designed for testing and debugging, but not really suitable for installing on to the bike. They're too big and the wrong shape to fit in any of the any wee nooks or crannies around the bike, so I need to come up with something smaller and find somewhere to install it.

A chap called Max reached out and suggested that we could possibly design a board that could fit inside the frame tubes, but I'm not sure if the current STM32 chip is small enough to fit through the existing hole used by the e-shifter cable. There are other, smaller, chips available but I don't know if they've got the right peripherals on the correct pins for our purposes.

Instead, I looked at the device replaced with my VanSpoof, the e-shifter itself!

Taking the shell apart reveals a series of gears driven by a motor. Taking out the gearset shows the PCB within the e-shifter. It's a pretty convoluted shape, with cutouts for the gears' bearings and it has been heatstaked in place, so a 1:1 replacement is off the cards. Removing the motor leaves a mostly rectangular area which could give us enough space to fit all our components.

Due to the awkward position of the space and the surrounding case, taking direct measurements with my callipers proved tricky. Its jaws weren't quite long enough to prevent the body from fouling on the case. This is when I returned to one of my favourite low tech prototyping methods. 1:1 scale models from paper, card, or board! Using some thin MDF sheets I recovered from old picture frame backings, I cut and trimmed a piece until it was a snug fit in the space.

I could then pop that piece back out of the space and measure it instead.

Measurements of 31.45 mm reducing to 27.45 mm were taken for the width of the cavity.

The depth of the space was found to be 21.55 mm reducing to 18.20 mm.

Transferring these measurements to KiCAD let me throw together a quick design to see if all of the components are likely to fit. I still need to work out if everything is routable within these new constraints, but my early tests are hopeful.

I believe the incoming cable, with Orange, Black, Brown and White wires, is terminated with a JST-SH connector. This hopefully means that I can use a JST-SR header, probably a BM04B-SRSS-TB, and make the VanSpoof a drop-in replacement part for X3 and S3 owners.

GNU Terry Pratchett

2025-03-12T13:37:00+00:00

This post is a break from the technical show-and-tell theme I've adopted of late and is much more personal. Please feel free to skip if that's likely to bug you.

Today marks ten years since the passing of Terry Pratchett.

I grew up with his work; the first Discworld novel was published when I was just 3 months old. I spent my adolescence reading his books, playing the video games, and wishing that Sky TV and the BBC did something more with their adaptations than just throwing large sums of money at the casting directors.

I now find myself parenting a two-year-old with an insatiable appetite for books. We obviously get through our fair share of classics like The Gruffalo and We're Going on a Bear Hunt, but none of them make me smile like being asked for "daddy's book" at bedtime. The 20 minutes spent reading from our latest Anhk-Morporkian adventure as the little one drifts off are the best 20 minutes of my day.

In honour of the impact he's had on my life, I have joined the ranks of similarly nerdy sysadmins and enabled the x-clacks-overhead header on all of my websites and services. GNU Terry Pratchett.

For those not in the know about clacks and GNU, daggerdragon has written this explanation on gnuterrypratchett.com.

In Terry Pratchett's Discworld series, the clacks are a series of semaphore towers loosely based on the concept of the telegraph. Invented by an artificer named Robert Dearheart, the towers could send messages "at the speed of light" using standardized codes. Three of these codes are of particular import:

G: send the message on

N: do not log the message

U: turn the message around at the end of the line and send it back again

When Dearheart's son John died due to an accident while working on a clacks tower, Dearheart inserted John's name into the overhead of the clacks with a "GNU" in front of it as a way to memorialize his son forever (or for at least as long as the clacks are standing.)

If you want to spot other sites out there using the clacks to honour Terry's legacy, there are extensions for both Firefox and Chromium based browsers that pick up the header and flash the message in their icon.

VanSpoof – A-Muntzing We Will Go

2025-03-05T13:37:00+00:00

With my first few VanSpoof prototypes assembled and the firmware coming together nicely, I realised it was time to start working on the second and hopefully final version of the board.

I had noticed that the L78L05, responsible for providing 5 V for the microcontroller's LDO and the USART pull-up resistor, was sometimes getting a little hot.

The initial version of the VanSpoof circuit was my first time designing with SMD parts, so I included a bunch of extra LEDs to prove that each stage of the power supply and the microcontroller were working. According to my power supply, at 24 V my circuit is drawing 27 mA and the L78L05 handles about 19 of those 24 V. That's about 0.6 W being dropped by the regulator.

The resistor in this slow-motion video is burning 0.5 W, almost equivalent to the L78L05's load, and provides more than enough heat to flash boil IPA on contact.

I was intrigued by how much of that current draw was being consumed by my 3 status LEDs and how much was actually being used by the microcontroller to talk to the USART pins. Instead of knuckling down and calculating the values, I turned to the tried and tested method of Muntzing. Unlike the eponymous Mr. Muntz, I didn't physically cut parts out of an existing circuit; I used one of the spare boards I'd ordered from OSH Park, including only the bare minimum of components needed to get the board to boot.

Leaving off those three LEDs and their accompanying resistors dropped the current draw to a maximum of 6 mA. The L78L05 now only has to burn off 0.1 W. It is even running cool enough I don't think I'll need to redesign the power supply circuit for the final version.

In my final design, I also won't be including a physical push button to reset the board, so I removed the whole "External reset circuit" detailed on page 66 of the STM32G030x6/x8 datasheet. The datasheet claims "the reset network protects the device against parasitic resets". I've no formal training in electronics, so I have no idea what that really means or how often you could expect the device to undergo a "parasitic reset". It turns out that my office has the perfect conditions to place an STM32 in to parasitic reset, so every time I booted the board without a debugger connected, it would reset. Adding the NRST capacitor back allowed the board to function properly once more.

Another problem I identified with the first prototype was the pretty slow rise-time on the USART TX signal. Every transition from 0 to 5 V happened with a definite "charging capacitor" shaped curve.

In my original design I used a 62 kΩ resistor as my 5 V pull up, which I picked out of an abundance of caution. The IO pins on these 3.3 V STM32 chips are only 5 V "tolerant", so I didn't want to push too much current through the pin.

According to the datasheet, the chip's internal pull-up resistor has a typical value of 40 kΩ. Using 3.3 V as the supply means that STMicroelectronics would typically push and pull just 82.5 μA through the pin. Being naive, I tried to maintain that low current with my higher 5 V USART signal by staying as close to 60.6 kΩ as I could.

A closer read of the datasheet reveals the IO pins can actually sink and source 15 mA. To quickly assess the response of the board to a lower pull-up value, I stacked three of my 62 kΩ resistors in parallel for an equivalent resistance of approximately 20 kΩ.

The USART signal's rise-time with this configuration is much better. The new 240 μA current is still two orders of magnitude away from the chip's limits, too.

With these changes tested, I'm much happier designing a new version of the board and sending it off for manufacture.

Simplify VCD

2025-02-28T13:37:00+00:00

Simplify VCD is a command-line tool designed to make working with Value Change Dump (VCD) files more efficient and faster.

VCD files can quickly become large and unwieldy, making analysis and processing slow and cumbersome. This tool enables users to clip sections of VCD files, trim irrelevant data, and reduce the resolution to a more manageable timescale, significantly improving processing speed and usability.

It started out as a simple script to convert the analyzer captures from my Glasgow Digital Interface Explorer down to the micro-second scale to speed up analysing them with Sigrok & Pulseview, but it grew arms and legs until it became what you see here.

It's distributed via PyPI, so installing it is just a pip install simplify-vcd away! The code is available from my Codeberg repository. It's free software so you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

I can't vouch it will play nicely with the VCDs produced by your favorite tool, but it's managed fine with the captures I've made with my Glasgow.

Pull Requests to support other, more complicated, VCD files are welcome!

VanSpoof - Prototype 2 - Echo Firmware

2025-02-17T13:37:00+00:00

In part 1 and part 2 of building my first VanSpoof prototype, I managed to flash the microcontroller on the PCB with a blinky demo. This time round, let's see about sending and receiving some serial data.

In this prototype, we'll read every byte that comes in to our USART, then echo it straight back out. We can adjust our code's forever loop to wait until it's read() a byte from the USART, then write!() it out again.

    // Forever more...
    loop {
        // Read a byte from the USART, waiting until we've got one.
        let byte = block!(usart.read()).expect("Failed to read from USART2.");
        // Write it straight back out again.
        write!(usart, "{}", byte).expect("Failed to write to USART2.");
    }

If we hook up a Glasgow Digital Interface Explorer to our PCB's RX & TX pins, we can send our laptop's key-presses to the VanSpoof and see what we get back. Typing the traditional "Hello, world!" message gives us the following output.

That's not exactly what I was expecting to see. Those are the ASCII character codes for the letters in the string. To check there's nothing wrong with our firmware or how we've set up the Glasgow, we can run a small test program locally on my laptop.

    let hello_world_bytes:Vec<u8> = "Hello, world!".as_bytes().to_vec();
    for i in hello_world_bytes.iter() {
        print!("{}",i);
    }

That snippet of code shows the same behaviour as we observed with the VanSpoof and Glasgow combination.

A stream of bytes, sent via write!() or print!(), appear as the string-ified representation of their ASCII codes. I think this is because I've only minimally changed our blinky code, and we're still getting our write! macro from the core::fmt::Write trait. Its documentation describes it as,

A trait for writing or formatting into Unicode-accepting buffers or streams.

A u8 isn't actually a "byte of ASCII", but an 8-bit number, so it makes sense the formatter would shape it to fit and string-ify the value. The core::io::Write trait is probably more appropriate for us once we start moving to byte-streams such as Modbus frames. It's described as,

A trait for objects which are byte-oriented sinks.

Just now, casting the byte to a char before writing it out will do, but we will have to remember to come back to this later.

    // Forever more...
    loop {
        // Read a byte from the USART, waiting until we've got one.
        let byte = block!(usart.read()).expect("Failed to read from USART2.");
        // Write it straight back out again.
        write!(usart, "{}", byte as char).expect("Failed to write to USART2.");
    }

That small change gives us the correct output when we couple our PCB back up to the Glasgow.

If we pop a Spy! Break! Inject! between the Glasgow and the VanSpoof, we can hook up our oscilloscope probes and see the byte and its echo being transmitted.

We can even use this to see the difference between 'A' (0b01000001) and 'a' (0b01100001).

The surpising thing is that the bytes are in the opposite direction to what I'd expect to see - the extra bit to shift to lower-case is towards the end of the bitstreams rather than the start. It turns out this because we normally visualise binary numbers MSB first, but USARTs send and receive LSB first.

Most serial communications designs send the data bits within each byte least significant bit first.

Now I've proven we can send and receive data over our USART pins, it's time to knuckle down and code up a Modbus frame assembly routine. We can then try to understand and respond to the bike's Modbus messages.

VanSpoof - Prototype 1 - Firmware

2025-02-14T13:37:00+00:00

Last time, we built a prototype PCB. This time, let’s take it to blinky!

All the code in this post, and the extra project files needed to build and flash it, can be found under the prototype-1 tag on my Codeberg repo.

The first thing we need to do is set up our environment. Since this is a firmware project, rather than software, we need to be a bit stricter with how we write our code. We want to prevent ourselves from doing unsafe things, and we need to tell the compiler that we’re running on a microprocessor without a traditional main function or a full standard library. We also want to allow an (incorrectly flagged) unused import as this is how we import our panic handler during debugging.

#![deny(warnings)]
#![deny(unsafe_code)]
#![no_main]
#![no_std]
#![allow(unused_imports)]

We import a number of crates here, the most important being our STM32’s HAL. We’re using a low level HAL, specific to our chip, to prevent us from trying to use features or peripherals that aren’t present on the physical device but might be on others in the range.

// Gives us access to our hardware features; timers, gpios, usarts, etc.
use stm32g0xx_hal::{
    stm32,
    prelude::*,
    serial::{BasicConfig, StopBits},
    time::{Bps, MicroSecond}
};

// Punt Unicode strings out over the usart.
use core::fmt::Write;

// We need to block on our timer `wait`s, so that we actually "wait" for them.
use nb::block;

// Use RTT for debug messaging, including panics.
use panic_rtt_target as _;
use rtt_target::{rprintln, rtt_init_print};

// `main` is our entry point.
use cortex_m_rt::entry;

Next, we need to get our code up and running and start accessing our chip’s peripherals.

#[entry]
fn main() -> ! {
    // Initialize our debugger, all our potential panics go through it.
    rtt_init_print!();

    // Grab and set up the chip's peripherals.
    let stm_dp = stm32::Peripherals::take().expect("Cannot take STM32 Peripherals.");
    let mut rcc = stm_dp.RCC.constrain();

We can then go on to configure the GPIO pins to reflect our PCB design. In particular, we need to set our TX pin to Open Drain Output mode, using our external resistor, R3, to pull up the line to 5v.

The RX pin needs to be configured to match a similar arrangement on the bike, so we set it up as a Pull-up Input. Our 3.3v STM32 is 5v tolerant, we can get away with using the internal pull-up resistor without any level shifting or further configuration.

    // Grab GPIO A since that's where our USART and LED are.
    let gpioa = stm_dp.GPIOA.split(&mut rcc);

    // Set up the pins to match the circuit board.
    let mut user_led = gpioa.pa11.into_push_pull_output();
    let tx_pin = gpioa.pa2.into_open_drain_output();
    let rx_pin = gpioa.pa3.into_pull_up_input();

With our pins configured correctly, we can move on and set up our peripherals. We identified during reverse-engineering that the signal was 9600 8-N-1, so we can set up our USART to match. A timer is started running, triggering itself every 1/4 of a second.

    // Build our usart, 9600 8-N-1 on USART2 pins.
    let mut usart = stm_dp
        .USART2
        .usart(
            (tx_pin, rx_pin),
            BasicConfig::default()
                .baudrate(Bps(9_600))
                .wordlength_8()
                .parity_none()
                .stopbits(StopBits::STOP1),
            &mut rcc,
        )
        .expect("Failed to initialize USART2.");

    // Use TIMER17 as our Blinky, triggering every 1/4 second.
    let mut timer = stm_dp.TIM17.timer(&mut rcc);
    timer.start(MicroSecond::micros(250_000));

Now we’ve brought up all of our peripherals, we can let the debugger know we’re ready to go.

    // Show the debugger-operator we're alive.
    rprintln!("Hello, world!");

In an infinite, loop 4 times a second, we turn on the LED, write a message to the USART, then turn the LED off again.

    // Forever more...
    loop {
        // Flash the LED while we send our message out of the USART.
        user_led.set_high().ok();
        writeln!(usart, "Blink!\n").expect("Failed to write to USART2.");
        user_led.set_low().ok();

        // Wait for the timer before we go again.
        block!(timer.wait()).ok();
    }

It turns out that it takes so little time to send "Blink!" at 9600 baud that the light flash is barely visible to the naked eye. The following video has been captured at a high frame-rate and played back at 1/8 speed.

Hooking up a signal analyser like a Glasgow Digital Interface Explorer lets us see the "Blink!" messages scrolling past.

VanSpoof - Prototype 1 - Hardware

2025-02-08T13:37:00+00:00

Let's look at building a prototype PCB for my VanSpoof project.

In my first post on reverse engineering the VanMoof e-shifter, I confirmed there was a 24v power supply from the bike to the e-shifter. In the latest reversing post, I determined that the communication is Modbus RTU with its USART lines pulled up to 5v. That won't let me write a fully-featured firmware, but it's more than enough information to let me design a prototype PCB.

I've a few goals I'd like to hit while building this prototype. I really want to get better at soldering SMD components, so I'm going to try to use as few through-hole parts as I can get away with. I'm also interested in designing a board that can be ordered directly from the online PCBA houses, so other folks in need can get their hands on them.

If you've been following this blog for a while, you'd probably be able to guess that I'm looking to use an STM32 as the brains of the spoofer. The catchily named STM32G030F6P6 is a perfect match for my needs. The 20 pin TSSOP footprint is just about hand solderable whilst still providing easy access to each of the peripherals I'll need.

To get everything up and running, the first things to sort out are the power supply subsystems. The 24v supply from the bike needs to be brought down to 5v for the serial pull-ups. A simple linear voltage regulator is good enough for the first round of prototyping. This board is more likely to be running on my workbench than on the bike, so I can simply dial back the input voltage to keep heat dissipation down.

The bike is stored in an outdoor shed all year round, so having parts that are rated to perform at subzero temperatures would be essential to protect the board against those cold winter nights.

A SOT-89 package device is perfect since it's small enough to keep the board size to a minimum while still being hand solder-able. STMicroelectronics have a chip, the L78L05ABUTR, which meets these criteria.

To provide 3.3v from the incoming 5v, a low dropout regulator will be fine. If I can find something that's pin compatible with the 5v regulator, that should keep my board layout coherent. ST's LD2981ABU33TR fits the bill nicely.

Since the boards will be hand soldered during prototyping, adding status LEDs to the regulator outputs will let me check everything's working as I'd expect.

My STM32 Discovery board has an on-board ST-Link which I'll use for programming, so I'll add a matching set of pin headers to my prototype. I'll also include a push-button to reset the microcontroller, just in case I manage to get the firmware in such a state during development that it can't recover itself.

To confirm I've soldered everything together correctly and managed to successfully program the chip, I'll hang an LED off the GPIO for a "blinky" status.

The final physical consideration is for strain relief on the four wires coming in from the bike. The WIGO catalogue specifies the wires attached to the shifter's connector as 30AWG so they'll need careful handling when they're hanging off the side of a bike at 25 kph. A few loops to take up the slack in the wire should keep the solder joint safe.

The full schematic and board layout can be found under the prototype-1 tag on my Codeberg repo and is released under the terms of the CERN Open Hardware Licence Version 2 - Strongly Reciprocal.

Next Trains

2025-01-25T13:37:00+00:00

Last week, I built a small web app to show the next few trains that are scheduled to arrive at or depart from my local railway station.

My two-year-old daughter loves trains, and since the station's in the city centre, next to all the shops, any time we can combine running errands with some playtime is well worth it. Having an at-a-glance view of all the trains soon to be at the station lets me plan when we should leave the house, or finish our shopping, so we can see a few trains come and go.

The app is up and running and available at next-trains.mikecoats.xyz. The application is free software so you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. The code is available from my Codeberg repository.

When I built my last silly web project, Poison the WeLLMs, I got half-way to publishing it as a PyPI package, moving the dependencies and scripts over to a pyproject.toml file, but I never actually finished the job. Prompted by Stefan on Mastodon and their blog post, "I published my first package to PyPi", I bit the bullet, got stuck in and published the app as my first PyPI package.

I fully expect no-one but me will ever install it, but packaging the app makes it much easier for me to install onto my server.

Reverse Engineering a VanMoof e-shifter – Part 2 – Decoding the Signals

2025-01-15T13:37:00+00:00

At the end of the last post, I left everyone hanging, having tapped into and sniffed some data being transferred on the wires between the bike and the e-shifter. The questions to answer were:

Is the bike the requester, or is it the responder?

What speed and format was that data?

What messages are being transmitted?

The reliability of this e-shifter in the X3 and S3 has been argued as the cause of the failure and eventual bankruptcy of VanMoof. If I can decode these messages, I have the opportunity to build a replacement module that could spoof the original e-shifter.

This component fails and has failed for many owners, and historically this failure occurred during the bike's warranty period. It's been suggested that VanMoof provided so many replacements that they used up their entire stock and were unable to make or sell any more bikes. We've had the e-shifter fail and be replaced twice on our bike since owning it. I really need to come up with a solution before it fails again.

Now, on to the reverse engineering!

Is the bike the requester, or is it the responder?

On the oscilloscope, we could see that a request appears to be sent on one wire and a response is received on the other.

By removing jumpers from the data lines on the Spy! Break! Inject! we can determine which side asks the question and which side responds.

Here we see that the bike's responsible for asking the questions and, with no signals being received by the e-shifter, no responses are generated and transmitted.

What speed and format was that data?

Using the right-angle pin headers on the Spy! Break! Inject!, we can hook up a logic analyser like a Glasgow Digital Interface Explorer.

With the Glasgow in place, we can capture the data being sent between the bike and the e-shifter. That capture can be opened in GTKWave for visualisation and measurement-taking.

Zooming in on the stream of data allows us to identify individual packets.

Zooming in further, we can see individual bits in the data stream. The on-transition of this bit is a little noisy, but we can still use it as the basis of our timing calculations.

The total time from the first spike of the bit turning on until it turned off again was 104,187 nanoseconds. Inverting that period to a baud rate gives us 9598.13, or as damn near as 9600 bps as we'd expect to find. Zooming back out again, we can see the question packet lasts 8,380,458 ns and the response packet is 7,279,542 ns long. Taking a bit as ~104,000 nanoseconds, that means a question packet is ~80 bits long and the answer packet is ~70 bits.

Assuming both of our question and answer packets use the same framing, the greatest common factor of 70 and 80 is 10, meaning our question is likely made up of 8 bytes, each 10 bits long, and our answer is 7 of these 10-bit bytes. 10-bit bytes seem silly until you think about serial UART framing. Commonly, UART frames will begin with a start bit, then all the data bits, then an optional parity bit and between 1 and 2 stop bits. One of the most common UART framing is 8-N-1, or 8 bits of data, no parity bits, 1 stop bit. Taken with the mandatory start bit, you get to 10-bits transmitted per byte, confirming 8 bytes for our question and 7 bytes for our answer.

What messages are being transmitted?

Guessing that our data is in 9600-8-N-1 format, we can use PulseView to decode the captured signals in to the bytes transmitted.

The request packet is decoded to 0x20, 0x03, 0x00, 0x01, 0x00, 0x01, 0xD3, 0x7B and the response is decoded as 0x20, 0x03, 0x02, 0x02, 0x00, 0x05, 0x23. Any time I see bytes repeated at the start of several packets, it sets off my spidey-senses that we're looking at common headers or addressing information. Similarly, a series of "low" or "small" bytes such as 0x00 and 0x01 followed by some unusually high values like 0xD3 or 0x23 screams out "checksum" to me.

Searching the web for "16-bit checksum" and "16-bit CRC" led me to the CRC Calc website. Dumping the first 6 bytes of the request packet in to their form and selecting CRC-16, gave a list of possible checksums. Searching within the results table for D3 and 7B highlighted the CRC-16/MODBUS row, although it presented the bytes as 0x7BD3 as opposed to 0xD37B which we expected based on what we saw within PulseView.

Now we think we're probably dealing with Modbus, we can do some research and try to understand the rest of the "conversation". Wikipedia has an article on Modbus including a section on Modbus RTU, which appears to match the data we're seeing. According to that page, the checksum is transmitted least-significant byte first which means the CRC Calc site was correct, 0x7BD3 is the checksum, but it is transmitted as D3 followed by 7B.

PulseView can be leaned on again to interpret the Modbus packets and reveal their contents.

This conversation appears to show a controller asking a peripheral device with ID 32 (0x20) a question, and a peripheral device with ID 32 sending an answer. Digging in to the question packet, we can see more details.

The question appears to be to "read a register", starting at address 0x0001, reading 0x0001 units of data. We can also look more closely at the answer.

Here, we can see a response indicating that our peripheral device has read a register, returning 2 bytes of data, 0x0200 or 512.

What is in register 0x0001 and what does a value of 0x0200 mean? Who knows?! Do we even need to understand the communications, or will rote repetition of prerecorded packets be enough to fool the bike?

In my next blog post, I'll detail a small project that can log an entire bike ride's worth of communication. Hopefully we can attempt to analyse the messages, or we can at least learn to spoof the correct responses to the bike's requests.

Reverse Engineering a VanMoof e-shifter – Part 1 – Connectors and Connections

2024-12-15T13:37:00+00:00

Anyone who's followed this blog for a while will know that we own a VanMoof e-bike, and we have a love/hate relationship with it due to its reliability. The most common and dreaded complaint for VanMoof owners is "Err 44". Error code 44 on a VanMoof X3 or S3 means that the bike cannot communicate with the e-shifter and gear shifting will not be available.

VanMoof really tried to be the "Apple" of e-bikes, and their e-shifter is part of that. Instead of producing a single-speed bike with no gears or a traditional manually shifted bike they built a bike with an automatic electronic gear shift. At certain speeds the bike will automatically shift gears, giving its rider more torque to get going from a stand-still or more speed once the bike was moving along.

If I can reverse engineer the communications between the bike and the e-shifter, I should be able to build a replacement module that spoofs the original. The gears in the bike's Sturmey Archer hub can be manually, and semi-permanently, set if the broken e-shifter is removed from the bike. The e-assistance, up to 15.5mph from the electric motor, and the boost button, giving 100% motor power from a stand-still, means the bike is still perfectly usable if it's manually shifted in to 3rd gear. Whether broken or removed, the bike will complain that it cannot communicate with the e-shifter and present "Err 44" whenever the bike comes to a stop.

The e-shifter has a 4 pole, trapezoidal connector, in blue plastic, with the word Higo written on the side. Searching for Higo e-bike connectors returns results for the Chinese company HIGO who specialise in waterproof connectors and harness system. It seems they've partnered with A&C Solutions to act as their European distributor, running the higoconnector.com website. A PDF catalogue on the European site includes our connector on page 24 and the order code we need to buy some.

Calculating the codes Z409FM and Z409FG from the brochure, we can now search for those connectors and luckily find a German shop selling both the socket and the plug we need. Reinhard from e-bike-technologies was excellent, arranging the international shipment on the same day, and my delivery arrived within 4 days.

With the new connectors in hand, it's possible to connect them to a Spy! Break! Inject! and use a multimeter to test for continuity. We can therefore determine how the pin numbering of the connectors matches up to the 4 coloured wires within the cable.

Pin Number	Wire Colour
1	Black
2	Yellow
3	Blue
4	Red

Now we've wired a Higo plug and socket to a Spy! Break! Inject!, we can insert our assembly in-line with the bike and e-shifter. Powering up the bike and probing between the test points on the Spy! Break! Inject! lets us explore the voltages available between the wires.

Wire	Voltage
Black	0v
Yellow	24v
Blue	5v
Red	5v

At first glance, finding 24v on the yellow wire is surprising. On reflection, the e-shifter is "mechatronic", so having the extra power available makes sense. A higher voltage would make it easier for the motor to physically shift gears. Having two 5v lines is interesting. These could be VCC and some bidirectional data for the microcontroller, or it could be the TX and RX lines for communication.

Clipping an oscilloscope to the two 5v lines reveals data on both, apparently in a request and response pattern.

Is the bike the requester, or it is it the responder? What speed and format is that data? What messages are they transmitting? All these questions and more, answered next time!

Introducing Spy! Break! Inject!

2024-12-11T13:37:00+00:00

Spy! Break! Inject! is a 4-wire Monster-in-the-Middle circuit. Inserting this board inline with any 4-wire bus lets you spy on, break into and inject signals. It's a purpose-built breadboard for reverse engineers.

The Würth terminal blocks have specifically been chosen to support wires down to 30 AWG for working with the smaller conductors commonly found in multicore communication cables. Right-angle pins and straight sockets allow connecting DuPont style jumper wires to other components such as microcontrollers or signal analysers. A row of test points along the bottom of the board support the spring-loaded hooks typically found on oscilloscope probes. All these connections are routed through a bank of jumper headers, allowing the paths to be broken and signals routed off-board.

Multi-meter probes can be connected across the rails to measure voltages. Current draw for a component can be measured by removing the jumper from the VCC rail and clipping an ammeter in line.

Removing jumpers and connecting wires to the pin headers allows signals to be routed away to a microcontroller for logging, relaying, proxying and modification.

Spy! Break! Inject! is released under the terms of the CERN Open Hardware Licence Version 2 - Strongly Reciprocal. The project files, including KiCAD schematics and PCB designs are available from my Codeberg repository. It has been certified as open source hardware by the Open Source Hardware Association.

Make Cisco Catalyst 2960-X switches run almost silently

2024-12-05T13:37:00+00:00

Cisco Catalyst 2960-X switches are now over a decade old and have been discontinued for over two years. As a result, companies are getting twitchy and have started to replace these switches, even though they still work and are still supported until 2027.

On eBay, you can find 48-port PoE switches with stack connectors and either four SFP or two SFP+ uplink ports for under £100. This seems like a great deal until you unbox them and power them up to get them configured.

Problem

The 2960-X has a single 12v blower fan to remove heat from the case and it screams. It's unbelievably loud both during startup and once it gets hot. Even during normal operation it's still unreasonably loud for most homes.

Like all those second-hand 1U servers on eBay that seem too good value to be true, these switches aren't really suitable for use anywhere outside the server room or data centre either. You really need to do something about the noise before you can use them in the home. Folks over on Reddit have done some work on this and identified a couple of options.

Solution 1 - Disconnect internal blower fan

There are several small screws around the case that when removed allow access to the switch's innards. The blower fan is very obvious, as is its power connector. Pop it off, then reassemble the switch.

Powering it back on, you'll find it doesn't really care if its fan has been disconnected.

cisco-switch#show env fan
FAN is OK

It also reckons its internal temperature is fine, even with no airflow through the case.

cisco-switch#show env temperature 
SYSTEM TEMPERATURE is OK

However, these statuses hide the real truth - the temperatures inside the switch are rising! They're getting quite high and they're getting there quickly. With just three of the 48 ports providing PoE to the WAPs in my house, the temperatures are almost up to the Red level and well beyond the comfortable ranges in Cisco's documentation.

cisco-switch#show power inline | include on
Gi2/0/8   auto   on         15.4    Ieee PD             4     30.0 
Gi2/0/45  auto   on         15.4    Ieee PD             0     30.0 
Gi2/0/47  auto   on         15.4    Ieee PD             0     30.0 
cisco-switch#show env all         
FAN is OK
SYSTEM TEMPERATURE is OK
System Temperature Value: 64 Degree Celsius
System Temperature State: YELLOW
Yellow Threshold : 58 Degree Celsius
Red Threshold    : 68 Degree Celsius![...]

To be fair to the switch, it's been installed in the top position in my mini rack, in the cupboard under my stairs. The rack runs double duty as the stand for my laser printer, so it's just about the hottest place in my whole house that I could have installed it, exacerbated by the complete lack of natural airflow.

Solution 2 - Replace internal blower fan

Noctua make a 40mm fan, the catch-ily named NF-A4x20-PWM, that fits neatly in a 1U chassis and can even have its speed controlled by the Cisco's PWM circuit. The folks over on Reddit designed a custom bracket, but with my lack of a 3D printer and a love of the "hack", I decided that hot-gluing a couple of fans in place would do the trick.

You'll need to do some clever jiggery-pokery with the cables and the connectors if you want variable speed control for the fans as the pins don't line up in the right spacing or order. In my own testing though, I couldn't see a big enough difference in noise by letting them spin down a bit. As a result I went with the easy option, snip the connector!

Noctua fans come with an Omni Join connector that allows you to reuse the Cisco fan connector, turning it in to a Noctua fan socket.

Also included in the Noctua box is a Y-Cable that lets you run two fans from a single header.

With that in place we can now install our pair of 40mm fans. I'll save you the gory details of my hot-glue job, but the gist of it is that the lip where the blower fan exhausted it's warm air is almost a friction fit for our two fans, so just plug them in, hold them in place and secure them with a few blobs of hot glue.

The switch still doesn't care that we've been monkeying around with its fans.

cisco-switch#show env fan         
FAN is OK

cisco-switch#show env temp        
SYSTEM TEMPERATURE is OK

However, checking for all the readings, we see a big difference.

cisco-switch#show env all         
FAN is OK
SYSTEM TEMPERATURE is OK
System Temperature Value: 51 Degree Celsius
System Temperature State: GREEN
Yellow Threshold : 58 Degree Celsius
Red Threshold    : 68 Degree Celsius

A 13 Degree Celsius reduction in temperature from adding two small, almost silent, fans. The switch is now quiet enough that it fades away behind the normal background noise of the house like the hum of our central heating pump or the occasional laptop fan whirring to life.

Comments

Wouter on 2024-12-06 wrote:

I installed A dc/dc converter from one dollar between the power of the fan. Works also fine.

Leaving WordPress for Zola

2024-12-03T13:37:00+00:00

I've used WordPress to run this website for the last 4 years. I first hosted it with Laughing Squid, who resell Pressable's service and then for the last year or so I've hosted with Mythic Beasts, who run their own servers. I've enjoyed using WordPress as a piece of software; it does the job well. Without it, I'd never have blogged so often or on the range of topics I have done to date.

Recent actions by Automattic and Matt Mullenweg have showed they are no longer the benevolent stewards they once pitched themselves as and, unfortunately, I feel I have to move off their platform. Realistically, this blog only ever used 1% of the capacity or capability of WordPress, and very little of the content could be considered "dynamic", so a static site generator is more than adequate for my needs.

Like every dev out there, I've prototyped and half built several SSGs over the years, but that has always led to more time being spent on the software and less time actually blogging. Instead, this time I've just selected a piece of software that matches up with my "head view" of the structure of the site and have chosen Zola. I can't vouch for it's long term usability, but I've managed to convert all of my WordPress posts to markdown files, wrapped them up in a git repo on Codeberg, and slapped a few templates together and managed to get a working site out of the other end. I'm still hosting with Mythic Beasts, but instead of their hosted WordPress service, I'm renting a virtual server and serving the static files with Caddy.

Caveats

There are two problems with the migration. The first is that there was a misconfiguration in my old WordPress site that despite naming posts with fixed slugs like poison-the-wellms, WordPress still knew those posts by its own internal naming scheme like ?p=1023. This was invisible everywhere except for the unique ID within the RSS and Atom feeds, so unfortunately anyone who was subscribed to my blog before the migration has just seen all of my old posts pop up again as if they were brand new. My apologies.

The second problem is one of accepting comments. WordPress runs on PHP, so providing interactivity such as comment submission is practically automatic. Static sites, though, can't do that. I very rarely receive comments, but I didn't want to remove them entirely from the site. Somehow, I must score quite highly on the SEO front when it comes to failing VanMoof batteries. Both of my VanMoof reverse engineering and repairing posts have received a fair few comments and I like to believe I've helped a few people get their rather expensive bikes back on the road.

I spent an afternoon investigating ways of adding comments, either via JavaScript plugins or through some sort of social network embedding, but in the end I realised I could just accept emails and then update the pages manually. My workflow on WordPress was to manually approve comments once I received an email notification, all I've done is add a copy & paste step in the middle. To this end, I've added mailto links at the bottom of every page, that go to a stand-alone email address and mailbox for collecting comments.

I've still some styles to tweak and pages to wrangle, but I feel it's better to just get the new site up and running and fix the remaining problems later. Perfect is the enemy of good, and all that!

Debian Packaging from First Principles – Part 2 – Dependencies

2024-09-24T13:37:00+00:00

Following on from my first blog post in this series, today I’m looking at dependencies within .deb files. As with part 1, all of the source code files for these packages are available from my project’s repository.

Impossible Dependencies

First of all, we’ll build an un-installable package with impossible to resolve dependencies. The libreoffice Debian package is composed of a number individual packages such as libreoffice-writer, libreoffice-calc, and libreoffice-impress. Imagine if Microsoft fully embraced their open-source ambitions; we could one day see microsoftoffice-word, microsoftoffice-excel and microsoftoffice-powerpoint. Until then, the following package will remain impossible to install.

Package: dpfp-impossibledependencies
Version: 0.1.0-1
Architecture: all
Description: An effectively empty deb file with impossible to resolve dependencies, manually assembled to understand Debian packaging.
Maintainer: Mike Coats <i.am@mikecoats.com>
Depends: microsoftoffice-word, microsoftoffice-excel, microsoftoffice-powerpoint, microsoftoffice-outlook

Since we’re not going to be able to install any files, anyway, the impossible package can be empty by including a blank tar file. This can be accomplished by passing the --files-from /dev/null argument to the tar command within the Makefile.

Attempting to install that file will return an error for each package that dpkg is unable to find.

$ sudo dpkg -i ./dpfp-impossibledependencies_0.1.0-1_all.deb
Selecting previously unselected package dpfp-impossibledependencies.
(Reading database ... 160683 files and directories currently installed.)
Preparing to unpack .../dpfp-impossibledependencies_0.1.0-1_all.deb ...
Unpacking dpfp-impossibledependencies (0.1.0-1) ...
dpkg: dependency problems prevent configuration of dpfp-impossibledependencies:
 dpfp-impossibledependencies depends on microsoftoffice-word; however:
  Package microsoftoffice-word is not installed.
 dpfp-impossibledependencies depends on microsoftoffice-excel; however:
  Package microsoftoffice-excel is not installed.
 dpfp-impossibledependencies depends on microsoftoffice-powerpoint; however:
  Package microsoftoffice-powerpoint is not installed.
 dpfp-impossibledependencies depends on microsoftoffice-outlook; however:
  Package microsoftoffice-outlook is not installed.

dpkg: error processing package dpfp-impossibledependencies (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 dpfp-impossibledependencies

Plain Dependency

A more rational example is one that depends on the single, already installed, package we created last time. To do so, our depends line becomes much simpler this time, just the name of the simple, no-dependency, package.

Package: dpfp-plaindependency
Version: 0.1.0-1
Architecture: all
Description: A bare-minimum deb file with a simple dependency, manually assembled to understand Debian packaging.
Maintainer: Mike Coats <i.am@mikecoats.com>
Depends: dpfp-simple

To prove that this package really does depend on dpfp-simple we’ll add a symbolic link in our new package that refers to the file installed in the first package.

$ ls -l data/opt/debian-packaging-first-principles/plain-dependency
total 8
-rw-r--r-- 1 mike mike 77 Jul 12 12:50 dpfp-plain-dependency-success.txt
lrwxrwxrwx 1 mike mike 69 Jul 12 12:49 dpfp-simple-success.txt -> /opt/debian-packaging-first-principles/simple/dpfp-simple-success.txt

Unlike the impossible example, installing this package goes smoothly and inspecting the installed files will show the text file and symbolic link side by side.

$ sudo dpkg -i ./dpfp-plaindependency_0.1.0-1_all.deb
Selecting previously unselected package dpfp-plaindependency.
(Reading database ... 160683 files and directories currently installed.)
Preparing to unpack .../dpfp-plaindependency_0.1.0-1_all.deb ...
Unpacking dpfp-plaindependency (0.1.0-1) ...
Setting up dpfp-plaindependency (0.1.0-1) ...

Listing the files and their contents will show that we’re pulling in the file from the first, pre-installed, package too.

$ ls -l /opt/debian-packaging-first-principles/plain-dependency/
total 8
-rw-r--r-- 1 root root 77 Jul 12 12:50 dpfp-plain-dependency-success.txt
lrwxrwxrwx 1 root root 69 Jul 12 12:49 dpfp-simple-success.txt -> /opt/debian-packaging-first-principles/simple/dpfp-simple-success.txt

$ cat /opt/debian-packaging-first-principles/plain-dependency/dpfp-*.txt
Debian Packaging from First Principles
    Plain Dependency
        Success!
Debian Packaging from First Principles
    Simple
        Success!

Mutual Dependencies

Until now all of our dependencies have formed a simple tree, but now we’re going to build a pair of packages that depend on each other. One will not be able to be installed without the other.

We will first create an “a” package that depends on our “b” package.

Package: dpfp-mutualdependency-a
[...]
Depends: dpfp-mutualdependency-b

We will then create the counterpart “b” package that will depend on our first “a” package.

Package: dpfp-mutualdependency-b
[...]
Depends: dpfp-mutualdependency-a

Attempting to install only one of the mutually dependent packages will fail, referencing the other half of the pair.

$ sudo dpkg -i dpfp-mutualdependency-a_0.1.0-1_all.deb
[...]
dpkg: dependency problems prevent configuration of dpfp-mutualdependency-a:
 dpfp-mutualdependency-a depends on dpfp-mutualdependency-b; however:
  Package dpfp-mutualdependency-b is not installed.
[...]
Errors were encountered while processing:
 dpfp-mutualdependency-a

Similarly, attempting to install only the second of the pair will return the same error.

$ sudo dpkg -i dpfp-mutualdependency-b_0.1.0-1_all.deb
[...]dpkg: dependency problems prevent configuration of dpfp-mutualdependency-b:
 dpfp-mutualdependency-b depends on dpfp-mutualdependency-a; however:
  Package dpfp-mutualdependency-a is not configured yet.
[...]
Errors were encountered while processing:
 dpfp-mutualdependency-b

Installing both packages of the mutual pair at the same time will complete successfully because dpkg can resolve the dependencies.

$ sudo dpkg -i dpfp-mutualdependency-a_0.1.0-1_all.deb dpfp-mutualdependency-b_0.1.0-1_all.deb
Selecting previously unselected package dpfp-mutualdependency-a.
(Reading database ... 160686 files and directories currently installed.)
Preparing to unpack dpfp-mutualdependency-a_0.1.0-1_all.deb ...
Unpacking dpfp-mutualdependency-a (0.1.0-1) over (0.1.0-1) ...
Selecting previously unselected package dpfp-mutualdependency-b.
Preparing to unpack dpfp-mutualdependency-b_0.1.0-1_all.deb ...
Unpacking dpfp-mutualdependency-b (0.1.0-1) over (0.1.0-1) ...
Setting up dpfp-mutualdependency-b (0.1.0-1) ...
Setting up dpfp-mutualdependency-a (0.1.0-1) ...

In the first post in this series I got to grip with how deb packages are put together and now in this second post I understand how they’re connected to each other. Next time, I’m going to look at repackaging an existing piece of software for an architecture it wasn’t originally published for, and then try to host it on my own “apt” repository.

Connecting to Serial Ports with Windows Terminal

2024-08-23T13:37:00+00:00

Windows Terminal is a killer app for Windows 10 & 11. With it you can launch Windows command interpreter, Powershell, bash, and WSL sessions. It is however missing the ability to connect to COM ports and serial connections.

If you’ve been a sysadmin on or with Windows long enough you’ve probably got PuTTY installed which will let you connect to serial consoles. Launching a whole other tool with different font & colour scheme settings, when Terminal should be able to do the job, seems silly to me. Luckily PuTTY bundles the plink tool which lets us connect to serial ports from the command line.

Speaking to the device at the other end of your serial port is as simple as passing the COM port as an argument, as long as your serial port’s default configuration matches the other device’s settings.

If you need to set some parameters such as a different baud rate these can be passed as arguments too but before we go too far and start adding a full plink session to our Windows Terminal configuration there’s an important note in the PuTTY documentation about plink.

Plink is probably not what you want if you want to run an interactive session in a console window.

This is true, but it probably won’t be obvious why until it suddenly becomes frustrating. It does not pass any of the “interactive” keystrokes in a console session, such as the up arrow to allow correcting mistyped commands.

Thankfully, Edward Wright wrote a nice tool, SimplySerial, that picks up where plink leaves off. Once installed, it can be launched much like plink, by running the ss command, passing the COM port as an argument.

The SimplySerial documentation includes a hint on how to add ss to Windows Terminal, but it’s default behaviour isn’t as clean as I’d like. I suggest adding the -nostatus flag to prevent the tab title from being renamed and the -quiet flag to suppress the large start-up banner.

With this configuration added to Windows Terminal, we can create a new tab with the COM5 profile.

This launches a nice, clean, serial session ready for you to configure your network switch or talk to your microcontroller.

Poison the WeLLMs

2024-08-12T13:37:00+00:00

It’s a little cheeky, but I’m really quite proud to announce the initial release of “Poison the WeLLMs”; a reverse-proxy that serves disassociated-press style re-imaginings of your upstream pages, poisoning any LLMs that scrape your content.

It does what?

It is a reverse-proxy. It sits between your visitors and your web-server and has the ability to modify requests and responses on-the-fly.

It produces disassociated-press style re-imaginings of your upstream pages. It reads the contents of your pages, splits the text into sentences, and then splits those sentences into word-pairs. It then randomly rebuilds the word-pairs into new sentences, arranging those sentences in to new paragraphs and returns the generated page to the visitor. These new, generated, pages have the look and feel of real text, but probably make little to no sense.

It poisons LLMs. In a recent paper, published in Nature, it was found that “indiscriminate use of model-generated content in training causes irreversible defects in the resulting models”. Deliberately feeding LLM scraper-bots pre-hallucinated text might reduce or remove the value gained from indiscriminately scanning websites and would potentially even degrade the performance of, or poison, the resulting models.

What does that look like?

Here’s an example of one of my blog posts and then what would be served up to any LLM bot that scrapes a poisoned copy.

This is another recent post and the equivalent page presented to LLM bots.

In both of these examples, all of the HTML tags are lost. Formatting, links and images are all stripped and just paragraphs of text are returned.

How does it work?

We grab the text content of the upstream pages, parse out each sentence on the page, then build a list of word-pairs that make up each sentence. We use None to signify the start and end of a sentence. Taking the simple sentence,

“this is the only sentence”,

we can split it into the following word-pairs.

If we treat these word-pairs like cons cells or tree nodes, we can build a graph that indicates the reading flow through the sentence.

Simplifying this by removing the duplicated information, we get the following, much more readable, graph.

Following the flow through the word-pairs we can see that “this is the only sentence” is the only sentence an algorithm could generate from this graph.

Creating another graph, this time based on a single sentence but with one word repeated in a couple of places,

“this is the sentence that might have the loop“,

we can see there are more options for the algorithm to follow.

In addition to the input text, “this is the sentence that might have the loop”, we can see that the algorithm could take a shortcut and skip the loop returning, “this is the loop”. It could also generate an infinite number of extended sentences by running round the loop several times before exiting, producing something like “this is the sentence that might have the sentence that might have the sentence that might have the sentence that might have the loop”.

If we feed the algorithm two sentences that share a single word,

“this is the only sentence” and

“only word that matters”,

we can see there are four paths through the graph.

The algorithm could therefore produce not only the two original input sentences, but two completely new ones, “only sentence” and “this is the only word that matters”.

Taking things further, here’s a graph built from an entire paragraph of one of my #NewMusicMonday posts.

With my tongue firmly lodged in my cheek, I like to refer to these graphs as little language models, or maybe wee language models depending on which side of the border you are.

See it in action

At the moment, I don’t have fully working copy running in front of my site, I’ve instead got it installed on my app server at https://poisoned.mikecoats.xyz. Since we only rewrite text not HTML, including a tags, you won’t be able to follow and of the links there, so instead here’s three pages that are being served through the reverse-proxy.

If you have a browser extension that lets you alter your user-agent, such as User-Agent Switcher and Manager for Firefox, visiting those links with an agent string like ClaudeBot or GPTBot should give you the hallucinated versions. A visit with your normal user-agent will give you the regular content. If you’re on a platform, or use a browser, where user-agent spoofing is not possible the following links will take you directly to the hallucinations.

There are still some rough edges around the text and sentence parsers that would improve the quality of the output, and I’ve spotted some server errors crop up from time to time, so it’s not finished but I think it’s good enough to show off.

The code is available from my git repository and it includes some quite terrible installation instructions if you want to play with it yourself. Right now I’ve only got configuration files that integrate with Caddy, but I’m looking in to Nginx and Apache versions too.

The application is free software so you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. The configuration files are released under the MIT License as they’re based on a JSON file from Cory Dransfeldt’s upstream ai.robots.txt repository.

aa-sms – Send messages from Rust with Andrews & Arnold’s SMS API

2024-07-31T13:37:00+00:00

I mentioned a few posts ago that I’d been learning a new programming language, and this post is the result of that work. I’m excited to announce the aa-sms library for sending SMS text messages from Rust with Andrews & Arnold’s APIs.

Before you can send messages using this library, you’ll need an account with Andrews and Arnold and be subscribed to their VoIP service with one or more phone numbers.

The library is available for installation from crates.io and can be added to your own Rust project with a simple cargo add aa-sms.

It’s built using the Builder pattern that seems common to Rust libraries and which I’ve previously known as a Fluent interface from my Java days. An example program using the library is included in the repository and can be launched by running cargo run --example send-library from the project’s root. Another example, this time using the reqwest library directly, is included for comparison and can be launched similarly, cargo run --example send-library.

This code is at a very early stage, and I’m still new to rust and it’s idioms. So, please use it but be aware it comes with a massive caveat emptor. If anyone has any recommendations or fancies doing a wee code review, all constructive criticism is well received. I’ve already got a number of improvements I hope to make soon.

The source code is available from it’s git repository and is released as free software under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

#NewMusicMonday – Kiasmos & Warrington-Runcorn New Town Development Plan

2024-07-29T13:37:00+00:00

This past week I spent a whole day scurrying about the server room at work, wiring up a full rack of switches, routers and site-to-site VPN devices. This coming week, I’ll be doing more of the same. A decent set of isolating, noise-cancelling, earbuds can do wonders to overcome the rushing whirr from rack after rack of servers and the throbbing rumble of air-conditioner units. Add some slick Electronica beats into the mix and you’re dropped right in to the zone.

This weeks #NewMusicMonday recommendations are the latest releases from Kiasmos and the excellently named Warrington-Runcorn New Town Development Plan.

II by Kiasmos

Your Community Hub by Warrington-Runcorn New Town Development Plan

Debian Packaging from First Principles – Part 1 – Simple .deb

2024-07-25T13:37:00+00:00

I’ve used Debian as my distro of choice for well over a decade and whilst I’ve become familiar with “using” Debian I’ve never really understood how it worked under the hood. I understand that behind the scenes of apt install there’s a repository out on the internet somewhere, some packages are downloaded, and then their contents are installed, but how that happens is a bit of a black-box mystery to me.

In this first post in the series I aim to uncover what exactly is a deb file, what it contains and how one works. In subsequent posts I hope to better understand package-to-package dependencies, and eventually apt repositories. If you want to follow along with my code from this post and across all of the posts in this series, the files can be found in this directory from within this git repository.

deb Format

To begin with, I first consulted the deb format’s man page.

$ man 5 deb
# [...]
The file is an ar archive with a magic value of !<arch>.
# [...]
The first member is named debian-binary and contains a
series of lines, separated by newlines. Currently only
one line is present, the format version number, 2.0 at
the time this manual page was written.
# [...]
The second required member is named control.tar.  It is
a tar archive containing the package control information
as a series of plain files, of which the file control is
mandatory
# [...]
The third, last required member is named data.tar.  It
contains the filesystem as a tar archive
# [...]
These members must occur in this exact order.
# [...]

`ar` Archive

The first requirement from that man page is that a deb file is “an ar archive with a magic value of !.” I’m not familiar with the ar tool, so I’ve no idea if it’s special or difficult to set “!” as a magic value. To test ar‘s default behaviour, we can create an empty file, add it to a new ar archive, then inspect the archive’s content with a hex viewer such as xxd.

$ touch empty

$ ar r empty.ar empty
ar: creating empty.ar

$ xxd -c 8 -g 1 empty.ar
00000000: 21 3c 61 72 63 68 3e 0a  !<arch>.
00000008: 65 6d 70 74 79 2f 20 20  empty/
00000010: 20 20 20 20 20 20 20 20
00000018: 30 20 20 20 20 20 20 20  0
00000020: 20 20 20 20 30 20 20 20      0
00000028: 20 20 30 20 20 20 20 20    0
00000030: 36 34 34 20 20 20 20 20  644
00000038: 30 20 20 20 20 20 20 20  0
00000040: 20 20 60 0a

From this output we can see that ar is using “!” by default, so we don’t need to take any special action here.

`debian-binary`

Creating the first member of the archive, debian-binary, is as straightforward as creating a plain text file with a single line containing “2.0”.

$ vim debian-binary
2.0

`control.tar`

The archive’s second member, control.tar, needs to contain a control file as a bare minimum. Consulting the deb-control format’s man page reveals the format and contents of that file, including which fields are required.

$ man 5 deb-control
# [...]
This file contains a number of fields.  Each field begins
with a tag, such as Package or Version (case insensitive),
followed by a colon, and the body of the field
# [...]
FIELDS
# [...]
       Package: package-name (required)
# [...]
       Version: version-string (required)
# [...]
       Architecture: arch|all (required)
# [...]

It looks like we only need to provide three fields to get dpkg to accept our deb file, a name, the package’s version and the target architecture. Architecture’s the easiest here, we can just use “all” since we’re not actually bundling any platform-specific binaries. Version is straightforward too, we can just use a sensible “first” version such as 0.0.1 and accompany it with a “first” package number to build “0.0.1-1”. The name is to our own whims and since it’s the Simple example from my Debian Packaging from First Principles series, “dpfp-simple” is good enough.

$ mkdir control

$ vim control/control
Package: dpfp-simple
Version: 0.0.1-1
Architecture: all

With our control file in place, we can now bundle it in to the control.tar file which will be later added to the deb. You can probably get away without setting the user and group to root, but you might end up leaking your own username and group in the tar file without it.

$ tar \
    --create \
    --file control.tar \
    --owner=root \
    --group=root \
    --directory=control \
    control

$ tar \
    --list \
    --verbose \
    --file control.tar
-rw-r--r-- root/root        54 2024-07-10 12:44 control

We can see the control.tar file contains a single control file, matching the man pages’s specifications.

`data.tar`

The data.tar file needs to hold the package’s contents as they appear on the filesystem, so we should create a deep hierarchy of directories and place a simple text file within it.

$ mkdir \
    --parents \
    data/opt/debian-packaging-first-principles/simple

$ vim data/opt/debian-packaging-first-principles/simple/dpfp-simple-success.txt
Debian Packaging from First Principles
    Simple
        Success!

With our package’s filesystem laid out, we can bundle the success file and it’s directory hierarchy in to the data.tar we need to add to the deb. We follow the same process as we did for the control.tar earlier.

$ tar \
    --create \
    --file data.tar \
    --owner=root \
    --group=root \
    --directory=data \
    opt/

$ tar \
    --list \
    --verbose \
    --file data.tar
drwxr-xr-x root/root         0 2024-07-10 14:45 opt/
drwxr-xr-x root/root         0 2024-07-10 14:45 opt/debian-packaging-first-principles/
drwxr-xr-x root/root         0 2024-07-10 14:48 opt/debian-packaging-first-principles/simple/
-rw-r--r-- root/root        67 2024-07-10 14:47 opt/debian-packagi

This time, we can see tar‘s created entries for the whole directory structure as well as the text file which will be installed by dpkg.

`our-package.deb`

Now we’ve created the three member files described by the first man page, we can use the ar command to bundle them together to build our final deb package.

$ ar \
    r dpfp-simple_0.0.1-1_all.deb \
    debian-binary \
    control.tar \
    data.tar
ar: creating dpfp-simple_0.0.1-1_all.deb

$ ar tv dpfp-simple_0.0.1-1_all.deb
rw-r--r-- 0/0      4 Jan  1 01:00 1970 debian-binary
rw-r--r-- 0/0  10240 Jan  1 01:00 1970 control.tar
rw-r--r-- 0/0  10240 Jan  1 01:00 1970 data.tar

Here the ar command has added the three member files to our deb file and they appear to be in the correct order, such that Debian should accept them for installation.

Installing and Removing

You can use either apt or dpkg to install a local deb file, but for simplicity’s sake, I’ll stick with dpkg for just now. Once the package has been installed, we should be able to find the included text file in the correct location within the filesystem.

$ sudo dpkg --install dpfp-simple_0.0.1-1_all.deb
dpkg: warning: parsing file '/var/lib/dpkg/tmp.ci/control'
near line 4 package 'dpfp-simple':
 missing 'Description' field
dpkg: warning: parsing file '/var/lib/dpkg/tmp.ci/control'
near line 4 package 'dpfp-simple':
 missing 'Maintainer' field
Selecting previously unselected package dpfp-simple.
(Reading database ... 136384 files and directories
currently installed.)
Preparing to unpack dpfp-simple_0.0.1-1_all.deb ...
Unpacking dpfp-simple (0.0.1-1) ...
Setting up dpfp-simple (0.0.1-1) ...

$ less /opt/debian-packaging-first-principles/simple/dpfp-simple-success.txt
Debian Packaging from First Principles
    Simple
        Success!

Interesting. It appears that whilst the deb man page only describes three fields as required, it will be quite loud about two other fields missing from the control file. Despite these warnings, the files are extracted correctly and can be viewed as we’d hoped. To remove our package again, we need to specify its name instead of the deb file.

$ sudo dpkg --remove dpfp-simple
dpkg: warning: parsing file '/var/lib/dpkg/status' near
line 1939 package 'dpfp-simple':
 missing 'Description' field
dpkg: warning: parsing file '/var/lib/dpkg/status' near
line 1939 package 'dpfp-simple':
 missing 'Maintainer' field
(Reading database ... 136387 files and directories
currently installed.)
Removing dpfp-simple (0.0.1-1) ...

$ ls -al /opt
total 12
drwxr-xr-x 1 root root 4096 Jul 10 16:09 .
drwxr-xr-x 1 root root 4096 Jan  1  2021 ..

It appears that as part of whatever Debian does to store information about its installed packages, it copies the control file in to some central list and still complains about missing fields even as it’s removing the defective package.

Bug Fixing

In order that we’re being well behaved citizens of the deb ecosystem, we should fix those warnings. We need to add the two missing fields to our control file, update our version number to indicate we’re on our second package version, and rebuild the deb following the earlier steps.

Package: dpfp-simple
- Version: 0.0.1-1
+ Version: 0.0.1-2
Architecture: all
+ Description: A bare-minimum deb file, manually assembled to understand Debian packaging.
+ Maintainer: Mike Coats <i.am@mikecoats.com>

With the changes from that diff in place, and a new deb file built, we can try installing and removing the package again to see if the warnings have been resolved.

$ sudo dpkg --install ./dpfp-simple_0.0.1-2_all.deb
Selecting previously unselected package dpfp-simple.
(Reading database ... 137130 files and directories currently installed.)
Preparing to unpack ./dpfp-simple_0.0.1-2_all.deb ...
Unpacking dpfp-simple (0.0.1-2) ...
Setting up dpfp-simple (0.0.1-2) ...

$ sudo dpkg --remove dpfp-simple
(Reading database ... 137133 files and directories currently installed.)
Removing dpfp-simple (0.0.1-2) ...

Bingo! No more warnings!

To simplify the repeated building of the deb and its member files, I wrapped up the process in a small, hand-rolled, Makefile. My plan for the next few blog posts is to iterate on this project to understand more about deb files and apt tooling, first getting to grips with dependencies.

Recover a single drive from an abandoned RAID 1 mirrored pair

2024-07-10T13:37:00+00:00

Like most folks who’ve been in tech for a couple of decades, I’ve accumulated my fair share of obsolete equipment. I normally either find new homes for old hardware or have it responsibly recycled but, for peace of mind, I always shuck the hard drives first and promise to myself to “deal with them later”. “Later” never seems to happen and during a recent home-office tidy I discovered I’d been hoarding 11 hard drives of various flavours and vintages. Most of these drives were simply pulled from laptops or external drive caddies so mounting them, backing up any extant data and securely erasing them is a simple affair within any reasonably modern Debian install. One of the drives was pulled from an old Synology DS210j NAS however.

The drives in the DS210j had been set up as a mirrored pair for resiliency. I’ve always understood that to mean that a full, identical, copy of the data was made to both disks, but I’ve never poked under the hood to see how that worked. Can one drive be mounted as if it was always just a single disk? How much of the RAID array’s state has been lost by pulling the drive and getting rid of the NAS? Is there even anything left to recover and erase?

Here’s the steps I went through to enumerate and mount the data partition from a single drive that was once part of a RAID 1 mirrored pair.

I use this USB-SATA adapter from StarTech to connect old drives to my computer since it comes with an external power supply, so it should support even the beefiest 3.5″ spinning metal HDDs without dropping out. Connecting the drive and adaptor to the PC reveals the following logs.

$ sudo journalctl --catalog --pager-end --follow
# [...]
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: new high-speed USB device number 8 using ehci-platform
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: New USB device found, idVendor=174c, idProduct=235c, bcdDevice= 1.00
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: Product: USB 3.0 Destop HD EP0 Product string
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: Manufacturer: ASMT
Jul 02 12:56:06 dev-box kernel: usb 1-1.1: SerialNumber: 0000000000B8
Jul 02 12:56:06 dev-box kernel: scsi host1: uas
Jul 02 12:56:06 dev-box kernel: scsi 1:0:0:0: Direct-Access     ASMT     USB 3.0 Destop H 0    PQ: 0 ANSI: 6
Jul 02 12:56:06 dev-box kernel: sd 1:0:0:0: [sdb] Spinning up disk...
Jul 02 12:56:18 dev-box kernel: ............ready
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] Write Protect is off
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] Optimal transfer size 33553920 bytes
Jul 02 12:56:18 dev-box kernel:  sdb: sdb1 sdb2 sdb3
Jul 02 12:56:18 dev-box kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
# [...]

We can see that Debian’s picked up the new USB device and set up our drive under /dev/sdb with three partitions /dev/sdb[1-3]. We can then use fdisk to inspect the partition table and try to see what each partition is for.

$ sudo fdisk /dev/sdb
# [...]
Command (m for help): p
# [...]
Device     Boot   Start        End    Sectors   Size Id Type
/dev/sdb1            63    4980149    4980087   2.4G fd Linux raid autodetect
/dev/sdb2       4980150    6024374    1044225 509.9M fd Linux raid autodetect
/dev/sdb3       6281415 1953520064 1947238650 928.5G fd Linux raid autodetect
# [...]
Command (m for help): q

It looks like /dev/sdb3 is likely to be our data partition since it takes up >90% of the total space on the drive. We can try to mount that partition to take a look at any remaining files, but Linux won’t mount a RAID member directly.

$ sudo mount /dev/sdb1 /mnt
mount: /mnt: unknown filesystem type 'linux_raid_member'.
       dmesg(1) may have more information after failed mount system call.

Referring to an old datasheet for the Synology, it looks like the only file system it supported was EXT3, so we should be able safe enough to assume that’s what’s actually on that partition.

We can go back in to fdisk to change the partition’s type from raid member to regular linux partition. That involves changing it’s ID from FD to 83.

$ sudo fdisk /dev/sdb
Command (m for help): t
Partition number (1-3, default 3): 3
Hex code or alias (type L to list all): L

#[...]
Aliases:
   linux          - 83
#[...]
   raid           - FD
#[...]
Hex code or alias (type L to list all): 83

Changed type of partition 'Linux raid autodetect' to 'Linux'.

Command (m for help): w

Unfortunately, that doesn’t seem to work. There must be some other data encoded within the partition table or filesystem referring back to the old format ID so it won’t automatically mount the partition.

$ sudo mount /dev/sdb3 /mnt
mount: /mnt: unknown filesystem type 'linux_raid_member'.
       dmesg(1) may have more information after failed mount system call.

At this point I’m still pretty sure that the partition is really just ext3 under the covers, so it should be possible to mount it by specifying the filesystem type explicitly in the mount command. We can use ext4 for this on a modern computer as there’s a good degree of forward and backward compatibility between the two filesystems.

$ sudo mount --types ext4 /dev/sdb3 /mnt

Running that mount command returned no errors, so to double check we can ask the system for a list of it’s currently mounted partitions and see how it’s getting on.

$ mount
[...]
/dev/sdb3 on /mnt type ext4 (rw,relatime)

That looks promising, we might be on to something. The next step is to see if there any files available under the mountpoint to prove we’ve really attached the partition properly.

$ ls --all -l --human-readable /mnt
[...]
-rw-------  1 root root  6.0K May  3  2014  aquota.group
-rw-------  1 root root  8.0K May  1  2014  aquota.user
drwx------  2 root root  4.0K Jun  4  2014  @autoupdate
drwxr-xr-x  7 root root  4.0K Apr 14  2014  @download
[...]

Bingo! A whole list of files with a reasonably appropriate date have been found on the drive. Now I can back up anything that I still need a copy of, erase the disk when I’m done, and reflect on the fact that this drive has been in my to-do pile for a decade. Oops.

#NewMusicMonday – Mammoth Weed Wizard Bastard & Slomatics

2024-07-08T13:37:00+00:00

I’ve been on annual leave this week, so like any good nerd I’ve spent all of my free time learning a new programming language. I do struggle sometimes where I can’t seem to concentrate on writing code, or at least well-documented code, if there’s a plain, easy to understand English speaking voice playing in the same room. I find I’m just too easily distracted. I therefore love music that I can let wash over me, like instrumental tracks and foreign-language punk and metal.

I saw someone on social media this week recommend the split-EP by Mammoth Weed Wizard Bastard & Slomatics, TOTEMS. I’ve never listened to much Doom or Sludge Metal, but the tracks from both of these bands certainly seem to fit my “wash over me” criteria, particularly when listened to with a large set of over-ear headphones. As well as that split-EP, for this week’s #NewMusicMonday I’ve included an album each from Slomatics and Mammoth Weed Wizard Bastard.

TOTEMS by Mammoth Weed Wizard Bastard & Slomatics

Future Echo Returns by Slomatics

Nachthexen by Mammoth Weed Wizard Bastard

STM32 to Blinky with Rust – Part 3 – HAL and Blinky

2024-07-04T13:37:00+00:00

In the first part of this series, we connected the dev board and installed the probe-rs tool. In part 2, we created a basic project that compiled and built successfully, flashed it to the chip and watched it print “Hello, world!” over the debug interface back to the host computer. This time we’ll blink the LEDs on the STM32F407G-DISC1 Discovery board, starting with a single LED and finishing with all four in a pattern.

As before, you can follow along with the code snippets here, or see the completed single LED blinky project under the naive-blinky tag in my repo. The first thing we need to do is add the STM32 HAL to our Cargo.toml file. This provides all the interfaces we need to access the hardware features of our STM32F4. To specify the unique set of hardware that makes up the STM32F407, we opt in to the F4 runtime feature and the F407 feature.

[dependencies]
# ...
hal = { package = "stm32-hal2", version = "1.8.3", features = ["f407", "f4rt"] }

In the main.rs file, we always need to import the cortex_m package in some fashion to ensure the linker can find a critical-section but, whereas we previously threw away the import, this time we want to pull out Delay so we can use it later to pause between each blink.

- use cortex_m as _;
+ use cortex_m::delay::Delay;

We import Clocks from our renamed stm32-hal2stm32-blinky-rust-part-2-debug/ package which will be used later to configure the pause between blinks, and several parts of the gpio module to allow us to toggle the onboard LEDs.

use hal::{
    clocks::Clocks,
    gpio::{Pin, PinMode, Port},
};

To work out which pins on the chip are connected to which LEDs on the board, we can refer to the Discovery board’s user manual.

The orange LED, labelled LD3 on the board, is connected to PD13 on the chip, so we set it up as an output pin.

let mut north_led = Pin::new(Port::D, 13, PinMode::Output);

We then set up the MCU’s clock configuration, to be used later when we pause between blinks.

let clock_cfg = Clocks::default();
clock_cfg.setup().unwrap();
let mut delay = Delay::new(
    cortex_m::Peripherals::take().unwrap().SYST,
    clock_cfg.systick(),
);

Now we’ve prepared the LED’s pin for toggling on and off and a delay timer that can be used to pause between blinks, we can do just that. In a loop. Forever!

loop {
    north_led.toggle();
    delay.delay_ms(1_000);
}

At this point cargo run will be compile and flash the above code to the STM32, and one of the LEDs will flash slowly.

That’s cool, but if you’re reading this blog post and have followed along so far, there’s a chance you’re a massive nerd, just like me. Given 4 LEDs, we could flash a pattern such as displaying the binary numbers from 0 to 15 but that would be too easy. Instead we can flash the Gray coded pattern of those numbers instead. The completed code for this stage can be found under the gray-blinky tag in my repo.

First we need to create an array with all 16 possible iterations of a 4-bit Gray code. We then need a similarly sized 4-bit bitmask to represent each LED.

const GRAY: [u32; 16] = [
    0b0000,
    0b0001, // Least-significant bit 0 appears first
    0b0011, // LSb 1 appears second
    0b0010,
    0b0110, // LSb 2 appears third
    0b0111,
    0b0101,
    0b0100,
    0b1100, // LSb 3, or MSb, appears fourth
    0b1101,
    0b1111,
    0b1110,
    0b1010,
    0b1011,
    0b1001,
    0b1000,
];

const NORTH: u32 = 0b0001;
const EAST: u32 = 0b0010;
const SOUTH: u32 = 0b0100;
const WEST: u32 = 0b1000;

If we perform a bitwise AND between a position in the Gray array and one of those cardinal directions’ bitmasks, we’ll be left with a positive value indicating when that LED should be illuminated. We can then make the same test for the other three directions and we’ll know whether to light each of our LEDs on every cycle through the loop.

let mut counter: usize = 0;
loop {
    let bits = GRAY[counter];

    if bits & NORTH > 0 {
        north_led.set_high();
    } else {
        north_led.set_low();
    }
    // ...
}

At the end of every loop we need to increment our position in the Gray list, but we must not overflow the end of the array and instead jump back to the start.

loop {
    // ...
    counter += 1;
    if counter > 15 {
        counter = 0
    }
}

Compiling and flashing the board with these changes will make the LEDs on the board flash according to the current position in the Gray code array.

There we go! STM32 to Blinky with Rust complete. We can now use this project as a worked example to base any other STM32 embedded Rust projects from and give them a hopefully head-ache free kickstart.

STM32 to Blinky with Rust – Part 2 – Development and Debug Toolchain

2024-06-30T13:37:00+00:00

In the first part of this series, we connected the dev board and installed the probe-rs tool. This time we’ll create a basic project that prints “Hello, world!” over the debug interface. This should prove we have a valid compilation toolchain, can successfully flash our own firmware to a STM32F4 and then connect to it for debugging.

Since we’ll be building for the STM32F407, a Cortex-M4F chip, we need the correct rust target installed. This is done using the rustup command we installed in the previous post in the series.

$ rustup target add thumbv7em-none-eabihf

There are a number of embedded Arm templates that can be used with the cargo generate tool, but the ones I tried were quite out of date and were not compatible with the RTT debug messages used by probe-rs. Instead, we’ll create our project from scratch, including only the bare minimum of files to get us up and running. If you feel ambitious, you can follow along with the snippets in this blog post, like a true child of the 80’s typing away at your Sinclair Spectrum. Alternatively, I’ve posted the completed code from this post to a repo on Codeberg, under the debug tag.

https://codeberg.org/MikeCoats/stm32-to-blinky/src/tag/debug

The repo can be cloned and the tag checked out by running these three commands.

$ git clone git@codeberg.org:MikeCoats/stm32-to-blinky.git
$ git fetch --all --tags
$ git checkout tags/debug -b debug-branch

To define the project you need a Cargo.toml manifest file. The package details like name, author and version aren’t important, but the dependencies section and a binary target are needed to get a compiled and linked firmware built.

[package]
# [...]

[dependencies]
cortex-m = { version = "0.7.7", features = ["critical-section-single-core"] }
cortex-m-rt = "0.7.3"
panic-rtt-target = "0.1.3"
rtt-target = "0.5.0"

[[bin]]
name = "stm32-to-blinky"
test = false
bench = false

At the time of writing, these packages were up to date and the correct features had been enabled. I’ve found some older documentation and blog posts that worked with the then-current packages, but newer versions have both added and deprecated features that prevent compilation and linking.

Next up, we need a memory map for our chip. Our ST Discovery board has an STM32F407VGT6 so, referring to its datasheet, we know it has 1M of flash starting at 0x0800_0000 and 128K of RAM starting at 0x2000_0000.

MEMORY
{
  FLASH : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM   : ORIGIN = 0x20000000, LENGTH =  128K
}

We need a build script to accompany our memory map to ensure the map is used by the linker, placing the appropriate sections of our binary at the correct locations. Your build script could get more complicated over time, but this is enough to get us going for now. All we need to build “Hello, world!” is to include the linker script from cortex-m-rt in the compiler’s link arguments.

fn main() {
    println!("cargo:rustc-link-arg=-Tlink.x");
}

Rust will compile and link for the host system’s architecture by default, such as x86_64 or aarch64. We must, then, supply a config file to tell it to build for our STM32F4’s Cortex-M4F thumbv7em architecture instead. We can also tell cargo to allow its run command to flash and debug our chip with probe-rs by setting up the target’s runner.

[build]
target = "thumbv7em-none-eabihf"

[target.thumbv7em-none-eabihf]
runner = "probe-rs run --chip STM32F407VGTx"

With all the project configuration out of the way, we can finally write our “Hello, world!” program. There are some important lines in the code to point out here.

One line 1, we’re telling rust to not use the standard library, which is important as without an OS running on the chip there won’t be a standard library available. Line 2 tells rust not to emit a “main” entrypoint, which is only useful when operating systems try to launch your program. Instead, on line 9, we indicate where our entrypoint is. This way we tell the linker which function needs to be placed at the matching location in the STM32’s memory.

#![no_std]
#![no_main]

use cortex_m as _;
use cortex_m_rt::entry;
use rtt_target::{rtt_init_print, rprintln};
use panic_rtt_target as _;

#[entry]
fn main() -> ! {
    rtt_init_print!();
    rprintln!("Hello, world!");

    loop {}
}

The rtt libraries need a “critical section” to be linked or they will, in turn, fail to link. The cortex_m package is included on line 4 so that its critical section implementation is linked but, as we don’t directly use any of its contents, we can discard the result of the import.

The final two lines of interest are 10 and 14. The method signature -> ! indicates that the function never returns and the infinite loop {} ensures that it will never do so.

With all the pieces in place we can now build our binary. Running cargo build will download and compile all of our dependencies, along with our code, and output our program formatted for Cortex-M4F chips, linked to match our STM32F4’s memory map.

$ cargo build
[...]
   Compiling cortex-m v0.7.7
[...]
   Compiling cortex-m-rt v0.7.3
[...]
   Compiling rtt-target v0.5.0
[...]
   Compiling stm32-to-blinky v0.1.0 (/home/mike/projects/stm32-to-blinky)
   Compiling panic-rtt-target v0.1.3
[...]
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 12.47s

If at this point you get a linker error instead of success, there’s a chance you’re missing some of the binary tools needed to manipulate compiled code for other target architectures. Adding the llvm-tools component gives us versions of the tools which support all of the architectures that rust itself supports.

$ rustup component add llvm-tools

Now that we’ve successfully built the project, we can deploy it to our bare-metal chip. The previously configured cargo run command will flash the program to the STM32F407VGT6 and attach the debugger, ready to receive output from the chip. Finally, “Hello, world!” appears on our console.

$ cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.03s          
     Running `probe-rs run --chip STM32F407VGTx target/thumbv7em-none-eabihf/debug/stm32-to-blinky`
      Erasing ✔ [00:00:01] [##########################] 16.00 KiB/16.00 KiB @ 12.20 KiB/s (eta 0s )
  Programming ✔ [00:00:06] [###########################] 16.00 KiB/16.00 KiB @ 2.51 KiB/s (eta 0s )
    Finished in 7.904s                                                           
Hello, world!

Done! Part 2 is complete! Building on part 1, we’ve now got a toolchain installed, the hardware connected, a project built, the binary flashed to the chip and a message returned via the debugger. In part 3 we need to access the GPIO pins on the STM32F407VGT6 and blink the attached LEDs on the STM32F407G-DISC1 Discovery board.

#NewMusicMonday – Cheap Dirty Horse, The Masochists and a (dis)honourable mention

2024-06-24T13:37:00+00:00

This week’s #NewMusicMonday is all about punk, politics and protest in the UK. In the UK we’re gearing up for our next General Election, where it looks like our incumbent blue coloured right-wing political party is going to be ousted by our red coloured right-leaning political party; plus ça change… Leaders and representatives of both parties have spent the last few weeks telling Scotland what the UK intends to do with us, rather than how they can actually work with the devolved nations.

Cheap Dirty Horse have to be on this list with their collection of recent tracks skewering late-stage capitalism and promoting LGBTQ+ issues, since both parties have spent much of the last 6 months tying themselves in knots over these. The Masochists released their EP including The TV News over a year ago, but it still fits the TV’s over-saturation with political party nonsense that we’re currently experiencing.

A sneaky little (dis)honourable mention this week goes out to Kunt and the Gang for their 40 seconds long ode to Rishi Sunak. Who knew his name had the same cadence as the Tellytubbies theme?!

Cheap Dirty Horse Raise Funds to Go On Tour by Cheap Dirty Horse

The TV News EP by The Masochists

Rishi Sunak (RFC) by Kunt and the Gang

STM32 to Blinky with Rust – Part 1 – Hardware – STM32F407G-DISC1

2024-06-20T13:37:00+00:00

It’s been more than a decade since I last played with or programmed a microcontroller in anger, and wow, how the world’s moved on! The Arduino and its ATmega328P AVR is no longer king and now you can get an Arm Cortex-M0+ complete with a re-usable USB programmer for less than £10. For around £20 you can buy a development board with an Arm Cortex-M4F and some peripherals including an accelerometer, microphone, DAC, and USB OTG port.

Programming languages, compilers and toolchains have moved on too; C and Assembly aren’t the only games in town for low level microcontroller coding anymore. Rust has gained widespread support for many platforms and architectures and offers a memory safe way to run code on the bare-metal processor.

This series of blog posts will document my attempts to get a rust toolchain installed, compiling code for Arm Cortex M processors and deploying a small program on an STM32.

The first thing we need to do is install the basic rust toolset. There are probably some secure, supported, packages for Debian that you can apt install, but the last time I looked they were 2 years out of date. caveat emptor, running random shell scripts downloaded from websites is potentially dangerous; here be dragons.

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

The installer will update your shell’s configuration, setting up rust and its tools ready for your next login. Until that time, you can manually update your shell’s environment by ‘sourcing’ rust’s package manager, cargo‘s, script.

$ . ~/.cargo/env

With a proper rust environment set up, we now need to install the programmer/debugger tools. probe-rs integrates with the standard cargo tool to push compiled code to the chip and run it with a debugger. Installing it is similar to rust’s installation method, so the same warnings apply.

$ curl --proto '=https' --tlsv1.2 -LsSf https://github.com/probe-rs/probe-rs/releases/latest/download/probe-rs-tools-installer.sh | sh

Only the root user will have access to the USB programmer by default. To let regular users connect to the ST-LINK programmer we need add some udev rules.

First we need to find the USB ID for the ST-LINK, so we know which device to apply the rule to. There’s a good chance that the ID is 0483:374b, since that seems to be the same across most ST-LINKs I’ve seen, but it’s always safer to check first.

$ lsusb | grep ST-LINK

Bus 004 Device 002: ID 0483:374b STMicroelectronics ST-LINK/V2.1

To let local, logged-in, users connect to the ST-LINK programmer we need add a uaccess tag to it with a udev rule. Remote, SSH, users will need to be added to the plugdev group and then we can use the udev rule to apply that group and the 660 mode to the device.

$ sudo usermod -a -G plugdev $USER

$ exec sg plugdev newgrp

$ sudo vim /etc/udev/rules.d/70-usb-stlink.rules

ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", MODE="660", GROUP="plugdev", TAG+="uaccess"

That rule and it’s clauses will be picked up on the next reboot, but we can force udev to read and apply it to any devices already connected with udevadm.

$ sudo udevadm control --reload

$ sudo udevadm trigger

Running probe-rs‘ list command will tell us which ST-LINKs have been detected, and its info command will then interrogate the chip its connected to about its configuration. If both succeed, we’ve probably got all of the permissions lined up to allow our user to program the chip.

$ probe-rs list

The following debug probes were found:
[0]: STLink V2-1 -- 0483:374b:066CFF575377524867052744 (ST-LINK)

$ probe-rs info

Probing target via JTAG

ARM Chip with debug port Default:
[…]
            │       ├── PARTNO: Cortex-M4
[…]
Probing target via SWD

ARM Chip with debug port Default:
[…]
            │       ├── PARTNO: Cortex-M4
[…]

That’s it for part 1. We’ve got the toolchain installed, connected the debugger and confirmed we can see the ARM chip ready for programming. Next we need to spin up a small project and send it to the programmer.

#NewMusicMonday – Alkanes, Broadsea & PaperSailor

2024-06-17T13:37:00+00:00

I’ve been “off” the birdsite for a little over a year now, and one of my most missed trends from there is #NewMusicMonday. I loved discovering smaller, less well known, bands and musicians. In an effort to “be the change [I] want to see”, I’m going to do my best to share my own choices with the fediverse every week, and see if I can’t find some likeminded folks.

For my first #NewMusicMonday, I’m going to start with something local and close to my heart. Alkanes are a stalwart of the Inverness music scene, gigging in town and across the country for the best part of a decade. They’ve recently announced that they’re bringing things to an end, and have lined up a farewell show.

At that gig they’re going to be supported by Aberdeen’s Broadsea and PaperSailor from Glasgow, so this week’s #NewMusicMonday playlist is going to be each band’s latest release, available from their respective Bandcamp pages.

Anoesis by Broadsea

Pictures of Black Holes by PaperSailor

This Is It by Alkanes

Data loss: A blind-spot in my backup strategy

2024-04-01T13:37:00+00:00

Last week I suffered a catastrophic disk failure, leaving my 1TB NVMe drive completely unreadable. Luckily I have backups, I thought.

Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it 😉

Linus Torvalds

I don’t, in general, backup my git projects. All of my personal projects are open source, so I always push my code up to an online repository. I don’t feel like paying to backup a couple of dozen python .venv/ and JavaScript node_modules/ directories full of other people’s code, so I exclude my projects directory from my backup plan.

I’m a little bit of a perfectionist and I don’t like publishing something in advance of announcing and publicising it. Therefore, I tend not to create a project for something on an online repository until v1.00 is ready to deploy. I still commit everything to a local git repository so I can roll back breaking changes, try out multiple different approaches, etc. I just wait until I’m completely finished before I push it out to the world.

These two choices came to bite me last week. I had three projects under development; one was about 50% there, another was about 90% done and one was 100% finished except for the blog post to announce it. All three were in local git repositories saved to my 1TB NVMe drive. All three had yet to be pushed to an online repository. All three were excluded from my backup plan. All three were lost when the drive failed.

I felt sick.

Although I’m an IT Manager now, I come from a background of agile software development. Its practice of Radical Honesty, that should be found in trusting teams and retrospectives, is why I’ve written this post. I similarly believe in Throwaway Prototyping and that its use can be one of the best ways to prove an idea works or is worthy of further development. Even still, I can’t bring myself to work on those three projects again, yet.

Instead, I’ve revised my backup plan, decided to get over my aversion to “private” projects on online repositories, and started another project to take the sting off things. I still won’t be publishing publicly until I’m ready to publicise it, but at least it’s saved in three different places now!

Stacking Loyalty Schemes for Extra Discounts

2024-03-10T13:37:00+00:00

This post is very “Guardian Reader” of me, and for that I apologise in advance.

One morning I found myself absent mindedly reading the back of my yogurt pot whilst eating my breakfast. This yogurt was made by Yeo Valley Organic and was advertising some kind of loyalty scheme called “Yeokens”. I’d never really thought about being “loyal” to a yogurt brand before, so I checked out their website to see what you could redeem a lifetime’s worth of yogurt eating points towards. There are branded tote bags, an annual pass to visit their 6 1/2 acre organic garden and – probably the most useful – discount vouchers for other shops.

The discount voucher that caught my eye was an offer to save 20% at Rapanui, a clothing manufacturer who appear to be trying to “do the right thing”. They focus on organic cotton, promoting cotton as a vegan alternative to wool for knitted items and offer items made from recycled cotton too.

Yeo Valley will charge you 20 Yeokens to get your 20% Rapanui discount, but you don’t have to purchase 20 Yeokens worth of yogurt to build up your balance. You get a 10 Yeoken bonus for simply activating your account and they will give you another 10 Yeokens for banking your first code.

The availability of a partner discount isn’t really worth a blog post on it’s own and would otherwise sound like an advert for a yogurt company, but I’ve discovered an interesting second aspect to improve the deal. Tesco periodically offer Yeo Valley Organic yogurts on their “Clubcard Price” scheme, which means that you can get a pot of yogurt for 50p less than normal.

So, is it worth it? Well, it’s only a deal if you were going to buy it anyway. If you are going to spend at least £7.50 at Rapanui then, yes, you should probably buy some yogurt first!

What is Gregg Wallace doing?

2024-02-06T13:37:00+00:00

I think I’ve trumped my previously silliest web app to date with my new one, “What is Gregg Wallace doing?”

what-is-gregg-wallace-doing.mikecoats.xyz

Based on his published schedule in the Torygraph which was then ridiculed on social media until the Grauniad reported on it, this web app will tell you exactly what Gregg Wallace is doing at any moment in time. Marvelous!

The Greg or Ian Calendar

2024-01-11T13:37:00+00:00

This week I published probably my silliest web app to date, The Greg or Ian Calendar.

gregorian.mikecoats.xyz

Based on the joke that's endemic across social media, it’s a web app that will tell you whether today is a ‘Greg’ day or if it’s an ‘Ian’ day.

Monday - Greg

Tuesday - Ian

Wednesday - Greg

Thursday - Ian

Friday - Greg

Saturday - Ian

Sunday - Greg

The Gregorian calendar.

To really run the joke in to the ground, I took it one step further and added an iCal feed that you can subscribe to from within your desktop or mobile Calendar app. Never again be unsure of whether it’s an ‘Ian’ or ‘Greg day again!

If you’re that way inclined, the source code is up on my GitHub. Criticism, bug reports and pull requests are all very welcome!

Bringing an Apple AirTag Back to Life

2023-11-27T13:37:00+00:00

If you’re lazy like me, you’ll probably have a few gadgets laying about the house that have flat batteries. Some of those widgets might have been needing those batteries replaced for more than six months. If one of them is an Apple AirTag, it might not be as simple as just popping in a fresh CR2032 and closing it back up. There’s a chance that your iPhone still won’t recognise or talk to your AirTag at all, even with a new cell inserted.

If you naively thought that removing the AirTag from your Apple ID would help reset things, you’d be wrong and possibly in an even worse state than before. If your iPhone cannot connect to your AirTag, even after you’ve inserted a fresh battery, the command to delete the AirTag’s on-board configuration will not go through. You’ll end up in a no-man’s land where your Apple ID & iPhone will deny all knowledge of the AirTag, while the AirTag still thinks it’s ‘owned’ by your Apple ID but it just can’t connect.

AirTags that have been without power for a decent amount of time need to be totally reset. This can be accomplished by completing the steps in the following knowledge base article, https://support.apple.com/en-us/102577.

Despite what Apple says in their support article, it might take more than five insert and remove cycles for the AirTag to reset. It seems that depending on how long you take, it might forget its position and restart the count. My advice is just to keep repeating the process until you hear a “different” sound and don’t bother counting. In my experience, it takes 6-8 cycles to reset my AirTags.

Once you hear that “different” sound, you’ve successfully reset the AirTag. You can now close the battery lid and re-associate it with your Apple ID by bringing it close to your iPhone and completing the automatic pairing process.

P.S. The reason this article is so keyword heavy is so that I can game my own SEO and find this post again in two years time, when I inevitably have to do exactly the same thing.

SQLite Adventure

2023-11-23T13:37:00+00:00

Nearly a decade ago, before the site formerly known as Twitter went to total ratshit, @edent published a choose-your-own-adventure game where Twitter was the game engine.

This was perfect nerd-sniping bait for my team at work. How far could you bend a common tool and use it to build a game? How small could a game engine be?

In response, my colleagues and I set about writing a game engine that could fit within in a single tweet. My attempt from 2015 is lost to the sands of time, now that I’m one employer and several laptops distant, but I was recently inspired to go back and give it another go. All I can remember from my first attempt was that I cheated (slightly) by storing all of the game data within a SQLite database, allowing me to build my game engine with a simple set of select statements.

Starting fresh, I was able to build a reasonable experience using 3 tables for game data and 3 select statements within a bash script as the game engine. The tables are arrange as in this diagram, centred around a page entry with multiple lines of descriptions and multiple choices hanging off each.

I’ve uploaded my code so far to my sqlite-adventure repo. Clone the repo to a *nix-ish environment and run the ./build.sh script to create the database and tables and fill them with entries. The game can then be played by running the ./page <number> command and following along with the (as yet unwritten) story.

./page 1" loading="lazy" decoding="async" />

It’s at this point, that the code-golf began. The full-fat, unfettered, version of the script comes in at an unreasonably large 335 characters. That’s practically a novel according to Twitter’s old limits. My first step was to rename all tables and columns to single characters and to remove some of the nicer formatting in the command’s output. These two steps allowed me to reduce the file down to 122 characters.

#!/bin/bash

sqlite3 a <<< "select t from p where p = $1; select c from d where p = $1; select t, c from c where f = $1;"

That’s small enough to fit within a tweet, but not small enough to satisfy my code-golf urges. There’s still multiple occurrences of relatively long words like “select” and “where” which could be replaced by some single character variables for a naïve form of dictionary compression.

#!/bin/bash
s=select;f=from;w=where
sqlite3 a<<<"$s t $f p $w p=$1;$s c $f d $w p=$1;$s t,c $f c $w f=$1;"

With all three occurrences of “select”, “from”, and “where” replaced with single character variables and all unnecessary whitespace removed my “game engine” is now just 106 characters long. The user experience isn’t as nice as the pre-shrunk version, but it’s still passable.

./p 1" loading="lazy" decoding="async" />

There are a couple of places the engine could be further minimised, but I’m happy to leave it here for now.

Bringing a VanMoof X3 or S3 Back to Life – Part 2 – Battery Pack

2023-10-13T13:37:00+00:00

In Part 1 of this series, I extracted and deconstructed the Smart Cartridge from my partner’s VanMoof X3 with the goal of charging the small, secondary, battery inside it. That was successful and I managed to charge the small Lithium-Poly cell, bringing the bike back to life. The VanMoof supplied power brick would still not charge the bike’s primary battery and I suspected that some or all of the individual cells have discharged to the point that the safety circuits will not allow a charging voltage to be applied.

My plan for this post is to lay out the steps and tools required to remove the primary battery pack from the bike, deconstruct it to the level of individual cells, charge them manually and rebuild the battery and the bike.

In part 1 some of the steps were detailed in VanMoof’s technical documents, but unfortunately everything we’re doing in this post is entirely unsupported. These steps have been reverse engineered by tearing down our bike so, caveat lector, they may vary from unit to unit. Luckily, removing the battery pack from the bike is easier than removing the Smart Cartridge and only involves removing three security torx bolts from the bottom of the downtube. The only tricky bolt is the one behind the chainring. Accessing it can be achieved by unclipping the soft plastic chain guard, then gently bending it out of the way.

Once all three bolts have been undone, the protective cap can be removed. This will reveal the end of the battery pack, complete with a swing-out removal handle. Pop out the handle with a finger tip and you’ll be able to pull the battery pack free with a firm tug. Be careful not to damage the cable you find in the same area; it’s connected to the cadence sensor and without it the bike will be unable to provide pedal assist.

With the battery pack free, it can be placed on the workbench for further break-down. Remove the 5 cross head screws from each end of the battery pack and use an iFixit Opening Tool, or similar, to pop the caps off. The cap with the swing-out handle can be completed removed from the battery pack, but the cap with the power connector is wired internally to the circuit and cells within.

Having removed the cap with the handle, press firmly on the inside of the battery pack that is now visible. The whole assembly of cells and circuitry should slide out of the other end of the casing tube.

Like many battery packs assembled from individual cells this whole thing has been spot welded together and then wrapped in glass fiber reinforced tape to provide physical and electrical protection.

Carefully unwrapping the tape reveals the pack’s make-up, including the safety precautions the manufacturer has added to extend the life of the bike and to prevent it from causing house-fires.

There are two temperature sensors embedded in the battery pack, each 1/3 of the way along its length. These will allow the charging circuit to detect any uneven charging in the pack and shutdown before a thermal run-away can cause damage or start a fire.

There are also voltage sense wires connected every 1/10 of the pack’s length at each group of four cells. These allow sub-voltages to be measured both before and during charging, preventing power being applied to an overly discharged pack and keeping the pack balanced.

Reverse engineering the pack allows us to build the following crude schematic. We can see that it will not be possible to charge individual cells, but each group of 4 could be charged as a smaller sub-battery.

To determine what constant current and constant voltage values we need to set on our power supply, we first need to determine what cells we’re dealing with. Searching the web for the partial product code “R18650MJ1” reveals that this is most likely an LG INR18650 MJ1 Lithium-Ion cell.

Consulting the LG datasheet suggests that single cells can be charged at 1.7A constant current followed by 4.2V constant voltage. We’ll be charging 4 cells at a time, in parallel sub-batteries, so we’ll need to use about 6.8A constant current. Since we’re unsure how safe each cell is, I decided to reduce the charge rate slightly to 6.4A total constant current, to give me a little overhead in case anything started to go wrong.

LG-INR18650-MJ1 Download

For safety’s sake, I de-soldered the positive end of the battery pack and the adjacent sense wire to break the circuit and ensure there would be no path for current to flow during the sub-battery charging. The positive terminal has quite a substantial amount of solder bonding it to the wire, so a fairly robust iron is needed to free the wire and clean the pad without heating up the surrounding cells too much. My Pinecil v2 was just about up to the job, but if you had to repair multiple batteries, I’d suggest picking up something a bit beefier.

Crocodile clips can be connected across every sub-battery using the sense wire solder tags. This is easier if you de-solder these sense wires as it will leave you with more of the tag to clip on to. We can then charge the pack as if we just had 10 cells that each needed 6.4A and 4.2V.

Once all of the cells have been charged, the sense wires and the main positive wire can be re-soldered, and the pack can then be taped back up. As you solder the main positive wire back on, there’s a chance of spark, so be aware soldering this connection around flammable fumes or gases.

The layout of the pieces of tape indicate the double duty it is being put to. The whole battery pack is wrapped for structural support, and the solder connections are wrapped to prevent the wires from rubbing through and shorting out. Finding a suitable tape proved tough, but eventually I managed to track down the GTIWUNG Filament Strapping Tape on Amazon, that has a similar arrangement of embedded glass fibers to the original tape. Be careful to use no more tape than strictly necessary as squeezing the battery pack back inside the casing tube is a tight fit.

Once you’ve reassembled the battery pack, all that’s left is to re-install the unit in the bike’s down tube and plug in the charging lead to see if you’ve brought the bike back to life. If you’re unsure which way round to insert the battery pack, shining a torch inside the down tube will reveal the orientation of the counterpart connector.

If you’ve successfully brought the bike’s primary battery back to life, you should be able to observe the charging brick turn from green to red to indicate charging has started and it should stay red to indicate that it is continuing to charge.

The matrix display on the bike’s top tube should also indicate a successful charging cycle has begun by pulsing a lightning bolt above the battery level indicator.

Comments

lincoln fowler on 2024-05-08 wrote:

mike- we have an A5. both small and main batteries were dead. i brought back the BMS by using a USB charger to pins 1 and 4 of the debug port. i am now thinking about manually charging the main battery. another poster (youtube: ebikerepairs) suggested an S5 could be charged with 35v at 0.5a to give it just enough juice to allow the main charge to recognize the pack and take over. does that sound right to you? i’m not willing to tear down the battery pack.

Mike Coats on 2024-05-08 wrote:

Hi Lincoln, That should work but I’ve no idea how long you should apply that voltage and current for and it’s not something I’d recommend without being extremely careful. It’s pretty much how the VanMoof charges itself once it’s in the CV section of the charge curve, except it’s got voltage monitoring every 1/10th of the pack and temperature monitoring every 1/3rd of the pack to protect the cells. If any of the cells have discharged themselves to a dangerous level there’s a chance you could get a thermal runaway that could lead to a battery fire. Realistically, as long as your power supply really can supply 35V with a hard limit of 0.5A then I doubt 17.5W would build up sufficient heat quickly enough to cause too much mischief. If you have an IR Thermometer, I’d at least give it a wave over the pack while it’s charging to make sure it doesn’t get away from you. Cheers, Mike

Tom Stewart on 2024-03-11 wrote:

Could you possibly have a go at mine, if I ship it to you? Thank you Tom Stewart

Mike Coats on 2024-03-11 wrote:

Hi Tom, I’m sorry, but no. I’m more than happy to take on the risk of charging a Lithium-Ion battery pack for myself, when I know the history of the pack. Rebuilding someone else’s pack and shipping it internationally is a risk beyond my comfort level. With the right equipment, particularly the power supply in the post, it’s really not too difficult to do it yourself. I’m happy to answer any questions you have, either here or by email, if you need any assistance. If you do still want someone else to take a look at it, I’d ask around the folks on Reddit. There’s got to be someone closer to you (or at least on the same continent) that will be able to help. Cheers, Mike

Koichi on 2024-04-02 wrote:

I’m trying to remove the battery, but I can’t get good access to the screws hidden in the chain cover. Could you please tell me a little more about how you accessed it?

Mike Coats on 2024-04-03 wrote:

Hi Koichi, One of the best tools I’ve found for getting access to bolts in hard to reach places is the Wera Zyklop Mini 1. It’s a tiny ratcheting wrench that can get in to places that hex keys or bit drivers can’t quite reach. My only other advice is to remove as much of the chain guard as you can. The only part that can’t be easily removed is attached to the bottom bracket but it’s quite flexible and with a bit of work and persuasion can be made to sit out of the way. In the second photo in the post you can see how I’ve wedged the chain guard on the other side of the chainring to give me access. Cheers, Mike.

Stuart on 2024-04-03 wrote:

Thanks for making this website, i have made a VanMoof s3 work again by charging the little single cell in the smart controller. Very helpful and well documented site.

Mike Coats on 2024-04-03 wrote:

Hi Stuart, Thanks for your kind message. I’m glad you found these posts useful. Cheers, Mike.

Rabi on 2024-04-04 wrote:

The problem wasn’t the 4045A or the VMS Chip on the main board? Did you check continuity on the fuse? I’m currently experiencing a flashing skull that the smart controller shows flashing on and off. Before I get into fixing this whole thing, it’s probably going to take some time.

Mike Coats on 2024-04-04 wrote:

No, I was lucky enough that my problem was just overly discharged cells. Since rebuilding and recharging everything I’ve not had any of the same problems come back. I’ve managed to keep the pack charged since then but I have had the dreaded Err44 pop up recently.

Rabi on 2024-04-04 wrote:

Err44, ah man. https://www.reddit.com/r/vanmoofbicycle/comments/169tfra/swap_your_broken_vanmoof_eshifter_for_a_3dprinted/ This might be worth checking out. You might be able to 3D print a new gear shifter. As for my charging issue, I guess it’s going to take some attempts for me. I hope my issue is similar to yours, since I really don’t want to have to replace the fuse. I’m an EE but it’s been a long time since I’ve done circuit soldering.

Stuart on 2024-04-08 wrote:

Have got the bike out of shipping? mode now with the lock code, unfortunately i am now getting error 20 message. Does anyone have any ideas?

Mike Coats on 2024-04-08 wrote:

Hi Stuart, Yes, once I got my bike out of shipping mode, I also found further battery problems. All of this second post is how I overcame those issues. Without manually refreshing all of the cells within the primary battery, I couldn’t get it to charge at all. Since I’ve done the refresh, I’ve had no further problems charging the bike. Cheers, Mike.

stuart on 2024-04-08 wrote:

Also charger stays with a green light when plugged in.

Mike Coats on 2024-04-08 wrote:

That definitely sounds like the controller’s not happy with the primary battery.

Andrew Kraut on 2024-06-01 wrote:

Mike, were you able to figure out a rough pinout for the connector on the battery? The specifics I’m trying to suss out are what each of the 4 large/high-current pins are for.

Mike Coats on 2024-06-01 wrote:

I’m afraid I never beeped them out or traced the wires, sorry. I always just assumed one pair was for connecting the charger to the battery and the other pair was for the connection between the battery and the motor. I’ll have a dig through my photo roll to see if I have any extra pictures from when I had the pack disassembled.

Carlos on 2024-07-12 wrote:

I have some cells under 1 volt. Would you recommend trying to bring them back, or is it not worth the risk? Thank you so much!

Mike Coats on 2024-07-17 wrote:

Are all the cells below 1 volt, or just some of them? If they’re uniformly low, then you might be able to charge the pack, just very carefully. Figure 2 in this article implies you can use a 0.1C charge current to pre-condition the battery until you get it up to 3 volts. https://www.digikey.com/en/articles/a-designer-guide-fast-lithium-ion-battery-charging If you have only a few cells, or 4-packs of cells, that are that low, then they’ve discharged themselves unusually in comparison the whole pack. That’s indicative of something more serious with the cells and I’d be looking to identify and replace any that are damaged. That’s way beyond my skills though.

javier on 2024-09-09 wrote:

Hello. Great guide! thanks! I have a problem, maybe somebody can help me: I have a X3,very few km (450km). I have left it unused for a year and when I want to use it again it does nothing. I disassemble the smart cartridge and change the Li-Po battery. It comes back to life, it connects to the app but now it tells me error 19 and the battery in the app flashes. I understand that it is the main battery so I remove it, and with the source I take it to 34v. When I insert it back, it detects it and starts charging, I leave it all night and it charges to 100% and it does not give me ANY ERROR. I think everything has been solved but now when I want to start it, the lock appears, and the 5 second countdown, and when I move forward, it does nothing, and it locks when it reaches 5. No matter what I do, I cannot unlock it, it is as if the engine does not start. Does anyone know what it could be? Also, I am surprised that the speaker volume is super high. Thanks.

Mike Coats on 2024-09-09 wrote:

Hi Javier, that sounds like your bike’s rear wheel is locked with its kick-lock. That’s the “button” you can find on the rear wheel that interfaces with the castellated ring attached to the brake disc. Normally you unlock it with the app or using the three-digit button press code on the handlebars. Once unlocked, you need to move the bike forward enough for it to detect rotation of the wheels. As long as you spin both wheels within the countdown, it should stay unlocked. I’ve no advice for problem solving the kick-lock, unfortunately, it’s always just “worked” on our bike.

Wouter on 2024-10-19 wrote:

Hi Mike, Thanks for sharing all this information, much appreciated! Then a question, which charger (brand/model) for the single cells do you recommend? Br, Wouter

Mike Coats on 2024-10-28 wrote:

Hi Wouter, I used the same power supply to charge these cells as I did to charge the cell in the Smart Cartridge in my other blog post. It’s a “NANKADF” brand 30V 10A unit, available from Amazon. I’m sure a proper “branded” power supply would be better or more reliable but this one worked well for me. https://www.amazon.co.uk/gp/aw/d/B09C8LWV9W/ Cheers, Mike

Victor on 2024-11-02 wrote:

Hi Mike, During one of the repairs I came across a battery that was deeply discharged. The cells were just above 0.3V per group. I brought them back to 30V very slowly by 50mA, using also a lab supply. May I ask how discharged your cells were? I’m kind of hesitant to charge these deeply discharged cells back to 42 volts. What do you think? Thanks in advance! Victor

Mike Coats on 2024-11-03 wrote:

Hi Victor, None of my cells had gotten that low, I think all of mine were still about 1v. Was the whole pack uniformly discharged, or was it just one section that was as low as 0.3V? If the whole pack was at the same level, and it all seemed to charge back up to 30v without any thermal problems, I’d keep going to 42v. It sounds like you’ve followed the “pre-conditioning” processes detailed in this paper, so you should be fine to step up the current and do a normal CC/CV process up to final voltage. https://www.digikey.com/en/articles/a-designer-guide-fast-lithium-ion-battery-charging Obviously, keep an eye on the temperatures just in case any of the cells are damaged. Cheers, Mike

Carlos on 2024-12-13 wrote:

Hello Mike, I've noticed you have commented that there's a e-shifter simulation circuit to overcome the error 44 on Vanmoof bikes. Can you give me more information on it? Is it commercially available as a drop-in replacement somewhere? Thanks!

Mike Coats on 2024-12-13 wrote:

Hi Carlos, I'm afraid I've no more information at this stage. I've only recently picked up this work again, so I've not made much progress yet. I've started reverse engineering the e-shifter and I'll hopefully have a rough prototype ready in a couple of weeks. Getting something ready for wider use will take a while longer. Cheers, Mike

Austin on 2024-12-18 wrote:

Hi Lincoln/Mike, I have a VanMoof A5 with a dead battery. Were you ever able to figure out how to charge the battery? Thank you! Austin

Mike Coats on 2024-12-21 wrote:

Hi Austin, I'm afraid I'm not going to be much help. I've never even seen an A5 in person, let alone taken one to pieces. If you can work out how to remove and dismantle the battery, charging it will be broadly similar my experience here with an X3. Give the folks on Reddit a shout. They're normally pretty helpful folks. Cheers, Mike

Bringing a VanMoof X3 or S3 Back to Life – Part 1 – Smart Cartridge

2023-09-08T13:37:00+00:00

The VanMoof X3 was a perfect city bike for my partner but, after being stashed over winter, the battery had gone flat and it refused to take a charge. When this happens it’s possible that the bike’s charging circuits are detecting an “overly” discharged battery and are trying to protect the Lithium cells from damage. VanMoof’s bikes are technically clever but many of the components are proprietary and options for replacing or repairing parts are pretty thin on the ground.

In this technical support document, VanMoof let slip that there is a small secondary battery responsible for the electronics in addition to the primary battery used for driving the motor. I had a theory that perhaps this battery had gone flat which was in turn preventing the electronics in the Smart Cartridge from kickstarting the charging circuit for the main battery.

In this post I will lay out the steps and tools required to extract and deconstruct the Smart Cartridge from an X3 and recharge it’s small internal battery. These instructions, while not identical, will be understandable for owners of a VanMoof S3 not just the VanMoof X3 we own.

Before you start, follow the first half of this document from VanMoof to remove the Smart Cartridge from your bike. The video below is taken from that page. If you’ve removed all of the screws shown below but the Smart Cartridge still doesn’t want to slide out, remember there is one screw behind the seat tube that’s very easy to overlook.

Once you’ve got the Smart Cartridge free from the bike frame, you can take it over to your workbench for dismantling.

The real bulk of the Smart Cartridge is forward of the seat tube, so we first need to remove the extension that holds the rear light. A small flat-bladed screw driver can be used to turn the two plastic screws by 90 degrees, freeing the housing that hides the rear light’s power connector. The rear light can now be unplugged and removed. The rest of the seat tube extension can then be removed using a T6 torx screwdriver. There are two screws holding the top and bottom of the extension together and another two that hold the extension to the Smart Cartridge.

Now the Smart Cartridge has been stripped down to just the “brain”, you can open it up by removing the 8 T6 torx screws around its perimeter. When you separate the top from the bottom be careful as there are two sets of quite fine cables connecting the halves.

The main circuit board is connected to the dot-matrix display via the ribbon cable. This can be disconnected to give you more room to work, but is not necessary as long as you are careful not to damage the cable. The small Lithium-Poly cell is connected by the bundle of red, yellow and black wires. It can be removed from the top case by releasing the four clips. Unplug the connector from the main circuit board and you can remove the cell from the Smart Cartridge.

Carefully pull back the piece of foam and you’ll reveal the cell and you can read off its details. We will need this information to find a datasheet that can tell us how to charge the cell safely.

Searching the web for “iGreen Tech” didn’t give me any decent leads. There appear to be a number of companies around the world with that name, none of whom seem particularly relevant. Searching for “iGreen Lithium” does find one company that might be close, but it still didn’t get me any closer to a datasheet.

Instead, I tried a brute force search for all of the numbers on the cell, “922543 1050 3.7 3.89”. That was much more useful. It appears that 922543 is some sort of standard reference number for this kind of cell as many different “manufacturers” have sold 3.7V 1050mAh Li-Po cells with this code. I say “manufacturers” as it appears that a company called Shenzen BAK Technology will white-label their cell with your brand if you buy enough of them.

Further digging reveals that the Dubilier 922543 is compatible with the BAK 922543, so the datasheets should be similarly compatible. Finally, with all that in hand, I managed to track down a Dubilier datasheet for their 922543 Li-Po cell which matches our 3.7V 1050mAh specifications.

922543.pdf Download

With that datasheet available, it’s time to figure how to use the information contained within to charge the cell. This video from Dave Jones of EEVblog goes over all of the details on how to charge Lithium-Ion and Lithium-Polymer cells.

Having consumed all the theory behind lithium charging another video, again from EEVblog’s Dave Jones, has practical advice on charging Li-Ion and Li-Po cells with a bench-top power supply.

I have a NANKADF 30V 10A programmable supply, so following those videos combined with the datasheet, I set the power supply to 0.53A CC and 4.20V CV mode and connected the cell. At this point there is a danger that the cell may have been damaged by the excessive discharge and recharging it this way could result in a battery fire. I monitored the power and temperatures over the recommended 3.5 hours charging period and observed nothing untoward, indicating that the cell was good to put back in to operation.

Now the small Lithium-Poly cell is charged, reverse the tear-down process and rebuild the Smart Cartridge. If everything’s gone to plan the Smart Cartridge should spring back to life and indicate that it’s in “Shipping Mode”. There’s a good chance your bike decided to enter this mode when it originally detected the battery draining to try to prevent the batteries from getting “dangerously” low.

To get the Smart Cartridge out of shipping mode, follow the 3 step instructions in this VanMoof support document. That is, after re-inserting the Smart Cartridge in to the bike’s top tube, plug in your charging lead, press and hold the bike’s power button for two seconds, then short press any of the bikes handlebar or power buttons.

If an “unsafely” discharged Smart Cartridge was your only problem, your bike should reboot and begin to charge the primary battery in the bike’s down tube. If, however, your primary battery was similarly discharged to an “unsafe” level you’ll see the status light on the charging brick pulse red as it tries to start charging, but quickly return to green when the charge fails.

In Part 2 of this series, I detail the steps required to extract, dismantle and refresh the main battery pack.

Update — 2023-11-13

When I wrote this post, I didn’t want to include anything about how I physically connected my power supply to the battery as it was a bit of an off-the-cuff hack. However, I’ve since received a couple of comments asking from more information.

I just snipped the legs of a spare LED, bent them 90°, then inserted them in to the positive and negative places. The square profile of the LED legs meant they wouldn’t spin once connected, removing the risk of them shorting against each other.

I didn’t connect the centre pin as I didn’t have any facility for monitoring or logging that data. Since I was already using a CC/CV process and monitored the temperature of the cell during charging, I didn’t feel it was worth the extra effort.

I was worried that the “random” size of the legs might have subtly damaged the spring terminals within the plug, so I didn’t want to recommend that as a solution more widely. It appears that those batteries use standard Molex PicoBlade connectors which have an aperture of at least 0.5-0.7mm, so a standard LED leg of 0.5mm should fit just fine without any worry.

Comments

David Ellington on 2023-11-13 wrote:

Hi Mike, great blog, I found it really informative and helpful. One question though – when you connected to the Lab power supply, how did you connect it – through the fitted plug? or did you bare the red and black wires and connect crocodile clips to them?

Mike Coats on 2023-11-13 wrote:

Hi David, Thanks for your feedback and question. I’ve included an update at the end of the post to answer your question. Luckily, I still had a photo in my archives to provide some more detail too. Cheers, Mike

Elwyn Davies on 2023-11-13 wrote:

Hi. Could you tell me which wires you connected to the charger please. I assume it was the positive and negative, and did not connect the third wire?

Mike Coats on 2024-11-13 wrote:

Hi Elwyn, I’ve updated the end of the post to address your question. I only connected the positive and negative terminals, leaving the centre pin unconnected. Cheers, Mike

David Ellington on 2023-11-14 wrote:

Awesome, thanks – based om the information on your blog I have successfully recharged the battery in my smart cartridge. Unfortunately I’m still getting an error (ERR 6) so I guess I’m now going to move onto your Part 2.

Mike Coats on 2023-11-14 wrote:

Congratulations and commiserations! Good luck with the battery pack. It’s no more involved than the smart cartridge; it’s just a bit bigger so it takes a good bit longer to charge. Unfortunately, I’m now dealing with the dreaded Err44. If I had a spare/working e-shifter I’d be inclined to run a datalogger on the wires and try to reverse engineer the communications between it and the smart cartridge to see what I could come up with. Unfortunately, they’re like hen’s teeth.

Chet on 2024-02-22 wrote:

Hi Mike excellent write-up. It has given me the confidence to attempt repair. I got a similar bench power supply as in the picture. When charging, it started with cc-mode at 4.2v & 0.53A. How do I change to cv-mode as shown in the other picture? Thank you

Mike Coats on 2024-02-23 wrote:

Hi Chet, Thanks for your kind words, I’m glad you found this useful. To answer your question, the power supply takes care of the switch-over from CC mode to CV mode automatically. When you set the voltage and current values you’re in effect setting the maximum values the power supply will drive. When the cell is flat the voltage will be low, so the current draw will be pinned against your 0.53A current limit which puts you in constant-current mode. Once the cell reaches 4.2V the voltage limit has been hit so then it’s in constant-voltage mode. Cheers, Mike

Jon Bonesteel on 2024-07-25 wrote:

Hello Mike, These two posts have been very informative and helpful. I have disassembled my smart cartridge and it’s clear that the lipo battery is bulging and damaged. I’d like to replace it, but have not been able to find a source in the US. I only see the two wire variants on Amazon for example. Could you provide a tip on where I may be able to find one? Thanks in advance.

Mike Coats on 2024-07-26 wrote:

Hi Jon, It’s good to hear you found the posts useful. I’ve had a dig about and you’re right – US stockists of that battery are hard to come by. I found my datasheet on Farnell’s website, who are a part of Avnet, but it appears that Newark/Avnet don’t stock the same items. I couldn’t find anything from the usual suspects, either – Digikey, etc. It does look like something similar is available on AliExpress, which might be worth a try? https://www.aliexpress.com/item/1005006129387074.html In another listing the same company says, “If you are not sure whether the battery is suitable for your model, you can contact our customer service. Tell us your battery parameter model and size, we can customize the battery you need for you, thank you.” They might be able to put one together for you using the dimensions and values from the datasheet? Apart from that, I’m out of answers. Hopefully you get it sorted, good luck! Cheers, Mike

Jon Bonesteel on 2024-08-07 wrote:

Thank you for the reply Mike. I was able to locate the proper battery on eBay, charged it correctly, and sadly no luck. Installed the battery in the smart cartridge and it flashes the skull icon, then turns off. A reset of the system results in the same outcome. If I plug in the charger while the skull is flashing that icon flash turns off, but will not present the charge icon. I suspect the smart cartridge is damaged in some other way. Unless you have any insight on this, I believe I will just need to part out the bike. I am glad this has worked for some and really appreciate what you posted here.

Arie on 2024-08-21 wrote:

Hello Mike, Great explanation and really good instruction. Top Job!. I have a similar situation: a friend of mine asked if I could look at his battery (as I am the only one he knew who had a multimeter :-). I understand your explanation, but I do not own such a professional power supply. only a 12 Volt 20 amps Siemens unit. Would there any other way to do this?

Danny on 2024-08-31 wrote:

Hey, thanks for publishing this, it’s super approachable. After reaching out to several e-bike shops in the area, none of them are willing to try and fix the battery, so I’m going to try and do it myself. The part of this that I’m most concerned about is connecting the battery to the power supply. Would a molex 3-pin like this (https://www.amazon.com/Davitu-Electrical-Equipments-Supplies-PicoBlade/dp/B089K2WQJ5/ref=mp_s_a_1_24) hook up to the battery to charge a bit more securely? Thanks!

Mike Coats on 2024-09-09 wrote:

Hi Jon, Sorry for taking so long to reply – I’d missed the notification that you’d left a comment. It does sound like something more serious has happened to your smart cartridge. I’m afraid, I’ve never had to deal with a damaged smart cartridge, so I’m out of advice. If it’s of any consolation, I’m sure there will be people desperate to buy parts from your bike; the e-shifter in particular.

Mike Coats on 2024-09-09 wrote:

Hi Arie, Right… I whole heartedly DO NOT recommend this but, in theory, it might work. I would hook up the cell and aim for getting its voltage up to about 2.5V – 3V. You could then transfer the cell back to the smart cartridge and hope that’s within the range that the bike might recognise it and carry on charging – safely. 12V @ 20A is really dangerous though. I’d be worried about going much above 1A, maybe 2A, if you have a thermometer you can use to keep an eye on the cell’s temperature. You’re really abusing the cell at that point, so explosions and fires are possible if not likely. I’d try cannibalising an old USB power supply/cable; that would be much safer since you’d restricted to the 5V and 0.5A – 2A range.

Mike Coats on 2024-09-09 wrote:

Hi Danny, sorry for taking so long to reply – I’d missed the notification that you’d left a comment. Yes, that looks like it’s got the right sort of connector on it to let you plug in the battery. I hope it goes well for you, good luck!

Max on 2024-09-27 wrote:

Hi Mike, i had a go at manually charging this module myself, and I think I found an easier way. when you supply 24v and 1.5 A to the bike, instead of the normal 42 V, somehow the power goes directly to the battery, which needs 29000 mAh to let current pass through the battery. Vanmoof used to sell these power supplies to repair shops, but I made one myself by sacrificing a charger and soldering the end plug’s two wires to a 24v power supply, should save some effort!

Nicola on 2024-10-25 wrote:

Hello Mike, thanks for your guide, that is very useful. My 2023 Vanmoof S3 has a problem located in the smart cartridge. I’m pretty sure because the battery and the BMS have just been restored thanks to a reparations shop in Tilburg. I’m lucky because I have two smart cartridges: the new one (the only one connected with my phone) while plugged in, shows the shipping mode’s boat led blinking (charger LED is green). The second smart cartridge gets connected to the main battery but error 45 is shown and isn’t linked with my phone. The same shop doesn’t repair the smart cartridge and VM customer support is bouncing me… I’m looking for a technical help near Verona, Italy, because I’m not able to do it by myself. Any suggestion? Thanks in advance. Best regards. Nicola

Nini on 2024-10-27 wrote:

Hi Mike, my Van mood S3 has an error 41 which does not respond to a reset. I am non techno. Do you think it is fixable? Thanks

Mike Coats on 2024-10-28 wrote:

Hi Nicola, I’m afraid I live in the north of Scotland, so I don’t have any advice about getting help near Verona. My only suggestion is that Error 45 means the Smart Cartridge cannot talk to the wheel motor so I’d try disconnecting the cable to the wheel from within the fork and trying to clean the electrical contacts. It’s possible that road grime or water has gotten in there and is causing your problems. Sorry I couldn’t be more help, good luck! Mike

Mike Coats on 2024-10-28 wrote:

It looks like Error 40 and Error 41 are due to the bell and the boost buttons failing, usually due to rainwater getting in them. Someone’s written up a guide on iFixit on replacing the buttons, https://www.ifixit.com/Guide/VanMoof+S3+Bell+Button+Replacement/138539 and they’ve also given a link to a replacement button on Amazon https://www.amazon.co.uk/Gebildet-Latching-Lockable-Trumpet-Doorbell/dp/B07XQSBW7Q I’ve not tried, but it sounds like this should do the trick. Cheers, Mike

Mike Coats on 2024-10-28 wrote:

Thanks Max, that’s really useful to know!

Nini on 2024-10-28 wrote:

Thanks Mike, looks too technical for me, so its off to Holy Spokes! I do hope it’s fixable. As an aside can water get into the smart cartridge from the cross bar and cause damage, or are those little holes sealed? My bike got really wet the other day and that’s when the error 41 started.

Mike Coats on 2024-10-31 wrote:

Water shouldn’t really be able to get in to the Smart Cartridge. There aren’t any holes in the top, the dot-matrix display has a reasonably decent seal and only lets light through. If you rode through a **really** deep puddle, there’s a chance you could spray some up around the power button/charge port area but you’d have to be really unlucky to get enough water up there to do any damage.

Nicola on 2024-11-10 wrote:

Thank you, Mike! You are very kind. Happy Sunday

Mariusz on 2024-12-10 wrote:

Cześć, Zwracam się z prośbą o pomoc w sprawie mojego Vanmoof S3 który nie chce połączyć się z aplikacją w telefonie… Czy macie pomysł czym to może być spowodowane? Z góry dziękuję za pomoc. Pozdrawiam, Mariusz

Machine Translation of Mariusz on 2024-12-10 wrote:

Hi, I'm asking for help with my Vanmoof S3 which won't connect to the app on my phone... Do you have any idea what could be causing this? Thanks in advance for your help. Best regards, Mariusz

Mike Coats on 2024-12-12 wrote:

I'm sorry Mariusz, but I don't. There are too many variables at play when it comes to the app communication. It could be the Bluetooth connection. It might be the bike/app encryption keys. The bike might have lost its memory and lost its pairing information. It's almost impossible to diagnose. You just kind of have to try everything and hope for the best. Maybe ask on Reddit and see if anyone there can help?

Radxa Rock 5B as a Raspberry Pi replacement?

2023-09-01T13:37:00+00:00

In December 2022, the Raspberry Pi Foundation set about burning a large amount of the good will they had built up in the hacker community. They announced that they had hired an ex-cop who had used their products to spy on members of the public.

For those outside of the UK, or the left-leaning section of its citizens, this probably seemed fairly harmless. However, UK policing has been undergoing some pretty damning self-reflection after overstepping the mark, by quite a distance, on more than one occasion.

When challenged on the tone of their announcement, the Raspberry Pi Foundation’s social media and PR teams doubled down, attacked their critics, and started spreading straw-men to the press covering the outrage.

I, like many others, decided we could no longer support that organisation and that it was time to look elsewhere for our single-board computers and hackable hardware.

Enter Radxa Rock 5B

In early 2023, the Rock 5B from Radxa seemed to poised to take the Raspberry Pi’s crown for the best SBC for Linux on desktops. I promptly ordered one from China and eagerly awaited its delivery. Life “got in the way” for a bit and it wasn’t until this summer that I managed to sit down and get to grips with it. Immediately, I stumbled on to this devices biggest caveat – powering it on.

As can be found all over Radxa’s forums, people have a tough time powering this board. According to the Armbian project’s documentation, almost all Rock 5Bs in the wild have a firmware that isn’t able to negotiate USB Power Delivery and then hand over to Linux during boot up, resulting in an infinite brown out and reboot loop. There are updated firmware blobs and instructions available that once installed do appear to correctly handle USB-PD, but these cannot be installed until the board boots. Catch 22!

The solution to this is to boot the device using a “dumb” power supply that just provides the volts and amps without negotiation, flash the new boot firmware, then use a proper, standards-abiding power supply. I did not have any USB-C power supplies that acted in “dumb” mode, so instead I set up my NANKADF 30V/10A Programmable Power Supply to supply 5V at 3A and hooked it up to the Rock 5B via a USB-C break-out cable.

Using this combination lets the board start up and get all the way through to a log in prompt. During boot, the board peaked at a draw of almost 2A, but once it all settled down it dropped to less than 1A.

Now that the system’s up and running, the firmware can be upgraded by downloading a new image and following the instructions from the Radxa wiki. Once the new firmware’s flashed, you should be able to shutdown and restart the board with a proper USB power supply. Initially, I used a Samsung EP-TA200, a QuickCharge/Adaptive Fast Charging adapter which gives 15W, but only at 9V. At 5V, it will only supply 2A which was fine for most tasks, but once I’d logged in to a KDE desktop session, started a full apt update and begun editing some files in VSCode it must have pushed the supply beyond 2A and reset. Subsequently, I’ve moved over to an Anker A2039 which can supply the full 3A at 5V and since then I’ve never had a single hiccup.

Would I buy one again?

No.

Just don’t. It’s not worth the hassle.

If you find yourself in my shoes and have already bought the board but don’t have a fancy desktop power supply and various connectors, I’d skip all the compatibility lists on the Wiki and buy a barrel-plug 5V 3A power supply and a matching barrel-socket to USB-C plug like these two available from Amazon.

What would I buy instead?

When I picked up the Rock 5B, it was the only RK3588 based board that came with 16GiB of RAM. A similar board which I use as my router running OpenWrt is the NanoPi R6S from FriendlyElec which is also RK3588 based but only comes with 8GiB of RAM. It’s been flawless in operation and a breath of fresh air to flash, install and maintain compared to the Rock 5B. FriendlyElec have since come out with the NanoPC-T6 which has an option to buy it with 16GiB of RAM. That’s what I’d pick instead of the Radxa Rock 5B.

Installing OpenWrt on a Unifi AP AC Lite in 2023

2023-07-25T13:37:00+00:00

OpenWrt is a very powerful OS and can be configured to be much more useful and capable than just an access point, but these instructions assume you have other devices on your network handling those duties. Our goal here is just to replace the OS on the Unifi AP AC Lite with OpenWrt, leaving the AP to only handle wireless connectivity to the rest of your network.

Before you start

Make sure you’ve got some empty IP addresses.

Unifi APs use 192.168.1.20 if they are not assigned addresses by DHCP
OpenWrt uses 192.168.1.1 regardless of DHCP and any existing equipment, so you might get a clash with an existing router

Make sure you take a note of your Unifi network’s SSH username & password. Once you begin the process, you will not be able to manage them from the Unifi controller. Out of the box, they’re ubnt:ubnt, but either through upgrading or twiddling over the years, mine were not that anymore. You can find them in the System Settings page, under Network Device SSH Authentication.

Downgrade the Unifi AP AC Lite

According to the OpenWrt Wiki, recent versions of the Unifi AP firmware have disabled write access to certain flash sections and removed some of the tools necessary for installing OpenWrt. These updates will hinder the installation process of OpenWrt. The easiest workaround for these restrictions is to downgrade the firmware to a version that predates the implementation of these protections. However, it is unclear which specific protections were introduced in which firmware versions. Therefore, to ensure a comprehensive approach, I recommend downgrading to the earliest available firmware version. As of July 2023, the earliest firmware version available on Ubiquiti’s site is v3.7.58. Click the Download button and then click through the EULA popup to view the download URL for the firmware. At the time of writing, it can be found at https://dl.ui.com/unifi/firmware/U7PG2/3.7.58.6385/BZ.qca956x.v3.7.58.6385.170508.0957.bin.

You now need to find your Unifi AP AC Lite in your Unifi console and navigate to the Location URL field in the Settings > Manage menu. Paste the link to the .bin file in the Location URL field, hit Update, and follow the prompts. The Unifi console will display a scary looking popup that asks you to confirm you’re happy to install firmware from a custom location and that there may be compatibility issues after installation. Hit Confirm on this message and the Unifi AP will reboot automatically once it completes installing the firmware.

The “compatibility issues” mentioned in that message appear to include a problem where the old firmware is unable to connect to the up to date console, so from this point on the Unifi console will be unable to adopt or configure the Unifi AP AC Lite. All configuration from this point on will be via SSH. Once installation has complete and the Unifi AP AC Lite has rebooted, if you have a DHCP allocation set , it will start up and respond on that address, otherwise it will use its default address, 192.168.1.20.

Install the OpenWrt firmware

To install the OpenWrt firmware, connect to the Unifi AP with SSH. The SSH server that’s included in v3.7.58 is pre-LogJam, so it only offers old, out of date key algorithms. Depending on how up to date your SSH client is, it may not support these algorithms by default. If so, you’ll see the following error message.

$ ssh ubnt@192.168.1.20
Unable to negotiate with 192.168.1.20 port 22: no matching host key type found.
Their offer: ssh-rsa,ssh-dss

To connect to an older SSH server such as this, you have to manually specify an acceptable key algorithm, using the HostKeyAlgorithms option. If successful, you should see a number of messages or banners scroll by and be presented with a BZ prompt that includes the downgraded firmware version.

$ ssh -oHostKeyAlgorithms=+ssh-dss ubnt@192.168.1.20
[...]
BZ.v3.7.58#

Once connected, you’ll need to download the latest suitable OpenWrt firmware to the Unifi AP. According to the OperWrt hardware wiki, as of July 2023 the latest version is 22.03.05, compiled for the ath79 target and packaged for the AC Lite. You can download it using the curl command, which I have split over multiple lines for readability here.

BZ.v3.7.58# curl \
> https://downloads.openwrt.org/releases/22.03.5/targets/ath79/generic/\
> openwrt-22.03.5-ath79-generic-ubnt_unifiac-lite-squashfs-sysupgrade.bin \
> >openwrt.bin
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6208k  100 6208k    0     0   339k      0  0:00:18  0:00:18 --:--:--  602k

APs like the Unifi AP AC Lite do not have storage in the form of HDDs or SSDs, but as embedded flash chips known as MTDs. This means we’re not going to write our image to a partition such as /dev/sda like you would when flashing an SD card for a Raspberry Pi. Instead, we deal with MTD character devices such as /dev/mtd4 or we can use the mtd tool to operate on the devices for us. To see the equivalent of the MTD’s partition table, you can look in the /proc/mtd file.

BZ.v3.7.58# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00060000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00790000 00010000 "kernel0"
mtd3: 00790000 00010000 "kernel1"
mtd4: 00020000 00010000 "bs"
mtd5: 00040000 00010000 "cfg"
mtd6: 00010000 00010000 "EEPROM"

Unifi APs have two “partitions” that can have images written to them, kernel0 and kernel1, to allow Ubiquiti to be clever and roll-back to a previous image if an upgrade fails. OpenWrt does not have this ability and is can only boot from the first of the two “partitions”. We will therefore use the mtd tool to write our openwrt.bin file to the kernel0 partition.

BZ.v3.7.58# mtd write openwrt.bin kernel0
Unlocking kernel0 ...

Writing from openwrt.bin to kernel0 ...

At this point, you have successfully written OpenWrt to the first “partition”, but Unifi’s OS will still be installed to the second one. We can use the mtd tool to erase the second “partition”, kernel1, leaving only OpenWrt installed on the AP.

BZ.v3.7.58# mtd erase kernel1
Unlocking kernel1 ...
Erasing kernel1 ...

Finally, we need to let the Unifi AP AC Lite know which “partition” to boot in to. This is done by writing a single 0 byte to the boot selector or “bs” partition in order to indicate kernel0. In an earlier command we saw that the mtd4 character device contained the “bs” partition, so we can use dd to write the single 0 byte.

BZ.v3.7.58# dd if=/dev/zero bs=1 count=1 of=/dev/mtd4
1+0 records in
1+0 records out

The only piece of Unifi’s OS that’s left is what remains in the Unifi AP AC Lite’s RAM. Rebooting the AP now will restart the device and load OpenWrt as the AP’s OS.

BZ.v3.7.58# reboot
Connection to 192.168.1.20 closed by remote host.
Connection to 192.168.1.20 closed.

Configure OpenWrt

Your Unifi AP AC Lite has now rebooted, launched OpenWrt and is listening on the IP address 192.168.1.1 over it’s ethernet port.

To begin setting up your AP, log in to LuCI, OpenWrt’s web-based admin panel, on http://192.168.1.1/cgi-bin/luci/. Your new admin username is root and, by default, the password is simply password. This can and should be changed in the “Router Password” tab on the the System > Administration page.

The next step is to change your AP’s IP address as it will probably either be clashing with your normal router or be entirely incorrect for the rest of your network; this can be set in the Network > Interfaces page. Choose the lan device on that page and press the “Edit” button. On the dialog that pops up you can either replace the static IP address with one of your own choosing or switch to an allocated address by selecting “DHCP client” from the “Protocol” drop down.

As OpenWrt is designed to support many different powerful router configurations, Dnsmasq is installed, enabled and started by default and provides DNS and DHCP for IPv4 networks. Odhcpd is also installed, enabled and started by default and provides RA and DHCP for IPv6 networks. Since we want to use the Unifi AP AC Lite as just an access point, we must stop and disable both of these services.

The last part to configure your AP is to add the SSIDs you want to broadcast. Unifi AP AC Lites have two radios onboard, an 802.11a/c/n radio broadcasting on 5GHz and an 802.11b/g/n radio broadcasting on 2.4GHz. Adding SSIDs is accomplished by pressing the “Add” button next to each and filling out the required fields. If you want to broadcast the same SSID on both frequencies to allow clients to migrate between them, you’ll need to create two identical SSIDs, one for each radio.

Finally, you’ll need to save and apply the changes your made above. This can be done by pressing the “UNSAVED CHANGES” link found in the top-right of the web admin panel. This will present you with a text based version of all the changes you have made, allowing you to confirm you’ve not made any typos and apply the configuration.

What next?

Sit back and enjoy your AP, you weird nerd! Alternatively, start to dig in to the OpenWrt documentation to expand on the ideas in this post. For example, I hope to cover band steering, 802.11r, 802.11k & 802.11v fast transition roaming and 802.1X access controls in subsequent, upcoming blogposts.

Weeknotes for 9th December 2019 – 15th December 2019

2019-12-21T13:37:00+00:00

Fàilte agus tapadh leibh, a charaid!

This one’s a little late, but it’s finally here; another #weeknotes report! This week was a different one for me as it was focused on learning rather than building.

SEPA Visit

On Monday and Tuesday, a group of us from NatureScot went to visit one of our sister agencies, SEPA, as they’ve just released three new applications.

They’ve developed these applications following the Digital First Service Standard and as we’re about to build and release our own applications under it’s successor, the Digital Scotland Service Standard, we were interested in discovering any lessons they had learned along the way. It was a really useful visit and we left with a lot to think about and to take in to our planning sessions.

Tha thu sgoinneil! Is toil leam cèic agus cofaidh.

The rest of the week, as if you couldn’t guess, has been taken up with learning Gaelic with Duolingo. The Daily Gael set up a campaign back in February to get Duolingo to support Gaelic learners with a course, and in November they went live. Ever since, I’ve been logging in everyday to get my practice in. Hopefully, I’ll soon be able to impress my office mates from Bòrd na Gàidhlig at the tea point with a bit of “Am bu toil leat cofaidh?”

Weeknotes for 2nd December 2019 – 8th December 2019

2019-12-08T13:37:00+00:00

In an effort to keep my blogging momentum up, here’s my third consecutive #weeknotes post. As in past weeks, I’ll be rounding up any of the interesting things I’ve been searching for on the internet.

🔎 advent of code

For the past few years, every December, Eric Wastl has run a series of coding challenges called Advent of Code. These work like an Advent Calendar, with a new challenge becoming available each day. They can be solved using any tools or programming languages you want, so I have chosen NodeJS & regular JS to keep the tooling to a minimum. I started off strongly, but I’ve not had enough time to dedicate to it yet and I’ve started running behind. To keep an eye on my progress, you can follow my GitHub repo, here.

🔎 mdn reduce && 🔎 mdn biggest number

One of the Advent of Code challenges had us searching for the smallest number in a list of results. My favorite aspect of programming in JavaScript over many other languages is it’s ability to work with lists and arrays, gained from its functional programming roots. This lets us process arrays using concepts like map and reduce giving us the following snippet for retrieving the smallest item from a list.

console.log([1, 2, 3, 4, 5].reduce(
    (prev, curr) => Math.min(prev, curr),
    Number.MAX_VALUE)
);

I used Number.MAX_VALUE as the initialValue in the reduce call as that’s the largest number JavaScript can hold; any other given value must be smaller than it, making it an ideal starting point for finding minimums in a list. Number.POSITIVE_INFINITY is also available, and could even be a better choice due to the Number.isFinite() method to make sure we’ve actually found a smaller number.

🔎 mdn spread operator array copy

When I was prototyping an answer for another challenge, I found myself needing to create a copy of an array, not just a reference to it, and the spread operator is great for that. It creates a new array with all of the original array members contained within.

const testArray1 = [1, 2, 3, 4, 5];

const testArray2 = testArray1;
testArray2.push('Everywhere');

const testArray3 = [...testArray1];
testArray3.push('Just Here');

console.log(testArray1); // [ 1, 2, 3, 4, 5, 'Everywhere' ]
console.log(testArray2); // [ 1, 2, 3, 4, 5, 'Everywhere' ]
console.log(testArray3); // [ 1, 2, 3, 4, 5, 'Everywhere', 'Just Here' ]

🔎 git change old commit messages

Working as a full-stack developer often means fixing bugs or adding features that cross both the front-end and back-end systems. At work, we follow Chris Beams’ seven rules for git commit messages, which means ending our messages with references to the issues that the piece of work was for. Jumping between different repos for front and back-ends can result in the front-end commits being tagged with the back-end issues and vice-versa. To fix this, and re-write a series of commit messages, you can take advantage of git’s interactive rebase mode, and rewrite the last, say, 3 messages by using the following command.

$ git rebase -i HEAD~3

You will then be presented with a summary listing those commits.

pick 55f9d3e Advent of Code 2018, Day 1, Stars 1 & 2
pick d577864 Advent of Code 2019, Day 2, Star 1
pick 62de55e Advent of Code 2019, Day 2, Star 2

Changing each of those picks (which would just use the commit as-is) to rewords tells git to accept the code changes, but re-write the commit messages, allowing you to fix your incorrect issue references.

reword 55f9d3e Advent of Code 2018, Day 1, Stars 1 & 2
reword d577864 Advent of Code 2019, Day 2, Star 1
reword 62de55e Advent of Code 2019, Day 2, Star 2

Weeknotes for 25th November 2019 – 1st December 2019

2019-12-02T13:37:00+00:00

For my second #weeknotes blogpost, I’ve continued with last weeks “theme” of collecting up my browser searches and publishing the interesting bits. I spent most of my time this week either in meetings or at home waiting for a heating engineer, so I didn’t actually have much time to do any searching for cool projects and instead I just ticked along some existing projects.

🔎 vscode browser & 🔎 code-server

As part of my ongoing effort on turning an iPad into a ‘proper’ computer for development, I continued searching for a way to run an IDE like vscode remotely from my home server. This week I came across the code-server project which runs a ‘full’ copy of vscode in a browser tab. Interestingly, it can be run in a docker container and connected over an HTTPS reverse proxy, providing a secure connection to an editor hosted on my own server.

To test this program out, I set it up as a container on my laptop and launched it in Firefox. I then put the tab in fullscreen mode and used it to edit this blog post. It worked! It’s not quite the same as running the editor on my server and editing on the iPad, but it’s getting pretty close. I even managed to bring up the interface on my iPhone and enter some text, but the small display, coupled with the on-screen keyboard meant it wasn’t really a go-er.

[][5]🔎 logitech slim folio & 🔎 brydge keyboard

The iPad’s on-screen keyboard takes up a fair amount of vertical space and isn’t really suitable for long typing sessions, especially for coding with all of the required alternative characters, etc. Really, I’m on the lookout for a physical keyboard to go along with the iPad. I’ve pretty much dismissed Apple’s Smart Keyboard straight away as it has zero key travel. I thought it felt terrible after 1-2 minutes use in the Apple Store, so I can only imagine I’ll hate it even more after any serious coding sessions. I also spend a lot of my time typing on my lap and I don’t like how flimsy the ‘laptop’ mode appears. It just seems a bit too ‘floppy’ for my liking.

To work around this, I’ve done some searching and discovered the Logitech Slim Folio Pro and the Brydge Pro. Both of these devices appear to do what I want, but both appear to have some tradeoffs when put head-to-head with one-another. I’ll need to see if any shops near me have some in stock and get a hands-on test with them, but until then I’ll just have to check out any reviews I can find.

Weeknotes for 18th November 2019 – 24th November 2019

2019-11-25T13:37:00+00:00

I’ve followed a few digital government folk like @edent on twitter for a while and seen their #weeknotes approach to blogging, so I’ve decided to dip my toe in and write a little post about what I’ve been up to this past week.

It can be difficult to remember everything you did if you don’t deliberately keep notes, but the one thing that was keeping notes all week was my browser history. Reviewing your browser searches can be quite enlightening, revealing things that tripped you up or that you needed help with.

🔎 roku sdk, 🔎 brightscript & 🔎 windows 95 star field

On the 17th Nicole He posted up a thread on twitter showing the truly bizarre and kinda-probably-NSFW collection of screensavers available for installation on Roku devices. I didn’t even realise that screensavers for your Roku were a thing or that custom ones were available. I immediately signed up for a developer account, of course, and started work on bringing a late 90’s classic back from the dead and on to my TV screen.

🔎 oracle regular expression & 🔎 regexp_like

We’re continually updating and upgrading our applications at NatureScot, and an integral part of that work is data migration and management. I had to wrangle some ‘stringly-typed’ numbers this week in our Oracle database and so I got an opportunity to flex my regular expression muscles. Luckily for me, it didn’t turn in to two problems.

🔎 angular template reference variable, 🔎 ngcontent & 🔎 ControlValueAccessor& HtmlInputElement

At NatureScot, we develop our applications like SiteLink using the Angular framework. To keep our UIs and UXs consistent between applications, I’ve been looking at what’s required to put our commonly re-used components in a library available for re-use across the organisation.

🔎 httpstatuses

Creating and working with RESTful services mean you need to have a pretty decent knowledge of the HTTP status codes. I can never keep track of the higher-numbered 4xx errors, which is why I like this HTTP Status Codes site.

🔎 metalsmith, 🔎 handlebars stringify & 🔎 json stringify circular

I had previously used Metalsmith for this blog – then WordPress and it is now built with Zola. I’ve written this blog using the static site generator Metalsmith and to get to grips with the data structures it creates on its journey from markdown to HTML I was looking at a way to dump the current page’s object to the HTML. This brought to light an interesting point that JSON.stringify cannot handle javascript objects that contain circular references, but console.log can. Something to remember for the future!

🔎 unicode arrow, 🔎 html5 unicode, 🔎 html5 semantic elements, 🔎 mdn date localedate

As part of my blog’s redesign I was looking at ways to embed forward and backward arrows for post-to-post navigation and how to get some ‘pretty’ looking dates displayed on the home page. I can never remember the proper way to embed a hex reference to a unicode character in HTML. It’s &#x????;, by the way.

🔎 remount usb rw & 🔎 linux mount hfsplus ignore user

I was doing some tidying one evening and came across a couple of old USB memory sticks that I had no idea what, if anything, was on them. It turned out they were from back when I ran OS X/macOS on my laptop, so getting access to them to back up the files and wipe the drives took a little bit of effort.

🔎 jess frazelle docker firefox, 🔎 vscode x11 forwarding & 🔎 web vnc

I’m a techie at heart, and I’m always on the look-out for new, hacky, ways to set up my environment. I’d love to be able to work properly from an iPad, and I’m 90% there with Prompt connecting to my Linux server, but I’ve not got a good solution for very interactive GUI applications yet. I’ve followed Jessie Frazelle on twitter for a few years and I could remember that she had written a blog post about running desktop programs like Firefox in docker containers. If I could spin up an application in a container then I could deploy that to my Linux server and use it as headless terminal.

I managed to get Mocha X11 on my iPhone to connect to my Debian laptop and launch vscode from there to display on my phone’s screen. It didn’t appear to work at first, as each time I connected using Mocha, the new copy of vscode appeared on my laptop screen and not my phone screen. I eventually realised that vscode was sharing some sort of ‘session’ and launching subsequent copies as extra windows on the first copy – not as wholly new processes. Killing all vscode instances and trying once again from the phone worked a treat.

It turns out that vscode isn’t a great application to run over X11, probably because it’s an electron app, so rendering is handled in a very non-X11-efficient way. I tried launching KeePassXC instead and it performed a lot better.

In my further searching around the idea of web vnc I came across Apache Guacamole, which looks quite promising as a method of accessing applications remotely. If I can set it up as some kind of gateway to allow access in to my dockerised desktop applications, I might be on to something.

Missing Maps #mapathon @ NatureScot

2018-12-31T13:37:00+00:00

One of the perks of working for NatureScot is that they encourage you to take a day per yea and volunteer on a charitable project. This year some of the staff from our GIS team organised a number of Missing Maps events, one of which I was lucky enough to find a place on.

In case you’ve never heard of Missing Maps or the work they do, I’ve included a link to a short video here.

We kicked off the event by getting everyone set-up with accounts on OpenStreetMap and watched a couple of quick video tutorials to get us up to speed with the kind of tasks we’d be spending the day completing. We then looked at the beginner level projects available on the HOT Tasking Manager and decided to work together on Project #5529. When we picked it, it was a high priority project with very little mapping completed on it. We felt we could make a real impact here by dedicating 19 volunteers’ time across both morning and afternoon sessions.

Tina from the GIS team posted to their twitter account throughout the day, including the following photo of us all deeply focussed on spotting and annotating buildings across Tanzania.

As a team, we managed to contribute a 12% boost to the project’s mapping goal and even more importantly there are an extra 19 trained and engaged volunteers out there contributing to the project in their spare time.

The idea of contributing to OpenStreetMap can be quite intimidating to new users, particularly when you know people will be referring to your maps in the field to assist in their humanitarian works, but it’s really not that difficult and you get to make a real difference.

If you’re still apprehensive, Missing Maps have a list of public events similar to our day on their website.

Personal Weather Forecast

2018-12-29T13:37:00+00:00

tl;dr Personal Weather Forecast iswas a small JavaScript program that mashes together Dark Sky’s API with Twilio’s APIs to produce a personally tailored weather forecast and sends it to you as a text message every morning. The source code is available as a project on GitHub, here.

If you want to receive your own personal weather forecast every morning…

check out the repository to a computer you’ll leave switched on—such as a virtual server from Mythic Beasts, or a RISC-V based Single Board Computer
create a script similar to the one below
save it somewhere accessible from your logged-in user on your server, such as ~/bin/forecast-sms.

#!/bin/sh

export DARKSKY_KEY=[your-darksky-key]
export DARKSKY_LATLONG=[the-location-for-the-forecast]
export TWILIO_ACCOUNT=[your-twilio-account-sid]
export TWILIO_TOKEN=[your-twilio-auth-token]
export TWILIO_FROM=[your-twilio-phone-number]
export TWILIO_TO=[your-destination-phone-number]

pushd /[repo-location]/personal-weather-forecast >/dev/null
node main.js
popd >/dev/null

To make it run every morning, you should edit your user’s crontab which with the following command…

$ crontab -e

…and add the following line…

0 7 * * 1-5 ~/bin/forecast-sms

…which references the location of the previously saved script. This cron entry means that every Monday to Friday morning at 7am you’ll receive your very own personal weather forecast!

Trump is Big Boss

2017-07-18T13:37:00+00:00

tl;dr Trump Is Big Boss iswas a silly little program that randomly generates fake tweet screenshots that attribute quotes from Metal Gear’s Big Boss to @realDonaldTrump.

The source code for the bot is shared as a project on GitHub, and the resulting tweets ~~are~~were posted to the parody account here.

This script is forked from my first proper Twitter bot, The Jeremy Kylebot. The quotes the bot uses to generate tweets were originally ripped by the user Nekura_Hoka on GameFAQs, whose complete rip can be found on the GameFAQs website.

Examples

Fork Your Own Repo on GitHub

2017-07-04T13:37:00+00:00

A common time-saving ‘hack’ of mine when building ‘new-but-related-to-old’ projects is to fork an existing code base and use it as the boot-strap for the new project. GitHub, however, does not provide the functionality on their website to fork your own project; you can only fork other people’s projects. Here’s how to work around that.

Create the new destination project on GitHub.

Create a new directory on your local computer to hold the new repository.

~$ mkdir test-project-2

~$ cd test-project-2

~/test-project-2$ git init .
Initialized empty Git repository in /home/mike/test-project-2/.git/

Add the new project as the origin remote and the old project as the upstream remote.

~/test-project-2$ git remote add origin https://github.com/MikeCoats/test-project-2.git

~/test-project-2$ git remote add upstream https://github.com/MikeCoats/test-project-1.git

Pull the code from the upstream project.

~/test-project-2 $ git pull upstream master
remote: Enumerating objects: 3, done.remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/MikeCoats/test-project-1
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> upstream/master

Push it to the origin project.

~/test-project-2 $ git push origin master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 881 bytes | 881.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/MikeCoats/test-project-2.git
 * [new branch]      master -> master

Congratulations! You’ve successfully forked your own repo on GitHub!

Jeremy Kylebot

2017-06-27T13:37:00+00:00

tl;dr Jeremy Kylebot iswas a silly little program that randomly generates title cards in the style of The Jeremy Kyle Show and posts them to Twitter.

The source code for the bot is shared as a project on GitHub, and the resulting tweets ~are~were posted to the parody account here.

I tried to make the format of the show titles match the look-and-feel of genuine episodes, while at the same time I made the subject of the titles as ludicrously “British” as possible.

Examples

Intruder Alert

2013-05-09T13:37:00+00:00

For a quick lunch-time electronics project, I’ve constructed an intruder alarm that can alert you any time somebody comes too close to your desk or cubicle. This project took me 45 minutes from start to finish including all coding, wiring and testing so—provided you’ve already got your lunch and eat it quickly—you too can be alerted to approaching co-workers before your lunch hour is up.

Using an Arduino for this project is overkill, as we could easily accomplish the same result without using a micro-controller at all, but it is a good introduction to using analogue electronics with the board.

In this project I’ve connected an ultrasonic range finder, a potentiometer and an LED to an Arduino to form a basic intruder alarm. The potentiometer acts as a threshold so you can easily tune the performance of the ultrasonic range finder to your local environment.

Very simply, every time the value from the ultrasonic range finder drops below the potentiometer’s threshold value, an alarm is triggered. In this case the alarm is an LED, but it could easily—if you wanted to annoy your cubicle neighbours—be something like a buzzer. If your Arduino is connected to a PC, you can also use the serial monitor to read the debug information of the two analogue devices.

This isn’t really a tutorial on how to use an Arduino but more of an example of what can be quickly accomplished by connecting a few simple components together and throwing a wee bit of code at a problem. If you want to build your own—or just look closer at how I built mine—keep reading for a BOM, Source Code and Schematic.

Bill of Materials

Qty	Item	Source	Cost
1 no.	Arduino Uno – R3	CoolComponents	£19.98
1 no.	Ultrasonic Range Finder	CoolComponents	£24.48
1 no.	10 kΩ Linear Pot	CoolComponents	£ 1.44
1 no.	5mm Red LED	CoolComponents	£ 0.40
1 no.	220Ω Resistor	CoolComponents	£ 0.06
12 no.	Jumper Wires	CoolComponents	£ 3.59
2 no.	Mini Bread-board	CoolComponents	£ 1.44

Fritzing Schematic

Arduino Sketch Source Code

GitHub Gist

mikecoats.com

Stop the WANPTEK/NANKADF power supply's beeps

Problem

Solution 1 - Turn off the beeps in the menu

Solution 2 - Remove the beeper from the PSU

Low Tech Prototyping

GNU Terry Pratchett

VanSpoof – A-Muntzing We Will Go

Simplify VCD

VanSpoof - Prototype 2 - Echo Firmware

VanSpoof - Prototype 1 - Firmware

VanSpoof - Prototype 1 - Hardware

Next Trains

Reverse Engineering a VanMoof e-shifter – Part 2 – Decoding the Signals

Is the bike the requester, or is it the responder?

What speed and format was that data?

What messages are being transmitted?

Reverse Engineering a VanMoof e-shifter – Part 1 – Connectors and Connections

Introducing Spy! Break! Inject!

Make Cisco Catalyst 2960-X switches run almost silently

Problem

Solution 1 - Disconnect internal blower fan

Solution 2 - Replace internal blower fan

Comments

Leaving WordPress for Zola

Caveats

Debian Packaging from First Principles – Part 2 – Dependencies

Impossible Dependencies

Plain Dependency

Mutual Dependencies

Connecting to Serial Ports with Windows Terminal

Poison the WeLLMs

It does what?

What does that look like?

How does it work?

See it in action

aa-sms – Send messages from Rust with Andrews & Arnold’s SMS API

#NewMusicMonday – Kiasmos & Warrington-Runcorn New Town Development Plan

Debian Packaging from First Principles – Part 1 – Simple .deb

deb Format

ar Archive

debian-binary

control.tar

data.tar

our-package.deb

Installing and Removing

Bug Fixing

Recover a single drive from an abandoned RAID 1 mirrored pair

#NewMusicMonday – Mammoth Weed Wizard Bastard & Slomatics

STM32 to Blinky with Rust – Part 3 – HAL and Blinky

STM32 to Blinky with Rust – Part 2 – Development and Debug Toolchain

#NewMusicMonday – Cheap Dirty Horse, The Masochists and a (dis)honourable mention

STM32 to Blinky with Rust – Part 1 – Hardware – STM32F407G-DISC1

#NewMusicMonday – Alkanes, Broadsea & PaperSailor

Data loss: A blind-spot in my backup strategy

Stacking Loyalty Schemes for Extra Discounts

What is Gregg Wallace doing?

The Greg or Ian Calendar

Bringing an Apple AirTag Back to Life

SQLite Adventure

Bringing a VanMoof X3 or S3 Back to Life – Part 2 – Battery Pack

Comments

Bringing a VanMoof X3 or S3 Back to Life – Part 1 – Smart Cartridge

Update — 2023-11-13

Comments

Radxa Rock 5B as a Raspberry Pi replacement?

Enter Radxa Rock 5B

Would I buy one again?

What would I buy instead?

Installing OpenWrt on a Unifi AP AC Lite in 2023

Before you start

Downgrade the Unifi AP AC Lite

Install the OpenWrt firmware

Configure OpenWrt

What next?

Weeknotes for 9th December 2019 – 15th December 2019

Fàilte agus tapadh leibh, a charaid!

SEPA Visit

Tha thu sgoinneil! Is toil leam cèic agus cofaidh.

Weeknotes for 2nd December 2019 – 8th December 2019

`ar` Archive

`debian-binary`

`control.tar`

`data.tar`

`our-package.deb`