Graph showing accuracy vs model

Why You Shouldn’t Trade Walter Cronkite For An LLM

Has anyone noticed that news stories have gotten shorter and pithier over the past few decades, sometimes seeming like summaries of what you used to peruse? In spite of that, huge numbers of people are relying on large language model (LLM) “AI” tools to get their news in the form of summaries. According to a study by the BBC and European Broadcasting Union, 47% of people find news summaries helpful. Over a third of Britons say they trust LLM summaries, and they probably ought not to, according to the beeb and co.

It’s a problem we’ve discussed before: as OpenAI researchers themselves admit, hallucinations are unavoidable. This more recent BBC-led study took a microscope to LLM summaries in particular, to find out how often and how badly they were tainted by hallucination.

Not all of those errors were considered a big deal, but in 20% of cases (on average) there were “major issues”–though that’s more-or-less independent of which model was being used. If there’s good news here, it’s that those numbers are better than they were when the beeb last performed this exercise earlier in the year. The whole report is worth reading if you’re a toaster-lover interested in the state of the art. (Especially if you want to see if this human-produced summary works better than an LLM-derived one.) If you’re a luddite, by contrast, you can rest easy that your instincts not to trust clanks remains reasonable… for now.

Either way, for the moment, it might be best to restrict the LLM to game dialog, and leave the news to totally-trustworthy humans who never err.

Self-Driving Cars And The Fight Over The Necessity Of Lidar

If you haven’t lived underneath a rock for the past decade or so, you will have seen a lot of arguing in the media by prominent figures and their respective fanbases about what the right sensor package is for autonomous vehicles, or ‘self-driving cars’ in popular parlance. As the task here is to effectively replicate what is achieved by the human Mark 1 eyeball and associated processing hardware in the evolutionary layers of patched-together wetware (‘human brain’), it might seem tempting to think that a bunch of modern RGB cameras and a zippy computer system could do the same vision task quite easily.

This is where reality throws a couple of curveballs. Although RGB cameras lack the evolutionary glitches like an inverted image sensor and a big dead spot where the optical nerve punches through said sensor layer, it turns out that the preprocessing performed in the retina, the processing in the visual cortex and analysis in the rest of the brain is really quite good at detecting objects, no doubt helped by millions of years of only those who managed to not get eaten by predators procreating in significant numbers.

Hence the solution of sticking something like a Lidar scanner on a car makes a lot of sense. Not only does this provide advanced details on one’s surroundings, but also isn’t bothered by rain and fog the way an RGB camera is. Having more and better quality information makes subsequent processing easier and more effective, or so it would seem.

Continue reading “Self-Driving Cars And The Fight Over The Necessity Of Lidar”

Why Sodium-Ion Batteries Are Terrible For Solar Storage

These days just about any battery storage solution connected to PV solar or similar uses LiFePO4 (LFP) batteries. The reason for this is obvious: they have a very practical charge and discharge curve that chargers and inverters love, along with a great round trip efficiency. Meanwhile some are claiming that sodium-ion (Na+) batteries would be even better, but this is not borne out by the evidence, with [Will Prowse] testing and tearing down an Na+ battery to prove the point.

The OCV curve for LFP vs Na+ batteries.
The OCV curve for LFP vs Na+ batteries.

The Hysincere brand battery that [Will] has on the test bench claims a nominal voltage of 12 V and a 100 Ah capacity, which all appears to be in place based on the cells found inside. The lower nominal voltage compared to LFP’s 12.8 V is only part of the picture, as can be seen in the OCV curve. Virtually all of LFP’s useful capacity is found in a very narrow voltage band, with only significant excursions when reaching around >98% or <10% of state of charge.

What this means is that with existing chargers and inverters, there is a whole chunk of the Na+ discharge curve that’s impossible to use, and chargers will refuse to charge Na+ batteries that are technically still healthy due to the low cell voltage. In numbers, this means that [Will] got a capacity of 82 Ah out of this particular 100 Ah battery, despite the battery costing twice that of a comparable LFP one.

Yet even after correcting for that, the internal resistance of these Na+ batteries appears to be significantly higher, giving a round trip efficiency of 60 – 92%, which is a far cry from the 95% to 99% of LFP. Until things change here, [Will] doesn’t see much of a future for Na+ beyond perhaps grid-level storage and as a starter battery for very cold climates.

Continue reading “Why Sodium-Ion Batteries Are Terrible For Solar Storage”

How Simple Can A Superhet Be

If you cultivate an interest in building radios it’s likely that you’ll at some point make a simple receiver. Perhaps a regenerative receiver, or maybe a direct conversion design, it’ll take a couple of transistors or maybe some simple building-block analogue ICs. More complex designs for analogue radios require far more devices; if you’re embarking on a superhetrodyne receiver in which an oscillator and mixer are used to generate an intermediate frequency then you know it’ll be a hefty project. [VK3YE] is here to explode that assumption, with a working AM broadcast band superhet that uses only two transistors.

The circuit diagram of the radio
It doesn’t get much simpler than this.

A modern portable radio will almost certainly use an all-in-one SDR-based chip, but in the golden age of the transistor radio the first stage of the receiver would be a single transistor that was simultaneously RF amplifier, oscillator, and mixer. The circuit in the video below does this , with a ferrite rod, the familiar red-cored oscillator coil, and a yellow-cored IF transformer filtering out the 455 kHz mixer product between oscillator and signal.

