It has often been lamented at various library technology conferences (and beyond, of course) that we collectively do a very poor job of documenting our failures. I prefer not to use the failure label, but rather refer to such things, more accurately, as unsuccessful experiments or simply the outcome of a normal research and development process. At any rate, I’m making a small contribution here toward improving this state of affairs by telling the tale of how a group of us were defeated by an HP scanner.
Here in the Sherman Centre, we have a fair bit of technology at our disposal. One piece is this fancy networked HP N6350 scanner. It has great scan quality, a document feeder, and does in fact connect to the network. Downsides include having a Windows-only driver, which is pretty fatal in an office that abounds with Mac and Linux devices. It’s a bad driver to boot, being wheezy and cranky as with so many device drivers these days. Across the room from this scanner, we have a makerspace chock full of Arduinos and Raspberry Pi boards, and myriad modules and extensions for both. It seemed like a good idea to give up trying to convince the graduate students and researchers who work here to run Windows in Parallels on their Macs or, even more futile, getting the driver to run in Wine on Linux boxes (which could be filed, even without trying it out, under Ideas Doomed to Fail Gloriously, or perhaps Succeeds Just Enough to Delude You Into Thinking it Works Before Sapping Your Will to Live), and just build a scan head for the thing using its USB port and a Raspberry Pi. We’d hack together a Pi board, a monitor, some cool-looking yet functional push buttons, and voilà, one could scan documents to a USB stick and get back to business.
Thankfully we didn’t spend much time on this idea before John deflated our collective balloon by declaring it utterly pointless. In a nutshell, the SANE api doesn’t work with the HP N6350 (only the 6350C, arrgh). Certain newish HP scanners don’t use HP’s older Scanner Control Language, but some other technology for device communication.
What did we learn from this experience? For my part, I learned not to assume that a scanner manufacturer will publish a decent driver for multiple platforms (well, I already knew that and just had it reinforced), and also to consider the compatibility of the scanner with other software solutions (such as SANE) when making purchase decisions. Collectively we learned, again, that there is often a gap between open technologies such as the Pi and legacy technologies such as HP scanners, and that unless one wants to decode how HP drives their scanners and build the bridge one stone at a time, it’s better just to give up and use, while gritting one’s teeth, a Windows box to drive a scanner. We ran into similar complications recently with some Toshiba netbooks while installing Ubuntu.
These experiences take some of the lustre off of our recent hardware purchases and make me wonder if one isn’t wiser to hang on to some of the older stuff just a bit longer, or to buy older hardware for which Linux drivers exist. Perhaps the most important lesson learned is that if you write this stuff down, no matter how inane or trivial it seems, you are putting wisdom out on the Web that might help some other poor soul avoid this beast of a driver. Serious product reviews or real-world experiences with relatively uncommon devices such as scanners are few and far between on the Web. Mostly it’s just product spec sheets and vendor boilerplate. So, if nothing else, publishing this tale means that the next person who googles for info on the HP N6350 scanner just might run across our experience and glean a few key bits of information before shelling out the cash.