XiCam Tech Issues

I decided to give up on my so called "XiCam" project.  The end goal was to control a digital camera via USB from a laptop or Android tablet.  When I first attached my camera to my notebook, it appeared that the drivers would only treat the camera as a mass-storage device.  When attached to a Windows computer, however, a window pops up asking for permission to install Samsung's Intelli-Studio program, which apparently includes the capability to update new firmware to the attached camera.  This told me two things: 1) There is more information which can be received from the camera than appears from Linux systems and 2) the capability exists to update firmware from a host PC.

However, even if I managed to get the firmware from the camera, there is still no guarantee that I'll be able to understand it once I've disassembled the code.  And even after spending the effort in figuring it out, then I may still not be able to hack it to control exposure time or trigger the camera via USB.  I decided I was better off, for my own sanity, to just buy a different camera when I'm ready to take pictures at that level.

It turns out, without any special settings or using my home made mounting bracket, I can still get decent pictures.  Here's a picture I took of Jupiter this morning:

USB Protocol

When you plug a USB device into a port on your computer (aka the "host"), the hardware signals the USB host controller that a new device has been attached.  The host controller then sends a command to the newly attached device via the default endpoint in an attempt to find out what the device is (vendor ID, product ID, product type, etc.).  Then it decides what drivers need to be used to work with that device.

I had originally thought, based on the simple configuration, that the only features available to control via USB was access to the data on the flash drive.  I now believe that this is simply how the driver treats the device.  If I were running Windows, I would be prompted to install the Intelli-Studio software, which is apparently built into the device.  If I ever wanted to update the firmware, I would have to do that through Intelli-Studio.  This means two things.  First, the capability to grab software from the camera exists.  Second, the capability to replace the camera firmware via USB also exists.

Just as before, I monitored the USB debugging data from port 2 by issuing the command:

$ sudo cat /sys/kernel/debug/usb/usbmon/2u > bus2data.txt

in one terminal window and,

$ tail -f bus2data.txt

in another. I plugged the camera into the USB port, but no messages were produced until I actually turned the camera on.

The first group of messages appear to be communication between the host controller and the USB port hub,

ffff880137cc2840 2476103001 S Ci:2:000:0 s 80 06 0100 0000 0040 64 <
ffff880137cc2840 2476103172 C Ci:2:000:0 0 18 = 12010002 00000040 e8040613 00000102 0301

The term "Ci:2:000:0" translates to "Input control packet to USB bus 2, device zero, endpoint zero". Eventually I start getting USB events like this,

ffff880137cc2840 2476234892 S Ci:2:007:0 s 80 06 0100 0000 0012 18 <
ffff880137cc2840 2476235047 C Ci:2:007:0 0 18 = 12010002 00000040 e8040613 00000102 0301

