Chameth.com - posts like filament-weight-display, infinite-avatars, why-you-should-be-using-https but not migrating-from-github-to-forgejo

Making a font of my handwriting

2025-08-08T00:00:00Z

Recently I’ve been on a small campaign to try to make my personal website more… personal. Little ways to make it obvious it’s mine and personal, not just another piece of the boring corporate dystopia that is most of the web these days. I don’t quite want to fully regress to the Geocities era and fill the screen with animated under construction GIFs, but I do want to capture some of that vibe.

I’d added some bits and pieces along those lines: floating images in articles now look like they’re stuck to the page with sellotape, related post links have a wavy border that animates when you hover over them, and so on. Next, I wanted to change the heading fonts from a monospace font to something cursive, to resemble handwriting. Less terminal output, more handwritten letter. I couldn’t find one I liked, though. So why not make my own? It can’t be that hard, right?

Failing to do it myself

I set out to try to make the font myself using open source tools. After doing a bit of research, it seemed like the general approach was to create vectors of each character and then import them into a font editor. That seems to mean either Adobe Illustrator and FontLab (if you have too much money) or Inkscape and FontForge (if you like open source). I fall firmly into the latter category, so I grabbed my graphics tablet and opened Inkscape.

I wrote out my first three letters: capital A, B and C. Saved them in Inkscape, and attempted to import them into FontForge. Then I remembered one crucial thing that had slipped my mind: I absolutely loathe using FontForge. It’s a bit like when you open an old version of GIMP and get a bunch of weird looking windows floating all over the place; it feels like you’re fighting against the tool to do even the most basic operations. The difference is I have cause to edit images a lot more than I edit fonts, and GIMP has actually significantly improved their UI over the years.

Here are the rough steps I went through with FontForge:

Launch Font Forge. It shows a weird bit of art in one window, and an open file dialog in another.
I don’t want to open a file, so I close that dialog. The program exits.
Relaunch Font Forge, and realise that within the “Open Font” dialog is a “New” button. Click it.
Get to the standard font-editing UI. Right-click on the “A” looking for a way to import an SVG. Don’t see one.
Click around a bit, exploring the menus. Everything feels a bit off. You can’t open one menu then hover over the next to see its content, like basically every UI toolkit in existence. I think FontForge has eschewed QT and GTK in favour of doing things itself.
Find the “Import” option in the File menu. Hope it’s for a single glyph not the whole font.
A file picker opens. Again it’s all a bit off from normal desktop conventions. Try to resize it, and just get blank grey space at the bottom.
Type the absolute path I want to go to in the text field.
Get a dialog saying “Not a bdf file /home/chris/etc”. Press OK.
Get a dialog saying “Could not find a bitmap font in”. Press OK.
Press Ctrl+L to see if that lets me enter a path. Click everything in the dialog to try to find a way to enter a path. Get annoyed. Give up. Click through folder-by-folder to get to where I want to be.
Get to the folder and don’t see any files. Change the format to “SVG”. Double-click the newly-visible SVG file.
Get a dialog saying “You must select a glyph before you can import an image into it”. Press OK.
The import dialog goes away, having not imported.
Select the glyph in the main tool area, then repeat the File→Import dance.
It’s actually there now! Open the glyph in the editor and see it’s a complete mess of Bézier curves. I can’t click what I want without accidentally moving a handle for an adjacent curve.
Rage-quit.

I’m sure FontForge is less anger inducing once you’re used to it. And you definitely could use it to build a font like this if you had much more patience than me. I’d had enough of death-by-a-thousand-paper-cuts though.

I briefly tried Inkscape’s built-in support for making an SVG font. It annoyed me a lot less, but it’s fiddly: it seemed like each glyph had to be a single path, so you had to convert the glyphs to paths, then merge them correctly. If you merge them incorrectly then the wrong bits of your letters end up filled (like the inside of the ‘B’). Path manipulation is getting towards the limit of my knowledge of vector editing, and it took a bit of trial and error for each letter that had more than a single stroke. I didn’t fancy doing that for every letter.

I’m usually a big advocate of open source, but this was one of those painful times when it feels like it just falls short. Clunky, painful UI and processes where commercial tools just let you get on with your work.

You can exchange money for goods and services

When I’d been looking for open source tutorials, I found many mentions of a closed source, hosted tool: Calligraphr. It has a free version with limitations (no ligatures, no variations, 75 glyphs per font), and a pro version for £8/month. I’d normally balk at the idea of a subscription for this, but they have the perfect answer: you can make a one-time payment, and your account automatically downgrades back to free after a month. It’s not a hidden option, either, it’s the most prominent button on the upgrade page. That made me happy to give them £8 to play around with the service for a month.

Calligraphr works by having you print templates, write out the letters, then scan them in. It does some magical processing to extract the glyphs, provides tools to tidy them up, align them, etc, and then produces a TTF file for you. You can see some of my completed templates here:

Most of the templates I used for the font

Calligraphr has a nice UI to generate the templates, allowing you to select which glyphs to include. I added the “minimal English”, “basic punctuation” and “Ligatures” sets. That gave me four pages to fill out, and I did them all twice. That let me filter out versions that didn’t work well, and have variants for some letters so the font wasn’t too repetitive. Later on, I went back and added some custom ligatures based on blog post titles that didn’t look quite right: “Re”, “To”, “ers”, “ey”, “hy”, “ra”, “re” and “ty”. Ligatures like this help it look more natural: when we write we don’t just stamp out identical letters regardless of their surroundings, instead they will connect to their neighbours, or overlap slightly, or even share a stroke.

