Posts in Electronics (20 found)

Great device, wrong problem: Two months with the Ultrahuman Air

I've been wearing an Apple Watch daily for the last 7-ish years now. It's kinda become part of my personality -- like, something feels off when I'm not wearing it. But lately, I thought I wanted a change. Maybe it’d be nice to wear a proper watch every now and then, or even go bare-wristed for a bit. So, a couple of months ago, I started hunting for an alternative device that could keep track of my health and stats -- which I figured was the main reason I wore my watch. After tons of research, I settled on the Ultrahuman Air. Some reviews mentioned that the Oura Ring seems generally more accurate, but the Ultrahuman does not require a subscription to fully utilize -- a total dealbreaker for me with the Oura Ring. I was stoked to try something new. It’s a fantastic device, no question. I was impressed. But as the weeks went on, I started to notice what it couldn’t do -- and that’s when I realized it's not replacing my watch. So I’ve come to realize that health tracking isn’t even the main thing I use my Apple Watch for -- it’s the alarms and notifications that keep my life together. This all means that while the Ultrahuman Air can definitely handle the health-tracking side of things, it can’t touch everything else I rely on the Apple Watch for. And now that both devices do a solid job at tracking stats, wearing two smart gadgets -- both needing charging and occasionally shining bright green lights at night -- feels redundant. I really love the Ultrahuman Air. It’s sleek, it’s smart, and it taught me a lot about my body. But it’s not the change I needed. So, it’ll probably be up on Facebook Marketplace soon. Maybe I’ll stick with my Apple Watch for now -- or who knows, maybe I’ll finally try going watch-free for a bit. We’ll see. Its app is fantastic. I love the design language they chose and how the stats are presented. Honestly, I didn’t know much about Heart Rate Variability (HRV) or VO2max until I wore the Ultrahuman Air, and now those are two stats I keep a close eye on. Handy features like Stress Rhythm and Caffeine Window feel a bit gimmicky, but they’ve got a ton of utility when you actually use them. The ring itself is super lightweight -- even lighter than a couple of carbide rings I like to wear. I barely notice it’s on, and its texturing makes it really scratch- and grime-resistant. Its reported stats are pretty close to what my Apple Watch shows, so without proper scientific gear to test it, I’m inclined to think they’re accurate enough. Its battery life is killer. I get about 4 and a half days on average -- compared to my Apple Watch, which I routinely charge before bed at night (thanks, low-battery anxiety issues). I wear my watch to bed so I can wake up at 5 AM without risking disturbing my wife and kid (who co-sleep with us). A phone alarm is a no-go since they’re both fairly light sleepers. I rely on reminders and message notifications to function. Seriously. With the amount of stuff I forget unless I write it down and set a reminder, the entire system I’ve built to manage my ADHD just breaks down without them. I use random Apple Watch features more than I realized: the handy flashlight that helps me navigate to the bathroom at midnight, the camera app that lets me take better group pics, and even the walkie-talkie that lets my wife and me ping each other quickly and directly.

1 views
Jeff Geerling 1 weeks ago

Air Lab is the Flipper Zero of air quality monitors

This air quality monitor costs $250. It's called the Air Lab , and I've been using it to measure the air in my car, home, studio, and a few events over the past few months. And in using it over the course of a road trip I learned to not run recirculate in my car quite as often—more on that later. Networked Artifacts built in some personality:

0 views
@hannahilea 1 weeks ago

Learning to learn how to play with electronics

A journey of a thousand doofy hardware projects starts with a single Adafruit blink

0 views
Ruslan Osipov 1 weeks ago

Modality, tactility, and car interfaces

Modal interfaces are genuinely cool. For the uninitiated, a “modal” interface is one where the same input does different things depending on the state (or mode) the system is in. Think of your smartphone keyboard popping up only when you need to type, or a gas pedal driving the car forward or backward depending on the gear. I love the concept enough to dedicate a whole chapter of Mastering Vim to it. But there’s a time and a place for everything, and a car’s center console is neither the time nor the place for a flat sheet of glass. I was traveling this week and rented a Kia EV6 - a perfectly serviceable electric car. I was greeted by a sleek touch panel that toggles control between the air conditioning and the audio system. Dear car manufacturers: please, I am begging you, stop. When I’m driving down the highway at 75 miles per hour, the absolute last thing I should be doing is taking my eyes off the road to visually verify which mode my AC knobs are in so I can turn down the volume. I can’t feel my way around the controls because gently grazing the surface of the screen registers as a button press. It’s not just annoying - it’s unsafe. Modality works fine when you have physical feedback. My old Pebble Time Round ( may it rest in peace ) had a tactile modal interface. It had four buttons that did different things depending on the context. But because they were physical, clicky buttons, I could operate the watch without ever looking at it. I could skip a track or dismiss a notification while riding my bike, purely by feel. Compare that to modern smart watches, or, worse, earbuds. Don’t even get me started on touch controls on earbuds. I’m out here riding my bike through rough terrain - I do not have the fine motor control required to perform a delicate gesture on a wet piece of plastic lodged in my ear. I miss the click. I miss the resistance. I miss knowing I’ve pressed a button without needing confirmation from the software. We’ve optimized for screens that can be anything in so many areas of our lives, but these screens aren’t particularly good at controlling stuff when we’re living said lives. Yeah, I miss analog buttons.

