Tuesday, May 17, 2016

Circuit Chaser: Raspberry Pi + NFC = timer for children's run thru a playground.

Circuit Chaser uses a Raspberry Pi along with an NFC reader to clock outgoing and incoming times for cards (or wristbands in this case) being placed near it.


Hardware wise, it consists of 3 major components:
Software wise, the main components are:
  • Python application using NFC.py to track card touches
  • Python application using CherryPy to supply latest info to web browser display
  • Web page running in Epiphany browser using some heavy duty JavaScripting to update screen continuously
  • Python application monitoring usage and enabling/disabling screen when required
 And then, of course, there is the case, which is actually a case within a case. But more about that later.

This project got started when my daughter bought Zoom Zoom's, an indoor children's playground. Always looking to get an edge up on the competition, we brainstormed several ideas around until the idea of Circuit Chaser came to the fore. This device lets kids clock out, run through a previously determined course in the playground and then clock back in. Runs can be done simultaneously, i.e. more than 1 kid can be out on course at the same time (up to 11).

I covered the installation of the NFC reader on the Pi here: http://khekker.blogspot.ca/2014/01/raspberry-pi-clean-install-of-nfcpy.html.

As a card is brought near the reader, it triggers the reader into action. It reports the unique id of the card, and my Python application then records this in a SQLite3 database table. If a card currently is 'out', the application records the new time as 'in' (or finish, if you like). Otherwise, it records this as 'out', along with the time of the event. The application next does a retrieval of the last 11 records and creates a text file, which will be used by the CherryPy based application described below.

The application also retrieves the pseudonym of the card, making it more palatable for human eyes.

The application based on CherryPy continuously monitors this text file for changes. If found, it will send this file to any browser currently connected to it. If none are found, it goes to sleep for .25 seconds and repeats.

Along with the file sent to the browser is a variable containing the number of seconds expired since midnight, since this is important to keep the times shown on the display accurate. Each system does not necessarily have the same time as the next.

An insight as to how the browser gets to display this information I provided here: http://khekker.blogspot.ca/2013/12/raspberry-pi-cherrypy-and-asynchronous.html

Once received by the browser, the JavaScript takes over and runs continuously, every second updating times for every card/wristband line shown on the display. It uses the variable containing seconds since midnight sent from the CherryPy application and compares it to its own, and either adds or subtracts the difference.

Lastly, the application monitoring usage runs continuously and shuts down the display if no activity has been detected in the last half hour and turns it back on when a card is entered near the reader. The shutting off and starting up is based on this hack by Alex Eames for the HDMPi.

The normal screen blanking on the Pi has been disabled, as explained here:http://khekker.blogspot.ca/2015/12/screen-blanking-raspberry-pi-b.html

I spent an inordinate amount of time on the case. I knew I wanted a transparent case. First, I found a lexan case on the web, which I spent alot of time hacking so the Pi and all its connectors would fit. It looked really good. Then I realized, hey, this has to be used with kids, they can break 'pretty near' (Canadian for 'almost') anything. So I built yet another lexan case around it. Next time, I'll simply go to the specialty place where they sell lexan sheets and for not too much money they can build me a case. A couple of aluminum strips attached to the back of the case allow for attaching to a wall.

The device has been running for over three months now, and has been received well. Better still, it hasn't been broken, hardware nor software wise. It is connected wirelessly to ZoomZooms LAN, and its output could, if port forwarding was employed, be visible on the greater Interweb.

 All files are up on Github: https://github.com/khekker/CircuitChaser, with the exception of NFC.py and CherryPy, as explained above.

The NFC wristbands I obtained from Overair.ca

Monday, May 16, 2016

Raspberry Pi Zero + HD44780 in a slim package for use as fuel computer

Back in August 2013, I blogged about the fact that I had constructed a car fuel computer. In a nutshell, this device displays instantaneous fuel consumption (last 3 seconds), as well as the trip average, using any one of 4 output formats on a dashboard mounted LCD. The device is hooked up thru a USB port to an ELM327 Car scanner, which, in turn, is plugged into the car's OBDII port.

Creation of the device was based on earlier work done by Martin O'Hanlon. It used a Nokia 5110 LCD to display the output. One might argue that it was more of a prototype than anything else, since the display was held to the dash with electrical tape and a case of any sort was absent. Proof of concept.