I filled these templates in with a Sharpie, as I wanted a fairly informal, scrap-booky look, and it would also give good solid shapes that should be easy to pick out of the template. I scanned them with the “Scan Document” function on my iPhone, and uploaded the PDFs to Calligraphr.

Iterating and tweaking

The Calligraphr UI allows you to preview the font, but I found it a lot more useful to just download a copy and use it on a local copy of my website. That let me test it with real text, and see how it’d look at the different font sizes I use on the site.

The first version was not great. Despite the guidelines on the template, I apparently wasn’t good at sticking to them. Some letters were floating way off the baseline, and some were sunken below. When those opposites met it looked terrible. Fortunately Calligraphr has a pretty easy tool to slide each letter up and down, and scale it up or down if needed, and you can see it next to other letters as you do it. It took a little bit of time to go through all the variants of all the letters, but the next version looked a lot better.

Another tweak I ended up doing was reducing the spacing between letters. The defaults Calligraphr uses are probably good for a blocky font, but I wanted to put the letters close together to give it more of a joined-up look. Again, this is an easy tool to use, you just drag the sides in or out as desired. While these tweaking steps were probably as fiddly as some of the Inkscape steps I refused to do earlier, they’re a lot more rewarding as you see things improving with each one. It’s a lot easier for me to commit time and effort to improving something that’s already working reasonably, than put that time and energy into an unknown.

Later, I noticed that occasionally there would be a huge gap in a title. Not “the kerning is slightly off” but “there’s enough room to park a bus”. It took me a while to figure out what was happening: a couple of glyphs hadn’t been isolated perfectly and had picked up a few pixels from the template lines at the edge of their boxes. That meant the glyph had a width that covered the actual written glyph, a big gap, and then the rogue marks. At first, I fixed this by just adjusting the width, but that left the little pixels floating awkwardly down-sentence. The proper fix was to use the editing tool and simply delete them, and then Calligraphr snapped the width back to what it should be.

These iterations took a while to do, but I just dipped in and out occasionally over the course of a week, so it didn’t actually feel like too much work. I quite enjoy the process of refining things, too.

Result and a surprise

If you’re viewing this post on my website¹, you can see the font in the headers, captions, and a few other places. Here’s how it compares to my actual handwriting:

My handwriting vs my handwriting font

It’s not close enough to forge documents, but I think it definitely gets across my style, and that’s exactly what I wanted. It’s surprisingly legible even at smaller font sizes — I think the weight of the Sharpie helps here — and at £8 and a bit of manual work was a lot more economical than spending days wresting with open source tools.

A few weeks after I put the finishing touches on the font, I got an e-mail from Calligraphr. As my account had lapsed back to the free version, I was no longer eligible for the “server-side backup” feature. So what did they do? They e-mailed me an exported copy! It’s a JSON file with the properties of each glyph and a base64 encoded image. Not only can I re-upload this to Calligraphr if I resubscribe, I can probably hook something up to edit it should I ever need to. I’m blown away by how pro-user Calligraphr’s business practices are. They’re up-front about pricing, don’t try to get you stuck on an auto-renewing subscription, and automatically export your data. It’s like a breath of fresh air compared to the barrage of dark patterns that other websites foist on us. If you want to make this kind of font, I’d definitely recommend them just because of how nice they are.

And I haven’t changed everything since writing this post… ↩︎

Coming around on LLMs

2025-05-28T00:00:00Z

Claude says hi.

For a long time I’ve been a sceptic of LLMs and how they’re being used and marketed. I tried ChatGPT when it first launched, and was totally underwhelmed. Don’t get me wrong: I find the technology damn impressive, but I just couldn’t see any use for it.

Recently I’ve seen more and more comments along the lines of “people who criticise LLMs haven’t used the latest models”, and a good number of developers that I respect have said they use coding models in some capacity. So it seemed like it was time to give them another shake.

The first decision to make was which model to try. OpenAI are no longer the only player in the game, every tech company of a certain size is now also somehow an AI company¹. I looked a bit at some benchmarks, and then mostly ignored them and went with the only company that I didn’t outright hate: Anthropic, and their model Claude.

Initial impressions

The latest Claude models do feel a lot more “capable” than the earlier ChatGPT versions I remember, but they also still have a lot of the same problems. At their heart, they’re still text-prediction models, and still seem to be trained to predict text that will please the user rather than be factually accurate or useful.

One of the improvements that people kept mentioning was the ability for models to access the web directly. I’ve seen it kick in a bit naturally, and asked for it explicitly sometimes, and it’s… nothing special? Are people just really bad at searching the web? Maybe they should try Kagi? I feel like about 80% of the time I could have found the information just as quickly myself, about 10% of the time it searched and then hallucinated an answer, and the remaining 10% it found something quicker than I otherwise would have. Those aren’t great results, especially when you consider how much cheaper and simpler just searching the web is.

