Devices that collect coins for payment typically use standardized coin acceptors like the one shown here. These devices use a protocol called ccTalk to let the system know what coins were inserted. [Balda] has built tools for implementing the ccTalk protocol to let you play around with the devices. He also gave a talk at DEF CON (PDF) about the protocol.
[Balda] got started with ccTalk because he wanted to add a coin acceptor to a MAME cabinet, and had a coin acceptor. His latest project converts ccTalk to standard keyboard keystrokes using a Teensy. The MAME cabinet can then interpret these and add to the player’s credits.
There’s two interesting sides to this project. By providing tools to work with ccTalk, it’s much easier to take a used coin acceptor off eBay and integrate it into your own projects. On the other hand, these acceptors are used everywhere, and the tools could allow you to spoof coins, or even change settings on the acceptor.
These slides may not be the style of character art you remember from the days of 2400 baud modems; they’re more advanced than what was out there in the beginning. It turns out there is still some life left in this art subculture. For this week’s installment of Retrotechtacular we look in on [Doug Moore’s] talk on the history and survival of ANSI and ASCII art given at this year’s BSides conference.
ASCII is still a common character encoding so chances are you’re already familiar with it. ANSI on the other hand is a rather confusing term as it’s been lost in obscurity when referring to character sets. In this case it refers to a set of extended characters which is better described as Windows Code Pages.
Most of what we know about the ANSI art scene is from watching BBS: The Documentary (which is on our ten best hacking videos list). We certainly remember seeing the vertically scrolling art after connecting to a dial-up BBS back in the day. But understanding the factions that formed around the creation, bundling, and distribution of this is art is fascinating. [Doug] does a great job of covering this history, sharing side-by-side examples of the shunned practice of “ripping” another artists work. This image is actually not a rip. Later in his talk he discusses the continued existence of the subculture, showing what a modern take on the same subject looks like.
If you’re merely into the technical the first half of the video below is worth watching. But we bet it’ll be hard not to continue to the end for a side-trip into art history.
Retrotechtacular is a weekly column featuring hacks, technology, and kitsch from ages of yore. Help keep it fresh by sending in your ideas for future installments.
Continue reading “Retrotechtacular: The history of ANSI and ASCII art”
Hackaday readers may remember a whistle detection device that I [limpkin] designed some time ago. As [Kevin] saw the new Staff roll call, he discovered this project and wanted to make his version of it.
In contrast with the original Whistled where all the signal processing is done in an ARM Cortex m4 microcontroler, [Kevin] uses discrete components, operational amplifiers and an Arduino Uno to detect someone’s whistle. In his video (embedded below), he goes into great lengths to explain how his circuit works along with the theory behind it. In his setup, his microphone’s signal is amplified, passed through a 1KHz-3KHz passive band-pass filter to a non-inverting amplifier with a 1000x gain (!) and finally to a voltage comparator. The Arduino measures the frequency of the signal coming out from the comparator and triggers a relay if the whistle is a ramp-up / ramp-down.
If you want to make the comparison between the two versions of the electronics, here is the link to the original whistled project.
Continue reading “Building an analog whistle detection device”
After working on the DARPA Virtual Robotics Challenge this summer, visions of a Heinlenesque robotic actuator filled [Hunter]’s head. His lab had access to something called a Cyberglove that used flexible pots in each of the fingers, but each of these gloves cost the lab $15,000 each.
With a little help from some joystick potentiometers, [Hunter] whipped up a decent approximation of a $15,000 device that measures how much a user’s fingers are bent. The pots are tied into an Arduino and read with analogRead(), while a small Python script interprets the data for whatever application [Hunter] can imagine.
There are a few drawbacks to [Hunter]’s design – it’s not wireless, unlike the $15,000 version, and they certainly don’t look as cool as the real thing. Then again, the DIY version only cost 0.2% as much as the real deal, so we’ll let any apparent problems slide for now.
When presented with a vintage Empisal Knitmaster knitting machine, members of the TOG Dublin Hackerspace worked together to not only bring it back from the dead but to also add some custom hardware that allows for computer generated patterns.
At first the Knitmaster was in fairly bad shape requiring a few custom machined parts just to function. It was originally designed to feed in special punch cards that mechanically directed the many moving parts of the machine (called “dibblers”) to knit patterns in yarn. Using an Arduino, a number of servos, and a microswitch to detect when the knitting carriage is pulled across, this card-read system was replaced with a computer controlled mechanism that can direct the machine to print out images one row at a time.
Of course, you don’t get too many opportunities to name your project something as cute as “The Twitter Knitter”, so once the system was working, it was only a matter of writing some code to snatch tweets from the web and generate images out of the text. Visitors of the Dublin Mini Maker Faire got to watch it in action as they posted tweets with a particular hashtag which the machine happily printed in yarn (as long as they weren’t too long).
Video demo after the jump.
Continue reading “Twitter Knitter combines 40 year old hardware with modern social media”
A while back we featured a magnetic rotary encoder that [LongHairedHacker] designed. The heart of the system is an AS5043 magnetic rotary sensor which runs from $6.5-$11 and has a 10 bits precision. As we wanted to check if his design was really efficient, he made a test bench for it.
For 360 degrees, a 10 bits precision means a ±0.175º accuracy, which is quite impossible to check with conventional measurement equipment. The first approach he thought of was to attach a mirror to the encoders axis and point a laser beam at it. The laser beam would be reflected across the room to a big scale, but the minimum required distance would have been 5 meters (16 feet). So he preferred attaching a motor to the sensor, rotating at a given speed and measuring the sensor output.
In the first part of his write-up, [LongHairedHacker] lays the math which explains the different kinds of errors that should be expected from his setup and sensor. He then proceeds with his test, where an ATMEGA8 based board is used to send the measured position to his computer. It should be noted that [LongHairedHacker] currently uses the time spent between two received measurements on his computer as a time base, but he is planning on time stamping the data on his board in the next future. Nevertheless, he managed to measure an average ±0.179º accuracy with his simple test bench, which is very close to the manufacturer specification.
Here is the link to our original post about his sensor.
If the media shortcut keys on your keyboard don’t function correctly due to outdated firmware, the manufacturer may recommend you ship it to them for an update. [Alvaro] didn’t care to wait that long, so he cracked it open and taught himself how to mod the EEPROM. The result is a well-documented breakdown of sorting out the keyboard’s guts. Inside he finds a USB hub, which he ignores, and the keyboard controller chip, which he attacks. Two data sheets and a schematic later, [Alvaro] breaks out the logic analyzer to compare physical key presses to the keypad codes they output.
He dumps the entire EEPROM and follows up with a quick flash via I2C to change the “next song” key to instead output the letter “a”. That seems to work, so [Alvaro] combs through an HID USB usage table for some codes and has to guess which ones will properly control Spotify. He converts the media keys from “scan next” and “scan previous” to “rewind” and “fast forward.” Problem solved.
[Alvaro] had zero knowledge of keyboards prior to opening this one up. If you aren’t already taking things apart to see how they function and how to fix them, hopefully his success will persuade you to explore and learn about those “black boxes” in your home. And, if you’ve never used I2C before—or think it might be the name of a boy band—head over to [Kevin’s] tutorial on bitbanging I2C by hand.