A Pocket-Sized Digital Fish Tank

The problem with trying to make a fish tank fit in your pocket is that you’ll either end up with water everywhere or a bunch of dead fish. Perhaps that’s why [StratoBuilds] pursued a digital solution instead.

The concept behind Pocket Tank is relatively simple—it’s a small device that displays a virtual tank with a bunch of little fish swimming around inside. It’s based on the Waveshare ESP32-S3-Touch-AMOLED-1.8, which, if you’re wondering, is an ESP32-S3 with a 1.8″ screen attached, all wrapped up in a convenient plastic housing.

Thanks to the powerful microcontroller, there’s plenty of grunt on tap to run and display a small simulated fish tank. [StratoBuilds] whipped up a system wherein fish movement and animations are handled by regular code running at 25-30 fps, while the fish’s decision making is handled by a custom large language model that was condensed down to run on the ESP32 itself. As the fish swim around the tank, the situation is observed by the LLM and the fish’s current goals are changed accordingly depending on what’s going on. Much like a Tamogotchi, there are regular maintenance tasks for the user to handle, too, like cleaning the tank and feeding the fish to keep them alive.

The blog post and YouTube video do a great job of explaining the project; files are on GitHub for those that wish to tinker more directly. It’s funny, because when we normally look at fish tanks, we’re talking about real ones.

Continue reading “A Pocket-Sized Digital Fish Tank” →

The Least Annoying Of All Evils

If you missed the hubbub this week, it was discovered that the Raspberry Pi Foundation added code in the firmware that locks the boot process up if non-original RAM chips are detected onboard. Hot-rodding your Pi is a time-honored tradition in these parts. We do wonder just how many folks are taking the risk of hot-airing the memory off the board, versus paying the extra cash to get one with more RAM. But according to Raspberry Pi, enough boards are showing up that have the RAM surreptitiously replaced, and often defective, that they took the step to lock the machine down.

Should users be alerted to potentially unscrupulous behavior by the companies selling them single-board computers? I think we’d all say “sure”. But should that entirely brick the device? And prevent people from upgrading their own? The hacker in me says “no”. Is there any way to reconcile these two? Our own [Arya Voronova] suggests that it’s no big deal to flash an older version of the initial firmware, and we concur, although it does leave behind all the improvements since 2023, and it will only get less fresh as time goes by.

How to announce that the board has non-factory memory without breaking it? [Jeff Geerling] suggested a non-matching-memory bit that users could check, but then they could also neglect to check. My cellphone has a screen that appears every bootup, and requires me to press the power button to continue, because I rooted the phone and installed an open-source OS. It’s a hassle for sure, but it’s a lot better than bricking the phone or disallowing user firmware entirely.

Doing the same thing for the Raspberry Pi isn’t as easy. You never know what, if any, peripherals are connected, so you can’t guarantee that there’s a screen to alert you or even necessarily a keyboard on which you could acknowledge. We’re reminded of a similar situation with FTDI USB-to-serial converter chips ages ago. Their driver software simply refused to work with counterfeit versions of their chips. Hackers were up in arms, largely because we couldn’t know if the parts were genuine at purchase time, and the counterfeits were widely distributed even by reliable resellers.

So what about it? Can you think up a tamper-evident signal that could run on boot on a Raspberry Pi, maybe a headless system installed in some difficult-to-reach place? Maybe ideally the equivalent of the cell phone’s scare message? It would have to be hard to overlook, but keep the machine running, notifying the user that things aren’t kosher, but not preventing them from getting to work. Sounds like a tall order to us.

You Can Make A Microprocessor That’s All Your Own

For a while now we’ve followed the slow progression of affordable integrated circuit fabrication, and through the likes of Tiny Tapeout we’ve seen impressive strides made. But they’re not the only player in the space, and [Breaking Taps] has a video showing their microprocessor built using wafer.space.

The microprocessor itself is a little unusual, being a transport triggered architecture design with two busses. The whole thing might better be described as a system-on-chip than a microprocessor, as like a microcontroller it contains both memory and peripherals. He’s used Spade to design the thing, and we get an in-depth look at all the steps involved between design and fabrication. It’s a level or two more difficult than passing the DRC standards for your PCB fabricator. The result is a chip carrier with the chip itself visible under clear epoxy. It’s using an old fabrication technology so the silicon is surprisingly big, but unlike Tiny Tapeout’s cell based fabrication the whole chip is the one circuit. Mounting it on a PCB and using a breadboard, he’s able to demonstrate it running simple programs.

It’s clear that having your own IC fabricated is not for everyone, as even though wafer.space has performed minor miracles it’s still a service for people with a few dollars in hand. But look at it this way, we’re still near the start of this particular curve, and we expect that further affordability breakthroughs will follow.

Continue reading “You Can Make A Microprocessor That’s All Your Own” →

Easy Ways Sink A Hardware Startup

[Ryan Walker] may have written up his observations a few years ago, but the lessons are just as relevant today as they were back then. He shares five easy ways to sink your hardware startup.

It’s a reminder that while hardware startups are unique, there are basic business realities that still apply because the hardware itself is going to be only one part of a whole. These business fundamentals can be a drag, but it’s worth giving them some attention. But if that’s not your jam, no worries. As [Ryan] experienced, they will explain themselves one way or another.

A good one is skipping market research. Do customers actually exist for this thing? Or forgoing market testing — do the customers actually want it enough to pay for it? One of the worst things to be stuck with is a product that everyone likes, but nobody wants to buy.