There is another way to trigger web searches in Claude: using “research mode”. When you enable it, it splits off into different models: a “lead researcher” to come up with a plan, and then some minions that execute it. It ends up doing hundreds of web queries in the span of a few seconds. Suddenly I understand why things like Anubis need to exist. I’ve not used the “please launch a DoS attack” button since.

What did impress me, though, was its ability to churn out reasonable-ish code. It can hack together a bash script as well as I can, and do it far faster than I’d be able to. Sometimes they even work. That made me wonder what it would be like doing actual coding with it. Anthropic have a CLI tool called claude-code, so I paid them lots of money and gave it a spin.

Coding with Claude

The first thing I notice about claude-code is that I really like the interface. It’s basically an input box in a terminal. It doesn’t force me to use a certain IDE or do things in a certain way. By default it asks before making any changes, showing you a side-by-side diff of what it’s doing and allowing you to provide feedback. If I had to design a way to interact with a coding agent from scratch, I can’t think of many things I’d improve.

A simple example of a claude-code session

The power in claude-code versus just using the web UI is that it can use tools. It can query git, run grep commands, even use sed if it wants to change something in lots of files at once. It’s very good at figuring out its way around a codebase, even without any explicit instructions. You can see in the screenshot that with a little prompting it managed to get the permalink to this post; I didn’t tell it where the posts were stored, or how to work out the latest, I just told it when it was wrong. If I’d run /init before it would have probably picked up on the fact that my posts have custom permalinks, and noted it in CLAUDE.md.

But how good is it at actually writing code? It’s like having a keen but not particularly thorough Junior Engineer at your beck and call. If you give it a clearly defined task and guidance on how to implement it (and maybe some feedback as it suggests changes), it’s more than capable of doing it. If you don’t give it enough guidance it tends to go more off the rails. I tried having it generate a simple application from scratch with minimal technical guidance and no review of what it was doing, and it made such a mess of it I decided it was quicker to throw it away and start again by hand.

The man behind the curtain

Even with sufficient guidance, at times it’s really obvious that it’s an LLM generating pleasing-token-strings and not something that genuinely understands what it’s doing. It will spit out code like this:

if err != nil {
    if err == sql.ErrNoRows {
       return nil, err
    }
    return nil, err
}

Why’s that check for sql.ErrNoRows there? It’s entirely pointless. There was no instruction to check for it, none of the existing code checked for it, but I assume it comes up quite a bit in the training data. But it didn’t understand why, so it put the check in, and returned the exact same thing as if it hadn’t.

It also occasionally tries to “cheat” or solve problems the wrong way. It sometimes feels a bit like you’re asking for wishes from a Monkey Paw. “Stop the unit tests failing”, you’ll say; Claude will respond with a request to delete the failing test. The man behind the curtain isn’t particularly well hidden, and the training data and pattern matching often shows through.

This lack of understanding also makes it very hard to get Claude to use comments in a sensible way. It absolutely loves doing nonsense like this:

// render form
function renderForm() {
    // ...
}

Even with explicit instructions to avoid useless comments, or comments that only explain what the code does (not why it does it), or other prompts. Again, I’m chalking it up to a mixture of training data that does that, and lack of any actual understanding about why a human developer may want a comment to exist. Of course, there are plenty of flesh-and-blood devs out there that also don’t comment effectively, so maybe I shouldn’t give Claude too much of a hard time on this.

… and yet …

So with all those problems, it sounds like it’s just not worth it, right? Well, not quite. I feel like programming mostly consists of two distinct tasks: thinking how to implement things; actually implementing them; and then debugging why you’re off-by-one somewhere. Letting an LLM do the thinking is a big no-go for me: it’s evidently not good at it, and frankly that’s one of the things I most like about programming. Having let it loose on small projects, I shudder to think what the codebases of all the “vibe coded” projects that are popping up are like.

For the second stage, though, it’s actually quite nice. If I’ve thought through how I want something to be implemented, I can feed those steps to Claude and have it churn out the otherwise not-too-interesting code. This requires far less time and concentration on my part than writing code, to the extent that I can be thinking about the next feature, or doing something else at the same time. I don’t feel like I’m going to end up deskilling myself this way, as I’ve already formed the idea of what I want to code, I’m just using the LLM to spit it out faster than I can type it.

A lot of the most boring bits of coding like implementing CRUD-y operations can be summarised as “Look at this file/function. Do the same thing but slightly differently elsewhere”. Claude is great at this, especially when explicitly prompted like that. You’re basically playing to its pattern-matching strengths, rather than asking it to come up with anything novel. Most of my prompts tend to be prefixed with “Look at @some_file.go and @other_file.go.” to cue up the patterns I want it to use, and I find this works well.

As for debugging, it’s a mixed bag. It’s sometimes amazingly insightful, and sometimes just runs around in circles trying the wrong things over and over. It’s worth asking the question, but I definitely wouldn’t rely on it over my own abilities.

The future

I’m probably going to carry on using claude-code, at least for personal projects. I’ve got so much done that I just wouldn’t have been bothered to do if I was doing it all by hand. I very much enjoy being in the more “diffuse thinking” mindset, planning how things are going to work, rather than being stuck in the mines digging out SQL queries. After all, who wouldn’t want an over-eager assistant to work on all their hobby projects?

