Building An Army Of Faux Cameras In The Name Of Art

August 10, 2021 by Tom Nardi 9 Comments

After taking mental note of the number of surveillance cameras pointed at him while standing in line at the local Home Depot, [Mac Pierce] was inspired to create A Scanner Darkly. The art installation uses beams of light projected by mock security cameras to create a dot-matrix character display on the opposing wall, which slowly blinks out US surveillance laws and regulations.

[Mac] has put together an extensive behind the scenes look at how he created A Scanner Darkly, which among other things covers the incredible time and effort that went into producing the fifteen identical cameras used to project the 3×5 grid. Early on he decided on 3D printing each one, as it would give him complete control over the final result. But given their considerable size, it ended up taking 230 hours and 12 kilograms of PLA filament to print out all the parts. It took a further 55 hours to sand and paint the camera housings, to make sure they didn’t actually look like they’d been 3D printed.

Internally, each camera has an off-the-shelf LED flashlight that’s had its power button rigged up to an ESP8266. Once they’ve been manually pointed to the appropriate spot on the wall, [Mac] can turn each camera’s spotlight on and off over WiFi. Rather than rely on the gallery’s infrastructure, all of the cameras connect to the ESP32 M5Stack that serves as the central controller via ESP-Now.

From there, it was just a matter of writing some code that would load a text document from the SD card, convert the current character into a 3×5 array, and then command the appropriate cameras to turn their lights on or off. [Mac] has not only provided the STL files for the 3D printed camera, but the client and server Arduino code to control the lights. Combined with his excellent documentation, this makes A Scanner Darkly something of a viral art piece; as anyone with the time and appropriate tools can either duplicate the installation or use it as a base for something new.

While some will no doubt argue that [Mac] could have completed this project far faster had he just modified some commercial dummy cameras, it’s important to remember that as an artist, he had a very specific look in mind for A Scanner Darkly. This project is a perfect example of how a creator’s passion can take an idea to new heights, and we think the end result proves it’s worth the time and sweat to put in the extra effort.

Continue reading “Building An Army Of Faux Cameras In The Name Of Art” →

Tamagotchis Everywhere

August 10, 2021 by Matthew Carlson 15 Comments

Tamagotchi’s relatively simple technical complexity pales in comparison to its huge cultural impact, with over 76 million sold. It has spawned comics, stories, numerous toys, and offshoots such as an anime and two films. [JC] was looking through some of his old stuff and came across a Tamagotchi P1 (the original Tamagotchi) and decided to create a portable emulator for it. The ROM for the P1 has long been dumped and can be run within a MAME emulator. After all, it’s just an E0C6S46 Epson MCU, 32×16 LCD with 8 additional icons, three buttons, and a piezo. The manual for the MCU is even available on Epson’s website. Here at Hackaday, we’ve seen Tamagotchis many times before, such as the infinite matrix of the Tamagotchi Singularity and a ROM dump of the latest generation of Tamagotchi based on a 6502 core.

So what’s different about what [JC] is trying to accomplish? For starters, the tooling. It is divided into two parts: TamaLIB and TamaTool. The first is a hardware-agnostic P1 emulation library that relies on a HAL layer to communicate with the hardware. The second is a frontend for the first, allowing debugging, RAM editing, and modifications to the ROM. In particular, it supports easy modification of images within the ROM and allows for custom eggs and Tamagotchis. The homage to the Jolly Wrencher is nice.

Given that the emulation is platform-agnostic and access to a low-resolution timer is not guaranteed, cycle counts become tricky. The rather clever solution [JC] stumbled upon was synchronizing against input polling, screen updates, and sound output. TamaLIb keeps track of how many CPU cycles have passed and regularly checks if the emulation is going too fast or too slow. Slowing down or speeding up the simulation allows it to seem to run in real-time.

