How often have you stood in the supermarket wondering about the inventory level in the fridge at home? [Mike] asked himself this question one time too often and so he decided to install a webcam in his fridge along with a Raspberry Pi and a light sensor to take a picture every time the fridge is opened — uploading it to a webserver for easy remote access.
Building a marble run has long been on my project list, but now I’m going to have to revise that plan. In addition to building an interesting track for the orbs to traverse, [Jack Atherton] added custom sound effects triggered by the marble.
I ran into [Jack] at Stanford University’s Center for Computer Research in Music and Acoustics booth at Maker Faire. That’s a mouthful, so they usually go with the acronym CCRMA. In addition to his project there were numerous others on display and all have a brief write-up for your enjoyment.
[Jack] calls his project Leap the Dips which is the same name as the roller coaster the track was modeled after. This is the first I’ve heard of laying out a rolling ball sculpture track by following an amusement park ride, but it makes a lot of sense since the engineering for keeping the ball rolling has already been done. After bending the heavy gauge wire [Jack] secured it in place with lead-free solder and a blowtorch.
As mentioned, the project didn’t stop there. He added four piezo elements which are monitored by an Arduino board. Each is at a particularly extreme dip in the track which makes it easy to detect the marble rolling past. The USB connection to the computer allows the Arduino to trigger a MaxMSP patch to play back the sound effects.
For the demonstration, Faire goers wear headphones while letting the balls roll, but in the video below [Jack] let me plug in directly to the headphone port on his Macbook. It’s a bit weird, since there no background sound of the Faire during this part, but it was the only way I could get a reasonable recording of the audio. I love the effect, and think it would be really fun packaging this as a standalone using the Teensy Audio library and audio adapter hardware.
2016 is the year of the consumer 3D printer. Yes, the hype over 3D printing has died down since 2012. There were too many 3D printers at Maker Faire three years ago. Nevertheless, sales of 3D printers have never been stronger, the industry is growing, and the low-end machines are getting very, very good.
Printers are also getting cheap. At CES last January, Monoprice, the same company you buy Ethernet and HDMI cables from, introduced a line of 3D printers that would be released this year. While the $300 resin-based printer has been canned, Monoprice has released their MP Select Mini 3D printer for $200. This printer appeared on Monoprice late last month.
My curiosity was worth more than $200, so Hackaday readers get a review of the MP Select Mini 3D printer. The bottom line? There are some problems with this printer, but nothing that wouldn’t be found in printers that cost three times as much. This is a game-changing machine, and proof 2016 is the year of the entry-level consumer 3D printer.
Continue reading “Review: Monoprice MP Select Mini 3D Printer”
Many of the hacks featured here are complex feats of ingenuity that you might expect to have emerged from a space-age laboratory rather than a hacker’s bench. Impressive stuff, but on the other side of the coin the essence of a good hack is often just a simple and elegant way of solving a technical problem using clever lateral thinking.
Take this project from [drtune], he needed to synchronize some lighting to an audio stream from an MP3 player and wanted to store his lighting control on the same SD card as his MP3 file. Sadly his serial-controlled MP3 player module would only play audio data from the card and he couldn’t read a data file from it, so there seemed to be no easy way forward.
His solution was simple: realizing that the module has a stereo DAC but a mono amplifier he encoded the data as an audio FSK stream similar to that used by modems back in the day, and applied it to one channel of his stereo MP3 file. He could then play the music from his first channel and digitize the FSK data on the other before applying it to a software modem to retrieve its information.
There was a small snag though, the MP3 player summed both channels before supplying audio to its amplifier. Not a huge problem to overcome, a bit of detective work in the device datasheet allowed him to identify the resistor network doing the mixing and he removed the component for the data channel.
He’s posted full details of the system in the video below the break, complete with waveforms and gratuitous playback of audio FSK data.
Continue reading “Synchronize Data With Audio From A $2 MP3 Player”
As buzzwords go, the “Internet of Things” is pretty clever, and at the same time pretty loathsome, and both for the same reason. “IoT” can mean basically anything, so it’s a big-tent, inclusive trend. Every company, from Mattel to Fiat Chrysler, needs an IoT business strategy these days. But at the same time, “IoT” is vacuous — a name that applies to everything fails to clarify anything.
That’s a problem because “IoT Security” is everywhere in the news these days. Above and beyond the buzz, there are some truly good-hearted security professionals who are making valiant attempts to prevent what they see as a repeat of 1990s PC security fiascos. And I applaud them.
But I’m going to claim that a one-size-fits-all “IoT Security” policy is doomed to failure. OK, that’s a straw-man argument; any one-size-fits-all security policy is bound for the scrap heap. More seriously, I think that the term “IoT” is doing more harm than good by lumping entirely different devices and different connection modes together, and creating an implicit suggestion that they can all be treated similarly. “Internet of Things Security” is a thing, but the problem is that it’s everything, and that means that it’s useful for nothing.
What’s wrong with the phrase “Internet of Things” from a security perspective? Only two words: “Internet” and “Things”.
[Sam Miller], [Sahil Gupta], and [Mashrur Mohiuddin] worked together on a very fast LED matrix display for their final project in ECE 5760 at Cornell University.
They started, as any good engineering students, by finding a way to make their lives easier. [Sam] had built a 32×32 LED matrix for another class. So, they made three more and ended up with a larger and more impressive 64×64 LED display.
They claim their motivation was the love of music, but we have a suspicion that the true reason was the love all EEs share for unnaturally bright LEDs; just look at any appliance at night and try not be blinded.
The brains of the display is an Altera DE2-115 FPGA board. The code is all pure Verilog. The FFT and LED control are implemented in hardware on the FPGA; none of that Altera core stuff. To generate images and patterns they wrote a series of python scripts. But for us it’s the particle test shown in the video below that really turns our head. This system is capable of tracking and reacting to a lot of different elements on the fly why scanning the display at about 310 FPS. They have tested display scanning at twice that speed but some screen-wrap artifacts need to be worked out before that’s ready for prime time.
The team has promised to upload all the code to GitHub, but it will likely be a while before the success hangover blows over and they can approach the project again. You can view a video interview and samples of the visualizations in the videos after the break.
Thanks to their Professor, [Bruce Land], for submitting the tip! His students are always doing cool things. You can even watch some of his excellent courses online if you like: Here’s one on the AVR micro-controller.
Continue reading “FPGA Powers Blazingly Fast LED Matrix Audio Visualizer”
We’re not sure we condone this at all. CRT monitors are virtually extinct, and here we have some folks just smashing them up for no good reason. That said, it’s kinda cool to see large industrial robots in motion, so we can’t really blame them. (Video embedded below.)
We’ve covered the [Geek Group] crushing TVs with their robot arm before although that first try was more like a fail, in the sense that the TV was only partly smashed. At the time, we joked that it was because they had a Jolly Wrencher holding the CRT together. But it could have been that the robot arm simply lacked the requisite grunt.
This time they came to it with a stronger robot arm, and removed the Jolly Wrencher from the screens. These folks aren’t scientists — changing two variables at once leaves the experiment inconclusive. But they do smash things. So that’s a success, right?
