All the components of the Piggymeter interface laid out on a silicon mat

Simple Optical Meter Sets New Standards For Documentation

March 9, 2024 by Arya Voronova 6 Comments

PiggyMeter is a wonderful example of a device that you never knew you needed – simple, elegant, easy to build, and accompanied by amazing documentation. It’s a snap-on interface for electric meters, dubbed so because its 3D printable shell looks like a pig nose, and it works with IEC62056-21 compliant meters. If you want to learn about your home’s power consumption in real time and your meter happens to fit the bill, look into building a PiggyMeter, it’s the kind of DIY project that a hacker was destined to design at some point.

All you need is a printed shell, a Wemos-compatible development board with an ESP32 MCU, an optical interface board, and a few small parts like a ring magnet. The optical interface board is not open source, but there’s drawings available, and the design is pretty simple, so it should be trivial to recreate. Plus, it’s also reasonably inexpensive if you don’t want to build your own board. Got parts? Simply put them all together, flash the firmware, and you have a meter adapter added to your smart home device family.

This device works with HomeAssistant, and it’s incredibly easy to set up, in part because of just how clearly everything is outlined in the blog post. Seriously, the documentation is written with love, and it shows. If you’re looking to learn how to document a device in a helpful way, take notes from the PiggyMeter. And, if you’d like to learn more about optically coupled power meter interfaces, here’s a different open source project we’ve covered before!

Hackaday Podcast 178: The Return Of Supercon, Victory For Open Source, Exquisite Timepieces, And Documentation To Die For

July 22, 2022 by Tom Nardi 2 Comments

Hackaday Editor-in-Chief Elliot Williams and Managing Editor Tom Nardi start this week’s podcast off with an announcement the community has been waiting years for: the return of the Hackaday Supercon! While there’s still some logistical details to hammer out, we’re all extremely excited to return to a live con and can’t wait to share more as we get closer to November. Of course you can’t have Supercon without the Hackaday Prize, which just so happens to be wrapping up its Hack it Back challenge this weekend.

In other news, we’ll talk about the developing situation regarding the GPLv3 firmware running on Ortur’s laser engravers (don’t worry, it’s good news for a change), and a particularly impressive fix that kept a high-end industrial 3D printer out of the scrapheap. We’ll also fawn over a pair of fantastically documented projects, learn about the fascinating origins of the lowly fire hydrant, and speculate wildly about the tidal wave of dead solar panels looming menacingly in the distance.

Or download the fresh bitstream yourself.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Continue reading “Hackaday Podcast 178: The Return Of Supercon, Victory For Open Source, Exquisite Timepieces, And Documentation To Die For” →

Modular Laptop Maker Provides Mainboard Documentation For Non-Laptop Projects

April 21, 2022 by Ryan Flowers 27 Comments

If you’ve been following the latest advancements in computing for a while, you already know that there’s a big problem with laptops: When they’re no longer useful as a daily driver, it can be a struggle to find a good use for all its parts. Everything is proprietary, and serious amounts of reverse engineering are required if you decide to forge ahead. This is where Framework, a laptop company building modular laptops comes in. They’ve made it clear that when you upgrade your Framework laptop with a new mainboard they want you to be able to continue to use the old mainboard outside of the laptop.

When it's done powering your laptop, use it for a cyberdeck? — When it’s done powering your laptop, use it for a cyberdeck?

To that end, Framework have provided 2D mechanical drawings of their mainboard and 3D printable cases that can of course be modified as needed. “But what about peripherals?” you might ask. Framework has provided pinouts for all of the connectors on the board along with information on which connectors to use to interface with them. No reverse engineering needed!

While it’s possible to buy a mainboard now and use it, their stated goal is to help people make use of used mainboards leftover from upgrades down the line. With just a stick of memory and a USB-C power adapter, the board will spring to life and even has i2c and USB immediately available.

