#elphel

I've undertaken a digitization project that involves scanning several large binders.  Each binder holds a series of plastic sheet protectors and each sheet protector contains mixed media (newspaper clippings, correspondence, booklets, etc.) that have been logically grouped together; the series progresses in a chronological storyline format.

Book scanners, such as the Internet Archive's Scribe, are not particularly well-suited for this task.  But a traditional flatbed scanner is, and a large–format one at that.  The highest–resolution A3-size scanner available is the Mustek A3 2400S (pictured middle–right).  At $270 USD it's also one of the most affordable—and, likely—appealing options for budget–minded archivists and graphic artists.

As a new-on-market scanner SANE support is currently non-implemented. From 2000–'07 Mustek maintained a substantial level of GNU/Linux support for their scanners by publishing a GPL'd SANE backend.  (Although GNU/Linux support appears to have become abandoned for reasons unknown since then I'm holding hope that Mustek will re-introduce this level of support for their products.)  Today the the free software community is left to reverse–engineer scanner support from scratch, a non-trivial process even by coding standards.

Unlike remote development on, say, a new chipset or codebase, writing a new SANE backend requires very real–world access: developers must be able to see, hear, and physically power–cycle scanners on an as-needed basis. Without these abilities a "mis-behaving" scanner may become physically damaged as the (delicate) positioning motor tries to continuously force the scan-bar past the maximum range.  Thus real-world access itself becomes an impediment to developing support for these type of devices in a timely fashion.

Introducing DANE: Developer Access Now Easy

(It's OK to chuckle, it's a funny name.)

In lieu of sending the scanner off to a developer I decided the next–best course of action would be finding a means of addressing, monitoring, and power-cycling the scanner remotely.  Correspondingly the above photos are of a Mustek A3 scanner and room lamp connected via the green power strip to a USB Net Power 8800 relay switch.  The overhead Elphel 353L camera and server (the cube-shaped black box, a Shuttle SG31G2 V2) are attached to an always–on power strip.  The relay switch control cable, scanner, and ThinkPenguin TPE-N150USB WiFi adapter are connected to a Koutech IO-PU520 5-port USB 2.0 PCI expansion card.  The USB expansion card provides a robust USB interface and makes the system reboot-safe; the Shuttle box always supplies power to all motherboard USB ports.

For monitoring the Elphel camera is set to transmit 'Full HD' Motion JPEG at 18 FPS to a GStreamer pipeline running on the Shuttle.  The pipeline in turn converts the video stream to Ogg Theora then bounces the encoded stream off of a localhost Iccast server with an end–to–end latency of about six seconds. The livestream is currently up and running.  offline for camera maintenance.

In the process I came to the realization that remote development access for such devices is, 1) really important, and 2) almost non-existent within the free software community.  There are a several cases where novel development approaches would really help:

—When gifting or shipping devices to developers is either impractical (e.g., expensive or bulky items) or precarious (e.g., customs delays, loss)

—Increasing developer multitasking efficiency (e.g., 'hacking' remote devices while waiting on a flight delay)

—Team–based remote development, side–stepping the need to purchase multiple devices for multiple developers

Encouragingly, Elphel adopted this approach with the (currently–offline) Elphel Camera Sandbox.  I'm at a loss to think of other examples.