Climbers care a lot about their ropes because their lives literally depend on them. And while there’s been tremendous progress in climbing rope tech since people first started falling onto hemp fibers, there are still accidents where rope failure is to blame.
This long, detailed, and interesting video from [Hard is Easy] follows him on a trip to the Mammut test labs to see what’s up with their relatively new abrasion-resistant rope. His visit was full of cool engineering test rigs that pushed the ropes to breaking in numerous ways. If you climb, though, be warned that some of the scenes are gut-wrenchingly fascinating, watching the ropes fail horribly in well-shot slow-mo.
As far as model construction sets go, LEGO is by far the most popular brand for building not only pre-planned models but whatever the builder can imagine. There are a few others out there though, some with some interesting features. Meccano (or Erector in North America) is a construction set based around parts that are largely metal including its fasteners, which allows for a different approach to building models than other systems including the easy addition of electricity. [Craig], a member of the London Meccano Club, is demonstrating his model Enigma machine using this system for all of its parts and adding some electricity to make the circuitry work as well.
The original Enigma machine was an electronic cypher used by the German military in World War 2 to send coded messages. For the time, its code was extremely hard to break, and led to the British development of the first programmable electronic digital computer to help decipher its coded messages. This model uses Meccano parts instead to recreate the function of the original machine, with a set of keys similar to a typewriter which, when pressed, advance a set of three wheels. The wheels all have wiring in them, and depending on their initial settings will light up a different character on a display.
There are a few modifications made to the design (besides the use of a completely different set of materials) but one of the main ones was eliminating the heavy leaf springs of the original for smaller and easier-to-manage coil springs, which are also part of the electrical system that creates the code. The final product recreates the original exceptionally faithfully, with plans to create a plugboard up next, and you can take a look at the inner workings of a complete original here.
Modern lithium-ion battery packs for cordless power tools contain an incredible amount of energy, which necessitates that they come with a range of safeties. Although it’s good when the battery management system (BMS) detects a fault and cuts power to prevent issues, there exist the possibility of false positives. Having an expensive battery pack brick itself for no good reason is rather annoying, as is being unable to reuse a BMS in for example a re-manufactured battery. This was the reasoning that led [Martin Jansson] down the path of reverse-engineering Makita batteries for starters.
After that initial reverse-engineering attempt involving a firmware dump of the NEC (Renesas) F0513 MCU, [Martin] didn’t get back to the project until recently, when he was contacted by [Romain] who donated a few BMS boards to the cause. One of these features an STM32 MCU, which made the task much easier. Ultimately [Martin] was able to determine the command set for the Maxim OneWire-based communication protocol, as was a hidden UART mode.
Due to the critical timing required, off-the-shelf programmers didn’t work, so an Arduino Uno-based programmer (ArduinoOBI) was created instead, which can be found on GitHub along with the Open Battery Information desktop application which provides access to these BMS features after connecting to the battery pack. Although only Makita is supported right now, [Martin] would like to see support for other brands being added as well.
Last week, I stumbled on a marvelous book: “Giant Brains; or, Machines That Think” by Edmund Callis Berkeley. What’s really fun about it is the way it sounds like it could be written just this year – waxing speculatively about the future when machines do our thinking for us. Except it was written in 1949, and the “thinking machines” are early proto-computers that use relays (relays!) for their logic elements. But you need to understand that back then, they could calculate ten times faster than any person, and they would work tirelessly day and night, as long as their motors keep turning and their contacts don’t get corroded.
But once you get past the futuristic speculation, there’s actually a lot of detail about how the then-cutting-edge machines worked. Circuit diagrams of logic units from both the relay computers and the brand-new vacuum tube machines are on display, as are drawings of the tricky bits of purely mechanical computers. There is even a diagram of the mercury delay line, and an explanation of how circulating audio pulses through the medium could be used as a form of memory.
All in all, it’s a wonderful glimpse at the earliest of computers, with enough detail that you could probably build something along those lines with a little moxie and a few thousands of relays. This grounded reality, coupled with the fantastic visions of where computers would be going, make a marvelous accompaniment to a lot of the breathless hype around AI these days. Recommended reading!
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
As humanity’s furthest reach into the Universe so far, the two Voyager spacecraft’s well-being is of utmost importance to many. Although we know that there will be an end to any science mission, the recent near-death experience by Voyager 1 was a shocking event for many. Now it seems that things may have more or less returned to normal, with all four remaining scientific instruments now back online and returning information.
Since the completion of Voyager 1’s primary mission over 43 years ago, five of its instruments (including the cameras) were disabled to cope with its diminishing power reserves, with two more instruments failing. This left the current magnetometer (MAG), charged particle (LECP) and cosmic ray (CRS) instruments, as well as the plasma wave subsystem (PWS). These are now all back in operation based on the returned science data after the Voyager team confirmed previously that they were receiving engineering data again.
With Voyager 1 now mostly back to normal, some housekeeping is necessary: resynchronizing the onboard time, as well as maintenance on the digital tape recorder. This will ensure that this venerable spacecraft will be all ready for its 47th anniversary this fall.
We may be a bit biased, but the storage media of yesteryear has so much more personality than that of today. Yes, it’s a blessing to have terabyte SD cards smaller than your pinky nail and be able to access its data with mind-boggling speed. But there’s a certain charm to a mass storage device that can potentially slice off your finger.
We’re overstating the dangers of the venerable paper tape reader, of course, a mass storage device that [David Hansel] recreated a few years back but we only just became aware of. That seems a bit strange since we’ve featured his Arduino-based Altair 8800 simulator, which is what this tape reader is connected to. Mechanically, the reader is pretty simple — just a wooden frame to hold the LEGO Technic wheels used as tape reels, and some rollers to guide the tape through a read head. That bit is custom-made and uses a pair of PCBs, one for LEDs and one for phototransistors. There are nine of each — eight data bits plus the index hole — and the boards are sandwiched together to guide the paper tape.
The main board has an ATmega328 which reads the parallel input from the read head and controls the tape motor. That part is important thanks to Altair Basic’s requirement for a 100- to 200-ms delay at the end of each typed line. The tape reader, which is just being used as sort of a keyboard wedge, can “type” a lot faster than that, so the motor speed is varied using PWM control as line length changes.
Voxels are effectively like 3D pixels, and they form an integral part of what is commonly referred to as a ‘retro 3D’ look, with pixelated edges sharp enough to cut your retinas on. The problems with modeling a scene using voxels come in the form of creating the geometry and somehow making a physics engine work with voxels rather than conventional triangular (or quad) meshes.
The same scene in Blender (above) and in the voxel-based renderer (below). (Credit: Daniel Schroeder)
The approach demonstrated by [Daniel Schroeder] comes in the form of a Voxel Displacement Renderer implemented in C++ and using the Vulkan API. Best part of it? It only requires standard meshes along with albedo and displacement maps.
These inputs are processed by the C++-based tools, which generate the voxels that should be rendered and their properties, while the GLSL-based shader handles the GPU-based rendering step. The pre-processing steps required make it a good idea to bake these resources rather than try to process it in real-time. With that done, [Daniel]’s demo was able to sustain a solid 100+ FPS on a Radeon RX 5700 XT GPU at 1440p, and 60+ FPS on a Steam Deck OLED.
In a second blog post [Daniel] goes through his motivations for this project, with it originally having been intended as a showpiece for his resume, but he can imagine it being integrated into a game engine.
There are still questions to be resolved, such as how to integrate this technique for in-scene characters and other dynamic elements (i.e. non-static scenery), but in terms of easing voxel-based rendering by supporting a standard mesh-based workflow it’s an intriguing demonstration.
