One of the fun aspects of astrophysics is that much of it involves phenomena which you cannot exactly study from up close, with the supermassive black hole (SMBH) at the center of this galaxy – called Sagittarius A* (Sgr A) – being a great example. Although it’s been predicted since 1971 that black holes like Sgr A radiate energy which then pushes away nearby matter to create something akin to solar wind, this had so far not been proven. Now astronomers have discovered evidence for this emanating from Sgr A*.

Using five years worth of observations made with the Atacama Large Millimeter/Submillimeter Array (ALMA) and correlating it with other observations, a Southern Lobe of movement was identified, along with evidence for a Northern Lobe. Unlike a star where you are dealing with relatively massive quantities of matter being hurled into space, in the case of a very quiet SMBH like Sqr A* you are talking about occasional small wisps of gas of which a fraction gets turned into the radiation that then exerts pressure on the remaining gas.

It is speculated to be exactly this quiescent nature of Sgr A* that makes it so difficult to find evidence of SMBH wind, though one could also argue that having a well-fed SMBH whose event horizon rapidly expands would be fascinating from an astrophysics perspective, but less exciting for any nearby inhabited planets.

There are plenty of ways to get sound into your house: good old fashioned headphones, the Dolby surround setup we all lusted after back in the day, or the 21st century’s ubiquitous soundbar, with its ‘spatial audio’ magic. Which will work in your space? If you were an audio engineer, you’d set up listening area and use a microphone to map the space– but that would be thousands of points and sounds like tedium. [PlasmatronX] had a better idea: use Schlieren imaging to see the sound waves as the travel through the space. Schlieren imaging has trouble with audio frequencies, though, and imaging the entire living room was going to be difficult. So he scaled it all down– including the sound waves, by shifting to ultrasonic frequencies.

He’s using the usual mirror-and-razor Schlieren setup with an 8″ telescope mirror– and if you don’t know what that is, we did a deep dive on this kind of optical flow visualizer a while back. Inside the circular imaging area where that lets him see density changes, he’s set up what he calls a CAT– Computer Acoustic Tomography– array. It’s a rig on a turntable he can set up ultrasonic transducers on, to match the various speaker setups he wants to test, and turn so he can see from all angles what the scaled-down waves are doing. To capture those waves, which aren’t going to be standing still, he adds a stroboscope. All the ultrasound signals are being generated by a Pi Pico, and are scaled 4:1 in the frequency domain– that is, a high 10kHz whine becomes inaudible 40kHz. Those signals are fed through a DIY 8-channel amp into both ultrasonic transducers and larger ‘cat-repellent speakers’ from AliExpress.

The microcontroller is actually a Pico 2W, which is using its “W” to communicate via Bluetooth with a Pi 4. That SBC is running the camera, the stepper for the turntable, and image processing, along with the timing for the audio signals. After that it’s a matter of setting up a scaled down 7.1 surround setup and itty-bity soundbar, and test it on a (stuffed) guinea pig. Obviously you can see a big difference between the steered beams from the tiny soundbar and the true surround, but how that translates to listening pleasure will be at least somewhat subjective.

What’s less subjective is the obvious effect soft furnishings add to the simulation. Now he doesn’t take the time to find a material that will scale the frequency response of a set of curtains, but we’re not sure how much that matters. At 5kHz or 20kHz, they’re going to deaden sound, and you can see that here, and you can see it’s a much bigger deal for the shaped beams of the soundbar than it is for surround sound. In the end, [PlasmatronX] decides to stick to headphones, but the whole video is very much worth watching, so we’ve embeddded it below. If you want to try it yourself he’s put his code on GitHub.

Thanks to [PlasmatronX] for the tip!

Especially in this era of the Internet, the role of the Internet Archive’s Wayback Machine has become increasingly essential as more and more web content vanishes into the ether or is surreptitiously altered to hide salient details. More recently a new worry has seemingly cropped up in the form of scraping of data for so-called AI systems, or at least that’s part of the excuses being offered for blocking the Wayback Machine’s web crawlers, with [Andrew Deck] and [Hanaa’ Tameez] of [Nieman Lab] detailing the impact and reasons provided.

