Receipt paper mural from above eye level

Massive Mural From Thermal Receipt Paper

Turning trash into art is something we undoubtedly all admire. [Davis DeWitt] did just that with a massive mural made entirely from discarded receipt paper. [Davis] got lucky while doing some light dumpster diving, where he stumbled upon the box of thermal paper rolls. He saw the potential them and, armed with engineering skills and a rental-friendly approach, set out to create something original.

The journey began with a simple test: how long can a receipt be printed, continuously? With a maximum length of 10.5 feet per print, [Davis] designed an image for the mural using vector files to maintain a high resolution. The scale of the project was a challenge in itself, taking over 13 hours to render a single image at the necessary resolution for a mural of this size. The final piece is 30 foot (9.144 meters) wide and 11 foot (3.3528 meters) tall – a pretty conversational piece in anyone’s room – or shop, in [Davis]’ case.

Once the design was ready, the image was sliced into strips that matched the width of the receipt paper. Printing over 1,000 feet of paper wasn’t without its issues, so [Davis] designed a custom spool system to undo the curling of the receipts. Hanging the mural involved 3D-printed brackets and binder clips, allowing the strips to hang freely with a kinetic effect.

Though the thermal paper will fade over time, the beauty of this project lies in its adaptability—just reprint any faded strips. Want to see how it all came together? Watch the full process here.

Continue reading “Massive Mural From Thermal Receipt Paper”

Your Undocumented Project May Also Baffle People Someday

What’s life without a little mystery? There’s one less rolling around after historians finally identified a donated mystery machine that had been in storage for years.

Feeding dough through this machine may have been faster, but probably not safer.

The main pieces of the machine are about a century old and any staff who may have known more about the undocumented device were no longer around to ask. The historical society finally posted pictures and asked for any insights, which eventually led to solving the mystery.

The machine is in all likelihood a beaten biscuit maker, which was a type of dense baked good popular in the American south. Making them called for a long and labor-intensive process of pounding and working the dough, and the society says this machine was likely created by a fellow trying to help his aunt streamline her business, offloading the labor of working the dough to a machine.

The machine had no branding of any sort and lacked any identifying marks. Its purpose was doubtlessly obvious at the time, but no records remained and quite possibly none existed in the first place. Sound familiar? Perhaps someday our own undocumented projects and prototypes will mystify people. It’s certainly happened in the case of mysterious Roman dodecahedrons, which remain a head-scratching mystery.

A Robot Meant For Humans

Although humanity was hoping for a more optimistic robotic future in the post-war era, with media reflecting that sentiment like The Jetsons or Lost in Space, we seem to have shifted our collective consciousness (for good reasons) to a more Black Mirror/Terminator future as real-world companies like Boston Dynamics are actually building these styles of machines instead of helpful Rosies. But this future isn’t guaranteed, and a PhD researcher is hoping to claim back a more hopeful outlook with a robot called Blossom which is specifically built to investigate how humans interact with robots.

For a platform this robot is not too complex, consisting of an accessible frame that can be laser-cut from wood with only a few moving parts controlled by servos. The robot is not too large, either, and can be set on a desk to be used as a telepresence robot. But Blossom’s creator [Michael] wanted this to help understand how humans interact with robots so the latest version is outfitted not only with a large language model with text-to-speech capabilities, but also with a compelling backstory, lore, and a voice derived from Animal Crossing that’s neither human nor recognizable synthetic robot, all in an effort to make the device more approachable.

To that end, [Michael] set the robot up at a Maker Faire to see what sorts of interactions Blossom would have with passers by, and while most were interested in the web-based control system for the robot a few others came by and had conversations with it. It’s certainly an interesting project and reminds us a bit of this other piece of research from MIT that looked at how humans and robots can work productively alongside one another.

A Laser With Mirrors Makes A CRT-like Display

[bitluni]’s laser-based display pretending to be a an old-school vector CRT.
Phosphor-based displays like CRTs rely on the phosphor to emit light for a set amount of time after being activated, allowing them to display a seemingly persistent image with one drawing beam per color. Translated to UV-sensitive PLA filament, this means that you can totally use a printed sheet of this material in combination with a 405 nm laser diode to create a display that doesn’t look dissimilar to an early CRT. This is exactly what [bitluni] did in a recent video, meshing together said laser diode, UV-sensitive PLA, stepper motors and two mirrors with an Arduino-based controller to create a rather interesting vector display.