Work is a slightly different matter: a private project or even an open source project that disclaims any liability is different to something I’m being paid to deliver, and bear responsibility for fixing if it’s not done correctly. I’m not saying I won’t use it at all, but if I do it’ll be much more constrained than I would in personal projects.

As for non-code usages: I’m not sold. My sceptic hat is still firmly in place. I don’t think chat is a particularly good interface for many things, and hallucinations are still a big problem despite what people say. I hate the tide of AI slop that’s taking over the Internet, and how LLM-powered chat agents are being forced into every random product. You’re definitely not going to be seeing any AI-generated blog posts from me!

One topic I’ve not gone into here is the ethical concerns about using LLMs. They obviously exist, and I do have thoughts, but that’s a topic for another day.

I’m surprised it’s not gone more mainstream: why’s there no Tesco Value LLM model, yet? ↩︎

Home Automation Without the Megacorps

2025-05-21T00:00:00Z

I first experimented with home automation in 2016, by picking up a Samsung “SmartThings” hub. It was terrible. The UI to configure things was slow and clunky, firmware updates were applied whether you wanted them or not, and everything stopped working if their cloud services stopped. You were also locked into whatever integrations they deigned to support, of course. After that broke for the umpteenth time I scaled back and for years the closest I got to home automation was a couple of Hue bulbs.

Recently I’ve been building it out again, though. This time using off-the-shelf components that interop using Zigbee, open-source software, and some code I wrote myself. It’s great; it runs entirely locally and has had basically zero downtime. The Zigbee ecosystem lets me integrate all sorts of things without having to spend lots of money on “smart” alternatives. I think I’ve spent less on this incarnation than I did on the original SmartThings hub all those years ago (even without adjusting for inflation!).

My current setup

I run everything on a Raspberry Pi 4, with a Sonoff USB Zigbee adapter based on the CC2652P chipset¹. Interfacing with the Zigbee stack is handled by zigbee2mqtt (z2m for short), an open-source project that basically bridges your devices to an MQTT broker². When a device reports some data, it will send a new message over MQTT; when you want to make a device do something you just post a message back. It’s incredibly lightweight, but supports a huge array of devices out of the box. And as it’s just using MQTT, it’s trivial to integrate with other software or build on top of.

I know a lot of people building out this kind of home automation use Home Assistant, but I don’t get on with it terribly well. It felt incredibly sluggish, and the entire project is just a bit… much. I want a binary or package or docker image I can just run, not an entire operating system. That’s not how computers are meant to work! In contrast, z2m is simple to set up, super light weight and responsive.

Anyway. z2m exposes Zigbee devices over MQTT, so I wrote some code in Go to connect to the MQTT broker, and listen to the messages. It’s grown a bit beyond this now, and I’m skipping some boring bits like error handling and JSON parsing, but at first I had something like:

for {
    message, topic, err := c.ReadSlices()
    
    if string(topic) == "zigbee2mqtt/desk-button" {
        if strings.Contains(message, "single") {
            c.Publish(nil, []byte("{\"state\": \"TOGGLE\"}"), "zigbee2mqtt/room-lights/set")
        }
    }
}

I think I actually made this harder to read by trying to simplify it here, but hopefully you can follow that it was relatively straight forward to listen for a particular action to happen (in this case me “single”-pressing on the device called “desk-button”) and then make another device do something in response (toggling the state of the “room-lights” device).

So what actually are these devices? At present in z2m I have the following:

Some generic buttons
An air quality sensor (USB powered), and a separate temperature sensor (battery powered)
A light switch
Some 240V relay modules, that I use to turn non-smart devices on and off
Some USB relay modules, for the same purpose
Some “smart” plugs that I mostly use to monitor power usage
A motorised blind roller

I think all of these are either Tuya or Moes branded, and were all sourced from AliExpress. You can get the same things from Amazon or elsewhere, but they tend to be 3-4x more expensive for the same product.

One of the cool things about Zigbee devices is that the powered ones work together to create a mesh network, so you don’t have to worry about network repeaters or signal strength like you do with Wi-Fi networks. z2m even makes a map showing the connections:

The network map produced by z2m. You can see how all the powered devices form a mesh that the lower power ones can connect to.

Some interesting automations

A Zigbee relay spliced into the power cable for the fan

So what do I actually do with all of this? Some of it is just what I’ll call “laziness automation”: I want to be able to turn on the lights without getting up and walking to the light switch. So there’s a Zigbee button on my desk that does it. Then there are some less manual automations: my blinds are automatically closed at sunset³, for example. It feels a bit trivial, but it’s surprisingly nice just not to have to think about that at all.

Another nice quality of life automation is the light I have above my monitor. It’s USB powered, and I now have it going through a Zigbee USB relay that lets it be toggled on and off. Then I have a small agent running on my desktop that turns the light on when the computer is unlocked, and off when it locks or shuts down. I keep meaning to make a “film mode” that detects when I’m watching a film, and turning all the lights and blinds down, but I haven’t got around to it yet.

The most complex automation is probably for a window fan. It’s not smart in any way, so I cut the power cable and inserted a Zigbee relay. The whole thing is housed in a little project box to keep it secure. The relay basically acts as a switch: the live wire leading to the fan runs to the “normally open”⁴ contact, while the upstream power goes to “common”. When the relay is told to turn the fan on, the two get connected and the fan gets power. Oh, it’s also not actually a window fan, but I designed and 3D printed some adapters so that it sits right in the window.