0 views
Stavros' Stuff 2 weeks ago

I converted a rotary phone into a meeting handset

As you may remember, or completely not know, I have a bit of a fascination with old rotary phones . Occasionally, when people learn about this fascination, they donate their old rotary phones to me, so I have ended up with a small collection. The other thing I have a fascination with is meetings. Well, I say “fascination”, but it’s more of a burning hatred, really. One day, a few months ago, I was in one such meeting, as I have been every day since, and I jokingly pretended to get irate about something. One of my coworkers laughed and said “I bet if this were a phone call, you’d slam the phone down right now”, and a dread spread over me. Why didn’t I have a phone handset I could slam down? Had I really become a corporate husk of my former, carefree self, puppeteered by the vicissitudes of capitalism? “No”, I decided, “because that sentence doesn’t even make sense”. I did, however, have a phone I could use for this project, 30% of the knowledge required, and 100% of the underestimation of how hard the other 70% would be. Armed with all these numbers, I quickly started to try to figure out how I could do this. The phone I used is an old Siemens rotary phone, pictured in the image to the right. That image is actually not a photo of the phone, but ChatGPT’s best attempt at one, because I’m too lazy to try to find where I put the phone to take a photo of it. Rest assured, though, the image is almost exactly what the phone looks like, except with a bit more 8 and a bit less 3. The good thing about these old phones is that nothing is soldered to anything else, which makes it possible to modify them without making any permanent changes to the phone, something which I really wanted to avoid. I don’t really think it matters much, but I don’t like breaking/altering these old phones at all. I prefer to make reversible changes where I can, and luckily the phones allow that. The phone’s board has these metal tabs that stick out, and the cables have a corresponding connector that opens up around the tab, making decent electrical contact and using friction to make sure they don’t slip off. Since I didn’t want to make any permanent changes to the phone, I didn’t want to remove these tabs, or to solder anything onto them. I just wanted to connect a cable to them in the easiest way possible. To do that, I designed and 3D-printed a very small connector (pictured in the photo on the right, the small, purple piece of plastic), which I used to hold a wire on top of the tab. This worked fairly well, the cable made good contact, and was relatively stable, as long as you didn’t pull on it at all. With the connections out of the way, I could move on to the electronics themselves, and where they’d go. Another benefit of these old phones are that they’re much larger than the circuits inside them, which means that the interior is very, very roomy, with lots of space for all the extra bits I wanted to use. Since I wanted to be able to use the phone as a meeting handset, I figured I needed something that would act as a keyboard/soundcard combo. The keyboard would be responsible for actually “hanging up” the meeting, ie sending the appropriate keystrokes to the active window to exit whatever meeting I happened to be on. The soundcard would expose a microphone/speaker combo, which could be used as an input and output device for the meeting software to play and record sound through the phone’s handset. I figured, since I’m at it, I might as well make the rotary dial work too, and have the keyboard type whatever number I dialed, just because I could. To do all this, I needed a capable microcontroller, and I had just the thing: The RP2040 by Raspberry Pi is plenty powerful enough to be used as a sound card, and can be made to show up to the computer as a USB device. Of course, if the RP2040 was to act as a USB device that’s a combination sound card/keyboard, I’d have to spend a lot of time learning about USB devices, sound cards, keyboards, and how the RP2040 works, which is a prospect which I relished with considerable gusto, said no one ever, and especially not me. Instead, we have LLMs now, and we can make them do the dirty work we don’t want to do, like program stuff for our inane side-projects. This is literally why LLMs were created and nobody can convince me otherwise, so I decided to help Claude Opus 4.1 (the best coding model at the time) progress on its goal towards self-actualization, and got to work. Unfortunately, Opus was only available on the $200/mo subscription, which was a bit too much for a silly side-project, so I decided to use the API instead for a few hours of coding. I mean, it’s one LLM, Michael. What could it cost? Ten dollars? I asked Claude to write some code to turn the RP2040 into a sound card using TinyUSB, I tested it and told Claude about the way in which it didn’t work, it wrote more code, and so on. Half an hour and fifty dollars later, I realized I had spent fifty dollars on this, and that this was not sustainable because, if anything, the code was getting more and more buggy the more Claude fixed it. It was time for plan B. Plan B is shameful, as it contains an element of me accepting defeat, but I guess it’s actually Claude that was defeated. Be that as it may, I decided that the RP2040 sound card approach was a dead-end, as I didn’t know anything about the RP2040 or about sound cards, and that I’d have to change my tactics. I’d use a USB hub with two separate devices, one sound card and one keyboard, and the hub would join them and allow them to use a single USB cable to connect to the host computer. I could still use the RP2040 as a keyboard, so I connected it to the phone’s hook and rotary dial, and wrote some code to measure the pulses and send keystrokes if the handset was placed on the hook. After verifying that this worked properly, I moved on to the second, and by far the hardest, part of my plan, finding an off-the-shelf sound card. I ran to my trusty shopping website, Amazon (the AliExpress of the US), but all the USB sound cards there were a bit more expensive than they needed to be, so then I went straight to the source, AliExpress. There, I found exactly what I needed: A USB sound card for $1.69, and the sexual reference was not lost on me. Well done, AliExpress. When the sound card arrived, I tested it on my computer, saw that it worked fine, and disassembled it. I removed the two 3.5mm jack connectors and soldered pins to them instead, with the intention that the phone’s connectors would slide over the pins instead of the metal tabs of the phone. Indeed, this worked beautifully, and the handset made a very solid connection with the sound card. I plugged the latter into my computer and confirmed that I could both listen to and record from the handset. I then desoldered the USB connector and soldered four wires onto where it used to be, to save space. I soldered the other side of those wires to the hub, where I desoldered the corresponding connector from, and tested to see if this worked. Amazingly, it did! The computer recognized the sound card, and audio worked fine with the handset. I connected the RP2040 keyboard to the hub as well, and confirmed that that, too, worked well, sending various keystrokes when hung up (Ctrl+Shift+E for Zoom, by Ctrl+W for Meet, for Teams, etc). To clarify, the RP2040 doesn’t actually know which software you’re using for the call, it just sends all the keystrokes, one after the other. On the image to the right, you can see everything connected together. The red square to the right of the phone is the USB hub, with wires coming out of it and going to the sound card, which has been connected to the handset. On the other end, a short USB cable leads to the RP2040, which has been connected to the hook and rotary dial. It took a bit of trial and error to find the hook connectors, but nothing too terrible. The hook is a simple switch, so the detection happens with a GPIO pin that gets pulled low whenever the phone is hung up. The rotary dial is similarly a second switch, one that opens and closes very quickly, a number of times equal to the number you just dialed. The software on the RP2040 just counts these opens and closes, waits a few milliseconds to see if there are any more of them, and, if not, simulates a keyboard typing the number it counted. Here’s a video of the whole thing, including the hanging up money shot: I hope this post made sense, it was a bit stream-of-consciousness but this was a pretty simple build, with nothing really too involved or complicated. The most complicated part was probably the RP2040 keyboard emulation, and even that was pretty simple, because the LLM did it on its own. If you have any feedback, questions, or hate mail, you can find me on Bluesky , or email me directly.

