Displays are crucial to modern life; they are literally everywhere. But modern flat-panel LCDs and cheap 7-segment LED displays are, well, a bit boring. When we hackers want to display the progress of time, we want something more interesting, hence the plethora of projects using Nixie tubes and various incantations of edge-lit segmented units. Here is [upir] with their take on the simple edge-lit acrylic 7-segment design, with a great video explanation of all the steps involved.

The idea behind this concept is not new. Older displays of this type used tiny tungsten filament bulbs and complex light paths to direct light to the front of the display. The modern version, however, uses edge-lit panels with a grid of small LEDs beneath each segment, which are concealed within a casing. This design relies on the principle of total internal reflection, created by the contrast in refractive indices of acrylic and air. Light entering the panel from below at an angle greater than 42 degrees from normal is entirely reflected inside the panel. Fortunately, tiny LEDs have a wide dispersion angle, so if they are positioned close enough to the edge, they can guide sufficient light into the panel. Once this setup is in place, the surface can be etched or engraved using a CNC machine or a laser cutter. A rough surface texture is vital for this process, as it disrupts some of the light paths, scattering and directing some of it sideways to the viewer. Finally, to create your display, design enough parallel-stacked sheets for each segment of the display—seven in this case, but you could add more, such as an eighth for a decimal point.

How you arrange your lighting is up to you, but [upir] uses an off-the-shelf ESP32-S3 addressable LED array. This design has a few shortcomings, but it is a great start—if a little overkill for a single digit! Using some straightforward Arduino code, one display row is set to white to guide light into a single-segment sheet. To form a complete digital, you illuminate the appropriate combination of sheets. To engrave the sheets, [upir] wanted to use a laser cutter but was put off by the cost. A CNC 3018 was considered, but the choice was bewildering, so they just went with a hand-engraving pick, using a couple of 3D printed stencils as a guide. A sheet holder and light masking arrangement were created in Fusion 360, which was extended into a box to enclose the LED array, which could then be 3D printed.

If you fancy an edge-lit clock (you know you do) check out this one. If wearables are more your thing, there’s also this one. Finally, etched acrylic isn’t anywhere near as good as glass, so if you’ve got a vinyl cutter to hand, this simple method is an option.

[Luizão] wanted to create some hardware to honour the memory of the technology used to put man on the moon and chose the literal core of the project, that of the hardware used to store the software that provided the guidance. We’re talking about the magnetic core rope memory used in the Colossus and Luminary guidance computers. [Luizão] didn’t go totally all out and make a direct copy but instead produced a scaled-down but supersized demo board with just eight cores, each with twelve addressable lines, producing a memory with 96 bits.

The components chosen are all big honking through-hole parts, reminiscent of those available at the time, nicely laid out in an educational context. You could easily show someone how to re-code the memory with only a screwdriver to hand; no microscope is required for this memory. The board was designed in EasyEDA, and is about as simple as possible. Being an AC system, this operates in a continuous wave fashion rather than a pulsed operation mode, as a practical memory would. A clock input drives a large buffer transistor, which pushes current through one of the address wires via a 12-way rotary switch. The cores then act as transformers. If the address wire passes through the core, the signal is passed to the secondary coil, which feeds a simple rectifying amplifier and lights the corresponding LED. Eight such circuits operate in parallel, one per bit. Extending this would be easy.

Obviously, we’ve covered the Apollo program a fair bit. Here’s a fun tale about recovering the guidance software from the real hardware. Like always, the various space programs create new technologies that we mere mortals get to use, such as an auto-dialling telephone.

(video in Brazilian Portuguese)

Have you ever tired of playing with your latest robot invention and wished you could just eat it? Well, that’s exactly what a team of researchers is investigating. There is a fully funded research initiative (not an April Fools’ joke, as far as we know) delving into the possibilities of edible electronics and mechanical systems used in robotics. The team, led by EPFL in Switzerland, combines food process engineering, printed and molecular electronics, and soft robotics to create fully functional and practical robots that can be consumed at the end of their lifespan. While the concept of food-based robots may seem unusual, the potential applications in medicine and reducing waste during food delivery are significant driving factors behind this idea.