So now we have a window fan that can be turned off and on automatically. But I don’t want to have to press a button to do that. I’m lazy, remember? Instead, I made it so that the Go code constantly monitors the temperature reported by the air quality sensor, and queries the free OpenWeatherMap API to get the rough temperature outside. It can then turn the fan on if the room is too hot, and outside is cool enough to make a difference (there’s no point in blowing hotter air in!).

A graph of room temperature, showing the effect of the fan being turned on and off

I don’t want it to do that all the time though. The room doesn’t need to be cooled if I’m not around. There are various Zigbee presence sensors you can get, but the cheaper ones seem to be of dubious quality. Instead, I wrote some code to guess whether I’m present. It uses the state of the monitor light as a proxy for “is the computer in use”, and then makes some guesses based on the last time the computer was used and the current time (if I turn the computer off at midnight it probably means I’m going to sleep; if I turn it off at 2pm it probably means I’m going out somewhere).

You can see in the graph that the fan has a decent impact on temperature. I coded it to cool the room to 19 degrees, but then not turn on again until it was above 20. This prevents it flip-flopping on and off constantly. You can clearly see the pattern in the graph, as it actively cools and then slowly the room warms back up. This arrangement is much better than being woken up at 5am because it’s painfully cold. Trust me.

Bonuses: metrics and 3D printer

One of the things my custom Go code does is collate all the various stats reported by the Zigbee devices, and inserts them into a VictoriaMetrics database. I originally hosted this on the Pi itself, and it performed fine, but I’ve since moved it onto a server so that I can use it for some other things as well.

I set up Grafana to point to VM, and can create dashboards showing power usage, what devices are turned on when, and a bunch of environmental conditions. This also makes it easy to spot how good the data coming from the devices are. For example, the air quality sensor reports a figure for the amount of Carbon Dioxide in the air, as well as the amount of Volatile Organic Compounds (VOCs). The graphs are basically identical, but on a different scale. It turns out this particular device has no actual way of detecting CO₂, so it just “calculates” it from the VOCs figure. Useful to know if you want to actually use that data.

Recently I came across a go library for interacting with Bambu Lab printers, so I’ve also hooked that into my automation. It exports metrics about the printer, so I now have a way of seeing what’s going on when I’m not physically present⁵. I even added a HTTP endpoint (exposed over Tailscale) that shows pictures from the built-in camera.

On the automation front, I’ve made it automatically turn off the printer’s light when it finishes a print, and also added push notifications via PushOver whenever the state changes. No longer will I be sat in another room blissfully unaware it ran out of filament seconds after I walked out the door!

Was it worth it?

These days you could probably just buy some kind of ‘smart home’ hub that works well enough, and do most of what I’ve done with a lot less effort and no coding. I’m still of the opinion that for something so essentially local, it should itself be managed entirely locally. I don’t trust companies like Google or Amazon not to kill their products, or change or remove an API I rely on.

Obviously the “Not Invented Here” approach of coding everything yourself doesn’t suit everyone, but as someone who enjoys coding and enjoys having things work just so it works very well for me.

It turns out the chipset is important. I initially used a similar Sonoff dongle that used a CC2531 chipset, and its performance wasn’t great. It often failed to pair with new devices, and dropped links to existing ones. The zigbee2mqtt docs do explicitly advise against the CC2531 chips for that reason. At the time they recommended CC2652Ps, so that’s what I went with. If you’re starting new I’d go with whatever their latest recommendation was. ↩︎
MQTT is basically a network protocol for publishing and subscribing to arbitrary messages. A broker is the thing that sits in the middle and routes the messages. I use Mosquitto but any will do. ↩︎
They originally also re-opened at sunrise but that was a terrible mistake. Who knew the sun rose so early?! ↩︎
“open” meaning “there’s a gap so it doesn’t work” not “open for business”. This confusion in terminology also extends to drawbridges. ↩︎
I use the printer in LAN mode, which means there’s no way to monitor it from a phone, even if you’re connected to the same network still. ↩︎

Further adventures in 3D printing

2024-08-04T00:00:00Z

The Bambu Labs P1S.

Not quite a year ago, I bought a Sovol SV06 3D printer and wrote about my initial experiences. At the end I joked:

I’m sure there will be more problems, but hopefully I get at least a week or so before anything else goes wrong. Maybe I’ll print an “X days since the last SV06 problem” counter…

That turned out to be more prophetic than I expected. It became a running joke that I’d flip the imaginary “days since” sign back to 0 almost every time I printed. I still really enjoyed having a printer, though: it’s so useful to be able to be able to go from an idea to a CAD drawing to a physical object in the space of minutes or hours. So when Bambu Labs reduced the price of the P1S — a printer generally regarded as about as trouble free as you can get — to £522 including shipping, I splurged on one.

Concerns

I make it sound like that was an easy decision, but I actually ummed and ahed a lot before pulling the trigger. I had a lot of objections to a Bambu Labs printer, and wasn’t quite sure if the price made up for them.

The Bambu Labs printers are designed to be more consumer friendly than most previous 3D printers. You can start a model printing directly from their website or mobile app, which employs a cloud-based slicer that then sends the model down to your printer. This is one of those things that sounds amazing for consumers, but should terrify anyone who works with computers. There are so many ways for a “cloud-connected” printer to go wrong, and with such potentially disastrous results it gives me anxiety just thinking about it.