Some news outlets like The Baltimore Banner insist that they’re only blocking the Wayback Machine crawlers because they are worried that LLM chatbots would otherwise ‘improperly cite’ the source of content, while outlets like The Atlantic have put a blanket anti-scraping policy in place. Meanwhile news outlets are generally happy to let paid commercial news archiving outlets like ProQuest and LexisNexis index their content, showing a potential financial incentive.

Whatever the reasons, the direct effect is that as content is modified or vanishes during for example a system migration, buy-out or bankruptcy, researchers who rely on the Wayback Machine are pretty much forced to rely on paid offerings by ProQuest and kin, without the pure archiving focus and free access to information. It will also leave big holes in what the Wayback Machine can cover in its archives, with news especially becoming very spotty.

Incidentally there’s an ongoing petition over at SaveTheArchive.com which people can sign.

Although parents and teachers like to point out the deep link between cooking and chemistry, most people don’t deliberately apply any chemical principles beyond acid/base reactions to their recipes. Not so [Ben Kazez]: he’s written a thorough exploration of the chemical journey to the perfect pancake, and made a calculator for others to use with their own ingredients.

The goal is to optimize the pancakes along four dimensions: interior texture (light and smooth), a tangy flavour, rise, and a crisp, brown exterior layer. The tang comes from residual acids, and since lactic acid produces the best taste, dairy-based acid sources (such as Greek yoghurt or buttermilk) are preferable. Acids also react with baking soda to release carbon dioxide, making them a part of one of the four rising agents. The other three are carbon dioxide released when double-acting baking powder is heated, steam released from the batter, and air bubbles stabilized by egg white foam.

Dairy products, besides contributing acid, also provide a protein structure to keep the interior smooth. In a normal wheat-heavy pancake, two proteins (glutenin and gliadin) interact to form tough strands of gluten. Fats bind to hydrophobic amino acids in these proteins and shorten the gluten chains, hence the name shortening. Adding ricotta cheese also replaces some of this gluten network with a smoother structure of previously-denatured dairy proteins. Dairy products also contribute to the Maillard reaction between reducing sugars (such as lactose, glucose, and fructose) and amino acids, which causes the browning of the pancake’s surface. Besides being brown, the surface should be crisp; since amylose, found in corn starch, forms a brittle, glassy, crackly network when dehydrated, corn starch was added.

The result is a set of chemical equations which can be tuned to create perfect pancakes, combined in the calculator. This summary doesn’t do justice to the depth of the research here; [Ben] also investigated optimal batter resting times, fermentation, cooking fats, cooking surfaces, and spatula properties. If all this has you interested in more about dairy proteins, check out our article on cheesemaking.

Featured image: “Buttermilk pancakes from a recipe by Darina Allen” by [Didym]. 

We’ve talked before about number stations — mysterious shortwave transmitters repeating numbers, presumably for clandestine purposes. But, of course, the mere fact that they are unusual makes them stand out. The best place to hide something is in plain sight. In the old days, a broadcaster might slip a fake news story in mentioning a name that has a secret meaning, for example. But according to [Steven Murdoch], the United States has an even more obvious hiding place for a numbers station: inside GPS.

Every L1 C/A navigation message is a 176-bit field known by the affectionate moniker: Subframe 4, Page 17. The GPS specification says it is for “special messages.” No one has disclosed what those messages might be.

[Murdoch] at University College London analyzed over 12 million GPS packets from 2007 to 2026, trying to understand what was in this field. You might think 176 bits isn’t much, and you are right. But the L1 C/A signal carries 50 bits per second, and each frame is 1,500 bits. As [Murdoch] points out: “every bit must earn its place.” Each subframe is 300 bits, so this mysterious signal is 12% of the subframe. It must be important to someone.

Even if you don’t find spy stuff that interesting, the techniques used to sift through 19 years of data using Python, Julia, and other tools are worth reading about. The source code is available, too.