The Robofood project (some articles are paywalled!) has clearly made some inroads into the many components needed. Take, for example, batteries. Normally, ingesting a battery would result in a trip to the emergency room, but an edible battery can be made from an anode of riboflavin (found in almonds and egg whites) and a cathode of quercetin, as we covered a while ago. The team proposed another battery using activated charcoal (AC) electrodes on a gelatin substrate. Water is split into its constituent oxygen and hydrogen by applying a voltage to the structure. These gasses adsorb into the AC surface and later recombine back into the water, providing a usable one-volt output for ten minutes with a similar charge time. This simple structure is reusable and, once expired, dissolves harmlessly in (simulated) gastric fluid in twenty minutes. Such a device could potentially power a GI-tract exploratory robot or other sensor devices.

But what use is power without control? (as some car tyre advert once said) Microfluidic control circuits can be created using a stack of edible materials, primarily oleogels, like ethyl cellulose, mixed with an organic oil such as olive oil. A microfluidic NOT gate combines a pressure-controlled switch with a fluid resistor as the ‘pull-up’. The switch has a horizontal flow channel with a blockage that is cleared when a control pressure is applied. As every electronic engineer knows, once you have a controlled switch and a resistor, you can build NOT gates and all the other logic functions, flip-flops, and memories. Although they are very slow, the control components are importantly edible.

Edible electronics don’t feature here often, but we did dig up this simple edible chocolate bunny that screams when you bite it. Who wouldn’t want one of those?

Tiny Tapout is an interesting project, leveraging the power of cloud computing and collaborative purchasing to make the mysterious art of IC design more accessible for hardware hackers. [Yeo Kheng Meng] is one such hacker, and they have produced their very first custom IC for use with their retrocomputing efforts. As they lament, they left it a little late for the shuttle run submission deadline, so they came up with a very simple project with the equivalent behaviour of the Covox Speech Thing, which is just a basic R-2R ladder DAC hanging from a PC parallel port.

The plan was to capture an 8-bit input bus and compare it against a free-running counter. If the input value is larger than the counter, the output goes high; otherwise, it goes low. This produces a PWM waveform representing the input value. Following the digital output with an RC low-pass filter will generate an analogue representation. It’s all very simple stuff. A few details to contend with are specific to Tiny Tapout, such as taking note of the enable and global resets. These are passed down from the chip-level wrapper to indicate when your design has control of the physical IOs and is selected for operation. [Yeo] noticed that the GitHub post-synthesis simulation failed due to not taking note of the reset condition and initialising those pesky flip-flops.

After throwing the design down onto a Mimas A7 Artix 7 FPGA board for a quick test, data sent from a parallel port-connected PC popped out as a PWM waveform as expected, and some test audio could be played. Whilst it may be true that you don’t have to prototype on an FPGA, and some would argue that it’s a lot of extra effort for many cases, without a good quality graphical simulation and robust testbench, you’re practically working blind. And that’s not how working chips get made.

If you want to read into Tiny Tapeout some more, then we’ve a quick guide for that. Or, perhaps hear it direct from the team instead?

Craig Lindley is a technical author and a prolific maker of things. This simple project was his first attempt to create a laser harp MIDI device. While on vacation, Craig saw a laser harp with only three strings and decided to improve upon it by expanding it to twelve strings. The principle of operation is straightforward: twelve cheap diode laser modules aim a beam towards an LDR, which changes resistance if the light level changes when the beam is interrupted.

The controller is a simple piece of perf board, with a Wemos D1 mini ESP32 module flanked by some passives, a barrel socket for power, and the usual DIN connector for connecting the MIDI instrument. Using the ESP32 is a smart choice, removing all the need for configuration and user indication from the physical domain and pushing it onto a rarely-needed webpage. After a false start, attempting to use a triangular frame arrangement, [Craig] settled upon a simple linear arrangement of beams held within a laser-cut wooden box frame. Since these laser modules are quite small, some aluminium rod was machined to make some simple housings to push them into, making them easier to mount in the frame and keeping them nicely aligned with their corresponding LDR.

