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.
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.
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.
We know what you’re thinking. It’s a bad power supply, of course it was capacitors to blame. But even if we all intuitively know at this point that bad caps are almost always the culprit when a PSU gives up the ghost, it’s not always easy to figure out which one is to blame. Which is why this deep dive into a failed ETK450AWT by [eigma] is worth a look.
The first sign of trouble was when the computer would unexpectedly reboot with nothing in the system logs to indicate a problem. Eventually, [eigma] noticed a restart before the operating system even loaded, which confirmed the hardware was to blame. A quick look at the PSU output with a voltmeter showed things weren’t too far out of spec, but putting an oscilloscope on the 12 V line uncovered a nasty waveform that demanded further investigation.
By carefully following traces and comparing with common PSU diagrams, [eigma] was able to identify the SG5616 IC that checks the various voltages being produced by the PSU and generates the PWR_OK signal which tells the motherboard that everything is working normally. As before, all of the DC voltages at this chip seemed reasonable enough, but the pin that was measuring AC voltage from the transformer was showing the same ripple visible on the 12 VDC line.
Even more digging uncovered that the transformer itself had a control IC nestled away. The 13 VDC required by this chip to operate is pulled off the standby transformer by way of a Zener diode and a couple capacitors, but as [eigma] soon found, the circuit was producing another nasty ripple. Throwing a few new capacitors into the mix smoothed things out and got the PSU to kick on, but that’s not quite the end of the story.
Pulling the capacitors from the board and checking their values with the meter, [eigma] found they too appeared to be within reasonable enough limits. They even looked in good shape physically. But with the help of a signal generator, he was able to determine their equivalent series resistance (ESR) was way too high. Case closed.
Good old nRF24L01+ wireless modules are inexpensive and effective. Well, they are as long as they work correctly, anyway. The devices themselves are mature and well-understood, but that doesn’t mean bad batches from suppliers can’t cause hair-pulling problems straight from the factory.
The Computer History Museum in Mountain View has two operational IBM 1401 mainframes, which use IBM 1403 high-speed printers. They aren’t some decades-old notion of “high speed” that barely looks sluggish today, either. These monsters slam out ten lines per second thanks to a rotating chain of type slugs and an array of electromagnetic hammers. Every 11.1 microseconds, a character in the chain would be lined up with a hammer, and if the control circuitry identified it as a character that needed to be printed, the hammer behind the paper would drive the paper into the print ribbon and the slug, putting an imprint of the character onto the paper. When one of these printers failed with a sync error, it kicked off some serious troubleshooting to diagnose the problem.
Investigation of the problem ultimately led to an intermittent connection in a driver card due to a broken PCB trace, but by then some fuses had been blown as well. In the end the printer was brought back online, but possibly with a slightly damaged coil on one of the hammers.
[Ken]’s writeup on the repair process is highly detailed and walks through the kind of troubleshooting and repairs involved when solving problems with vintage electronics. Electrical fundamentals might be the same, but a deep understanding of not only the architecture but also the failure modes of vintage hardware is needed in order to troubleshoot effectively.
If IBM 1401 mainframes and fixing 1403 printers sounds familiar, it’s because a printer fix has been done before. That was due to a different problem, but still a challenging task to narrow down and fix.
The IBM PCjr was a computer only the marketing geniuses of a multi-billion dollar corporation could love. On the face of it, it seemed like a great idea – a machine for the home market, meant to complement the “big boy” IBM PC in the office and compete against the likes of Apple and Commodore. What it ended up as was a universally hated, only partially PC-compatible machine which sold a mere half-million units before being mercifully killed off.
That doesn’t mean retrocomputing fans don’t still snap up the remaining machines, of course. [AkBKukU] scored a PCjr from a thrift store, but without the original external brick power supply. An eBay replacement for the 18-VAC supply would have cost more than the computer, so [AkBKukU] adapted a standard ATX power supply to run the PCjr. It looked as if it would be an easy job, since the external brick plugs into a power supply card inside the case which slots into the motherboard with a card-edge connector. Just etch up a PCB, solder on an ATX Molex connector, and plug it in, right? Well, not quite. The comedy of errors that ensued, from the backward PCB to the mysteriously conductive flux, nearly landed this one in the “Fail of the Week” bin. But [AkBKukU] soldiered on, and his hand-scratched adapter eventually prevailed; the video below tells the whole sordid tale, which thankfully ended with the sound of the machine booting from the 5-1/4″-floppy drive.
In the end, we’ve got to applaud [AkBKukU] for taking on the care and feeding of a machine so unloved as to be mentioned only a handful of times even on these pages. One of those articles marks the 25th anniversary of the PCjr, and lays out some of the reasons for its rapid disappearance from the market.