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.

youtube.com/embed/mr3uRO7FDz8?…

hackaday.com/2025/09/09/o-brot…

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.

youtube.com/embed/WC3O2cKT8Eo?…

Thanks to [Binh] for sharing this project with us.

hackaday.com/2025/09/09/this-o…

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:

• All messages to the ordinary Linux start with >
• All messages to the Android device start with <
• All messages end with a carriage return

Security

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.

Backtalk

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.

A Not So Simple Sample

One of the pages in the designer
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.

Just Browsing

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.

Other Gotchas

You’d think 500 blocks was the biggest App Inventor program anyone would be dumb enough to write…
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.

How’d It Work?

Over 900 blocks is really dumb!
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.

youtube.com/embed/15znMKz42yM?…

hackaday.com/2025/09/09/the-an…

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.

youtube.com/embed/ZSGpUEHWeTg?…

Thanks [George Graves] for the tip.

hackaday.com/2025/09/09/give-y…

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.

To The Floor And Beyond

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.

Build Up This Wall!

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.

Stepping Up

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.

hackaday.com/2025/09/09/freeca…

Over 500 of the world’s leading cryptographers, security researchers, and scientists from 34 countries have today delivered a devastating verdict on the EU’s proposed “Chat Control” regulation. An open letter published this morning declares the plan to mass-scan private messages is “technically infeasible,” a “danger to democracy,” and will “completely undermine” the security and privacy of all European citizens.

The scientific consensus comes just days before a crucial meeting of EU national experts on September 12 and weeks before a final vote planned for October 14. The letter massively increases pressure on a handful of undecided governments—notably Germany—whose votes will decide whether to form a blocking minority to stop the law.What is ‘Chat Control’?

The proposed EU regulation would legally require providers of services like WhatsApp, Signal, Instagram, E-Mail and others to scan all users’ private digital communications and chats—including text messages, photos, and videos. This automated, suspicionless scanning would apply even to end-to-end encrypted chats, forcing companies to bypass or break their own security protections. Any content flagged by the algorithms as potential child sexual abuse material (CSAM) would be automatically reported to authorities, effectively creating a system of constant mass surveillance for hundreds of millions of Europeans.

What the researchers highlight (key points)

The open letter from the scientific community systematically dismantles the core arguments for Chat Control, warning that the technology simply does not work and would create a surveillance infrastructure ripe for abuse:

• A Recipe for Error and False Accusations: The scientists state it is “simply not feasible” to scan hundreds of millions of users’ private photos and messages with “an acceptable level of accuracy.” This would trigger a tsunami of false reports, placing innocent citizens—families sharing holiday photos, teenagers in consensual relationships, even doctors exchanging medical images—under automatic suspicion.
• The End of Secure Encryption: The letter confirms that any form of scanning “inherently undermines the protections that end-to-end encryption is designed to guarantee.” It creates a backdoor on every phone and computer, a single point of failure that the scientists warn will become a “high-value target for threat actors.”
• A Gift to Criminals, a Threat to the Innocent: Researchers confirm that detection algorithms are “easy to evade” by perpetrators with trivial technical modifications. The surveillance system would therefore fail to catch criminals while subjecting the entire population to invasive, error-prone scanning.
• A Blueprint for Authoritarianism: The letter issues a stark warning that the proposal will create “unprecedented capabilities for surveillance, control, and censorship” with an inherent risk of “function creep and abuse by less democratic regimes.”

The Political Battlefield: Undecided Nations Hold the Key

The future of digital privacy in Europe hangs in the balance, with EU member states deeply divided. A blocking minority requires rejection or abstention by at least four Member States representing more than 35% of the EU population. Based on current stances, the population threshold would be reached if Germany joined the “not in favour” group alongside the seven governments already not in favour.

• Pro-Surveillance Bloc (14): A coalition led by Denmark, Ireland, Spain, and Italy is pushing hard for the law. They are joined by Bulgaria, Croatia, Cyprus, France, Hungary, Latvia, Lithuania, Malta, Portugal, and Slovakia.
• The Resistance (7): A firm group of critics includes Austria, Belgium, the Czech Republic, Finland, Luxembourg, the Netherlands, and Poland.
• The Kingmakers (7): The deciding votes lie with Estonia, Germany, Greece, Romania, Slovenia, and Sweden. Germany’s position is pivotal. A ‘No’ vote or an abstention from Berlin would kill the bill.

Patrick Breyer, a digital rights advocate and former Member of the European Parliament for the Pirate Party, urges the undecided governments to heed the scientific evidence:

“This letter is a final, unambiguous warning from the people who build and secure our digital world. They are screaming that this law is a technical and ethical disaster. Any minister who votes for this is willfully ignoring the unanimous advice of experts. The excuse that this can be done without breaking encryption is a lie, and the myth that exempting encrypted services would solve all problems has now been proven wrong.

I am calling on the government of Germany, in particular, to show political courage, but also on France to reconsider its stance. Do not sacrifice the fundamental rights of 500 million citizens for a security fantasy that will not protect a single child. The choice is simple: stand with the experts and defend a free and secure internet for all – including children, or stand with the surveillance hardliners and deploy authoritarian China-style methods. Europe is at a crossroads, and your vote will define its digital future.”

The Pirate Party and the scientific community advocate for investing in proven child protection measures, such as strengthening law enforcement’s targeted investigation capabilities, designing communications apps more securely, funding victim support and prevention programs, and promoting digital literacy, rather than pursuing dangerous mass surveillance technologies.

Suggested questions for competent national ministries:

• Encryption and national security: How will E2EE used by citizens, public authorities, businesses and critical services remain uncompromised under any detection mandates?
• Accuracy and efficacy: What evidence shows image/URL scanning can achieve low false‑positive/negative rates at EU scale and resist trivial evasion? The German Federal Crime agency has reported an error rate of 48% in 2024 (page 18).
• Scope and function creep: How does the government intend to ensure detection cannot be expanded or repurposed to broader surveillance/censorship in future (e.g., text/audio, political content)?
• Child protection outcomes: Which evidence‑based measures (education, digital literacy, trauma‑informed victim support, faster handling of voluntary reports, targeted investigations) will be prioritised?

Key quotes from the open letter:

• “On‑device detection, regardless of its technical implementation, inherently undermines the protections that end‑to‑end encryption is designed to guarantee.”
• “Existing research confirms that state‑of‑the‑art detectors would yield unacceptably high false positive and false negative rates, making them unsuitable for large‑scale detection campaigns at the scale of hundreds of millions of users.”
• “There is no machine‑learning algorithm that can [detect unknown CSAM] without committing a large number of errors … and all known algorithms are fundamentally susceptible to evasion.”

Further Information:

• Open Letter from 500+ Scientists (9 Sept 2025): csa-scientist-open-letter.org/…
• Map of National Positions and background information: www.chatcontrol.eu

Upcoming Dates:

• 12 September 2025: Council working party meeting on the proposal.
• 14 October 2025: Planned final vote by EU home affairs ministers.

patrick-breyer.de/en/danger-to…