2026 Hackaday Supercon: All The Speakers!

We announced our first round of speakers, and then the workshops, and we were going to dribble out updates on the rest of the speakers as they came in, but then time slipped away from us. So we are left here announcing a veritable cornucopia of twenty wonderful talks that you absolutely won’t want to miss.

Supercon is just about a week away, and there are still a few tickets left, so grab them now before it’s too late.

And the talks are just half the fun. Between food, merriment, a killer badge with the biggest e-paper display that you’ve ever seen, and all the assorted shenanigans, it’s the highlight of our hacking year. Come join us!

Continue reading “2026 Hackaday Supercon: All The Speakers!” →

Making For Others

One of the nicest things about the Hackaday community, and the open-source hardware community at large, is the incredible generosity of one hacker to another. But it’s not purely altruism – it’s also just a great feeling to be able to share your work with other folks who understand what it represents and how to use it.

I’m looking at my workbench right now. Because I’ve been testing out the Supercon badge prototype, there is a small pile of SAOs to the right. SAOs are the perfect size for giving out to fellow hackers, because they can be small, inexpensive, and yet still embody a ton of your creativity. [Tom]’s marvelous Ode to the SAO, even opens with this as one of the main benefits, alongside teaching you “full-stack” PCB production at small scale; they are cheap enough that you can give them away. Of course, you end up getting as many or more than you give, so it’s not just the pure joy of giving at work in the SAO scene.

On my left, I have a couple dev boards made by fellow hackers. One is a clone of the Raspberry Pi Pico that’s made by the high-school students of Hack Club, and the other is [CNLohr]’s ch32v003fun board and esp32s2-funprog programmer. I needed to test out a quick microcontroller application, and having a few dev boards on hand is always useful. Because I know the people who made these boards, I tend to reach for these over their commercial alternatives. Romantic? Maybe. But they were given to me by friends.

And of course the badge prototype is sitting in the middle of all this, and that’s how I really know about the joy of giving away your designs to fellow hackers. We at Hackaday are in the incredibly fortunate position of being able to dream up a new and fun badge every year, and give it out to hundreds of fellow hackers. Heck, this year, we’re making 1,000. I say “fortunate” because we don’t have to pay for them ourselves, but rather our Supercon sponsors help pick up the bill, and that means we can make stuff that’s far cooler than our budgets would otherwise allow.

So to everyone in the SAO scene, may you give away your designs to people who really appreciate them. For the folks who have built tools for other hackers to use, you should know that the recipients probably reach for your boards over their bland commercial alternatives. And for all of you coming to Supercon in two weeks, we hope you dig the badge. It has maybe become a bit of a cliché these days, but you should know that it’s made with love.

Discovering SDRs Everywhere

To quote commenter [douyarou], “It’s like our little version of a Precambrian explosion”. A bunch of hackers have discovered, independently and building on each other’s work, software-defined radio (SDR) capabilities in more places than you can shake a stick at.

It all started with [Espargos] and [h0m3us3r] apparently independently discovering that the ESP32 family of chips had a “secret” debug mode that allowed direct access to the radio that’s normally used for WiFi. While the 2.4 GHz radio signal is almost always immediately converted into data by the MAC hardware, here they found a way to listen in upstream, to the raw IQ data.

Seeing this, folks were immediately inspired to find out if they could transmit as well. [marble] not only got transmit functionality working, but integrated the part in with the standard osmosdr data flow, which meant that a whole bunch of existing tools were ready to go. We didn’t know about it at the time, but apparently [jochenhammes] and [z1000biker] concurrently had their TX-capable hacks up and running: here and here.

At this point, folks have already started to use the capabilities for broadcasting digital TV signals, voice signals, FM Hell, and other hijinks. This reminds us of the early days of the RTL-SDR project, when a competent, if receive-only, SDR functionality was found in a bunch of USB TV-tuner dongles. Once the hardware capabilities were sussed out, people started writing all sorts of useful software, and it gave rise to all manner of radio projects, from simply poking at domestic wireless devices to tracking all the airplanes in the world as they fly by.

[Tom] and I were discussing this on the podcast, and he remarked that of course there are SDRs hidden everywhere there is a radio unit these days, and the question is just whether or not we could hack them into usability. And before the podcast was even finally edited, [Samson1te] told us about his find in the LR2021 LoRa chip. This is a radio that’s designed to be a radio, with 16-bit resolution, and covering lower frequencies from 150 MHz to 960 MHz.

Compared to the RTL-SDR revolution, this is all happening at incredible speed. Each of these hacks will enable us to use different slices of radio spectrum with different degrees of ease, but it’s clear that the cost of entry into playing around with digital radio has just dropped precipitously. We will see hundreds of new signals hacks in the next few months – the floodgates have been opened.

2026 Hackaday Supercon: Workshops Are Open!

Supercon is Hackaday’s annual gathering, and you absolutely need to be there.

Today, we’re pleased to announce our lineup of workshops, and it’s more than we’ve ever offered, thanks to moving to a bigger venue and to our awesome community of hackers stepping up to give them. There’s something here for everyone, so if anything strikes your fancy, be sure to book yourself a slot soon. (If you have a ticket already, you sign up for the workshop as an “add-on”, BTW.) Workshops always fill up fast, due to the small and hands-on nature of the beast.

Continue reading “2026 Hackaday Supercon: Workshops Are Open!” →

ESP-SDR Can Now Transmit