In 2023, the field has, at least sometimes, changed format. However, the best guess is that the field is sending cryptographic rekeying to other systems.

Of course, the truth could be different, but you have to admit, hiding spy messages in the GPS stream is truly hiding in plain sight. Of course, there are still contemporary traditional number stations out there, too.

After scathing accusations of skimping on due diligence, as well as other feedback to my article on trying to use an ‘AI coding assistant’ for the first time, the only rational, academic response is to lick one’s wounds following a particularly bruising peer review and try to address the raised issues. Reality after all does not care about one’s feelings, and there may be more to this AI assistant technology that can be coaxed out with a more in-depth look.

To this end I’ll do my best to try and work through each raised point, criticism and accusation, to see what I – and perhaps others – can learn of this endeavor. Said points include the use of the wrong frontend – i.e. Copilot – and the wrong model – being Claude Haiku 4.5 – as well as the egregious flaw on my end of ‘prompting wrong’.

For the sake of due diligence the best frontend and models will be investigated for particular tasks, with finally the verbal minefield of ‘prompt engineering’ examined for industry-standard approaches.

Junior Developer

The exact way to refer to an LLM coding assistant is still in flux, with some comparing it to pair programming, while others see the assistant more as a glorified search engine that also has code-complete features as a kind of merger of a web search engine and IntelliSense in Visual Studio. This relationship and how to look at it is the cause of a lot of contention as a result.

Another perspective is that of these assistants being more like junior developers. After all, they can apparently do all the basic boilerplate stuff, write unit tests and perform a range of other basic tasks that are beneath more senior developers. The corollary here is then of course why companies would even want to hire another junior developer if the LLM can fill these jobs. Unsurprisingly, it is already being reported that this happening.

The million dollar question that remains is that if all of this is true whether a junior developer still has value. The answer appears to be ‘yes’, even if you ask Microsoft. The argument would appear to boil down to that these assistants supposedly automate away a lot of the tedium that used to get pushed onto junior developers, leaving them free to develop more advanced skills, naturally supported by the same coding assistants.

Fancier Automation

This gets us to the question of whether these assistants are really much better than the automation tools that have existed in IDEs for many decades now with arguable improvements over time. They certainly do seem to be more capable, but they’ll still never exceed their programming, and require a lot of finagling to make them do the right thing.

Returning to junior developers for a moment: bad apples aside, they will let you know if they didn’t understand something correctly, ask for clarification, admit that they don’t know something and offer to look something up in the documentation if they do not know. None of these are things that these glorified chatbots are capable of, which makes a comparison with IDE automation tools rather fair, especially since junior developers tend to get fired if they screw up as badly as the LLM tools seem to regularly do.

While it’s true that these newfangled coding assistants do have a context window in which they “remember” previous details, you’re still dealing with the limitations of the underlying model no matter how good your prompt engineering skills are. They will also regularly confabulate and you have to accept that they generate code and documentation that is just as likely to be correct as completely wrong, even if many users of these tools seem to believe that they are actually more performant.

Ergo you’ll be writing test cases for the test cases and generated code, while also pulling code review duty, as there is no possibility of ever establishing a level of trust. Especially not after it deletes your entire hard drive or the production database for the second time that week.

If that sounds like the kind of junior developer or automation tool you’d love to be paired up with, then you’re quite the adventurous spirit. Meanwhile I have had enough fun with even code completion tools like the aforementioned IntelliSense or its equivalents in the various other IDEs that I have used over the years to never use them again. It’s bad enough when a code completion tool gets it wrong, it’s worse when the human in the loop fails to catch the glaring mistake.

Model Frontends

Although we generally refer to ChatGPT, Claude or Copilot as an LLM, this is technically incorrect, as these are merely the chatbot frontends that are written to provide a natural language interface experience. The choice here is naturally quite dizzying, as you have a range of major players including the aforementioned, each of which offers a web interface as well as integration with various IDEs and use on the CLI for easy automation.

