Like Chording But Not

February 17, 2023 by Dave Rowntree 3 Comments

Repetitive strain injuries (RSI) can be a real pain. You’ve got a shiny new laptop, and everything’s going smoothly, but suddenly you can’t use it without agonizing (as in typing-speed reducing) pain caused by years of keyboard bashing or just plain bad posture. All of us hacker types will likely have or will experience this at some point, and luckily there are many potential solutions.

[Zihao Wang] writes to show us kseqi, another chord-like textual input method, with a focus on the input sequences, as opposed to any particular mechanical arrangement of keys. The idea is to make use of two sets of independent inputs, where the sequence of actuation codes for the keystrokes to be emitted into the application.

Left-hand-first to select a column of the left character set. Right-hand-first selects the other set.

An example interface would be to arrange two sets of five keys as the input mechanism. One can arrange characters in a matrix. The left key is pressed and held first which selects a column (1 out of 5) then the right key is pressed to select a row, and thus a character. Next, you release in the same order, left, then right, to send the character.

Swapping left and right allows a different set of characters. In this simple scheme, fifty characters can be coded. Check out this web assembly demo for how this operates. Swapping out the physical inputs for a pair of joysticks is another option, which may be better for some folks with specific physical difficulties, or maybe because it just looks fun. As [Zihao] mentions in the write-up, the sequence order can be changed to code for other character sets, so this simple scheme can handle many more character codings than this simple example. All you have to do is remember them. Interested parties may want also wish to dig into the kseqi Rust crate for information.

Chorded keyboard projects are plentiful out there, here’s a nice Bluetooth-connected keeb, and another one that’s all wiggly.

Continue reading “Like Chording But Not” →

Ploopy Builds Open Source RP2040-Powered Headphones And You Can Too!

February 15, 2023 by Dave Rowntree 16 Comments

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 I²S 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.

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.

OpenSPICE: A Portable Python Circuit Simulator

February 14, 2023 by Dave Rowntree 22 Comments

[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!

Continue reading “OpenSPICE: A Portable Python Circuit Simulator” →

Parametric Press Unravels The JPEG Format

February 14, 2023 by Dave Rowntree 5 Comments

This is the first we’ve heard of Parametric Press — a digital magazine with some deep dives into a variety of subjects (such as particle physics, “big data” and such) that have interactive elements or simulations of various types embedded within each story.

The first one that sprung up in our news feed is a piece by [Omar Shehata] on the humble JPEG image format. In it, he explains the how and why of the JPEG encoding process, allowing the reader to play with the various concepts along the way, in real time, within the browser.

RGB colour-space subsampling doesn’t affect each component to the same degree due to the human eye cone cell response. Also, the chroma components are much less affected than the luminance.

For those not familiar with the format, the first step (which is actually optional) to JPEG encoding is to transform the image from the RGB color space, into a YCbCr (luminance, chrominance) color space. Since the human eye is far more sensitive to luminance (brightness) differences than it is to Cb (chroma relative blueness) and Cr (chroma relative redness) differences, these latter two components can be subsampled by only storing a single value for each, in every 2×2 pixel matrix. JPEG allows other matrix sizes, but 2×2 is the most common.

This sets the scene for the clever bit, that comes next and allows more of that harder-to-perceive chroma information to be discarded. It’s fun to play with the chroma sub-sampling slider and see how the different colours are not equally affected, due to the relative sensitivities of the human eye cone cells.

Next, the three YCbCr components are treated independently to a discrete cosine transform and quantization. This transforms each 8×8 pixel block into 64 discrete spatial frequencies. The JPEG compression level (which you can change) affects how many of the upper-frequency components get discarded, and thus how much of the fine spatial detail gets discarded. This is the main source of JPEG image quality loss. Finally, the compressed blocks are delta encoded, where each subsequent block is coded as the difference from the previous one. Like chroma subsampling, this doesn’t offer any compression on its own but allows the subsequent run-length encoding to be more effective, giving more (lossless) compression. Finally, the whole lot is then Huffman compressed with a unique table stored in the JPEG header. So want to play with JPEGs some more? here’s the GitHub source.

If all of this theoretical stuff is a bit useless to you, perhaps you just want to decode some JPEGs, then here is a speedy library for just that.

An Open Hardware Eurorack Compatible Audio FPGA Front End

February 13, 2023 by Dave Rowntree 4 Comments

[Sebastian Holzapfel] has designed an audio frontend (eurorack-pmod) for FPGA-based audio applications, which is designed to fit into a standard Eurorack enclosure. The project, released under CERN Open-Hardware License V2, is designed in KiCAD using the AK4619VN four-channel audio codec by Asahi Kasei microdevices. (And guess what folks, there’s plenty of those in stock!) Continue reading “An Open Hardware Eurorack Compatible Audio FPGA Front End” →

GhostSCAD: Marrying OpenSCAD And Golang

February 12, 2023 by Dave Rowntree 18 Comments

It’s been at least a couple of months since we’ve seen a different 3D modeling language project, so here’s [Lukasz Janyst] with GhostSCAD: a take on creating OpenSCAD models, using the Go language as the front end, bringing all the delights this modern modular language has to offer (and a few of its own idiosyncrasies.) As [Lukasz] says in the blog, from a programmer’s viewpoint, openSCAD has a number of failings that make it not necessarily hard, just kinda annoying to work with, due to the way the geometry tree works. The OpenSCAD way of working ends up with the programmer requiring knowledge of the internal workings of sub-modules, in order to work at the top level (assembly) which is not an ideal situation from a code reuse perspective.

A programmer would describe this problem as “abstraction leakage” and it doesn’t make modular, reusable coding easy to do without a lot of extra work. [Lukasz] says regarding the example GhostSCAD project, that some parts were modeled in a way that knowledge was needed of some mounting points of sub-modules, but those sub-modules had no way to expose this information to the outside world. GhostSCAD enables the programmer to define parts that expose specific parameters to the world that can be queried, for example, to produce a joining part, or an exploded assembly diagram. These properties can be interpreted without the querying module having any knowledge of the internal structure of the thing it’s working with. GhostSCAD provides a Java3D-like API for defining the geometry tree, which may be familiar to some.

Continue reading “GhostSCAD: Marrying OpenSCAD And Golang” →

Directing Ambient Light For Some Extra Glow

February 11, 2023 by Dave Rowntree 17 Comments

[Yuichiro Morimoto] wanted to create a decorative lamp, one that wasn’t burdened with batteries or wires, but used just the ambient light in the room to create a directed glow effect. Using a coloured circular acrylic sheet, with a special coating (not specified) ambient light impinging on the surface is diffused toward the edge. This centre sheet is embedded in an opalescent sheet, which scatters the light from the center sheet, giving a pleasant glow, kind of akin to a solar corona. An additional diffuser cover sheet on the front covers over the edge to hide it, and further enhance the glow effect.

Details of the ‘special coating’ are scarce, with the coloured sheet described as a condenser plate. This clearly isn’t the same as diffuser plastic, as that cannot be seen through as clearly as some of the photographs show. So we’re a little stumped on this one! Please answer in the comments if you can, ahem, shed some light on this one!

When talking about ambient light, many people will think more along the lines of active lighting, for example, adaptive ambient light around a TV like this hack.

Continue reading “Directing Ambient Light For Some Extra Glow” →