Sadly, the magnetic attachment method [Craig] used to keep the LDRs in place and aligned with the laser didn’t work as expected, so it was necessary to reach for the hot glue. We’ve all done that!

An interesting addition was using an M5 stack Unit-Synth module for those times when a proper MIDI synthesiser was unavailable. Making this luggable was smart, as people are always fascinated with laser harps. That simple internal synth makes travelling to shows and events a little easier.

Laser harps are nothing new here; we have covered plenty over the years. Like this nice build, which is more a piece of art than an instrument, one which looks just like a real harp and sounds like one, too, due to the use of the Karplus-Strong algorithm to mimic string vibrations.

[Simon B] enters our 2024 Business Card Challenge with BAUDI/O, a genuinely useful audio output device. The device is based around the PCM2706 DAC, which handles all the USB interfacing and audio stack for you, needing only a reference crystal and the usual sprinkling of passives. This isn’t just a DAC board, though; it’s more of an audio experimentation tool with two microcontrollers to play with.

The first ATTiny AT1614 is hooked up to a simple LED vu-meter, and the second is connected to the onboard AD5252 digipot, which together allows one to custom program the response to the digital inputs to suit the user. The power supply is taken from the USB connection. A pair of ganged LM2663 charge-pump inverters allow inversion of the 5V rail to provide the necessary -5 V for the output amplifiers.  This is then fed to the LM4562-based CMoy-type headphone amplifier.  This design has a few extra stages, so with a bit of soldering, you can adjust the output filtering to suit. An LM1117 derives 3.3 V from the USB input to provide another power rail,  mostly for the DAC.

There’s not much more to say other than this is a nice, clean audio design, with everything broken out so you can tinker with it and get exactly the audio experience you want.

The Marimbatron is [Leo Kuipers] ‘s final project as part of the Fab Academy program supervised by [Prof. Neil Gershenfeld] of MIT’s Center for Bits and Atoms. The course aims to teach students how to leverage all the fab lab skills to create unique prototypes using the materials at hand.

Fortunately, one of the main topics covered in the course is documentation, and [Leo] has provided ample material for review. The marimba consists of a horizontal series of wooden bars, each mounted over a metal resonator tube. It is played similarly to the xylophone, with a piano-type note arrangement, covering about five octaves but with a lower range than the xylophone. [Leo] converted this piano-type layout into a more logical grid arrangement. The individual pads are 3D printed in PETG and attached to a DIY piezoresistive pressure sensor made from a graphite-sprayed PET sheet laid upon a DIY flexible PCB. A central addressable LED was also included for indication purposes. The base layer is made of cast polyurethane, formed inside a 3D-printed rigid mould. This absorbs impact and prevents crosstalk to nearby sensors. The sensor PCB was initially prototyped by adhering a layer of copper tape to a layer of Kapton tape and cutting it out using a desktop vinyl cutter. While this method worked for the proof of concept, [Leo] ultimately outsourced the final version to a PCB manufacturer. The description of prototyping the sensor and dealing with over-moulding was particularly fascinating.

For the electronics, a modular approach was needed. Each row of ten sensors was daisy-chained to connect the LEDs, with an individual sense line passed down for each sensor to a common sensor PCB. This uses a SAMD21-series microcontroller with enough ADC channels to handle the task. This was initially prototyped using a micro-milled PCB and a laser-cut PET solder stencil. Once that was proven to work well, the sensible thing was done, and the final PCBs were ordered from a proper fab. Additionally, a user interface PCB was created to host a few pushbuttons and a Waveshare round LCD display. Finally, a main control PCB routes I²C to the sensor boards and interfaces to the SPI LCD. It also handles sending MIDI data over USB for playback on an external MIDI device.

Documentation and design data can both be found on the project fabcloud page. To dig into the Fab Academy courses, wander over to the course archive and get cracking.