Hence the claim that one should never use the web frontend for coding, as it needs access to your code and local environment, which makes sense if you want more of the pair programming experience. Since my ‘IDE’ of choice are Notepad++ and Vim, my options here are of course rather limited. There is a third-party OpenAI integration plug for NP++ called NPPOpenAI, but that would seem to be it.

The cool kids are of course all using Visual Studio Code with direct integration of all the frontends, but that option seems about as appealing as ripping half the RAM out of my PC and smashing my fingers with a hammer. Even as a former avid Visual Studio Pro user I feel insulted on a fundamental level at the mere thought.

Maybe that one of the CLI tools like Copilot CLI are a better match for me here as suggested, but this would appear to be more of a way to automate various GitHub tasks. Despite searching around I could not find an objective comparison of the different frontends, just many strong opinions and various pricing plans for model access, so for all intents and purposes they’re being treated as the same.

The Model Catwalk

It was further suggested that I take a look at LiveBench.ai for a comparison of how models perform on various tasks. This does indeed appear to be a valuable resource, if only for providing what appears to be a fairly objective way to compare these individual models against each other.

When sorting by the heading Coding Average, it puts OpenAI’s GPT-5.2 Codex at the top, with Claude 4.7 Opus Thinking High Effort close behind at both a hair over 83%. The Haiku 4.5 model that I was using comes in at a mere 72.17%, which is still much better than the sub-60 percent models near the bottom. Of the free models Haiku 4.5 at least would seem to be not too terrible, with Anthropic marketing it in October of 2025 as equivalent to Sonnet 4 when it comes to coding performance:

Consequently, it would be expected to perform at least decently at given tasks, but we can take a look at what other models are available via GitHub Copilot, for instance.

If you’re not into shelling out any clams for a purported improved experience with at least the Pro+ – not Pro – subscription, you get access to quite a few models to pick from that are apparently not ‘premium’. Of note here is that new sign-ups are currently ‘paused’ as usage-based billing is being introduced.

Of these available free models the following would have theoretically performed better according to the aforementioned benchmarks:

• GPT-5.4 Mini, at 74.70%.
• GPT-5 Mini, at 76.07%.

Following the ‘fast and cost-efficient’ category things get a bit dicey to compare, due to Anthropic’s awesome naming scheme and apparently an additional mode you can use these models in, which may or may not apply here:

• Claude Sonnet 4.6 (Thinking High Effort), 79.9%.
• Claude Sonnet 4.5 (Thinking), 80.36%.

These are apparently ‘more versatile and highly intelligent’, which doesn’t seem to bump up their total score too much compared to the mini models. Following this we get the ‘most powerful at complex tasks’ models:

• GPT-5.4 (Thinking High Effort), 78.18%.
• GPT 5.3 Codex (High), 78.18%.

Taken at face value, the 72.17% for the Haiku 4.5 model is indeed somewhat worse than the other two mini models, yet as this points system relies on a specific methodology it’s important to consider what this means. From the underlying coding tests we can see that they are all Python-based programming examples, which is great if you’re testing Python coding assistants, but rather useless for my purposes as I program in just about any language except Python.

Perhaps more worrying here is the statistic that even in this scenario the best model (GPT-5.2 Codex) only managed to score a rather pitiful 83.62%, so your choice would seem to be roughly between ‘atrocious’ and ‘very bad’. Within the free model selection you’re choosing between roughly 28% and 22% of the answers being incorrect, or roughly a 3/4 chance of getting what you were asking for.

Statistically, this wouldn’t seem to make much of a difference when picking either model.

Prompt Engineering

On my last foray, I was also accused of “prompting the wrong way”, which brings us to the topic of prompt engineering, where you must learn to follow specific rules in order to “correctly” use one of these coding assistants. A crucial aspect that was not obvious to me is that you absolutely must use so-called ‘environmental prompting’, where you set the equivalent of global variables.

To this you then add , such as in the absolute gem that is used by the Livebench code test for an array test:

