Food Irradiation Detector Doesn’t Use Banana For Scale

How do the potatoes in that sack keep from sprouting on their long trip from the field to the produce section? Why don’t the apples spoil? To an extent, the answer lies in varying amounts of irradiation. Though it sounds awful, irradiation reduces microbial contamination, which improves shelf life. Most people can choose to take it or leave it, but in some countries, they aren’t overly concerned about the irradiation dosages found in, say, animal feed. So where does that leave non-vegetarians?

If that line of thinking makes you want to Hulk out, you’re not alone. [kutluhan_aktar] decided to build an IoT food irradiation detector in an effort to help small businesses make educated choices about the feed they give to their animals. The device predicts irradiation dosage level using a combination of the food’s weight, color, and emitted ionizing radiation after being exposed to sunlight for an appreciable amount of time. Using this information, [kutluhan_aktar] trained a neural network running on a Beetle ESP32-C3 to detect the dosage and display relevant info on a transparent OLED screen. Primarily, the device predicts whether the dosage falls into the Regulated, Unsafe, or just plain Hazardous category.

[kutluhan_aktar] lets this baby loose on some uncooked pasta in the short demo video after the break. The macaroni is spread across a load cell to detect the weight, while [kutluhan_aktar] uses a handheld sensor to determine the color.

This isn’t the first time we’ve seen AI on the Hackaday menu. Remember when we tried those AI-created recipes?

What Do You Get When A Raspberry Pi Pico Flashes A Nintendo 64

The joke was when the Nintendo 64 first hit the streets around a quarter century ago, that the 64 in the name referred not to the technology on board, but to the excessive cost of the cartridges. Whatever the truth in that, it’s something now completely laid to rest by [Konrad Beckmann] with his Nintendo 64 flash cart powered by a Raspberry Pi Pico (Nitter Link).

The schematic is surprisingly simple, in that the Pico does everything required to both interface to the N64 and to an SD card to hold the software. The clever work is done by the RP2040 firmware, which can be found along with the hardware details in the “develop” branch of the project’s GitHub repository. And while the earliest version was a Raspberry Pi Pico with a host of jumper wires, the more polished version focuses on a custom PCB and bare RP2040 chip.

Perhaps the N64 hasn’t received the attention it should have over the years, overshadowed as it was by its competitors such as the original PlayStation, but it’s projects like this one which remind us that there’s still life in Nintendo’s ’90s flagship. Speaking of which, if you were on Team Sony back in the day but still want to put your Pi Pico to use, check out this DIY PlayStation Memory Card we covered recently.

Faux-Retro “Tape” Player Runs On ESP32 And 80s Vibes

At first glance, this gorgeous retro-styled audio player built by [Max Kern] could absolutely pass for the genuine article. But then you take a closer look and realize that the “tape” it’s playing is actually an animation running on a 320 x 240 IPS display, and the Play and Rewind buttons on the front aren’t the chunky electromechanical affairs of yesteryear but actually cleverly repurposed MX keyboard switches.

By now you’re probably realizing that this player is quite a bit smaller than you first imagined, which in turn, means that it even its case is a modern fabrication. While it might perfectly encapsulate the look and feel of a piece of 1980s consumer electronics, it was squirted out on a thoroughly modern desktop 3D printer.

Even so, [Max] made sure to include draft angles in the CAD design and and a distinctive separation line so the case looked like it was injection molded. Following similar logic, he decided against using a modern rechargeable battery pack to power the electronics, opting instead for a more era-appropriate set of AA batteries.

In terms of hardware, the custom PCB is home to an ESP32 WROOM, a MAX98357A I2S audio amplifier, a FT231XS USB-to-serial chip, with enough passives and regulators to keep them all well fed and happy. The ESP32 has more than enough computational horsepower to chew through MP3 files, which are conveniently loaded via an SD slot built into the side of the player. As the player was actually intended for audio books, onboard playback is limited to a mono speaker; though there is a 3.5 mm audio jack to plug in a pair of headphones for when the built-in speaker isn’t up to the task.

Check out the video after the break to see how the player is assembled, as well as a demonstration of its simple three-button user interface. It looks like a joy to use, though the lack of fast forward and rewind sound effects took us a bit by surprise given the otherwise impeccable attention to detail. We’ll assume there’s some technical limitation that makes this particularly difficult to implement, and that their absence is currently keeping [Max] up at night.

As impressive as the final product is, we can’t say it’s a surprise. Frankly, we wouldn’t expect anything less from [Max] at this point. His adaptive OLED macro pad wowed us back in 2020, and his ZeroBot is still one of the slickest designs for a DIY two-wheeled robots we’ve ever seen.

Continue reading “Faux-Retro “Tape” Player Runs On ESP32 And 80s Vibes”

Plastic CPUs Will Bend To Your Will

