This is the third post along my journey to creating a biometric password manager. For an overview of the project, read this post.

Questionable findings

Finding the actual fingerprint reader for the job was not easy. Which is crazy considering how popular small fingerprint readers are - chances are, you have one in your pocket right now. The problem is that those parts are made specifically for mobile phone manufacturers, and don't typically trickle down to the average maker. I think at the very beginning of this project, before I even decided to do it, I spent about a day's worth of mashing different keywords together and browsing through parts. Some "highlights":

1. DigiKey, Mouser, Farnell - the usual suspects - didn't have any modules small enough for my application. Even LCSC, which specialises in Asian brands, doesn't have anything (useful) in stock.
2. You can find quite a lot of materials about a particular Adafruit part, which unfortunately is flipping huge - the intended use is in fingerprint-enabled safes or locks.
3. There's quite a lot on Aliexpress and Alibaba, but finding what I want in this particular haystack is never easy, especially with people putting up a clone of a clone, or reselling somebody else's part with $1 markup.
4. You'll also find tiny little USB dongles that integrate the exact sort of fingerprint reader you might want, as if to taunt you - "you want that sensor, don't you? too bad, you can't have it"
5. Alibaba is slightly more forthcoming but only if you tweak your keywords just right. fingerprint reader seems to be more suitable for complete devices, fingerprint sensor or module would usually throw up more parts.

For now I settled on a module made by a company called Grow (or Hangzhou Grow), where you can buy the sensors direct on Alibaba. I will probably revisit my part selection before any serious production. However, I now have something semi-reasonable to start prototyping with: the Grow R502 (not an affiliate link). That part itself appears to be a clone of this Miaxis part - however that module is not readily available.

For a more detailed - and by that I mean longer and less coherent - version of this sort of process, I recommend that one EEVBlog video, which is just half an hour of Dave browsing through similarly decreasing in reputation corners of the internet, looking for a perfect display for his project.

"Data" sheets

To get the full datasheet or manual for the sensor, or the example code, SDKs, and other essential equipment, you have to go to the manufacturer's website... and they're not there, because you need to contact them. I think this might be because of some copy protection tactics they're trying to do? In any case, what they will send you eventually is a pair of Dropbox links, one for the manuals for all their products, and one for the code examples and test software.

The datasheet/manual is in delightful Chinglish that you typically only find on cheap tat that Big Clive tears down on YouTube for our collective amusement. You really have to work hard to figure out what they mean. And sometimes they'll have downright incorrect information. For instance, the datasheet would say that the connector on the back of the device is a "MX1.0-6P", presumably meaning Molex. However it's not Molex, but rather a 1mm pitch micro JST type connector. Did I mention the cables are really hard to find? Yes, you could probably make your own, but really, would you like to spend an afternoon crimping wires for a 1 millimetre pitch connectors? Nah.

I would really love it if the manufacturer offered an option of a flat flex cable. That would make integrating this module in a small, USB dongle sized enclosure much easier. Perhaps that's what I'll look for when I revisit my part selections.

Iron work

Because of the small pitch of the original connector, I decided to make a breakout board from some perfboard. It's just connecting some 2.54mm (0.1") headers to the loose ends of the wires coming out of the cable supplied with the sensor. You can see a video of how I did it below:

Next, I just had to hook it up to a serial to USB converter that could also supply 3.3V power to the module. From there, I should be able to run the quasi-supplied software and get the module up and running. I chose to use the ESP-Prog. Normally this device is used to program the ESP8266 and ESP32 microcontrollers, however it can also function as a general purpose USB to serial converter with 3.3V supply and logic. Of the 6 pins on the R502 you only need to connect 4 in order to test the sensor - RXD, TXD, VCC, and GND. The next thing is to run the software.

Software gore

Once I connected everything together, I double checked which serial port I would be using and opened the TestDemo app you get by emailing the company. It lets you interface with the sensor, enrol fingerprints, query them, and notionally also view the image captured by the sensor, but...

This glitch art is lovely, isn't it? It also kinda looks like some fake unicode escaped that one twitter account. Still, the core function of the sensor did work - I was able to enrol a finger, match it again, and have it not find a match if a different finger is used. The Grow rep tells me this sort of image is normal, though, so maybe it's not meant to be like a photograph but some sort of internal representation used by the R502.

Road rage

So now the "only" thing left to do is write some software for the F446RE board that works with this sensor.

For which there are no Rust drivers.

low voice we're gonna have to write a driver aren't we

What is there are some Arduino examples and a library which we can shamelessly pilfer from. It's okay because they were clearly shamelessly pilfered from Adafruit. No, really. As well as source code for what might be the TestDemo application. That folder they send you is really full of stuff - there's apparently a .NET SDK, something for Android, two demo apps, and a copy of the aforementioned Adafruit fingerprint library, no doubt with some customisations of dubious quality.

For a first stab at the driver, I want a really simple API. The fingerprint sensor itself is largely a request-response device, with a separate GPIO line for generating an interrupt when a finger is placed on the reader so it can also act as a button. Something like this would be neat:

let (tx, rx) = serial1.split();
let r502 = R502::new(tx, rx);
let response = r502.send_command(Command::ReadSysPara { address: 0xFFFFFFFF })
                   .unwrap();

The design goal here is to make the driver be consistent with the datasheet, such as it is, which means using the same command and field names, unless they're absolutely ridiculous. I also want to use the embedded-hal crate so that the whole thing can be used on any microcontroller that has Rust support when I'm done with it, and then it can be pilfered back by the manufacturer and stuck in another randomly named RAR file inside that Dropbox link. Your (sic) welcome, HZ Grow!

Up next

Writing drivers is of course going to take a while with the sort of hectic schedule I seem to have found myself in the middle of right now, so I will write another post when I make the first release. Stay tuned for that! And for now - did you ever find yourself having to write drivers for a poorly documented part? Or designed an embedded driver API? I'd like to hear from you in the comments!