What would you do with a powerful Intel i5-1135G7 mainboard? Framework wants to know, and to that end, they are actually giving away 100 mainboards to makers and developers. Mind you this is a program created and ran by Framework — and is not associated in any way Hackaday or our overlords at Supplyframe.

If you’ve read this far and still don’t know what the Framework laptop is, go check out this introduction by our own [Jenny List].

Threeboard: Short On Keys, Long On Documentation

January 18, 2022 by Matthew Carlson 8 Comments

As peripherals go, few are hacked on more than keyboards. The layouts, the shapes, the sizes, materials, and even the question of what a keyboard is are all on the table for tinkering. In that vein, [TaylorConor] released his simplified keyboard called the threeboard on GitHub, having only three keys and replicating a full keyboard.

We’ve covered keyboards built with chording in mind, wrapped around coffee cups, and keyboards with joysticks for added speed. So why cover this one? What makes it different? The execution is superb and is a great example to look at next time you’re making a project you want to show off. The keyboard is just three mechanical switches, two 8-bit binary displays (16 LEDs total), three status LEDs, and three LEDs showing the current layer (four layers). The detailed user’s manual explains it all. There is a reliable Atmega32U4 microcontroller and two EEPROM chips at its heart.

Where this project shows off is the testing. It has unit tests, simulated integration tests, and simulated property tests. Since all the code is in C++, unit testing is relatively straightforward. The integration and property tests are via a simulator. Rather than recompiling the code with some new flags, he uses the simavr AVR simulator, which means it simulates the same binary file that gets flashed onto the microcontroller. This approach means the design is tested and debugged via GDB. It’s an incredible technique we’d love to see more of in hobby projects. Marketing speak might call this a “digital twin” but the idea is that you have a virtual version that’s easier to work on and has a tighter iteration loop while being as close as possible to the physical version.

[TaylorConor’s] goal was to create a from-scratch microcontroller project with easy-to-read code, fantastic documentation, and best practices. We think he nailed it. So feel free to run the simulator or jump right into building one for yourself. All the hardware is under a CERN-OHL-P license, and the firmware is under GPLv3.

Documentation Is Hard, Let The SkunkWorks Project Show You How To Do It Well

September 12, 2021 by Orlando Hoilett 6 Comments

Documentation can be a bit of a nasty word, but it’s certainly one aspect of our own design process that we all wish we could improve upon. As an award-winning designer, working with some of the best toy companies around, [Jude] knows a thing or two about showing your work. In his SkunkWorks Project, he takes a maker’s approach to Bo Peep’s Skunkmobile and gives us a master class on engineering design in the process.

As with any good project brief, [Jude] first lays out his motivation for his work. He was very surprised that Pixar hadn’t commercialized Bo Peep’s Skunkmobile and hoped his DIY efforts could inspire more inclusive toy options from the Toy Story franchise. He does admit that the Skunkmobile presents a more unique design challenge than your standard, plastic, toy action figure. Combining both the textile element to create the illusion of fur and the RC components to give the toy its mobility requires careful thought. You definitely don’t want the wheels ripping into the fabric as you wheel around the backyard or for the fur to snag every object you pass by in the house.

Given the design challenges of making the Skunkmobile from scratch, [Jude] decided the best way forward was to retrofit a custom-designed skunk-shaped body onto a standard RC car chassis. The difficulty here lies in finding a chassis that can support the weight of the retrofitted body as well as one big enough to hold a 9-inch Bo Peep doll inside the driver’s compartment. Before spending endless hours 3D printing (and re-printing) his designs, [Jude] first modeled the Skunkmobile in card (using cardboard), a practice we’ve seen before, and are always in love with. He continually emphasized the form of his device was probably even more important than its function as capturing the essence as well as the “look and feel” of the Skunkmobile were critical design criteria. You can even see the skunk wagging its tail in all his demo videos. Prototyping in card gave [Jude] a good feel for his Skunkmobile and the designs translated pretty well to the 3D printed versions.