In doing further testing with the Nokia display, my findings were that it was somewhat unreliable in the harsh environment that a car interior can present. For 'no good reason', the display at times would blank. Reboot the Pi, and everything would be fine again. Not good when you are travelling down the freeway at 100 km/h. (I'll never admit to speeding).

So in early 2014, I adapted the fuel computer application to use the very standard HD44780 LCD (16 characters by 2 lines) display. This time, I used a display case, but it only contained the LCD, since the Raspberry Pi 2 was too big to fit inside.

Enter the Raspberry Pi Zero and its small form factor. Just as soon as it was released November 2015, I knew that I would like to take a crack at incorporating this little miracle along with the LCD in the display box. So, early February, I started on this quest. Of course, what seemed simple from the outset, turned out to be quite the opposite: never have I stared so hard for so long at so few square inches, trying to fit it all in and still have it work reliably as well as allowing for maintenance and accessibility. Here is the result, with the device showing data for the last 3 seconds and the trip average in litres per 100 km (Canadian standard):





This is what you see when you take the 4 screws out of the back and open up the case. Note that the SD card can still be removed without taking anything else out.



For reasons explained below, I had to create an intermediate board between the Zero and the LCD. Here, the HD44780 is on its back here ready for mating with my sandwich board:


And here is the Raspberry Pi Zero and the sandwich board. Notice that only 1 row of GPIO pins from the Raspi Zero are being used.


This is a side view, the HD44780 LCD display on top and the Raspberry Pi Zero on the bottom:


The three buttons perform the following actions: pressing the top one steps thru the brightness level from 1 to 10. Pressing the middle one steps thru the contrast level from 1 to 10. Pressing the bottom one changes the readout mode from litres per 100km to miles per gallon US, then to miles per gallon Imperial, and lastly to km per litre. In addition, if the device detects the car is idling and you press this button, it will change the display to "Press shutdown again within 3 sec". If you do, the Raspberry Pi will shutdown, which is far better than simply turning the ignition key off right away.

So, to construct this, at first I thought I'll just connect individual wires from the Pi to the HD44780, plus a few more to the buttons for contrast, backlighting and display mode and then simply (and cleverly I thought) use short right OTG cables for power and data. Wrong, wrong and wrong. Loose wires tend to break if wiggled once too often or pushed into too tight a corner too vigorously. Too many wires, and you don't know what is what anymore. Besides, what length should they be? And 2 right angle OTG cables won't fit, because one overlaps the other, which makes it physically impossible for it to fit in the intended USB port.

Plan B: use male and female headers soldered directly onto an intermediate PCB (a 'sandwich' board) from both the Pi and the HD44780, then have the PCB traces hook up to the correct pins. In theory, this should work. The total depth of the case is 25 mm, a male and female combination makes up 10 mm, you have 2 of those, what could possibly go wrong? A whole lot, that is.

First off, my soldering skills are level amateur. This means heaps of solder at the base of a pin amounting to probably a few mm. Then you have the thickness of an extra PCB. There are also a few capacitors sticking out of the sandwich board.

Plan C: use right angles male and female headers. After an overnight deliver from buyapi.ca (thanks guys!), I was able to start development of a PCB in Fritzing. I had to get out my micrometer for super accurate measurements. After 12 iterations, (each time I would print a version on paper and fit the connectors on there, trying desperately not to prick my fingers too often) I decided to make a PCB. I will spare you the details, suffice to say, it took a lot of time and it wasn't half bad. Physically fitting it all together seemed to work so...

With loads of confidence, I fired it up in the car and, of course, it didn't work. It turned out, I had soldered and desoldered the HD44780 so often, I had fried it. Fortunately, I had another one at hand.
After soldering on the right angled header, another trial run. More problems. At that point, I realized I still had a database in my possession from the Raspberry Pi 2 prototype. (The Fuel Miser generates a new SQLite database every time it is run.) Since in-car testing is very time consuming and difficult, I decided to create an emulation mode where the Python 2.7 script steps through entries in the database and presents them on the LCD display as though we are driving in a car. Not perfect, but a lot quicker. This weeded out yet another pile of bugs. Next, I also incorporated in the application for info that is normally written to the console to be redirected to a text file. Very handy. This allowed me to, upon return from a trip, to review debug data I had 'print'ed. Finally, success.

But: the case wasn't put together yet and this proved impossible to do without screws through the three boards keeping it altogether. Since I had made no provision in my sandwich board for mounting screws (duh!), it was back to PCB design. A few more hours (or was it days?) in Fritzing, moving components around, making room for the screw heads, and, more importantly, the nuts. I was ready. But, by that time, I just wasn't up to making yet another PCB board myself. Instead, I sent it off to a fab house.

Waiting, waiting, waiting was the name of the game for the next 28 days. That's how long it took to get the board back. Then, soldering it all together and fitting it into the box. Time to test: it works!

I just had to do some software fine tuning. I may still have to do some more.

I used GPIO Zero to use PWM for both the brightness and the contrast levels. You can actually use RPi.GPIO in the same script as GPIO Zero. Who knew! In testing, I found that GPIO Zero was not as fast as RPi.GPIO when displaying text, so I decided to use RPi.GPIO for that.

I also incorporated the writing of text and that of the PWM for the contrast and brightness buttons into a separate class called HD44780.py. Even though I am using the whole unit for fuel economy purposes, as such it could easily be employed for some other use. Another right angle header could be mounted on the Pi, giving access to 20 more GPIO pins.

I kept the readout mode button out of this class, since it is not necessarily related to the functions of the LCD panel.

All the files are on github here: https://github.com/khekker/Raspi-Fuel-Miser. There you will also find a not-so-neat hand drawn wiring diagram. Sorry 'bout that, my Fritzing skills are limited. Check out the readme.md file for further information.

The PCB's from the fab house turned out really nice. I have some spares, in case anyone is at all interested. I'll sell them for $3.00 Canadian plus postage. Let me know in the comments.

Since the following parts are hard to get, I could supply them as well:

7 pieces 2.6 mm screws 10 mm long with nuts $1.00
7 standoffs (3 short and 4 long pieces) $0.50
3 pairs of right angle headers (male and female) (2x6 and 1x20) $1.50
1 project case $5.00

That's $11.00 Canadian, approximately $8.75 US or €7.30 plus postage.

If you want me to 'hack' the appropriate holes in this case, then there is a $5.00 charge for that. Canadian of course, $3.90 US, or  €3.30.

Just 2 observations I made using the device in-car, both of which would likely make safety experts cringe. The first is that driving behind a large truck makes a difference in fuel consumption (around 10%), the second is that on a car with standard transmission ('stick shift'), putting your foot on the clutch while coasting down the hill cuts (the already greatly reduced) fuel consumption in half. But it is not safe to do, so I strongly advise against it.

Note that the device stores a whole range of parameters generated by the engine's computer in a database, which could be reviewed or otherwise analyzed afterwards. For every trip, a new database table is created in SQLite3.

Now if only the Raspberry Pi was more readily available!  Oh, wait a minute...hot off the press...a new Raspberry Pi Zero released today...it adds a camera function. The camera connector sticks out a few mm from the Pi, but that should not present any problems fitting it into this particular case.