37C3: You Think It’s Bad With Pluto? A History Of The Planets

Not every talk at the Chaos Communication Congress is about hacking computers. In this outstanding and educational talk, [Michael Büker] walks us through the history of our understanding of the planets.

The question “What is a planet?” is probably more about the astronomers doing the looking than the celestial bodies that they’re looking for. In the earliest days, the Sun and the Moon were counted in. They got kicked out soon, but then when we started being able to see asteroids, Ceres, Vesta, and Juno made the list. But by counting all the asteroids, the number got up above 1,200, and it got all too crazy.

Viewed in this longer context, the previously modern idea of having nine planets, which came about in the 1960s and lasted only until 2006, was a blip on the screen. And if you are still a Pluto-is-a-planet holdout, like we were, [Michael]’s argument that counting all the Trans-Neptunian Objects would lead to madness is pretty convincing. It sure would make it harder to build an orrery.

His conclusion is simple and straightforward and has the ring of truth: the solar system is full of bodies, and some are large, and some are small. Some are in regular orbits, and some are not. Which we call “planets” and which we don’t is really about our perception of them and trying to fit this multiplicity into simple classification schemas. What’s in a name, anyway?

Don’t Give Up

I’m at Chaos Communication Congress this weekend, and it’s like being surrounded by the brightest, most creative, and being honest, nerdiest crowd imaginable. And that’s super invigorating.

But because of the pandemic, this is the first in-person conference in four years, and it’s been a rather unsettling time in-between. There are tons of unknowns and issues confronting us all, geeks or otherwise, at the moment. I know some people who have fallen prey to this general malaise, and become more or less cynical.

Especially in this context, watching a talk about an absolutely bravado hack, or falling into a conversation that sparks new ideas, can be inspiring in just the right way to pull one out of the slump. Every talk is naturally a success story — of course they are, otherwise they wouldn’t be up there presenting.

But all of the smaller interactions, the hey-why-didn’t-I-think-of-that moments or the people helping each other out with just the right trick, that give me the most hope. That’s because they are all around, and I’m sure that what I’m seeing is just the tip of the iceberg. So stick together, nerds, share your work, and don’t give up!

Hackaday Podcast Episode 250: Trains, RC Planes, And EEPROMS In Flames

This week in the Podcast, Elliot Williams is off at Chaos Communication Congress, hearing tales of incredible reverse engineering that got locomotives back up and running, while Al Williams is thinking over what happened in 2023. There’s a lot of “how things work” in this show, from data buoys to sewing machines to the simulated aging of ICs.

Whether you’re into stacking bricks, stacking Pi Picos, or stacking your 3D prints to make better use of precious bed space, this episode is for you. Enjoy.

This is your last chance to download a new podcast this year. Take it!

Continue reading “Hackaday Podcast Episode 250: Trains, RC Planes, And EEPROMS In Flames”

Unbricking Trains, Uncovering Shady Behavior

The first clue was that a number of locomotives started malfunctioning with exactly 1,000,000 km on the odometer. And when the company with the contract for servicing them couldn’t figure out why, they typed “Polish hackers” into a search engine, and found our heroes [Redford], [q3k], and [MrTick]. What follows is a story of industrial skullduggery, CAN bus sniffing, obscure reverse engineering, and heavy rolling stock, and a fantastically entertaining talk.

Cutting straight to the punchline, the manufacturer of the engines in question apparently also makes a lot of money on the service contracts, and included logic bombs in the firmware that would ensure that revenue stream while thwarting independent repair shops. They also included “cheat codes” that simply unlocked the conditions, which the Polish hackers uncovered as well. Perhaps the most blatant evidence of malfeasance, though, was that there were actually checks in some versions of the firmware that geofenced out the competitors’ repair shops.

We shouldn’t spoil too much more of the talk, and there’s active investigation and legal action pending, but the smoking guns are incredibly smoky. The theme of this year’s Chaos Communication Congress is “Unlocked”, and you couldn’t ask for a better demonstration of why it’s absolutely in the public interest that hackers gotta hack. Of course, [Daniel Lange] and [Felix Domke]’s reverse engineering of the VW Dieselgate ECU shenanigans, another all-time favorite, also comes to mind.

