You know the saying: “Dogs have people, cats have servants.” This is especially true when your feline overlord loses track of time and insists on being fed at oh-dark-thirty. You’re tempted to stay in bed feigning death, but that’s a tall order with the cat sitting on your chest and staring into your soul.
An automatic cat feeder would be nice at moments like these, but off-the-shelf units are pricey. [Mom Will Be Proud] decided to roll his own cat feeder, and the results are pretty impressive for what amounts to a trash can build. Two old food cans form the body — a Pringles can on top to hold the food and a nut can below for the servo. The metal ends of the cans nest together nicely, and with a large section removed from each, an aperture opens every time the hopper rotates, dropping food down a chute. A BeagleBone Black controls the servo, but anything with PWM outputs should do the trick. We’d lean toward the ESP8266 ecosystem for WiFi support for remotely controlling feedings, and we’d probably beef up the structure with PVC tube to prevent unauthorized access. But it’s a simple concept, and simple is a good place to start.
You shall not want for pet feeder builds around these parts. Take your pick — snazzy Steampunk, super cheap, or with an Archimedean twist.
Continue reading “Eat Some Pringles, Feed The Cat” →
The CAN bus has become a defacto standard in modern cars. Just about everything electronic in a car these days talks over this bus, which makes it fertile ground for aspiring hackers. [Daniel Velazquez] is striking out in this area, attempting to decode the messages on the CAN bus of his Smart ForTwo.
[Daniel] has had some pitfalls – first attempts with a Beaglebone Black were somewhat successful in reading messages, but led to strange activity of the car and indicators. This is par for the course in any hack that wires into an existing system – there’s a high chance of disrupting what’s going on leading to unintended consequences.
Further work using an Arduino with the MCP_CAN library netted [Daniel] better results, but it would be great to understand precisely why the BeagleBone was causing a disturbance to the bus. Safety is highly important when you’re hacking on a speeding one-ton metal death cart, so it pays to double and triple check everything you’re doing.
Thus far, [Daniel] is part way through documenting the messages on the bus, finding registers that cover the ignition and turn signals, among others. Share your CAN hacking tips in the comments. For those interested in more on the CAN bus, check out [Eric]’s great primer on CAN hacking – and keep those car hacking projects flowing to the tip line!
The BeagleBone is a very popular single board computer, best applied to real-time applications where you need to blink LEDs really, really fast. Over the years, the BeagleBone has been used for stand-alone CNC controllers, the brains behind very large LED installations, and on rare occasions has been used to drive CRTs. If you just want a small Linux board, get a Pi. If you want to do something interesting with hardware, get a BeagleBone.
The BeagleBone ecosystem has grown a lot in the last year, from the wireless and Grove connector equipped BeagleBone Green, the robotics-focused BeagleBone Blue, the Zoolander-inspired Blue Steel. Now there’s a new BeagleBone, built around a very interesting System on Module introduced earlier this year.
The new board is called the BeagleBone Black Wireless, and it brings to the table all you know and love about the BeagleBone. There’s a 1GHz ARM355x with two 32-bit 200MHz PRUs for the real-time pin toggling. RAM is set at 512MB, with 4GB of eMMC Flash and Debian pre-installed, and a microSD card for larger storage options. The new feature is wireless connectivity: a TI WiFi and Bluetooth module with provisions for 802.11s replaces the old Ethernet connector.
Taken at face value, the new BeagleBone Black Wireless deserves a mention — it’s a BeagleBone with wireless — but isn’t particularly noteworthy. But when you get to the gigantic brick of resin dropped squarely in the middle of the board does the latest device in the BeagleBone family become very, very interesting. The System on Module for this version of the BeagleBone is the BeagleBone On A Chip released a few months ago. The Octavo Systems OSD335x is, quite literally, a BeagleBone on a chip. It’s a BGA with big balls, making it solderable with hand-applied solder paste and a toaster oven reflow conversion. In fact, the BeagleBone Wireless was designed by [Jason Kridner] in Eagle as a 6-layer board. It’s still a bit beyond the standard capabilities of OSHPark, but the design can still be cut down, and shows how this BeagleBone on a Chip can be applied to other Open Hardware projects.
If you have ever spent a while delving into the bare metal of talking to the I/O pins on a contemporary microprocessor or microcontroller you will know that it is not always an exercise for the faint-hearted. A host of different functions can be multiplexed behind a physical pin, and once you are looking at the hardware through the cloak of an operating system your careful timing can be derailed in an instant. For these reasons most of us will take advantage of other people’s work and use the abstraction provided by a library or a virtual filesystem path.
If you have ever been curious enough to peer under the hood of your board’s I/O then you may find [Ken Shirriff]’s latest blog post in which he explores the software stack behind the pins on a BeagleBone Black to be of interest. Though its specifics are those of one device, the points it makes have relevance to many other similar boards.
He first takes a look at the simplest way to access a Beagle Bone’s I/O lines, through virtual filesystem paths. He then explains why relying so heavily on the operating system in this way causes significant timing issues, and goes on to explore the physical registers that lie behind the pins. He then discusses the multiplexing of different pin functions before explaining the role of the Linux device tree in keeping operating system in touch with hardware.
For some Hackaday readers this will all be old news, but it’s safe to say that many users of boards like the BeagleBone Black will never have taken a look beyond the safely abstracted ways to use the I/O pins. This piece should therefore provide an interesting education to the chip-hardware novice, and should probably still contain a few nuggets for more advanced users.
We’ve seen a lot of [Ken]’s work here at Hackaday over the years, mostly in the field of reverse engineering. A few picks are his explanation of the TL431 voltage reference, a complete examination of the 741 op-amp, and his reverse engineering of the 1970s Sinclair Scientific calculator.
We appreciate [Fustini]’s tip on this story.
BeagleBone Black image: BeagleBoard.org Foundation [CC BY-SA 3.0], via Wikimedia Commons.
The Peanuts cartoon character Schroeder liked to bang out Beethoven a toy piano. Now, thanks to this hack from [Liam Lacey], Schroeder can switch to Skrillex. That’s because [Liam] built a polyphonic synth into a toy piano. It’s an impressive build that retains the look and feel of the piano, right down to a laser-etched top panel with knobs that match the glossy black styling.
The brains of the synthesizer is a Beaglebone Black using the Maximillian synthesis library. To capture the key presses, he used Velostat, a pressure-sensitive material that changes resistance under pressure. This is probably the only toy piano in the world with fully polyphonic velocity and aftertouch. The build also includes MIDI support, with two ports on the back. [Liam]’s build log is full of more details than we can even summarize here.
This beautiful build won [Liam] first place in the Element 14 Music Tech competition, and it is a well-deserved prize for a clean and elegant way to update a vintage piano.
Continue reading “Toy Piano Gets Synth Overhaul” →
York Hackspace needed a demonstration piece to grace their stand at Maker Faires and similar events. Their solution was Spacehack, a multi-player control console based starship emergency simulator game. Each Spacehack player has console with a selection of displays, switches, dials, and levers. Players must operate their controls in response to a series of sometimes confusing commands the game supplies them from their fellow crew members. Each wrong move brings the disaster-prone ship closer to destruction, and the aim is to keep it spaceworthy for as long as possible. The result is an engaging and addictive draw for the hackspace.
Behind the brilliantly designed consoles, silver ducting and pyramidal hub box the game relies on a Raspberry Pi acting as a server and a Beaglebone Black for each player. All resources can be found on York Hackspace’s GitHub repository. The hackspace has a selection of videos on the Spacehack website, the one below the break shows the game as well as a montage of its construction. Continue reading “Save A Spaceship With Spacehack!” →
Bela is a cape for the BeagleBone Black that’s aimed at artists and musicians. Actually, the cape is much less than half of the story — the rest is in some clever software and a real-time Linux distribution. But we’re getting ahead of ourselves. Let’s talk hardware first.
First off, the cape has stereo input and output as well as two amplified speaker outs. It can do all of your audio stuff. It also has two banks of analogue inputs and outputs, each capable of handling eight signals. In our opinion, this is where the Bela is cool. In particular, the analog outputs are not Arduino-style “analog outputs” where it’s actually a digital output on which you can do PWM to fake an analog signal. These are eight 16-bit outputs from an AD5668 DAC which means that you can use the voltages directly, without filtering.
Then there’s the real trick. All of these input and output peripherals are hooked up to the BeagleBone’s Programmable Realtime Units (PRUs) — a hardware subsystem that’s independent of the CPU but can work along with it. The PRU is interfaced with the real-time Linux core to give you sub-microsecond response in your application. This is a big deal because a lot of other audio-processing systems have latencies that get into the tens of milliseconds or worse, where it starts to be perceptible as a slight lag by humans.
The downside of this custom analog and audio I/O is that it’s not yet supported by kernel drivers, and you’ll need to use their “Heavy Audio Tools” which compiles Pd programs into C code, which can then drive the PRUs. Of course, you can write directly for the PRUs yourself as well. If you just want to play MP3s, get something you have a bunch of simpler, better options. If you need to do responsive real-time audio installations, Bela is a way to go.
The project is open-source, but we had to do a bunch of digging to find what we were looking for. The hardware is in zip files here, and you’ll find the software here. The demo projects look/sound pretty cool and their Kickstarter is long over-funded, so we’re interested to see what folks make with these.