[Jon] wanted to keep track of his home power use, but didn’t want to have to push his data up to some cloud service that’s just going to leave him high and dry in the future. So he went completely DIY.
This simple and sweet build is now in its third revision, and the refinements show. A first prototype was nothing more than an ESP32 with a screen and some current transformer (CT) sensors to read the current flowing in the wires in his breaker box. The next version added a PCB and a color screen, and the most recent version swapped up to eInk and a nice local power supply, all sized to fit a nice clear power box.
What’s really cute about this design is the use of standard phono headphone jacks to plug the CT sensors into, and the overall sweet combination of a local display and interactivity with [Jon]’s ESPHome-based home automation setup. This design isn’t super complicated, but it doesn’t need to be. It has one job, and it does it nicely. What more do you want?
If you’re interested in getting into ESPHome and/or home automation, check out this great ESPHome resource. It’s probably a lot easier than you think, and you can build your system out one module at a time. If you’re like us, once you get started, you’ll find it hard to stop until everything falls under your watchful eyes, if not your control.
Modern processors come with all kinds of power management features, which you don’t typically notice as a user until you start a heavy program and hear the CPU fan spin up. Back in the early 1990s however, power management was largely unheard of, meaning that a CPU with nothing to do would run through an idle loop that dissipated about as much power as a real computing task. [Michal Necasek] noticed this while experimenting with DR-DOS 6.0 in a virtual machine – his laptop fan would start running on full blast whenever he opened the VM. His search for a solution to this annoyance led him down a fascinating journey into the intricacies of DOS power management.
As it turned out, DR-DOS 6.0 does have functionality built in for putting the CPU in power saving mode when it’s idle. This feature is not complete, however: Digital Research required each computer manufacturer to develop an IDLE driver customized to their specific hardware platform in order to enable power management. Sadly, no manufacturer ever bothered to do so, leaving [Michal] with no option other than writing a driver himself. While there was some documentation available, it didn’t include any example code or sufficient detail to write a driver from scratch.
What it did include was a reference to U.S. Patent No. 5,355,501. Normally this sort of information is of interest only to those planning to sell a competing system, but this specific patent happens to include dozens of pages of well-documented but poorly-scanned x86 assembly code, including source code for a basic IDLE86.SYS driver. As [Michal] wasn’t looking forward to chasing bugs caused by OCR errors, he simply copied the source code by hand, then ran it through an assembler. The end result was a working IDLE driver, which is now available for download from his website.
[Michal]’s blog post also includes lots of details on early power saving implementations, including all the DOS interrupt calls involved in the process. Patents might seem boring in contrast, but they sometimes contain surprising amounts of usable information. You might find enough details to reverse-engineer a wireless protocol, or even to help track down an obscure instrument’s original designer.
Handcrafted gifts are special, and this one’s no exception. [John Pender] made a Tolkien-inspired box for his son and shared the details with us on Hackaday.io. This one-of-a-kind handcrafted box fulfills one role and does it perfectly – just like with the Doors of Durin, you have to say ‘friend’ in Elvish, and the box shall unlock for you.
This box, carefully engraved and with attention paid to its surface finish, stands on its own as a gift. However, with the voice recognition function, it’s a project complicated enough to cover quite a few fields at once – woodworking, electronics, and software. The electronics are laid out in CNC-machined channels, and LED strips illuminate the “Say Friend And Come In” inscriptions once the box is ready to listen. If you’re wondering how the unlocking process works, the video embedded below shows it all.
Two solenoids keep the lid locked, and in its center is a Pi Zero, the brains of the operation. With small batteries and a power-hungry board, power management is a bit intricate. Two capacitive sensors and a small power management device are always powered up. When both of the sensors are touched, a power switch module from Pololu wakes the Pi up. It, in turn, takes its sweet time, as fully-fledged Linux boards do, and lights up the LED strip once it’s listening.
Another week, another exploit against an air-gapped computer. And this time, the attack is particularly clever and pernicious: turning a GPU into a radio transmitter.
The first part of [Mikhail Davidov] and [Baron Oldenburg]’s article is a review of some of the basics of exploring the RF emissions of computers using software-defined radio (SDR) dongles. Most readers can safely skip ahead a bit to section 9, which gets into the process they used to sniff for potentially compromising RF leaks from an air-gapped test computer. After finding a few weak signals in the gigahertz range and dismissing them as attack vectors due to their limited penetration potential, they settled in on the GPU card, a Radeon Pro WX3100, and specifically on the power management features of its ATI chipset.
With a GPU benchmarking program running, they switched the graphics card shader clock between its two lowest power settings, which produced a strong signal on the SDR waterfall at 428 MHz. They were able to receive this signal up to 50 feet (15 meters) away, perhaps to the annoyance of nearby hams as this is plunk in the middle of the 70-cm band. This is theoretically enough to exfiltrate data, but at a painfully low bitrate. So they improved the exploit by forcing the CPU driver to vary the shader clock frequency in one megahertz steps, allowing them to implement higher throughput encoding schemes. You can hear the change in signal caused by different graphics being displayed in the video below; one doesn’t need much imagination to see how malware could leverage this to exfiltrate pretty much anything on the computer.
On the 3rd of June 2019, a 1U CubeSat developed by students of the AGH University of Science and Technology in Kraków was released from the International Space Station. Within a few hours it was clear something was wrong, and by July 30th, the satellite was barely functional. A number of problems contributed to the gradual degradation of the KRAKsat spacecraft, which the team has thoroughly documented in a recently released paper.
We all know, at least in a general sense, that building and operating a spacecraft is an exceptionally difficult task on a technical level. But reading through the 20-pages of “KRAKsat Lessons Learned” gives you practical examples of just how many things can go wrong.
KRAKsat being released from the ISS
It all started with a steadily decreasing battery voltage. The voltage was dropping slowly enough that the team knew the solar panels were doing something, but unfortunately the KRAKsat didn’t have a way of reporting their output. This made it difficult to diagnose the energy deficit, but the team believes the issue may have been that the tumbling of the spacecraft meant the panels weren’t exposed to the amount of direct sunlight they had anticipated.
This slow energy drain continued until the voltage dropped to the point that the power supply shut down, and that’s were things really started going south. Once the satellite shut down the batteries were able to start charging back up, which normally would have been a good thing. But unfortunately the KRAKsat had no mechanism to remain powered down once the voltage climbed back above the shutoff threshold. This caused the satellite to enter into and loop where it would reboot itself as many as 150 times per orbit (approximately 90 minutes).
The paper then goes into a laundry list of other problems that contributed to KRAKsat’s failure. For example, the satellite had redundant radios onboard, but the software on them wasn’t identical. When they needed to switch over to the secondary radio, they found that a glitch in its software meant it was unable to access some portions of the onboard flash storage. The team also identified the lack of a filesystem on the flash storage as another stumbling block; having to pull things out using a pointer and the specific memory address was a cumbersome and time consuming task made all the more difficult by the spacecraft’s deteriorating condition.
Of course, building a satellite that was able to operate for a couple weeks is still an impressive achievement for a student team. As we’ve seen recently, even the pros can run into some serious technical issues once the spacecraft leaves the lab and is operating on its own.
Like many of us, [Zak Kemble] has an indeterminate number of tiny packages coming his way from all over the globe at any given time. Unfortunately, the somewhat unpredictable nature of the postal service where he lives meant he found himself making a lot of wasted trips out to the mailbox to see if any overseas treasures had arrived for him. To solve the problem, he decided to build an Internet-connected mailbox notification system that could work within some fairly specific parameters.
For one thing, the mailbox is too distant to connect directly to it over WiFi. [Zak] mentions that 433 MHz might have been an option, but he decided to skip that entirely and just connect it to the cellular network with an A9G GPRS/GSM module from A.I. Thinker. This device actually has its own SDK that allows you to create a custom firmware for it, but unfortunately the high energy consumption of the radio meant it would chew through batteries too quickly unless it had a little extra help.
Not wanting to have to change the batteries every couple months, [Zak] added a ATtiny402 to handle the notifier’s power management needs. By using a P-MOSFET to completely cut power to the A9G, the notifier can save an incredible amount of energy by only activating the cellular connection once it actually needs to send a notification; which in this case takes the form of an HTTP request that eventually works its way to a Telegram group chat.
To cut a long story short, testing seems to indicate that the notifier can fire off approximately 800 requests before needing its 10440 lithium battery recharged. Given how often [Zak] usually receives mail, he says that should last him around five years.
The A9G module, the ATtiny402, a BME280 environmental sensor (because, why not?), the battery, and all the ancillary support hardware are on a very professional looking PCB. That goes into a relatively rugged enclosure that’s designed to keep the electronics from shorting out on the mailbox’s metal case as well as keeping any particularly weighty parcels from crushing it.
When the Raspberry Pi 4 was first launched, one of its few perceived flaws was that it had a propensity to get extremely hot. It’s evidently something the Pi people take very seriously, so in the months since they have addressed the problem with a set of firmware updates. Now they’ve taken a look at the effect of the fixes in a piece on the Raspberry Pi web site, and it makes for an interesting comparison.
The headline figure is that all updates together remove about a watt of power from the load, a significant quantity for what is still a board that can run from a capable phone charger. Breaking down the separate parts of the updates is where the meat of this story lies though, as we see the individual effects of the various USB, memory, power management and clocking updates. In temperature terms they measure an on-load drop from 72.1 °C to 58.1 °C, which should be a significant improvement for any Pi 4 owner.
There is a debate to be had over in what role a computer such as a Pi should serve. As successive revisions become ever more desktop-like in their capabilities, do they run the risk of abandoning the simplicity of a cheap Linux box as a component that makes us come back for more? It’s a possibility, but one they have very well addressed by developing the Pi Zero. They have also successfully avoided the fate of the Arduino — inexorably tied to its ATmega powered original line despite newer releases. As we have frequently said when reviewing Raspberry Pi competitors, it’s the software support that sets them apart from the herd, something this power-draw story demonstrates admirably.
