The only problem I se with the plan is the difficulty of turning the shaft of a 30:1 or 50:1 gearmotor.  When you turn the output shaft by hand you are turning the motor 30 or 50 times as fast.  That's a lot of momentum.

A better choice might be a stepper motor with a shaft encoder.  The encoder will allow you to track the current position and the motor is fairly easy to turn when the windings are not powered.

100 times a second the ISR will refresh all 64 pixels, one row at a time, using whatever image the 'frame' counter points to.

10 times a second (well, slower because the delay() isn't the only thing that takes time) the main loop updates the 'frame' counter.  (it also scrolls all the frames sideways)

The net effect is that the pixels get refreshed about ten times between frame changes.

Does the "Severino S3V3" mean that it's running on 3.3 Volts?  If so you probably shouldn't be running it at 16 MHz.  You need at about 3.8 Volts to run at 16 MHz.  You can easily run at 8 MHz which only requires about 2.4 Volts.

To determine required voltage:  Take the desired clock speed (between 4 and 20 MHz), add 6.665 MHz and divide by 5.925 MHz/Volt to get Volts.

What format is the object code?  .o?  .hex?

The Arduino distribution includes avr-objdump and avr-readelf which can read and disassemble various object formats.

In a terminal window, try:  /Applications/Arduino22.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-objdump -h (yourfile)

You forgot to set 'i' back to 0 after you process the input.
You should also put a null terminator on the string before you convert to a number.
You should also allow for values less than four characters.

Something like this should work (not tested):

Code:

void loop() {
      // send data only when you receive data:
      if (Serial.available())
          {
          dados[i] =  Serial.read();
          if (isdigit(dados[i]))
               i++;
          else
          if (i > 0) // Make sure we have some digits
              {
              dados[i] = '\0';  //  Add null terminator
              recebido = atoi(dados);
              i = 0;
     
              analogWrite(9,recebido);
              Serial.print("dir: ");
              Serial.println(recebido);
             delay(500);     
             }
        else
             {
            analogWrite (9, 0);
             }
       }
}

Given the desired heading it should be easy enough to calculate an error term in the range -180 to +180.

If simple proportional control gives too much of a dead band (error term too low to cause a correction but too high to be on course) you can change to a PI control.  If the heading oscillates, you can go to PID control.

One thing you should be aware of is that your course (direction of travel) will not necessarily be the same as your heading (direction the boat is pointing).  If there is a side force (current or wind) then the boat will drift sideways relative to the heading.

I could get the SSID of any nearby Wifi from a small keychain Wifi finder.  Then send it via 60mw Xbee.

I would know the approximate location of the Balloon!  Enough to find it anyway.
What do you think?  Feasible?

I think there might be a few minor glitches in your plan that may combine to make it infeasible.

1) Keychain WiFi detectors usually just give rough signal strength and not BSSID (MAC address)
2) With a 60mW XBee you would have to be fairly close to the balloon to get a data connection
3) Google seems to have blocked access to the BSSID-to-location database.  At least the two sites I found that used to be able to query the database no longer work.

You can't use delay() in an ISR because it relies on interrupts for timing and the interrupts are disabled during an ISR.

If you declare 'count' as volatile and just set it to 0 in the ISR then loop() will put the processor back to sleep in 10 seconds.

Code:

#include <avr/sleep.h>
#include <avr/power.h>

int fsr = 0;
volatile int count = 0;
int analogPin = 0;

[...]

ISR(ANALOG_COMP_vect)
{
  if(analogRead(analogPin) > 100)
  {
    count = 0;
    fsr = analogRead(analogPin);
    Serial.println("The reading is ");
    Serial.println(fsr);
  }
}

The interrupt service routine updates an 8x8 LED matrix 1000 times a second (or as fast as it can if it takes more than a millisecond to do an update).  You might want to change that time to 10,000 microseconds (100 refreshes per second).

The main loop runs at close to 10 frames per second.  For each frame it indexes to the next image to cause the wheel to appear to rotate and shifts  all the wheel images one pixel to the left so it will appear as if one wheel is moving out of frame to the left while a second wheel moves into frame from the right.

Since 'frame' is written in loop() and read in the interrupt service routine you should declare it 'volatile'.

Several times in the recent past people have asked "If I have a bare-bones Arduino project in a remote installation, how do I send a new sketch to the site in such a way that someone there can upload it to the Arduino without having to install the Arduino environment and having a USB-to-Serial cable?".  This article just published in Hack-a-Day might provide a solution:

http://hackaday.com/2011/09/09/program-an-arduino-using-your-sound-card/
    http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=128&p=531
    http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=127

The article is about a Java program that will convert a .hex file to a .wav file and an Audio Bootloader that will allow the ATmega chip to interpret the audio in the .wav file.  Send the .wav to the remote site and have them play it through a cable to the Arduino.  The only cable they should need is a mini phone plug to mini phone plug cable.  They might even be able to copy the audio to an iPod and play from there.

The 3.3v model will have a 3.3v regulator and 8 MHz crystal/resonator.
The 5v model will have a 5v regulator and 16 MHz crystal/resonator.

The regulator appears to have 5 pins and is between the processor and the end with the serial port connections.
The crystal/resonator is near Pin 2.

I remember someone else having a similar problem.  It turned out that one of their two devices was not fully I2C compliant.  It worked fine by itself but since it did not implement addressing it responded to every request on the bus, even requests for other devices.  Check the specifications for our LCD to see if it's supposed to work with other I2C devices on the same bus.

Check the current flow on those with a multimeter - they don't look very bright.

From the close-up picture it looks like there is one current limiting resistor for all four LED's in a group.  I'm pretty sure that each LED should have a separate current limiting resistor.  If the resistor is chosen to provide 20 milliamps then, the way it is wired, the four LED's have to share the 20 milliamps rather than each getting 20.

http://www.hobbyking.com/hobbycity/store/uh_viewitem.asp?idproduct=11867

$12.99 keychain video camera + 2GB micro-SD card
"This is an archived page. This product is no longer available and has been replaced by a newer product."

http://www.hobbyking.com/hobbycity/store/uh_viewitem.asp?idproduct=13447
$7.69 keychain video camera (Micro SD card sold separately for $5.59)

For $50 you can get a Boost Mobile Motorola i296: http://www.boostmobilestore.com/bpdirect/boost/PhoneList.do?action=view&id=i296

Then you can install free GPS tracking software from mologogo.com InstaMapper.com or Buddyway.com

If the phone is too heavy you can remove the case some other parts.