An Improved Spectrometer, No Lasers Required

Here at Hackaday, we love it when someone picks up the ball from a previous project and runs with it. That’s what we’re all about, really — putting out cool projects that just might stimulate someone else to extend and enhance it, or even head off in an entirely new direction. That’s how the state of the art keeps moving.

This DIY spectrometer project is a fantastic example of that ethos. It comes to us from [Michael Prasthofer], who was inspired by [Les Wright]’s PySpectrometer, a simple device cobbled together from a pocket spectroscope and a PiCam. As we noted at the time, [Les] put a lot of the complexity of his instrument in the software, but that doesn’t mean there wasn’t room for improvement.

[Michael]’s goals were to make his spectrometer a little easier to build, and to improve the calibration process and overall accuracy. To help with the former, he went with software correction of the color filter array on his Fuji X-T2. This has the advantage of not requiring a high-power laser and precision micropositioner to ablate the CFA, and avoids potentially destroying an expensive camera. For the latter, [Michael] delved deep into the theory behind spectroscopy and camera optics to develop a process for correlating the intensity of light along the spectrum with the specific wavelength at that location. He also worked a little machine learning into the process, training a network to optimize the response functions.

The result is pretty accurate spectra with no lasers required for calibration. The video below goes into a lot of detail and ends up being a good introduction to some of the basics of spectroscopy, along with the not-so-basics.

Continue reading “An Improved Spectrometer, No Lasers Required”

Recycling Of Portland Cement And Steel In Electric Arc Furnaces

The use of concrete and steel have both become the bedrock of modern-day construction, which of course also means that there is a lot of both which ends up as waste once said construction gets demolished again. While steel is readily recyclable, the Portland cement that forms the basis of concrete so far is not. Although the aggregate from crushed concrete can be reclaimed, the remainder tends to end up in a landfill, requiring fresh input of limestone to create more cement. Now a team of researchers from the University of Cambridge claim to have found a way to recycle hydrated Portland cement by using it as flux during steel production in electric arc furnaces (EAFs).

Not only does this save a lot of space in landfills, it also stands to reduce a lot of the carbon dioxide produced during cement and steel production, which is primarily from the use of limestone for cement and lime-dolomite for steel. The details can be found in the open access paper in Nature by [Cyrille F. Dunant] and colleagues. Essentially reclaimed cement paste is mixed with some fresh material to form the flux that shields the molten steel in an EAF from the atmosphere. The flux creates the slag layer that floats on top of the molten steel, with this slag after cooling down being ground up and turned into cement clinker, which is then mixed to create fresh cement.

The process has been patented by Cambridge, who call the product ‘Cambridge Electric Cement‘, with the claim that if using low-carbon power sources for the EAF like hydro and nuclear, it would constitute ‘no emissions’ and ‘no landfill’ cement. We have to see how this works out on an industrial scale, of course, but it would definitely be nice to keep concrete and cement in general out of landfills, while cutting back on limestone mining, as well as questionable practices like adding heavy metal-laden fly ash as filler to concrete.

Thanks to [cscott] for the tip.

Connecting (And Using) High-Capacity Batteries In Parallel

For those willing to put some elbow grease into it, there is an almost unlimited supply of 18650 lithium ion batteries around for cheap (or free) just waiting to be put into a battery pack of some sort. Old laptop and power tool batteries are prime sources, as these often fail because of one bad cell while the others are still perfectly usable. [limpkin] built a few of these battery packs and now that he’s built a few, he’s back with a new project that allows him to use four custom packs simultaneously.

The problem with using different battery packs in parallel is that unless the batteries are charged to similar voltages, they could generate a very high and potentially dangerous amount of current when connected in parallel. This circuit board, powered by a small ATtiny microcontroller, has four XT60 connectors for batteries and a fifth for output. It then watches for current draw from each of the batteries and, using a set of solid-state relays, makes sure that no dangerous over-current conditions occur if the batteries are connected with mismatched voltages. The code for the microcontroller is available on this GitHub page as well.

An array of batteries with a balancing system like this has a number of uses, from ebikes to off-grid power solutions, and of course if you build your own packs you’ll also want to build a cell balancer of some sort as well. Batteries go outside the realm of theory and into that of chemistry, so we’ll also provide a general warning about working in potentially dangerous situations without specialized knowledge, but you can see how [limpkin] built his original packs here if you want to take a look at one person’s strategy for repurposing old cells.

Continue reading “Connecting (And Using) High-Capacity Batteries In Parallel”

The Emperor’s New Computer

