We’ve always been a little sad that supercapacitors aren’t marked with a big red S on a yellow background. Nevertheless, [DiodeGoneWild] picked up some large-value supercapacitors and used his interesting homemade oscilloscope to examine how they worked. You can watch what he is up to in his workshop in the video below.
Supercapacitors use special techniques to achieve very high capacitance values. For example, the first unit in the video is a 500 F capacitor. That’s not a typo — not microfarads or even millifarads — a full 500 Farads. With reasonable resistance, it can take a long time to charge 500F, so it is easier to see the behavior, especially with the homemade scope, which probably won’t pick up very fast signals.
For example, A 350 mA charging current takes about an hour to bring the capacitor up to 2.6 V, just under its maximum rating of 2.7 V. Supercapacitors usually have low voltage tolerance. Their high capacity makes them ideal for low-current backup applications where you might not want a rechargeable battery because of weight, heat, or problems with long-term capacity loss.
The real star of the video, though, is the cast of homemade test equipment, including the oscilloscope, a power supply, and a battery analyzer. To be fair, he also has some store-bought test gear, too, and the results seem to match well.
Supercapacitors are one of those things that you don’t need until you do. If you haven’t had a chance to play with them, check out the video or at least watch it to enjoy the homebrew gear. We usually look to [Andreas Spiess] for ESP32 advice, but he knows about supercaps, too. If you really like making as much as you can, you can make your own supercapacitors.
Looking back on what programming used to be like can be a fascinatingly entertaining thing, which is why [Tough Developer] decided to download and try using Turbo C and C++, from version 1.0 to the more recent releases. Borland Turbo C 1.0 is a doozy as it was released in 1987 — two years before the C89 standardization that brought us the much beloved ANSI C that so many of us spent the 90s with. Turbo C++ 1.0 is from 1991, which precedes the standardization of C++ in 1998. This means that both integrated development environments (IDEs) provide a fascinating look at what was on the cutting edge in the late 80s and early 90s.
It wasn’t until version 3.0 that syntax highlighting was added, with the IDE’s focus being mostly on features such as auto-indentation and tool integration. Version 2.0 added breakpoints and further integration with the debugger and other tools, as well as libraries such as the Borland Graphics Interface (BGI). Although even editors like Notepad++ and Vim probably give these old IDEs a run for their money nowadays, they were totally worth the money asked.
Beyond the IDE itself, these also came with language documentation, as in the absence of constant internet access, referencing APIs and syntax was done using dead-tree reference books or online documentation. Here “online” meaning digital documentation that came provided on a CD and which could be referenced from within the IDE.
[Tough Developer] walks the reader through many features of the IDE, which includes running various demos to show off what the environment was capable of and how that in turn influenced contemporary software and games such as Commander Keen in Keen Dreams. While we can’t say that a return to Turbo C is terribly likely for the average Hackaday reader, we do appreciate taking a look back at older languages and development environments — if for no other reason than to appreciate how far things have come since then.
Hackaday readers fit into two broad categories: those who experienced the wild and woolly early days of the Internet, and those who are jealous that they missed it. And it’s safe to say that both groups will get something out of this aggressively Web 1.0 retro experience, courtesy of a server that was actually part of it.
This comes to us via The Serial Port, a virtual museum dedicated to 90s technology, where curators [Mark] and [Ben] managed to find a pair of Cobalt RaQ 3 servers from the late 1990s. The RaQ was the first true “Internet appliance,” designed to be as simple as possible to set up and operate. If you wanted to get your small business online, machines like these were just the ticket. They were designed to be as plug-and-play as possible, and they did a pretty good job of it, at least for the time.
The machines that showed up were quite the worse for the wear, which is understandable given the decades since they were last relevant, but that just makes it all the more fun to get them going again. One didn’t even come close to booting, but the other showed more promise.
The video below is the first of a three-part series, and has a nice introduction to the RaQ and its important place in the early Internet, as well as a peek inside the two machines. That revealed some leaky caps that needed replacement in Part 2; after that minor surgery and a little persuasion, the 300-MHz screamer was ready for a test run. It worked, and The Serial Port put it right to work in Part 3 hosting a gloriously retro home page. Hit the link at the top of the article and enjoy the 90s all over again — the visitor counter, the mixed fonts, the “Under Construction” animated GIF, and the reminder to bookmark this page in your browser, which was probably Netscape Navigator. We love the guestbook, too. But — no marquee?
Nice job, [Mark] and [Ben], and kudos for keeping this little slice of computing history alive.
The Buzzer, also known as UVB-76 or UZB-76, has been a constant companion to anyone with a shortwave radio tuned to 4625 kHz. However, [Ringway Manchester] notes that there is now a second buzzer operating near in frequency to the original. Of course, like all mysterious stations, people try to track their origin. [Ringway] shows some older sites for the Buzzer and the current speculation on the current transmitter locations.
Of course, the real question is why? The buzzing isn’t quite nonstop. There are occasional voice messages. There are also jamming attempts, including one, apparently, by Pac Man.
Some people think the new buzzer is an image, but it doesn’t seem to be the same signal. The theory is that the buzzing is just to keep the frequency clear in case it is needed. However, we wonder if it isn’t something else. Compressed data would sound like noise. Other theories are that the buzzing studies the ionosphere or that it is part of a doomsday system that would launch nuclear missiles. Given that the signal has broken down numerous times, this doesn’t seem likely.
What’s even stranger is that occasional background voices are audible on the signal. That implies that buzzing noise isn’t generated directly into the transmitter but is a device in front of a microphone.
We’ve speculated on the buzzer and the jamming efforts around it before. Not exactly a numbers station, but the same sort of appeal.
It doesn’t matter how you pronounce it, because whichever way you choose to say “GIF” is guaranteed to cheese off about half the people listening. Such is the state of our polarized world, we suppose, but there’s one thing we all can agree on — that a mechanical GIF is a pretty cool thing.
What’s even better about this thing is that [Mitch], aka [Hack Modular], put some very interesting old aircraft hardware to use to make it. He came upon a set of cockpit indicators from a Cold War-era RAF airplane — sorry, “aeroplane” — that used a magnetically driven rack and pinion to swivel a set of prism-shaped pieces to one of three positions. Which of the three symbols displayed depended on which faces were turned toward the pilot; they were highly visible displays that were also satisfyingly clicky.
After a teardown in which [Mitch] briefly discusses the mechanism behind these displays, he set about customizing the graphics. Rather than the boring RAF defaults, he chose three frames from the famous Horse in Motion proto-motion picture by [Eadweard Muybridge]. After attaching vertical strips from each frame to the three sides of each prism, [Mitch] came up with a driver for the display; he could have used a 555, but more fittingly chose series-connected relays to do the job. Capacitors slow down the switching cascade and the frame rate; a rotary switch selects different caps to make the horse appear to be walking, trotting, cantering, or galloping — yes, we know they’re each physically distinct motions, but work with us here.
The whole thing looks — and sounds — great mounted in a nice plastic enclosure. The video below shows it in action, and we find it pretty amazing the amount of information that can be conveyed with just three frames. And we’re surprised we’ve never seen these displays before; they seem like something [Fran Blanche] or [Curious Marc] would love.
We all make things. Sometimes we make things for ourselves, sometimes for the broader hacker community, and sometimes we make things for normal folks. It’s this last category where it gets tricky, and critical. I was reminded of all of this watching Chris Combs’ excellent Supercon 2022 talk on how to make it as an artist.
“But I’m not making art!” I hear you say? About half of Chris’ talk is about how he makes his tech art worry-free for galleries to install, and that essentially means making it normie-proof – making sure it runs as soon as the power is turned on, day in, day out, without hacker intervention, because venues hate having you on site to debug. As Tom joked in the podcast, it’s a little bit like designing for space: it’s a strange environment, you can’t send out repair teams, and it has to have failsafes that make sure it works.
What is striking about the talk is that there is a common core of practices that make our hardware projects more reliable, whatever their destination. Things like having a watchdog that’ll reboot if it goes wrong, designing for modularity whenever possible, building in hanging or mounting options if that’s relevant, and writing up at least a simple, single-page info sheet with everything that you need to know to keep it running. Of course with art, aesthetics matters more than usual. Or does it?
So suppose you’re making a thing for a normal person, that must run without your babysitting. What is the common core of precautionary design steps you take?
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!
There was a time when a digital camera was a surprisingly simple affair whose on-board processor didn’t have much in the way of smarts beyond what was needed to grab an image from the sensor and compress it onto some storage. But as they gained more features, over time cameras acquired all the trappings of a fully-fledged computer in their own right, including full-fat operating systems and the accompanying hackability opportunities.
Fujifilm cameras past 2017 or so run the ThreadX real-time operating system on a variety of ARM SoCs, with an SQLite data store for camera settings and some custom software controlling the camera hardware. The hackability comes through patching firmware updates, and aside from manipulating the built-in scripting language and accessing the SQLite database, can include code execution.