Supercon 2023: Receiving Microwave Signals From Deep-Space Probes

October 10, 2024 by Lewin Day 5 Comments

Here’s the thing about radio signals. There is wild and interesting stuff just getting beamed around all over the place. Phrased another way, there are beautiful signals everywhere for those with ears to listen. We go about our lives oblivious to most of them, but some dedicate their time to teasing out and capturing these transmissions.

David Prutchi is one such person. He’s a ham radio enthusiast that dabbles in receiving microwave signals sent from probes in deep space. What’s even better is that he came down to Supercon 2023 to tell us all about how it’s done!

Continue reading “Supercon 2023: Receiving Microwave Signals From Deep-Space Probes” →

Fail Of The Week: The Case Of The Curiously Colored Streetlights

October 9, 2024 by Dan Maloney 119 Comments

What color are the street lights in your town? While an unfortunate few still suffer under one of the awful colors offered by vapor discharge lamps, like the pink or orange of sodium or the greenish-white of mercury, most municipalities have moved to energy-saving LED streetlights, with a bright white light that’s generally superior in every way. Unless, of course, things go wrong and the lights start to mysteriously change colors.

If you’ve noticed this trend in your area, relax; [NanoPalomaki] has an in-depth and surprisingly interesting analysis of why LED streetlights are changing colors. After examining a few streetlights removed from service thanks to changing from white to purple, he discovered a simple explanation. White LEDs aren’t emitting white light directly; rather, the white light comes from phosphors coating the underlying LED, which emits a deep blue light. The defunct units all showed signs of phosphor degradation. In some cases, the phosphors seemed discolored, as if they experienced overheating or chemical changes. In other LEDs the phosphor layer was physically separated from the backing, exposing the underlying LEDs completely. The color of these damaged modules was significantly shifted toward the blue end of the spectrum, which was obviously why they were removed from service.

Now, a discolored LED here and there does not exactly constitute a streetlight emergency, but it’s happening to enough cities that people are starting to take notice. The obvious solution would be for municipalities to replace the dodgy units Even in the unlikely event that a city would get some compensation from the manufacturer, this seems like an expensive proposition. Luckily, [NanoPalomaki] tested a solution: he mixed a wideband phosphor into a UV-curable resin and painted it onto the lens of each defective LED in the fixture. Two coats seemed to do the trick.

We have to admit that we have a hard time visualizing a city employee painstakingly painting LEDs when swapping out a fixture would take an electrician a few minutes, but at least it’s an option. And, it’s something for hobbyists and homeowners faced with the problem of wonky white LEDs to keep in mind too.

Continue reading “Fail Of The Week: The Case Of The Curiously Colored Streetlights” →

FLOSS Weekly Episode 804: The AI Alliance — Asimov Was Right

October 9, 2024 by Jonathan Bennett 1 Comment

This week Jonathan Bennett and and Dan Lynch chat with Anthony Annunziata about Open Source AI and the AI Alliance. We get answers to our burning AI questions, and talk about the difficulty of defining what Open Source means for these large models.

Continue reading “FLOSS Weekly Episode 804: The AI Alliance — Asimov Was Right” →

3D Printering: Listen To Klipper

October 8, 2024 by Al Williams 10 Comments

I recently wrote about using Klipper to drive my 3D printers, and one natural question is: Why use Klipper instead of Marlin? To some degree that’s like asking why write in one programming language instead of another. However, Klipper does offer some opportunities to extend the environment more easily. Klipper runs on a Linux host, so you can do all of the normal Linux things.

What if you wanted to create a custom G-code that would play a wave file on a speaker? That would let you have custom sounds for starting a print, aborting a print, or even finishing a print.

If you recall, I mentioned that the Klipper system is really two parts. Well, actually more than two parts, but two important parts at the core. Klipper is, technically, just the small software stub that runs on your 3D printer. It does almost nothing. The real work is in Klippy, which is mostly Python software that runs on a host computer like a Raspberry Pi or, in my case, an old laptop.

Because it is Python and quite modular, it is very simple to write your own extensions without having to major surgery or even fork Klipper. At least in theory. Most of the time, you wind up just writing G-code macros. That’s fine, but there are some limitations. This time, I’m going to show you how easy it can be using the sound player as an example.

Macros All the Way Down

Normally, you think of gcode as something like: G1 X50 Y50. Some of the newer codes don’t start with G, but they look similar. But with Klipper, G1, M205, and MeltdownExtruder are all legitimate tokens that could be “G-code.”

For example, suppose you wanted to implement a new command called G_PURGE to create a purge line (case doesn’t matter, by the way). That’s easy. You just need to put in your configuration file:

[gcode_macro g_purge]
gcode:
# do your purge code here

