Presenter holds an induction lamp bulb

An Induction Lamp Made On The Same Principle As Ordinary Fluorescent Lamp

Over on YouTube, [Technology Connections] has a new video: Induction lamps: fluorescent lighting’s final form.

This video is about a wireless fluorescent light which uses induction to transfer power from the electrical system into the lamp. As this lamp doesn’t require wiring it is not prone to “sputtering” as typical fluorescent lights are, thus improving the working life by an order of magnitude. As explained in the video sputtering is the process where the electrodes in a typical fluorescent lamp lose their material over time until they lose their ability to emit electrons at all.

This particular lamp has a power rating of 200 W and light output of 16,000 lumens, which is quite good. But the truly remarkable thing about this type of lighting is its service life. As the lamp is simply a phosphor-coated tube filled with argon gas and a pellet of mercury amalgam it has a theoretically unlimited lifespan. Or let’s call it 23 years.

Given that the service life is so good, why don’t we see induction lamps everywhere? The answer is that the electronics to support them are very expensive, and these days LED lighting has trounced every lighting technology that we’ve ever made in terms of energy efficiency, quality of light, and so on. So induction lamps are obsolete before they ever had their day. Still pretty interesting technology though!

Continue reading “An Induction Lamp Made On The Same Principle As Ordinary Fluorescent Lamp”

Dearest C++, Let Me Count The Ways I Love/Hate Thee

My first encounter with C++ was way back in the 1990s, when it was one of the Real Programming Languages™ that I sometimes heard about as I was still splashing about in the kiddie pool with Visual Basic, PHP and JavaScript. The first formally standardized version of C++ is the ISO 1998 standard, but it had been making headways as a ‘better C’ for decades at that point since Bjarne Stroustrup added that increment operator to C in 1979 and released C++ to the public in 1985.

Why did I pick C++ as my primary programming language? Mainly because it was well supported and with free tooling: a free Borland compiler or g++ on the GCC side. Alternatives like VB, Java, and D felt far too niche compared to established languages, while C++ gave you access to the lingua franca of C while adding many modern features like OOP and a more streamlined syntax in addition to the Standard Template Library (STL) with gobs of useful building blocks.

Years later, as a grizzled senior C++ developer, I have come to embrace the notion that being good at a programming language also means having strong opinions on all that is wrong with the language. True to form, while C++ has many good points, there are still major warts and many heavily neglected aspects that get me and other C++ developers riled up.

Continue reading “Dearest C++, Let Me Count The Ways I Love/Hate Thee”

Hackaday Podcast Episode 328: Benchies, Beanies, And Back To The Future

This week, Hackaday’s Elliot Williams and Kristina Panos joined forces to bring you the latest news, mystery sound, and of course, a big bunch of hacks from the previous week.

In Hackaday news, the One Hertz Challenge ticks on. You have until Tuesday, August 19th to show us what you’ve got, so head over to Hackaday.IO and get started now! In other news, we’ve just wrapped the call for Supercon proposals, so you can probably expect to see tickets for sale fairly soon.

On What’s That Sound, Kristina actually got this one with some prodding. Congratulations to [Alex] who knew exactly what it was and wins a limited edition Hackaday Podcast t-shirt!

After that, it’s on to the hacks and such, beginning with a ridiculously fast Benchy. We take a look at a bunch of awesome 3D prints a PEZ blaster and a cowbell that rings true. Then we explore chisanbop, which is not actually K-Pop for toddlers, as well as a couple of clocks. Finally, we talk a bit about dithering before taking a look at the top tech of 1985 as shown in Back to the Future (1985).

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download in DRM-free MP3 and savor at your leisure.

Continue reading “Hackaday Podcast Episode 328: Benchies, Beanies, And Back To The Future

PlayStation Case Mod Hides Gamer Shame

[Zac] of Zac Builds has a shameful secret: he, a fully grown man, plays video games. Shocking, we know, but such people do exist in our society. After being rightfully laughed out of the family living room, [Zac] relocated his indecent activities to his office, but he knew that was not enough. Someone might enter, might see his secret shame: his PlayStation 5. He decided the only solution was to tear the game console apart, and rebuild it inside of his desk.

All sarcasm aside, it’s hard to argue that [Zac]’s handmade wooden desk doesn’t look better than the stock PS5, even if you’re not one of the people who disliked Sony’s styling this generation. The desk also contains his PC, a project we seem to have somehow missed; the two machines live in adjacent drawers.

While aesthetics are a big motivator behind this case mod, [Zac] also takes the time to improve on Sony’s work: the noisy stock fan is replaced by three silent-running Noctua case fans; the easy-to-confuse power and eject buttons are relocated and differentiated; and the Blu-ray drive gets a proper affordance so he’ll never miss the slot again. An NVMe SSD finishes off the upgrades.

Aside from the woodworking to create the drawer, this project relies mostly on 3D printing for custom mounts and baffles to hold the PS5’s parts and direct airflow where it needs to go. This was made much, much easier for [Zac] via the use of a 3D scanner. If you haven’t used one, this project demonstrates how handy they can be — and also some of the limitations, as the structured-light device (a Creality Raptor) had trouble with the shinier parts of the build. Dealing with that trouble still saved [Zac] a lot of time and effort compared to measuring everything.

