Skip navigation

Original article at:


Here are the updates:

I’ve bought an extender for the RP pins from Jola Engineering and soldered the shim onto it. Now I can put everything together nicely.

After that I’ve started playing with the PiFace using the pifacecad library.



The initial test was just to show stuff on the screen, and then I wanted to use the buttons to do something with them, but…. apparently, I couldn’t. It seems that the Linux kernel 4.1.6-v7+ on the latest Rasbian, has a bug with the epoll system call that causes it not to react to hardware interrupts on GPIO25 (RP pin 22).

More info and explanation can be found in this bug report.

Here’s the sample code I’ve used from the pifacecad documentation:

>>> import pifacecad
>>> def update_pin_text(event):
...     event.chip.lcd.set_cursor(13, 0)
...     event.chip.lcd.write(str(event.pin_num))
>>> cad = pifacecad.PiFaceCAD()
>>> cad.lcd.backlight_on()
>>> cad.lcd.write("You pressed: ")
>>> listener = pifacecad.SwitchEventListener(chip=cad)
>>> for i in range(8):
...     listener.register(i, pifacecad.IODIR_FALLING_EDGE, update_pin_text)
>>> listener.activate()

Because of this, I’ll put the piface on the side for now and continue to play with the GPS module.

I’ve yet to find a good battery that I can use, to make the RP portable.


Previous posts:


An Ill Wind...

Posted by dmedlow Sep 14, 2015

Alas winter has hit the old homestead hard, with most of the family down with or recovering from variations of head, chest and other colds.

Hence not much fun stuff happening.....


However I did start thinking about how to get diagnostic info to a gps client program, and again came to the conclusion that it still might be better to read the gps stream myself as the other parsers generate errors without a fix present. So I modified my last software to add more diagnostic info to a file and took the GPS board for a walk. Within about 30 seconds a valid fix was reported and all seemed to be well, except that the LCD froze and didn't display the (expected) location information. Initially I thought this was my code doing something unexpected so I brought the unit indoors and plugged it into the monitor.


It turns out that a Python exception had occurred so the code was no longer executing. The exception was easy to fix but it highlighted that the LCD buffer continues to display what it was last sent and will continue to display that data even if the PI is shutdown. Therefore any code writing to it should have a high level exception handler and closing code to gracefully clear the display and power off the backlight. I'm new to Python and will need to think about how to do this elegantly and will try to incorporate this in the next version.

Having now resolved (hopefully) the hardware issues with the GPS and display mounted simultaneously it was time to check out the GPS reception and ensure that I was seeing good NMEA data on the serial interface.

My problem is that the area where I do most of the experimentation has no close area where GPS signals would be available, and the Pi display currently is shown on a large 27" display I can't relocate.

The solution of course is to use the Pi LCD display as there are Python libraries to write to this. But I need to display something meaningful on the LCD - I picked the number of satellites available as the data for this - it doesn't mean you have a fix, but it does indicate if your GPS receiver is able to receive the sat's signal.

# Simple routine to read GPS data from the serial stream and search for
# the number of sats in view in the GPGSV sentence.

import sys, math, time
import microstacknode.gps.l80gps
import pifacecad


while a:
    with open("/dev/ttyAMA0") as gpsData:
        for line in gpsData:
            sentence = line.split(',')
            if (sentence[0][:6] == '$GPGSV'):
                cad.lcd.write("Sats= " + sentence[3])


Therefore I wrote a small program that read from the GPS library and displayed the output. Unfortunately these libraries raise exceptions when a GPS fix is not available. (To me this is not a good thing, these libraries should be a little more defensive. For instance if you ask for the GSV data (GPS Satellites in View) with no fix the library effectively gets an array out of bounds exception as the GSV sentence returns less data points when there is no fix.)


The next best thing was to read the NMEA serial port (/dev/ttyAMA0) directly as a file. A few versions later I had something that would start-up, read the NMEA stream, look for a $GPGSV sentence header, decode it and report the number of visible satellites on the Pi LCD display. Running this via a battery box USB supply allowed me to take the entire assemblage outside and check that yes, indeed I was seeing one, 2, 3, ... up to 10 satellites using the high gain antenna.


Therefore I was happy I can accept input from the GPS and will probably go back to using the gps client libraries but I will have to trap exceptions when a fix isn't available. However the libraries do do a lot of the heavy lifting with respect to data element decoding. This is what others have done in their code and this exercise helped me to understand why that was needed.


The other interesting thing was that after some time I found my 4xAA battery box could no longer support the PI, to the extent it would refuse to boot. This was only after ~1.5 hours of use, so I am curious now as to the power consumption of the Pi, GPS & LCD configuration. At some point I'll put my meter on this to measure it.


Next step is to store the GPS data in a file and make this process auto-running in the linux environment. Then I can move the LCD display code to a client process that interrogates the data file.