If you’re planning on working satellites or doing any sort of RF work where the signal lives down in the dirt, you’re going to need a low-noise amplifier. That’s typically not a problem, as the market is littered with dozens of cheap options that can be delivered in a day or two — you just pay your money and get to work. But is there a case to be made for rolling your own LNA?

[Salil, aka Nuclearrambo] thinks so, and he did a nice job showing us how it’s done. The first step, as always, is to define your specs, which for [Salil] were pretty modest: a low noise figure, moderate gain, and good linearity. He also wanted a bandpass filter for the 2-meter amateur radio band and for weather satellite downlinks, and a bias-tee to power the LNA over the coax feedline. The blog post has a detailed discussion of the electrical design, plus some good tips on PCB design for RF applications. We also found the discussion on bias-tee design helpful, especially for anyone who has ever struggled with the idea that RF and DC can get along together on a single piece of coax. Part 2 concentrates on testing the LNA, mostly using hobbyist-grade test gear like the NanoVNA and tiny SA spectrum analyzer. [Salil]’s tests showed the LNA lived up to the design specs and more, making it more than ready to put to work with an RTL-SDR.

Was this more work than buying an LNA? Absolutely, and probably with the same results. But then again, what’s to learn by just getting a pre-built module in the mail?

“It was the best of times, it was the blurst of times?” Perhaps not anymore, if this Ig Nobel-worthy analysis of the infinite monkey theorem is to be believed. For the uninitiated, the idea is that if you had an infinite number of monkeys randomly typing on an infinite number of keyboards, eventually the complete works of Shakespeare or some other famous writer would appear. It’s always been meant to be taken figuratively as a demonstration of the power of time and randomness, but some people just can’t leave well enough alone. The research, which we hope was undertaken with tongue firmly planted in cheek, reveals that it would take longer than the amount of time left before the heat death of the universe for either a single monkey or even all 200,000 chimpanzees in the world today to type the 884,647 words of Shakespeare’s complete works in the proper order.

We feel like they missed the point completely, since this is supposed to be about an infinite number of monkeys. But if they insist on sticking with real-world force monkey labor, what would really be interesting is an economic analysis of project. How much space would 200,000 chimps need? What would the energy requirements be in terms of food in and waste out? What about electricity so the monkeys can see what they’re doing? If we’re using typewriters, how much paper do we need, and how much land will be deforested for it? Seems like you’ll need replacement chimps as they age out, so how do you make sure the chimps “mix and mingle,” so to speak? And how do you account for maternity and presumably paternity leave? Also, who’s checking the output? Seems like we’d have to employ humans to do this, so what are the economic factors associated with that? Inquiring minds want to know.

Speaking of ridiculous calculations, when your company racks up a fine that only makes sense in exponential notation, you know we’ve reached new levels of stupidity. But here we are, as a Russian court has imposed a two-undecillion rouble fine on Google for blocking access to Russian state media channels. That’s 2×10³⁶ roubles, or about 2×10³³ US dollars at current exchange rates. If you’re British and think a billion is a million million, then undecillion means something different entirely, but we don’t have the energy to work that out right now. Regardless, it’s a lot, and given that the total GPD of the entire planet was estimated to be about 100×10¹² dollars in 2022, Google better get busy raising the money. We’d prefer they don’t do it the totally-not-evil way they usually do, so it might be best to seek alternate methods. Maybe a bake sale?

A couple of weeks back we sang the praises of SpaceX after they managed to absolutely nail the landing of the Starship Heavy booster after its fifth test flight by managing to pluck it from the air while it floated back to the launch pad. But the amazing engineering success was very close to disaster according to Elon Musk himself, who discussed the details online. Apparently SpaceX engineers shared with him that they were scared about the “spin gas abort” configuration on Heavy prior to launch, and that they were one second away from aborting the “chopsticks” landing in favor of crashing the booster into the ground in front of the launch pad. They also expressed fears about spot welds on a chine on the booster, which actually did rip off during descent and could have fouled on the tower during the catch. But success is a hell of a deodorant, as they say, and it’s hard to argue with how good the landing looked despite the risks.

We saw a couple of interesting stories on humanoid robots this week, including one about a robot with a “human-like gait.” The bot is from China’s EnginAI Robotics and while its gait looks pretty good, there’s still a significant uncanny valley thing going on there, at least for us. And really, what’s the point? Especially when you look at something like this new Atlas demo, which really leans into its inhuman gait to get work done efficiently. You be the judge.