0 views
Jeff Geerling 3 weeks ago

Converting hot dog plasma video to sound with OpenCV

When you ground a hot dog to an AM radio tower, it generates plasma. While the hot dog's flesh is getting vaporized, a tiny plasma arc moves the air around it back and forth. And because this tower is an AM tower, it uses Amplitude Modulation , where a transmitter changes the amplitude of a carrier wave up and down. Just like a speaker cone moving up and down, the plasma arc from the hot dog turns that modulation into audible sound.

1 views
Daniel Mangum 3 weeks ago

Interesting SPI Routing with iCE40 FPGAs

A few weeks ago I posted about how much fun I was having with the Fomu FPGA development board while travelling. This project from Tim ‘mithro’ Ansell and Sean ‘xobs’ Cross is not new, but remains a favorite of mine because of how portable it is — the entire board can fit in your USB port! The Fomu includes a Lattice Semiconductor iCE40 UltraPlus 5K, which has been a popular FPGA option over the past few years due to the reverse engineered bitstream format and ability to program it with a fully open source toolchain (see updated repository here).

0 views
Rik Huijzer 3 weeks ago

Some Thoughts on High Frequency Currents and Oxidative Stres...

s As I wrote before, there is much research that shows that electromagnetic radiation causes oxidative stress. This means that electromagnetic radiation can knock an electron out of a molecule, which is called ionizing radiation. Some people say that electromagnetic radiation from radio frequencies is non-ionizing, but this contradicts the fact that many studies have shown that radio frequencies also produce oxidative stress. The higher the frequency, the more ionizing (read: damaging) the radiation is. Similarly, it is known that x-rays at wavelengths below 10 nm will destroy cells. Electro...

