troubleshooting

23 Articles

Vintage IBM 1403 Printer Problem Evades An Easy Fix

December 20, 2018 by 15 Comments

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.

The IBM 1403’s type chain has a repeating set of characters that spins around at high speed. Unlike a typewriter or label maker, the hammers are not inside this unit. The hammers are on the outside, and work by pressing the paper onto the type slugs as the required characters line up.

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.

IBM PCjr Revived By An ATX Power Supply And Many False Starts

August 10, 2018 by 26 Comments

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.

Continue reading “IBM PCjr Revived By An ATX Power Supply And Many False Starts” →

Precision Pantograph Probes PCBs

October 4, 2017 by 26 Comments

Electronic components are getting smaller and for most of us, our eyesight is getting worse. When [Kurt] started using a microscope to get a better view of his work, he realized he needed another tool to give his hands the same kind of precision. That tool didn’t exist so he built it.

The PantoProbe is a pantograph mechanism meant to guide a probe for reaching the tiny pads of his SMT components. He reports that he has no longer has any trouble differentiating pins 0.5 mm apart which is the diameter of the graphite sticks in our favorite mechanical pencils.

[Kurt] has already expanded his machine’s capability to include a holder for a high-frequency probe and even pulleys for a pick-and-place variation. There’s no mention of dual-wielding PantoProbes as micro-helping-hands but the versatility we’ve seen suggests that it is only a matter of time.

Four bar linkages are capable of some incredible feats and they’re found all around us. Enjoy one of [Kurt]’s other custom PCBs in his Plexitube Owl Clock, or let him show you to make 3D objects with a laser engraver.

Continue reading “Precision Pantograph Probes PCBs” →

World’s Largest Telescope Stopped By LED

October 3, 2017 by 75 Comments

Earlier this year a simple indicator LED brought the Keck 1 telescope, a 370 tons mass, to a halting stop. How exactly did an LED do this? Simple: it did nothing.

As it so happens, [Andrew Cooper] was just about the leave the summit of Mauna Kea (in Hawaii) when his radio instructed him otherwise: there was an issue. Upon returning, [Andrew] was met by a room of scientists and summit supervisors. “Yeah, this was not good, why are they all looking at me? Oh, h%#*!” The rotor wasn’t moving the telescope, and “no rotator equals no science data.” After being briefed on the problem, [Andrew] got to work. Was it a mechanical issue? No: manual mode worked quite fine, also indicating that the amplifiers and limit switches are functional as well.

Jumping from chip to chip, [Andrew] came across an odd voltage: 9.36V. In the CMOS [Andrew] was investigating, this voltage should have High (15V) or Low (0v) and nowhere in between. Judging by the 9.36V [Andrew] decided to replace the driving IC. One DS3632 later, nothing had changed. Well, maybe is one of the loads pulling the line low? With only two choices, [Andrew] eliminated that possibility quickly. Likely feeling as if he was running out of proverbial rope, [Andrew] remembered something important: “the DS3236 driving this circuit is an open collector output, it needs a pull-up to go high.”

Reviewing the schematic, [Andrew] identified the DS3236’s pull-up: an LED and its current limiting resistor. While the carbon composition resistor was “armageddon proof,” [Andrew] was suspicious of the LED. “Nick, can you get me a 5k resistor from the lab?” Hold the resistor on the pins of the chip and the amplifiers immediately enabled.

[Andrew] summarizes things quite well: “yes… One of the world’s largest telescopes, 370 tons of steel and glass, was brought to a halt because of a bad indicator LED”. It stopped things by doing nothing, or rather, by not turning on.

We love it when we get troubleshooting stories, and if you share our interest in problem-solving, check out this broken power supply troubleshooting or learn what could go wrong with I2C.

Edit: Keck 1 is one of the largest optical telescopes in the world. Thanks to [Josh] for noticing our error.

Steve Collins: When Things Go Wrong In Space

January 19, 2017 by 14 Comments

[Steve Collins] is a regular around Hackaday. He’s brought homebrew LIDARs to our regular meetups, he’s given a talk on a lifetime’s worth of hacking, and he is the owner of the most immaculate Hackaday t-shirt we’ve ever seen.

For the 2016 Hackaday SuperConference,  [Steve] took a break from his day job of driving spacecraft around the Solar System. As you can imagine, NASA plans on things going wrong. How do you plan for that? [Steve] answers all your questions by telling you what happens when things go wrong in space.

Continue reading “Steve Collins: When Things Go Wrong In Space” →

Navigation Thing: Four Days, Three Problems, And Fake Piezos

October 20, 2016 by 13 Comments

The “Navigation Thing“ was designed and built by [Jan Mrázek] as part of a night game activity for high school students during week-long seminar. A night-time path through a forest had stations with simple tasks, and the Navigation Thing used GPS, digital compass, a beeper, and a ring of RGB LEDs to provide a bit of “Wow factor” while guiding a group of students from one station to the next. The devices had a clear design direction:

“I wanted to build a device which a participant would find, insert batteries, and follow the beeping to find the next stop. Imagine the strong feeling of straying in the middle of the night in an unknown terrain far away from civilization trusting only a beeping thing you found. That was the feeling I wanted to achieve.”

The Navigation Things (there are six in total) guide users to fixed waypoints with GPS, a digital compass, and a ring of WS2812 LEDs — but the primary means of feedback to the user is a beeping that gets faster as you approach the destination. [Jan] had only four days to make all six units, which was doable. But as most of us know, delivering on a tight deadline is often less about doing the work you know about, and more about effectively handling the unexpected obstacles that inevitably pop up in the process.

Continue reading “Navigation Thing: Four Days, Three Problems, And Fake Piezos” →

What Could Go Wrong? I2C Edition

July 19, 2016 by 53 Comments

I should really like I2C more than I do. In principle, it’s a brilliant protocol, and in comparison to asynchronous serial and SPI, it’s very well defined and clearly standardized. On paper, up to 127 devices can be connected together using just two wires (and ground). There’s an allowance for multiple clock-masters on the same bus, and a way for slaves to signal that the master needs to wait. It sounds perfect.

In reality, the tradeoff for using only two wires is a significantly complicated signalling and addressing system that brings both pitfalls and opportunities for debugging. Although I2C does reduce the number of signal wires you need, it gets dangerous when you have more than a handful of devices on the same pair of wires, and you’re lucky when they all conform to the same standard. I’ve never seen twenty devices on a bus, much less 127.

But still, I2C has its place. I2C was designed to connect up a bunch of slower, cheaper devices without using a lot of copper real estate compared to its closest rival protocol: SPI. If you need to connect a few cheap temperature sensors to a microcontroller (and their bus addresses don’t clash) I2C is a great choice. So here’s a guide to making it work when it’s not working.

Continue reading “What Could Go Wrong? I2C Edition” →