Letting go is hard, especially when it concerns an irreplaceable space probe like the two Voyagers. Fortunately JPL engineers have managed to pull off a ‘big bang’ switch on Voyager 2, involving two heaters and another device that was kept on to keep providing sufficient heat to the spacecraft to allow it to keep functioning. After all, while the vacuum of space isn’t cold, out in deep space you’re radiating away all your precious heat.

Unfortunately the official press release in exceedingly limited in details, but The Register was kind enough to already nag a NASA spokesperson about it, which gives us some technical details. The short version is that these heaters don’t just keep the electronics within a happy operating range, they also keep the fuel lines warm and capable of providing fuel for attitude adjustments.

With this switch apparently enough of the rapidly diminishing power from the RTG has been freed up that the Voyager 2 has just gained a whole extra year on its extended mission. The JPL team hopes to perform the same switch on the Voyager 1 spacecraft soon, giving it a similar boost to its expected lifespan, before both of them go quiet in the depths of space.

Thanks to [Mark Stevens] for the tip.

You’ve probably heard of rubidium frequency standards, which are used where you need an extremely accurate time or frequency reference. [IMSAI] guy has a good explainer video about what’s actually going on inside one of these standards. Much of the basic idea also applies to cesium standards.

The explainer starts with the periodic table. Rubidium and cesium are both alkali metals, with a single electron in their outermost electron shell. Rubidium has 37 electrons, with the outermost one relatively loosely bound. Naturally occurring rubidium consists mainly of two isotopes, rubidium-85 and rubidium-87, which have the same number of protons and electrons but different numbers of neutrons.

A rubidium standard typically has three gas cells that have a bit of rubidium in them. An RF-excited rubidium-87 discharge lamp produces light at very specific wavelengths. The RF energy excites rubidium atoms into higher electronic states, and when their electrons fall back to lower-energy states, the atoms emit photons.

That light passes through a filter cell containing rubidium-85. The filter preferentially absorbs part of the lamp’s spectrum, leaving light that optically pumps the rubidium-87 atoms in the second resonance cell into one of two closely spaced hyperfine states of the atom’s ground state.

Those two states differ because of the interaction between the magnetic moment of the outer electron and that of the rubidium-87 nucleus. Their energy separation corresponds to a microwave frequency of about 6.835 GHz.

The resonance cell is illuminated by the filtered light while also being exposed to microwave energy from a local oscillator. When the microwave frequency is exactly equal to the rubidium-87 hyperfine transition frequency, it transfers atoms between the two ground-state hyperfine levels. That changes how strongly the cell absorbs the optical pumping light, producing a detectable dip in the light reaching a photodetector.

Electronics then servo the microwave oscillator onto the center of that absorption dip, using a feedback technique somewhat analogous to a phase-locked loop. Once locked, the oscillator is effectively referenced to an atomic transition rather than to the dimensions or mechanical properties of a crystal, giving you an extremely stable frequency standard.

We’ve peeked into these before. Cesium clocks are more accurate, and optical clocks are even better than that.

It’s a complex world out there, and more than ever folks may find themselves in a situation where they want to keep particular bits of information away from prying eyes. At the same time, overly complex methods of file security can make it difficult to share said information with the intended recipients impractical. So what’s the solution?

One proposal from [Ryan Walker] AKA [machinehum] is the Phantomdrive — a fully open source USB flash drive that features a secret secondary filesystem. Not only is the existence of this data hidden from the operating system under normal circumstances, but it’s encrypted with AES-256. Rather than relying on software running on the computer to handle the decryption, the CH569 chip that powers the drive does it internally.

To complete this platform-agnostic approach, [machinehum] had to come up with a way for the user to unlock the secure storage that didn’t require running any code on the client machine. A hardware solution such as a keypad is the obvious answer, but in this case, was out of the question as it would immediately tip off an observer about the drive’s true nature. A covert storage device needs a similarly inconspicuous method of authentication.

That’s why the firmware on the Phantomdrive keeps an eye on all the write operations to the unsecured section of the drive looking for the string password:. Once it sees that, it treats whatever follows as the decryption key. If it’s correct, the previously inaccessible data will appear to the operating system as a new drive.