0 views
Rik Huijzer 3 weeks ago

Solar Cell Spectral Sensitivity

I just came across the book _Solar Secrets_ (2014) by Peter Lindemann. It observes that most solar panels are optimized to perform on bright sunny days whereas they barely perform on cloudy days. This while there are panels that capture light of lower wavelengths and are therefore much less affected by clouds. The author shows this in the following figure from page 17: ![Solar Cell Spectral Sensitivity a-Si solar versus c-Si solar](/files/e452ae9cbcc36dba) Here it can be seen that Amorphous Silicon (a-Si) solar panels produce energy from the 500 to 700 nm wave length range while Crystalline...

0 views
Jeff Geerling 1 months ago

The Arduino Uno Q is a weird hybrid SBC

The Arduino Uno Q is... a weird board. It's the first product born out of Qualcomm's buyout of Arduino . It's like if you married an Intel CPU, and a Raspberry Pi RP2040 microcontroller—oh wait, Radxa's X4 did that . Arduino even tried it before with their old Yún board, which had Linux running on a MIPS CPU, married to an ATmega microcontroller.

0 views

My impressions of the MacBook Pro M4

I have been using a MacBook Pro M4 as my portable computer for the last half a year and wanted to share a few short impressions. As always, I am not a professional laptop reviewer, so in this article you won’t find benchmarks, just subjective thoughts! Back in 2021, I wrote about the MacBook Air M1 , which was the first computer I used that contained Apple’s own ARM-based CPU. Having a silent laptop with long battery life was a game-changer, so I wanted to keep those properties. When the US government announced tariffs, I figured I would replace my 4-year old MacBook Air M1 with a more recent model that should last a few more years. Ultimately, Apple’s prices remained stable, so, in retrospect, I could have stayed with the M1 for a few more years. Oh well. I went to the Apple Store to compare the different options in person. Specifically, I was curious about the display and whether the increased weight and form factor of the MacBook Pro (compared to a MacBook Air) would be acceptable. Another downside of the Pro model is that it comes with a fan, and I really like absolutely quiet computers. Online, I read from other MacBook Pro owners that the fan mostly stays off. In general, I would have preferred to go with a MacBook Air because it has enough compute power for my needs and I like the case better (no ventilation slots), but unfortunately only the MacBook Pro line has the better displays. Why aren’t all displays nano-textured? The employee at the Apple Store presented the trade-off as follows: The nano texture display is great at reducing reflections, at the expense of also making the picture slightly less vibrant. I could immediately see the difference when placing two laptops side by side: The bright Apple Store lights showed up very prominently on the normal display (left), and were almost not visible at all on the nano texture display (right): Personally, I did not perceive a big difference in “vibrancy”, so my choice was clear: I’ll pick the MacBook Pro over the MacBook Air (despite the weight) for the nano texture display! After using the laptop in a number of situations, I am very happy with this choice. In normal scenarios, I notice no reflections at all (where my previous laptop did show reflections!). This includes using the laptop on a train (next to the window), or using the laptop outside in daylight. (When I chose the new laptop, Apple’s M4 chips were current. By now, they have released the first devices with M5 chips.) I decided to go with the MacBook Pro with M4 chip instead of the M4 Pro chip because I don’t need the extra compute, and the M4 needs less cooling — the M4 Pro apparently runs hotter. This increases the chance of the fan staying off. Here are the specs I ended up with: One thing I noticed is that the MacBook Pro M4 sometimes gets warm, even when it is connected to power, but is suspended to RAM (and has been fully charged for hours). I’m not sure why. Luckily, the fan indeed stays silent. I think I might have heard it spin up once in half a year or so? The battery life is amazing! The previous MacBook Air M1 had amazing all-day battery life already, and this MacBook Pro M4 lasts even longer. For example, watching videos on a train ride (with VLC) for 3 hours consumed only 10% of battery life. I generally never even carry the charger. Because of that, Apple’s re-introduction of MagSafe, a magnetic power connector (so you don’t damage the laptop when you trip over it), is nice-to-have but doesn’t really make much of a difference anymore. In fact, it might be better to pack a USB-C cable when traveling, as that makes you more flexible in how you use the charger. I was curious whether the 120 Hz display would make a difference in practice. I mostly notice the increased refresh rate when there are animations, but not, for example, when scrolling. One surprising discovery (but obvious in retrospect) is that even non-animations can become faster. For example, when running a Go web server on , I noticed that navigating between pages by clicking links felt faster on the 120 Hz display! The following illustration shows why that is, using a page load that takes 6ms of processing time. There are three cases (the illustration shows an average case and the worst case): As you can see, the waiting time becomes shorter when going from 60 Hz (one frame every 16.6ms) to 120 Hz (one frame every 8.3ms). So if you’re working with a system that has <8ms response times, you might observe actions completing (up to) twice as fast! I don’t notice going back to 60 Hz displays on computers. However, on phones, where a lot more animations are a key part of the user experience, I think 120 Hz displays are more interesting. My ideal MacBook would probably be a MacBook Air, but with the nano-texture display! :) I still don’t like macOS and would prefer to run Linux on this laptop. But Asahi Linux still needs some work before it’s usable for me (I need external display output, and M4 support). This doesn’t bother me too much, though, as I don’t use this computer for serious work. 14" Liquid Retina XDR Display with nano texture Apple M4 Chip (10 core CPU, 10 core GPU) 32 GB RAM (this is the maximum!), 2 TB SSD (enough for this computer) Best case: Page load finishes just before the next frame is displayed: no delay. Worst case: Page load finishes just after a frame is displayed: one frame of delay. Most page loads are somewhere in between. We’ll have 0.x to 1.0 frames of delay