In the video, [bitluni] goes over the development steps, including a range of improvements like being able to turn off the laser when moving between the end of a line and the beginning of a new one. While the Arduino Nano board does the driving of the stepper motor controllers, an ESP32 provides the drawing instructions. The STL and other project files including Nano & ESP32 firmware can be found on the GitHub project page.

While far from being a practical display with a single-digit Hz refresh rate, it does provide an interesting demonstration of these types of persistence of vision based displays, and without the use of exotic MEMS mirror modules or the like.

Continue reading “A Laser With Mirrors Makes A CRT-like Display”

Alternatives Don’t Need To Be Bashed

By default, bash is the most popular command language simply because it’s included in most *nix operating systems. Additionally, people don’t tend to spend a lot of time thinking about whatever their computer uses for scripting as they might for other pieces of software like a word processor or browser. If you are so inclined to take a closer look at this tool that’s often taken for granted, there are a number of alternatives to bash and [monzool] wanted to investigate them closely.

Unlike other similar documentation that [monzool] has come across where the writers didn’t actually use the scripting languages being investigated, [monzool] is planning to use each of these and accomplish specific objectives. This will allow them to get a feel for the languages and whether or not they are acceptable alternatives for bash. Moving through directories, passing commands back and forth, manipulating strings, searching for files, and manipulating the terminal display settings are all included in this task list. A few languages are tossed out before initial testing even begins for not meeting certain specific requirements. One example is not being particularly useful in [monzool]’s preferred embedded environments, but even so there are enough bash alternatives to test out ten separate languages.

Unfortunately, at the end of the day none of the ten selected would make a true replacement for bash, at least for [monzool]’s use case, but there were a few standouts nonetheless. Nutshell was interesting for being a more modern, advanced system and [monzool] found Janet to be a fun and interesting project but had limitations with cross-compiling. All in all though this seemed to be an enjoyable experience that we’d recommend if you actually want to get into the weeds on what scripting languages are actually capable of. Another interesting one we featured a while back attempts to perform as a shell and a programming language simultaneously.

Linux Fu: Audio Network Pipes

Life was simpler when everything your computer did was text-based. It is easy enough to shove data into one end of a pipe and take it out of the other. Sure, if the pipe extends across the network, you might have to call it a socket and take some special care. But how do you pipe all the data we care about these days? In particular, I found I wanted to transport audio from the output of one program to the input of another. Like most things in Linux, there are many ways you can get this done and — like most things in Linux — only some of those ways will work depending on your setup.

Why?

There are many reasons you might want to take an audio output and process it through a program that expects audio input. In my case, it was ham radio software. I’ve been working on making it possible to operate my station remotely. If all you want to do is talk, it is easy to find software that will connect you over the network.

However, if you want to do digital modes like PSK31, RTTY, or FT8, you may have a problem. The software to handle those modes all expect audio from a soundcard. They also want to send audio to a soundcard. But, in this case, the data is coming from a program.

Of course, one answer is to remote desktop into the computer directly connected to the radio. However, most remote desktop solutions aren’t made for high-fidelity and low-latency audio. Plus, it is nice to have apps running directly on your computer.

I’ll talk about how I’ve remoted my station in a future post, but for right now, just assume we want to get a program’s audio output into another program’s audio input. Continue reading “Linux Fu: Audio Network Pipes”

Recreating Unobtainium Weather Station Sensors

Imagine you own a weather station. Then imagine that after some years have passed, you’ve had to replace one of the sensors multiple times. Your new problem is that the sensor is no longer available. What does a hacker like [Luca] do? Build a custom solution, of course!

[Luca]’s work concerns the La Crosse WS-9257F-IT weather station, and the repeat failures of the TX44DTH-IT external sensor. Thankfully, [Luca] found that the weather station’s communication protocol had been thoroughly reverse-engineered by [Fred], among others. He then set about creating a bridge to take humidity and temperature data from Zigbee sensors hooked up to his Home Assistant hub, and send it to the La Crosse weather station. This was achieved with the aid of a SX1276 LoRa module on a TTGO LoRa board. Details are on GitHub for the curious.

Luca didn’t just work on the Home Assistant integration, though. A standalone sensor was also developed, based on the Xiao SAMD21 microcontroller board and a BME280 temperature, pressure, and humidity sensor. It too can integrate with the Lacrosse weather station, and proved useful for one of [Luca’s] friends who was in the same boat.

Ultimately, it sucks when a manufacturer no longer supports hardware that you love and use every day. However, the hacking community has a way of working around such trifling limitations. It’s something to be proud of—as the corporate world leaves hardware behind, the hackers pick up the slack!