Lowering Your Noise Floor, The Easy Way

If there’s anything more annoying to an amateur radio operator than noise, we’re not sure what it could be. We’re talking about radio frequency noise, of course, the random broadband emissions that threaten to make it almost impossible to work the bands and pick out weak signals. This man-made interference is known as “QRM” in ham parlance, and it has become almost intolerable of late, as poorly engineered switch-mode power supplies have become more common.

But hams love a technical challenge, so when a nasty case of QRM raised its ugly head, [Kevin Loughlin (KB9RLW)] fought back. With an unacceptable noise floor of S8, he went on a search for the guilty party, and in the simplest way possible — he started flipping circuit breakers. Sure, he could have pulled out something fancier like a TinySA spectrum analyzer, but with his HF rig on and blasting white noise, it was far easier to just work through the circuits one by one to narrow the source down. His noise problem went away with the living room breaker, which led to pulling plugs one by one until he located the culprit: a Roomba vacuum’s charging station.

Yes, this is a simple trick, but one that’s worth remembering as at least a first pass when QRM problems creep up. It probably won’t help if the source is coming from a neighbor’s house, but it’s a least worth a shot before going to more involved steps. As for remediation, [Kevin] opts to just unplug the Roomba when he wants to work the bands, but if you find that something like an Ethernet cable is causing your QRM issue, you might have to try different measures.

Continue reading “Lowering Your Noise Floor, The Easy Way”

Ball Nut Modification Charts A Middle Course Between Building And Buying

A lot of the projects we feature here on Hackaday engender the classic “build versus buy” argument. We’ve always been puzzled by that; if anyone can appreciate the sheer joy of making something rather than buying it, it should be our readers. But there’s something to be said for buying the stuff you can buy and concentrating your effort on the bespoke aspects of the project. It’s perhaps not as exciting, but needs must, oftentimes.

Let’s not forget there’s a third way though, which [Andy] explores with this ball nut modification project. Keen-eyed readers will recall [Andy]’s recent scratch-built ball screw build, in service of some top-secret, hush-hush project related to world domination and total subjugation of humanity. His homebrew efforts in this regard were a great lesson in how to machine a complex mechanism to work in a constrained space. Still, it left folks wondering why he’d go to all the trouble when he could have just trimmed an off-the-shelf part down to size. So, he decided to give that a try.

Continue reading “Ball Nut Modification Charts A Middle Course Between Building And Buying”

A Die-Level Look At The Pentium FDIV Bug

The early 1990s were an interesting time in the PC world, mainly because PCs were entering the zeitgeist for the first time. This was fueled in part by companies like Intel and AMD going head-to-head in the marketplace with massive ad campaigns to build brand recognition; remember “Intel Inside”?

In 1993, Intel was making some headway in that regard. The splashy launch of their new Pentium chip in 1993 was a huge event. Unfortunately an esoteric bug in the floating-point division module came to the public’s attention. [Ken Shirriff]’s excellent account of that kerfuffle goes into great detail about the discovery of the bug. The issue was discovered by [Dr. Thomas R. Nicely] as he searched for prime numbers. It’s a bit of an understatement to say this bug created a mess for Intel. The really interesting stuff is how the so-called FDIV bug, named after the floating-point division instruction affected, was actually executed in silicon.

We won’t presume to explain it better than [Professor Ken] does, but the gist is that floating-point division in the Pentium relied on a lookup table implemented in a programmable logic array on the chip. The bug was caused by five missing table entries, and [Ken] was able to find the corresponding PLA defects on a decapped Pentium. What’s more, his analysis suggests that Intel’s characterization of the bug as a transcription error is a bit misleading; the pattern of the missing entries in the lookup table is more consistent with a mathematical error in the program that generated the table.

The Pentium bug was a big deal at the time, and in some ways a master class on how not to handle a complex technical problem. To be fair, this was the first time something like this had happened on a global scale, so Intel didn’t really have a playbook to go by. [Ken]’s account of the bug and the dustup surrounding it is first-rate, and if you ever wanted to really understand how floating-point math works in silicon, this is one article you won’t want to miss.

The Business Card Of DOOM

This account of running DOOM on a PCB business card isn’t really about serving the “Will it DOOM?” meme of getting the classic game to run on improbable hardware. Rather, this project has more to do with getting it done right and leveraging work that’s already been done.

We’ll explain. You may recall [rsheldiii]’s previous DOOM keycap build, which was quite an accomplishment for someone who doesn’t fancy himself a hardware hacker. But he made a fair number of compromises to pull that build off, and rather than letting those mistakes propagate, he decided to build a more general platform to serve as a jumping-off point for the DOOM building community. The card is centered on the RP2040, which keeps things pretty simple. The card has a tiny LCD screen along with USB jacks for power and a keyboard, so you can actually play the game. It also has GPIO lines brought out to pads on the edge of the board, in case you want to do something other than play the game, which is shown in the brief video below.