0 views
Jeff Geerling 1 months ago

Why do some radio towers blink?

One day on my drive home, I saw three towers. One of them had a bunch of blinking white lights, another one had red lights that kind of faded in and out, and the third one, well, it wasn't doing anything. I'm lucky to have a radio engineer for a dad, so Dad: why do some towers blink? Joe: Well, blinking I would call like the way you described it, "flashing", "white light", or "strobe". All these lights are to aid pilots and air traffic. helicopters, fighter planes, regular jets. So that's the purpose of it. Jeff: Well that one tower that I saw had red lights that faded in and out, but I even think there's a freestanding tower just north of here that has red and white on top.

1 views
Maurycy 1 months ago

Some hot rocks:

I recently went on a rock collecting trip, but apart from the usual — quartz, K feldspar crystals, garnet, etc — I found some slightly radioactive rocks: All of these were found using my prospecting scintillator , but I took measurements with a Radiacode 102 — a very common hobbyist detector — so that other people can compare readings. Despite being small, it is still a gamma scintillator, so the count rates are much higher then any G-M tube. None of these are crazy hot, but they were all collected off the surface: I didn’t bring any good digging equipment on the trip. (Really should have considering how my detector is able to pick up deeply buried specimens) The biggest hazard with my rocks is dropping them on your toes. Even if you were to grind them up and inhale the dust, the host rock is much more of a danger then the radioactivity. I’ve personally been in multiple residential and office buildings that are more radioactive then my specimens because of the stone that was used to construct them. Also, if you have any “Anti-Radiation” or “Bio Energy” or “Quantum Energy” wellness products: they are quite the opposite. (and many are spicier then my rocks.) … or how about some nice decorative glass ? It glows

0 views
iDiallo 1 months ago

Why We Don't Have Flying Cars

