What Could Go Wrong: SPI

July 1, 2016 by Elliot Williams 58 Comments

Serial Peripheral Interface (SPI) is not really a protocol, but more of a general idea. It’s the bare-minimum way to transfer a lot of data between two chips as quickly as possible, and for that reason alone, it’s one of my favorites. But that doesn’t mean that everything is hugs and daffodils. Even despite SPI’s simplicity, there are still a few ways that things can go wrong.

In the previous article in this series, inspired by actual reader questions, I looked into troubleshooting asynchronous serial connections. Now that you’ve got that working, it’s time to step up to debugging your SPI bus! After a brief overview of the system, we’ll get into how to diagnose SPI, and how to fix it.

Continue reading “What Could Go Wrong: SPI” →

What Could Go Wrong: Asynchronous Serial Edition

June 22, 2016 by Elliot Williams 50 Comments

It’s the easiest thing in the world — simple, straightforward serial data. It’s the fallback communication protocol for nearly every embedded system out there, and so it’s one that you really want to work when the chips are down. And yet! When you need it most, you may discover that even asynchronous serial can cost you a few hours of debugging time and add a few gray hairs to your scalp.

In this article, I’m going to cover most (all?) of the things that can go wrong with asynchronous serial protocols, and how to diagnose and debug this most useful of data transfer methods. The goal is to make you aware enough of what can go wrong that when it does, you’ll troubleshoot it systematically in a few minutes instead of wasting a few hours.

Continue reading “What Could Go Wrong: Asynchronous Serial Edition” →

Retrotechtacular: TV Troubleshooting

May 3, 2016 by Al Williams 30 Comments

As technology advances, finding the culprit in a malfunctioning device has become somewhat more difficult. As an example, troubleshooting an AM radio is pretty straightforward. There are two basic strategies. First, you can inject a signal in until you can hear it. Then you work backwards to find the stage that is bad. The other way is to trace a signal using a signal tracer or an oscilloscope. When the signal is gone, you’ve found the bad stage. Of course, you still need to figure out what’s wrong with the stage, but that’s usually one or two transistors (or tubes) and a handful of components.

A common signal injector was often a square wave generator that would generate audio frequencies and radio frequency harmonics. It was common to inject at the volume control (easy to find) to determine if the problem was in the RF or audio sections first. If you heard a buzz, you worked backwards into the RF stages. No buzz indicated an audio section problem.

A signal tracer was nothing more than an audio amplifier with a diode demodulator. Starting at the volume control was still a good idea. If you heard radio stations through the signal tracer, the RF section was fine. Television knocked radio off of its pedestal as the primary form of information and entertainment in most households, and thus the TV repair industry was created.

Continue reading “Retrotechtacular: TV Troubleshooting” →

Don’t Tempt The Demo Gods

April 30, 2016 by Elliot Williams 9 Comments

Including a live technical demonstration as part of a presentation is a lot like walking a tightrope without a net. Which isn’t to say that we don’t do it — we just keep our fingers crossed and bring our lucky horseshoe. The demo gods have smote [Quinn] a mighty blow, in front of a class at Stanford, no less.

[Quinn]’s scratch-built computer, Veronica, failed to boot in front of a hall of eager students. When the pressure was off, in the comfort of her own lab, [Quinn] got to debugging. You should read her blog post if you’re at all interested in retrocomputing or troubleshooting of low-level hardware bugs. But if you just can’t spare the five minutes for a pleasant read, here’s a spoiler: watch out for flaky card-edge connectors. All’s well that ends well, with a game of pong.

We’ve been following Veronica from her very first clock cycles, so we’re happy to see her back on her feet again. Good job, [Quinn]!

Solving Arduino’s Stk500_getsync() Error

November 22, 2014 by Brian Benchoff 27 Comments

[psgarcha] took a year-old Arduino Uno on an international trip and upon returning found something was wrong. Every time he would try to upload, he would get the dreaded avrdude error, ‘stk500_getsync(): not in sync resp=0x00’. The Rx light would blink a few times during the attempted upload, but the tx light did not. Somehow, something was terribly wrong with the ‘duino, and [psgarcha] dug deep to figure out why.

