AI For The Skeptics: The Universal Function For Some Things Only

It’s a phrase we use a lot in our community, “Drink the Kool-Aid”, meaning becoming unreasonably infatuated with a dubious idea, technology, or company. It has its origins in 1960s psychedelia, but given that it’s popularly associated with the mass suicide of the followers of Jim Jones in Guyana, perhaps we should find something else. In the sense we use it though, it has been flowing liberally of late with respect to AI, and the hype surrounding it. This series has attempted to peer behind that hype, first by examining the motives behind all that metaphorical Kool-Aid drinking, and then by demonstrating a simple example where the technology does something useful that’s hard to do another way. In that last piece we touched upon perhaps the thing that Hackaday readers should find most interesting, we saw the LLM’s possibility as a universal API for useful functions.

It’s Not What An LLM Can Make, It’s What It Can Do

When we program, we use functions all the time. In most programming languages they are built into the language or they can be user-defined. They encapsulate a piece of code that does something, so it can be repeatedly called. Life without them on an 8-bit microcomputer was painful, with many GOTO statements required to make something similar happen. It’s no accident then that when looking at an LLM as a sentiment analysis tool in the previous article I used a function GetSentimentAnalysis(subject,text) to describe what I wanted to do. The LLM’s processing capacity was a good fit to my task in hand, so I used it as the engine behind my function, taking a piece of text and a subject, and returning an integer representing sentiment. The word “do” encapsulates the point of this article, that maybe the hype has got it wrong in being all about what an LLM can make. Instead it should be all about what it can do. The people thinking they’ve struck gold because they can churn out content slop or make it send emails are missing this. Continue reading “AI For The Skeptics: The Universal Function For Some Things Only”

Repairing A Mercedes EQC 300 BEV Battery

When [OGS Mechanics] got a Mercedes EQC 300 battery-electric car in for repair, it was found to have a bit of a weird issue: after sitting in a garage for a while, its range on battery had suddenly reduced significantly without clear cause. Although the typical response here is to just mark the battery pack as ‘faulty’ and replace the whole unit, [OGS] decided to dig into the pack to see what was going on.

The short version is that this particular battery pack consists of two individual batteries, each with its own BMS, one of which had reported a condition to the master BMS that triggered the ‘replace battery module’ error observed with the scan tool. From this it could also be seen that the first battery was at a 10% state-of-charge (SoC), and the second at 95%, making them incredibly unbalanced. Unfortunately the dealer procedure to rebalance did not work here, with only the second battery wanting to charge even after draining both to the same initial level.

To diagnose the underlying issue in earnest required gently prying open the battery pack like a massive glued-shut smartphone. Going by the theory that it is a software glitch, since the first battery was still at a healthy voltage level, it was decided to manually charge it. With both batteries now fully charged, the BMS for the first battery was then removed to have its memory overwritten with that of a known good BMS module, clearing the ‘replace battery module’ error.

Although in the preview for the next video it’s hinted that there’s also an internal balancing issue in the first battery pack, this could be another symptom of its BMS glitching out. Either way, it would seem that BEVs battery modules are both heavily dependent on software, as well as afflicted by the same throw-away culture that has people just buying a new smartphone when the battery fails.

Continue reading “Repairing A Mercedes EQC 300 BEV Battery”

What Have We Dumped On The Moon?

If you read a headline that signs of intelligent life were found on the moon, you might suspect a hoax. But they are there! Humans have dumped a lot of stuff on the moon, both in person and via uncrewed rockets. So after the apocalypse, what strange things will some alien exo-archaeologist find on our only natural satellite?

The Obvious

Of course, we’ve left parts of rockets, probes, and rovers. Only the top part of the Apollo Lunar Excursion Module left the moon. (See for yourself in the Apollo 17 ascent video below.) The bottoms are still there, along with the lunar rovers and a bunch of other science instruments and tools. There are boots and cameras, as you might expect.

But what about the strange things? As of 2012, NASA compiled a list of all known lunar junk that originated on Earth. The list starts with material from the non-Apollo US programs like the Surveyor and Lunar Prospector missions. Next up is the Apollo stuff, which is actually quite a bit: an estimated 400,000 pounds, we’ve heard. This ranges from the entire descent stage and lunar overshoes to urine bags. There are even commemorative patches and a gold olive branch.

After that, the list shows what’s known to be on the surface from the Russian space program, along with objects of Chinese, Indian, Japanese, and European origin.

Continue reading “What Have We Dumped On The Moon?”

ESP32 Hosts A Public Website