Imagine this: You walk up to your driveway where your car is parked. You reach for the handle that automatically senses your presence, confirms your identity, and opens to welcome you in. You sit down, the controls appear in front of you, and your seatbelt secures itself around your waist. Instead of driving forward onto the pavement, you take off. You soar into the skies like an eagle and fly to your destination. This is what technology promises: freedom, power, and something undeniably cool. The part we fail to imagine is what happens when your engine sputters before takeoff. What happens when you reach the sky and there are thousands of other vehicles in the air, all trying to remain in those artificial lanes? How do we deal with traffic? Which directions are we safely allowed to go? And how high? We have flying cars today. They're called helicopters. In understanding the helicopter, we understand why our dream remains a dream. There's nothing romantic about helicopters. They're deafeningly loud and incredibly expensive to buy and maintain. They require highly skilled pilots, are dangerously vulnerable to engine failure, and present a logistical nightmare of three-dimensional traffic control. I can't even picture what a million of them buzzing between skyscrapers would look like. Chaos, noise pollution, and a new form of gridlock in the sky. Even with smaller drones, as the technology evolves and becomes familiar, cities are creating regulations around them, sucking all the fun and freedom out in favor of safety and security. This leads me to believe that the whole idea of flying cars and drones is more about freedom than practicality. And unregulated freedom is impossible. This isn't limited to flying cars. The initial, pure idea is always intoxicating. But the moment we build a prototype, we're forced to confront the messy reality. In 1993, a Japanese man brought a video phone to demo for my father as a new tech to adopt in our embassy. I was only a child, but I remember the screen lighting up with a video feed of the man sitting right next to my father. I could only imagine the possibilities. It was something I thought only existed in sci-fi movies. If this was possible, teleportation couldn't be too far away. In my imagined future, we'd sit at a table with life-like projections of colleagues from across the globe, feeling as if we were in the same room. It would be the end of business travel, a world without borders. But now that the technology is ubiquitous, the term "Zoom fatigue" is trending. It's ironic when I get on a call and see that 95% of my colleagues have their cameras turned off. In movies, communication was spontaneous. You press a button, your colleauge appears as a hologram, and you converse. In reality, there's a calendar invite, a link, and the awkward "you're on mute!" dance. It's a scheduled performance, not an organic interaction. And then there are people who have perfect lighting, high-speed internet, and a quiet home office. And those who don't. Video calls have made us realize the importance of physical space and connection. Facebook's metaverse didn't resolve this. Imagine having a device that holds all of human knowledge at the click of a button. For generations, this was the ultimate dream of librarians and educators. It would create a society of enlightened, informed citizens. And we got the smartphone. Despite being a marvel of technology, the library of the world at your fingertips, it hasn't ushered us into utopia. The attention economy it brought along has turned it into a slot machine designed to hijack our dopamine cycles. You may have Wikipedia open in one tab, but right next to it is TikTok. The medium has reshaped the message from "seek knowledge" to "consume content." While you have access to information, misinformation is just as rampant. The constant stimulation kills moments of quiet reflection, which are often the birthplace of creativity and deep thought. In The Machine Stops by E.M. Forster, every desire can be delivered by pulling a lever on the machine. Whether it's food, a device, or toilet paper. The machine delivers everything. With Amazon, we've created a pretty similar scenario. I ordered replacement wheels for my trash bin one evening, expecting them to arrive after a couple of days. The very next morning, they were waiting at my doorstep. Amazing. But this isn't magical. Behind it are real human workers who labor without benefits, job security, or predictable income. They have an algorithmic boss that can be more demanding than a human one. That promise of instant delivery has created a shadow workforce of people dealing with traffic, poor weather, and difficult customers, all while racing against a timer. The convenience for the user is built on the stress of the driver. The dream of a meal from anywhere didn't account for the reality of our cities now being clogged with double-parked delivery scooters and a constant stream of gig workers. Every technological dream follows the same pattern. The initial vision is pure, focusing only on the benefit. The freedom, the convenience, the power. But reality is always a compromise, a negotiation with physics, economics, and most importantly, human psychology and society. We wanted flying cars. We understood the problems. And we got helicopters with a mountain of regulations instead. That's probably for the best. The lesson isn't to stop dreaming or stop innovating. It's to dream with our eyes open. When we imagine the future, we need to ask not just "what will this enable?" but also "what will this cost?" Not in dollars, but in human terms. In stress, inequality, unintended consequences, and the things we'll lose along the way. We're great at imagining benefits and terrible at predicting costs. And until we get better at the second part, every flying car we build will remain grounded by the weight of what we failed to consider.

0 views
Dangling Pointers 1 months ago

Automata All the Way Down