To test the quality of the Arduino’s serial connection, [psgarcha] performed a loopback test; basically a wire plugged into the Tx and Rx pins of the Arduino. Sending a short message through the serial port showed the problem wasn’t the USB cable, the ATmega16u2 on the ‘duino, or any traces on the board. This would require more thought.

The main reason for the error would then be no communication between the computer and the ‘duino, the wrong COM port selected, the wrong board selected in the Arduino text editor, or timing errors or a corrupt bootloader. The first three errors were now out of the question, leaving timing errors and a corrupt bootloader. Troubleshooting then moved on to ordering a new programmer, and still this didn’t work with the broken Uno.

Frustrated with one of the greatest failures to become an Arduino tinkerer, [psgarcha] took a good, long look at the Uno board. He glanced over to an Arduino Mega board. Something looked different. On the Uno, the resonator had blown off. Problem found, at least.

Replacing the blown part with a hilariously large can crystal oscillator, [psgarcha] was back in business. This isn’t how you would fix 99% of getsync() errors, and it’s difficult imagining a situation where a this part would randomly blow, but if you’re ever looking at a nearly intractable problem, you need to start looking at what really shouldn’t fail.

Awesome rework, though.

Diagnose And Repair A Yaesu FT-7800 Ham Radio

November 11, 2013 by Todd Harrison 26 Comments

[Alan Wolke] aka [w2aew] was challenged to repair a friends Yaesu FT-7800 ham radio. This radio operates on two ham bands, 2 m VHF and 70 cm UHF. The complaint was that the 2 m side was not working but the 70 cm was transmitting fine. Alan started by verifying the complaint using a Bird watt meter with a 50 watt slug and terminating the signal into a 50 W dummy load. [Allen’s] bird meter is the type that has an RF sampler that can be connected to an oscilloscope for added signal viewing and validation.

After verifying that the radio was not working as described, Alan starts by glancing over the circuit board to look for any obvious damage. He then walks us through a block diagram as well as a circuit diagram of the FT-7800 radio before stepping us through the troubleshooting and diagnostics of radio repair. Even when he realizes he might have found the problem he still steps us through the remainder of his diagnostics. The skills and knowledge that Alan shares is extremely valuable to anybody looking to repair radios.

Spoiler alert. At the end of the first video he determines that the pin diodes near the final VHF output were bad. In the second video he reveals that he could no longer source these bad components. Through some clever evaluation of a more current Yaesu radio, [Allen] was able to find suitable replacement components. Lesson two ends with some surface mount solder rework tips as well as testing that the repair was successful.

And just in case you don’t know what a pin diode is, or is used for, Alan shares a third video covering just what this component is and does in a radio. You can follow the jump to watch all three videos.

Continue reading “Diagnose And Repair A Yaesu FT-7800 Ham Radio” →

The Dish-o-Tron 6000 Is Back And Better Than Ever

August 24, 2011 by Mike Nathan 30 Comments

dish_o_tron_6000_extreme

When designing a circuit on the bench, sometimes things work far better than they do in real life. [Quinn Dunki] learned this lesson over the last few months as she struggled with one of her recent creations, the Dish-o-Tron 6000. We featured the Dish-o-Tron back in April, and at that point things seemed to be working out well for [Quinn]. As time passed however, she found the device to be an unreliable power hog. Aside from eating through a battery every few weeks, it kept spontaneously switching states from ‘Dirty’ to ‘Clean’ and back. It was time to take the Dish-o-Tron back to the bench for some debugging.

The random status flip from ‘Dirty’ to ‘Clean’ was a relatively easy fix, and required a small capacitor between the set pin and ground to eliminate the electrical noise that was tripping things up. She nailed down the spontaneous ‘Clean’ to ‘Dirty’ flip to a stuck tilt switch, which she swapped out for a mercury-based model, making things far more reliable. She solved her battery problems by wiring in a 12v wall wart, which might not be any more energy efficient, but it does save her from swapping out batteries all the time.

It’s always nice to see how projects evolve over time, and how the inevitable bugs are worked out of an initial design.