This is not just theoretical, either. In a blog post with the rather under-stated title of “Initial Investigation in the Bambu Cloud Temporary Outage”, Bambu describe how a server-side error caused printers to start printing unprompted. Users on Reddit reported printers starting in the middle of the night, trying to print on top of other objects that were left on the build plate, and so on. 3D printers can easily start fires; having them cloud controlled is frankly insane.

As a result of that “temporary outage”, Bambu further improved the “LAN mode” for their printers, which allows you to sever its connection from their servers and control it over the network. That’s basically how my old printer worked anyway, so I was happy enough that I could enable LAN mode and ignore all the cloud nonsense.

My other objection to Bambu was more nebulous. Almost all 3D printers are built upon open source software, and some companies like Prusa go out of their way to make their products more open to give back to the community. Bambu don’t really do any of that: I’d be very surprised if they hadn’t incorporated a bunch of open source software into their printers and just ignored the licences¹. I’d much rather give my money to a company doing good, but the only equivalent printer was the Prusa MK4 which was double the price and didn’t come with an enclosure. To add an enclosure kit would have made it £800 more expensive than the P1S, and I just can’t justify that.

Experience

The initial setup of the P1S was a breeze. While the SV06 shipped in parts, the P1S came fully assembled and just needed some packaging and retaining screws removed. These were all clearly marked with large coloured arrows. It’s very much designed so anyone can do it.

I ran through the initial calibration, firmware update, and then put it in LAN mode. Then I just started printing and it went fine. No messing around levelling a bed, or using a sheet of paper to try and set the Z-offset properly; it just worked. It was really loud though. After talking a bit with a friend who’d also bought a P1S, I realised that most of his noise was from the fans, while most of mine was from the servos. A bit of research later and I found out they added servo noise compensation in a firmware update, but I hadn’t run the calibration for it because the initial calibration happened before the update. After doing that, the printer went from sounding like it was impersonating a continental police siren to just being a bit fan-y.

The biggest difference over the SV06 is the speed. I’d swapped the nozzle on the SV06 to a 0.6mm one, and generally printed at a layer height of 0.4mm. The P1S still has its 0.4mm nozzle, and I mostly print at a layer height of 0.2mm. So it’s laying down twice the number of layers, with a nozzle that can extrude half the amount of plastic… And it’s at least twice as fast! Prints that I previously wouldn’t have even attempted on the SV06 are now 8-10 hours on the P1S, without even adjusting the speed or lowering the quality. Here’s a side-by-side comparison:

P1S vs SV06.

The P1S can print eight objects because of its slightly larger bed, while the SV06 can only manage three. The P1S is also printing at a much higher quality. Yet somehow it still ends up being faster. It’s mind blowing.

The other big difference I’ve not mentioned yet is that the P1S is a “core XY” printer rather than a “bed slinger”. That means in order to move along the Y-axis (from the front of the bed to the back), the P1S moves the extruder while the SV06 moves the bed. This makes a big difference when printing tall objects, as they’re far more likely to wobble and come loose when the bed is moving back and forth. It also presumably makes the kinematics a lot easier as the mass of the moving parts is constant, instead of gradually becoming heavier as more and more plastic gets added.

The only failures

I’ve only had a handful of failures since getting the P1S. I had one weird issue where the slicer decided to print some parts extremely slowly, and the print just didn’t work out in those parts; that’s more of a slicer issue, though: after tweaking the model to stop the weird behaviour it printed fine.

The only failure I can directly attribute to the printer was when I tried ironing. This is a process where after printing the top layer, the printer slowly goes back over it at the same height while extruding a small amount of plastic. This is meant to fill in the small gaps between extrusions and give a smooth finish. In my case, though, it just clogged the nozzle and extruder.

At first I thought it was because I was printing too hot: the profile I was using was designed for fast printing, so had to melt the filament rapidly, but there was no way to turn that temperature down just for the ironing pass. I tried another run at a lower temperature and everything clogged again. I then swore off ironing, did a normal print, and everything clogged once more.

At this point I was getting exceedingly good at disassembling the hot end, but also fairly annoyed. It felt like I was using an SV06 again²! I’d previously read some recommendations that you should leave the door or top of the enclosure open when printing PLA, but had never really had any issues so hadn’t bothered. I tried a print with the top propped open and everything worked smoothly again. In hindsight all these clogging issues happened when it was particularly hot and humid outside, which was probably a factor.

Summary

Upgrading to the P1S has made the 3D printer feel more like a tool and less like an additional ongoing project. The speed increase continues to amaze me, as does the increase in quality.

I still think it was valuable to have the SV06 to learn how printers work — you definitely don’t get as much of that from using something so consumer-focused as the P1S — and figure out if I was actually going to use it long-term or whether it was just a fad for me. So it served its purpose, but I’m rather glad to see the back of it in favour of something better in pretty much every way.

And if they did there’s nothing anyone can do about it because copyright doesn’t exist in the same way in China. ↩︎
Although taking apart the P1S (which is a proprietary machine you might not expect to be very user-servicable) was orders of magnitude easier than taking apart the SV06 (which was an open source design). Everything is just much nicer: the connectors are easier to attach and detach, the screws are all a consistent size instead of needing a whole suite of allen keys, and so on. ↩︎