This is the first marimba we’ve covered, so here’s a mechanical xylophone instead. Whilst we’re on the subject of mechanical music, here’s a fun one to go back over.

We touched on the open source SLS4All DIY SLS 3D printer a year or two ago when the project was in the early stages. Finally, version one is complete, with a parts kit ready to ship and all design data ready for download if a DIY build or derivative is your style. As some already mentioned, this is not going to be cheap: with the full parts kit running at an eye-watering $7K before tax. But it’s possible to build or source almost all of it a bit at a time for those on a budget.

It’s important to note that to access the detailed information, you’ll need to create an account, which is a bit inconvenient for an open source design. However, all the essential components seem to be available, so it’s forgivable. In terms of electronics, there are two custom PCBs: the GATE1 (GAlvo and Temperature Control) and the ZERO1 (Zero-crossing dimming) controller. Other than that, all the electronics seem to be standard off-the-shelf components. Both of these PCBs are designed using EasyEDA.

Unfortunately we couldn’t find access to the PCB Gerbers, nor does there appear to be a link to their respective EasyEDA projects, just the reference schematics. This is a bit of a drawback, but it’s something that could easily be reproduced with enough motivation. Control is courtesy of a Radxa Rock Pi, as there were ‘problems’ with a Raspberry Pi. This is paired with a 7-inch touchscreen to complete the UI. This is running a highly modified version of the Klipper together with their own control software, which is still undergoing testing before release.

The laser head is built around a 10 W 450 nm laser module from China and a high-end galvanometer set. Two 200 W halogen tube heaters heat the print bed, and 200 W silicone heating pads heat both the powder bed and the print bed.

The upper and lower frames are basic boxes made from 2020 profile aluminium extrusions, with aluminium sheets for the panels. There are no big surprises here. As expected, numerous custom-made aluminium parts are involved, and this is where most of the cost lies. This might be a significant challenge for those who don’t have access to a CNC milling machine. The mechanics can be viewed in-browser via Fusion 360 Live or downloaded as a STEP model for later import.

We last checked in on this project back in 2022, and we’re glad to see it finally cross the finish line. Is this the first open source SLS printer? Of course not! But we’re always glad to see more options out there.

We take easy communications for granted these days. It’s no bother to turn on a lightbulb remotely via a radio link or sense the water level in your petunias, but how does a drilling rig sense data from the drill head whilst deep underground, below the sea bed? The answer is with mud pulse telemetry, about which a group of researchers have produced a study, specifically about modelling the signal impairments and strategies for maintaining the data rate and improving the signal quality.

If you’re still confused, mud pulse telemetry (MPT) works by sending a modulated pressure wave vertically through the column of mud inside the drilling tube. It’s essential to obtain real-time data during drilling operations on the exact angle and direction the drill bit is pointing (so it can be corrected) and details of geological formations so decisions can be made promptly. The goal is to reduce drilling time and, therefore, costs and minimize environmental impact — although some would strongly argue about that last point.

One challenge with MPT is that the transmission media can be inconsistent. It may contain rocks and gas, leading to variations in physical properties like density, compressibility, and viscosity throughout the column, which can affect signal transmissibility. The MPT system includes a pressure transducer at the drill head that encodes data about local parameters such as temperature and pressure. The paper also describes other sources of noise that can distort the signal, including vibrations from the drill head and pressure pulses from the drilling mud pumps.

From what we can gather the MPT system is bidirectional, using mechanical means via ‘poppet valves’ to create positive or negative pressure pulses and a rotating slotted disk to generate continuous waves. It’s possible to achieve a data rate of 20 bps from depths of over 6 km. The paper also discusses other data transmission methods as part of the logging-while-drilling (LWD) system, some of which are used alongside MPT in specific circumstances. All of these methods face challenges when transmitting data through this complex medium.

We couldn’t find much on Hackaday about this topic, but we did recall an interesting piece about dealing with oil spills and who could forget this one about fracking?

