A new display wedged into a car-based fridge

New Brains Save 12 V Fridge From The Scrap Heap

March 14, 2024 by Dave Rowntree 17 Comments

Recently [nibbler]’s Evakool 55L vehicle fridge started to act strangely, reporting crazy temperature errors and had no chance of regulating. The determination was that the NTC thermistor was toast, and rather than trying to extricate and replace this part, it was a lot easier to add a new one at a suitable location

A straight swap would have been boring, so this was a perfect excuse for an overboard hack. Reverse engineering the controller wouldn’t be easy, as the data wasn’t available, as is often the case for many products of this nature.

While doing a brain transplant, the hacker way, we can go overboard and add the basics of an IoT control and monitoring system. To that end, [nibbler] learned as much as possible about the off-the-shelf ZH25G compressor and the associated compressor control board. The aim was to junk the original user interface/control board and replace that with a Raspberry Pi Pico W running CircuitPython.

For the display, they used one of the ubiquitous SH1106 monochrome OLED units that can be had for less than the cost of a McDonald’s cheeseburger at the usual purveyors of cheap Chinese electronics. A brief distraction was trying to use a DS18B20 waterproof thermometer probe, which they discovered didn’t function, so they reverted to tried and trusted tech — a simple NTC thermistor.

Continue reading “New Brains Save 12 V Fridge From The Scrap Heap” →

A vanadium based flow battery made with 3D printed parts

A Vanadium Redox Flow Battery You Can Build

March 9, 2024 by Dave Rowntree 37 Comments

Vanadium flow batteries are an interesting project, with the materials easily obtainable by the DIY hacker. To that effect [Cayrex2] over on YouTube presents their take on a small, self-contained flow battery created with off the shelf parts and a few 3D prints. The video (embedded below) is part 5 of the series, detailing the final construction, charging and discharging processes. The first four parts of the series are part 1, part 2, part 3, and part 4.

The concept of a flow battery is this: rather than storing energy as a chemical change on the electrodes of a cell or in some localised chemical change in an electrolyte layer, flow batteries store energy due to the chemical change of a pair of electrolytes. These are held externally to the cell and connected with a pair of pumps. The capacity of a flow battery depends not upon the electrodes but instead the volume and concentration of the electrolyte, which means, for stationary installations, to increase storage, you need a bigger pair of tanks. There are even 4 MWh containerised flow batteries installed in various locations where the storage of renewable-derived energy needs a buffer to smooth out the power flow. The neat thing about vanadium flow batteries is centred around the versatility of vanadium itself. It can exist in four stable oxidation states so that a flow battery can utilise it for both sides of the reaction cell.

Continue reading “A Vanadium Redox Flow Battery You Can Build” →

A multifactor authentication device showing TOTP codes

An ESP32 MultiFactor TOTP Generator

March 7, 2024 by Dave Rowntree 22 Comments

MFA, or multifactor authentication, is a standard security feature these days. However, it can be a drag to constantly reach into one’s pocket, scroll to Google Authenticator (other MFA applications are available!), and find the correct TOTP code to log in to a site for a short while. [Allan Oricil] felt this pain point, so they took the problem by the horns and created a desktop MFA TOTP generator to make life just that little bit easier.

TOTP, which stands for Time-based One-Time Password, is a security measure that uses a device or application to provide unique codes that expire after a short time. Two-factor authentication requires a physical item (something you have), such as a key or swipe card, and knowledge of a fact (something you know), like a password, rather than relying on a single factor. This approach ensures a higher level of security. [Allan]’s project is a physical thing one would use with a password or key file.

Continue reading “An ESP32 MultiFactor TOTP Generator” →

Harvard Claims Breakthrough In Anode Behavior Of Solid State Lithium Batteries

March 6, 2024 by Dave Rowntree 20 Comments

One of the biggest issues facing the solid-state lithium-based batteries we all depend upon is of the performance of the anode; the transport of lithium ions and minimization of dendrite formation are critical problems and are responsible for charge/discharge rates and cell longevity. A team of researchers at Harvard have demonstrated a method for using a so-called constriction-susceptible structure on a silicon anode material in order to promote direct metal lithium deposition, as opposed to the predominant alloying reaction. After the initial silicon-lithium alloy layer is formed, subsequent layers are pure lithium. Micrometre-scale silicon particles at the anode constrain the lithiation process (i.e. during charging) where free lithium ions are pushed by the charge current towards the anode area. Because the silicon particles are so small, there is limited surface area for alloying to occur, so direct metal plating of lithium is preferred, but crucially it happens in a very uniform manner and thus does not tend to promote the formation of damaging metal dendrites.

Continue reading “Harvard Claims Breakthrough In Anode Behavior Of Solid State Lithium Batteries” →

Walking And Talking Through The UK National Museum Of Computing

March 5, 2024 by Dave Rowntree 18 Comments