If you wanted to host a website, you could use any one of a number of online services, or spin up a server on a spare computer at home. If you’re a bit more daring, you could also do what [Tech1k] did, and run one on an ESP32 microcontroller.

The site in question is available (or at least, should be) at HelloESP.com. The first revision ran entirely on an ESP32, serving pages from a SPIFFS filesystem. The device was also fitted with a BME280 environment sensor and an OLED screen. It had an uptime of 500 days before the board failed.

The site has since been relaunched, running on a board that is framed on [Tech1k]’s wall. It runs on an ESP32-WROOM-32D, paired with a BME280 again, along with a CCS811 CO2 and air quality sensor and a DS3231 RTC for accurate timekeeping. The ESP32 is setup to hold an outbound WebSocket to a Cloudflare worker, with the Worker routing HTTP requests to the site via that route. This avoids the need for port forwarding for the ESP32 to be visible to the outside world, and the Cloudflare Worker will also serve a static version of the page in the case of WiFi dropouts or other temporary failures.

It’s true that this isn’t a completely unheard of project—microcontrollers have been working as simple web servers for a long time now. Still, [Tech1k] did a great job of making this as robust as possible and more like a real functional webserver rather than just something that runs on a local network to serve up a config page. That’s worthy of note.

You can run webservers on all kinds of chips these days, even the Raspberry Pi Pico. If you’re doing web stuff on something weird, you know we always wanna hear about it on the tipsline!

DIY Smart Button Gets Surprisingly Complicated

There’s a reason that the standards specifications for various wireless communications protocols are extremely long and detailed. [Made by Dennis] found this out first hand when he decided to build a wireless button from scratch.

The major issues with wireless devices is one of power consumption. If reliable power is available from a wall plug or solar panel, this isn’t as serious of a concern. But [Dennis] is using batteries for his buttons, so minimizing power consumption is a priority. He’s going with the nRF52, a microcontroller designed for low power and which has a built in wireless radio, and configuring it in a way that uses the least amount of energy possible.

From there, [Dennis] turns to the wireless communication. He goes into detail about how the microcontroller is woken up, how it sends its data packets to another wireless-enabled microcontroller, and how they handle handshakes and acknowledgements of data. For something as simple as a button press, it gets quickly more complicated especially when adding some basic encryption and security to the communications protocol.

With all the design decisions out of the way, the system can be built. [Dennis] has created custom PCBs for his devices, and also included some expansion I/O for other sensors and peripherals beyond just a pushbutton. All of the schematics and code are available on the project’s GitHub page and the STL files can be found at Printables.

For those new to offline home automation or who are turning away from cloud-based services lately, there are some easy entry points that don’t require much extra hardware or expenditure.

Continue reading “DIY Smart Button Gets Surprisingly Complicated”

Wearable MIDI Controller Built With Raspberry Pi

Most synths happily get by with keyboard or pad inputs and make lovely sounds in response. [Becky Clarke] and her fellow collaborators are building a synth that works rather differently. DigitSynth is a wearable controller that’s rather fun to interact with.

The heart of the build is a Raspberry Pi 5. It’s set up to talk to a TI ADS1115 ADC chip that lets it read a bunch of analog flex sensors embedded in a right-hand glove, while the Pi can also read a bunch of tactile buttons activated by the left hand. The flex sensors are used to control synth parameters like LFO rate and filter cutoffs, while the buttons control chord changes. The Raspberry Pi runs custom code to read these devices and generate the requisite MIDI commands to send to a Roland JD-Xi synth which is responsible for actually making the sound. Both sets of fingers are also dotted with LEDs for visual feedback, controlled via a TLC59711 PWM driver.

It’s a fun build that creates some ethereal sounds in an intuitive way, thanks to the nature of the interface. We’ve featured some similar builds before, using the flexure of the hand to create musical soundscapes. Video after the break.

Continue reading “Wearable MIDI Controller Built With Raspberry Pi”

Itanium: The Great X86 Replacement That Never Was

Itanium was once meant to be the next step in computing, to compete with the likes of IBM, Sun and DEC, but also for Intel to have an architecture that couldn’t be taken from it, as the PC was from IBM by its clones. Today, however, Itanium is a relic of the past. [Asianometry] tells us the story of Itanium.

By the ’90s, servers were an established market dominated by RISC architectures and Unix-like operating systems. Intel wanted to compete in this market, due in part to worries of losing control over x86. So, when Hewlett Packard came to Intel in late ’93, Intel eventually agreed to collaborate on a new project in EPIC (Explicitly Parallel Instruction Computing).
Continue reading “Itanium: The Great X86 Replacement That Never Was”