|The digitalPersona Fingerprint Scanner|
U.are.U: A Biometric Device
The hardware is a little 1.5 inch square plastic box with an oval glass window in the top. This is the fingerprint scanner. It is sold by a company called digitalPersona under the product name U.are.U 2000. It is a USB device, at least it plugs into the USB port. It is fast and seems to do the trick.
Our application needed a fingerprint scanner (the aforementioned Biometric Device) and the digitalPersona product was selected because the company sells an SDK that supports Visual Basic. The developer gets an SDK CD in addition to the standard product CD and the device. Support also comes in the form of telephone and email help, though we only tried the email.
The SDK is a little short on detail. The example code is pretty much comment free country (a comment desert as I like to call it: free of green), which I find a little hard to understand. There is a manual containing the API calls, but no guide to their use. In general the SDK is hard work.
Fortunately the software itself, the DLL's and the typelibs, seem to function well in getting you going. The only thing we eventually did was to supplement the code in the fingerprint registration examples with some database save functionality, and in the fingerprint identify routines with the necessary database reads. We also added a new event, used to signal to a parent that some match had been achieved. This was all fairly simple stuff.
We got into trouble handling blobs, and I would recommend that anyone using this stuff, not use blobs, particularly on Oracle. The fingerprint registrations tend to come in at about 512 bytes, so there are several database field types that could be used before resorting to BLOB's.
The performance of the Fingerprint identification routine was pretty good. It was able to scan through our database (admittedly quite small) in a very short period of time.
In general, the software worked well to build the application. However, it was not so nice in regards to operating the application. We found a number of issues that a developer is going to have to consider that should be placing a lot pressure on digitalPersona's shoulders, but didn't seem to illicit much comment from them.
We ran into problems with the product in a number of areas:
Unreliable software operation
We noticed on many occasions that the scanner would fail to get a fingerprint. Once it failed, there was no easy way of getting the scanner to function again. In fact the DLL's would conspire to hose the computer if you called for the scanner to do something in this condition. I was never able to solidly identify what was going on, but suspect that there might be a threading/re-entrancy issue somewhere in the DLL's. One thing we asked digitalPersona for was any documentation on a call to reset or re-initialize the scanner or its software, but nothing was ever forthcoming. What we would see would be that there would be a time lag between the scanner functioning and response coming back to the VB interface, however, if the user then clicked somewhere on the VB interface there would be no error but the scanning software would cease to function. The next call to one of the scanner DLL's would cause the program to go into an infinite loop somewhere (according to Win2K's task manager the application was still responding).
USB support extremely suspect
Initially you could be convinced this device was a USB device, it has a USB connector, it plugs into the USB port, and during the software install you get a "USB device found" dialog. However, that seems the extent of the USB support. It registers in a Biometric folder in the Device Manager. It does not seem to have an eject capability, an if taken out does not cause re-registering as a USB device. Woe betide anyone that unplugs, or plugs in, the scanner while the machine is running! Such activity invites a reboot.
Install with a custom application is complex
We found that we could not create a standard install with VB 6 (and it work). We had various registration errors during the install. We then moved over to the Wise Installer and made an MSI install package. This too was initially afflicted by the same dll registration errors as the VB install. By removing all the digitalPersona DLL's we were able to get the install to work without errors, but the application failed saying there was no device. Even when we made sure the scanner was installed, the install of our application failed to make the registry linkage between the dll's we needed and those that were present. In the end I meat balled the whole thing. I put all the digitalPersona software (as much as I could find) in our install, added in the registry entries, too. Then after we installed this ball of fur on the target we re-installed the scanner software. This gave us a fully working system. But the pain!
Far be it from me to suggest that after an uninstall your machine should be back to what it was prior to the install, we all know various files change or are added so directories are frequently left around, but this install/uninstall is a doozy. Not only were the system dll's left in place, but the registry entries were also still present, hence the scanner authentication was never disabled. This meant that the Win2K system authentication engine was quite severely compromised. About 30 minutes of registry editing, reboots, file deletions and general hair loss were required to return normality to my little world.
I think it fair to say that this product needs a lot more work, however it's a nice piece of gear, and with some updates to the reliability of the DLL's and clarification of how installs should be done, this would be a killer product. So, if you are in the market for a biometric device and need it to go in a VB application this is not a bad choice, just be aware you will have issues.
Update: July 2002
Well, as with all things software, humans frequently cause the problems. We discussed some of the reliability issues we were having with DigitalPersonna and they asked to see the software. A version of our application was built that replicated the problems, and was consistent in failing. The D.P. people soon came back and informed us that we had built in some of the problems ourselves. It seems that we had mixed code from several samples to achieve what we wanted, but that the resulting code had used features of more than one of the COM components. The components seemingly are not friendly toward each other, or the calls we were making were inconsistent with the state machines in the components, and so we were getting our problems. The software was amended and the system has been quite reliable since.
|© Copyright A. Maclean 2002 -|