What really impressed us about [Jude’s] project is the incredible detail he provides for his entire design process from his backstory, to the initial prototypes, to the user testing, and, finally, to the realization of the final product. Remember, “We want the gory details!”

Continue reading “Documentation Is Hard, Let The SkunkWorks Project Show You How To Do It Well” →

The Compromises Of Raspberry Pi Hardware Documentation

June 23, 2021 by Maya Posch 86 Comments

[Rowan Patterson] informed us about a recent ticket he opened over at the Raspberry Pi Documentation GitHub repository. He asked about the the lack of updates to the Raspberry Pi 4’s USB-C power schematics for this board. You may recall that the USB-C power issue was covered by us back in July of 2019, yet the current official Raspberry Pi 4 schematics still show the flawed implementation, with the shorted CC pins, nearly two years later.

[Alasdair Allan], responsible for the Raspberry Pi documentation, mentioned that they’re in the process of moving their documentation from Markdown to AsciiDoc, and said that they wouldn’t have time for new changes until that was done. But then [James Hughes], Principal Software Engineer at Raspberry Pi, mentioned that the schematics may not be updated even after this change due to a of lack of manpower.

As [James] emphasized, their hardware will probably never be open, due to NDAs signed with Broadcom. The compromise solution has always been to publish limited peripheral schematics. Yet now even those limited schematics may not keep up with board revisions.

An easy fix for the Raspberry Pi 4’s schematics would be for someone in the community to reverse-engineer the exact changes made to the Raspberry Pi 4 board layout and mark these up in a revised schematic. This should be little more than the addition of a second 5.1 kΩ resistor, so that CC1 and CC2 each are connected to ground via their own resistor, instead of being shorted together.

Still, you might wish that Raspberry Pi would update the schematics for you, especially since they have updated versions internally. But the NDAs force them to duplicate their efforts, and at least right now that means that their public schematics do not reflect the reality of their hardware.

This Week In Security: SAD DNS, Incident Documentation Done Well, And TCL Responds

November 20, 2020 by Jonathan Bennett 6 Comments

One of the big stories from the past few days is the return of DNS cache poisoning. The new attack has been dubbed SADDNS, and the full PDF whitepaper is now available. When you lookup a website’s IP address in a poisoned cache, you get the wrong IP address.

This can send you somewhere malicious, or worse. The paper points out that DNS has suffered a sort of feature creep, picking up more and more responsibilities. The most notable use of DNS that comes to mind is LetsEncrypt using DNS as the mechanism to prove domain ownership, and issue HTTPS certificates.

DNS Cache poisoning is a relatively old attack, dating from 1993. The first iteration of the attack was simple. An attacker that controlled an authoritative DNS server could include extra DNS results, and those extra results would be cached as if they came from an authoritative server. In 1997 it was realized that the known source port combined with a non-random transaction ID made DNS packet spoofing rather trivial. An attacker simply needs to spoof a DNS response with the appropriate txID, at the appropriate time to trick a requester into thinking it’s valid. Without the extra protections of TCP connections, this was an easy task. The response was to randomize the txID in each connection.

I have to take a moment to talk about one of my favorite gotchas in statistics. The Birthday paradox. The chances that two randomly selected people share a birthday is 1 in 365. How many people have to be in a room together to get a 50% chance of two of them sharing a birthday? If you said 182, then you walked into the paradox. The answer is 23. Why? Because we’re not looking for a specific birthday, we’re just looking for a collision between dates. Each non-matching birthday that walks into the room provides another opportunity for the next one to match.

This is the essence of the DNS birthday attack. An attacker would send a large number of DNS requests, and then immediately send a large number of spoofed responses, guessing random txIDs. Because only one collision is needed to get a poisoned cache, the chances of success go up rapidly. The mitigation was to also randomize the DNS source port, so that spoof attempts had to have both the correct source port and txID in the same attempt. Continue reading “This Week In Security: SAD DNS, Incident Documentation Done Well, And TCL Responds” →