Some of the prior art that went into this project includes Ping Pong Plus Plus, an augmented-reality-ish implementation of ping pong that puts projected light wherever a ping pong ball hits the table. The game does this by mounting piezos to the bottom of a table and just a slight bit of math to determine where on the table the ball hit. There’s also MicLoc, a door lock that responds to knocking.
With this prior art, it’s all about microcontrollers and peripherals, and for that, [Ben] turned to the STM32F303RE, which sports four very fast ADCs and op-amps. There’s a lot of DMA usage on there, and the code is using a ton of signal processing. The important bit here is finding the difference between whatever the tabletop equivalent to an earthquake’s P-waves and S-waves are — [Ben] only wants the first bit of a waveform that travels through the table longitudinally, not the much louder vibrations of the entire table.
If [Ben] manages to put this together, an entire wall could be a light switch or a dimmer. You could add a secret knock to your door, and your desk could control your computer. It’s a promising idea, and the engineering that’s going into this project is just fantastic.
There were so many amazing unofficial badges at DEF CON this year that I can’t possibly cover them all in one shot. I tried to see every badge and speak with every badge maker — like a hardware safari. Join me after the jump for about fourteen more badges that I saw at DEF CON 26!
You can plug in a Raspberry Pi, and you can blink a LED. You can visualize data, and now there’s a contest on Hackaday.io to show off your skills. Right now, we’re opening up the Visualize It With Pi contest on Hackaday.io. The challenge? Visualize data with LED strips and panels. Is that ‘data’ actually just a video of Never Gonna Give You Up? We’ll find out soon enough.
The goal of this contest is to combine a Raspberry Pi and its immense processing power and the blinky goodness of LED strips and panels to visualize and interpret data in novel and artistic ways. We’re looking for animation. clarity, and flamboyant flickering. Want some ideas? Check out the World of Light or the American Constitution Candle. We’re looking for the most blinky you can do with a Pi, and yes, there will be prizes.
Prizes for the best blinky include, of course, more blinky. The best visualizations from a directly connected sensor, data from an Internet Source, and data from an esoteric data source will each receive some Blinkytape. This is a strip of WS2812b LEDs with an ATMega32u4 embedded on the end. Plug a USB power supply into the Blinkytape, and you get a strip of LEDs in whatever color you want with the ability to push animation frames to the chip on the strip. The Grand Prize winner for this contest will also receive Blinkytile Explorers Kit, a Serpentine LED strip, a LED ring, and two meters of ultra thin LED strip.
Let’s Do This!
The requirements for the contest are simple: just use a Raspberry Pi to drive LED strips or panels, post it as a new project on Hackaday.io, and submit the project to the contest. We’re looking for a full description, source, schematics, and photos and videos of the finished version of the project — do everything you can to show off your work! The contest is open right now, and ends at 08:00 Pacific on October 1st. We know you like to blink those LEDs, so get crackin’.
Arguably one of the most difficult aspects of 3D printing is trying to make the finished product look like it wasn’t 3D printed. It can take a lot of time and work to cover up the telltale layer lines (or striations, if you want to get fancy), especially if your 3D printer isn’t perfectly calibrated. While there aren’t many shortcuts to achieve a glass-like finish on 3D printed parts, if your end goal is to make something that looks like stone, [Wekster] has a tip for you.
He demonstrates the technique by building a gorgeous recreation of the main gate from Jurassic Park. The process gives the relatively smooth plastic the gnarled look of rough-hewn stone with very little in the way of manual work. While it’s true there’s no overabundance of projects this stone-look finish will work for, it’s definitely something we’ll be filing away mentally.
So what’s the secret? [Wekster] first coats the 3D printed parts with common wood filler, the sort of stuff available at any hardware store. He then wraps them in clear plastic wrap, allowing the wrap to bunch up rather than trying to pull it taught. For extra detail, he digs into the plastic wrap here and there to create what will appear to be gaps and cracks on the finished piece. The wood filler is then left to dry; a process which normally only takes a few minutes, but now will take considerably longer as the plastic wrap will be keeping the air from it.
Once its hardened and unwrapped, [Wekster] sprays it with a base coat of color, and follows up with a few washings with watered down black and gray paints. This technique is well known to anyone who’s done miniature or model painting; serving to highlight the surface texture and give the finish more depth. With this method, anything that resembles a layer line in the print is long gone, and the surface looks so complex and detailed that at first glance few would believe it’s plastic.
Imagine having to program your computer by rewiring it. For a brief period of time around the mid-1940s, the first general-purpose electronic computers worked that way. Computers like ENIAC initially had no internal storage for code. Programming it involved manipulating thousands of switches and cables. The positions of those switches and cables were the program.
Kathleen Booth began working on computers just as the idea of storing the program internally was starting to permeate through the small set of people building computers. As a result, she was one of the first programmers to work on software and is credited with inventing assembly language. But she also got her hands dirty with the hardware, having built a large portion of the computers which she programmed. She also did some early work with natural language processing and neural networks. And this was all before 1962, making her truly a pioneer. This then is her tale.
We confess. When starting a microcontroller project, we often start with the last one we did for that environment, copy it, and just make changes. And the first one? It — ahem — might have been found on the Internet. There’s a lot more than just your code that goes into this. If you want to do (and understand) absolutely everything yourself on an ARM development project, you could use an all-in-one walkthrough. It just so happens [Jacob Mossberg] has a from scratch guide of what you need to do to get your C code running on ARM.
Starting with an ARM Cortex M3, he writes a simple C program and gets the assembly language equivalent. What follows is a detailed analysis of the machine code, exploring what the compiler assumed would be set up. This leads to understanding of what the start up code and linker script needs to look like.
It is a great approach and reminded us of the old saying about “teach someone how to fish.” He even devotes a little time to talking about getting debugging working with OCD. Of course, the exact details are specific to the chip he’s using, but most of it would apply to any ARM chip. Even if you don’t use ARM, though, the thought process and methodology is itself quite interesting.
This post would be just the thing if you are using Blue Pills and ready to move away from the Arduino ecosystem. Of course, if you want to veer away from the Arduino system, but don’t want to go all the way to bare metal, there’s always mBed.
We’d seen it done with buttons, switches, gestures, capacitive touch, and IR remote, but never like this. [electron_plumber] made an LED that can be blown out like a candle, and amazingly it requires no added sensors. The project uses an Arduino to demonstrate turning a tiny LED on and off in response to being blown on, and the only components are the LED and a resistor.
How is this done? [electron_plumber] uses an interesting property of diodes (which are the “D” in LED) to use the LED itself as a temperature sensor. A diode’s voltage drop depends on two things: the current that is being driven through the diode, and the temperature. If the current is held constant, then the forward voltage drop changes reliably in response to temperature. Turning the LED on warms it up and blowing on it cools it off, causing measurable changes in the voltage drop across the device. The change isn’t much — only a handful of millivolts — but the effect is consistent and can be measured. This is a principle [Elliot Williams] recently covered in depth: using diodes as temperature sensors.
It’s a clever demo with a two important details to make it work. The first is the LED itself; [electron_plumber] uses a tiny 0402 LED that is mounted on two wires in order to maximize the temperature change caused by blowing on it. The second is the method for detecting changes of only a few millivolts more reliably. By oversampling the Arduino’s ADC, an effectively higher resolution is obtained without adding any hardware or altering the voltage reference. Instead of reading the ADC once, the code reads the ADC 256 times and sums the readings. By working with the larger number, cumulative changes that would not register reliably on a single read can be captured and acted upon. More details are available from [electron_plumber]’s GitHub repository for LEDs as Sensors.
Embedded below is a video that is as wonderful as it is brief. It demonstrates the project in action, takes a “show, don’t tell” approach, and is no longer than it needs to be.