[Johan’s] been working on a chunk of code for about seven years and he thinks it’s ready to help you with your next project. He calls it D1 (The One) and it lets you receive asynchronous data without the need for a hardware USART. It’s capable of working with signals from an IR or RF remote, as well as tangentially related transmissions like RFID and magstripe readers.
It uses timer and port interrupts to sample the incoming data. Once it’s captured a transmission, the code sets a flag so that you can pull what it got into your own application. If you’re expecting to receive a protocol that sends packets several times in a row a verification module is also included which runs as a precondition of setting the received flag. The package is written in PIC assembly, but with all the information that [Johan] included in his post this shouldn’t be hard to port over to other chip architecture.
When [Bill Porter] works on a project, he says that he typically writes his own NMEA standard communications protocols to fit the job at hand. While it makes things easy to troubleshoot, he admits that his custom protocols are wasteful of both processor time and bandwidth. Binary communications on the other hand are more efficient, but a bit trickier to manage.
To make things easy for the common user, he wrote a library called EasyTransfer which abstracts packetized serial communications between two Arduino boards. The process is pretty simple – all one has to do is define a data structure on both Arduino boards so that they know what sort of data is coming over the wire, and EasyTransfer handles the rest. This allows users to worry less about communications protocols or transmission errors, and focus on their projects instead.
If you’re working on a project and searching for an easy way to get a pair of Arduinos talking, swing by his site and grab the library. It doesn’t get much easier.
[Greg] built himself a small indicator dial with his laser cutter, and wanted to use it for visualizing server performance and load information. Before he started using it for server monitoring however, he thought he should test out his data parsing skills on a simpler data set.
Pachube has a wealth of information that can be freely used for whatever project you might have in mind, so [Greg] started looking around for something interesting to track. Eventually he located the data feed for a tanker ship and wired his dial to display the ship’s speed. He uses a Python script to interface with the Pachube API, which is fed to his Netduino board. A servo motor then changes the position of the dial based on the feed’s data. Since large tankers don’t change speed often, the experiment was a bit of a letdown. He searched for a bit and tuned into another feed that tracked wind speed in New Zealand, getting much better results.
His future plans include hooking it directly to his network and eventually using it to monitor his servers…at least once the novelty of tracking random data feeds wears off.
All of his code is available on GitHub, and he is happy to make a gauge for anyone who is interested, though he doesn’t currently list a price.
This setup helps to represent data in a meaningful way to for visually impaired people. It uses a combination of physical objects to represent data clusters, and audio feedback when manipulating those objects. In the video after the break you’ll see that the cubes can orient themselves to represent data clusters. The table top acts as a graphing field, with a textured border as a reference for the user. A camera mounted below the clear surface allows image processing software to calculate the locations for the cubes. Each cube is motorized and contains an Arduino and ZigBee module, listening for positioning information from the computer that is doing the video processing. Once in position, the user can move the cubes, with modulated noise as a measure of how near they are to the heart of each data cluster.
The team plans to conduct further study on the usefulness of this interactive data object. We certainly see potential for hacking as this uses off-the-shelf components that are both inexpensive, and easy to find. It certainly reminds us of a multitouch display with added physical tokens.
Continue reading “Data plotting for the visually impaired”
Props go to [Michael Nash] for establishing an interface between National Instrument’s labVIEW and an Arduino (an example video using a potentiometer is above). Personally, from the one time we were forced to use labVIEW, we hated every second of it.
One reason it’s so terrible, is the Data Acquisition Modules cost well into the hundreds of dollars, yet the documentation and help resources are very scarce. By using an Arduino instead of the modules, the price and difficulty decrease a considerable amount. Which begs the question why has it taken so long to get a decent (and so simple) of a setup working?
Anyone who has tried their hand at RPG Maker 1 (or any text input with a controller) knows how difficult it can be typing long paragraphs into the console. [Thutmose] is here to save the day with Kupid 1.0 (2.0 in production). A PICAXE takes ps/2 keyboard input and converts it to a series of d-pad button presses for PS1 and PS2 controllers, providing quick data entry compared to the previously monotonous task.
We’re happy to learn that the source code and hardware is released, meaning it has the potential to be easily adapted to any controller/console.
[Viktor], one of our favorite avid hackers, has been playing around with 1-wire systems all this month. What started out as a MicroLAN Fonera has turned into an iButton interface, to a 1-wire powered hub, and finally a 1-wire character driven LCD. Anyone looking at 1-wire systems or OWFS could surely benefit from his testing.
However, if you still haven’t gotten your fill of 1-wire goodness, let us remind you of the 1-wire HVAC and IPv6 to 1-wire protocol translator.