The last goal [JC] had was to run it on embedded hardware. Using an STM32F072 board and a cheap OLED screen had a portable emulated Tamagotchi known as MCUGotchi. The code is available on GitHub and should work on most STM32 MCUs with a few small tweaks. Now that someone has gone through the effort to make it easy to run a Tamagotchi literally anywhere, it might not be long until we see a coffee maker or a smart light acting as a Tamagotchi. Perhaps the new joke will be, can it run Tamagotchi?

Video after the break.

Continue reading “Tamagotchis Everywhere” →

Improving OLED VU Meters With A Little Physics

August 9, 2021 by Tom Nardi 23 Comments

Last month we featured a project that aimed to recreate the iconic mechanical VU meter with an Arduino and a common OLED display. It was cheap and easy to implement, and promised to bring a little retro style to your otherwise thoroughly modern project.

[sjm4306] liked the idea, but thought it was a tad too stiff. So he’s been experimenting with adding some physics to the meter’s virtual needle to better approximate the distinctive lag and overshoot that’s part and parcel of analog indicators. Obviously it’s something that can only be appreciated in motion, so check out the video below for an up-close look at his quasi-retro indicator.

Unfortunately there’s no code for you to play with right now, but [sjm4306] says he’ll release it on the project’s Hackaday.IO page once he’s cleaned things up a bit. We know it will take more than a few wiggling pixels to pry real analog indicators out of some hacker’s tool boxes, but anything that helps improve the digital approximation of this sort of vintage hardware is a win in our book. Continue reading “Improving OLED VU Meters With A Little Physics” →

Wristwatch PCB Swaps Must Be In The Air

August 8, 2021 by Mike Szczys 19 Comments

Are we seeing more wristwatch PCB swapping projects because more people are working on them, or because we saw one and they’re on our mind? The world may never know, but when it comes to design constraints, there’s a pretty fun challenge here both in fitting your electronic wizardry inside the confines of an injection molded case, and in the power budget to make your creation run on a sippy straw of battery power.

Just this morning we came across [Joey Castillo’s] sensor-watch project. He chose the Casio F-91W as the donor wristwatch. It’s got that classic Casio look of a segment LCD display capable of displaying hours, minutes, and seconds, as well as day and date. But the added bonus is that we know these have decent water resistance while still providing three buttons for user input. Sure, it’s less buttons than the pink calculator watch we saw [Dave Darko] working on earlier in the week, but which would you trust in the pool?

Replacement PCB sized to use the same battery contact and CR2016 for power [via @josecastillo]

We see that [Joey] also chose to use the ATSAML22 microcontroller and sheds some light on why: it includes a built-in segment LCD controller! If you’re a peripheral geek like us, you can read about the SLCD controller on page 924 of the datasheet (PDF), it’s a whole datasheet onto itself.

The sensor part of the sensor-watch is a flex PCB breakout that allows you to swap in whatever sensor fits your needs. The first to be reflowed at [Joey’s] bench is a BME280 humidity sensor, which is most obviously useful for the included temperature measurements, but maybe it could also alarm at moisture ingress? [Joey] says you can swap in other parts as long as they’re in the QFN or LGA size range. We think an IMU is in order since there’s a lot of fun interaction there like the watch reacting to being positioned in front of your face, or to take tap-based inputs.

We think beginning with a donor watch is brilliant since pulling off a case, especially one that keeps water out, is 97% of the battle. But when your UI is unique to the watch world, sometimes you need to start from scratch like this wooden word clock wristwatch.

Raspberry Pi Pico Used As A Transputer

August 5, 2021 by Mike Szczys 43 Comments

You can’t fake that feeling when a $4 microcontroller dev board can stand in as cutting-edge 1980s technology. Such is the case with the working transputer that [Amen] has built using a Raspberry Pi Pico.

For a thorough overview of the transputer you should check out [Jenny List’s] longer article on the topic but boiled down we’re talking about a chip architecture mostly forgotten in time. Targetting parallel computing, each transputer chip has four serial communication links for connecting to other transputers. [Amen] has wanted to play with the architecture since its inception. It was expensive back then and today, finding multiple transputers is both difficult and costly. However, the RP2040 chip found on the Raspberry Pi Pico struck him as the perfect way to emulate the transputer design.

