The ThinkPad 701 is an iconic laptop series from the mid-90s and is still highly sought after today because of its famous butterfly keybaord. The laptop itself is tiny even by the standards of the time, so in order to fit a full-size keyboard IBM devised a mechanism where the keyboard splits and slides over itself to hide away as the screen is closed. But, like most 30-year-old laptops, the original batteries for these computers are well past their prime. [polymatt] takes us through all of the steps needed in order to recreate a battery from this era down to the last detail.
He starts by disassembling an old battery with extensive damage from the old, leaky batteries. The first part of the recreation is to measure the battery casing so a new one can be modeled and printed. The control boards for the batteries of these computers were not too sophisticated, so [polymatt] is able to use a logic analyzer with a working unit to duplicate its behavior on an ATtiny microcontroller. With that out of the way, a new PCB is created to host the cloned chip and a new battery pack, made out of 9 NiMH cells is put together.
[polymatt] wanted this build to be as authentic as possible, so he even goes as far as replicating the label on the underside of the battery. With everything put together he has a faithful recreation of this decades-old battery for a famous retro laptop. ThinkPads are popular laptops in general, too, due to their fairly high build quality (at least for their enterprise lineups) and comprehensive driver support especially for Linux and other open-source software projects like coreboot and libreboot.
Detecting gravity waves isn’t easy. But what if you had a really big detector for a long time? That’s what researchers did when they crunched 15 years’ worth of data from the NANOGrav data set. The data was collected from over 170 radio astronomers measuring millisecond pulsars as a way to potentially detect low-frequency gravity waves.
Millisecond pulsars spin fast and make them ideal for the detection of low-frequency gravity waves, which are difficult to detect. The bulk of the paper is about the high-powered data analysis for a very large data set.
[atomic14] has been interested in wireless power for a while, and while most of the hardware he’s tested over the years has been less than impressive, he demonstrates one that’s able to reliably deliver 5 V at about 1 A which is more than enough to boot a Raspberry Pi W2 into X and launch DOOM. But while that’s neat, he explains that wireless power isn’t quite yet an effortless solution.
For one thing, the hardware he’s using — similar to those used for mobile phone charging — need the receiver to be very close to the transmitter. In addition, they need to be aligned well or efficiency drops off sharply. For mobile phones this isn’t much of a problem, but it’s difficult to position a Raspberry Pi and display just so when one can’t see the coils. Misalignment means brownouts and other unreliable operation.
So while the wireless power is capable of running the Pi directly, [atomic14] attempts to put a small battery and charger circuit into the mix in order to make the whole thing both portable and more reliable. But because nothing is easy, he discovers that his charging board — which should be able to output as low as 4.5 V — isn’t able to be adjusted down any lower than 5.66 V. It turns out that a resistor marked 104 (which should be 100 kΩ) is actually measuring 57 kΩ, and the trim pot doesn’t go lower than 10 kΩ. The solution is a bit of component swapping, but we suppose it’s a reminder that sometimes with cheap parts, one pays in other ways.
You can see [atomic14]’s wireless power Raspberry Pi running the classic shooter in the video below. Wireless power may have its issues, but it’s certainly a lot less messy than running DOOM with a gigantic potato battery.
A good universal remote can help tame today’s complex home entertainment systems, combining both classic IR and more modern WiFi and Bluetooth connectivity with programmable functions that allow the user to execute multi-step operations with a single button. Unfortunately, programming them often involves the use of clunky proprietary software.
Which is why [Maximilian Kern] has developed the OMOTE. This open source universal remote is powered by the ESP32, and features the usual collection of physical buttons in addition to a 2.8” 320 x 240 touchscreen with a responsive graphical interface that can display more advanced user interfaces. Everything is packed into an ergonomic 3D printed case that gives it an exceptionally professional look.
The remote’s USB-C port can be used to recharge the internal 2,000 mAhA battery, as well as reprogram the ESP32’s firmware via a CH340C serial chip. The battery life is estimated to be about six months given the considerable low-power capabilities of the ESP32, which includes the use of a LIS3DH 3-axis accelerometer to keep the hardware in sleep mode until it’s picked up.
The software side is still in development, so the IR codes for the remote are currently hardcoded and its WiFi capabilities are limited to MQTT. But in the future, [Maximilian] imagines a web-based configuration interface that runs on the ESP32 and lets you add codes and setup the remote via your phone or desktop.
It looks like the hardware is more or less complete, so presumably the focus from here on out will be bringing the software across the finish line. Don’t worry, there’s still plenty of time — since it’s an entry into the Gearing Up challenge of the 2023 Hackaday Prize, the judges won’t pick the finalists until August 8th.
One of the things ssh can do is execute a command on a remote server. Most of us expect it to work transparently when doing so, simply passing the command and its arguments on without any surprises in the process. But after 23 years of using OpenSSH on a nearly daily basis, [Martin Kjellstrand] got surprised.
One would reasonably expect the commands figlet foobar bar\ baz and ssh localhost figlet foobar bar\ baz to be functionally equivalent, right? The former ultimately runs the command “figlet” with arguments “foobar” and “bar baz” on the local machine. The second does the same, except with ssh being involved in the middle. As mentioned, one would expect both commands to be functionally identical, but that’s not what happens. What happens is that ssh turns bar\ baz into two distinctly separate command-line arguments in the process of sending it for remote execution: “bar” and “baz”. The result is mystification as the command fails to run the way the user expects, if it runs at all.
What exactly is going on, here? [Martin] goes into considerable detail tracking down this odd behavior and how it happens, but he’s unable to ultimately explain why ssh does things this way. He suspects that it is the result of some design decision taken long ago. Or perhaps a bug that has, over time, been promoted to entrenched quirk.
Do you have any insights or knowledge about this behavior? If so, [Martin] wants to hear about it and so do we, so don’t keep it to yourself! Let us know in the comments, below.
If you read Hackaday long enough, you’ll start to categorize everything. There are the purely technical hacks, beautiful hacks, minimalist hacks, maximalist hacks, and then the straight-up oddball hacks. Sometimes what strikes us is the beauty of the execution. Sometimes it’s clever choice of parts that were designed to do exactly the right thing, and simply watching them do their job well is satisfying, and other times we like to see parts fooled into doing something they have no right to.
While I really like the above speaker build because it’s beautiful, and because it uses a clever choice of audio amplifier to work with the supercapacitors’ wild voltage swings, what really struck me about the project is that [Jamie Matthews] has been using it every day for the last nine months. It’s on his desk and he uses it to listen to music.
That’s a simple feat in a way, but it’s a powerful one. Some of my absolutely favorite projects of my own are similar – they are ones that I use all the time. Not the cliche “life hack”, which are usually like a clever way to peel a grapefruit, but rather hacks that become part of daily life. So look around you, and if you’re anything like me, you’ll find a number of these “daily driver” hacks. And if you do, celebrate them.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
[IMSAI Guy] bought a fake Nixie clock, and luckily for all of us has filmed a very close look and demonstration. Using OLED displays as the fake Nixie elements might seem like cheating to some, the effect is really very well done.
When it comes to Nixie elements, it’s hard to say which gets more attention and project time from hardware folks: original Nixie tube technology, or fake Nixie elements. Either way, their appeal is certainly undeniable.
Authentic Nixie elements require high voltages and are labor-intensive to manufacture to say the least, and as far as fake Nixie elements go, this one looks pretty good once it lights up. You can see it in action in the video, embedded below.