Pretty standard stuff, right? Perhaps, but where this project stands out for us is that it stresses the importance of relying on reference circuits. We’ve all seen projects that have been derided for pulling the example circuit from the datasheet, but as [rsheldiii] points out, that seems a little wrongheaded. Component manufacturers put a lot of effort into those circuits, and they don’t do it out of the goodness of their hearts. Yes, they want to make it easier for engineers to choose their parts, but in doing so they’ve done a lot of the work for you. Capitalizing on that work wherever possible only makes sense, and in this case the results were perfect for the task at hand.

Continue reading “The Business Card Of DOOM

A Low-Cost Spectrometer Uses Discrete LEDs And Math

A spectrometer is a pretty common lab instrument, useful for determining the absorbance of a sample across a spectrum of light. The standard design is simple; a prism or diffraction grating to break up a light source into a spectrum and a detector to measure light intensity. Shine the light through your sample, scan through the spectrum, and graph the results. Pretty easy.

That’s not the only way to do it, though, as [Markus Bindhammer] shows with this proof-of-concept UV/visible spectrometer. Rather than a single light source, [Marb] uses six discrete LEDs, each with a different wavelength. The almost-a-rainbow’s-worth of LEDs are mounted on circular PCB, which is mounted to a stepper motor through a gear train. This allows the instrument to scan through all six colors, shining each on the sample one at a time. On the other side of the flow-through sample cuvette is an AS7341 10-channel color sensor, which can measure almost the entire spectrum from UV to IR.

The one place where this design seems iffy is that the light source spectrum isn’t continuous, as it would be in a more traditional design. But [Marb] has an answer for that; after gathering data at each wavelength, he applies a cubic spline interpolation to derive the spectrum. It’s demonstrated in the video below using chlorophyll extracted from spinach leaves, and it seems to generate a reasonable spectrum. We suppose this might miss a narrow absorbance spike, but perhaps this could be mitigated by adding a few more LEDs to the color wheel.

Continue reading “A Low-Cost Spectrometer Uses Discrete LEDs And Math”

Blast Away The Flux — With Brake Cleaner?

Can you use brake cleaner for flux removal on PCBs? According to [Half Burnt Toast], yes you can. But should you? Well, that’s another matter.

In our experience, flux removal seems to be far more difficult than it should be. We’ve seen plenty of examples of a tiny drop of isopropyl alcohol and a bit of light agitation with a cotton swab being more than enough to loosen up even the nastiest baked-on flux. If we do the same thing, all we get is a gummy mess embedded with cotton fibers smeared all over the board. We might be doing something wrong, or perhaps using the wrong flux, but every time we get those results, we have to admit toying with the idea of more extreme measures.

The LED bar graphs were not a fan of the brake cleaner.

[Toast] went there, busting out a fresh can of brake cleaner and hosing down some of the crustier examples in his collection. The heady dry-cleaner aroma of perchloroethylene was soon in the air, and the powerful solvent along with the high-pressure aerosol blast seemed to work wonders on flux. The board substrate, the resist layer, and the silkscreen all seemed unaffected by the solvent, and the components were left mostly intact; one LED bar graph display did a little melty, though.

So it works, but you might want to think twice about it. The chlorinated formula he used for these tests is pretty strong stuff, and isn’t even available in a lot of places. Ironically, the more environmentally friendly stuff seems like it would be even worse, loaded as it is with acetone and toluene. Whichever formula you choose, proceed with caution and use the appropriate PPE.

What even is flux, and what makes it so hard to clean? Making your own might provide some answers.

Continue reading “Blast Away The Flux — With Brake Cleaner?”

A LoRa Rain Gauge From The Ground Up

It’s a fair bet that most of us have a ton of wireless doo-dads around the house, from garage door remotes to wireless thermometers. Each of these gadgets seems to have its own idea about how to encode data and transmit it, all those dedicated receivers seem wasteful. Wouldn’t it be great to use existing RF infrastructure to connect your wireless stuff?

[Malte Pöggel] thinks so, and this LoRa rain gauge is the result. The build starts with a commercially available rain transmitter, easily found on the cheap as an accessory for a wireless weather station and already equipped with an ISM band transmitter. The rain-collection funnel and tipping-bucket mechanism were perfectly usable, and the space vacated by the existing circuit boards left plenty of room to play, not to mention a perfectly usable battery compartment. [Malte] used an ATmega328P microcontroller to count the tipping of the bucket, either through the original reed switch or via Hall Effect or magnetoresistive sensors. An RFM95W LoRa module takes care of connecting into [Malte]’s LoRaWAN gateway, and there’s an option to add a barometric pressure and temperature sensor, either by adding the BMP280 chip directly to the board or by adding a cheap I2C module, for those who don’t relish SMD soldering.

[Malte] put a lot of work into power optimization, and it shows. A pair of AA batteries should last at least three years, and the range is up to a kilometer—far more than the original ISM connection could have managed. Sure, this could have been accomplished with a LoRa module and some jumper wires, but this looks like a fantastic way to get your feet wet in LoRa design. You could even print your own tipping bucket collector and modify the electronics if you wanted.