Fabs and EDA companies collaborate to provide the abstraction of synchronous digital logic to hardware designers. A hardware design comprises: A set of state elements (e.g., registers and on-chip memories), which retain values from one clock cycle to another A transfer function , which maps the values of all state elements at clock cycle N to new values of all state elements at clock cycle The transfer function cannot be too fancy. It can be large but cannot be defined with unbounded loops/recursion. The pragmatic reason for this restriction is that the function is implemented with physical gates on a chip, and each gate can only do one useful thing per clock cycle. You cannot loop the output of a circuit element back to itself without delaying the value by at least one clock cycle (via a state element). It feels to me like there is a deeper reason why this restriction must exist. Many people dabbled with synchronous digital logic in college. If you did, you probably designed a processor, which provides the stored program computer abstraction to software developers. And here comes the inception: you can think of a computer program as a transfer function. In this twisted mindset, the stored program computer abstraction enables software engineers to define transfer functions . For example, the following pseudo-assembly program: Can be thought of as the following transfer function: In the stored program computer abstraction, state elements are the architectural registers plus the contents of memory. As with synchronous digital logic, there are limits on what the transfer function can do. The switch statement can have many cases, but the body of each case block is defined by one instruction. Alternatively, you can define the transfer function at the basic block level (one case per basic block, many instructions inside of each case). Programming in assembly is a pain, so higher level languages were developed to make us less crazy. And here we go again, someone could write an interpreter for C. A user of this interpreter works at the C level of abstraction. Following along with our previous pattern, a C program comprises: A set of state elements (variables, both global and local) A transfer function For example, the following C function: Can be thought of with as the following transfer function: Think of and as intrinsics used to implement function calls. The key building blocks of the transfer function are state ments. It is easy to just store the term “statement” into your brain without thinking of where the term comes from. A state ment is a thing which can alter state . This transformation of an imperative program into a transfer function seems strange, but some PL folks do it all the time. In particular, the transfer function view is how small step operational semantics are defined. And of course this can keep going. One could write a Python interpreter in C, which allows development at a higher level of abstraction. But even at that level of abstraction, programs are defined in terms of state elements (variables) and a transfer function (statements). The term Turing Tax was originally meant to describe the performance loss associated with working at the stored-program computer level of abstraction instead of the synchronous digital logic level of abstraction. This idea can be generalized. At a particular level of abstraction, code defines the transfer function while data is held in the state elements. A particular set of bits can simultaneously be described as code at one level of abstraction, while defined as data at a lower level. This code/data duality is intimately related to the Turing Tax. The Turing Tax collector is constantly looking for bags of bits which can be interpreted as either code or data, and he collects his tax each time he finds such a situation. An analogous circumstance arises in hardware design. Some signals can be viewed as either part of the data path or the control path, depending on what level of abstraction one is viewing the hardware from. A compiler is one trick to avoid the Turing Tax by translating code (i.e., a transfer function) from a higher level of abstraction to a lower level. We all felt awkward when I wrote “interpreter for C” earlier, and now we can feel better about it. JIT compilers for Python are one way to avoid the Turing Tax. Another example is an HLS compiler which avoids the Turing Tax between the stored-program computer abstraction layer and the synchronous digital logic layer. No, this section isn’t about your Fitbit. Let’s call each evaluation of a transfer function a step . These steps occur at each level of abstraction. Let’s define the ultimate performance goal that we care about to be the number of steps required to execute a computation at the synchronous digital logic level of abstraction. The trouble with these layers of abstraction is that typically a step at a higher layer of abstraction requires multiple steps at a lower layer. For example, the multi-cycle processor implementation you learned about in a Patterson and Hennessy textbook could require 5 clock cycles to execute each instruction (instruction fetch, register fetch, execute, memory, register write back). Interpreters have the same behavior: one Python statement may be implemented with many C statements. Now imagine the following house of cards: A Python interpreter which requires an average of 4 C statements to implement 1 Python statement A C compiler which requires an average of 3 machine instructions to implement 1 C statement A processor which requires an average of 5 clock cycles to execute 1 machine instruction When the Turing property tax assessor sees this house, they tax each level of the house . In this system, an average Python statement requires (4 x 3 x 5) 60 clock cycles! Much engineering work goes into avoiding this problem (pipelined and superscalar processors, multi-threading, JIT compilation, SIMD). Partial evaluation is another way to avoid the Turing Tax. Partial evaluation transforms data into code . There must be some other method of creating abstractions which is more efficient. Self-modifying code is rarely used in the real world (outside of JIT compilers). Self-modifying code seems crazy to reason about but potentially could offer large performance gains. Partial evaluation is also rarely used but has a large potential. Subscribe now A set of state elements (e.g., registers and on-chip memories), which retain values from one clock cycle to another A transfer function , which maps the values of all state elements at clock cycle N to new values of all state elements at clock cycle A set of state elements (variables, both global and local) A transfer function Code vs Data At a particular level of abstraction, code defines the transfer function while data is held in the state elements. A particular set of bits can simultaneously be described as code at one level of abstraction, while defined as data at a lower level. This code/data duality is intimately related to the Turing Tax. The Turing Tax collector is constantly looking for bags of bits which can be interpreted as either code or data, and he collects his tax each time he finds such a situation. An analogous circumstance arises in hardware design. Some signals can be viewed as either part of the data path or the control path, depending on what level of abstraction one is viewing the hardware from. Compilers vs Interpreters A compiler is one trick to avoid the Turing Tax by translating code (i.e., a transfer function) from a higher level of abstraction to a lower level. We all felt awkward when I wrote “interpreter for C” earlier, and now we can feel better about it. JIT compilers for Python are one way to avoid the Turing Tax. Another example is an HLS compiler which avoids the Turing Tax between the stored-program computer abstraction layer and the synchronous digital logic layer. Step Counting (Multiple Taxation) No, this section isn’t about your Fitbit. Let’s call each evaluation of a transfer function a step . These steps occur at each level of abstraction. Let’s define the ultimate performance goal that we care about to be the number of steps required to execute a computation at the synchronous digital logic level of abstraction. The trouble with these layers of abstraction is that typically a step at a higher layer of abstraction requires multiple steps at a lower layer. For example, the multi-cycle processor implementation you learned about in a Patterson and Hennessy textbook could require 5 clock cycles to execute each instruction (instruction fetch, register fetch, execute, memory, register write back). Interpreters have the same behavior: one Python statement may be implemented with many C statements. Now imagine the following house of cards: A Python interpreter which requires an average of 4 C statements to implement 1 Python statement A C compiler which requires an average of 3 machine instructions to implement 1 C statement A processor which requires an average of 5 clock cycles to execute 1 machine instruction

