Show Posts
Pages: [1]
1  Using Arduino / Sensors / Re: SHARP IR Distance Sensor - GP2D120XJ00F on: September 14, 2011, 03:14:55 pm
FYI, in my case adding just the capacitor onto the sensor power pins (directly on the sensor, not Arduino) did not reduce the spikes in measured distance readings much. But adding a 10ohm resistor between Arduino +5V power and the capacitor improved things a lot. Here are the standard deviations of measured distance (about 10cm from sensor, measured every 7ms):

plain sensor connected to Arduino +5V/GND: 0.27cm standard deviation, mainly consisting of ca 1cm spikes occuring ca 20 times per sec

with 100uF cap on sensor power pins: 0.15cm

with 100uF cap+10ohm resistor: 0.03cm
2  Using Arduino / Programming Questions / Re: Problem uploading to board on: September 11, 2011, 04:45:35 am
I also had the same problem (on Linux; Fedora 13 with brand new Arduino Uno R2), and finally solved it after debugging for a few days. The critical bit of the solution was just to plug Arduino directly into my computer's USB port, instead of Apple Cinema display USB hub port! And also use arduino-0022 and its avrdude binary (which is apparently modified from standard avrdude to support Arduino).

Some infobits that I discovered while debugging this:

* The "not in sync: resp=0x86" error stems from the fact that the default program contained in my Arduino as shipped prints a string of bytes (beginning with 86 hex) into the USB connection. The string is (in hex): 86 18 18 00 86 86 00 18 1e 66 60 06 06 06 f8 9e 00 60 06 06 06 18 06 60 06 78 06 86 9e 00 18 06 e6 9e 00 06 06 60 06 06 06 fe 66 18 18 fe 66 18 18 fe 66 78 06 fe 9e 00 18 06 66 66 f8 98 00 fe 98 00 fe 66 00 18 fe 66 1e 18 7e 00 78 00 06 78 00 18 78 00 (in 7N1 serial data format, this actually contained an intelligible string "Standarda_2_2_forUNO_0_3"). So the "not in sync: resp=0x86" effectively means that the optiboot bootloader on Arduino has gave up waiting for input from USB (it waits for input for 500ms), and has started the user program. After that there is no hope of uploading anything, before the Arduino is reset.

* Uploading the latest 8U2 firmware via dfu-programmer did not improve anything. Still the same symptoms.

* Experimenting with pressing the reset button before/while/after uploading (or while plugging the USB cable in) did not fix the problem in my case, although it sometimes changed the error message, and with upload.verbose=true in ~/.arduino/preferences.txt I saw that avrdude sometimes managed to issue a couple of commands successfully to Arduino, but then it again got a 0x86 response before upload could be completed.

* In fact the problem was caused by about 70% of commands on the USB being somehow randomly dropped. Since avrdude needs to issue more than 10 commands to successfully upload the program, it had a very low chance of succeeding, even though it sometimes managed to issue the first few commands. And as soon as 500ms are passed without any successful command, the bootloader starts the user program and the dreaded 0x86 byte is received. Here is a Perl script I wrote to debug the issue:

Code:
#!/usr/bin/perl

use strict;
use Device::SerialPort;
use Time::HiRes qw ( time sleep );

my $port = Device::SerialPort->new("/dev/ttyACM0");
my $start_time=time;
# $port->dtr_active(0);
$port->databits(8);
$port->baudrate(115200);
$port->parity("none");
$port->stopbits(1);
$port->read_const_time(20);

$port->write("0 ");
sleep(0.55); # In my tests, this had to be 0.45..0.95, otherwise almost no responses are received
$port->input;

my $last_recv=time;
my $recv_count=0;
my $send_count=0;
while ($recv_count < 100) {
$port->write("0 "); # stk500 protocol STK_GET_SYNC command
$send_count++;

my ($count,$string_in)=$port->read(1);
if ($count > 0) {
$string_in.=$port->input;
$last_recv=time;
$recv_count++;
}
last if (time-$last_recv > 1.5);
}

print "$recv_count $send_count\n";

If everything works, it should print "100 100" (meaning it sent 100 commands to bootloader and got 100 responses). But when Arduino is plugged into Apple Cinema USB, it prints something like "31 100", meaning only 31 responses were received, or even something like "9 40", meaning the bootloader gave up even before it managed to send 100 commands. Both conditions are symptoms of the "packet loss" problem, which was ultimately solved by not using the Apple Cinema USB hub.
Pages: [1]