As microcontroller prices drop, they appear in more things. Today you will find microcontrollers in your car, your household appliances, and even kid’s toys. But you don’t see them often embedded in things that are either super cheap or have to flex, such as for example a bandage. Part of the reason is the cost of silicon chips and part of the reason is that silicon chips don’t appreciate bending. What if you could make CPUs for less than a penny out of flexible plastic? What applications would that open up? PragmatIC — a company working to make this possible — thinks it would open up a whole new world of smart items that would be unthinkable today. They worked with a team at the University of Illinois Urbana-Champaign to create prototype plastic CPUs with interesting results.

This is still the stuff of research and dreams, but a team of researchers did work to produce 4-bit and 8-bit processors using IGZO –indium gallium zinc oxide — semiconductor technology. This tech can be put on plastic and will work even if you bend it around a radius as small as a few millimeters.

Continue reading “Plastic CPUs Will Bend To Your Will”

Blinking An Arduino LED, In Julia

The Julia programming language is a horrible fit for a no-frills microcontroller like the ATMega328p that lies within the classic Arduino, but that didn’t stop [Sukera] from trying, and succeeding.

All of the features that make Julia a cool programming language for your big computer make it an awful choice for the Arduino. It’s designed for interactivity, is dynamically typed, and leans heavily on its garbage collection; each of these features alone would tax the Mega to the breaking point. But in its favor, it is a compiled language that is based on LLVM, and LLVM has an AVR backend for C. Should just be a simple matter of stubbing out some of the overhead, recompiling LLVM to add an AVR target for Julia, and then fixing up all the other loose ends, right?

Well, it turns out it almost was. Leaning heavily on the flexibility of LLVM, [Sukera] manages to turn off all the language features that aren’t needed, and after some small hurdles like the usual problems with volatile and atomic variables, manages to blink an LED slowly. Huzzah. We love [Sukera’s] wry “Now THAT is what I call two days well spent!” after it’s all done, but seriously, this is the first time we’ve every seen even super-rudimentary Julia code running on an 8-bit microcontroller, so there are definitely some kudos due here.

By the time that Julia is wedged into the AVR, a lot of what makes it appealing on the big computers is missing on the micro, so we don’t really see people picking it over straight C, which has a much more developed ecosystem. But still, it’s great to see what it takes to get a language designed around a runtime and garbage collection up and running on our favorite mini micro.

Thanks [Joel] for the tip!

Diagram of the LTC protocol, showing the difference between 1 bits and 0 bits - both transmitted using one up and one down pulse, but with '1' bit pulses being half as short.

Animate Arcane Protocols With Interrupt-Backed Bitbanging

We often take our “SoftwareSerial” libraries for granted, and don’t investigate what goes on under the hood — until they fail us, at least. Would you like to learn how to harness the power of interrupt-driven bitbanging? [Jim Mack] teaches us how to make our protocol implementations fly using the LTC protocol as a springboard.

LTC (Linear/[Longitudinal] TimeCode) is a widely-used and beautifully-crafted protocol that tends to fly under our radar, and is one that hackers could learn plenty from. It’s used for synchronization of audio/video devices during media production and playback. LTC’s signal is almost digital but not quite: it doesn’t need a clock, and it has no polarity. Additionally, it mimics an audio signal really well, you can decode it at any playback speed, and many other benefits and quirks that [Jim] outlines. You do need to maintain the timings, though, and [Jim]’s article shows us how to keep them right while not inconveniencing your primary tasks.

Continue reading “Animate Arcane Protocols With Interrupt-Backed Bitbanging”

Kved: An Embeddable Key/Value Datastore

At some point when developing embedded applications, you’re going to want to store unique values in non-volatile memory, values that can’t be fixed at compilation time. Many microcontrollers have a small amount of EEPROM memory for this very purpose, but it’s usually rather limited if it’s provided at all. Even if you do have a bit of space on an EEPROM at your disposal, actually formatting your values into the memory and dealing with the pesky problem of wear leveling (necessary for parameters that need to change often) can be a bit of a hassle.

Lucky for us, [Marcelo Barros] decided to share his own implementation, Kved (key/value database) which uses the flash memory instead for such storage. Kved implements a dictionary type data structure, using numeric keys and values, supporting a few integer types. Using the library should be straightforward enough, as [Marcelo] says, all you need are a pair of spare flash sectors and the ability to port the flash the sector read, write, and erase functions. There are plenty of examples of such code available for practically any microcontroller out there, so that should be no barrier. For those who want to play with it right now, the repo currently has ports for the STM32L433RC and STM32F411CE, as well as a simulated version you can compile and run on your computer.

From an implementation perspective, the write algorithm uses a COW (Copy On Write) method. Changed values are invalidated by over-writing the storage location with all-zeros, and re-writing the changed value to a new location, cycling through the unused locations until the sector is full. Data-integrity mechanisms are implemented, preventing corruption of the data structure due to power fail situations, so incorrectly written values will be corrected on start-up and not affect the integrity of the configuration.

When looking around, we found a similar project, Embedis, over on hackaday.IO, as well as this article on the subject of embedded filesystems from a little while back.