Well, that was fast! Last week, we reported on two apparently simultaneous hacks using the 2.4 GHz radio inside many ESP32 variants that enabled raw access to the radio samples, turning it into a listen-only software defined radio (SDR) platform. Listen only? That’s only half of the SDR story.

Last weekend, [marble] got started fixing that, and released an early version of ESP32 firmware that can also transmit, and got receive working with gqrx. The demo communicates between an S3 and a C6 using a Hellschreiber mode, something that’s certainly out of the WiFi spec. And it didn’t stop there, either. [marble] is working on 802.15.4 modulation at the moment, which means that maybe soon your ESP32 will speak ZigBee.

This is all in the roughly 2.4 GHz band, but [marble] suggests that it might be good down to 1.8 GHz. (Editor’s note: previously, we said 100 MHz, but that was incorrect.) So there is still some uncharted terrain, and it’s clear that the boundaries on the ESP-SDR are just starting to get pushed.

If the early hacks on the RTL-SDR set off a wave of hacker SDR radio experimentation, and we can only hope that this is the beginning of the ESP-SDR era. Thanks then to [marble]– and the original hacks coming from the Espargos team for kicking this all off!

The Weirdest Video Games Were Hacks

We were looking into the marvelous recent project by [Throaty Mumbo] to recreate and reimagine the forgotten world of VHS-tape-based video games. Wait, what? Yes, back in the day, when computer graphics were more primitive, there were attempts to mix the gameplay of video games with the graphics from a video cassette. Take the Action Max system. It worked with a light-gun that pointed at the screen while the video played, and you tried to shoot at things as they flew by. Think Duck Hunt, but in glorious VHS video quality with cheesy acting, and the same gameplay loop every time, because it’s on the tape.

The unreleased Control-Vision VHS gaming system, co-developed with none other than Steve Wozniak, took the idea a little further and ran simultaneous sub-videos, and your actions would choose which of the sub-tracks would play at any given time. This let them do things like switch between videos depending on whether you caught the bad guys or missed them entirely, for instance.

These games came in the late 1980s, though, and they were all derivatives of the seminal Dragon’s Lair, which is probably the least fun video game I’ve ever had the chance to play, but among the most entertaining in a weird way. Instead of a linear VHS tape, Dragon’s Lair, and the later but equally unplayable Space Ace, were based on the then-new video disc technology that could swap between entirely different tracks almost seamlessly.

“Almost” is the key word here, though. Although the animations were absolutely marvelously cartoony, and looked stunning in an arcade up against video games of the time, there was a significant fraction of a second of delay between commanding an action with the joystick and the machine swapping up to the correct track. There were a couple of sections where back-to-back actions were necessary, and the challenge was to work around the game’s exact track-swapping-glitch time. As good as they looked, the gameplay was no fun.

But the game was influential, as evidenced by its VHS-based clones. If you’d like to give it a try, you’ll not be surprised to hear that there’s an emulator for Dragon’s Lair and its spin-off games.

What do all of these have to do with each other? We love how these games took a current technology – in this case video discs or video tapes – and tried to make it do something else: These games were all hacks. If you look at them in that light, maybe you can look past the horrible acting in Night Trap or the frustrating glitches in Dragon’s Lair. (Or maybe not. Give me Robotron: 2084 any day.)

The Least Annoying Of All Evils

If you missed the hubbub this week, it was discovered that the Raspberry Pi Foundation added code in the firmware that locks the boot process up if non-original RAM chips are detected onboard. Hot-rodding your Pi is a time-honored tradition in these parts. We do wonder just how many folks are taking the risk of hot-airing the memory off the board, versus paying the extra cash to get one with more RAM. But according to Raspberry Pi, enough boards are showing up that have the RAM surreptitiously replaced, and often defective, that they took the step to lock the machine down.

Should users be alerted to potentially unscrupulous behavior by the companies selling them single-board computers? I think we’d all say “sure”. But should that entirely brick the device? And prevent people from upgrading their own? The hacker in me says “no”. Is there any way to reconcile these two? Our own [Arya Voronova] suggests that it’s no big deal to flash an older version of the initial firmware, and we concur, although it does leave behind all the improvements since 2023, and it will only get less fresh as time goes by.

How to announce that the board has non-factory memory without breaking it? [Jeff Geerling] suggested a non-matching-memory bit that users could check, but then they could also neglect to check. My cellphone has a screen that appears every bootup, and requires me to press the power button to continue, because I rooted the phone and installed an open-source OS. It’s a hassle for sure, but it’s a lot better than bricking the phone or disallowing user firmware entirely.

Doing the same thing for the Raspberry Pi isn’t as easy. You never know what, if any, peripherals are connected, so you can’t guarantee that there’s a screen to alert you or even necessarily a keyboard on which you could acknowledge. We’re reminded of a similar situation with FTDI USB-to-serial converter chips ages ago. Their driver software simply refused to work with counterfeit versions of their chips. Hackers were up in arms, largely because we couldn’t know if the parts were genuine at purchase time, and the counterfeits were widely distributed even by reliable resellers.

So what about it? Can you think up a tamper-evident signal that could run on boot on a Raspberry Pi, maybe a headless system installed in some difficult-to-reach place? Maybe ideally the equivalent of the cell phone’s scare message? It would have to be hard to overlook, but keep the machine running, notifying the user that things aren’t kosher, but not preventing them from getting to work. Sounds like a tall order to us.