You walk into a home office and see an attractive standing desk that appears bare. Where’s the computer? Well, if it is [DIY Perk]’s office, the desk is the computer. Like a transformer robot, the desk transforms into a good-looking PC.

He starts with a commercial desk and creates a replacement desktop out of some aluminum sheets and extrusions. The motion uses some V-slot profiles and linear rails. The monitor and keyboard shelf pop up on invisible hinges. When closed, there’s no trace of a computer.

Continue reading “The Emperor’s New Computer”

A System Board For The 8008

Intel processors, at least for PCs, are ubiquitous and have been for decades. Even beyond the chips specifically built by Intel, other companies have used their instruction set to build chips, including AMD and VIA, for nearly as long. They’re so common the shorthand “x86” is used for most of these processors, after Intel’s convention of naming their processors with an “-86” suffix since the 1970s. Not all of their processors share this convention, though, but you’ll have to go even further back in time to find one. [Mark] has brought one into the modern age and is showing off his system board for this 8008 processor.

The 8008 predates any x86 processor by about six years and was among the first mass-produced 8-bit processors even before the well-known 8080. The expansion from four bits to eight was massive for the time and allowed a much wider range of applications for embedded systems and early personal computers. [Mark] goes into some of the details for programming these antique processors before demonstrating his system board. It gets power from a USB-C connection and uses a set of regulators and level shifters to make sure the voltages all match. Support for all the functions the 8008 needs is courtesy of an STM32. That includes the system memory.

For those looking to develop something like this, [Mark] has also added his development tools to a separate GitHub page. Although it’s always a good idea for those interested in computer science to take a look at old processors like these, it’s not always the easiest path to get original hardware like this, which also carries the risk of letting smoke out of delicate components. A much easier route is to spin up an emulator like an 8086 IBM PC emulator on an ESP32. Want to see inside this old chip? Have a look.

Continue reading “A System Board For The 8008”

Camera And Lens Repair Hack Chat

Join us on Wednesday, May 29 at noon Pacific for the Camera and Lens Repair Hack Chat with Anthony Kouttron!

Unlike the normies, most of us are pretty comfortable looking under the hood of just about anything electronic or mechanical. Whether it’s to effect a repair, make a modification, or just to take a look around, voiding warranties is what we do. A lot of us have hard limits, though, and will shy away from certain types of equipment. High voltages and radiation come to mind, as well as machines with lots of spinny bits that can devour your hands in a trice. One mustn’t be foolhardy, after all.

But one place that we’ve always feared to tread for some reason is camera equipment. Perhaps it has to do with all those impossibly tiny screws with subtly different lengths and the knowledge that putting the wrong screw in the wrong hole could have disastrous results. Or maybe it’s just the general fear that messing around with the insides of lenses could knock something slightly off-kilter and ruin the optics.

join-hack-chatWe’re certainly glad that Anthony Kouttron doesn’t share this trepidation. We recently featured a lens repair that he accomplished that was packed with tips and tricks for optical repairs. It turns out that Anthony has been repairing cameras for leisure since 2010, and has serviced both consumer and high-end cinema equipment — so he’s seen his fair share of broken camera bits. We’ve asked him to drop by the Hack Chat, so if you’ve been hesitant to dive into optical fixes, now might be your chance to learn about the dos and don’ts of camera and lens repair.

Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, May 29 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.

The Long Road Towards Reverse Engineering The ESP32 Wi-Fi Driver

Although much of the software that runs on the ESP32 microcontroller is open source, the Wi-Fi driver is not. Instead, it uses a proprietary binary blob. This was no problem for [Jasper Devreker]’s reverse-engineering of the ESP32’s Wi-Fi stack so far until he came face to face with reverse-engineering the initialization of the Wi-Fi peripheral. As it turns out, there is a lot of work involved after you call esp_phy_enable in the Espressif binary blob, with the team logging 53,286 peripheral accesses during the initialization phase. In comparison, sending a Wi-Fi packet takes about ten calls.

Currently, the way that the initialization step is handled is by having the initialization routine in the binary blob do its thing by configuring the radio and other elements before killing the FreeRTOS task and replacing it with their own version. The team is actively looking for a clean approach for moving forward that will avoid simply writing everything from scratch. For the Wi-Fi MAC, existing code (e.g., FreeBSD’s stack) could be used, but the radio code is much more of a headache. Clearly, there’s still a lot more work to be done in order to get a fully open-source Wi-Fi MAC and stack for the ESP32, but having the community (that’s you) pitch in might speed things up if there’s demand for an open-source driver.

[Jasper’s] been working on this for a while. He’s even built a Faraday cage to make the task easier.