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.

Pico-WSPR-tx Does It In Software

What do you need to make a radio transmitter? There are builds that work with just a couple of transistors. But how about a GPS-disciplined small signal beacon? You can actually get the job done for less than the cost of a fancy hamburger, thanks to [RPiks]’s pico-WSPR-tx and the Weak Signal Propagation Reporter Network (WSPR).

WSPR is a digital protocol where a beacon encodes its callsign, location, and transmitting power, and then sends it out to a network of receiving stations worldwide. The idea is to use the data coming from the beacons to determine whether radio propagation conditions are good or not; if you hear a quiet signal from afar, they’re good in that direction. [RPiks]’s beacon design simply includes a Raspberry Pi Pico and a GPS receiver. Everything else is software.

Of course, this means that it’s using the Pico’s GPIO pins for transmission. Maybe you want to add some filtering to take off the rough square-wave edges, and/or maybe you want to boost the power a little bit with an external amplifier. If so, check out our own $50 Ham column’s advice on the topic. But you don’t need to. Just a Pico and a GPS should get you working, if you want to test the WSPR waters.