Random number generation is a frequent topic of discussion in projects that involve encryption and security. Intel has just announced a new feature coming to many of their processors that affect random number generation.

The random number generator, which they call Bull Mountain, marks a departure from Intel’s traditional method of generating random number seeds from analog hardware. Bull Mountain relies on all-digital hardware, pitting two inverters against each other and letting thermal noise tip the hand in one direction or the other. The system is monitored at several steps along the way, tuning the hardware to ensure that the random digits are not falling more frequently in one direction or the other. Pairs of 256-bit sequences are then run through a mathematical process to further offset the chance of predictability, before they are then used as a pseudorandom number seed. Why go though all of this? Transitioning to an all-digital process makes it easier and cheaper to reduce the size of microchips.

A new instruction has been added to access this hardware module: RdRand. If it works as promised, this should remove the need for elaborate external hardware as a random number source.

[via Reddit]

In our hands-on review of the Digilent chipKIT Uno32, we posed the question of what the lasting appeal might be for a 32-bit Arduino work-alike. We felt it needed some novel applications exploiting its special features…not just the same old Arduino sketches with MOAR BITS. After the fractal demo, we’ve hit upon something unique and fun…

So just what are the chipKIT’s unique features over a stock Arduino? Until the expected Ethernet shield ships this summer, a few ideas are on hold. Let’s see then…there’s no shortage of MIPS, of course…but there’s also heaps of RAM and flash storage. And with the latter, sampled audio came to mind. There are Arduino shields for just this sort of thing — the Adafruit Wave Shield turns up in many projects, using an SD card for sound storage — but if one’s needs are modest, the chipKIT’s PIC32 is perfectly capable of storing brief audio samples in its own flash program space, no cards, adapters or added expense required. We estimate the Max32 can hold nearly a full minute of voice-quality audio.

Playing with the idea, we found we could do one better. Actually, several better. A limitation of SD card-based players like the Wave Shield is that they can only play one sound at a time. Dealing with the FAT filesystem and buffering audio data off the card takes nearly everything the Arduino’s little ATmega chip can muster…polyphonic sound requires kludges. But our flash-resident audio samples on the chipKIT are trivial to access. With the fast 32-bit CPU, many samples can be processed simultaneously…and then, with gobs of RAM, time-based effects such as reverb can be added. And before we knew it, there was a toy synthesizer sitting on the table:

Having previously dabbled with the PIC32 using Microchip’s tools, we were surprised by the simplicity with which this went together. A few early rough spots aside, the chipKIT and MPIDE environment show major promise for being every bit as simple as Arduino. In fact, the whole build was completed faster than the documentation phase. And then a second surprise, even to us: everything in the parts list, aside from the chipKIT board itself, is common stuff that could be found at RadioShack. No funky special ICs, components or mail-order shields. Most of the “magic” is in software, thanks to this fast microcontroller.

Here’s a demonstration of the finished mini-synth in action:

Please excuse the demonstrator’s tragic lack of rhythm and coordination. This is why professional musicians get paid millions while amateurs lead sad lives as technology bloggers. Be thankful that we spared you the blooper reel.

