TechyMagThings

Water timers are nifty devices that can water the lawn at set times or keep that vegetable garden from turning into a dustbowl. When [electronupdate] timer refused to output water on any of its three outlets, he did the right thing. Instead of angrily checking the warranty on the sodding thing, he tore it apart to attempt a repair.

As expected, the design of these devices is quite straightforward. Three solenoids control whether an outlet is open or closed. A control board also handles the user controls and display.

There was no obvious sign of damage, and the PCB was potted in a white substance that should have kept out any moisture. A quick check with a battery revealed that the three solenoids also worked just fine, so the cause likely was somewhere on the — potted — PCB.

These solenoids are rated for 6VDC and take about 20 ms to act, but on an oscilloscope capture it was plain to see that the board was only putting out around 2V. This wasn’t enough to drive the solenoid, raising the question of what had gone wrong on the controller board and setting the stage for some fun epoxy potting compound scraping.

A good bit of elbow grease revealed the control ICs, the H-bridges that drive the solenoids, and the rest of the circuitry, including a power boost circuit with a big electrolytic capacitor. The latter had a bit of suspicious liquid near its base, which turned out to be the culprit. Perhaps the most annoying thing here is that this electrolytic capacitor had the temerity to fail after only four months of use, but at least it was an easy enough fix.

If we had been in there, we might have been tempted to avoid many future battery changes. Impractical, but we wonder if anyone ever built a water timer with a water clock?

The RP2350 is actually a pretty secure chip, all things considered. It has secure boot, ARMv8’s TrustZone to split secure and non-secure execution, and you can permanently disable debug — the Pi Foundation even included glitch detection, meaning the traditional ‘zap the chip until it obeys’ technique is blocked. That’s why the [Ledger Donjon] security team went full Bond Villain and strapped everyone’s favourite fruit-flavoured microcontroller to a table with a slowly-approaching laser beam.

Okay — movie clichés aside, the laser was in fact very carefully focused on target before they turned it on. That target was the register that enables the 2350’s debug features. Said register was located by decapsulating the chip and examining the die with photon-emission electron microscopy; the actual attack was carried out on a chip that had been decapped on the back side, with IR shining through the silicon wafer. There was probably more than a little trial-and-error to figure out exactly where on the die adjacent to the register to zap with the laser to flip those bits. But flip they did, restoring the debugger’s access to the secure execution zone. Then, after resetting the chip, [Ledger]’s team read the 128-bit secret the Pi Foundation hid in memory as part of the 2350 hacking challenge.

It’s long been accepted that once the black hats — or white hats, for that matter — have their hands on your hardware, they’re going to find a way in. The effort it takes to break into a simple microcontroller here is actually kind of impressive. We’ve talked about laser fault injection before; ironically, we’ve also featured Pi Pico-powered glitching attacks — the kind that this chip’s glitch detection thwarts.

A Linux handheld computer is, in theory, easy and inexpensive given the availability of single-board computers, but in practice the budget invariably edges well into three figures. There’s an interesting alternative from [bkovac] that won’t break the bank as much, using a cheap 4G wireless hotspot, an iPhone USB keyboard case accessory, and, though a cheaper display could suffice, a fancy Adafruit Sharp memory display.

The hotspot is available from AliExpress for around 20 dollars/Euros/pounds, and it’s referred to by its model number, MF800. It’s powered by a Qualcomm MSM8916, also known as the Snapdragon 410, which you might have found in a budget cellphone early in the last decade. Importantly, though, it’s supported by mainstream Linux, and while it’s by no means the fastest on the block, it can be a poor man’s alternative to a Raspberry Pi. It comes with a small SPI display, but this project replaces it with a much bigger Sharp SPI memory display.

The build walks through a few case mods and a PCB mod on the modem, getting the keyboard to fit, and making a custom power board. Perhaps the software setup is the most interesting part, because this isn’t a simple case of installing a distro. Instead, there’s quite a bit of hackery to get the display working.

We really like this project because while a Linux handheld is nothing new, it’s making one using an unexpected starting point. It reminds us of the old days of running Linux on an old router.

This article is written on an open-source operating system, but not an open-source machine — the BIOS isn’t open-source, and even if it were supported by the coreboot project (formerly LinuxBIOS), there would still be a whole host of binary blobs required to get it to boot. On one vintage architecture, there’s one less blob, as coreboot can now initialize DRAM on Intel Bay Trail SOCs, as [Mate Kukri] presented in a talk at the recent Open Source Firmware Conference.

Bay Trail isn’t exactly cutting-edge hardware, to be sure — the SoCs are over a decade old at this point, and were only used in low-performance mobile applications like Chromebooks. On the other hand, coreboot has been on Chromebooks for at least as long. Getting DRAM set up is difficult because, well, you don’t have any memory to work with until you do. Traditionally, the way you did that was to call on one of the many proprietary ‘binary blobs’ provided with next to no documentation by the manufacturer. Reverse engineering that requires some serious bus-sluthing, which was done in software with the SerialICE debugger and the Unicorn Engine CPU emulator. The talk focused on that technique and how it might be applied more widely, rather than getting into the weeds of how to do DRAM init on one obsolete SOC. At some point the whole thing should be archived on the OFSC website so those of us not lucky enough to attend in person can hear what [Mate] — and all the other speakers — had to say.

