The tape reader and amplifiers mounted with the other UE1 modules. (Credit: David Lovett, YouTube)
After recently putting together the paper tape reader for his custom tube-based UE1 computer, [David Lovett] did get squiggles on the outputs, but not quite the right ones. In the most recent video, these issues are addressed one by one, so that this part of the UE1 1-bit computer can be called ‘done’. Starting off the list of issues were the odd readings from the photodiodes, which turned out to be due to the diodes being misaligned and a dodgy solder joint. This allowed [David] to move on to building the (obviously 6AU6 tube-based) amplifier for the photodiode output signals.
Much like the Bendix G-15’s tape reader which served as inspiration, this also meant adding potentiometers to adjust the gain. For the clock signal on the tape, a clock recovery PCB was needed, which should provide the UE1 computer system with both the clocks and the input data.
Using the potentiometers on the amplification board, the output signals can be adjusted at will to give the cleanest possible signal to the rest of the system, which theoretically means that as soon as [David] adds the permanent wiring and a few utility boards to allow the code to manipulate the tape reader (e.g. halt) as well as manual inputs. The UE1 computer system is thus being pretty close to running off tape by itself for the first time and with it being ‘complete’.
Before the age of lithium batteries, any project needing to carry its own power had to rely on batteries that were much less energy-dense and affordable. In many ways, we take modern lithium technology for granted, and can easily put massive batteries in our projects by the standards of just a few decades ago. While the affordability of lithium batteries has certainly decreased the amount of energy we need to put in to our projects to properly size batteries, there’s still a lot of work to be done if you’re working on a bigger project or just want to get the maximize the efficiency and effectiveness of your DIY battery pack.
The main problem with choosing a battery, as [ionworks] explains, is that batteries can’t be built for both high energy and high power, at least not without making major concessions for weight or cost. After diving in to all of the possible ways of customizing a battery, the battery guide jumps in to using PyBaMM to perform computational modeling of potential battery designs to hopefully avoid the cumbersome task of testing all of the possible ways of building a battery. With this tool virtually all of a battery’s characteristics can be simulated and potential problems with your setup can be uncovered before you chose (or start production of) a specific battery system.
While customizing a battery pack to this extent might not be a consideration for most of us unless the project is going to be big enough to run something like an electric car or a whole-house generator, it’s a worthwhile tool to know about as even smaller projects like ebikes can benefit from choosing the right cell for the application. Some of the nuances of battery pack design can be found in this guide to building packs from the standard 18650 cells.
Troubleshooting a circuit is easy, right? All you need is a couple of hands to hold the probes, another hand to twiddle the knobs, a pair of eyes to look at the schematic, another pair to look at the circuit board, and, for fancy work, X-ray vision to see through the board so you know what pads to probe. It’s child’s play!
In the real world, most of us don’t have all the extra parts needed to do the job right, which is where something like CircuitScout would come in mighty handy. [Fangzheng Liu] and [Thomas Juldo]’s design is a little like a small pick-and-place machine, except that instead of placing components, the dual gantries place probes on whatever test points you need to look at. The stepper-controlled gantries move independently over a fixture to hold the PCB in a known position so that the servo-controlled Z-axes can drive the probes down to the right place on the board.
As cool as the hardware is, the real treat is the software. A web-based GUI parses the PCB’s KiCAD files, allowing you to pick a test point on the schematic and have the machine move a probe to the right spot on the board. The video below shows CircuitScout moving probes from a Saleae logic analyzer around, which lets you both control the test setup and see the results without ever looking away from the screen.
CircuitScout seems like a brilliant idea that has a lot of potential both for ad hoc troubleshooting and for more formal production testing. It’s just exactly what we’re looking for in an entry for the Gearing Up round of the 2023 Hackaday Prize.
A computer’s BIOS includes basic diagnostic tools for troubleshooting issues. Often, we rely on the familiar beeps from the POST system for this reason. However, error codes are also available via hardware “POST Cards” that were particularly popular in the 1990s. [Mr. Green] has now built a POST card using readily-available modern hardware.
[Mr. Green] built the device to help troubleshoot an x86 based firewall appliance that was having trouble. Like many x86 systems, it featured a Low Pin Count (LPC) bus which can be used to capture POST troubleshooting codes. By hooking up a Raspberry Pi Pico to the LPC bus on the firewall’s motherboard, it was possible to get it to display the POST error codes on some LEDs. This is of great use in the absence of a conventional PC speaker to sound the error out with beeps.
The build can be used for POST-based troubleshooting on any x86 system with an LPC bus. Files are on Github for those eager to replicate the build. We’ve seen similar work before, too. Video after the break.
A right-to-repair battle is being waged in courts. The results of it, we might not see for a decade. The Caps Wiki is a project tackling our repairability problem from the opposite end – making it easy to share information with anyone who wants to repair something. Started by [Shelby], it’s heavily inspired by his vintage tech repairs experience that he’s been sharing for years on the [Tech Tangents] YouTube channel.
When repairing a device, there are many unknowns. How to disassemble it? What are the safety precautions? Which replacement parts should you get? A sporadic assortment of YouTube videos, iFixit pages and forum posts might help you here, but you have to dig them up and, often, meticulously look for the specific information that you’re missing.
The Caps Wiki talks a lot about capacitor replacement repairs – but not just that. Any device, even modern ones, deserves a place on the Caps Wiki, only named like this because capacitor repairs are such a staple of vintage device repair. You could make a few notes about something you’re fixing, and have them serve as help and guideline for newcomers. With time, this won’t just become a valuable resource for quick repairs and old tech revival, but also a treasure trove of datapoints, letting us do research like “which capacitors brands or models tend to pass away prematurely”. Plus, it also talks about topics like mains-powered device repair safety or capacitor nuances!
It would be fair to say that the Internet as we know it runs on Cisco hardware. While you might never see the devices first-hand, there’s an excellent chance that every web-bound packet leaving your computer or smartphone will spend at least a few milliseconds of its life traveling through hardware built by the San Jose, California based company. But of course, even a telecommunications giant like Cisco had to start somewhere.
Cisco’s first commercial router, the Advanced Gateway Server (AGS), was released in 1986 and helped put the company (and the Internet) on the path towards unfathomable success. [Andreas Semmelmann] had wanted to add one of these microwave-sized machines to his collection for some time, so when an AGS+ popped up in the local classifieds he didn’t hesitate to make the hour drive to go pick it up. But like many pieces of vintage computing equipment, it needed a little help getting back on its feet.
What 4 MB of flash looked like in the late 1980s.
Since he had to take the router apart anyway to diagnose what ailed it, [Andreas] decided to take photographs along the way and document this piece of Internet history. He walks the reader through the massive processor, Ethernet, and serial cards that are housed in the unit’s rack-like enclosure. We appreciate him taking the scenic route, as it gives us a great look inside what would have been state-of-the-art telecommunications gear when this version of the AGS hit the market in 1989.
The walk-through is full of interesting details that make us appreciate just how far things have come in the last 32 years. Imagine yanking the EPROMs out of the board and firing up the UV eraser each time you needed to update your router’s firmware. Or needing a special adapter to convert the AUI-15 connectors on the back panel to the now ubiquitous RJ45 jack.
After this stroll down memory lane, [Andreas] gets to the actual repair work. It likely won’t surprise the regular Hackaday reader to find that the power supply wasn’t operating to spec, and that some aged capacitors and a shorted rectifier diode needed to be replaced to put it back on an even keel. But even with the PSU repaired, the router failed to start. The console output indicated the software was crashing, but hardware diagnostics showed no obvious faults.
Replacing these failed PSU components was just the beginning.
With some part swapping, firmware flashing, and even a bit of assistance from Cisco luminary [Phillip Remaker], the issue was eventually identified as a faulty environmental monitoring (ENVM) card installed in the AGS+. As luck would have it the ENVM capability isn’t required to boot the router, so [Andreas] was able to just disconnect the card and continue on with his exploration of the hardware that helped build the Internet as we know it.
We’ve all experienced that magic moment when, after countless frustrating hours of experimentation and racking your brain, the object of our attention starts working. The 3D printer finally produces good output. The hacked up laptop finally boots. The car engine finally purrs. The question is, do we know why it started working?
This is more important than you might think. Knowing the answer lets you confirm that the core problem was solved, otherwise you may have just fixed a symptom. And lack of understanding means fixing one problem may just create another.
The solution is to adopt a methodical troubleshooting method. We’re talking about a structured problem solving technique that when used properly can help us solve a problem at its core without leaving any loose ends. Such methodology will also leave you knowing why any solution did or didn’t work in the end, and will give you reproducible results.
