Precision Pantograph Probes PCBs

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

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

[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

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

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 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

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

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”