Premature optimization is another good one that a number of our readers can probably relate to in one way or another. It’s one thing to buy a tool or a part that one doesn’t end up needing, but when that gets scaled up it can put a real dent in a fledgling business’s development.

We’ve also shared insights on what it takes to develop a product and get it out there, whether as a solo entrepreneur or as part of a larger team, to help nudge the process toward success.

Abusing SQL To Play DOOM

Most laypeople who encounter SQL think of it purely as a tool for managing large datasets. While that is certainly what it was designed for, SQL is still a programming language at its core. It includes many of the features found in general-purpose languages like C or Python, and although it wasn’t built for general-purpose work, it can handle a surprising range of tasks that programmers might not expect to use it for. To demonstrate its capabilities, and perhaps to show off their skills with SQL, a group at CedarDB ported the original DOOM to this language.

The project stores the WAD data (essentially everything except the engine) in a series of tables, which was fairly straightforward compared to the rest of the project. Where it gets more complicated is managing the timing that ties the game to 35 fps, and of course rendering the images. Their rendering process takes up 1300 lines of SQL across 89 common table expressions (CTEs) which is certainly advanced for this language. The rest of the project is another 4000 lines of SQL, with a bit of Python to handle the keyboard inputs, timing, and display of the generated bitmap.

Perhaps counterintuitively, DOOM might be the perfect game to run on SQL. It was built in an era before dedicated graphics cards and isn’t truly 3D, meaning that the programmers had to do a lot of tricks to get it to look as if it is 3D. This results in a lot of data transformations uniquely suited to SQL. It’s almost like DOOM‘s original renderer was built by someone with extensive SQL knowledge in the first place. For those looking to try this out, the source code for the project is available on a GitHub page, and for some other unique implementations of DOOM there’s also this version built in regular expressions and this one in Microsoft Word.

The Low-Level Waste Dumps In The Atlantic Have Become Ecosystems

Dumping of the barrels into the Atlantic. (Credit: Greenpeace, Pierre Gleizes)
Dumping of the barrels into the Atlantic. (Credit: Greenpeace, Pierre Gleizes)

Recently French and international researchers took a look at the state of the thousands of barrels of radioactive waste that were dumped into the Atlantic Ocean between 1950 and 1990, trying to ascertain the state of this waste and its effect on the ecosystem.

Although a lot of fuss is made of the spent uranium fuel and high-level waste produced by light water reactors and fuel reprocessing facilities, the overwhelming majority of nuclear waste is low- and intermediate-level waste (LLW and ILW) churned out by hospitals, laboratories and various industries.

Due to the sheer volume of this waste over the decades creative ways have been sought to dispose of it, which include burying in landfills and incinerating.

For a while tossing such waste into the ocean was also deemed to be an excellent destination for LLW and ILW, with the latter especially encapsulated in bitumen or cement. This was the poured into the barrels that many people have come to associate with nuclear waste in general. Since the approximately 200,000 tons of such barrels and similar were tossed into the Atlantic Ocean decades ago the question was where they ended up and their state.

The Radiocean mission site lists the objectives, including the mapping of the sites and identifying the elements of the ecosystems in addition to any radioisotope levels and their effect on said ecosystems. As it turns out, although the barrels have definitely degraded and their contents are slowly collapsing, the local ecosystems seem to have adapted well, treating the dump sites more as convenient shelters rather than a hazard. Some more photos can be found on the Bluesky account of [Javier Escartin].

None of this should come as a surprise if you are aware of just how much radioactive material is already dissolved naturally in the oceans, with much more uranium present in seawater than can be mined on-shore. Although the introduction of isotopes that are not part of the normal thorium and uranium decay chains into the ocean is of course undesirable, it’s good to know that this rather haphazard treatment of LLW and ILW has apparently just resulted in some Atlantic Ocean floor critters ending up with an interesting reef.

Reviving The PoE++ Feature On A Ubiquiti Switch

Recently [The Parallel Port] was asked to take a look at repairing the PoE++ feature on a Ubiquiti switch that otherwise worked fine. This is a pretty nice 24-port rackmounted switch with 2.5 Gbit-capable RJ-45 ports and two 10 Gbit SFP+ ports, so by itself it’s pretty useful, but having the 400 Watt PoE feature just go AWOL still stings, especially if you bought it new for $800.

With power applied the switch starts up as normal, including its 1.3″ touch screen that provides direct port information as well as a fancy screensaver cum QR code for the AR feature.

After logging into the switch’s BusyBox console it showed that all ports reported bad for the PwrGood status, and there were PoE power status request errors in the log, but this could be just the consequence of something else. Using a PoE splitter it was confirmed that the PoE functionality was indeed dead.

After disassembly and some testing with a multimeter and thermal camera, a short and related hot spot on the PCB that the PoE power board connects to was identified, with the short persisting after removing this PCB from the switch. Since the switch had suffered a bit of an electrical event the TVS diode was checked, but it turned out to be fine.

Next to it, marked as fuses, were protective thyristor surge protection devices (Trisil), functioning as a crowbar device. These aren’t supposed to be shorted to ground until a surge event occurs, but these were indeed both shorted when measured directly. Clearly they had taken the brunt of the electrical event and sacrificed themselves in the process.

One replacement later of these devices the switch now happily reports a good PoE status and even was able to power a DC fan via the PoE splitter. Even if it wasn’t a particularly hard fix, this is definitely one of those cases where knowing how the protective circuit works can save a lot of time in diagnosing and fixing a fault.

Continue reading “Reviving The PoE++ Feature On A Ubiquiti Switch” →