Around this time last year, [KopfKopfKopfAffe] was enlisted as a set designer and was told to build some sort of light effects for electronic music parties. The budget for the project wasn’t much at 200 Euros, but he did manage to build decent 5×5 RGB LED matrix that is fully controllable by a computer.

[KopfKopfKopfAffe] didn’t have the time or money to wait for manufactured PCBs, so a bunch of perfboard was placed in a CNC mill with a pen to act as a plotter. All the lines that needed soldered were drawn on by the mill, a feat that probably saved hours of looking at the design before committing solder to iron.

A total of five boards were constructed, each one capable of controlling five RGB LEDs. Each board can be dasiy-chained with an RS-232 serial connection for further expansion. The only thing that’s needed to control the matrix is 17 bits that includes an address and RGB color data for each LED. The system only cost about 10 Euros per node, but we think that could be significantly reduced by leaving out the Molex and DB-9 connectors. [Kopf] project turned out very nice, check it out after the break.

X10 has been around for a long time. It’s the brand name for a set of wireless modules used to switch electrical devices in the home. There’s all kinds of different units (bulb sockets, electrical outlets and plug pass-throughs, etc.) and they’re mass-produced which makes them really inexpensive. Whether you already have some X10 controlled devices or just plan to add them later, we think you’ll find [Jeff Ledger's] post on controlling the system with a Propeller chip interesting. The technique is not Propeller specific and will be simple to port to your microcontroller of choice.

[Jeff] got his hands on an X10 Firecracker. This provides a DB-9 serial connection meant to be used for computer control. But the interface is so simple all you need is two I/O pins feeding the level converter circuit seen above. You can get the TC4427 for less than a dollar, and the Firecrcker module for as little as $6. Since [Jeff] has already covered adding Ethernet via a ENC28J60 he goes on to detail a web-server that lets him switch his devices, all served from the Propeller chip.

Here’s a different ENC28J60 Ethernet tutorial for those interested in webpages from microcontrollers. And then there’s also a ZigBee home automation project if you’re not warming up to the idea of using X10 modules.

[Andrew] is trying to buckle down and hammer out his PhD project but was surprised by the sorry state of the configuration options for his FPGA/ARM dev board. Using JTAG was painfully slow, so he studied the datasheet to see if there was another way. It turns out the Xilinx FPGA he’s using does have a slave serial mode so he came up with a way to push configuration from the ARM to the FPGA serially.

Four of the connects he needed were already mapped to PortC pins on the AT91SAM9260 ARM System on a Chip. He ended up using the EN_GSM pin on the FPGA, since there is no GSM module on this board; connecting it to the microcontroller with a piece of wire. Now he can SSH into the ARM processor, grabbing information on the FPGA from /dev/fpga0. When it comes time to program, it’s as easy as using the cat command on the binary file and redirecting the output to the same hook.

[Larsim] worked out the timing necessary to read button and joystick data from an N64 controller using an ATtiny85 microcontroller. The project was spawned when he found this pair of controllers in the dumpster. We often intercept great stuff bound for the landfill, especially on Hippie Christmas when all the student switch apartments at the same time.

Instead of cracking the controllers open and patching directly to the buttons, [Larsim] looked up the pinout of the connector and patched into the serial data wire. In true hacker fashion, he used two 5V linear regulators and a diode in series to step his voltage source down to close to 3.6V, as he didn’t have a variable regulator on hand. It does sound like this causes noise which can result if false readings, but that can be fixed with the next parts order.

The controller waits for a polling signal before echoing back a response in which button data is embedded. This process is extremely quick, and without a crystal on hand, the chip needs to be configured to use its internal PLL to ramp the R/C oscillator up to 16Mhz. With the chip now running fast enough, an external interrupt reads the serial response from the controller, and the code reacts based on that input.

It seems the biggest reason these N64 controllers hit the trash can is because the analog joystick wears out. If you’ve got mad skills you can replace it with a different type.

If you find a crusty old IT guy and give him half a chance, he’ll probably regale you with stories of how things were done “in the old days” where no one had their own computer and everyone worked on mainframe-connected dumb terminals. [JSTN] yearned for a true to life terminal display that he could attach to his 2010 Mac Pro, and since there’s no chance anybody is bringing one to market any time soon, he pieced one together on his own.

He dug up a digital VT220 terminal, and got to work trying to interface this office relic with his shiny new Mac. He found a few helpful tips from someone who did the same thing with an Apple ][c, though that solution relied on emulating a terminal - something he did not want to do.

He connected the VT220 to his computer using an off the shelf USB to serial adapter, but the software side of things still needed attention. A quick gettytab tweak later, he had his hardware terminal up and running without much trouble.

He says that he is more than happy to help anyone do the same, so let the mad eBay scramble for old terminals begin!

[via Adafruit blog]

[Giacomo] finds that every once in awhile, he needs to flash a sketch to an Arduino while on the go. While he doesn’t always carry his laptop with him, he almost certainly has his Zipit Z2 on hand. He prefers to use the Zipit because it’s tiny, it uses Debian, has built-in WiFi, and can run for about 5 hours before requiring a recharge. The only shortcoming is that the device lacks a serial port.

Following instructions we featured last year he added a serial port to his device, then built a small converter cable that allows him to connect it to virtually any Arduino. He says it only takes a moment to get avrdude up and running on the Zipit via apt-get, and once that’s done, he is in business. He wrote a short script that saves him from entering the flash command over and over, so the process couldn’t be simpler.

He does mention that since the Zipit does not have a DTR line, Arduino resetting must be done manually. For the convenience of flashing sketches from the palm of our hand, we can deal with that.

Check out the video below for a quick demonstration of his setup.

[Arto] recently upgraded his home Internet subscription from an ADSL to VDSL, and with that change received a shiny new ZTE ZXDSL 931WII modem/wireless router. Once he had it installed, he started to go about his normal routine of changing the administrator password, setting up port forwarding, and configuring the wireless security settings…or at least he tried to.

It seems that he was completely unable to access the router’s configuration panel, and after sitting on the phone with his ISP’s “support” personnel, he was informed that there was no way for him to tweak even a single setting.

Undaunted, he cracked the router open and started poking around. He quickly identified a serial port, and after putting together a simple RS232 transceiver, was able to access the router’s telnet interface. It took quite a bit of experimentation and a good handful of help from online forums, but [Arto] was eventually able to upload an older firmware image to the device which gave him the configuration tools he was looking for.

Aside from a few Ethernet timeout issues, the router is now performing to his satisfaction. However, as a final bit of salt in his wounds, he recently read that the admin panel he was originally seeking can be accessed via the router’s WAN interface using a well-known default password – frustrating and incredibly insecure, all at the same time! He says that he learned quite a few things along the way, so not all was lost.

[Autuin] found a Compaq Portable III destined for the scrap bin at Free Geek Vancouver. Upon seeing it he realized that it could still fight;  fight against the tyranny of hipsters and their shiny Macbook Pros at his  local coffee shop. Unfortunately, being a 286, the computer couldn’t do much. He could take the usual route; which is to remove all the internals, and use the vast amount of space to fit a more modern computer inside. However, he decided to go a different path and save the internals, leaving it in original working order. The computer didn’t have enough power to browse the web, but it had just enough room to fit a small single-board computer inside; to which he could connect through serial. He hasn’t taken it down to the coffee shop yet, but we’re hoping for a few horrified hipsters and a full mission report when he does.

[Sent in by Alec Smecher]

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.

Following Maker Faire, we’ve had a few days to poke around with Digilent’s 32-bit Arduino-compatible chipKIT boards and compiler. We have some initial performance figures to report, along with impressions of the hardware and software.

Disclaimer: Digilent has provided Hack a Day with Uno32 and Max32 boards for evaluation.

chipKIT isn’t the first attempt to extend the Arduino form factor to a 32-bit microcontroller core…other products such as Maple, Netduino or the FEZ Domino have been around for well over a year…but the chipKIT boards are notable for the effort Digilent has put into creating a seamless transition. The aim is to create a single unified tool both for traditional 8-bit Arduino boards and Digilent’s 32-bit work-alikes, where the same IDE, the same code, and a good number of the same shields can all work despite the different underlying architectures. In fact, they’re hoping the Arduino project accepts their integration method as an official means of adding new hardware to the Arduino IDE — not just for their own product, but for anyone else to use as well.

As noted in our prior report, we were impressed that they do appear to deliver on this promise. The transition between “classic” Arduinos and the 32-bit boards is indeed quite slick. But we’re finding at this early stage that there are still some rough bits to be worked out. So, for the time being, we’re keeping both the Arduino IDE and Mpide (Digilent’s multi-platform derivative) installed on the development system; the latter has not yet obviated the need for the former. But we see how the concept is supposed to work, and we like it.

For the most part, Mpide works as intended as a dual-platform IDE. Just select the appropriate device from the Tools->Board menu, recompile, and the code is now ready for the corresponding chip. But a couple things have bit us in the rear:

• The AVR compiler in Mpide either isn’t fully optimizing, or the floating-point libraries were built sans optimization or something. This threw off our benchmark numbers initially — the results were atrocious! In order to keep the numbers realistic, we’re using the standard Arduino IDE for the corresponding benchmarks. To be fair, they did warn us about this performance issue in person at Maker Faire, but until it’s fixed they could be more forthcoming about it with some documentation or on the web site…otherwise it could look like they’re trying to skew benchmarks more in their favor.
• The String() constructor is borked when handling integers. The following line compiles fine for AVR chips, but throws a tizzy fit with the PIC32 compiler:
  

  String foo = String(42);

Given that the IDE was wrapped up literally hours before going live online and at Maker Faire, it’s understandable that there are some loose ends. Just be prepared as an early adopter that this won’t be as pain-free a transition as they’re aiming for. The great thing with open source is that we can get in there, spot such problems, and offer suggestions and submit fixes…the situation will no doubt improve with time.

Some Benchmarks

We wanted to create a fractal demo similar to what they were displaying at Maker Faire. We didn’t have the spiffy SparkFun Color LCD Shield on hand, so instead we had to settle for a serial LCD, 4D Systems’ uLCD-144. This does affect the numbers somewhat, as we’ll see.

In MIPS alone, the chipKIT should beat the Arduino by a factor of five. Then there’s the native 32-bit-ness of it: when dealing with larger numbers, the AVR processor at Arduino’s core has to shift and fiddle bits between consecutive 8-bit values in order to achieve 32-bit results. So the PIC32 should show a considerable performance benefit beyond MIPS alone. In practice, this doesn’t always pan out.

The uLCD-144 is a 128 by 128 pixel 16-bit color LCD with a serial UART interface running at 115,200 bits per second. The graphics commands aren’t terribly efficient, and it’s necessary to send a five byte packet for every pixel drawn. This includes coordinate data; there’s no block write function in serial mode. On the plus side, it’s easy to talk to using the Arduino or chipKIT’s native serial UART.

Here’s the code for the Mandelbrot sketch, using floating-point math:

/* Simple Mandelbrot set renderer for Arduino vs. chipKIT benchmarking
   w/floating-point math, via www.hackaday.com.  This example uses the
   4D Systems uLCD-144(SGC) serial display module, wired as follows:

      uLCD Pin:   RES  GND  RX  TX  VIN
   Arduino Pin:     2  GND   1   0   5V    */

const int
  pixelWidth  = 128,  // LCD dimensions
  pixelHeight = 128,
  iterations  = 255;  // Fractal iteration limit or 'dwell'
const float
  centerReal  = -0.6, // Image center point in complex plane
  centerImag  =  0.0,
  rangeReal   =  3.0, // Image coverage in complex plane
  rangeImag   =  3.0,
  startReal   = centerReal - rangeReal * 0.5,
  startImag   = centerImag + rangeImag * 0.5,
  incReal     = rangeReal / (float)pixelWidth,
  incImag     = rangeImag / (float)pixelHeight;

void setup()
{
  pinMode(13,OUTPUT);   // Arduino status LED
  pinMode(2,OUTPUT);    // LCD reset pin
  digitalWrite(13,LOW); // LED off
  Serial.begin(115200);

  digitalWrite(2,LOW);  // Reset LCD
  delay(10);
  digitalWrite(2,HIGH);
  delay(2000);          // Allow time for reset to complete

  Serial.write(0x55);   // Issue auto-baud command
  while(Serial.read() != 0x06); // Wait for ACK
}

void loop()
{
  unsigned char cmd[20];   // Serial packet for LCD commands
  int           x,y,n;
  float         a,b,a2,b2,posReal,posImag;
  long          startTime,elapsedTime;

  Serial.write(0x45);      // Clear screen
  delay(100);              // Brief pause, else 1st few pixels are lost

  cmd[0] = 0x50;           // 'Pixel' command is issued repeatedly

  digitalWrite(13,HIGH);   // LED on while rendering
  startTime = millis();

  posImag = startImag;
  for(y = 0; y < pixelHeight; y++) {
    cmd[2] = y;            // Y coordinate of pixel
    posReal = startReal;
    for(x = 0; x < pixelWidth; x++) {
      a = posReal;
      b = posImag;
      for(n = iterations; n > 0 ; n--) {
        a2 = a * a;
        b2 = b * b;
        if((a2 + b2) >= 4.0) break;
        b  = posImag + a * b * 2.0;
        a  = posReal + a2 - b2;
      }
      cmd[1] = x;          // X coordinate of pixel
      cmd[3] = n * 29;     // Pixel color MSB
      cmd[4] = n * 67;     // Pixel color LSB
      Serial.write(cmd,5); // Issue LCD command
      posReal += incReal;
    }
    posImag -= incImag;
  }

  elapsedTime = millis() - startTime;
  digitalWrite(13,LOW);    // LED off when done

  // Set text to opaque mode
  cmd[0] = 0x4f;
  cmd[1] = 0x01;
  Serial.write(cmd,2);

  // Seems the chipKIT libs don't yet handle the String(long)
  // constructor, hence this kludge.  Working backward, convert
  // each digit of elapsed time to a char, with " ms" at end
  // and text command at head.  Length is variable, so issue
  // command from final determined head position.
  cmd[19] = 0;
  cmd[18] = 's';
  cmd[17] = 'm';
  cmd[16] = ' ';
  n = 15;
  do {
    cmd[n--] = '0' + elapsedTime % 10;
    elapsedTime /= 10;
  } while(elapsedTime);
  cmd[n--] = 0xff; // Color LSB
  cmd[n--] = 0xff; // Color MSB
  cmd[n--] = 0;    // Use 5x7 font
  cmd[n--] = 0;    // Row
  cmd[n--] = 0;    // Column
  cmd[n] = 0x73;   // ASCII text command
  Serial.write(&cmd[n],20-n);

  delay(5000); // Stall a few seconds, then repeat
}

And the timing results, in milliseconds, for the Arduino (top) and chipKIT (bottom):

Arduino: 54,329 ms.
chipKIT: 12,417 ms.

To reiterate (pardon the pun), due to some performance issues we used the traditional Arduino compiler, not the one included in Mpide. If you’re curious, the output from that compiler took about 8.5 minutes to complete the task! Oof.

So, about a 4.4x speedup. Not bad, but we were expecting a more dramatic difference. Part of this is due to the inherent bottleneck of the serial communication with the LCD…we’ll get back to that in a moment. Another limiting factor is that both chips are emulating floating-point math. If we can use 32-bit integer data types, thePIC32 should really shine. So, a fixed-point Mandelbrot generator followed:

/* Simple Mandelbrot set renderer for Arduino vs. chipKIT benchmarking
   w/fixed-point math, via www.hackaday.com.  This example uses the
   4D Systems uLCD-144(SGC) serial display module, wired as follows:

      uLCD Pin:   RES  GND  RX  TX  VIN
   Arduino Pin:     2  GND   1   0   5V    */

const int
  bits        = 12,   // Fractional resolution
  pixelWidth  = 128,  // LCD dimensions
  pixelHeight = 128,
  iterations  = 255;  // Fractal iteration limit or 'dwell'
const float
  centerReal  = -0.6, // Image center point in complex plane
  centerImag  =  0.0,
  rangeReal   =  3.0, // Image coverage in complex plane
  rangeImag   =  3.0;
const long
  startReal   = (long)((centerReal - rangeReal * 0.5)   * (float)(1 << bits)),
  startImag   = (long)((centerImag + rangeImag * 0.5)   * (float)(1 << bits)),
  incReal     = (long)((rangeReal / (float)pixelWidth)  * (float)(1 << bits)),
  incImag     = (long)((rangeImag / (float)pixelHeight) * (float)(1 << bits));

void setup()
{
  pinMode(13,OUTPUT);   // Arduino status LED
  pinMode(2,OUTPUT);    // LCD reset pin
  digitalWrite(13,LOW); // LED off
  Serial.begin(115200);

  digitalWrite(2,LOW);  // Reset LCD
  delay(10);
  digitalWrite(2,HIGH);
  delay(2000);          // Allow time for reset to complete

  Serial.write(0x55);   // Issue auto-baud command
  while(Serial.read() != 0x06); // Wait for ACK
}

void loop()
{
  unsigned char cmd[20];   // Serial packet for LCD commands
  int           x,y,n;
  long          a,b,a2,b2,posReal,posImag,startTime,elapsedTime;

  Serial.write(0x45);      // Clear screen
  delay(100);              // Brief pause, else 1st few pixels are lost

  cmd[0] = 0x50;           // 'Pixel' command is issued repeatedly

  digitalWrite(13,HIGH);   // LED on while rendering
  startTime = millis();

  posImag = startImag;
  for(y = 0; y < pixelHeight; y++) {
    cmd[2] = y;            // Y coordinate of pixel
    posReal = startReal;
    for(x = 0; x < pixelWidth; x++) {
      a = posReal;
      b = posImag;
      for(n = iterations; n > 0 ; n--) {
        a2 = (a * a) >> bits;
        b2 = (b * b) >> bits;
        if((a2 + b2) >= (4 << bits)) break;
        b  = posImag + ((a * b) >> (bits - 1));
        a  = posReal + a2 - b2;
      }
      cmd[1] = x;          // X coordinate of pixel
      cmd[3] = n * 29;     // Pixel color MSB
      cmd[4] = n * 67;     // Pixel color LSB
      Serial.write(cmd,5); // Issue LCD command
      posReal += incReal;
    }
    posImag -= incImag;
  }

  elapsedTime = millis() - startTime;
  digitalWrite(13,LOW);    // LED off when done

  // Set text to opaque mode
  cmd[0] = 0x4f;
  cmd[1] = 0x01;
  Serial.write(cmd,2);

  // Seems the chipKIT libs don't yet handle the String(long)
  // constructor, hence this kludge.  Working backward, convert
  // each digit of elapsed time to a char, with " ms" at end
  // and text command at head.  Length is variable, so issue
  // command from final determined head position.
  cmd[19] = 0;
  cmd[18] = 's';
  cmd[17] = 'm';
  cmd[16] = ' ';
  n = 15;
  do {
    cmd[n--] = '0' + elapsedTime % 10;
    elapsedTime /= 10;
  } while(elapsedTime);
  cmd[n--] = 0xff; // Color LSB
  cmd[n--] = 0xff; // Color MSB
  cmd[n--] = 0;    // Use 5x7 font
  cmd[n--] = 0;    // Row
  cmd[n--] = 0;    // Column
  cmd[n] = 0x73;   // ASCII text command
  Serial.write(&cmd[n],20-n);

  delay(5000); // Stall a few seconds, then repeat
}

And the numbers:

Arduino: 27,734 ms.
chipKIT:  7,209 ms.

Now only a 3.8x difference, despite the PIC32 speaking its native tongue. What gives?

Even at 115,200 bits/sec, the serial LCD is seriously holding us back, as the code is going to “block” as each character is output. Some back-of-envelope calculations suggest how much time is being lost there:

128 x 128 pixels, 5-byte command per pixel = 81,920 bytes.
Including start and stop bits for each byte = 819,200 bits total
819,200 bits / 115,200 bps = ~7.1 seconds.

So our MCU is sitting there for seven seconds with its thumb up its ASCII in order to update the display. Sure enough, if we comment out the Serial.write() command but leave all the calculations in place, the results are significantly more dramatic:

Floating-point:

Arduino: 49,685 ms.
chipKIT:  5,822 ms.
9.3x improvement.

Fixed-point:

Arduino: 22,326 ms.
chipKIT:    168 ms
133x improvement. Hot damn. Now we’re talking!

So we could actually render this at interactive frame rates, for the want of a sufficiently fast interface to the LCD. This sort of limitation is going to crop up every time we connect to a real-world device. Not everything is 100% internal code and math…there are finite limits to I/O throughput, and that more than anything can cap the speed of the total application. So we really can’t give a consistent “Everything will be X percent faster” estimate for this board.

The performance looks good for math, especially if an algorithm can work in integer or fixed-point formats. Another thought we had was analog-to-digital sampling, which has applications in robotics…say for a line-follower or balancing robot. More frequent samples should yield smoother operation, or multiple samples can be averaged to yield higher-precision results. The PIC32 should scream in that regard. And yet…

void setup()
{
  const int samples = 10000;
  int       i,n;
  long      startTime,elapsedTime;

  Serial.begin(115200);

  startTime = millis();
  for(i = 0; i < samples; i++) {
    n = analogRead(0);
  }
  elapsedTime = millis() - startTime;

  Serial.print(samples);
  Serial.print(" samples in ");
  Serial.print(elapsedTime);
  Serial.print(" ms = ");
  Serial.print(((float)samples * 1000.0) / (float)elapsedTime);
  Serial.println(" samples/sec");
}

void loop()
{
}

Arduino: 10000 samples in 1119 ms = 8936.55 samples/sec
chipKIT: 10000 samples in 1008 ms = 9920.63 samples/sec

Running full-tilt, the PIC32 is capable of up to 1 million ADC samples per second, compared to 125,000 on the Atmel chip. Certainly the library implementation is going to introduce some overhead, but what gives? Rooting through the library source code turns up this gem in wiring_analog.c:

 //*     A delay is needed for the the ADC start up time
 //*     this value started out at 1 millisecond, I dont know how long it needs to be
 //*     99 uSecs will give us the same approximate sampling rate as the AVR chip
 //      delay(1);
 delayMicroseconds(99);

This raises a couple of red flags. First, why should the sampling rate aim to match the AVR? For time-related functions like delay() and for Serial.begin() bitrates, of course we’d want similar numbers, those relate to temporal increments. But we don’t — or at least shouldn’t — measure time with ADC readings. And secondly, well, why not find out how long the ADC startup time really needs to be? A few minutes’ sifting through Microchip datasheets eventually turned up the correct answer: two microseconds. So, changing the line in wiring_analog.c to:

delayMicroseconds(2);

Yields dramatically different results:

chipKIT: 10000 samples in 101 ms = 99009.90 samples/sec

About a tenfold improvement, and the readings still look valid. This does break like-timing compatibility with the AVR-based Arduinos, but as we said, why? It’s understandable that some decisions may have been made in haste…it’s a monumental project, getting all this code ported to an entirely different chip, and the IDE is still fresh from the oven…but some of these little broken details do have us concerned about what other surprises may still lurk beneath.

Don’t get us wrong…we’re enthusiastic about the chipKIT boards. The technical challenge is met, and just needs some cleaning up. What remains for Digilent now is a marketing challenge: who is this really for? When we talk about things like megasamples and fixed-point algorithms, these aren’t exactly day-one topics familiar to the Arduino’s target audience of first-time programmers. And the more advanced user may have moved on already, leaving Arduino behind. So why keep this form factor? Why keep this IDE?

Obviously, part of the allure is the existing ecosystem of Arduino shields. There’s some pretty nifty stuff out there, networking and touch screens and stepper motor drivers, most of which will physically plug right in. Having an existing solution saves development time. Then there’s the ease and familiarity of the Arduino libraries. Even though they’re slow and clunky in places, it can be really handy sometimes just to squirt out some status information to a serial port without having to do all the UART setup manually.

The chipKIT boards are cleverly priced to approximate Arduino on a cost basis (even undercutting a bit). That’s a great start, with code and price parity, but where’s the extra value? What the Uno32 and Max32 may need are some killer apps. Ideas that the novice can implement, but that really take advantage of the PIC32 chip’s added performance and capabilities. Speed may be just one part of that. What can we do with the extra RAM and flash space that a normal Arduino just can’t handle, even with the fanciest of shields? Folks have done some mind-blowing stuff with the little 8-bit AVR. We’re looking forward to seeing if this is the tool that takes these hacks to the next level.

[Wayne] wrote in to share an item he just finished working on, an I²C GPS shield for the Arduino. While other GPS solutions have existed for quite some time, his caught our eye due to its feature list.

The shield removes a good bit of the hassle associated with parsing raw NMEA data from traditional GPS addons. While you have the option to communicate with the GPS module over serial in order to obtain the raw data, the use of the I²C interface makes getting the most commonly used GPS data a breeze. The GPS module itself can be set to update at anywhere from 1 to 10 Hz, and [Wayne] says that the I²C bus blows away the oft-used 9600 baud serial interface. While I²C is primarily used for receiving data, it can also be utilized to configure the GPS via its control registers, allowing for on the fly settings tweaks.

While he does sell the units pre-assembled at a competitive price, [Wayne] also provides a full schematic, making this an easy afternoon project once you have sourced the proper components.

[Paul] wrote in to tell us about some interesting Arduino latency issues he helped nail down and fix on the Arduino.

It seems that [Michu] was having some problems with controlling his Rainbowduino project we featured earlier this year, and he couldn’t quite figure out why he was experiencing such huge delays when sending and receiving data.

Searching online for answers turned up very little, and since [Michu] was using Processing, the pair designed a set of tests to see what kind of latency was being introduced by Java. Pitting an Arduino Uno and an Arduino from 2009 against a Teensy 2.0, the tests gauged the latency of native data transfers versus transfers facilitated by Java via the rxtx library it uses for serial communications.

The results were pretty stunning. While both of the Arduinos lagged behind the Teensy by a long shot, their latency values under Java were always 20ms at a minimum – something didn’t add up. [Michu] poked around in the rxtx code and found a mystery 20ms delay programmed into the serial library. It made no sense to him, so he changed the delay to 2ms and saw a drastic increase in performance when transferring less than 128 bytes of data.

The pair’s fix doesn’t seem to affect latency when larger amounts of data (>1kB) are being transferred, but it makes a world of difference when manipulating smaller chunks of data.

For the sake of disclosure, it should be noted that [Paul’s] company produces the Teensy mcu.

[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.

[Oneironaut] is trying out a new GPS module with the prototype seen above. It’s a San Jose Navigation device identified as FV-M8 and sold by Sparkfun for just under a hundred bucks. That’s it hanging off the bottom-right of the breadboard seen above. They’ve packed a lot of power into the small footprint, and made it very easy to control at the same time. Although the device is fully configurable, you can start grabbing serial data from it just by connecting a single data line, 3.3V, and ground.

[Oneironaut] tests it out by streaming the serial data to a character LCD screen, then comparing the output to his handheld Garmin GPS device. You can see him describe his ATmega32-based test platform in the video after the break. We’re used to seeing spy-tech for most of his projects and this will eventually join those ranks. He’s thinking of putting together a magnetic tracking module that plays nicely with Google Earth.

This hack is a bit older, but one aspect of the setup makes it worth sharing. Shift registers are a common component to include in a project when you need to increase the number of I/O pins available. We’ve used them to drive LCD screens before, but we never realize you could use a 595 chip to make a 3-wire serial LCD interface. That’s because we’ve always thought of shift registers as having three control pins which must be addressed: data, clock, and latch. But it seems that’s not the case. This hack gangs the pins for clock and latch (called the storage register clock input on this chip) together. This causes the shifted data to be latched to output register one clock cycle after it is shifted into the chip.

This means you can operate the 595 chip with just two pins, but alas, you do need one more connection to drive the LCD properly. This is an HD44780 compliant display. It is being used in 4-bit mode; four of the shift register pins provide that data, while a fifth controls the Register Select pin. Since the shifted data from the 595 appears on the pins after each clock strobe, you must control the Enable pin on the LCD separately or it will behave sporadically.

So there you have it, control an HD44780 display with just 3-pins by using a $0.42 part. Are we going a little too fast for you? Check out this 595 tutorial and give the shift register simulator a try. That should bring you up to speed.

[Thanks Rajendra]