[machinehum] cautions that none of this has been professionally audited from a security standpoint, and that you should treat this whole concept as an experiment. In other words, it’s probably more than sufficient for the average person, but no guarantees on how long it would last should a three letter agency gets too interested in what you’re up to.

If this seems a bit familiar, it’s because the Phantomdrive follows up [machinehum]’s self-destructing USB flash drive from a few years back. The concept is essentially the same, except this time there’s no Magic Smoke getting released.

We’ve probably all got one item in our toolboxes or chests that we really, really don’t like, but find too handy to toss. For [Someone Should Make That], that item was the bolt-rounding adjustable wrench. Rather than continuing to gripe about it, or alter his habits to make greater use of the full wrench set he also owns, he decided to build a better mousetrap. By mousetrap, we mean adjustable wrench.

It took a couple of iterations on-screen before he hits on a solution that seems to work quite well indeed. The problem [Someone] had with his adjustable wrench was one of physical slop: once adjusted, there’s just too much play in the mechanism, which results in rounded-off bolt heads. [Someone]’s CNC’d solution takes inspiration from the CNC machine that manufactures it: he’s using spring-loading in the adjustment screw akin to what you find in the anti-backlash nut on your CNC mill or 3D printer’s ball threads. The tension from the springs keeps the wrench tight to the bolt, and that keeps [Someone] from rounding them off. Speaking of 3D printers, he prototyped in plastic before machining, and the screw in the end product stayed that way. It would be interesting to see how well that holds up.

Not only do we appreciate that it’s solved a common problem many of us have, the ethos of “this angers me, so I shall hack it” is one we support 100%, so do give a watch unless you’re one of those people who absolutely can’t stand videos, even when they’re spring-loaded to have no slop. There’s some good tips for beginner CNC operators in there, too.

This isn’t the first time someone’s tried to reinvent this particular wheel, though the last version we liked was a ratchet.

PID controllers are everywhere. They regulate temperature, motor speed, power supplies, positioning systems, process equipment, and probably a dozen things within arm’s reach of you right now.

They’re also frequently explained with enough calculus to make them seem more mysterious than they really are. Granted, the I and D in PID stand for calculus terms, but they are easy enough to build into a spreadsheet. Grab a copy and keep it open while you read this post.

The Google Sheet implements a simple simulated PID controller along with a simulated process — the thing we’re trying to control. You can change the controller gains, alter the process, introduce disturbances, and watch what happens without compiling anything or wiring up a heater that might accidentally become a toaster.

The three letters in PID stand for Proportional, Integral, and Derivative. If your calculus is rusty, integral is just how much is building up over time, and the derivative is how much changed just now. Each operates on the error:

error = setpoint - process value

The setpoint is where we’d like the system to be, the process value (PV) is where it actually is, and we would obviously like the error to be zero. Proportional is the most obvious method of control. The more we are off, the more we adjust. The closer we are to the setpoint, the less proportional output we need.

Integral, on the other hand, looks at a running tally of errors. Finally, derivative measures how much things have changed from the last time we looked. The basic cycle time for the spreadsheet is set by dt, which, by default, is 0.1 seconds. Therefore, it takes ten spreadsheet rows to cover an entire second.

Suppose we’re controlling temperature and want it to be 20 degrees. If the temperature is 15, the error is +5. If it’s 22, the error is -2. Our controller’s job is to turn that error into an output. That output affects something — a heater or a motor speed or whatever — that can change the process value. So for a temperature example, the output might drive a heating resistor, and the process value is measured by a thermistor.

The PID tries to drive the heater so that the process value is as close as possible to the setpoint. To the PID algorithm, the actual units of the output and the process values are immaterial. The spreadsheet limits output from 0 to 100 and, presumably, that would be a percentage of voltage or a PWM duty cycle. The setpoint and process value might be in degrees C or F. But the algorithm doesn’t really care.

First, Just P

Make sure the Model drop-down is set to DEFAULT. We’ll begin by setting:

Kp = 4
Ki = 0
Kd = 0