And finally, we’ve always been amazed by Liberty ships, the class of rapidly produced cargo ships produced by the United States to support the British war effort during WWII. Simple in design though they were, the fact that US shipbuilders were able to ramp up production of these vessels to the point where they were building a ship every eight hours has always been fascinating to us. But it’s often true that speed kills, and this video shows the fatal flaw in Liberty ship design that led to the loss of some of the early ships in the class. The short video details the all-welded construction of the ships, a significant advancement at the time but which wasn’t the cause of the hull cracks that led to the loss of some ships. We won’t spoil the story, though. Enjoy.

If you need to measure the temperature of something, chances are good that you could think up half a dozen ways to do it, pretty much all of which would involve some kind of thermometer, thermistor, thermocouple, or other thermo-adjacent device. But what if you need to measure something really hot, hot enough to destroy your instrument? How would you get the job done then?

Should you find yourself in this improbable situation, relax — [Anthony Francis-Jones] has you covered with this calorimetric method for measuring high temperatures. The principle is simple; rather than directly measuring the temperature of the flame, use it to heat up something of known mass and composition and then dunk that object in some water. If you know the amount of water and its temperature before and after, you can figure out how much energy was in the object. From that, you can work backward and calculate the temperature the object must have been at to have that amount of energy.

For the demonstration in the video below, [F-J] dangled a steel ball from a chain into a Bunsen burner flame and dunked it into 150 ml of room-temperature water. After a nice long toasting, the ball went into the drink, raising the temperature by 27 degrees. Knowing the specific heat capacity of water and steel and the mass of each, he worked the numbers and came up with an estimate of about 600°C for the flame. That’s off by a wide margin; typical estimates for a natural gas-powered burner are in the 1,500°C range.

We suspect the main source of error here is not letting the ball and flame come into equilibrium, but no matter — this is mainly intended as a demonstration of calorimetry. It might remind you of bomb calorimetry experiments in high school physics lab, which can also be used to explore human digestive efficiency, if you’re into that sort of thing.

If you’re like us, you’ve got at least one bin dedicated to keeping the random hardware you just can’t bear to part with. In our case it’s mostly populated with the nuts and bolts left over after finishing up a car repair, but however it gets filled, it’s a mess. The degree to which you can tolerate this mess will vary, but for [EmGi], even a moderately untidy pile of bolts was enough to spur this entirely 3D-printed mechanical bolt sorter.

The elements of this machine bear a strong resemblance to a lot of the sorting mechanisms we’ve seen used on automated manufacturing and assembly lines. The process starts with a hopper full of M3 cap head bolts of varying lengths, which are collated by a pair of elevating platforms. These line up the bolts and lift them onto a slotted feed ramp, which lets them dangle by their heads and pushes them into a fixture that moves them through a 90° arc and presents them to a long sorting ramp. The ramp has a series of increasingly longer slots; bolts roll right over the slots until they find the right slot, where they fall into a bin below. Nuts can also feed through the process and get sorted into their own bin.

What we like about [EmGi]’s design is its simplicity. There are no motors, bearings, springs, or other hardware — except for the hardware you’re sorting, of course. The entire machine is manually powered, so you can just grab a handful of hardware and start sorting. True, it can only sort M3 cap head bolts, but we suspect the design could be modified easily for other sizes and styles of fasteners. Check it out in action in the video below.

Just because it’s simple doesn’t mean we don’t like more complicated hardware sorters, like the ones [Christopher Helmke] builds.

Thanks to [john] for the tip.

At this point in the tech dystopia cycle, it’s no surprise that the initial purchase price of a piece of technology is likely not the last payment you’ll make. Almost everything these days needs an ongoing subscription to do whatever you paid for it to do in the first place. It’s ridiculous, especially when all you want to do is charge your electric motorcycle with electricity you already pay for; why in the world would you need a subscription for that?

That was [Maarten]’s question when he picked up a used EVBox wall mount charger, which refused to charge his bike without signing up for a subscription. True, the subscription gave access to all kinds of gee-whiz features, none of which were necessary for the job of topping off the bike’s battery. A teardown revealed a well-built device with separate modules for mains supply and battery charging, plus a communications module with a cellular modem, obviously the bit that’s phoning home and keeping the charger from working without the subscription.