There would normally follow at least one more transistor amplifying the 455 kHz signal, but instead the next device is both a detector and an audio amplifier. Back in the day that would have been a germanium point contact diode, but now the transistor has a pair of 1N4148s in its biasing. We’re guessing this applies a DC bias to counteract the relatively high forward voltage of a silicon diode, but we could be wrong.

We like this radio for its unexpected simplicity and clever design, but also because he’s built it spiderweb-style. We never expected to see a superhet this simple, and even if you have no desire to build a radio we hope you’ll appreciate the ingenuity of using simple transistors to the max.

Continue reading “How Simple Can A Superhet Be”

Schematic diagram of part of RAM

Making RAM For A TMS9900 Homebrew Computer

Over on YouTube [Usagi Electric] shows us how to make RAM for the TMS9900.

He starts by remarking that the TI-99/4A computer is an excellent place to start if you’re interested in getting into retro-computing. Particularly there are a lot of great resources online, including arcadeshopper.com and the AtariAge forums.

The CPU in the TI-99 is the TMS9900. As [Usagi Electric] explains in the video this CPU only has a few registers and most actual “registers” are actually locations in RAM. Because of this you can’t do much with a TMS9900 without RAM attached. So he sets about making some RAM for his homebrew TMS9900 board. He uses Mitsubishi M58725P 16 kilobit (2 kilobyte) static RAM integrated circuits; each has 11 address lines and 8 data lines, so by putting two side-by-side we get support for 16-bit words. Using six M58725Ps, in three pairs, we get 6 kilowords (12 kilobytes).

Continue reading “Making RAM For A TMS9900 Homebrew Computer”

Hello World In C Without Linking In Libraries

If there’s one constant with software developers, it is that sometimes they get bored. At these times, they tend to think dangerous thoughts, usually starting with ‘What if…’. Next you know, they have gone down a dark and winding rabbit hole and found themselves staring at something so amazing that the only natural conclusion that comes to mind is that while educational, it serves no immediate purpose.

The idea of applying this to snipping out the <stdio.h> header in C and the printf() function that it provides definitely is a good example here. Starting from the typical Hello World example in C, [Old Man Yells at Code] over at YouTube first takes us from the standard dynamically linked binary at a bloated 16 kB, to the statically linked version at an eyepopping 767 kB.

To remove any such dynamic linkages, and to keep file sizes somewhat sane, he then proceeds to first use the write()function from the <unistd.h> header, which does indeed cut out the <stdio.h> include, before doing the reasonable thing and removing all includes by rewriting the code in x86 assembly.

While this gets the final binary size down to 9 kB and needs no libraries to link with, it still performs a syscall, after setting appropriate register values, to hand control back to the kernel for doing the actual printing. If you try doing something similar with syscall(), you have to link in libc, so it might very well be that this is the real way to do Hello World without includes or linking in libraries. Plus the asm keyword is part of C, although one could argue that at this point you could just as well write everything in x86 ASM.

Of course, one cannot argue that this experience isn’t incredibly educational, and decidedly answers the original ‘What if…’ question.

Continue reading “Hello World In C Without Linking In Libraries”

10 Cent Microcontroller Makes Tracker Music

We are absurdly spoiled these days by our microcontrollers. Take the CH32V00X family– they’ve been immortalized by meme as “the ten cent micro” but with a clock speed of 48MHz and 32-bit registers to work with, they’re astoundingly capable machines even by the standards of home computers of yore. That’s what motivated [Tim] to see if he could use one to play MOD files, with only minimal extra parts– and quite specifically no DAC.

Well, that’s part of what motivated him. The other part was seeing Hackaday feature someone use a CH32V003 making chiptune-like beeps. [Tim] apparently saw that post as a gauntlet thrown down, and he picked it up with an even smaller chip: the CH32V002, which he proceeded to turn into a MOD player. For those of you who slept through 80s and early 90s (or for those precocious infants reading this who hadn’t then yet been born), MOD files are anĀ  electronic music format, pioneered on the Amiga home computers. Like MIDI, the file specifies when to play specific voices rather than encoding the sound directly. Unlike MIDI, MOD files are self-contained, with the samples/voices used being stored inside the file. The original version targeted four-channel sound, and that’s what [Tim] is using here.

As you can see from the demo video, it sounds great. He pulled it off by using the chip’s built-in PWM timer. Since the timer’s duty cycle is determined by a variable that can be changed by DMA, the CPU doesn’t end up with very much to do here. In the worst case, with everything in flash memory instead of SRAM, the CPU is only taxed at 24%, so there’s plenty of power to say, add graphics for a proper demo. Using the existing MODPlay Library, [Tim]’s player fits into 4kB of memory, leaving a perfectly-usable 12kB for the MOD file. As far as external components needed, it’s just an RC filter to get rid of PWM noise.

[Tim] has put his code up on GitHub for anyone interested, and has perhaps inadvertently cast down another gauntlet for anyone who wants to use these little RISC V microprocessors for musical tasks. If you can do better, please do, let us know.

Continue reading “10 Cent Microcontroller Makes Tracker Music”