### Instructions: You are an expert Python programmer. You will be given a question (problem specification) and will generate a correct Python program that matches the specification and passes all tests. You will NOT return anything except for the program.
### Question:
You are given an integer array nums and an integer k.
The frequency of an element x is the number of times it occurs in an array.
An array is called good if the frequency of each element in this array is less than or equal to k.
Return the length of the longest good subarray of nums.
A subarray is a contiguous non-empty sequence of elements within an array.

Example 1:

Input: nums = [1,2,3,1,2,3,1,2], k = 2
Output: 6
Explanation: The longest possible good subarray is [1,2,3,1,2,3] since the values 1, 2, and 3 occur at most twice in this subarray. Note that the subarrays [2,3,1,2,3,1] and [3,1,2,3,1,2] are also good.
It can be shown that there are no good subarrays with length more than 6.

Example 2:

Input: nums = [1,2,1,2,1,2,1,2], k = 1
Output: 2
Explanation: The longest possible good subarray is [1,2] since the values 1 and 2 occur at most once in this subarray. Note that the subarray [2,1] is also good.
It can be shown that there are no good subarrays with length more than 2.

Example 3:

Input: nums = [5,5,5,5,5,5,5], k = 4
Output: 4
Explanation: The longest possible good subarray is [5,5,5,5] since the value 5 occurs 4 times in this subarray.
It can be shown that there are no good subarrays with length more than 4.


Constraints:

1 <= nums.length <= 10^5
1 <= nums[i] <= 10^9
1 <= k <= nums.length

### Format: You will use the following starter code to write the solution to the problem and enclose your code within delimiters.
```python
class Solution:
def maxSubarrayLength(self, nums: List[int], k: int) -> int:

```

### Answer: (use the provided format with backticks)

With this kind of preamble and explicit instructions to the ‘coding assistants’, you may as well just write the code yourself. Even if further brevity is usually ‘good enough’, the need to spend all that time and effort just to get the answer that you know you were looking for. Even a junior developer wouldn’t need this much hand holding.

In this regard, the other uses that people have mentioned, such as bouncing ideas off the chatbot — “rubber ducking” — has merit, but often even talking to potted plants or going on that walk around the block can do just about as much with getting one’s thoughts in order, along with random web searches.

Whether to use “micro prompts” or larger tasks, whether to use the chatbot as a search engine or not, and whether to correct answers to previous prompts are all details that seem to be highly divisive among users of these tools, as is the topic of vibe coding, which some seem to embrace, while others dismiss it as an insult for their artisanal craftwork.

Local Models

There are many more things to cover here, such the use of local models vs these hosted ones, with all the gotchas of subscriptions, private data harvesting and the like that this entails, but that will have to wait for another article. It’s also interesting how much the subscription and usage fees (and limitations) are currently going up across the various services, making the idea of local models seem more attractive, if they are even worth it with such limited inference capacity available.

Suffice it to say that I have learned some things along the way of writing this article, while not changing my overall premise and conclusion of the previous article. Although I could have certainly picked a theoretically better model, this is hard to to substantiate without pitting the models against each other in STM32 CMSIS and Ada coding challenges. Based on the results in Python it’s hard to make the claim that it would have made an amazing distinction, but maybe not using a ‘mini’ model makes all the difference here?

Hopefully the better models won’t be removed from free access before I can even give this idea a shot.

There’s not much more nostalgic for many than good ole’ Jimmy Neutron. This was true for [Kiara], who saw the gorgeous pupper Goddard and wanted him for herself. Of course, there was no solution other than to make an animatronic version of the robot dog.

Starting with some files ripped from a Jimmy Neutron GameCube game, Goddard was designed digitally before being printed in life size. Of course, for a true reproduction of the robot dog, the parts had to be prepped and painted in the iconic chrome and purple. A real plasma ball was used for the brain, and linear actuators were used for the legs. The head was able to be moved around similarly to professional animatronics using fishing line and servos. Put together the entire finished pup, looks incredible.

[Kiara] isn’t a stranger to the animatronic world, and Hackaday isn’t a stranger either. If you want to see some other funky animatronics to bring fiction to life make sure to check out the singing Magikarp. Or if you are wanting something a bit more serious, check out the dystopian work from Danny Huynh!