Set the initial process value to 0, the setpoint to 20, the process gain to 1, and the time constant to 2 seconds. With only the proportional term operating, the controller is particularly easy to understand:

output = Kp × error

At the beginning, the error is 20, so the controller asks for an output of 80 (that is, 4 times 20). However, the process doesn’t instantly jump to 80. Our simulated plant is a first-order system implemented essentially as:

PVnew = PVold + dt/tau × (Kprocess × output - PVold)

The actual spreadsheet has extra terms for a bias and disturbance, but you’ll usually leave those at zero. That’s a useful generic model for a surprising number of real things. Turn up a heater, and the temperature approaches a new value gradually. Apply voltage to a motor and its speed doesn’t change instantaneously. Charge a capacitor through a resistor, and you’ve seen exactly this sort of exponential behavior before.

As the process value rises, the error gets smaller. Because the error gets smaller, the proportional controller reduces its output. This works. At least, mostly.

Watch where it eventually settles. With the suggested values, the process value winds up around 16 even though our setpoint is 20. Why? At a process value of 20, the error would be zero. A proportional controller presented with zero error produces zero output. But this particular process needs an output of 20 to remain at 20. Therefore, it can’t ever quite get there.

This is the classic steady-state error of proportional-only control. We could crank Kp upward. Try Kp=8. The process gets much closer to the setpoint. But continually increasing proportional gain isn’t a universal solution. Eventually real systems start overshooting, oscillating, amplifying noise, or otherwise expressing their displeasure. We need another term.

Remember the Error

Set Kp back to 4 and try:

Ki = 0.5

The integral term looks at not just the error right now, but the error accumulated over time. In the spreadsheet there’s an Integral State column. Each row does approximately this:

integral = previous_integral + error × dt

and the I contribution becomes:

I = Ki × integral

Now consider our P controller sitting stubbornly below the desired value. As long as some positive error remains, the integral keeps growing.

That gradually increases the controller output until the remaining error disappears. Instead of settling around 16, the process now creeps all the way toward 20. This demonstrates one of the major reasons integral control exists: it eliminates persistent offset. It also gives us a good excuse to disturb the system.

Select the user process model and set User Model # to 1. This will let you disturb the process value by entering numbers into the User1 column. Leave the first bit of the User1 column at 0. But somewhere farther down the simulation, put a disturbance into that column — perhaps -5. If you are feeling especially salty, try a sequence like: 0.5, 0.75, 1, 1.5, 2, 1.5, 0.75, 0.5, -1, -1, -0.5. That sequence should already be in the template’s User1 column.
You can imagine that as opening a refrigerator door, suddenly putting a mechanical load on a motor, or connecting another load to a regulated power supply.

A proportional-only controller reacts immediately, but once things settle, it again tolerates a permanent error.

The integral controller doesn’t. If the process remains below the setpoint, integral action continues increasing until the disturbance has been compensated. That’s a powerful trick. Unfortunately, integral control has tricks of its own.

Too Much of a Good Thing

Integral action remembers errors, but memories aren’t always helpful. The derivative term responds to how rapidly the error is changing:

D = Kd × (error - previous_error) / dt

If proportional control asks, “How far away are we?”, derivative control asks, “How fast are we approaching?” Or, more precisely in this case, “How fast is the error changing?”

Make the simulated process faster by changing its time constant from 2 to about 0.8 seconds. Then try something deliberately more aggressive:

Kp = 8
Ki = 1
Kd = 0

The response now gets to the setpoint quickly, but it overshoots it. The problem is easy to see in the spreadsheet. While the process is racing upward, it remains below the setpoint, so the integral continues accumulating positive error. By the time we arrive at the destination, the integral term is still pushing. Depending on the process and gains, the result may be a little overshoot, a lot of overshoot, or sustained oscillation.

Since the default plant is only first-order, derivative action doesn’t have much to work with. User Model 2 adds another lag, using the USER2 column as an intermediate process state. That produces more phase lag and makes aggressive PI tuning more prone to overshoot.

