Interfacing your own hardware with a Java app couldn’t be easier than this example. [Pn] created this proof-of-concept using an Arduino, an analog joystick from a gaming controller, and a few lines of Java code. The Arduino reads an ADC value from the joystick’s x-axis and transmits it over the serial connection ten times a second. The Java program triggers on every serial event, parsing the data based on the @ symbol that the Arduino sends as a start and end condition.

We like this kind of example because there’s nothing extra involved. It lets you take the concept and run with it in any project imaginable. Be it a more complicated Joystick, or simple sensors that you’d like to interface with.

[Sebastian] is trying to improve the responsiveness of an electric keyboard. He was unsatisfied with the lack of adequate sensitivity to keystroke. The first step in his process was to measure how fast the quickest keystroke actually is. By setting up an LED and phototransistor and taking some measurements he found that sampling at 1 kHz would be more than adequate.

With initial testing complete he ordered some CNY70 transmissive/reflective light sensors that can be place below the keys. He measures the sensor with the ADC on an ATmega16 microcontroller. Running at 16 MHz he can sample each of the eight analog-to-digital converter channels at 1202 Hz. After doing a bunch of math he put together some lookup tables that are used to translate the ADC data into midi signals. We’ve embedded a video of one sensor controlling the midi program PianoTeq. [Sebastian] also sent us a schematic of one node in the sensor network (see it after the break).

When everything is said and done he plans to use eleven ATmega16 microcontrollers to address the 88 keys, with an additional microcontroller to act as the master using a two-wire interface for communications.

Update: [Sebastian] put up a webpage with a fairly verbose description. Reading it straight from the source really clears up a lot of questions.

Read the rest of this entry »

[Mike] built a sensor rig to measure projectile speed. The setup uses a tunnel with two sensors in it. Each consists of a laser diode on one side focused on a photodiode in the other. The two are monitored by an op amp and measured by an ATmega128 microcontroller. When the beams are broken the elapsed time between the two events is measured in order to calculate speed. There is a setting to adjust the calibration for a range of speeds, which came in quite handy as [Mike] initially tested the device with rubber bands before moving on to a pellet gun and then a rifle.

It seems like he’s tempting fate by shooting a target just a few inches below his exposed circuitry but his marksmanship prevailed. We’ve seen bullet speed detectors in the past, used just for the delight of seeing how fast the projectile is moving, and also to capture an impact at just the right instant.

This alarm system senses motion and then alerts you by phone. [Oscar] had an old external modem sitting around and, with some wise hardware choices, he came up with a simple circuit to use it. First up is the PIC 16F628A chosen because it doesn’t require an external crystal. This connects with the modem via a DS275 RS232 transceiver because it requires no external parts for connection. The final portion of the puzzle is a PIR sensor that triggers a pin interrupt in the sleeping PIC, which then dials your number to alert you. It doesn’t look like anything happens other than your phone ringing, but that’s enough for a simple system. We’re just happy to see how easy it was to use that modem… time to go hunting for one in dreaded junk trunk. Don’t miss the clip after the break.

Read the rest of this entry »

[Stewart Allen] acquired a Mindstorm kit about a month ago and he’s already building his own sensors for it. He wanted a more accurate range finder with a narrower measurement field than the stock sensor. Mindstorm has the option to communicate with sensors via an I2C bus. [Stewart] set up an ATtiny45 to act as a the slave on the bus, facilitating the analog measurement of the distance voltage by using and lookup table, and handling the data transfer with the NXT brick. His testing setup is pictured above, with an AVR Dragon for programming the tiny45 and a Bus Pirate for sniffing the I2C data during the development process. The sensor, looking great on a professionally made PCB he ordered, requires a simple driver that [Stewart] hammered out for use with leJOS, the alternative Mindstorm firmware we’ve seen before.

As part of his Master’s dissertation [Salvador Faria] built a sensor suite for wine monitoring. He needed to develop a method of tracking data inside the wine cask during the vinification process. What he came up with eclipses the wine cellar temperature monitors we’ve seen before.

He picked up pH, temperature, carbon dioxide, alcohol, and relative humidity sensors from familiar vendors like Seeed, Parallax, and SparkFun. His original idea was to develop a floating probe that housed the entire package but he had quite a bit of trouble getting everything inside and maintaining buoyancy. The solution was a two-part probe; the stationary portion seen mounted on top of the cask houses the microcontroller, RF 433 MHz transmitter, and the gas sensors. Tethered to that is a floating probe that measures pH and temperature. Data is sent over radio frequency to an HTTP POST server every minute.

[Steve] let us know about his MultiDisplay car monitoring system. Unlike traditional systems that rely on interfacing with the OBD-II protocol and existing car computer, the MultiDisplay uses an Arduino and custom shield with a combination of sensors; including temperatures, pressures, throttle, Boost, and etc. The data collected can then be displayed on a 20×4 LCD or streamed to a PC with visualization and event recording.

It’s nice to see half a years worth of work finally be complete and presented in such a clean and professional manner, keep up the good work [Steve]