Thanks to [Derek] for the tip!

The featured image is courtesy of Dynamic Graphics, Inc.

Many hackers have familiar sayings in their heads, such as “If it ain’t broke, don’t fix it” and KISS (Keep it simple, stupid). Those of us who have been in the field for some time have habits that are hard to break. When it comes to personal networks, simplicity is key, and the idea of transitioning from IPv4 to IPv6 addresses seems crazy. However, with the increasing number of ‘smart’ devices, streaming media gadgets, and personal phones, finding IPv4 space for our IoT experiments is becoming difficult. Is it time to consider embracing IPv6?

The linked GitHub Gist by [timothyham] summarizes the essential concepts for home network admins to understand before making changes. The first major point is that IPv6 has a vastly larger address space than IPv4, eliminating the need to find spare IPv4 addresses. IPv6 assigns multiple addresses to the same interface. The 128-bit addresses are split into a 64-bit prefix assigned by your ISP and a 64-bit interface identifier. Using SLAAC (Stateless Address Autoconfiguration), clients can manage their own addresses. You don’t have to use SLAAC, but it will make life easier. The suffix typically remains static, allowing integration with a local DNS server.

Another major concept concerns routing. IPv6 uses RA (Router Advertisement) instead of DHCP for address assignment. Local clients receive a globally routable prefix, meaning each device can communicate directly over the Internet without needing an intermediate WAN IP address like in the IPv4 system. However, a stateful firewall is still necessary for security.

Finally, we will assign another address to the local clients that need to communicate with each other; this is the ULA (Unique local address), which is the address given to your internal devices, such as printers, media servers, and your pile of IoT gadgets. You can grab a ULA prefix from a website such as this one, to generate a unique locally routable IPv6 prefix, then assign this to your clients and let them autoconfigure the suffix part. This new ULA is assigned to your local DNS server. So, it’s a lot of work, but with IPv4 running on borrowed time, we might be forced to switch eventually, and it’s better to have a head start, eh?

Need convincing that there really is an IPv4 addressing problem? Well, this side of the pond, we ran out already. In case this is all too serious for you, we discovered a hack from a few years ago that seriously abuses the IPv6 address space. Go check this out!

Header: Raysonho @ Open Grid Scheduler / Grid Engine, CC0.

Many people have been attracted to the low price and big dreams of the CNC3018 desktop CNC router. If you’re quick, you can pick one up on the usual second-hand sales sites with little wear and tear for a steal. They’re not perfect machines by any stretch of the imagination, but they can be improved upon, and undoubtedly useful so long as you keep your expectations realistic.

[ForOurGood] has set about such an improvement process and documented their journey in a whopping eight-part (so far!) video series. The video linked below is the most recent in the series and is dedicated to creating a brushless spindle motor on a budget.

As you would expect from such a machine, you get exactly what you pay for.  The low cost translates to thinner than ideal metal plates, aluminium where steel would be better, lower-duty linear rails, and wimpy lead screws. The spindle also suffers from cost-cutting, as does the size of the stepper motors. But for the price, all is forgiven. The fact that they can even turn a profit on these machines shows the manufacturing prowess of the Chinese factories.

We covered the CNC 3018 a while back, and the comments of that post are a true gold mine for those wanting to try desktop CNC. Warning, though: It’s a fair bit harder to master than 3D printing!

Thanks to [Thomas] for the tip!

With the performance of modern CPU cores plateauing recently, the main performance gains are with multiple cores and multithreaded applications. Typically, a fast GPU is only so mind-bogglingly quick because thousands of cores operate in parallel on the same set of tasks. So, it would seem prudent for our applications to try to code in a multithreaded fashion to take advantage of this parallelism. Or so it would seem, but as [Marc Brooker] illustrates, it’s not as simple as one would assume, and it’s very easy to end up with far worse overall performance and no easy way to fix it.