Because coreboot is open, you can do a lot more with it than a proprietary UEFI firmware — for example, you can choose not to initialize RAM at all, and run entirely in the CPU’s cache. You can also — of course — run DOOM. If you want to be binary-blob-free, you’ll need to find hardware supported by the more hardcore Libreboot distribution of coreboot, which admits no binary blobs at all. When it comes to Libreboot, it might actually be easier to install than to find compatible hardware these days.

If you’ve used MicroPython much, you know that debugging usually amounts to printing a few things out, trying your code out, and then repeating. But [ghi-electronics] wants you to have full on-chip source-code debugging in Visual Studio. You don’t need anything special to use it — just a supported MicroPython host and the same USB cable you program with now.

The downside is that you either have to build a custom MicroPython image and flash it or use one that they include. They support several Raspberry Pi Pico versions and ESP32 chips, as well. However, at least one “odd” Pico we had lying around wouldn’t take the firmware. A stock one did, and it worked as you would expect. A little more investigation showed the odd Pico (an RP2040 GEEK) probably did take the firmware; it just produced an error during setup. There is a known problem with Linux and the ESP32-S3 having similar behavior.

Of course, you can build your own image, but now you are talking a bit more work to get a toolchain and all the dependencies together. For simple programs, you might not need a full-blown debugger. But it is nice to be able to peek at variables and see the control flow visually.

There are a few limitations documented on GitHub. For example, you can’t catch exceptions that the code already catches, although, presumably, you could set a breakpoint in the exception handler. Breakpoints halt all threads. There are a few other limits, but nothing we’d consider a showstopper.

Full Python has some debugging assistance built into it. MicroPython has some of the same things, but it isn’t trivial to build a debugger.

In 1982, desktop computers were coming into their own, and no clear leaders had emerged. But everyone knew they wanted a piece of the action. This led to, among other things, Sony’s SMC-70, which, frankly, for 1982, was a good-looking, if not oddball, machine. [Tech Tangents] shows the machine off in a recent video.

From the front, the computer looks more-or-less like everything else. But as you move backward, you can see this computer wasn’t another typical entry into the market. One of the things that was the hallmark of successful business computers of the day was expandability. The earlier Altair had the later-titled S100 bus. The IBM PC had the ISA bus. But in both cases, you had to open the box to plug and unplug cards.

The SMC-70, though, had a very unique system. Instead of boards, users would line up modules and stab them with what amounted to skewers to mechanically secure the stack of modules. You could stack some modules vertically or horizontally using ribbon cables or external cables. This particular box needed some power supply work, and a 3D printer lets it look essentially stock.

Computing-wise, the SMC-70 was pretty typical. A CP/M machine with a 4 MHz Z-80 wasn’t novel then, although few CP/M systems had 3.5-inch floppies. What set the Sony apart was its 16-color graphics system, which was well ahead of its time. It even had some sound capability.

It also had a module that offered quite a bit of video output capability, which shouldn’t be surprising given Sony’s other product lines. There was, apparently, an 8086 module that eventually became available, but it was late and didn’t run MS-DOS (but could run CP/M-86).

A few nice features didn’t catch on. A dedicated red help button on the keyboard was a nice idea, for example. There was even a RAM disk mode, which was great if you didn’t suffer power outages.

Of course, Sony made many more computers. If you want to play with a CP/M machine, you probably could get a virtual one up in a few minutes.

In the cross-over between the era of tapes into that of MP3s, you’d see quite a few of those special cassette tapes that were actually digital music players inside. Some simply provided a 3.5 mm input, while others were complete MP3 players or Bluetooth receivers that just happened to also output to the magnetic read head of a cassette player. Recently [Jonathan Rowny] decided to make his own version of the latter.

Although getting the actual audio signal into the read head is easy enough – requiring little more than its equivalent being used as a write head on the cassette side – actually interfacing with the player’s mechanisms like auto-stop, reverse and so on requires the use of some gearing that detect motion on what would be the tape spools, as well as transfer the motion from the take-up spool to the other spool so that features like the auto-stop mechanism don’t get triggered.

A lot of inspiration here can be found in e.g. the videos made by [Clint] of [Lazy Game Reviews] who looked at a number of examples – including their internals – over the years, with various levels of functionality. For this particular implementation an ESP32-S3 module is used for the brains, along with a microSD card reader for music and a PCM5102 I2S audio codec to create the analog audio signal.

The gears were printed using an SLA printer and seem to work all right. Unfortunately he didn’t realize the importance of the capstan as the mechanism that actually transports the tape, so its motion was not measured as is done in the better cassette adapters. This will likely be corrected in a future iteration, however.