Dress Up Your 3D Prints With Toner-Transfer Labels

We’ve always found the various methods for adding text and graphics to 3D prints somewhat underwhelming. Embossed or debossed characters are fuzzy, at best, and multi-color printers always seem to bleed one color into the next. Still, the need for labels and logos is common enough that it’s worth exploring other methods, such as this easy toner transfer trick.

Home PCB makers will probably find the method [Squalius] describes in the video below very familiar, and with good reason. We’ve seen toner transfer used to mask PCBs before etching, and the basic process here is very similar. It starts with printing the desired graphics on regular paper using a laser printer; don’t forget to mirror the print. The printed surface is scuffed up a bit, carefully cleaned, and coated with a thick layer of liquid acrylic medium, of the kind used in paint pouring. The mirrored print is carefully laid on the acrylic, toner-side down, and more medium is brushed on the back of the paper. After the print dries, the paper is removed with a little water and some gentle friction, leaving the toner behind. A coat of polyurethane protects the artwork reasonably well.

[Squalius] has tested the method with PLA and PETG and reports good results. The text is clear and sharp, and even fine text and dithered graphics look pretty good. Durability could be better, and [Squalius] is looking for alternative products that might work better for high-wear applications. It looks like it works best on lightly textured surfaces, too, as opposed to surfaces with layer lines. We’d love to see if color laser prints work, too; [Squalius] says that’s in the works, and we’ve seen examples before that are reason for optimism.

Continue reading “Dress Up Your 3D Prints With Toner-Transfer Labels”

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