Project log: Filament weight display

2023-12-03T00:00:00Z

The finished project

One problem¹ I have when 3D printing is that it’s hard to gauge whether there’s enough filament left on a roll to complete a print. Sometimes it’s obvious when the print is small or the roll is full, but often it’s not. If I’m unsure about it, I end up obsessing over the printer instead of just leaving it to do its thing.

The typical approach to this problem is to use a run-out sensor, which stops the printer when it detects that the filament is no longer running through it. I’d rather know in advance though: it’s no good stopping the print if I’m making something that has to look nice and now half of it is one colour and the remainder will be something else.

While browsing around for ideas, I came across a project that used a load cell to measure the weight of the filament roll². I didn’t really know what a load cell was, but decided to do some research and see if I could build my own. I didn’t actually read the article I found, intending to figure things out on my own if I could.

Load Cells 101

A load cell, its amplifier, and some random headers

At the heart of the project is a load cell. It turns out these are the things that do the lifting in most electronic scales. They’re basically a carefully machined metal bar with a strain gauge attached to it. The strain gauge is a long trace of conductive material that runs back and forth across the middle of the bar. When the bar bends very slightly (due to load), the conductor flexes with it and gets longer or shorter; that flex changes its resistance by a tiny amount, which can be measured using a Wheatstone bridge.

The Wheatstone bridge is a diamond of resistors, and requires an ’excitation’ voltage to be applied across it in one direction, and the resistance is then read from the perpendicular pair. As the resistance is tiny, and the changes even more tiny, you generally need an amplifier to read it and output something more useful. The HX711 is such an amplifier, and is so ubiquitous that most places that sell load cells will just bundle one with it.

The HX711 connects to the load cell using four wires: two for the excitation voltage, and two for the output. On the other end it takes a 5V input, ground, and then has two pins to deal with the onward communication: one for a clock signal, and one for data. We’ll get back to that later!

Early prototyping

The prototype, mid-debugging

I decided early on to base the project around an RP2040-based board, as I had previous experience with them and they’re cheap and easy to get hold of. I started off with a Raspberry Pi Pico, slotted it into a breadboard, and connected it to the HX711. A short search produced three or so different python libraries, but I couldn’t get any of them to work reliably.

If you look at the picture of the prototype, you’ll notice a large bundle of wires to the left. These are connected to a logic analyser I bought to try and understand what on earth was happening, because it seemed like the code should work, and there was definitely some communication with the HX711 happening, but none of the readings made any sense.

At one point I noticed that moving my head near to the Pico caused the readings to change, but I didn’t understand the implication of that³. I went to bed unable to figure out what was going on, and just before I dozed off realised that I must have the pins configured wrong. The next day I checked the spec sheet and discovered that the pin with the number “1” silk-screened next to it is in fact GPIO 0, not GPIO 1⁴. The pin the Pico was trying to read data from wasn’t actually connected to anything, which is why waving my hand near it was enough to induce a signal.

Updating the code to use the correct pins made everything work much better and I started to get sensible readings. At this point I came across the RP2040-Zero by Waveshare, which is not only a smaller, cuter, cheaper Pico, but has silk-screened numbers that actually match the GPIO pin numbers (plus an actual a reset button!). I immediately bought several, and switched the prototype over as soon as they arrived.

The rest of the prototyping was reasonably uneventful. I used a little OLED screen I had sitting around from a past Ali Express order, and once again there were several python libraries to handle it. Soon enough I had raw weight readings from the load cell (which was stuck to my desk with painters’ tape) being displayed on the screen.

The load cells don’t measure absolute weight, so you have to “calibrate” them by remembering the reading when there is no load, and then applying a scaling factor to turn the raw reading into a weight. I worked these out by putting a known weight on the business end of the load cell, and then hard-coding the numbers.

An interruption to deal with interrupts

One thing I noticed with the MicroPython libraries for the HX711 is that they relied on polling the data pin to see if there was any data to read. The way the HX711 communicates is by pulling the data line low when it has data; you then have to pulse the clock line to get it to shift a bit of the reading out over the data line. The HX711 I have operates at 10Hz by default⁵, and reading the data takes almost no time at all, so the most “efficient” thing to do is to sleep for 100ms between readings.

This is fine if you’re not doing anything else, but gets awkward if you also want to refresh a screen at certain points, or check for button inputs, etc. It also upset me to see the data line being low for so long when viewing the logic analyser traces. The RP2040 supports setting interrupts on the GPIO pins, but I couldn’t find anyone who was actually using them for the HX711.

I therefore did the only sensible thing: wrote my own library, using interrupts to monitor for data availability. It was pretty straightforward, but didn’t actually work consistently. Looking more closely at the other libraries, they all do something to try to increase the speed at which the clock signals are written⁶: some were disabling interrupts, others were using assembly. I, again, did the only sensible thing: I threw all the python away and wrote a new driver in TinyGo.

My new code is event driven: it adds interrupts for button presses, and one for the HX711 data line. When the data line is pulled low, it removes that interrupt (so it doesn’t fire for every bit of data we receive), does the reading logic, then re-adds the interrupt. Theoretically if you spam buttons at an inopportune time you could mess up a reading, but the reading 100ms after would be fine. So my code spends most of the time idle, which translates to very little power draw.