Input is via five piezoelectric transducers (RadioShack #273-0073, $2.19 each) attached to analog inputs A0 through A4. We could have just used pushbuttons, sure, but we wanted something that could sense the pressure of each hit, and these were cheaper than force-sensitive resistors. Piezo sensors have a specific polarity, and the positive side (red wires) should connect to the analog inputs, and black to ground. There’s also a 2000 Ohm resistor added across each element:

Input for the reverb effect is straightforward. Two 10K potentiometers on analog inputs A6 and A7 (these are on the second row of analog inputs on the chipKIT Uno32, not present on Arduino). One controls the amplitude, the other controls the delay:

Finally, sound output uses high-speed PWM output on digital pin 3, passed through a simple low-pass filter to a headphone jack:

On our breadboard we’re using a handy little headphone breakout board from SparkFun, but one could just solder the appropriate wire leads onto a bare jack from “The Shack” (ugh). You may want to optionally add a 1 Meg pot just before the headphone jack. The circuit worked fine as-is with headphones or an amplified iPod speaker, but totally saturated our camera’s microphone input when fed directly.

This demo uses 16 KHz sound samples. As per Nyquist theory, the low-pass filter is then designed for an 8 KHz (-ish) cutoff frequency. For purely voice applications, half those rates should be sufficient (saving flash space and allowing longer samples), and the two resistor values should then be doubled.

And that’s it for parts. Can you believe it? On to the code…

To begin, we need something that can convert sound files into a format the C compiler can use. An ugly little UNIX command-line utility converts WAV files from a very specific format (8-bit mono, uncompressed) into C header files that can be #included by the MPIDE project. Arduino normally would use the PROGMEM directive to put these tables into the code flash space, but that’s not required here. Surprisingly, the much-loved Audacity program wouldn’t export 8-bit WAVs, but we found it possible to batch convert sounds using iTunes.

const signed char sample_drum[] = {
        0x02,0x03,0x01,0x00,0x00,0x00,0x00,0x01,
        0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x00,
        ...HUNDREDS OF LINES OF STUFF...
        0xff,0xff,0xff,0xfd,0xfd,0xff,0x00,0x00,
        0x00,0x00,0x00,0x00,0x02,0x00 };

We’ll spare you the horror of looking at that code or doing the conversion. You can download the complete set of project files here, and then adapt it to your own needs. The remainder of this article deals only with the MPIDE code.

But first, one fix is required: in our prior article, we encountered an issue with the chipKIT’s analog read speed, and a fix was discussed in the comments. This involves scrounging among the MPIDE source files for “wiring_analog.c” and changing a few lines. The old code resembles:

delayMicroseconds(99);
while ( ! mAD1GetIntFlag() ) { }
analogValue = ReadADC10(0);
mAD1ClearIntFlag();

This should be changed to:

delayMicroseconds(2);
mAD1ClearIntFlag();
while ( ! mAD1GetIntFlag() ) { }
analogValue = ReadADC10(0);

We’re told this change will be incorporated into later releases of the toolkit and this won’t be necessary for much longer. If you’re just ripping out the digital audio code from this project and ignoring this drum pad stuff, you can skip the change altogether.

And then there’s our sketch code:

// Mini sampling synthesizer for chipKIT Uno32.

#include "sounds.h"       // N_SAMPLES and data are here
#define PWM_PIN         3 // OC1 PWM output - don't change
#define SAMPLE_RATE 16000 // All samples fixed at 16 KHz
#define MAX_SOUNDS     10 // Polyphonic limit
#define MAX_ECHO     4000 // 1/4 sec fits in Uno32 RAM

short
  echo_data[MAX_ECHO]; // Circular buffer for echo

int
  echo_delay = 0, // Duration of echo effect
  echo_vol   = 0, // Echo effect volume (0-1023)
  echo_pos   = 0; // Current position in echo buffer
volatile int      // May change during interrupt:
  n_sounds   = 0; // Number of sounds currently playing

struct soundStruct {
  int sample; // Index of corresponding audio sample
  int pos;    // Current position within sample
  int vol;    // Playback volume, 0-1023
} sound[MAX_SOUNDS];

#define N_PADS N_SAMPLES // One pad for each sample

struct padStruct {
  short max;       // Max pressure during press (0-1023)
  short count;     // Timer for filtering out noise
  byte  triggered; // If set, currently reading a press
  short add;       // If >0, begin sound at next interrupt
} pad[N_PADS];

void setup()
{
  memset(pad, 0, sizeof(pad));    // Clear drum pad data
  memset(echo_data, 0, sizeof(echo_data)); // Clear echo
  pinMode(PWM_PIN, OUTPUT);     // Enable PWM output pin

  // Open Timer2, 1:1 w/256 tick interval (for 8-bit PWM)
  OpenTimer2(T2_ON | T2_PS_1_1,256);
  OpenOC1(OC_ON | OC_TIMER2_SRC | OC_PWM_FAULT_PIN_DISABLE,
    0,0);

  // Open Timer1 with interrupt for sample mixer (16 KHz)
  ConfigIntTimer1(T1_INT_ON | T1_INT_PRIOR_3);
  OpenTimer1(T1_ON | T1_PS_1_1, F_CPU / SAMPLE_RATE);

  delay(1);  // Slight delay avoids false trigger at start.
}

// Piezo transducers as input pads are fussy.
// To avoid false positives, a bit of hysteresis is used:
#define PRESS_MIN     20 // Must read at least this force
#define PRESS_COUNT    3 // for this many samples, then...
#define RELEASE_MAX    8 // Must read less than this force
#define RELEASE_COUNT 15 // for this many samples.
// Still imperfect; there are occasional double-triggerings
// and false triggers on adjacent pads.  Could be addressed
// with better mounting and isolation of pads and/or with
// improved input filtering in code or in hardware.

// The loop() function just reads pad and dial inputs; all
// audio work is done in the subsequent interrupt function.

void loop()
{
  int i, a;

  for(i = 0; i < N_PADS; i++) {  // Sample each pad...
    a = analogRead(i);

    if(pad[i].triggered) {    // Previously pressed?
      if(a <= RELEASE_MAX) {  // Yes, released now?
        if(++pad[i].count >= RELEASE_COUNT) {  // Really?
          // Sounds aren't added to play list here, just
          // flagged; they're added to the mix in the
          // interrupt.  This avoids a race condition
          // where this code may be trying to add a sound
          // while the interrupt is removing one.
          pad[i].add       = pad[i].max;
          pad[i].triggered = 0;
          pad[i].count     = 0;
        }
      } else {  // Still pressed...watch for new max
        if(a > pad[i].max) pad[i].max = a;
        pad[i].count = 0;  // Reset release counter
      }
    } else if(a >= PRESS_MIN) {  // Untriggered; new press?
      if(++pad[i].count >= PRESS_COUNT) {  // Really?
        pad[i].triggered = 1; // Flag to watch for release
        pad[i].count     = 0;
        pad[i].max       = a;
      }
    } else {  // Untriggered and below press threshold
      pad[i].count = 0;  // Clear press counter
    }
  }

  // Echo parameters come from potentiometers on A6 and A7
  echo_vol   = analogRead(6);
  echo_delay = map(analogRead(7), 0, 1023, 0, MAX_ECHO);
}

// This is the mixing/sample-playing interrupt,
// invoked at 16 KHz to match the audio sample rate.
// With guidance from Mark Sproul's PIC32 port of
// Brett Hagman's Tone library for Arduino.
extern "C"
{

void __ISR(_TIMER_1_VECTOR,ipl3) playSample(void)
{
  int i = 0, sum = 0;

  mT1ClearIntFlag();  // Clear interrupt flag

  while(i < n_sounds) {  // For each sound playing...
    // Waveform is cumulative, NOT averaged
    sum += (int)sample[sound[i].sample].data[sound[i].pos] *
      sound[i].vol;
    sound[i].pos++;  // Advance counter.  If end hit...
    if(sound[i].pos >= sample[sound[i].sample].size) {
      n_sounds--;  // Decrement number of sounds playing:
      // Move sound at end of list to the slot currently
      // occupied by the vacating sound (unless the same)
      if(i < n_sounds) {
        memcpy(&sound[i], &sound[n_sounds],
          sizeof(soundStruct));
        continue;  // Sound moved; dont advance index
      }
    }
    i++;
  }
  sum /= 1024;

  // Add in echo effect (if enabled) from circular buffer.
  // This takes place before audio level clipping so that
  // any clipping distortion won't be repeated in echo.
  if((echo_delay > 0) && (echo_vol > 0)) {
    sum += echo_data[echo_pos] * (echo_vol + 1) / 1024;
    echo_data[echo_pos] = sum;
    if(++echo_pos >= echo_delay) echo_pos = 0;
  }

  // Clip audio to 8-bit range.  This may cause distortion
  // when multiple sounds or echo exceed the 8-bit range.
  // Invoking the "quick & dirty" alibi again.
  if(sum < -128)     sum = -128;
  else if(sum > 127) sum =  127;

  SetDCOC1PWM(sum + 128);  // Set PWM output value 0-255

  // Check for any new sounds flagged by loop().
  // Done last because sounds finished above will
  // free up polyphonic slots.
  for(i = 0; i < N_PADS; i++) {
    if(pad[i].add) {
      if(n_sounds < MAX_SOUNDS) {
        sound[n_sounds].sample = i;
        sound[n_sounds].pos    = 0;
        sound[n_sounds].vol    = pad[i].add + 1;
        n_sounds++;
      }
      pad[i].add = 0;  // Clear flag even if not added
    }
  }
}

} // end extern "C"

Explanation:

The setup() function initializes two timers:

• Timer 2 and Output Compare 1 (hardware features of the PIC32 chip) are used for pulse width modulation (PWM). In conjunction with the filter previously described, this positions the speaker for each audio sample (Google for “PWM DAC” for explanations and examples). The PWM input clock is set to the chip’s full speed of 80 MHz, with an interval of 256 “ticks” (for 8-bit resolution), yielding a PWM waveform at 312,500 Hz. For this sort of DAC filtering it’s recommended that the PWM frequency be at least ten times the sample rate, so this is more than adequate for our needs. This is also why the code bypasses the native Arduino analogWrite() function for PWM, which operates on a much slower clock. Lastly, using Output Compare 1 dictates that we must use digital pin 3 for the audio output; this is one of the five native hardware PWM lines on this chip.
• Timer 1 operates at our audio sample frequency (16 KHz) and has an interrupt function attached. This function mixes audio samples and changes the PWM duty cycle of Timer2/OC1. The rates on both of these timers are set up once and never need to change, just the one duty cycle is varied.

This section of the code (and one line in the interrupt function) is admittedly not very Arduino-like, directly accessing hardware features in a non-portable manner. A more formal implementation would abstract these details into a library to which the novice programmer could just pass data. But for the sake of a simple, single-file demo, there it is, warts and all. In many ways, this is just a starting point to work from.

The loop() function reads the state of the piezo sensors and marks sounds to be played (received by the interrupt, later). There’s some crude debouncing of the piezo inputs…this really could use some more sophisticated filtering (which the PIC32 could easily handle), but it was skipped for brevity. The code generally detects varying pressure, but there’s still a fair bit of false triggering going on. In this function the reverb controls are also read: just two analogRead() calls, with the second one then mapped to the full length of the reverb buffer.

The interrupt handler is where all the fun stuff happens, and it’s surprisingly simple.

The extern “C” declaration makes the C++ compiler happy with the interrupt function declaration.

The program is designed for up to ten concurrent sounds, the details of which are held in the “sound” structure array (there’s more than enough CPU performance for greater polyphony, but it’s mostly just a matter that the input pads aren’t terribly practical for this). When a pad hit is sensed, a new item is added to this array (up to the maximum). Structure elements indicate which audio sample is used for this sound, the current playback position within the sample, and the volume level.

Audio samples are stored as signed values (rather than unsigned) because this makes them easier to mix (just add together) and easier to adjust gains (just multiply). Every opportunity is taken to use fixed-point math. From the prior fractal demo, we saw what a massive performance difference this can make — sometimes orders of magnitude. Most of our analog readings (returned as 10 bit integers from 0 to 1023) correspond to a gain (relative volume) value of 0.0 to 1.0 (or 0% to 100%). To perform this scaling in fixed-point units, add 1 to the reading, perform the multiplication (one instruction on the PIC32), then divide by 1024 (a simple shift operation, also one instruction). There’s no loss in accuracy vs. converting to floating-point; the source and destination values are going to be quantized anyway.

// Floating-point, slow:
// scale = float 0.0 to 1.0
out = (int)((float)in * scale);

// Fixed-point, crazy fast:
// scale = integer 0 to 1023
out = in * (scale + 1) / 1024;

Along these lines, note that where the audio samples are summed, this division is skipped until the end. This saves some cycles and the result works out the same. Algebraically speaking, (A/X)+(B/X)=(A+B)/X, and so forth. The interim 32-bit sum isn’t likely to overflow.

Fixed-point math happens again when applying reverb. The echo volume, in the integer variable echo_vol (10 bit again, from one of the analog knobs) is in the range 0 to 1023, corresponding to 0% (no reverb) to 100% (echo is as loud as the original sound). Reverb (in echo_data[] array) is a circular buffer — as sounds are played, the contents here (scaled by echo_vol) are first added to the output, then the result is placed back in the same position in the array and the position counter is incremented by one. When the end of the array is reached (or a shorter limit indicated by echo_delay) we “wrap around” back to the beginning.

The final resulting audio value is clipped to an 8-bit range. This may introduce clipping distortion when many loud sounds are used simultaneously. For brevity again, bells and whistles have been omitted, but courageous programmers could opt to add “soft clipping” here to limit such distortion. There’s ample CPU muscle.

The final 8-bit signed value is then transposed into the unsigned range and fed into the OC1 duty cycle for PWM output.

Lastly, the interrupt checks for any sounds that the loop() function flagged as being “hit,” and adds these to the concurrent play list. This flag-and-add behavior, rather than adding items directly in loop(), avoids a potentially nasty race condition whereby loop() could be in the midst of adding a sound just as the interrupt is removing others, throwing off the counter.

And that’s all there is to it. This demo only uses about one fourth of the storage on the Uno32, which itself has one fourth the capacity of the Max32…and we’ve yet to exploit any sort of compression. There could be some fun applications here, maybe adding better Super Mario sounds to toilets or voice prompts to other chipKIT projects (“Your door is ajar”). What other ideas could you see happening here?

If it sometimes seems that there is only a finite amount of things you can do with your kids, have you ever considered making movies? We don’t mean taking home videos – we’re talking about making actual movies where your kids can orchestrate the action and be the indirect stars of the show.

Maker [Friedrich Kirchner] has been working on an application called MovieSandbox, which is an open-source realtime animation tool. A couple of years in the making, the project is cross-platform compatible on both Windows and Apple computers (with Linux in the works), making it accessible to just about everyone.

His most recent example of the software’s power is a simple digital puppet show, which is sure to please young and old alike. Using sock puppets fitted with special flex sensors, he is able to control his on-screen cartoon characters by simply moving his puppets’ “mouths”. An Arduino is used to pass the sensor data to his software, while also allowing him to dynamically switch camera angles with a series of buttons.

Obviously something like this requires a bit of configuration in advance, but given a bit of time we imagine it would be pretty easy to set up a digital puppet stage that will keep your kids happily occupied for hours on end.

Continue reading to see a quick video of his sock puppet theater in action.

[via Make]

[Joren] likes his digital piano, but it was missing one key component that he wanted to use: the ability to produce vibrato while playing. Vibrato can be done in several different ways on regular pianos, but it seemed as if there was not a lot of consideration given to the effect when designing digital pianos.

He enjoys playing all sorts of music, including solos from Franz Liszt which suggest using vibrato at times, so he decided to build himself a vibrato box. Constructed with a bit of assistance from the friendly folks at Hackerspace Ghent, his “Pidato” incorporates an Arduino and three-axis accelerometer to get the job done.

The Arduino is connected to both the MIDI output of the piano as well as to the accelerometer, which he has mounted on his wrist. While playing, all he needs to do is simply move his hand rapidly to produce the vibrato sound as you can see in the video below. The Arduino code filters out any other sorts of movements to ensure that he does not accidentally trigger the effect when it is not desired.

Check out the video below for a quick demonstration of the Pidato box.

This is a hack in the finest sense of the term. It not only allows you to capture data from an analog oscilloscope for later analysis, but provides you with a great tool if you’re posting on the Internet about your projects. [J8g8j] used an empty cashew container to add a camera mount to the front of his scope. This is possible because the bezel around the display has a groove in it. A bit of careful measuring helped him make an opening that was just right.

You can see that the red cap for the jar holds the camera and gave him a bit of trouble in the original prototype. This version has a tray where camera sits, which replaces the Velcro with didn’t hold the camera level the first time around. He’s also painted the inside of the clear plastic to reduce glare on the oscilloscope readout. Black and white images seem to come out the clearest, but it can be difficult to make out the grid lines. The addition of LEDs to help them stand out is one of the improvements we might see in the future.

[Jonas Kroyer] is a digital  photographer, with a fascination with old cameras and pairing the two together sounded like a fun idea. Searching around on the net he fell in love with the design of the Zeiss Ikon Ikonette (1929-31), and found one with a chipped lens.

After dismantling the camera completely, it was found out that he needed the lens/shutter mechanism, the bellows, and the rails that allow the lens to slide back and forth. The bellows were glued to the body of the camera, but some careful prying and they were quickly removed unharmed. Next was to make an adapter so he could attach the lens to a digital DSLR camera, a steel plate and a Nikon Bayonet swiped off of a no name lens holds everything together. Rails were reattached using rivets, and the bellows were glued onto the plate. Other mods include adding small brass knobs to aid in adjustments, and a spring from a ballpoint pen to hold the original shutter open.

The new old lens is said to be easy to operate, and produces some beautiful images. Though since the lens does not have any modern day coatings it does have its drawbacks, like a diamond shaped flare in the middle of the image, which can be good when you want it, or partially removed in photoshop if you don’t.

Shots of this Canon AE-1 camera-gone-digital have a lot of people scratching their heads. Originally there were a lot of “that’s been photoshopped” cries but the video after the break shows that it physically exists. This particular model of camera hasn’t been manufactured since 1984 so there’s little chance that the company’s bringing it back in a digital format. What we have here is a classic camera body with a modern point-and-shoot fit inside. This seems to be a PowerShot SD 870 IS and we’d guess the original lens has been replaced with a plate of glass so as not to affect the PowerShot’s focus, and the “AE-1 Program Digital” screen is probably just an image on the memory card.

We admire the clean mod work necessary to produce this hack.

[Thanks Juan]

[Mike Bradley] wanted to use his oscilloscope to display 8 channels of digital signals. Alas, the analog unit didn’t have this capability. Not to worry, he threw together an adapter module that does the trick. Using a PIC 18F26K20 microcontroller he inputs four or eight channel digital logic (at 5V) and filters the output to an analog signal that the oscilloscope can interpret. What you see in the photo above is the result.

[Kieran] let us know about his hybrid analog/binary clock. The circuitry behind the clock is nothing too new. An Arduino combined with a Chronodot to produce an accurate clock. What we really enjoyed however was the creative implementation of an old British Telecom Linesman’s Multimeter as the case. The analog meter acts as the seconds hand, while a another display made of LEDs diffused with stripboard is the binary clock. The end product is nothing short of ingenuitive.

Kodak managed to release a product with a big fat security vulnerability. [Casey] figured out that the Kodak W820 WiFi capable digital frame can be hijacked for dubious purposes. The frame can add Internet content as widgets; things like Facebook status, tweets, and pictures. The problem is that the widgets are based on a feed from a website that was publicly accessible. The only difference in the different feed addresses is the last two characters of the frame’s MAC address. Feeds that are already setup can be viewed, but by brute-forcing the RSS link an attacker can take control of the feeds that haven’t been set up yet and preload them with photos you might not want to see when you boot up your factory-fresh frame.

It seems the hole has been closed now, but that doesn’t diminish the delight we get from reading about this foible. There’s a pretty interesting discussion going on in the thread running at Slashdot.

[Photo credit]

Analog clocks now a days get no respect. Everyone is digital this, or binary that, and we admit it is nice to look over and see the time promptly displayed. But there’s something about the quiet ticking and ominous feeling you get when around a large intricate clock that you know some serious time has been invested.

Nostalgia feelings aside, [Alan] from Hacked Gadgets introduced us to his Gear Clock. While it’s not a new idea, and in fact we have a few around the office, his concept really inspired us. His clock is driven via stepper motor and a PIC, allowing for the time to be fairly accurate. The only small problem he mentions is the poor paint job, but we think it looks amazing regardless.

A while back we looked at [Matthias'] one-pin dot matrix printer. Now we’re jumping over to his woodworking website to feast on his wooden binary adding machine. His creation uses glass marbles as the data for this device. A resolution of up to six bits can be set on the top of the adder, then dropped into the machine as one number. With each new drop, the number is added to the total stored in the machine. The device is limited to totals less than 64. If a larger number is enter, the device wraps around back to zero by dumping the 7th bit off the end. He’s even got a master clear that allows you to easily read the stored total and evacuate the “data” from the machine.

This has quite a few less wires than the last binary adder we looked at… wait, it has no wires! But we still love it. A physical representation of what is going on with binary math really helps grasp what the magic blue smoke inside those silicon chips is all about. Don’t miss his video walk through of the adding machine embedded after the break. Can’t get enough of marbles interacting with wood? He’s got a few more projects you might enjoy.

Network engineer [Mario Giambanco] recently purchased a cable to move his flash off camera. Unfortunately, it ended up way too short for his purposes. Instead of purchasing a slightly longer proprietary cable, he decided to employ what he had around him: a lot of cat5e cable and ethernet jacks. He cut the cable close to the center in case things didn’t work out and he’d need to repair it. His post on building the custom ethernet flash extension cable goes into heavy detail to make sure you get it right the first time. He’s tested it using both five and 50 foot pieces of cable with no apparent lag.

This isn’t the first time we’ve seen cat5 repurposed: composite video through cat5, vga cat5 extension, and cat5 speaker cables.

[via Lifehacker]