0 views
Jeff Geerling 1 months ago

VCF Midwest was even better than I expected

Earlier this year, I inherited a bunch of old Macs and computer parts, including the PowerBook 520 pictured above. And, for the past three years I've been trying to visit VCF Midwest up in Chicago, where there's this odd blend of old computers, radio, broadcast gear... Honestly, it's hard to pin down exactly what it is. And I also had no idea how overwhelming the two-day event would be. Overwhelmingly awesome , that is.

0 views
./techtipsy 1 months ago

Comparing the power consumption of a 30 year old refrigerator to a brand new one

Our apartment came with a refrigerator. It was alright, it made things cold, it kept them cold. It was also incredibly noisy, and no matter how much I fiddled with its settings, the compressor was always running and any ice cream left in the deep freeze part got rock solid. 1 When I hooked up one of my smart plugs to it, I soon learned why: one of the two compressors was running all the time. This lead to a huge block of ice forming on the back of the main compartment, and the deep freeze section icing up really quickly. I suspect that the thermostat may have been busted and contributed to the issue, but after trying to repair a dishwasher, getting cut about 10 times on my hands and losing, I had zero interest in attempting another home appliance repair on my own. The refrigerator was the UPO Jääkarhu ( jääkarhu means polar bear in Finnish), and the manual that the previous owner had still kept around had July 1995 on it, meaning that the refrigerator was about the same age as I am: 30 years old. Not bad at all for a home appliance! I shopped around for a new refrigerator and got a decent one that’s about the same size, except newer. I won’t mention the brand here because they didn’t pay me anything and this post really isn’t a refrigerator review, but it was in the low-to-midrange class, sporting a “no frost” feature, and could be bought for about 369 EUR in Estonia in the summer of 2025. Based on some napkin math, I assumed that within a few years, the electricity savings will cover the upfront cost of buying the new refrigerator, assuming that it doesn’t break down. After letting it run for a while, I had some data! Turns out that the old one consumed 3.7x more electricity compared to the new one. Here are some typical daily power consumption numbers: The difference is more noticeable if we zoom out a bit. Moving from ~78 kWh to ~21 kWh consumed each month is nice. Around the time we replaced the refrigerator, we also got a working dishwasher, and with those two combined I saw a solid 10-20% decrease in the overall power usage of the whole apartment. We went from using 334 kWh in June to 268 kWh in July, 298 kWh in August and 279 kWh in September. Remember that napkin math I made earlier? If we assume about 57 kWh savings per month, and an average electricity price of 17 cents per kWh (based on actual rates during August 2025), it will take about 38 months or a bit over 3 years for the new refrigerator to pay off in the most pessimistic scenario. The pay-off will likely be larger if we account for energy prices usually rising during winter. Don’t worry about the old refrigerator, we gave it away to a person who needed one for their new home in the short term as a stopgap until they get further with renovation work. Even got some good chocolate for that! The only point of concern with this change is that I don’t really trust the new refrigerator to last as long as the old one. The previous one was good for 30 years if you look past the whole ice buildup, heat and noise, but with the new one I suspect that it’s not going to last as long. At least my new refrigerator doesn’t have a Wi-Fi-connected screen on it! honestly, I miss that a lot, the ice cream was colder for longer, I ate it in smaller bites and savored it more.  ↩︎ old refrigerator: 2.6 kWh new refrigerator: 0.7 kWh honestly, I miss that a lot, the ice cream was colder for longer, I ate it in smaller bites and savored it more.  ↩︎

0 views