2025-09-10 04:00:12
Dedicated word processors are not something we see much of anymore. They were in a weird space: computerized, but not really what you could call a computer, even in those days. More like a fancy typewriter, with a screen and floppy disks. Brother made some very nice ones, and [Chad Boughton] got his hands on one for a modernization project.
The word processor in question, a Brother WP-2200, was chosen primarily because of its beautiful widescreen, yellow-phosphor CRT display. Yes, you read that correctly — yellow phosphor, not amber. Widescreen CRTs are rare enough, but that’s just different. As built, the WP-2200 had a luggable form-factor, with a floppy drive, mechanical keyboard, and dot-matrix printer in the back.
Thanks to [Chad]’s upgrade, most of that doesn’t work anymore. Not yet, anyway. The original logic controller of this word processor was… rather limited. As generations have hackers have discovered, you just can’t do very much with these. [Chad] thus decided to tear it all out, and replace it with an ESP-32, since the ESP32-VGA library is a thing. Of course this CRT is not a VGA display, but it was just a matter of tracing the pinout and guesstimating sane values for h-sync, v-sync and the like. (Details are not given in the video.)
Right now, the excellent mechanical keyboard (mostly) works, thanks to a Teensy reading the keyboard matrix off the original cable. The teensy sends characters via UART to the ESP32 and it can indeed display them upon the screen. That’s half of what this thing could do, back in the 1980s, and a very good start. Considering [Chad] now has magnitudes more compute power available than the engineers at Brother ever did (probably more compute power than the workstation used to program the WP2200, now that we think of it) we’re excited to see where this goes. By the spitballing at the end of the video, this device will end its life as much more than a word processor.To see what he’s got working so far, jump to 5:30 in the video. Once the project is a bit more mature, [Chad] assures us he’ll be releasing both code and documentation in written form.
We’ve seen [Chad]’s work before, most recently his slim-fit CD player, but he has been hacking for a long time.We covered his Super Mario PLC hack back in 2014.
2025-09-10 02:30:40
Business cards, on the whole, haven’t changed significantly over the past 600-ish years, and arguably are not as important as they used to be, but they are still worth considering as a reminder for someone to contact you. If the format of that card and method of contact stand out as unique and related to your personal or professional interests, you have a winning combination that will cement yourself in the recipient’s memory.
In a case study of “show, don’t tell”, [Binh]’s business card draws on technological and paranormal curiosity, blending affordable, short-run PCB manufacturing and an, LLM or, in this case, a Small Language Model, with a tiny Ouija board. While [Binh] is very much with us in the here and now, and a séance isn’t really an effective way to get a hold of him, the interactive Ouija card gives recipient’s a playful demonstration of his skills.
The interface is an array of LEDs in the classical Ouija layout, which slowly spell out the message your supernatural contact wants to communicate. The messages are triggered by the user through touch pads. Messages are generated locally by an ESP32-S3 based on Dave Bennett’s TinyLlama LLM implementation.
For a bit of a role reversal in Ouija communication, check out this Ouija robot. For more PCB business card inspiration, have a look at this pong-playing card and this Arduboy-inspired game console card.
Thanks to [Binh] for sharing this project with us.
2025-09-10 01:00:11
Last time, I described how to write a simple Android app and get it talking to your code on Linux. So, of course, we need an example. Since I’ve been on something of a macropad kick lately, I decided to write a toolkit for building your own macropad using App Inventor and any sort of Linux tools you like.
I mentioned there is a server. I wrote some very basic code to exchange data with the Android device on the Linux side. The protocol is simple:
You can build the server so that it can execute arbitrary commands. Since some people will doubtlessly be upset about that, the server can also have a restrictive set of numbered commands. You can also allow those commands to take arguments or disallow them, but you have to rebuild the server with your options set.
There is a handshake at the start of communications where Android sends “>.” and the server responds “<.” to allow synchronization and any resetting to occur. Sending “>#x” runs a numbered command (where x is an integer) which could have arguments like “>#20~/todo.txt” for example, or, with no arguments, “>#20” if you just want to run the command.
If the server allows it, you can also just send an entire command line using “>>” as in: “>>vi ~/todo.txt” to start a vi session.
There are times when you want the server to send you some data, like audio mute status or the current CPU temperature. You can do that using only numbered commands, but you use “>?” instead of “>#” to send the data. The server will reply with “<!” followed by the first line of text that the command outputs.
To define the numbered commands, you create a commands.txt file that has a simple format. You can also set a maximum number, and anything over that just makes a call to the server that you can intercept and handle with your own custom C code. So, using the lower-numbered commands, you can do everything you want with bash, Python, or a separate C program, even. Using the higher numbers, you can add more efficient commands directly into the server, which, if you don’t mind writing in C, is more efficient than calling external programs.
If you don’t want to write programs, things like xdotool, wmctrl, and dbus-send (or qdbus) can do much of what you want a macropad to do. You can either plug them into the commands file or launch shell scripts. You’ll see more about that in the example code.
Now all that’s left is to create the App Inventor interface.
App Inventor is made to create simple apps. This one turned out not to be so simple for a few reasons. The idea was that the macro pad should have a configuration dialog and any number of screens where you could put buttons, sliders, or anything else to interact with the server.
The first issue was definitely a quirk of using App Inventor. It allows you to have multiple screens, and your program can move from screen to screen. The problem is, when you change screens, everything changes. So if we used multiple screens, you’d have to have copies of the Bluetooth client, timers, and anything else that was “global,” like toolbar buttons and their code.
That didn’t seem like a good idea. Instead, I built a simple system with a single screen featuring a toolbar and an area for table layouts. Initially, all but one of the layouts are hidden. As you navigate through the screens, the layout that is active hides, and the new one appears.
Sounds good, but in practice there is a horrible problem. When the layouts become visible, they don’t always recalculate their sizes properly, and there’s no clean way to force a repeat of the layout. This led to quirks when moving between pages. For example, some buttons would have text that is off-center even though it looked fine in the editor.
Another problem is editing a specific page. There is a button in the designer to show hidden things. But when you have lots of hidden things, that’s not very useful. In practice, I just hide the default layout, unhide the one I want to work on, and then try to remember to put things back before I finish. If you forget, the code defensively hides everything but the active page on startup.
I also included some web browser pages (so you can check Hackaday or listen to Soma FM while you work). When the browser became visible, it would decide to be 1 pixel wide and 1 pixel high, which was not very useful. It took a lot of playing with making things visible and invisible and then visible again to get that working. In some cases, a timer will change something like the font size just barely, then change it back to trigger a recalculation after everything is visible.
Speaking of the browser, I didn’t want to have to use multiple pages with web browser components on it, so the system allows you to specify the same “page” more than once in the list. The page can have more than one title, based on its position, and you can initialize it differently, also based on its position. That was fairly easy, compared to getting them to draw correctly.
A few other problems cropped up, some of which aren’t the Inventor’s fault. For example, all phones are different, so your program gets resized differently, which makes it hard to work. I just told the interface I was building for a monitor and let the phone resize it. There’s no way to set a custom screen size that I could find.
The layout control is pretty crude, which makes sense. This is supposed to be a simple tool. There are no spacers or padding, for example, but small, fixed-size labels will do the job. There’s also no sane way to make an element span multiple cells in a layout, which leads to lots of deeply nested layouts.
The Bluetooth timeout in App Inventor seemed to act strangely, too. Sometimes it would time out even with ridiculously long timeout periods. I left it variable in the code, but if you change it to anything other than zero, good luck.
This is probably the most complex thing you’d want to do with App Inventor. The block structure is huge, although, to be fair, a lot of it is just sending a command off when you press a button. The example pad has nearly 500 blocks. The personalized version I use on my own phone (see the video below) has just over 900 blocks!
Of course, the tool isn’t made for such a scale, so be prepared for some development hiccups. The debugging won’t work after a certain point. You just have to build an APK, load it, and hope for luck.
You can find the demo on GitHub. My version is customized to link to my computer, on my exact screen size, and uses lots of local scripts, so I didn’t include it, but you can see it working in the video below.
If you want to go back and look more at the server mechanics, that was in the last post. Of, if you’d rather repurpose an old phone for a server, we’ve seen that done, too.
2025-09-09 23:30:31
We’ve all done it at some time — made an electrical connection by twisting together the bare ends of some wires. It’s quick, and easy, but because of how little force required to part it, not terribly reliable. This is why electrical connectors from terminal blocks to crimp connectors and everything else in between exist, to make a more robust join.
But what if there was a way to make your twist connections stronger? [Ibanis Sorenzo] may have the answer, in the form of an ingenious 3D printed clamp system to hold everything in place. It’s claimed to result in a join stronger than the wire itself.
The operation is simple enough, a spring clamp encloses the join, and a threaded outer piece screws over it to clamp it all together. There’s a pair of 3D printable tools to aid assembly, and a range of different sizes to fit different wires. It looks well-thought-out and practical, so perhaps it could be a useful tool in your armoury. We can see in particular that for those moments when you don’t have the right connectors to hand, a quick 3D print could save the say.
A few years ago we evaluated a set of different ways to make crimp connections. It would be interesting to subject this connection to a similar test. Meanwhile you can see a comprehensive description in the video below the break.
Thanks [George Graves] for the tip.
2025-09-09 22:00:36
Over a year ago, we took a look at importing a .step file of a KiCad PCB into FreeCAD, then placing a sketch and extruding it. It was a small step, but I know it’s enough for most of you all, and that brings me joy. Today, we continue building a case for that PCB – the delay is because I stopped my USB-C work for a fair bit, and lost interest in the case accordingly, but I’m reviving it now.
Since then, FreeCAD has seen its v 1.0 release come to fruition, in particular getting a fair bit of work done to alleviate one of major problems for CAD packages, the “topological naming problem”; we will talk about it later on. The good news is, none of my tutorial appears to have been invalidated by version 1.0 changes. Another good news: since version 1.0, FreeCAD has definitely become a fair bit more stable, and that’s not even including some much-needed major features.
High time to pick the work back up, then! Let’s take a look at what’s in store for today: finishing the case in just a few more extrusions, explaining a few FreeCAD failure modes you might encounter, and giving some advice on how to make FreeCAD for you with minimum effort from your side.
As I explained in the last article, I do my FreeCAD work in the Part workbench, which is perfectly fine for this kind of model, and it doesn’t get in your way either. Today, the Part and Sketcher workbenches are all we will need to use, so you need not be overwhelmed by the dropdown with over a dozen entries – they’re there for a reason, but just two will suffice.
Last time, I drew a sketch and extruded it into a box. You’ll want your own starting layer to look different from that, of course, and so do I. In practice, I see two options here. Either you start by drawing some standoffs that the board rests on, or you start by offsetting your sketch then drawing a floor. The first option seems simpler to me, so let’s do that.
You can tie the mounting holes to external geometry from the STEP file, but personally, I prefer to work from measurements. I’d like to be easily able to substitute the board with a new version and not have to re-reference the base sketches, resulting in un-fun failure modes.
So, eyeballing the PCB, the first sketch will have a few blocks that the PCB will be resting on.
Let’s just draw these in the first sketch – four blocks, with two of them holding mounting holes. For the blocks with holes, if your printer nozzle size is the usual 0.4 mm, my understanding is that you’ll want to have your thinnest structure be around 1.2 mm. So, setting the hole diameter (refer to the toolbar, or just click D to summon the diameter tool), and for distances between points, you can use the general distance tool (K,D, click K then click D). Then, exit the sketch.
Perfect – remember, the first sketch is already extruded, so when we re-drew the sketch, it all re-extruded anew, and we have the block we actually want. Now, remember the part about how to start a sketch? Single click on a surface so it gets highlighted green, press “New sketch”, and click “ok” on the box that asks if you want to do it the “Plane X-Y” way. That’s it, that’s your new sketch.
Now, we need to draw the box’s “floor”. That’s simple too – just draw a big rectangle. You’ll want to get some dimensions going, of course. Here, you can use the general distance constraint (K,D, click K then click D), or constrain even quicker by clicking I (vertical dimension) and L (horizontal dimension). Now, for the fun part – filleting! Simply put, you want to round the box corners for sure, nobody wants a box with jagged sharp holes.
You might have seen the Fillet tool in the Part workbench. Well, most of the time, it isn’t even needed, and frankly, you don’t want to use it if a simpler option exists. Instead, here, just use a sketch fillet – above in the toolbar; sadly, no keybind here. Then, click on corners you want rounded, exit the tool, then set their radius with diameter tool (D), as default radii are way too large at our scale. The sketch fillet tool basically just creates arcs for you – you can always draw the arcs yourself too, but it’s way easier this way.
You got yourself a rounded corners rectangle, which, naturally, means that you’ll be getting a cease and desist from multiple smartphone makers shortly. You might notice that the rectangle is offset, and really, you’d want it aligned. Fortunately, we placed our STEP-imported board approximately in the center of the screen, which makes the job very easy, you just need the rectangle centered. Draw two construction lines (G,N) from opposite corners of the sketch. Then, click on one of the lines, click on the sketch center point, and make them coincident (C). Do the same with the second line, and you’ll have the sketch center point on the intersection of the two lines, which will make the whole sketch centered.
Extrude that to 1 mm, or your favourite multiple of your layer height when slicing the print, and that’s the base of your case, the part that will be catching the floor. Honestly, for pin insulation purposes, this already is more than enough. Feel free to give it ears so that it can be mounted with screws onto a surface, or maybe cat ears so it can bring you joy. If you’re not intimidated by both the technical complexity and the depravity of it, you can even give it human ears, making your PCB case a fitting hacking desk accessory for a world where surveillance has become ubiquitous. In case you unironically want to do this, importing a 3D model should be sufficient.
Make a sketch at the top of the floor, on the side that you’ll want the walls to “grow out of”. For the walls, you’ll naturally want them to align with the sides of the floor. This is where you can easily use external geometry references. Use the “Create external geometry” tool (G, X) and click on all the 8 edges (4 lines and 4 arcs) of the floor. Now, simply draw over these external geometry with line and arc tool, making sure that your line start and end points snap to points of external geometry.
Make an inset copy of the edges, extrude the sketch, and you’re good to go. Now, did you happen to end up with walls that are eerily hollowed out? There’s two reasons for that. The first reason is, your extruded block got set to “solid: false” in its settings. Toggle that back, of course, but mistaken be not, it’s no accident, it happens when you extrude a sketch and some of the sketch lines endpoints are not as coincident as you intended them to be. Simply put, there are gaps in the sketch — the same kind of gaps you get if you don’t properly snap the Edge.Cuts lines in KiCad.
To fix that, you can go box-select the intersection points with your mouse, and click C for a coincident constraint. Sometimes the sketch will fail. To the best of my knowledge, it’s a weird bug in KiCad, and it tends to happen specifically where external geometry to other solids is involved. Oh well, you can generally make it work by approaching it a few times. If everything fails, you can set distance (K,D) to 0, and if that fails, set vertical distance (I) and then horizontal distance (L) to zero, that should be more than good enough.
And with that, the wall is done. But it still needs USB-C socket holes. Cutting holes in FreeCAD is quite easy, even for a newcomer. You make a solid block that goes “into” your model exactly in the way you want the cut to be made. Then, in Part workbench, click the base model that you want cut in the tree view, click the solid block model, and use the “Cut” tool. Important note – when using the “Cut” tool, you have to first click on the base object, and then the tool. If you do it in reverse, you cut out the pieces you actually want to save, which is vaguely equivalent to peeling potatoes and then trashing the potatoes instead of the peels.
Want a souvenir? In Part toolbox, click Chamfer, click on the USB-C opening edges, set chamfer distance to something lower than your wall thickness, say, 0.6 mm (important!), and press Ok. Now your case has USB-C openings with chamfers that as if direct the plug into the receptacle – it’s the nicer and more professional way to do USB-C openings, after all.
Once you get past “Hello World”, and want to speed your FreeCAD work tremendously, you will want to learn the keybinds. Once again, the key to designing quickly and comfortably is having one hand on keyboard and another hand on mouse, doesn’t matter if you’re doing PCBs or 3D models. And the keybinds are very mnemonic: “d” is dimension, “c” is coincident.
Another tip is saving your project often. Yet another one is keeping your FreeCAD models in Git, and even publishing them on GitHub/GitLab – sure, they’re binary files, but revision control is worth it even if you can’t easily diff the files. We could always use more public 3D models with FreeCAD sources. People not publishing their source files has long been a silent killer of ideas in the world of 3D printing, as opposed to whatever theories about patents might be floating around the web. If you want something designed to your needs, the quickest thing tends to be taking someone else’s project and modifying it, which is why we need for sharing culture so that we can all finally stop reinventing all the wheels our projects may require.
This is more than enough to ready you up for basic designs, if you ask me. Go get that case done, throw it on GitHub, and revel in knowing your board is that much less likely to accidentally short-circuit. It’s a very nice addition for a board intended to handle 100 W worth of power, and now it can also serve as a design example for your own needs. Next time, let’s talk about a number of good practices worth attending to if you want your FreeCAD models to last.
2025-09-09 19:00:08
One of the great things about sharing hacks is that sometimes one person’s work inspires someone else to take it even further. A case in point is [Ivor]’s colorimeter hacking (parts two and three), which started with some relatively simple request spoofing to install non-stock firmware, and expanded from there until he had complete control over the hardware.
After reading [Adam Zeloof]’s work on replacing the firmware on a cosmetics spectrophotometer with general-purpose firmware, [Ivor] bought two of these colorimeters, one as a backup. He started with [Adam]’s method for updating the firmware by altering the request sent to an update server, but was only able to find the serial number from a quality-control unit. This installed the quality-control firmware, which encountered an error on the device. More searching led [Ivor] to another serial number, which gave him the base firmware, and let him dump and compare the cosmetic, quality-control, and base firmwares.
After analyzing traffic between the host computer and the colorimeter during an update, he wrote a Python program to upload firmware without using the official companion app. Since the first data sent over is a loading screen, this let him display custom images, such as the DOOM title page.
During firmware upload, the colorimeter switches into a bootloader, the menu of which has some interesting options, such as viewing and editing the NAND. Opening the device revealed a flash chip, an AT91SAM ARM9 chip, and some test pads. After carefully soldering to the test pads, he was able to dump the bootloader, and with some difficulty, the NAND contents. Changing the chip ID and serial number in the NAND let the quality-control firmware work on the cosmetic model; interestingly, only the first digit of the serial number needed to be valid.
Of course, the actual journey wasn’t quite this straightforward, and the device seemed to be bricked several times, one of which required the installation of a jumper to force it into a recovery mode. In the end, though, [Ivor] was able to download and upload content to NAND, alter the bootloader, alter the serial number, and enter boot recovery; in short, to have total control over the device’s software. Thoughtfully, he’s used his findings to write a Python utility library to interact with and edit the colorimeter’s software over USB.
If this makes you interested in seeing more examples of reverse-engineering, we’ve covered some impressive work on a mini console and an audio interface.
