Adding an additional fan to your PC is usually pretty straightforward, but as [Randy Elwin] found, this isn’t always the case with the newer Small Form Factor (SFF) machines. Not only was the standard 80 mm fan too large to fit inside of the case, but there wasn’t even a spot to plug it in. So he had to come up with his own way to power it up and control its speed.
Now if he only needed power, that wouldn’t have been a problem. You could certainly tap into one of the wires coming from the PSU and get 12 V to spin the fan. But that would mean it was running at max speed the whole time; fine in a pinch, but not exactly ideal for a daily driver.
To get speed control, [Randy] put together a little circuit using an ATtiny85, an IR LED, and a LTR-306 phototransistor. The optical components are used to detect the GPU fan’s current speed, which itself is controlled based on system temperature. Using the GPU fan RPM as an input, a lookup table on the microcontroller sets an appropriate speed for the 80 mm case fan.
One could argue that it would have been easier to connect a temperature sensor to the ATtiny85, but by synchronizing the case fan to the computer-controlled GPU fan, [Randy] is able to manually control them both from software if necessary. Rather than waiting on the case temperature to rise, he can peg the GPU fan and have the external fan speed up to match when the system is under heavy load.
The wood-burning heater [g3gg0] has at home works perfectly, except for one flaw: the pellet reservoir needs to be manually refilled every few days. Humans being notoriously unreliable creatures, this critical task is sometimes overlooked, which naturally leads to literally chilling results.
With automatic fill systems expensive and difficult to install, [g3gg0] wanted to find some kind of way for the heater to notify its caretakers about any potential fault conditions. Not just the fact that it was out of fuel (though that would naturally be the most common alert), but any other issue which would potentially keep the heater from doing it’s job. In short, the heater was going to get a one-way ticket to the Internet of Things.
As it turns out, this task was not quite as difficult as you might expect. The Windhager heater already had upgrade bays where the user could insert additional modules and sensors, as well as a rudimentary data bus over RS-485. All [g3gg0] had to do was tap into this bus, decode what the packets contained, and use the information to generate alerts over the network. The ESP32 was more than up to the task, it just needed a custom PCB and 3D printed enclosure that would allow it to slot into the heater like an official expansion module.
When an interesting message flashes across the bus, the ESP32 captures it and relays the appropriate message to an MQTT broker. From there, the automation possibilities are nearly endless. In this case, the heater’s status information is being visualized with tools like Grafana, and important alerts are sent out to mobile devices with PushingBox. With a setup like this, the Windhager will never go hungry again.
What if your microcontroller IDE was running on the microcontroller itself and not hosted on the computer you use to do the programming? The greatest legacy of Arduino in all its forms has arguably been a software one, in that it replaced annoying proprietary development environments with one that installed easily on a range of operating systems, was easy to use, and above all, worked. The next level of portability is to get rid of any specialize computer-side software. [Ronny Neufeld] wrote MicroIDE for ESP32 as an IDE accessible through a web browser, which interestingly is hosted on the target device itself.
Using the IDE is easy enough, install a binary, connect to the ESP with a web browser, start writing MicroPython code. There is a choice of connecting directly to the chip as a hotspot, or connecting via another WiFi network. The interface is looking pretty slick but he’s at pains to remind us that it’s a work in progress. Sadly there is no source code yet as it’s a binary distribution that is free for non-commercial use, we’d hope that an open-source release might one day happen. It’s not for everyone, but the convenience of accessing the same interface from almost any modern device should help attract a healthy community.
There are some incredibly cheap WiFi smart bulbs on the market these days, but as is often the case, you tend to get what you pay for. When [Viktor] took delivery of his latest bargain basement bulb, the thing didn’t even work. So much for Quality Assurance. On the plus side, it was a great excuse to pop it open and replace the firmware.
For anyone wondering, [Viktor] never actually figured out why the bulb didn’t work. Its ESP8266-based control board was getting power, and data was getting spit out of the serial port when he connected it to the computer (although he never got the communications settings right to actually see what it was saying). But he also didn’t care much; once he confirmed that the hardware was good, he just uploaded the custom firmware he’d previously developed for another ESP8266 bulb.
Of course, it wasn’t quite that easy. The chances that both bulbs would have used the same GPIO pins to control the red, green, blue, and white LEDs were pretty slim. But after some testing and modifications to the code, he was able to fire them up. The other issue was a bit trickier, as it turned out the bulb’s flash chip was too small to hold his firmware’s web configuration pages. So he had to break out the hot air gun and replace the SPI flash chip with something a bit roomier. We suppose he could have just made smaller web pages… but where’s the fun in that?
Reverse engineering or modifying a device often requires you to access the firmware stored on a microcontroller. Since companies are usually not fond of people who try to peek into their proprietary data, most commercial devices are readout protected. [rumpeltux] ran into this problem when he tried to dump the firmware on an HC-12 wireless serial communication module for yet undisclosed reasons. Hacking into the device was a challenge that he gladly accepted and in the end, he succeeded by building a low-cost setup for voltage glitching.
Voltage glitching is a form of fault injection that has, e.g., been successfully used to hack the Playstation Vita. It involves the injection of voltage spikes on the power line in order to force the bootloader to skip security checks. The hard thing is trying to find the right shape of the waveform and the best way to inject the signal.
While there are already open-source boards for fault injection like ChipWhisperer, [rumpeltux] chose to build his own setup around an FPGA. By using a cheap EPM240 board, some MOSFET, and a USB-to-Serial converter, the total costs of the glitching setup were under 20 Euros. [rumpeltux] then recorded a larger number of voltage traces on the VCC pin around the reset phase and analyzed the differences. This helped him to pinpoint the best time for injecting the signal and refine the search space. After some unsuccessful attempts to glitch the VCC and GND pins, he got lucky when using one of the voltage regulator pins instead.
Security has always been an issue with IoT devices. Off the shelf devices often have terrible security while DIY solutions can be complicated, needing recompilation every time a website’s fingerprint changes. [Johannes] wrote in to let us know he’s been working on a way to make HTTPS requests easier to do on ESP devices.
The normal ways to do HTTPS with an ESP8266 is to either use Fingerprints, or to use client.setInsecure(). Fingerprints require the user to know exactly which pages the ESP will connect to and extract the Fingerprints from each of those websites. Since the fingerprints change yearly, this means the fingerprint will have to be re-extracted and the code recompiled each time a fingerprint changes. The use of client.setInsecure() is, obviously, insecure. This may not be an issue for your project, but it might be for others.
[Johannes’] solution is to extract the trusted root certificates and store them in PROGMEM. This allows access to any web page, but the root certificates do expire as well. As opposed to the fingerprints, though, they expire after 20 years, rather than every year, so the program can run for a long time before needing recompilation. This solution also doesn’t require any manual steps – the build process runs a script that grabs the certificates and stores them in files so that they can be uploaded to the SPIFFS written to PROGMEM to be used during HTTPS requests.
He’s come up with a fairly straightforward way to have your IoT device connect to whichever web page you want, without having to recompile every once in a while. Hopefully, this will lead to better security for your IoT devices. Take a look at some previous work in this area.
While most people are satisfied with a calculator application on their smartphone these days, there’s still something to be said for the old fashioned desk calculator. Maybe it’s the fact the batteries last long enough that you can’t remember the last time you changed them, or the feel of physical buttons under your fingers. It could even be the fact that it keeps your expensive smartphone from needing to sit out on the workbench. Whatever the reason, it’s not uncommon to see a real-life calculator (or two) wherever solder smoke tends to congregate.
Which is precisely the idea behind this DIY calculator kit. Available from the usual overseas retailers for about $15 USD, it has some hobbyist-oriented features such as the ability to decode resistor color bands, convert hexadecimal numbers, and calculate resistor values for driving LEDs. If you’re going to keep a knock-around calculator on your bench, why not build the thing yourself?
Given the dual nature of this product, a DIY electronics kit and a functional desk calculator for electronic hobbyists, it seems only appropriate to review both aspects of it individually. Which is good, since there may be more to this product than just the sum of its parts.