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).

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.

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.

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.

Monday, May 16, 2016

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:

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.

Saturday, March 26, 2016

The other day I received the Itead PN532 NFC module in the mail. Time to install it on Raspberry Pi.The PN532 allows for Near Field Communications, e,g, for using an access card to enter a building or transferring info from a smart phone to a computer.The installation instructions that came with the device were rather vague or shall I say non existent. And so was any other information about it on the Interweb. Piecing together various snippets allowed me to install it and actually have it work. That is why I am documenting it here just in case someone else comes across the same problem.In am installing it on Raspberry Pi 2, with Raspbian Jessie as the OS. Furthermore, I will be using it with NFC.py, a Python library I am quite familiar with. It uses the UART set up (serial).First off, we will not use the double row of pins (26 pins) on the PN532. We will use the single row of 8 pins, of which only 4 will actually be connected to the Pi. Note that you will have to flip the device over to read the markings for each pin on the back of the PN532.

The connection from the Pi to the PN532 is as follows:Connect Pin 2 (5V) on the Pi to the Pin marked 5V on the PN532Connect Pin 6 (Ground) on the Pi to the Pin marked GND on the PN532Connect Pin 8 (GPIO14) (UART TX) on the Pi to the Pin marked NSS/RCL/RX on the PN532Connect Pin 10 (GPIO15) (UART RX) on the Pi to the Pin marked MO/SDA/TX on the PN532So much for the hardware side. Now we go on to the software side. Of course, we bring the entire system up to the latest value by issuing:sudo apt-get updatesudo apt-get upgrade

Then, we need to modify the file /boot/cmdline.txt. Do that by issuing the following command:

This line will install serial library for Python used by NFC.py.sudo apt-get install bzr

This command will install Launchpad bazaar, a VCS (Version Control System), which allows you to download NFC.py.mkdir pythonprogs cd pythonprogs

Above 2 commands create and then switch to the directory where my Python programs will be stored on this machine. You may already have a favourite directory on your machine.bzr branch lp:nfcpy

This line downloads the latest version of NFC.py.cd /pythonprogs/nfcpy/examples

Now you've changed to the examples directory of NFC.py.

python tagtool.py --device tty:AMA0:pn53x show

Run the Python program tagtool. The ‘device’ switch following tagtool.py specifies that we want to use the serial device. If there is no error message, things should be working!Touch a card on the reader. You should get a response on your screen. Notice that you cannot use a Mifare Classic 1K card, they are incompatible with NFC.py. However, I've had good luck with NTAG203 cards, which are readily available.

Thursday, February 04, 2016

I obtained a Raspberry Pi Zero a few weeks ago, but hadn't really done anything with it. I was puzzled as to how to access it initially, since it only has one USB port and no RJ45 connector built in for accessing a network.

The easiest thing would be to get a USB hub, but I wanted a minimalist approach. No screen, keyboard, mouse. This method only requires a wireless dongle. So I did some sleuthing on the old Interweb and stumbled and David Maitland's blog.

My approach varies slightly from his, that is why I describe it here:

get access to Raspberry Pi Zero on the network by:
- downloading Raspbian Jessie and dump the image on a microSD card using your PC - taking another Raspberry Pi, a B+, inserting the 'Zero' microSD card in it - hooking this up to the network (or screen, keyboard and mouse) - booting the Pi B+ - modifying the file /etc/network/interfaces file
specifically: add 'auto wlan0' as a separate line above 'allow-hotplug wlan0' - modifying the file /etc/wpa_supplicant/wpa_supplicant.conf
specifically: add to the end of this file

Obviously you will replace MYNETWORKNAME and MYNETWORKPASSWORD with your specific values.

- gracefully shut down the B+ - take the microSD card from the B+ and insert it into the Zero
- attach a wireless dongle to the Zero's USB port - boot the Zero, it should work. If not, check the entries you made for the network values.

Hunting around on the forums, I found a post that stated that if you were
presented with a blank screen after booting, you should try pressing Ctrl+Alt+F2
to get back to a regular console screen. It worked. I hunted around some more
for a better solution, but to no avail.

By the way, this problem does not occur if you have it setup so that you
automatically startup startx after booting.