After some time going down dead ends and a futile search for documentation, [Maarten] decided to snoop into the conversation between the charger boards and the comms board, reasonably assuming that if he knew what they were talking about, he’d be able to mimic the commands that make the charger go. He managed to do exactly that, reverse engineering enough of the protocol to do a simple replay attack using a Raspberry Pi. That let him use the charger. Problem solved, right?

Not so fast — this is a “Fail of the Week,” after all. This is where [Maarten] should have called it a day, but he decided to keep poking enough to snatch defeat from the jaws of victory. He discovered that the charging module’s firmware was only doing limited validation of messages coming from the comms module, and since he’d only found fourteen of the commands in the protocol, he thought he’d take advantage of the firmware’s openness to explore all 256 possible commands. Scanning through all the commands proved fatal to the charger, though, bricking the poor thing right after he’d figured everything out. Ouch!

To his credit, [Maarten] was only trying to be complete in his exploration of the protocol, and his intention to make it easier for the next hacker is laudable in the extreme. That he took it a byte too far is unfortunate, but such is the price we sometimes pay for progress. Everything he did is thoroughly documented, so if you’ve got one of these chargers you’ve got all the tools needed to make it a standalone. Just make sure you know when to stop.

We hate to admit it, but whenever we see an article about either Voyager spacecraft, our thoughts immediately turn to worst-case scenarios. One of these days, we’ll be forced to write obituaries for the plucky interstellar travelers, but today is not that day, even with news of yet another issue aboard Voyager 1 that threatens its ability to communicate with Earth.

According to NASA, the current problem began on October 16 when controllers sent a command to turn on one of the spacecraft’s heaters. Voyager 1, nearly a light-day distant from Earth, failed to respond as expected 46 hours later. After some searching, controllers picked up the spacecraft’s X-band downlink signal but at a much lower power than expected. This indicated that the spacecraft had gone into fault protection mode, likely in response to the command to turn on the heater. A day later, Voyager 1 stopped communicating altogether, suggesting that further fault protection trips disabled the powerful X-band transmitter and switched to the lower-powered S-band downlink.

This was potentially mission-ending; the S-band downlink had last been used in 1981 when the probe was still well within the confines of the solar system, and the fear was that the Deep Space Network would not be able to find the weak signal. But find it they did, and on October 22 they sent a command to confirm S-band communications. At this point, controllers can still receive engineering data and command the craft, but it remains to be seen what can be done to restore full communications. They haven’t tried to turn the X-band transmitter back on yet, wisely preferring to further evaluate what caused the fault protection error that kicked this whole thing off before committing to a step like that.

Following Voyager news these days feels a little morbid, like a death watch on an aging celebrity. Here’s hoping that this story turns out to have a happy ending and that we can push the inevitable off for another few years. While we wait, if you want to know a little more about the Voyager comms system, we’ve got a deep dive that should get you going.

Thanks to [Mark Stevens] for the tip.

It probably comes as little surprise that our planet is practically buzzing with radio waves. Most of it is of our own making, with cell phones, microwaves, WiFi, and broadcasts up and down the spectrum whizzing around all the time. But our transmissions aren’t the only RF show in town, as the Earth itself is more than capable of generating radio signals of its own, signals which you can explore with a simple sferics receiver like this one.

If you’ve never heard of sferics and other natural radio phenomena, we have a primer to get you started. Briefly, sferics, short for “atmospherics,” are RF signals in the VLF range generated by the millions of lightning discharges that strike the Earth daily. Tuning into them is a pretty simple proposition, as [DX Explorer]’s receiver demonstrates. His circuit, which is based on a design by [K8TND], is just a single JFET surrounded by a few caps and resistors, plus a simple trap to filter out the strong AM broadcast signals in his area. The output of the RF amplifier goes directly into an audio amp, which could be anything you have handy — but you risk breaking [Elliot]’s heart if you don’t use his beloved LM386.

This is definitely a “nothing fancy” build, with the RF section built ugly style on a scrap of PCB and a simple telescopic whip used for an antenna. Tuning into the Earth’s radio signals does take some care, though. Getting far away from power lines is important, to limit AC interference. [DX Explorer] also found how he held the receiver was important; unless he was touching the ground plane of the receiver, the receiver started self-oscillating. But the pips, crackles, and pings came in loud and clear on his rig; check out the video below for the VLF action.