Shielding is crucial for all manner of electronic devices. Whether you want to keep power supply noise out of an audio amplifier, or protect ICBMs against an electromagnetic pulse from a nuclear attack, the basic physics behind shielding remains the same. A Faraday cage or shield will do the trick.
At times, though, it would be desirable to shield and unshield a device at will. A new class of materials known as MXenes may be able to offer just that functionality, with microscopically thin films serving as shields that can be switched on and off at will.
We’ve seen many DIY headphones projects on these fair pages over the years, but not many that are quite as DIY as the Ploopy Headphones. What makes this project interesting is the sheer depth of the construction, with every single part being made from what we might call base materials. Materials such as 3D printer filament, foam and felt, and the usual metallic vitamins.
The electronics are fairly straightforward, with an RP2040 functioning as the USB audio interface and equalizer function. Audio samples are emitted as I2S into a PCM3050 24-bit stereo codec which generates a pair of differential output audio signals. These are then converted from differential to single-ended signals and passed on to the coil drivers. The coil drivers consist of no fewer than eight-paralleled opamps per channel. All of this is powered by the USB-C connection to the host computer. Whilst a kit of parts is available for this, you can make your own if you wish, as the full source (Altium designer needed for tweaks) is available on the Ploopy headphone GitHub.
A pretty ploopy response
Many DIY headphone builds would likely be using off-the-shelf speaker units, with large parts of the ear cups being taken from spare parts kits for commercial offerings. But not the Ploopy. The drivers are constructed from flex PCB coils with a standard TRRS jack on each side. Magnets for these coils to react against are held in a 3D-printed frame that is attached to the outer cover. The coils are aligned with a special jig and bonded to the ‘driver foam’ with some 3M VHB tape.
The ear cups are constructed with some 3D printed rings, foam pieces, and simple woven material. The resonator plates push into the inner side of the cup, and the assembly simply screws to the driver assembly. The incredibly detailed assembly wiki makes it look easy, but we reckon there are a few tricky steps in there to trip the unwary. The headband again consists of printed spring sections, some woven material, and foam with a few metallic vitamins thrown in. That makes it sounds simple, but it isn’t.
On the whole the build looks fantastic, but what does it sound like? The Ploopy team has tested them against a pair of Sennheiser HDRXX giving a broadly comparable response, but we’re no audio experts, and the proof, as always, is in the wearing. This project seems to be the ultimate in audio tweakability, with the punchy RP2040 capable of running six audio filters at the full 48 KHz, 16-bit audio, though, the PCM3050 is capable of more.
Want to build some headphones, but need a Bluetooth interface? We got you covered. Can 3D printed headphones ever compare to the big names? We’ll see.
Jenny did an Ask Hackaday article earlier this month, all about the quest for a cheap computer-based audio mixer. The first attempt didn’t go so well, with a problem that many of us are familiar with: Linux applications really doesn’t like using multiple audio devices at the same time. Jenny ran into this issue, and didn’t come across a way to merge the soundcards in a single application.
I’ve fought this problem for a while, probably 10 years now. My first collision with this was an attempt to record a piano with three mics, using a couple different USB pre-amps. And of course, just like Jenny, I was quickly frustrated by the problem that my recording software would only see one interface at a time. The easy solution is to buy an interface with more channels. The Tascam US-4x4HR is a great four channel input/output audio interface, and the Behringer U-PHORIA line goes all the way up to eight mic pre-amps, expandable to 16 with a second DAC that can send audio over ADAT. But those are semi-pro interfaces, with price tags to match.
But what about Jenny’s idea, of cobbling multiple super cheap interfaces together? Well yes, that’s possible too. I’ll show you how, but first, let’s talk about how we’re going to control this software mixer monster. Yes, you can just use a mouse or keyboard, but the challenge was to build a mixing desk, and to me, that means physical faders and mute buttons. Now, there are pre-built solutions, with the Behringer X-touch being a popular solution. But again, we’re way above the price-point Jenny set for this problem. So, let’s do what we do best here at Hackaday, and build our own. Continue reading “How To Build Jenny’s Budget Mixing Desk”→
There was a time around two decades ago, when the new hotness was taking control of home routers to use as small Linux computers. An echo of this era lives on in the name of the OpenWrt minimal Linux distribution, in reference to the Linksys WRT54G router which started it all. Routers as small computers were displaced by small cheap Linux machines from the likes of Raspberry Pi, and the promise of discarded home network gear doing interesting stuff receded. Now it might just be back, as [Jasper Devreker] shows us an Android TV set-top box from a mobile carrier repurposed as a Linux computer that can even run a desktop environment.
The method starts as you might expect, by identifying a mystery connector as a debug serial port. This outputs all sorts of interesting boot information, but can be dropped into a uBoot shell. From here with a bit of effort the eMMC storage could be dumped, and from that the nature of the machine could be deduced. The CPU is an Amlogic quad core ARM Cortex-A53 SoC, which by a stroke of luck is a target for which an Armbian build is available. From there a Linux installation could be assembled, and even an AFCE desktop.
These boxes are handed out in the hundreds of thousands by home connectivity providers, so there’s value in this type of hack as they become available for experimenters. Perhaps it’s more useful as a small headless Linux machine than as a desktop, but we sense there are more machines to come in this line.
Regardless of the mythical qualities that are all too often attributed to vacuum tubes, they are still components that can be damaged and wear out over time. Much like with transistors and kin, they come with a stack of datasheets, containing various curves detailing their properties and performance. These curves will change as a part ages, and validating these curves can help with debugging a vacuum tube-based circuit. This is where one can either spend an enormous sum on a commercial curve tracer like the Tektronix 570, or build your own, as [Basin Street Design] has done.
A semi-retired electronics design engineer by trade, he has previously covered the development of the curve tracer on Instructables for the version 1 and version 1.1. What this device essentially allows you to do is sweep the connected tube through its input parameter ranges, while observing the resulting curves on an attached (external) oscilloscope. Here a storage oscilloscope (or DSO) is immensely helpful to capture the curves.
In the project pages, the in-depth theory and functioning of the circuitry is explained, along with the schematics and a number of builds. The project has been around since before the VBA tracer which we covered last year, both of which are infinitely more affordable than a genuine Tektronix 570.
[Action Retro] came into an antique Sol-20 computer and argues that it was the first totally integrated computer aimed at consumers that didn’t require you to buy or build some kind of terminal. These are fairly rare, so we appreciated the peek inside that you can see in the video below.
Sure, the Sol-20 wasn’t the very first computer out there in the market. It was, however, one of the first ones that didn’t need anything more exotic than a monitor to have a functional system (and the monitor was included). There were alternatives such as a Xerox Alto or a Wang 2200, but those had price tags that didn’t land them in your home. Even Apple, which would become famous for a turnkey system, was only producing the Apple I at that time. As the video points out, it was complete as long as you could build your own power supply and knew how to interface a keyboard — keeping in mind that keyboards were all wildly different in those days.
[Roman Parise] and [Georgios Is. Detorakis] have created OpenSPICE a fork of the PySpice project, adding a new simulation engine written entirely in Python. This enables the same PySpice simulations to be executed on any platform that runs python (which we reckon is quite a few!) whilst leveraging the full power of the python infrastructure. Since it is a fork — for supported platforms — you can also run your simulations upon Ngspice as well as Xyce, giving options for scaling up to larger systems when required, but importantly without having to recreate your circuit from scratch.
The OpenSPICE simulator first converts the parsed netlist into a set of data structures that represent the equations describing the various parts of the system. These are then in turn passed along the scipy library “optimize.root” function which solves the system, generating a list of branch currents and node voltages. The output of the simulation is a numpy array, which can be further processed and visualized with the mathplotlib library. All pretty standard stuff in python circles. Since this is based upon PySpice, it’s also possible to use KiCAD netlists, so you have a nice way to enter those schematics. We’ve not dug into this much yet, but support for the vast libraries of spice models out there in circulation would be high up on our wish list if it already can’t handle this. This scribe will most definitely be checking this out, as LTSpice whilst good, is a bit of a pain to use and does lack the power of a Python backend!
