The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: PC Tweakage

Remembering which tweaks worked

  • Arduino Command Line Programming: Avrdude Puzzlement

    For all the usual reasons, I’d like to compile & download Arduino programs from the command line, rather than through the (excellent!) IDE. That is supposed to work and, for most folks, apparently it does.

    Not here, alas.

    I’ve installed the 0012 Arduino Java IDE (x86 or x86_64 as appropriate) from http://code.google.com/p/arduino/ on three different systems, all with Kubuntu 8.04:

    • Dell Dimension 9150 – x86_64, which seemed like a good idea at the time
    • Dell Inspiron E1405
    • Dell Inspiron 8100

    In all cases the IDE works perfectly, compiles & downloads programs just fine, and behaves exactly as you’d expect. I had a few minor quibbles with sorting out various paths & suchlike, but, on the whole, it has no troubles at all with either a Diecimila or a Sparkfun Arduino Pro (with a Sparkfun FTDI Basic USB gizmo).

    I tweaked ~/.arduino/preferences.txt to include:

    console.auto_clear=false
    build.verbose=true
    upload.verbose=true

    Here’s the final step in the IDE compile-and-download dance. Backslashes indicate continuations of the same line; the original is all on single line:

    hardware/tools/avrdude -Chardware/tools/avrdude.conf -v -v -v -v -pm168
    -cstk500v1 -P/dev/ttyUSB0 -b19200 -D
    -Uflash:w:/mnt/bulkdata/Above the Ground Plane/
    2009-06 Solar Data Logger/Firmware/Logger/applet/Logger.hex:i 
    
    avrdude: Version 5.4-arduino, compiled on Oct 22 2007 at 13:15:12
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
    
             System wide configuration file is "hardware/tools/avrdude.conf"
             User configuration file is "/home/ed/.avrduderc"
             User configuration file does not exist or is not a regular file, skipping
    
             Using Port            : /dev/ttyUSB0
             Using Programmer      : stk500v1
             Overriding Baud Rate  : 19200
    avrdude: Send: 0 [30]   [20]
    avrdude: Send: 0 [30]   [20]
    avrdude: Send: 0 [30]   [20]
    avrdude: Recv: . [14]
    avrdude: Recv: . [10]
             AVR Part              : ATMEGA168

    The IDE evidently does the reset-from-USB trick through the standard USB hardware.

    I set up the command-line Makefile from http://www.arduino.cc/en/Hacking/CommandLine, although that’s for the 0011 IDE, then made the recommended tweaks. The make section does exactly what you’d expect: compiles the source program.

    Running make upload fails every time, on every PC, with both boards. Indeed, in all cases, running avrdude on the command line produces the dreaded “not in sync” errors, showing that it’s unable to communicate with the Arduino board. Blipping the reset button on the Arduino board generally makes the USB transfer work fine, with the failures most likely due to my lack of dexterity & timing precision.

    The usual debugging suggestions aren’t relevant, as they all assume there’s a basic communication failure caused by anything from a completely dead board to mysterious library incompatibilities. In this case, however, I have an existence theorem: the IDE works perfectly before and after the command-line failure.

    It turns out that the IDE includes a specially patched avrdude, so I tried running that version from the directory where the IDE lives, using exactly the same command-line flags as the IDE does. Surprisingly, that doesn’t work. Again, backslashes indicate continuations of the same line and I added quotes to the file name to protect the blanks…

    hardware/tools/avrdude -Chardware/tools/avrdude.conf -v -v -v -v -pm168
    -cstk500v1 -P/dev/ttyUSB0 -b19200 -D
    -Uflash:w:"/mnt/bulkdata/Above the Ground Plane/
    2009-06 Solar Data Logger/Firmware/Logger/applet/Logger.hex":i
    
    avrdude: Version 5.4-arduino, compiled on Oct 22 2007 at 13:15:12
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
    
             System wide configuration file is "hardware/tools/avrdude.conf"
             User configuration file is "/home/ed/.avrduderc"
             User configuration file does not exist or is not a regular file, skipping
    
             Using Port            : /dev/ttyUSB0
             Using Programmer      : stk500v1
             Overriding Baud Rate  : 19200
    avrdude: Send: 0 [30]   [20]
    avrdude: Send: 0 [30]   [20]
    avrdude: Send: 0 [30]   [20]
    avrdude: Recv: . [1e]
    avrdude: stk500_getsync(): not in sync: resp=0x1e
    avrdude: Send: Q [51]   [20]
    avrdude: Recv: . [0f]
    avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x0f

    There’s no difference between the /opt/arduino/lib/librxtxSerial.so and /usr/lib/librxtxSerial.so libraries, which normally causes some confusion on x86_64 systems. I think that means the x86_64 version of the IDE has the correct library.

    I’ve also tried the stock Kubuntu avrdude, which is at V 5.5, to no avail.

    Given that the IDE works, that I’m running the same avrdude executable, and that the libraries match, I’m not sure where to go from here.

    While I’m generally dexterous enough to run make upload and blip the Arduino board’s reset button with my other hand, I’m bringing up a shield-like board that plugs atop the Arduino and, alas, lacks both a reset button and a hole over the Arduino’s button.

    The board is, of course, that one.

    Update: As a reasonable workaround, I’ve set the IDE up to use an external editor. Then I can tweak the programming, flip to the IDE, click the Download button, and away it goes. Not quite as easy as a full command-line solution, but close enough.

  • Dell GX270 Burn-in

    After describing the initial failure there, I’ve been having it boot at 6:15 am and shut down at 8:00 am; if it ever fails to shut down, I know it hasn’t started up correctly.

    As you might expect, it’s booted fine every morning for the last week. I think that’s good news…

    The /etc/crontab entry to make that happen is:

    00 08   * * *   root    shutdown -P now

    I suppose I should put a little script in /etc/cron.daily, rather than futzing with the main crontab file, but I’m lazy.

    The /etc/rc.local file starts up a few odds & ends:

    date >> /home/ed/startup.txt
    echo -n "starting rc.local ... " >> /home/ed/startup.txt
    ##-- update dyndns record of our external IP address
    echo -n "ddclient ... " >> /home/ed/startup.txt
    if [ -x /usr/sbin/ddclient ] ; then
             ddclient -force
    fi
    #-- fire off Primenet Mersenne Prime search
    echo -n "mprime ... " >> /home/ed/startup.txt
    /opt/primenet/mprime -t &
    echo -n "scanbuttond ... " >> /home/ed/startup.txt
    scanbuttond
    echo "done" >> /home/ed/startup.txt
    exit 0

    Most of that does some really crude logging to a file in my home directory. If it fails to start up, I’ll at least know when it last worked…

    As I mentioned earlier, I’ve disabled ddclient (to prevent it from snatching Mom’s current IP address out from under dyndns.com) by the simple expedient of renaming the file to ddclient.off. The script actually tests whether /usr/sbin/ddclient is executable, but changing the name makes it obvious why it’s not running.

    Just to keep the CPU heatsink warm, it runs GIMPS: The Great Internet Mersenne Prime Search. Admittedly, a 2.4 GHz Celeron isn’t exactly the ideal CPU for this task, but every little bit helps. Right now it’s running the torture test with all the memory it wants, but I’ll throttle that back when Mom gets it.

    Don’t know what I’ll do if it fails, to tell you the truth.

    Memo to self: remember to switch mprime back to normal mode with less memory.

  • USB Disconnects: Nobody Moves, Nobody Gets Hurt

    After grounding the obvious metal bits around the desk as shown there and taking some pains to zap the light switch on the wall (rather than the grounded objects) before sitting down and routing the USB cable away from everything else, the mysterious USB disconnects seem to have Gone Away.

    The USB hubs were reporting exactly what happened:

    hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling...

    Which wasn’t much help in the beginning, because I couldn’t correlate a static zap with the disconnect. Quite often, it’d be something innocent like plugging a camera into its USB/charging cradle with no obvious discharge.

    The onset of 0 °F weather and the ensuing 0% relative humidity, plus my donning a synthetic fleece jacket while venturing into the rather too-chilly basement laboratory, brought the problem to the fore. An inch-long arc to a light switch gets your attention pretty quick!

    Hint: when you know you’re charged, pull a pen from your pocket, get a good grip on the metal pocket clip, and use that to draw the spark from the light switch. The larger surface area contacting your fingers reduces the current density to the mild tingle level, rather than leaving a charred pit on the end of your finger.

    In round numbers, the dielectric breakdown voltage of air is 1 kV / mm. That inch-long arc required upwards of 20 kV: not bad for an acrylic jacket!

    When we go riding in the winter, we dress in layers of acrylic this and synthetic that, to the extent that simply moving generates a nasty charge. Hence the punchline: nobody moves, nobody gets hurt.

  • Kubuntu “Server” Time Drift

    I just tried compiling a program (for an Arduino) and make grumped about a date in the future:

    make: Warning: File `Makefile' has modification time 1.4e+02 s in the future
    <<< usual compile output snipped >>>
    make: warning:  Clock skew detected.  Your build may be incomplete.

    Turns out that the timestamps really were screwy:

    [ed@shiitake Solar Data Logger]$ date
    Sun Jan 25 10:57:44 EST 2009
    [ed@shiitake Solar Data Logger]$ ll
    total 28
    drwxr-xr-x 2 ed ed 4096 2009-01-25 10:59 applet
    -rw-r--r-- 1 ed ed 1920 2009-01-25 10:35 Logger.pde
    -rwxr-xr-x 1 ed ed 7719 2009-01-25 10:59 Makefile
    -rwxr-xr-x 1 ed ed 7689 2009-01-25 10:53 Makefile~
    -rw-r--r-- 1 ed ed 1880 2009-01-25 10:08 Solar Data Logger.pde~

    Well, now, how can that be?

    The offending files are stored on a file server, not on the machine in front of my Comfy Char. The current dates for the two machines weren’t quite the same: the server was running just slightly in the future.

    I used an ordinary Kubuntu desktop install on our “file server”, which is basically a Dell Inspiron 531s running headless in the basement. All this is behind a firewall router, so I do not have an Internet-facing machine running X, OK?

    Kubuntu has an option that updates the clock automagically, but only once per boot.

    Right now, that box claims an uptime of just over 22 days. It’s run for months at a time without any intervention, which just one of the things I like about Linux:

    uptime
     11:07:08 up 22 days, 19:52,  1 user,  load average: 0.00, 0.02, 0.00

    I think you can see the problem: after three weeks the PC’s internal clock had drifted more than two minutes fast.

    I used the Big Hammer technique to whack the server’s clock upside the head:

    sudo ntpdate pool.ntp.org
    [sudo] password for ed: youwish
    25 Jan 11:01:22 ntpdate[23062]: step time server 66.7.96.2 offset -151.277185 sec

    That’s 7 seconds per day or 151 seconds out of 2 megaseconds: 77 parts per million. It’s in a basement at 55 F right now, so there may well be a temperature effect going on.

    You can set up ntp (www.ntp.org or, better, from a package in your distro) to run continuously in the background and keep the clock in time by slewing it ever so slightly as needed to make the average come out right. I just added an entry to /etc/crontab like this:

    00 01   * * *   root    ntpdate north-america.pool.ntp.org

    That way the clock gets whacked into line once a day when nobody’s looking.

    If you’re running a real server with heavy activity, ntp is the right hammer for the job because you don’t want ntpdate to give you mysterious gaps of a few seconds or, worse, duplicate timestamps. Leap year is bad enough.

    More about ntp at http://en.wikipedia.org/wiki/Network_Time_Protocol.

    Memo to Self: set up ntp on the server and then aim all the desktops at it.

    I used to do that when I was running a GPS-disciplined oscillator to produce a nearly Stratum 1 clock on my server, but then power got too expensive for that frippery.

  • USB Disconnects: The Saga Continues

    Adding those grounding wires from my desk lamp and the aluminum plate under the keyboard / trackballs to the PC case reduced the problem, but didn’t eliminate it.

    Grounding Wire on Desk Lamp
    Grounding Wire on Desk Lamp

    Logging all that data, though, pointed to what (I think) is the cause: static discharge. I’ve been touching the screws on the wall switch before sitting down, which pretty much made the problem Go Away. Touching the (now-grounded) desk lamp or the keyboard plate still kills the hub, so the hub inside the PC must be way sensitive.

    The disconnect follows the external hub’s cable, which means (I think) the jolt’s entering through that wire. I’ve already tried different cables, but perhaps different routing will help; there’s a huge tangle of wires behind the desk.

    It’s enough to make one swear off this USB stuff!

  • USB Disconnects, Continued

    The saga continues…

    After adding ground connections to the lamp and keyboard / trackball tray (doodling off to the PC case), another disconnect after a day of rising expectations:

    [37681.592585] hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
    [37681.592595] usb 3-1: USB disconnect, address 4
    [37681.592598] usb 3-1.1: USB disconnect, address 5
    [37681.644329] usb 3-1.3: USB disconnect, address 6
    [37681.720326] usb 3-1.4: USB disconnect, address 7
    [37681.875555] usb 3-1: new full speed USB device using uhci_hcd and address 8
    [37682.044444] usb 3-1: configuration #1 chosen from 1 choice
    [37682.047403] hub 3-1:1.0: USB hub found
    [37682.049363] hub 3-1:1.0: 4 ports detected
    [37682.371776] usb 3-1.1: new low speed USB device using uhci_hcd and address 9
    [37682.508656] usb 3-1.1: configuration #1 chosen from 1 choice
    [37682.511687] input: Wacom Graphire3 6x8 as /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1.1/3-1.1:1.0/input/input10
    [37682.759115] usb 3-1.3: new low speed USB device using uhci_hcd and address 10
    [37682.902996] usb 3-1.3: configuration #1 chosen from 1 choice
    [37682.920106] input: Microsoft Comfort Curve Keyboard 2000 as /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1.3/3-1.3:1.0/input/input11
    [37682.957903] input,hidraw2: USB HID v1.11 Keyboard [Microsoft Comfort Curve Keyboard 2000] on usb-0000:00:1d.2-1.3
    [37682.977914] input: Microsoft Comfort Curve Keyboard 2000 as /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1.3/3-1.3:1.1/input/input12
    [37683.033615] input,hidraw3: USB HID v1.11 Device [Microsoft Comfort Curve Keyboard 2000] on usb-0000:00:1d.2-1.3
    [37683.238299] usb 3-1.4: new low speed USB device using uhci_hcd and address 11
    [37683.377195] usb 3-1.4: configuration #1 chosen from 1 choice
    [37683.398232] input: Kensington      Kensington Expert Mouse as /devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1.4/3-1.4:1.0/input/input13
    [37683.436882] input,hidraw4: USB HID v1.10 Mouse [Kensington      Kensington Expert Mouse] on usb-0000:00:1d.2-1.4

    I’m running out of ideas…

  • Dell GX270 Auto-On Power Setting

    I bought an off-lease Dell Optiplex GX270 from Dell Financial Services (via the highly useful techbargains.com) to update my mother’s PC.

    For the last month I’ve been twiddling it every now & again in preparation for my next visit, plus just letting it run to get some power-on hours under my supervision. You’ll find some of the info on that process earlier in the PC Tweakage category.

    So it’s been booting up automagically at 6:15 am every morning, which is easier for Mom, but every now & again it wakes up dead. This is why I’m doing a month or two of burn-in here!

    The diagnostic LEDs (the ABCD lights on the back panel) are GYGG, which isn’t listed in their hard-to-find LED reference[Update: maybe now at Optiplex Diagnostic Indicators]

    Dell Optiplex GX270 Auto-On Boot Failure LEDs
    Dell Optiplex GX270 Auto-On Boot Failure LEDs

    I did the usual diagnostic stuff. All the Dell diagnostic tests work fine, replugging the memory doesn’t help, and so forth & so on. Running many passes of memtest86+ (from the invaluable System Rescue CD) shows no problems at all.

    Called up 800-891-8595, the DFS warranty service number (which is different from the usual Dell route), told my story, and got a call back (!) from the tech. I related the situation, mentioned that I’d set it for auto-on, and he said “Oh, they never got that BIOS code working, it’s never been released, and I’m surprised it works at all.”

    Riiiight

    This is a biz machine, the sort acquired in semitrailer loads by big companies with actual IT departments, the ones that automagically wake up their flock of machines for overnight updates. Maybe they trigger auto-on through the LAN port (that’s another BIOS option) these days, but the BIOS wake-up alarm clock function has been available in pretty nearly every Dell I’ve ever owned… and works fine.

    This is not rocket science.

    Indeed, if anyone’s ever had the slightest problem with Dell’s auto-on, Google shows no sign of it. There’s nothing on the normally loquacious Dell forums. Nay, verily, the GX270 manual itself touts the “advanced feature” of having it turn on at a preset time and day.

    Anyhow, he says the LED code shows the problem has something to do with the memory or video chip not starting up in time. That information is in his “internal” debugging info, which is not available to mere customers. He’s unwilling to swap memory (I tried another stick to no avail), let alone the system board.

    Conclusion: his assignment is to make me Go Away without spending any money on warranty repairs.

    Seeing as how the GX270 was a whopping 100 bucks delivered, I can sympathize with his marching orders, even if I disagree with their outcome.

    So maybe Mom’s going to have to get used to turning the box on in the morning; it seems to work perfectly that way. A straightforward crontab entry turns it off in the evening… at least that part still works.

    I’ve bought other off-lease & Dell Outlet boxes; they’ve worked fine. This one is a bit more battered than usual, but it’s otherwise in fine shape. It’s even been re-capped; the larger electrolytic caps aren’t the dreaded Nichicon popcorn caps.

    Update: It seems to be booting OK with this burn-in regimen.