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:
Encouragingly, Elphel adopted this approach with the (currently–offline) Elphel Camera Sandbox. I’m at a loss to think of other examples.
We need a name to call this, or at least an adopting project, and a collection of guidelines and reference implementations across a broader range of devices. Thoughts?