User experience

While prototyping I was using some standard small push buttons to navigate the user interface I was creating. I soon realised that if I needed to enter weights on the real device I wasn’t going to be happy poking an annoying little button hundreds of times, and I didn’t feel like coding anything more elaborate to make input easier. Instead, I switched to using a rotary encoder. This is a bit like a variable resistor, but it can rotate completely freely, and sends a signal when it’s turned. It also has a button built in, so you can press it down to select things.

It took me a while to get the hang of the rotary encoder: it has two data pins for turning, and you have to wait for a falling edge on one pin and then immediately read the other to figure out which way it’s turning. My initial attempts at doing this weren’t quite immediate enough⁷, so I ended up with somewhat random data. Trying to select a number when going right sometimes increases it and sometimes decreases it is an exercise in frustration.

The correctly functioning rotary encoder makes it much easier to input numbers and change settings. I ended up with a very simple menu system at the bottom of the screen which lets you cycle between three options: setting the spool weight, zeroing the scale, and calibrating it. Zeroing is the most straightforward option: it simply reads the current value, and saves it as the zero offset in the flash memory. Selecting spool weight enters a mode where turning the rotary encoder increases or decreases the spool weight by a gram at a time; pressing the encoder in saves the value to flash and exits the mode⁸.

Calibration is a bit more confusing. Changing the spool weight changes the value you see on the screen directly and predictably. Calibration instead affects the “scale” value you can’t actually see; you just see the effect of the scaling on the weight reading. Still, if you have a known weight on the scale you simply rotate the encoder until the right weight is displayed on the screen. Pressing the encoder saves the value to flash as with the other modes.

Putting it together

The final assembly

The final step was to assemble everything in a way where it would be usable, and wires wouldn’t keep falling out whenever you looked at it. I found some cute little prototype boards that would just about fit all the components on – I left the OLED screen and rotary encoder off so they could be mounted to the front of the box.

I obviously 3D printed the enclosure, because I own a 3D printer and therefore spend a lot of my time 3D printing parts for my 3D printer. In my first prototype I put raised areas on the back panel and put some heat-press inserts in them, intending to screw down the protoboard. The screw holes I was going to use, however, were underneath the soldered-down RP2040-Zero and HX711. I instead uninserted the inserts and simply put some screws through the back panel with the intention of slotting nuts under the components. This turned out to be both incredibly annoying and entirely unnecessary; the board sits at the back of the box on its own, and there’s no real danger from it having a bit of freedom.

While I was prototyping I was powering the circuit from the USB port on the microcontroller, but for the actual unit I added a buck converter and ran a cable from the 3D printer’s power supply (which outputs 24V). This has the handy side effect of turning the scale on and off with the printer. I’ve recently bought a bench power supply, which made testing this part a lot easier: being able to dial in a voltage and current limit and then just plug things in is great.

The other thing that needed to change between my prototype and the final version was the load cell. It needed to be attached to the printer in such a way that one end bore all the weight of the spool (and, you know, not stuck to my desk with painters’ tape). I was originally going to do something fancy with bearings, but settled on the easier option of a spool holder which uses the same threading as the original, so it slots straight in:

The load cell mounted as part of a spool holder on the printer.

With all of this done, I invented a complicated mounting system to keep it attached to the printer. Any resemblance to blue painters’ tape is entirely coincidental.

Bill of materials and sources

Here are the major components that I ended up using:

Part	Source	Cost
RP2040-Zero microcontroller	WaveShare	£3.15
5KG load cell + HX711	AliExpress	£1.89
Buck converter	AliExpress	£0.51
SH1106 OLED module	AliExpress	£1.70
Rotary encoder	AliExpress	£0.80
Mini PCB prototype board	Amazon	£1.49

Where things come in packs of more than one, I’ve listed the cost of one unit. I’ve not included things like wires, connectors, or the filament used in printing the enclosure as you can use whatever you have to hand.

The source code I wrote is available on GitHub, and the designs for the 3D printed parts are shared in OnShape.

Among many, many others, of course. ↩︎
I can’t actually find where I saw this original project now, but there are quite a few kicking around if you search. ↩︎
This happened at about 1am and I was tired and frustrated. That’s my excuse, anyway. ↩︎
At this point I realised I’d made the exact same mistake the last time I used a Pico. Fool me once, etc. ↩︎
You can change this to 80Hz by resoldering a resistor on the board, but 10Hz is already several orders of magnitude faster than I actually need. ↩︎
If the clock signal stays high for longer than 60ms it’s treated as a shutdown signal by the HX711. This is somewhat unideal when you’re trying to read data from it. ↩︎
Because of my very clever interrupt system. I wanted to do as little work in the interrupt handler as possible, so I was just enqueuing an event to be processed in the main loop. This introduced enough delay that I wasn’t reading the second pin at the right time. The solution was to read the pin in the interrupt handler and then just enqueue a “left” or “right” event instead of my original “turning somehow, you figure it out” event. ↩︎
I was initially planning on hard-coding the weights for all the spools I’m likely to use, and just having a way to switch between them. But the thought of having to re-flash the device every time I bought a new type of filament made me reconsider. Plus, it was way easier to not do that. ↩︎