2025-12-07 11:00:58
USB PD is a fun protocol to explore, but it can be a bit complex to fully implement. It makes sense we’re seeing new stacks pop up all the time, and today’s stack is a cool one as far as code reusability goes. [Vitaly] over on Hackaday.io brings us pdsink – a C++ based PD stack with no platform dependencies, and fully-featured sink capabilities.
This stack can do SPR (5/9/15/20V) just like you’d expect, but it also does PPS without breaking a sweat – perfect for your Lithium Ion battery charging or any other current-limited shenanigans. What’s more, it can do EPR (28V and up) – for all your high-power needs. For reference, the SPR/PPS/EPR combination is all you could need from a PD stack intended for fully taking advantage of any USB-PD charger’s capabilities. The stack is currently tailored to the classic FUSB302, but [Vitaly] says it wouldn’t be hard to add support for a PD PHY chip of your choice.
It’s nice to have a choice in how you want your PD interactions to go – we’ve covered a few stacks before, and each of them has strong and weak sides. Now, if you have the CPU bandwidth, you could go seriously low-tech and talk PD with just a few resistors, transistors, and GPIOs! Need to debug a particular USB-C edge case? Don’t forget a logger.
2025-12-07 08:00:10
[Michael Lynch] recently decided to delve into the world of off-grid, decentralized communications with MeshCore, because being able to communicate wirelessly with others in a way that does not depend on traditional communication infrastructure is pretty compelling. After getting his hands on a variety of hardware and trying things out, he wrote up his thoughts from the perspective of a hardware-curious software developer.
He ends up testing a variety of things: MeshCore firmware installed on a Heltec V3 board (used via an app over Bluetooth), a similar standalone device with antenna and battery built in (SenseCAP T-1000e, left in the header image), and a Lilygo T-Deck+ (right in the header image above). These all use MeshCore, which is built on and reportedly compatible with Meshtastic, a framework we have featured in the past.
The first two devices are essentially MeshCore gateways, to which the user connects over Bluetooth. The T-Deck is a standalone device that resembles a Blackberry, complete with screen and keypad. [Michael] dove into what it was like to get them up and running.
Probably his most significant takeaway was that the whole process of onboarding seemed a lot more difficult and much less clear than it could be. This is an experience many of us can relate to: the fragmented documentation that exists seems written both by and for people who are already intimately familiar with the project in its entirety.
Another thing he learned was that while LoRa is a fantastic technology capable of communicating wirelessly over great distances with low power, those results require good antennas and line of sight. In a typical urban-ish environment, range is going to be much more limited. [Michael] was able to get a maximum range of about five blocks between two devices. Range could be improved by purchasing and installing repeaters or by having more devices online and in range of one another, but that’s where [Michael] drew the line. He felt he had gotten a pretty good idea of the state of things by then, and not being a radio expert, he declined to purchase repeater hardware without any real sense of where he should put them, or what performance gains he could expect by doing so.
Probably the most surprising discovery was that MeshCore is not entirely open source, which seems odd for an off-grid decentralized communications framework. Some parts are open, but the official clients (the mobile apps, web app, and T-Deck firmware) are not. [Michael] found this out when, being primarily a software developer, he took a look at the code to see if there was anything he could do to improve the poor user experience on the T-Deck and found that the firmware was proprietary.
[Michael]’s big takeaway as a hardware-curious software developer is that the concept is great and accessible (hardware is not expensive and there is no licensing requirement for LoRa), but it’s not really there yet in terms of whether it’s practical for someone to buy a few to distribute among friends for use in an emergency. Not without getting into setting up enough repeaters to ensure connectivity, anyway.
2025-12-07 05:00:01
If you’ve got an RTL-SDR compatible receiver, you’ve probably used it for picking up signals from all kinds of weird things. Now, [Jaron McDaniel] has built a tool to integrate many such devices into the world of Home Assistant.
It’s called RTL-HAOS, and it’s intended to act as a bridge. Whatever you can pick up using the RTL_433 tool, you can set up with Home Assistant using RTL-HAOS. If you’re unfamiliar with RTL_433, it’s a multitalented data receiver for picking up all sorts of stuff on a range of bands using RTL-SDR receivers, as well as a range of other hardware. While it’s most closely associated with products that communicate in the 433 MHz band, it can also work with products that talk in 868 MHz, 315 MHz, 345 MHz, and 915 MHz, assuming your hardware supports it. Out of the box, it’s capable of working with everything from keyless entry systems to thermostats, weather stations, and energy monitors. You can even use it to listen to the tire pressure monitors in your Fiat Abarth 124 Spider, if you’re so inclined.
[Jaron’s] tool integrates these devices nicely into Home Assistant, where they’ll appear automatically thanks to MQTT discovery. It also offers nice signal metrics like RSSI and SNR, so you can determine whether a given link is stable. You can even use multiple RTL-SDR dongles if you’re so inclined. If you’re eager to pull some existing environmental sensors into your smart home, this may prove a very easy way to do it.
The cool thing about Home Assistant is that hackers are always working to integrate more gear into the ecosystem. Oftentimes, they’re far faster and more efficient at doing this than big-name corporations. Meanwhile, if you’re working on your own hacks for this popular smart home platform, we’d probably like to know about it. Be sure to hit up the tips line in due time.
2025-12-07 02:00:40
Nothing lasts forever, and that includes the ROMs required to make a retrocomputer run. Even worse, what if you’re rolling your own firmware? Period-appropriate EPROMs and their programmers aren’t always cheap or easy to get a hold of these days. [Kyo-ta04] had that problem, and thanks to them, we now all have a solution: Pico2ROMEmu, a ROM emulator based on, you guessed it, the Raspberry Pi Pico2.
The ROM emulator has been tested at 10MHz with a Z80 processor and 12MHz with an MC68000. An interesting detail here is that rather than use the RP2350’s RISC-V or ARM cores, [kyo-ta04] is doing all the work using the chip’s powerful PIO. PIO means “programmable I/O,” and if you need a primer, check this out. Using PIO means the main core of the microcontroller needn’t be involved — and in this context, a faster ROM emulator.
We’ve seen ROM emulators before, of course — the OneROM comes to mind, which can also use the RP2350 and its PIOs. That project hasn’t been chasing these sorts of speeds as it is focused on older, slower machines. That may change in the newest revision. It’s great to see another contender in this space, though, especially one to serve slightly higher-performance retrocomputers. Code and Gerbers for the Pico2RomeEMU are available on GitHub under an MIT license.
Thanks to [kyo-ta04] for the tip.
2025-12-06 23:00:38
The site is called Hackaday, and has been for 21 years. But it was only for maybe the first half-year that it was literally a hack a day. By the 2010s, we were putting out four or more per day, and in the later 20-teens, we settled into our current cadence of eight hacks per day, plus some original pieces over the top. That’s a lot of hacks per day! (But “Eight-to-Ten-Hacks-a-Day” just isn’t as catchy.)
With that many posts daily, we also tend to reach out to a broader array of interests. Quite simply, not every hack is necessarily going to be just exactly what you are looking for, but we wouldn’t be writing it up if we didn’t think that someone was looking for it. Maybe you don’t like CAN bus hacks, but you’re into biohacking, or retrocomputing. Our broad group of writers helps to make sure that we’ll get you covered sooner or later.
What’s still surprising to me, though, is that a couple of times per week, there is a hack that is actually relevant to a particular project that I’m currently working on. It’s one thing to learn something new every day, and I’d bet that I do, but it’s entirely another to learn something new and relevant.
So I shouldn’t have been shocked when Tom and I were going over the week’s hacks on the podcast, and he picked an investigation of injecting spray foam into 3D prints. I liked that one too, but for me it was just “learn something new”. Tom has been working on an underwater ROV, and it perfectly scratched an itch that he has – how to keep the top of the vehicle more buoyant, while keeping the whole thing waterproof.
That kind of experience is why I’ve been reading Hackaday for 21 years now, and it’s all of our hope that you get some of that too from time to time. There is a lot of “new” on the Internet, and that’s a wonderful thing. But the combination of new and relevant just can’t be beat! So if you’ve got anything you want to hear more about, let us know.
2025-12-06 20:00:51
If you wanted to build an electronic dice, you might grab an Arduino and a nice OLED display to whip up something fancy. You could even choose an ESP32 and have it log your rolls to the cloud. Or, you could follow the lead of [Axiometa] and do it the old-school way.
The build is based around the famous 555 timer IC. It’s paired with a 4017 decade counter IC, which advances every time it receives a clock signal from the 555. With the aid of some simple transistor logic, this lights the corresponding LEDs for the numbers 1 to 6, which are laid out like the face of a typical six-sided die. For an added bit of fun, a tilt sensor is used to trigger the 555 and thus the roll of the dice. A little extra tweak to the circuit ensures the 555 keeps counting just a little while after you stop shaking. This makes the action feel like an actual dice roll.
Schematics are available for the curious. We’d love to see this expanded to emulate a range of other dice—like a D20 version that could blink away on the D&D table. We’ve covered some very exciting technology in that area as well.