Switch to User Model 2 and start with Kd=0. Then note the peak process value. Then try Kd=0.2, 0.5, and perhaps 1.0. Try some negative values. You will find that there is a range where the peak overshoot is reduced slightly, but keep going and the response starts to ring. Push Kd far enough, and the derivative term becomes part of the problem rather than part of the cure. The graphs autoscale, so sometimes what looks like a peak the same size (or even bigger) is really smaller than the previous result. Be sure to read the numbers.

That’s the basic PID balancing act. P reacts to the error that exists now. I reacts to error that has existed for a while. D reacts to where the error appears to be heading. Put all three together, and you have a controller that may respond strongly, eliminate steady-state error, and anticipate rapid changes. However, sometimes you are better off with, for example, just PI or even just pure proportional control. Having the algorithm in a spreadsheet form is a nice way to experiment, especially if you can model the system’s behavior.

It’s Only a Spreadsheet

You can add your own models by modifying USR_PROCESS to call your function or just modify one of the existing ones. DEF_PROCESS is just a simple lag model. USR_PROCESS0 has some random noise, while USR_PROCESS1 lets you inject a disturbance in the USER1 column. USR_PROCESS2 is like USR_PROCESS1 but has a second-order process in the USER2 column as well. Of course, real control systems are messier than these nice models.

The output may have hard limits. In fact, the spreadsheet includes minimum and maximum output clamps. This exposes another classic PID problem: integral windup. If the controller desperately requests an output of 150 but the actuator can only deliver 100, the integral can continue accumulating error even though the actuator cannot respond. When the error finally reverses, all of that stored integral has to unwind. Practical controllers frequently include anti-windup schemes to deal with this. In practical terms, imagine a thermistor gets unplugged, and the system suddenly thinks there is a giant temperature error. It will try to correct it, but it can’t. Then someone plugs the sensor back in. All the accumulated error in the integral term now has to be backed off.

Derivative action causes its own problems. The spreadsheet calculates derivative from the error, which means suddenly changing the setpoint produces a large derivative pulse — the notorious derivative kick. Real controllers often calculate derivative from the process value instead.

Of course, real measurements also contain noise. Differentiation is very good at making high-frequency noise more prominent, so the D term is commonly filtered. We aren’t doing any of those sophisticated things here, and that’s intentional. The point of the sheet is that every number is visible and to make it easy to experiment.

Change a setpoint in the middle of the Setpoint column, and you’ve generated a step input. Change one of the User columns, and you can inject a disturbance. Adjust Kp, Ki, or Kd, and you can immediately see which portions of the controller output changed and why.

To add your own models, modify USR_PROCESS and add a custom function to the SWITCH statement. Then create your custom function. If you need to grab data from the spreadsheet, you’ll see examples of using ROW() and INDIRECT() to get the right numbers. It is fairly straightforward to add motors, thermal systems, second-order plants, dead time, nonlinearities, or whatever other pathological system you’d like to inflict on your controller.

The most important lesson about PID control? There isn’t a magic set of Kp, Ki, and Kd values. A set of gains that works beautifully on one plant may be terrible on another. Change the mass, thermal capacity, load, delay, sample rate, actuator limits, or sensor characteristics and the optimum controller changes with it. Not every control job needs all three terms.

The equations fit comfortably into a few spreadsheet cells. The interesting part is figuring out what numbers to put in them.

Most of our spreadsheet hijinks center around DSP. Except for the ones that simulate computers.

Back in the late 90s, Apple was definitely a pretty fruity company, with its aggressively translucent shades of colored plastic that often got described in terms of such fruit variants. Although the iMac steals a lot of the glory here, the Power Mac series and associated hardware deserves that spot in the limelight as well. Recently [Dan Wood] put together a full Power Mac G3-based setup, including the appropriate LCD monitor and other peripherals as someone with some serious disposable income back in 1999 might have owned.

Part of Steve Jobs’ return to Apple, the Power Macintosh G3 debuted first in basically recycled beige enclosures from previous Macintosh systems before its second generation introduced the Blue and White version, as it was officially called. This dazzling style was carried through in the peripherals, with pin stripes, translucent plastic and a distinct absence of sharp corners or edges.

