16 Apr kittE (Raspberry Pi/Touchscreen/Fingerprint Scanner Project) part 3
Research (or mucking about with stuff)
The first job was to buy a Pi screen and fingerprint scanner. I already had a Pi kicking around looking bored. A quick session on the interweb saw me securing a screen from Pimoroni and GT-511C3 finger print scanner from Proto-Pic.
The Finger Print Scanner is ideal. It is a self-contained unit that stores the fingerprint templates locally, all you need to do is ask it for the unique ID of the finger print on the scanner. This can then be cross referenced to a person. It connects via a serial connection (0-3.3V rather than 0-12V of standard RS-232) which is ideal for connecting to a Pi or Arduino UART. There was a cheaper version but that could only store 20 fingerprints, this model can store 200, which is more than we should ever need. The only problem was there were none in stock, but that was OK because Proto-Pic said they could get more stock within a week.
Therefore first to arrive was the touchscreen, which I bought with a stand. I screwed this together, bolted in the Pi, connected the flexi and the GPIO pins, plugged it in and was up and running in under 10 minutes. A quick search later I’d found out how to rotate the screen 180 degrees in the Raspbian config. Nice. The touchscreen was ideal for the app, so I was happy with that. No sign of the finger print scanner though.
Next step was to determine a programming tool chain, database package and GUI environment. After some online research I decided to work in C (Python seemed to be a better option as it offered more options on the Pi, but I only have a passing knowledge of it, whereas I’ve being using C on and off for 20 years), SQLite3 for the database and the GTK library for the user interface. I wrote some test code using SQLite, designed the database, implemented it and was able to add to and query the database. Good start.
Next I installed GTK, however my code failed to compile. It seems the GTK library couldn’t be found. I did all the obvious things (check user permissions, check I’d installed the Dev library, check the location in the OS, post on HackOldham discourse) and everything seemed fine.
It was as if the compiler couldn’t find the library. So I double checked my Make file against the documentation, which used the apt-package switch, and this was correct. On the off-chance I tried moving the GTK library to the C file directory – it compiled, or at least failed at a point further into the GTK stack. Oh dear, that’s not a good sign. I could have used it but any package updates would fail to fix problems and I would need to modify the headers within the package itself to reference the correct modified locations. Alternatively I could have included the entire GTK library in my solution, but then it would not receive any updates in the future. Either option is bad practice and even though this was a personal project, as opposed to professional, I really didn’t want to do it.
After some more digging it turned out I wasn’t alone. GTK on Raspbian Wheezy simply doesn’t work unless you include it within an application and/or modify it in a suitable way. So plan A was a failure. On to plan B. Still no sign of that finger print scanner btw.
Plan B involved using Python. Well, if you are going to embrace something like a Pi you might as well do it properly. I gave GTK a bash, although logically knew it wouldn’t work. It didn’t. TKinter seemed to work straight out of the box with Python, so even though it isn’t the nicest or most flexible user interface I decided to use it at least until I was more confident with Python. And SQLite worked fine too so at least I was able to reuse the queries and commands I’d already defined. Still no finger print scanner though.
After a few nights coding/googling (mainly the later) I’d managed to build an application with a navigable interface. I could create users (minus their finger prints), add products to the database and make and commit purchases. The interface looked OK too (images are our friend).
And finally, after nearly a month, the finger print scanner arrived. Happy days! There was a problem though – the finger print scanner uses a tiny JST 4 pin connector. I’d ordered the finger print scanner cable with the scanner. There were two in the related items bit on the scanners page, one was in stock, the other wasn’t. I went with the one in stock. It was for a 6 pin connection. A quick double check on the website confirmed it was my mistake, I’d ordered the wrong part. True the “related items” link was a bit misleading but I should know better than to not bother checking obvious things like number of pins!
I ordered some JST housings (working in the industry has its advantages at times like these) and once they had arrived I dismantled my wrong cable, and plugged the individual wires into the correct housing. They didn’t fit. Well, they didn’t fit very well. A little manipulation later and they were locked in to the header in the correct positions. I wired the finger print scanner up to the GPIO pins on the Pi and …. Nothing. Nothing happened. After a bit of digging I disabled the Boot terminal (which outputs on the UART I was using for the scanner) and getty (ditto) but still nothing. Using Minicom and a loop back connector I could see the port was working, but once I’d connected the scanner nothing happened. There was no magic smoke (a good thing) but no comms to the device (a bad thing). Bugger.
By now I’d also got something else to play with. A Raspberry Pi 3. When I was setting this up I noticed that Raspbian Jessie had been released – perhaps this corrected the GTK problem on Raspbian Wheezy? So because I’m a glutton for punishment I decided to transfer everything over to this device (after trying out RetroPi with it first – because reasons) and do the fault finding on the 3 (also hoping the problem would disappear. It didn’t). In fact this seemed even worse. I was seeing nothing at all on the UART pins in the GPIO, even before I disabled the boot terminal.
More digging. It turns out that Raspberry Pi 1 and 2 had the UART pins on the GPIO mapped to UART0 on the Broadwell chip at the heart of the Pi. Raspberry Pi 3, which features on board Bluetooth, has UART0 mapped to the Bluetooth gear. The pins on the GPIO are mapped to … nothing. Or so it appears. Somebody at the Pi Foundation has made a booboo.
So now back to the Pi 2 but this time running Jessie. The new plan – once I’ve got the serial port running I’ll check if GTK now works.
It quickly became obvious the 4 way JST housing with the wrong crimp connections in it was causing the problem. D’oh. I finally did what I should have done a couple of weeks before and ordered the correct cable I should have ordered a couple of months before (that will make sense if you’ve stayed with it this long). Fortunately it arrived the next day.
Now armed with the correct cable I was able to get the LED on the finger print scanner to light. Hooray! Finger on scanner detection worked too. Now to teach the scanner a finger print. Aaaaaargh!
I spent two weeks trying to work out what was going on. It appears that simple messages worked fine, but anything that involved a proper interchange of information with more than one exchange failed. Even finger detection seemed to be a random Boolean generator. Looking at the responses from the Fingerprint scanner it appeared something else was using the UART. But I could not find the rogue application.
I seriously considered going back to the Tablet and dodgy splitter idea at this point, but then had an even more drastic idea – Windows 10 IoT.
Without getting in to the history of Operating Systems let’s just say people who like Linux don’t like Windows. Generally. Personally I’m more pragmatic. An OS is nothing but a tool. I don’t care about an OS, applications are important, the messenger between the low level systems and the GUI are not. I just want the right tool for the job. A hammer is not better than a screwdriver, unless you have some nails you want to bang in to something.
Limited resource devices that do dedicated jobs, such as the kittE, are firmly in Linux and Debian territory (which is why the official Pi operating system is a variant of Debian). If this thing was also meant to simultaneously play games, manage an extensive media library, wasn’t struggling for processor power or RAM and needed to have system settings changed regularly it would be in Windows territory. If I had more money than sense and wanted to be locked in a walled garden for eternity I’d go with the other one.
So Windows is not a natural fit for the Pi or this scenario. However Windows 10 IoT is claimed to be different. So I gave it a try, more in the hope I’d be able to fault find whatever was going on with the scanner as I have a lot more experience of controlling serial comms with Microsoft’s languages.
Well, you know what. I was impressed. Not only did the touchscreen work (once I’d downloaded the pre-release version of Windows 10 IoT), it worked well. Okay my Wi-Fi dongle wouldn’t play but other than that it was terrific. The UI looked clean and crisp and modern, the finger print scanner worked fine and there was even an extension for SQLite. At this point the research phase was over. I’d got my hardware and software issues all sorted. Windows, it turns out, solved my problems. I didn’t see that coming!
So, to answer the question posed at the very end of Part 2, many things. Many, many things.