[Marc] was rerunning an old experiment to calculate the expected number of birthdays in a shared group of people using brute force. The experiment was essentially a tight loop running a pseudorandom number generator, the standard libc rand() function. [Marc] profiled the code for single-thread and multithreaded versions and noted the runtime dramatically increased beyond two threads. Something fishy was going on. Running perf, [Marc] noted that there were significant L1 cache misses, but the real killer for performance was the increase in expensive context switches.  Perf indicated that for four threads, the was an overhead of nearly 50% servicing spin locks. There were no locks in the code, so after more perf magic, the syscalls taking all the time were identified.  Something in there was using a futex (or fast userspace mutex) a whole lot.

After delving into the glibc source code, a comment said it all:

/* POSIX.1c requires that there is mutual exclusion for the `rand' and
`srand' functions to prevent concurrent calls from modifying common
data. */

__libc_lock_lock (lock);
 (void) __random_r (&unsafe_state, &retval);
 __libc_lock_unlock (lock);

By replacing the call to rand() with random_r(), the program’s performance with four threads improved dramatically. The runtime was reduced to a theoretical quarter of the single-thread version. As Marc summarizes, multi-threaded programming is not always as straightforward as one might think. While performance can be significantly worse in some cases, improvements are possible. However, this is not guaranteed to be the case in every situation.

The art of debugging and profiling code is complex, so here’s how to use Valgrind to look for problems you might not even know about. Even the humble Linux pipe needs to be thought out to get decent performance. What a surprise!

Sometimes, startups fail due to technical problems or a lack of interest from potential investors and fail to gain development traction. This latter case appears to be the issue befalling A³ Audio. So, the developers have done the next best thing, made the project open source, and are actively looking for more people to pitch in. So what is it? The project is centered around the idea of spatial audio or 3D audio. The system allows ‘audio motion’ to be captured, mixed and replayed, all the while synchronized to the music. At least that’s as much as we can figure out from the documentation!

The system is made up of three main pieces of hardware. The first part is the core (or server), which is essentially a Linux PC running an OSC (Open Sound Control) server. The second part is a ‘motion sampler’, which inputs motion into the server. Lastly, there is a Mixer, which communicates using the OSC protocol (over Ethernet) to allow pre-mixing of spatial samples and deployment of samples onto the audio outputs. In addition to its core duties, the ‘core’ also manages effects and speaker handling.

The motion module is based around a Raspberry Pi 4 and a Teensy microcontroller, with a 7-inch touchscreen display for user input and oodles of NeoPixels for blinky feedback on the button matrix. The mixer module seems simpler, using just a Teensy for interfacing the UI components.

We don’t see many 3D audio projects, but this neat implementation of a beam-forming microphone phased array sure looks interesting.

YouTuber My Developer Thoughts, a self-confessed middle-aged Software Developer, clearly has a real soft spot for the 6502-based 8-bit era machines such as the Commodore 64 and the VIC-20, for which he has created several video tutorials while travelling through retro-computing. This latest instalment concerns bringing up the toolchain for using the Kick Assembler with VS Code to target the C64, initially via the VICE emulator.

The video offers a comprehensive tutorial on setting up the toolchain on Windows from scratch with minimal knowledge. While some may consider this level of guidance unnecessary, it is extremely helpful for those who wish to get started with a few examples quickly and don’t have the time to go through multiple manuals and Wikis. In that regard, the video does an excellent job.

VS Code is a great tool with a large user base, so it’s not surprising that there’s a plugin for using the Kick Assembler directly from the IDE. You can also easily launch the application onto the emulator with just a push of a button, allowing you to focus on learning and working on your application. Once it runs under emulation, there’s a learning curve for running it on native hardware, but there are plenty of tutorials available for that. While you could code directly on the C64 itself, it’s much more pleasant to use modern tools, revision control, and all the conveniences and not have to endure the challenges.

Once you’ve mastered assembly, it may be time to move on to C or even C++. The Oscar64 compiler is a good choice for that. Next, you may want to show off your new skills on the retro demo scene. Here’s a neat C64 demo with a twist. There is no C64.

Thanks to [Stephen] for the tip!