The RP2040 chip on the Pico board has two programmable input/output blocks (PIOs), each with four state machines in them. That matches up perfectly with the four transputer links (each is bi-directional so you need eight state machines). Furthermore, the link speed is spec’d at 10 MHz which is well within the Pico’s capabilities, and since the RP2040 runs at 133 MHz, it’s conceivable that an emulated core can get close to the 20 MHz top speed of the original transputers.

Bringing up the hardware has been a success. To see what’s actually going on, [Amen] sourced some link adapter chips (IMSC011), interfacing them through an Arduino Mega to a computer to use the keyboard and display. The transputer architecture allows code to be loaded via a ROM, or through the links. The latter is what’s running now. Future plans are to figure out a better system to compile code, as right now the only way is by running the original INMOS compiler on DOS in a VM.

Listen to [Amen] explain the project in the first of a (so far) six video series. You can find the links to the rest of those videos on his YouTube channel.

Continue reading “Raspberry Pi Pico Used As A Transputer” →

Knowing The Bits And Bytes That Make Images Live In Memory

August 5, 2021 by Mike Szczys 16 Comments

We know we’re living in the future because there’s hi-resolution, full color images plastered on every high-density screen in sight. Of course this comes at a cost, one that’s been hidden away by the myriad improvements in the way we digitally represent those pretty pixels and how we push them to the screens. Nobody thinks about this, except those who are working behind the screen to store and light up those pixels. And hey, chances are that’ll be you some day. Time to learn a bit more about image encoding!

Test renders illustrate the time savings from premultiplied alpha formats

[Scott W Harden] put together a succinct primer on representing images in memory. It focuses on the basics of how images are stored: generally with the B before the G, sometimes including an alpha (transparent) channel, and with a number of different bit depths. Having these at the front of your mind is crucial for microcontroller projects, where deciding what types of images to support is often limited by the amount of memory available for frame buffers, and the capabilities of the screen chosen as the device’s display.

Speaking of display specifics, [Scott] shares some detail about mapping the memory to the dimensions of your screen. If the byte count of pixel data doesn’t line up nicely with the dimensions of the screen, padding the rows out may help in the processing overhead it takes to get those pixels onto the screen. He also has some tips about “premultiplied alpha” which makes the transparency calculation a part of the image itself, rather than demanding this be done when trying to update the screen. Running a test in C# on one million frame renders shows the type of savings you can expect.

Decades of trial and error landed us with these schemes. Looking back is literally an archaeology project, as one hacker discovered when trying to get a set of digital images off of a floppy from a 1990s photo processing service.

Working LEGO Space Computers Are A Chip Off The Old Block

August 4, 2021 by Kristina Panos No comments

We all have our favorite classic LEGO bricks, and wouldn’t be surprised if one or more of the various space computers showed up on pretty much everyone’s list. [dyoramic] loves them so much that they built two different working versions that do different things.

The first one is about six times the size of the original brick. Inside the 3D printed case is an ESP32 and a 1.5″ OLED display. [dyoramic] wired up the top six buttons as inputs and the rest are just for looks. The screen defaults to the classic white cross on green that just sits there looking legit. But start pushing buttons and you’ll find other modes — the cross becomes a radar screen in one, the computer spits out space facts in another, there’s a falling bricks game, and finally, a time and date screen.

The second LEGO space computer build is even bigger — both were designed around the size of their screens. It has a Raspi 4 and shows a dashboard with the weather, time, date, latest xkcd, and a few cryptocurrency prices. [dyoramic] has an even bigger version in the works that will use a 720 x 720 screen and a handful of brown key switches as inputs. We can’t wait to see that one! For now, check out the build and demo of the first two after the break.

What can’t you do with LEGO? It feels like we’ve seen it all, from cameras to microscopes to continuously variable transmissions. Wouldn’t you love to drive one of those around the block?

Continue reading “Working LEGO Space Computers Are A Chip Off The Old Block” →