The only restriction is that numbers have to occur at the end of the name, if at all. You can create a macro called “Hackaday2024,” but you can’t create one called “Hackaday2024_Test.” At least, the documentation says so. We haven’t tried it.

There’s more to macros. You can add descriptions, for example. You can also override an existing macro and even call it from within your new macro. Suppose you want to do something special before and after a G28 homing command:

[gcode_macro g28]
description: Macro to do homing (no arguments)
rename_existing: g28_original
gcode:
M117 Homing...
g28_original
M117 Home done....

Continue reading “3D Printering: Listen To Klipper” →

Hack On Self: The Alt-Tab Annihilator

October 7, 2024 by Arya Voronova 43 Comments

Last time, I told you about a simple script I made to collect data about my laptop activity, talked about why collecting data about yourself is a moral imperative, and shared the upgraded script with you alongside my plans for it. Today, I will show you a problem I’ve been tackling, with help of this script and the data it gives, and I also would love to hear your advice on a particular high-level problem I’m facing.

Today’s problem is as old as time – I often can’t focus on tasks I badly need done, even ones I want done for myself. This has been a consistent problem in my life, closing off opportunities, getting me to inadvertently betray my friends and family, hurting my health and well-being, reinforcing a certain sort of learned helplessness, and likely reinforcing itself as it goes, too.

It’s deeply disturbing to sit down fully intending to work on a project, then notice no progress on it hours later, and come to a gut-wrenching realization you’ve had hundreds of such days before – I think this screws with you, on a fundamental level. Over the years, I’ve been squeezing out lessons from this failure mode, making observations, trying out all sorts of advice, in search of a solution.

Join me today in non-invasive brain augmentation and reprogramming, as I continue trying to turn my life around – this time, with help of my laptop, a computer that I already spend a ton of time interfacing with. Ever notice that starting work on a task is often the hardest part of it? It’s the same for me, and I decided to hack away at it.

Staying On Track

Continue reading “Hack On Self: The Alt-Tab Annihilator” →

Hackaday Links: October 6, 2024

October 6, 2024 by Dan Maloney 22 Comments

Remember that time a giant cylindrical aquarium in a Berlin hotel bar catastrophically failed and left thousands of fish homeless? We sure do, and further recall that at the time, we were very curious about the engineering details of how this structure failed so spectacularly. At the time, we were sure there’d be plenty of follow-up on that score, but life happened and we forgot all about the story. Luckily, a faithful reader named Craig didn’t, and he helpfully ran down a few follow-up articles that came out last year that are worth looking at.

The first is from prosecutors in Berlin with a report offering three possibilities: that the adhesive holding together the acrylic panels of the aquarium failed; that the base of the tank was dented during recent refurbishment; or that the aquarium was refilled too soon after the repairs, leading to the acrylic panels drying out. We’re a little confused by that last one just from an intuitive standpoint, but each of these possibilities seems hand-wavy enough that the report’s executive summary could have been “Meh, Scheiße happens.”

Continue reading “Hackaday Links: October 6, 2024” →

Where Is The End Of DIY?

October 5, 2024 by Elliot Williams 72 Comments

Al and I were talking on the podcast about Dan Maloney’s recent piece on how lead and silver are refined and about the possibility of anyone fully understanding a modern cellphone. This lead to Al wondering at the complexity of the constructed world in which we live: If you think hard enough about anything around you right now, you’d probably be able to recreate about 0% of it again from first principles.

Smelting lead and building a cellphone are two sides of coin, in my mind. The process of getting lead out of galena is simple enough to comprehend, but it’s messy and dangerous in practice. Cellphones, on the other hand, are so monumentally complex that I’d wager that no single person could even describe all of the parts in sufficient detail to reproduce them. That’s why they’re made by companies with hundreds of engineers and decades of experience with the tech – the only way to build a cellphone is to split the complicated task into many subsystems.

Smelting lead is a bad DIY project because it’s simple in principle, but prohibitive in practice. Building a cellphone from the ground up is incomprehensible in principle, but ironically entirely doable in practice if you’re willing to buy into some abstractions.

Indeed, last week we saw a nearly completely open-source build of a simple smartphone, and the secret to making it work is knowing the limits of DIY. The cell modem, for instance, is a black box. It’s an abstract device that you can feed data to and read data from, and it handles the radio parts of the phone that would take forever to design from scratch. But you don’t need to understand its inner workings to use it. Knowing where the limits of DIY are in your project, where you’re willing to accept the abstraction and move on, can be critical to getting it done.

Of course, in an ideal world, you’d want the cell modem to be like smelting lead – something that’s possible to understand in principle but just not worth DIYing in practice. And of course, there are some folks out there who hack on cell modem firmware and others who could do the radio engineering. But despite my strong DIY urges, I’d have to admit that the essential complexity of the module simply makes it worth treating as a black box. It’s very probably the practical limit of DIY.