Hardware: It’s Made Of Software!

We had the opportunity to add a new feature to our lineup: the FLOSS Weekly podcast. It’s a very long running series that covers the goings on in the free, libre, and open-source software world. It’s been co-hosted by our own [Jonathan Bennett] for quite a while now, and when This Week in Tech announced that they wanted to cancel it, [Jonathan] asked if he could keep it running over here at Hackaday.

Hackaday is hardware, though. Why would we be hosting a podcast on open software? It’s no secret that a bunch of us are open-source software fans in general here at Hackaday, but take a quick inventory of the various open projects that you use to make and hack your hardware. We use open-source compilers, libraries, and flashing tools to handle the firmware we write on open-source text editors. Heck, half of the time we even program microcontrollers in the open-source MicroPython. We design PCBs in the open-source KiCAD, do CAD/CAM in FreeCAD, and don’t even get me started in the open-source software and firmware underlying the entire 3D printing ecology. Reverse engineering? Free software, from Wireshark straight through to Ghidra.

All of this is to say, that even while we’re making or breaking hardware, we’re using open-source software to do it. So, if you’re interested in peeking behind the curtain, give the FLOSS Weekly a listen.

You Can’t Make What You Can’t Measure

What’s the most-used tool on your bench? For me, it’s probably a multimeter, although that’s maybe a tie with my oscilloscope. Maybe after that, the soldering iron and wire strippers, or my favorite forceps. Calipers must rate in there somewhere too, but maybe a little further down. Still, the top place, and half of my desert-island top-10, go to measuring gear.

That’s because any debugging, investigation, or experimentation always starts with getting some visibility on the problem. And the less visible the physical quantity, the more necessary to tool. For circuits, that means figuring out where all the voltages lie, and you obviously can’t just guess there. A couple months ago, I was doing some epoxy and fiberglass work, and needed to draw a 1/2 atmosphere vacuum. That’s not the kind of quantity you can just eyeball. You need the right measurement tool.

A few weeks ago, I wrote about my disappointment in receiving a fan that wouldn’t push my coffee beans around in the homemade roaster. How could I have avoided this debacle? By figuring out the pressure differential needed and buying a fan that’s appropriately rated. But I lacked pressure and flow meters.

Now that I think about it, I could have scavenged the pressure meter from the fiberglassing rig, and given that a go, but with the cheap cost of sensors and amplifiers, I’ll probably just purpose-build something. I’m still not sure how I’ll measure the flow; maybe I’ll just cheese out and buy a cheap wind-speed meter.

When people think of tools, they mostly think of the “doers”: the wrenches and the hammers of this world. But today, let’s all raise a calibrated 350 ml glass to the “measurers”. Without you, we’d be wandering around in the dark.

Degrees Of Freedom, But For Whom?

Opening up this week’s podcast, I told Kristina about my saga repairing our German toilet valve. I’m American, and although I’ve lived here over a decade, it’s still surprising how things can be subtly different from how they worked back home.

But what was amazing about this device was that it had a provision for fine adjustment, and to some extent relied on this adjustment to function. Short version: a lever mechanism provides mechanical advantage to push a stopper against the end of a pipe to block the water flow, and getting the throw of this mechanism properly adjusted so that the floater put maximum pressure against the pipe required fine-tuning with a screw. But it also required understanding the entire mechanism to adjust it.

Which makes me wonder how many plumbers out there actually take the time to get that right. Are there explicit instructions in the manual? Does every German plumber learn this in school? I was entirely happy to have found the adjustment screw after I spent 15 minutes trying to understand the mechanism, because it did just the trick. But is this everyone’s experience?

I often think about this when writing code, or making projects that other people are likely to use. Who is the audience? Is it people who are willing to take the time to understand the system? Then you can offer them a screw to turn, and they’ll appreciate it. But if it’s an audience that just doesn’t want to be bothered, the extra complexity is just as likely to cause confusion and frustration.