This submission/callback pair is the device telling the host controller what it is. The first byte is length (0x12=18 bytes), the next is bDescriptorType (0x01=1), USB minor and major version (0x00, 0x02 or "2.0"), The next word contains the device class (0x00), subclass (0x00), protocol (0x00) and maxPacketSize (0x40=64 bytes). The next word contains the vendor and product ID numbers (0x04e8 = Samsung, 0x1306 = ST100 digital camera). Then comes device version (minor, major, in this case 0.0), manufacturer (the '1' here means SAMSUNG, though I'm not sure yet how the USB host controller knows this) and the '2' designates that it is a digital camera. The 3 indicates the serial number. These must be pointers to information strings or something like that. Finally, the '0x01" at the end tells the number of device configurations that are available.

The next submission/callback pair describes the first (and only) configuration.

ffff880137cc2840 2476235204 S Ci:2:007:0 s 80 06 0200 0000 0009 9 <
ffff880137cc2840 2476235293 C Ci:2:007:0 0 9 = 09022000 010100c0 00

which corresponds to this:

 Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA

The next pair is the first (and only) interface,

ffff880137cc2840 2476235412 S Ci:2:007:0 s 80 06 0200 0000 0020 32 <
ffff880137cc2840 2476235547 C Ci:2:007:0 0 32 = 09022000 010100c0 00090400 00020805 50000705 02020002 00070582 02000200

which corresponds to this:

  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      5 SFF-8070i
      bInterfaceProtocol     80 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0

So what happened to endpoint one? And what does this mean?

ffff880137cc2840 2476235709 S Ci:2:007:0 s 80 06 0300 0000 00ff 255 <
ffff880137cc2840 2476235792 C Ci:2:007:0 0 4 = 04030904
ffff880137cc2840 2476235826 S Ci:2:007:0 s 80 06 0302 0409 00ff 255 <
ffff880137cc2840 2476235917 C Ci:2:007:0 0 48 = 30035300 61006d00 73007500 6e006700 20004400 69006700 69007400 61006c00
ffff880137cc2840 2476235936 S Ci:2:007:0 s 80 06 0301 0409 00ff 255 <
ffff880137cc2840 2476236042 C Ci:2:007:0 0 20 = 14035300 41004d00 53005500 4e004700 20002000
ffff880137cc2840 2476236055 S Ci:2:007:0 s 80 06 0303 0409 00ff 255 <
ffff880137cc2840 2476236167 C Ci:2:007:0 0 28 = 1c034500 30003000 30003000 30003000 30003000 30003000 32002000
ffff880137cc2a80 2476236645 S Co:2:007:0 s 00 09 0001 0000 0000 0
ffff880137cc2a80 2476236792 C Co:2:007:0 0 0
ffff8801122bfc00 2477238949 S Ci:2:007:0 s a1 fe 0000 0000 0001 1 <
ffff8801122bfc00 2477260196 C Ci:2:007:0 0 1 = 01

0x30=decimal 48, 0x03=index 3, 0x53='S', 0x61='a', 0x6d='m', 0x73='s', 0x75='u', 0x6e='n', 0x67='g', 0x20=' ', 0x44='D', 0x69='i', 0x67='g', 0x69='i', 0x74='t', 0x61='a', 0x6c='l'
0x14=decimal 20, 0x03=index 3, 0x53='S', 0x41='A', 0x4d='M', 0x53='S', 0x55='U', 0x4e='N', 0x47='G', 0x20=' ', 0x20=' '
0x1c=decimal 28, 0x03=index 3, 0x45='E', 0x30='0', 0x32='2', 0x20=' '
So these must be the info strings, although the string "camera" doesn't show up. The first byte must be the string size in bytes (wide char format), the second byte the number of info strings, in this case '3', then the actual strings ("Samsung Digital", "SAMSUNG ", and "E00000000002 ").

XiCam Assembly

There are two parts to this project. One was developing a device driver to run my digital camera from my tablet. This is likely a fools errand, but you can't succeed unless you try, right? The other, far simpler, part is to build a structure that holds the camera lens fixed against the telescope eyepiece. The assembly in the pictures cost me about $9 from The Home Depot. It consists of a 2"x5" joiner plate (Simpson TP15). It's thin, but fairly rigid. I drilled holes for a 1/4" machine screw (I suppose this is fairly standard for mounting cameras to a tripod) and a 3/8" screw. I held the plate steady by hand, and nearly slit my wrist when the drill passed through and the plate spun loose. So be wise: use a clamp if you try this. I used a 1" long machine screw with nut and locking washer to hold the camera in place. I used a 3" hex bolt with nuts and standard washers (the lock washers tend to tilt the bolt unless you really tighten it). The bolt feeds into a 1" pipe clamp, which happens to fit the eyepiece perfectly. It does not, however, fit around the larger eyepiece, which I think might be more useful due to the wider field of view.

I was tinkering around with the built-in exposure and ISO settings. The ST100 allows up to ST3200 and uses an exposure scale of -2 to 2 (I don't really know what that means. Could it be a multiplier for integration time?). The first picture I took the other night. It was fairly overcast, and we get a lot of light pollution around here. I used exposure setting "zero" (for "auto") and ISO 3200. The second picture is Vega, taken last night using my medieval eyepiece attachment device. The high magnification makes vibrations even more annoying, so I will certainly need to get a larger clamp so I can use the lower magnification, larger FOV eyepiece.

Getting USB Debugging Info from the Linux Command Line.

Not ready to give up on this just yet. Having a closer look at the command line tools that are available.

seans@snowpack:~$ sudo lsusb -v

...

Bus 002 Device 005: ID 04e8:1306 Samsung Electronics Co., Ltd 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x04e8 Samsung Electronics Co., Ltd
  idProduct          0x1306 
  bcdDevice            0.00
  iManufacturer           1 SAMSUNG  
  iProduct                2 Samsung Digital Camera 
  iSerial                 3 E00000000002 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      5 SFF-8070i
      bInterfaceProtocol     80 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

Ubuntu has a USB debugging feature, which on my installation was running automatically. You can monitor the communication on the various USB buses by,

seans@snowpack:~$ sudo cat /sys/kernel/debug/usb/usbmon/2u > bus2data.txt

Here's a sample of the output,

ffff88009bf78240 752186120 S Bo:2:005:2 -115 31 = 55534243 18070000 08000000 80010c4a 01000010 00000008 00000000 000000
ffff88009bf78240 752186154 C Bo:2:005:2 0 31 >
ffff880062803c00 752186180 S Bi:2:005:2 -115 8 <
ffff880062803c00 752186403 C Bi:2:005:2 -32 0
ffff88009bf78240 752186412 S Co:2:005:0 s 02 01 0000 0082 0000 0
ffff88009bf78240 752186527 C Co:2:005:0 0 0
ffff88009bf78240 752186548 S Bi:2:005:2 -115 13 <
ffff88009bf78240 752207425 C Bi:2:005:2 0 13 = 55534253 18070000 08000000 01
ffff88009bf78240 752207452 S Bo:2:005:2 -115 31 = 55534243 19070000 12000000 80010c03 00000012 00000000 00000000 000000
ffff88009bf78240 752207652 C Bo:2:005:2 0 31 >
ffff880062803c00 752207718 S Bi:2:005:2 -115 18 <
ffff880062803c00 752207778 C Bi:2:005:2 0 18 = 70000500 0000000a 00000000 20000000 0000
ffff88009bf78240 752207788 S Bi:2:005:2 -115 13 <
ffff88009bf78240 752207901 C Bi:2:005:2 0 13 = 55534253 19070000 00000000 00
ffff88009bf78240 752698083 S Bo:2:005:2 -115 31 = 55534243 1a070000 00000000 00000c00 00000000 00000000 00000000 000000
ffff88009bf78240 752698157 C Bo:2:005:2 0 31 >
ffff88009bf78240 752698391 S Bi:2:005:2 -115 13 <
ffff88009bf78240 752698527 C Bi:2:005:2 0 13 = 55534253 1a070000 00000000 00
ffff88009bf78240 754234230 S Bo:2:005:2 -115 31 = 55534243 1b070000 08000000 80010c4a 01000010 00000008 00000000 000000
ffff88009bf78240 754234295 C Bo:2:005:2 0 31 >
ffff8801380f9f00 754234315 S Bi:2:005:2 -115 8 <
ffff8801380f9f00 754234415 C Bi:2:005:2 -32 0
ffff88009bf78240 754234438 S Co:2:005:0 s 02 01 0000 0082 0000 0
ffff88009bf78240 754234528 C Co:2:005:0 0 0
ffff88009bf78240 754234540 S Bi:2:005:2 -115 13 <
ffff88009bf78240 754255617 C Bi:2:005:2 0 13 = 55534253 1b070000 08000000 01
ffff88009bf78240 754255664 S Bo:2:005:2 -115 31 = 55534243 1c070000 12000000 80010c03 00000012 00000000 00000000 000000
ffff88009bf78240 754255906 C Bo:2:005:2 0 31 >
ffff880132d0b3c0 754255925 S Bi:2:005:2 -115 18 <
ffff880132d0b3c0 754256032 C Bi:2:005:2 0 18 = 70000500 0000000a 00000000 20000000 0000
ffff88009bf78240 754256047 S Bi:2:005:2 -115 13 <
ffff88009bf78240 754256155 C Bi:2:005:2 0 13 = 55534253 1c070000 00000000 00

I still don't understand some of the intermediate messages, but I found a resource that explains a couple of them. I made this legend from the description on that webpage.

The upshot is that there seems to be a means to send a variety of commands over the same "configuration". However, I haven't been able to find any resource that describes the commands and arguments that would be recognized by the device. I thought about just sending 256 different command signals to see what comes back, but I think I'd risk sending a factory reset signal or something that might render the camera useless. I'd rather have a camera that doesn't do everything I want but works than have no camera at all.

Okay, so maybe I'm a glutton for punishment or just dumb. But I decided I didn't like the Windows installation after all. Mainly because I didn't feel like dealing with the "bonus" software and the friendly reminders to register for software I haven't used in four years. Also, I think trying to run Ubuntu in a VM was a little too much to ask for the HP. Long story short, I reinstalled Ubuntu 12.04 and made a promise to myself that I wouldn't try to install (or uninstall) any packages related to the USB.
Side note: I could have installed an earlier version of Eclipse using apt-get, but I wanted to go with the Kepler edition, so I downloaded the tarball instead. After installing the Android SDK, I was surprised to find that adb wasn't working. I kept getting file not found errors, even though I could clearly see it was there. Problem was I didn't have 32-bit executable support installed yet. Ran apt-get intall ia32-libs, which installed a whole bunch of crap. But this did, in fact, solve the problem.
Back to business. At first glance it doesn't look like I'll be able to control the camera at the level I want, at least from the USB. Here's what I get from the command line:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 090c:137b Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) 
Bus 005 Device 002: ID 046d:c52f Logitech, Inc. Wireless Mouse M305
Bus 002 Device 004: ID 04e8:1306 Samsung Electronics Co., Ltd 
seans@snowpack:~$ sudo cat /sys/kernel/debug/usb/devices

...

T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=04e8 ProdID=1306 Rev= 0.00
S:  Manufacturer=SAMSUNG  
S:  Product=Samsung Digital Camera 
S:  SerialNumber=E00000000002 
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=05 Prot=50 Driver=usb-storage
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

...

(note: I removed all the extra crap related to the host controllers and USB mouse). A more experienced eye might see something else. But what I see is that I'll only be able to access files through USB.  I need to do a little research to see exactly what each term means, but I believe "T" designates a device, either root hub or hardware device, "D" designates the USB version, number of available configurations and a few other things I don't know.  I get the vendor number and product ID, but I don't understand "Rev" (revision?  if so, why zero?).  "S" must designate some generic string descriptor.  I don't believe the serial number that's given there.  "C" seems to designate the start of a specific configuration, not sure what the asterisk is for.  "#Ifs is the number of sub-configurations, in this case there's just the one.  "I" indicates the sub-configuration and "E" are endpoints.  This allows one input (I) and one output (O) bulk endpoint, designed for transferring large amounts of data.  Seems like this device is configured at "full speed" (480 MBps).<p>

 I did some searching on the interwebs and found that, at least for other digital cameras, any "hacking" of the firmware had to be done via memory chip. I can see how this might work for this camera, since it does seem to do some check of the SD chip when turning it on. As of now there's no firmware provided for this particular model, but I'll keep my eyes peeled.

Getting Basic Information from a USB Device

Top-level stuff (no code required)
From command line:

[strattonsr@bishop]$ lsusb

gives manufacturer ID : product ID and one-line description

[strattonsr@bishop]$ cat /sys/kernel/debug/usb/devices

gives more detailed info about device configurations

sample

T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 2
P: Vendor=04e8 ProdID=6860 Rev= 4.00
S: Manufacturer=SAMSUNG
S: Product=SAMSUNG_Android_SCH-I535
S: SerialNumber=d6190436
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 96mA
I:* If#=0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MsPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS=512 Ivl=125us
E: Ad=82(I) Atr=03(Int.) MxPS= 28 Ivl=4ms
C: #Ifs Cfg#= 2 Atr=c0 MxPwr= 96mA
A: FirstIf#= 1 IfCount= 2 Cls=02(comm.) Sub=02 Prot=01
I: If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver=
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
E: Ad=82(I) Atr=03(Int.) MxPS=  28 Ivl=4ms
I: If#= 1 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=
E: Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I: If#= 2 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Setting up Platform for Project XiCam

I suppose the upside to the USB debacle is I now have a clean slate to start working on this project.  This isn't the most ideal starting point, but I now have an HP dv4 Notebook running the factory install of Windows Vista (circa 2008).  It has an Intel Core2 Duo 2.1GHz processor and 4GB RAM which should be good enough for my purposes here.  I have to remember how to get rid of the various annoying registration and update reminders which are all more or less pointless now, but I digress.

First step was install eclipse.  Went with the the standard version of the Kepler release, since I don't expect to do much outside of Java programming.  In fact, it probably would have made more sense to install the Java 7 SDK first, but it doesn't really make a difference.  Both installed and run without any problems.

Next step was to install VirtualBox so I have something to write lower level stuff in C/C++.  I used to use Cygwin, but that comes with some extra complications that I'd rather not deal with.  Running Linux in a VM not only gives you the desktop appearance but also adds a nice layer of protection to help keep you from doing anything really damaging to your computer (like muffing up your USB host controller).  I had intended to install Ubuntu 12.04 64-bit on the guest machine, but apparently 64-bit guests are not supported on this computer (it does, however work on 64-bit Windows 7 on the Intel quad-core I have at work, so I think this may be more an issue with the CPU on the notebook not supporting virtualization rather than an issue with VirtualBox).

Installed Ubuntu 10.04 for x86 architecture on the guest machine.  I may have to deal with the 800x600 screen, which actually isn't so terrible.  At least the USB 2.0 passthrough apparently works!

Ubuntu 10.04 running in VirtualBox with the mouse and camera showing up in lsusb.

Last, I installed the Android SDK plugin for Eclipse.  Release 19 (Kit Kat) is fairly recent and today is the first day I've noticed it in the SDK manager.  I would normally have installed the SDK for the last five or six releases so that I could check back-compatibility, but I just included this latest release for now.  I build a virtual device with the general specs of the ASUS tablet.  It runs pretty slow and takes several minutes to boot, so it may need some tweaking.

Tablet emulated using the Android SDK plugin in Eclipse.

XiCam Project on Hold until USB Issue is Solved

USB host controller on the HP appears to be broken.  From what I'm reading, the driver is owned by Microsoft, and resides on the chipset, which partially explains why reinstalling Ubuntu didn't solve the problem.  I have the recovery disks, so I'm going to try to do the recovery tonight.  If that works, then I'll install Ubuntu on a VM instead of having that as the main OS.  This might cause some difficulty passing USB connections through, but I'd rather deal with that than breaking the driver again, then having to go through this mess all over again.  Here's the details of what I've done so far:

• SD card reader still worked, so I used the 8GB micro SD I found for the camera to save my latest work.
• Did fresh install of Ubuntu.  This solved the infinite login loop problem, but not the USB issue.
• Tried following the advice here (link), but that didn't work.  I did, however, notice that the system recognized a device was there, it just wasn't responsive.
• I wanted to keep the 8GB card in the camera, so I used the card reader to move the saved data to the 32GB card in my phone and wiped the data from the 8GB card.

I did a full factory restore on the HP, but that still didn't fix the USB issue.  Plugged in the mouse and Windows said the device wasn't recognized.  Opened up the device manager and uninstalled all of the USB device drivers.  After hitting check for new devices, they all came back and no errors came up, but USB ports still didn't work.  The next step is to do a BIOS update.  After that, I'm not sure what else to do.

Project XiCam Back on Track

Well, it was quite a debacle, but I finally have the HP back in working condition.  The USB issue turned out to be a hardware-level problem and required a full BIOS update to fix.  Here's a summary of the problem I encountered and what it took to fix it:

• Plugged my phone into one of the USB ports at which point the computer stopped responding to the mouse.  I thought the error might have come from a conflict after installing libusb-1.0-0 with its corresponding dev package.
• Ran apt-get remove the packages I had just installed and it removed a whole bunch of critical packages that were reassigned as dependencies.  After install, it realized it needed to re-update them all so the whole thing was a mess.
• Rebooted computer and found the OS in an infinite loop on the logon screen.  When I deliberately put in a wrong password, it indicated the bad password with a red "invalid password" message.  When I entered the correct one, the screen would flash an error for 1/2-second an return to the logon screen.  I tried to find a solution on-line.  The most common cause of the problem was an .Xauthority file getting set to the wrong permissions.  This was not the problem, though.
• Found an old Ubuntu install disk and started the computer in live mode.  I had access to all the old directories and tried fixing the problem from there without any luck.  Eventually I resigned myself to reinstalling the OS so I backed everything up on a SD card (the USB ports were still not responding, which I think should have been a hint that an OS reinstall wouldn't help).
• Reinstalled Ubuntu 12.04 but USB ports still didn't work.  Checked /var/log/syslog and there were repeated error messages.  The messages would change when I connected the mouse, but the system never responded to the mouse.  Did some more checking of the interwebs but none of the fixes I found worked in my case.  Checked HP support site and started researching USB host drivers, which apparently, for my computer, are owned by Microsoft, so I decided to restore the HP to factory default.
• Reinstalled Windows Vista from the recovery disks.  This still didn't solve the problem.
• As a last resort, I downloaded the BIOS update.  This required Windows to run the installer.  This finally worked!

Lessons learned:

• Take extra care installing USB packages in Ubuntu.  If there's a conflict, you won't be able to remove them without affecting a lot of other critical software.
• The USB drivers on HP notebooks are integrated as part of the motherboard chipset.  If something goes wrong with it, then you need to flash the BIOS.  In the case of this computer, this requires running from Windows (I've heard many complaints about Vista, but to be honest it's always worked well for me; I'm also a fan of Windows 7).

Project XiCam -- Part 1

Calling this project XiCam for lack of a better idea.  The concept is this:  Hack one of our old digital cameras so that I can control it from my Android tablet.  Why do this?  I'll let you know when I figure that out for myself.  My goal is to create some attachment mechanism so I can position the camera lens to the eyepiece of my telescope.  I'd like to see what options I can control over the USB port.  If I'm lucky, I might be able to manipulate settings beyond the controls provided by the on-board UI.

Samsung ST100 digital camera.

Here's what I'm working with:

•  Samsung ST100 14.2 Mpx digital camera
• 5x optical zoom
• 8GB micro SD
• ASUS TF201 Transformer prime
• NVIDIA Tegra 3 quad-core CPU
• 10.1" screen
• Android Ice Cream Sandwich OS



ASUS  Tablet with keyboard dock.



HP Pavilion dv4 notebook

• 32GB micro SD
• HP Pavilion dv4
• Intel core 2 duo CPU
• Ubuntu 12.04 LTS OS
• Eclipse Juno IDE + Android SDK + ADK

Android has some good functionality for USB communication, unfortunately there's no good way to develop software on the tablet itself (I installed one of the free IDE's, which appeared to be inspired by eclipse, but there were limitations due to screen size, responsivity of keyboard, and other reasons which made that option impractical).  My general approach will be to develop some basic USB communication software on the notebook, using an emulated tablet as the target.  Once that's working, install it on the ASUS  and make sure the USB interface actually works.  Next, further develop the software to perform some basic control operations on the camera.  Then finish by adding some pretty GUI controls to control exposure and read image data into the tablet and present it on the screen.

Before I can do any of these things, I need to develop an understanding of USB protocol.  I spent the last couple of days researching this and the communication format doesn't seem terribly complicated.  However, many USB products, especially digital cameras, use proprietary formats which require their own drivers.

I ran into a big problem, likely due to installing libusb on the HP.  Mouse suddenly stopped working.  Thought it was the battery but it worked on another computer.  When I checked /var/log/syslog, it was getting overloaded with messages about not being able to enumerate the USB devices.  I tried removing libusb-1.0-0 and libusb-1.0-0-dev (the exact packages I installed), then the whole thing went to pot.  When the system rebooted after removing and updating the packages, it got stuck in some weird loop where the login screen would come up, I'd enter my password (I had setup the OS to not go to a login screen, so even that was weird), another screen would come up with error messages, but it only stayed for about 1/2 second, so I couldn't tell what the errors were, then went back to the login screen.

I couldn't find the install disk to run the live version and potentially fix the problem, but that was lost.  I found the ISO for 10.04 on an external drive, so I burned a new copy and am running that right now.  Even in "live" mode, the USB ports aren't working, so even though I can view my directories, I can't save the files to it.  Instead, I took the SD card from the camera and am tarballing the essential stuff and saving it to that.  Thankfully that works.

Eventually, I plan on doing this kind of work in a virtual machine running on Windows.  This way when I encounter big problems with the OS, I don't wind up losing everything.  Unfortunately, can't do that until I get a new computer.