While we missed [Zac]’s desk build, we’ve seen his work before: everything from a modernized iPod to wooden sound diffusion panels.

Continue reading “PlayStation Case Mod Hides Gamer Shame”

This Week In Security: Bitchat, CitrixBleed Part 2, Opossum, And TSAs

@jack is back with a weekend project. Yes, that Jack. [Jack Dorsey] spent last weekend learning about Bluetooth meshing, and built Bitchat, a BLE mesh encrypted messaging application. It uses X25519 for key exchange, and AES-GCM for message encryption. [Alex Radocea] took a look at the current state of the project, suspects it was vibe coded, and points out a glaring problem with the cryptography.

So let’s take a quick look at the authentication and encryption layer of Bitchat. The whitepaper is useful, but still leaves out some of the important details, like how the identity key is tied to the encryption keys. The problem here is that it isn’t.

Bitchat has, by necessity, a trust-on-first-use authentication model. There is intentionally no authentication central authority to verify the keys of any given user, and the application hasn’t yet added an out-of-band authentication method, like scanning QR codes. Instead, it has a favorites system, where the user can mark a remote user as a favorite, and the app saves those keys forever. There isn’t necessarily anything wrong with this approach, especially if users understand the limitations.

The other quirk is that Bitchat uses ephemeral keys for each chat session, in an effort to have some forward secrecy. In modern protocols, it’s desirable to have some protection against a single compromised encryption key exposing all the messages in the chain. It appears that Bitchat accomplishes this by generating dedicated encryption keys for each new chat session. But those ephemeral keys aren’t properly verified. In fact, they aren’t verified by a user’s identity key at all!

The attack then, is to send a private message to another user, present the public key of whoever your’re trying to impersonate, and include new ephemeral encryption keys. Even if your target has this remote user marked as a favorite, the new encryption keys are trusted. So the victim thinks this is a conversation with a trusted person, and it’s actually a conversation with an attacker. Not great. Continue reading “This Week In Security: Bitchat, CitrixBleed Part 2, Opossum, And TSAs”

Photo showing the wire-wrapped version and PCB version of MyCPU side-by-side.

This Homebrew CPU Got Its Start In The 1990s

[Sylvain Fortin] recently wrote in to tell us about his Homebrew CPU Project, and the story behind this one is truly remarkable.

He began working on this toy CPU back in 1994, over thirty years ago. After learning about the 74LS181 ALU in college he decided to build his own CPU. He made considerable progress back in the 90s and then shelved the project until the pandemic hit when he picked it back up again and started adding some new features. A little later on, a board house approached him with an offer to cover the production cost if he’d like to redo the wire-wrapped project on a PCB. The resulting KiCad files are in the GitHub repository for anyone who wants to play along at home.

An early prototype on breadboard

The ALU on [Sylvain]’s CPU is a 1-bit ALU which he describes as essentially a selectable gate: OR, XOR, AND, NOT. It requires more clock steps to compute something like an addition, but, he tells us, it’s much more challenging and interesting to manage at the microcode level. On his project page you will find various support software written in C#, such as an op-code assembler and a microcode assembler, among other things.

For debugging [Sylvain] started out with das blinkin LEDs but found them too limiting in short order. He was able to upgrade to a 136 channel Agilent 1670G Benchtop Logic Analyzer which he was fortunate to score for cheap on eBay. You can tell this thing is old from the floppy drive on the front panel but it is rocking 136 channels which is seriously OP.

The PCB version is a great improvement but we were interested in the initial wire-wrapped version too. We asked [Sylvain] for photos of the wire-wrapping and he obliged. There’s just something awesome about a wire-wrapped project, don’t you think? If you’re interested in wire-wrapping check out Wire Wrap 101.

Listen To The Sound Of The Crystals

We’re all used to crystal resonators — they provide pretty accurate frequency references for oscillators with low enough drift for most of our purposes. As the quartz equivalent of a tuning fork, they work by vibrating at their physical resonant frequency, which means that just like a tuning fork, it should be possible to listen to them.

A crystal in the MHz might be difficult to listen to, but for a 32,768 Hz watch crystal it’s possible with a standard microphone and sound card. [SimonArchipoff] has written a piece of software that graphs the frequency of a watch crystal oscillator, to enable small adjustments to be made for timekeeping.

Assuming a microphone and sound card that aren’t too awful, it should be easy enough to listen to the oscillation, so the challenge lies in keeping accurate time. The frequency is compared to the sound card clock which is by no means perfect, but the trick lies in using the operating system clock to calibrate that. This master clock can be measured against online NTP sources, and can thus become a known quantity.

We think of quartz clocks as pretty good, but he points out how little it takes to cause a significant drift over month-scale timings. if your quartz clock’s accuracy is important to you, perhaps you should give it a look. You might need it for your time reference.


Header: Multicherry, CC BY-SA 4.0.