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

October 20, 2016 by Donald Papp 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 Elliot Williams 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” →

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.