I found myself in Milton Keynes, UK, a little while ago, with a few hours to spare. What could I do but rock over to the National Museum of Computing and make a nuisance of myself? I have visited many times, but this time, I was armed with a voice recorder and a mission to talk to everybody who didn’t run away fast enough. There is so much to see and do, that what follows is a somewhat truncated whistle-stop tour to give you, the dear readers, a flavour of what other exhibits you can find once you’ve taken in the usual sights of the Colossus and the other famous early machines.

A VT01 terminal showing "the adventure" game running — Click this image to play in your browser.

We expect you’ve heard of the classic text adventure game Zork. Well before that, there was the ingeniously titled “Adventure”, which is reported to be the first ‘interactive fiction’ text adventure game. Created initially by [Will Crowther], who at the time was a keen cave explorer and D & D player, and also the guy responsible for the firmware of the original Arpanet routers, the game contains details of the cave systems of Mammoth and Flint Ridge in Kentucky.

The first version was a text-based simulation of moving around the cave system, and after a while of its release onto the fledgling internet, it was picked up and extended by [Don Woods], and the rest is history. If you want to read more, the excellent site by [Rick Adams] is a great resource that lets you play along in your browser. Just watch out for the dwarfs. (Editor’s note: “plugh“.) During my visit, I believe the software was running on the room-sized ICL2966 via a VT01 terminal, but feel free to correct me, as I can’t find any information to the contrary.

A little further around the same room as the ICL system, there is a real rarity: a Marconi TAC or Transistorised Automatic Computer. This four-cabinet minicomputer was designed in the late 1950s as a ‘fast real-time computer’, is one of only five made, and this example was initially installed at Wylfa nuclear power station in Anglesey, intended as a monitoring and alarm system controller. These two machines were spare units for the three built for the Swedish air defence system, which were no longer required. Commissioned in 1968, this TAC ran continuously until 2004, which could make it one the longest continuously running computers in the world. The TAC has 4 kwords of 20-bit core memory, a paper tape reader for program loading and a magnetic drum storage memory. Unusually, for this period, the TAC has a micro-coded CISC architecture, utilising a whole cabinet worth of diode-matrix ROM boards to code the instruction set. This enabled the TAC to have a customizable instruction set. As standard, the TAC shipped with trigonometric and other transcendental functions as individual instructions. This strategy minimized the program size and allowed more complex programs to fit in the memory.

Continue reading “Walking And Talking Through The UK National Museum Of Computing” →

Accelerate Your Large Builds Locally With Distcc

March 4, 2024 by Dave Rowntree 20 Comments

The motto of Sun Microsystems back in the day was “The Network Is The Computer” which might be kind of relevant when CPUs were slower and single-core affairs, but lately to get a faster compile, you’d simply throw more cores and memory at the problem. The thing is, most of us don’t do huge compilations all that often, we can’t remember the last time we even attempted a Linux kernel build. However if you do find yourself with a sudden need to do so, and have access to a pile of machines hooked to a network, then why not check out distcc: the fast distributed C/C++ Compiler? We’ve seen a few mentions in comments and a HaD links article referencing it, but never explicitly covered the tool. So here we go.

Continue reading “Accelerate Your Large Builds Locally With Distcc” →

The Juggler: In Rust

March 4, 2024 by Dave Rowntree 12 Comments

Back on the theme of learning to program by taking on a meaningful project — we have another raytracing demo — this time using Rust on the Raspberry Pi. [Unfastener] saw our previous article about writing a simple raytracer in spectrum BASIC and got inspired to try something similar. The plan was to recreate the famous juggler 3D demo, from the early days of 3D rendering on the Amiga.

The juggler story starts with an Amiga programmer called [Eric Graham] who created ssg, the first ray tracer application on a personal computer. A demo was shown to Commodore, who didn’t believe it was done on their platform, but a quick follow-up with the actual software used soon quelled their doubts. Once convinced, they purchased the rights to the demo for a couple of thousand dollars (in 1986 money, mind you) to use in promotional materials. [Eric] developed ssg into the popular Sculpt 3D, which became available also on Mac and Windows platforms, and kick-started a whole industry of personal 3D modelling and ray tracing.

Anyway, back to the point. [Unfastener] needed to get up the considerable Rust learning curve, and the best way to do that is to let someone else take care of some of the awkward details of dealing with GUI, and just concentrate on the application. To that end, they use the softbuffer and winit Rust crates that deal with the (important, yet frankly uninteresting) details of building frame buffers and pushing the pixels out to the window manager in a cross-platform way. Vecmath takes care of — you guessed it — the vector math. There’s no point reinventing that wheel either. Whilst [Unfastener] mentions the original Amiga demo took about an hour per frame to render, this implementation runs in real-time. To that end, the code performs a timed pre-render to determine the most acceptable resolution to get an acceptable frame rate, achieving a respectable 30 or so frames per second on a Pi 5, with the older Pis needing to drop the resolution a little. This goes to show how efficient Rust code can be and, how capable the new Pi is. How far we have come.

We saw another interesting rust-based raytracer a while back, which is kinda fun. We’ve also covered rust in other applications a few times, like inside the Linux kernel. Finally here’s our guide to getting started with rust, in case you need any more motivation to have a crack at this upcoming language.