As for what you get in these colorful Power Mac G3s, a 300 to 450 MHz CPU, an official memory limit of 192 MB and perhaps the most user-friendly way to access the logic board to upgrade and install components with the folding lid. Something which had PC users with sharp edged cases and plentiful blood sacrifices to the PC gods somewhat steaming in jealousy.

For the time these Power Mac G3s didn’t just look fetching, they also were quite powerful. Something which came at a pretty hefty price tag, of course. The 400 MHz model that [Dan] got his paws on would have cost around $2,000 back in 1999, or closer to $4,000 clams today. The active-matrix TFT LCD screen would have been cutting edge as well, with a similar cutting edge price tag.

Released before OS X this system runs Mac OS 8.6, though it can run OS X 10.4 (Tiger) which unlocks more software options and of course the transition to a proper multi-tasking OS. This particular system was apparently used for graphics design until 2010 based on the files on the HDD. As demonstrated in the video, the system is still quite usable, even in 2026, thanks to all the software available online.

Everyone talks about the weather. This is doubly true for sailors, where bad weather could mean a very bad day. So it isn’t surprising that navies around the world have had a keen interest in weather forecasting. But how did you predict the weather before modern instruments, radar, and satellite images? Vice Admiral Robert FitzRoy had great faith in “storm glasses,” a glass chamber containing some chemicals that he didn’t invent, but did document and promote heavily during the 1860s.

Did it work? Apparently not, but the device is still interesting in its own right. FitzRoy was a pioneer of meteorology, replacing folklore with actual observations and attempts at scientific rigor. While he did arm observation stations with conventional things like thermometers and barometers, he was also a proponent of the weather glass.

What is it?

The glass itself was a sealed glass vessel, often a tube, that contained a mixture of alcohol and water. In that mixture were camphor, saltpeter, and sal ammoniac.

The camphor will precipitate out or dissolve into the solvent, forming amazing crystal patterns. According to FitzRoy, the liquid will be clear if the weather is clear, and cloudy if it is cloudy outside. Different sizes of particulates indicate rain, snow, and other weather phenomena. FitzRoy thought the wind had “electrical tension” and that was responsible for the device’s ability to predict weather.

Scientific studies showed little correlation between the state of the glass and the weather. However, it is still a great conversation piece.

Despite the salts in the recipe, the spectacular crystals in a storm glass are primarily camphor. Camphor dissolves readily in alcohol but poorly in water, while potassium nitrate (saltpeter) and ammonium chloride (sal ammoniac) have roughly the opposite preference. The mixed alcohol-water solvent accommodates all three, but the camphor sits close enough to its solubility limit that temperature changes cause it to crystallize and redissolve. The salts appear to affect the form of the growing crystals, helping produce the elaborate dendritic structures that make the glass look so dramatic.

Maybe it Works?

FitzRoy was convinced the glass was effective. However, in 1863, Charles Tomlinson wrote in The Philosophical Magazine that the instrument was little more than a crude thermometer. This was later suggested in a 2008 article, as well.

Proponents of the glass will tell you that they need to be placed very carefully, out of climate-controlled areas. They also, apparently, say you have to initially heat the liquid until the crystals are totally dissolved. After a few weeks to adapt, they swear the Storm Glass is a perfectly good weather prediction system.

Despite their unreliable nature, the storm glass was a popular item, and you can even find them today, more as decor. But in 1863, you could find a variety of choices with and without thermometers attached, as you can see in the James J. Hicks catalog page.

Before the Glass

Of course, people were interested in the weather well before the late 19th century. Even FitzRoy admitted that the storm glass was at least 100 years old by his day. The game changer was the electric telegraph.

The telegraph allowed for widespread real-time observations. FitzRoy was a pioneer in that game, as was his mentor Sir Francis Beaufort, famous for developing the Wind Force Scale, sometimes known as the Beaufort scale. If you read his writings, he was, for the most part, on the right track for weather observations. But the storm glass that is most closely associated with his name wasn’t really the thing you wanted to be remembered for.

You can make your own storm glass, as you can see in [NightHawkInLight’s] video below. Maybe you can determine whether it really works. Or take your weather station into the modern era.

Featured image: Baromètre de Fitroy ou ou verre-de-tempêtes by [Anja]