Recovering An Agilent 2000a/3000a Oscilloscope With Corrupt Firmware NAND Flash

June 18, 2024 by Maya Posch 21 Comments

Everyone knows that you can never purchase enough projects off EBay, lest boredom might inadvertently strike. That’s why [Anthony Kouttron] got his mitts on an Agilent DSO-X 2014A digital oscilloscope that was being sold as defective and not booting, effectively just for parts. When [Anthony] received the unit, this turned out to be very much the case, with the front looking like it got dragged over the tarmac prior to having the stuffing beaten out of its knobs with a hammer. Fortunately, repairing the broken encoder and the plastic enclosure was easy enough, but the scope didn’t want to boot when powered on. How bad was the damage?

As [Anthony] describes in the article, issues with this range of Agilent DSOs are well-known, with for example the PSU liking to fry the primary side due to soft power button leaving it powered 24/7 with no cooling. The other is corrupted NAND storage, which he confirmed after figuring out the UART interface on the PCB with the ST SPEAr600 ARM-based SoC. Seeing the sad Flash block decompression error from the Windows CE said enough.

This led him down the rabbithole of finding the WinCE firmware images (nuked by Keysight, backed up on his site) for this scope, along with the InfiniiVision scope application. The former is loaded via the bootloader in binary YMODEM mode, followed by installing InfiniiVision via a USB stick. An alternate method is explained in the SPEAr600 datasheet, in the form of USB BootROM, which can also be reached via the bootloader with some effort.

As for the cause of the NAND corruption, it’s speculated that the scope writes to the same section of NAND Flash on boot, with the SPEAr600’s Flash controller documentation not mentioning wear leveling. Whether that’s true or not, at least it can be fixed with some effort even without replacing the NAND Flash IC.

McDonald’s Terminates Its Drive-Through Ordering AI Assistant

June 18, 2024 by Maya Posch 72 Comments

McDonald’s recently announced that it will be scrapping the voice-assistant which it has installed at over 100 of its drive-throughs after a two-year trial run. In the email that was sent to franchises, McDonald’s did say that they are still looking at voice ordering solutions for automated order taking (AOT), but it appears that for now the test was a disappointment. Judging by the many viral videos of customers struggling to place an order through the AOT system, it’s not hard to see why.

This AOT attempt began when in 2019 McDonald’s acquired AI company Apprente to create its McD Tech Labs, only to sell it again to IBM who then got contracted to create the technology for McDonald’s fast-food joints. When launched in 2021, it was expected that McDonald’s drive-through ordering lanes would eventually all be serviced by AOT, with an experience akin to the Alexa and Siri voice assistants that everyone knows and loves (to yell at).

With the demise of this test at McDonald’s, it would seem that the biggest change is likely to be in the wider automation of preparing fast-food instead, with robots doing the burger flipping and freedom frying rather than a human. That said, would you prefer the McD voice assistant when going through a Drive-Thru^® over a human voice?

Reverse-Engineering Makita Batteries To Revive Them

June 15, 2024 by Maya Posch 35 Comments

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.

Voyager 1 Once Again Returning Science Data From All Four Instruments

June 15, 2024 by Maya Posch 13 Comments

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.

Thanks to [Mark Stevens] for the tip.

Easy Retro 3D Look With Voxel Displacement Renderer

June 14, 2024 by Maya Posch 9 Comments

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.

Continue reading “Easy Retro 3D Look With Voxel Displacement Renderer” →

Forsp: A Forth & Lisp Hybrid Lambda Calculus Language

June 13, 2024 by Maya Posch 17 Comments

In the world of lambda calculus programming languages there are many ways to express the terms, which is why we ended up with such an amazing range of programming languages, even if most trace their roots back to ALGOL. Of the more unique (and practical) languages, Lisp and Forth probably range near the top, but what if you were to smudge both together? That’s what [xorvoid] did and it resulted in the gracefully titled Forsp programming language. Unsurprisingly it got a very warm and enthusiastic reception over at Hacker News.

While keeping much of Lisp-isms, the Forth part consists primarily out of it being very small and easy to implement, as demonstrated by the C-based reference implementation. It also features a Forth-like value/operand stack and function application. Also interesting is Forsp using call-by-push-value (CBPV), which is quite different from call-by-value (CBV) and call-by-name (CBN), which may give some advantages if you can wrap your mind around the concept.

Even if practicality is debatable, Forsp is another delightful addition to the list of interesting lambda calculus demonstrations which show that the field is anything but static or boring.