Skip navigation


7 Posts authored by: dmedlow

A few weeks since the last post, mainly due to the tenacious cold & flu-like bug circulating around the family. Since that's now gone I was keen to look at more GPS coding on the Pi.


My last attempt had reading of the serial port running fine until it was interrupted, then it produced errors on reading caused by the serial stream being read off of a character boundary.

Furthermore once the stream has been read for a while it then only produced 8 or so characters per read - pointing to a buffer starvation as the read terminated before the characters from the GPS could be read in. Both of these were fixed by treating the GPS as a serial stream device with a defined timeout:


gpsStream = serial.Serial(gpsDevice, 9600, timeout=1)


At this point I wanted to auto-mount my USB device so I edited the /etc/fstab and added a line for the USB drive, now this mounts automatically.

Then being conscious of the need to keep software up to date I then performed a apt-get update/upgrade cycle, noting that the microstack code was listed among the packages being updated.


Bad move. Once the new software had installed my code now refused to run - an error being reported at the GPS module import...


import microstacknode.gps.l80gps


and saying this module could not be found.

After an hour or so of googling this and not getting anywhere I had a look inside the /usr/lib structure where all of these libraries live and found the microstacknode folder area.

I noticed that the folder path to the l80gps module included a 'hardware' folder that wasn't represented in the import path.

Sure enough once I changed the import statement to:


import microstacknode.hardware.gps.l80gps


... and the code once again ran happily. I have no idea if the update actually changed anything in the folder path - all I know is that it ran OK prior to the update and didn't afterwards until I made the change to the import statement, so if this also happened in your project that might help you out.


Now I was able to modify and debug the code to watch for an active fix, extract the lat and long and save these to a file for the client to inspect as well as display these on the LCD. At the same time I experimented with using the piFace switches so that rather than killing the code from a Ctrl-C I can now exit gracefully by pressing a LCD board button. All pretty much Pi-101 I'm sure for most but new to me and useful in working out what I can and can't do with this set of boards.


This means that the GPS interface code is fairly complete for now and I need to remove its access to the LCD and package it up to be run automatically when the Pi boots. It will write its results to a file for the client to read. It also writes a log file to the USB so that if I ever need to see what the GPS is outputting I have a trace of that (and with a 64GB USB stick to play with there's plenty of space for logs!).


The next job is to think more about what the GPS client is going to look like. Like some of the other examples I'm thinking of reading in a list of caches and allowing the user to select one using the switches on the LCD board, whereupon the distance to the cache will be calculated. This is where I might add some electronics to display a LED bar graph based on the distance to go once the unit is within, say, 50m of the cache. I'll think some more about that and post something next week...


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.

I was quite happy to get the Pi LCD display working by following the blog posts, but was disappointed to find that when I had both the MicroStack GPS module and the Display Board connected, the GPS Board stopped working. By a few elementary tests this was found to be caused by the shim board power connections (and probably data as well) not making positive connection on the side connector (the one to which the GPS was connected).


A number of others have commented on this and the solution seems to be to solder the shim onto a 2x20 pin header. I duly went out and procured same, soldered on the shim and, voila.. working GPS on the side connector. On reflection the shim idea is probably OK if it works for people, but I think it is a solution that relies too much on the vagaries of the mechanical setup of the boards on the Pi. Supplying the shim kit with the aforementioned header would resolve the problem.


Now I can progress with writing some software - however an idea occurred to me that in addition to the display, you could also utilise a LED bar graph that is slaved to the distance from the cache point - a kind of 'getting hot, getting cold' indicator that might be more fun for the junior cachers rather than reading GPS coordinates. I'll think about adding that a bit later and see how well it works.

Today was spent soldering the Pi Shim and finding out exactly how bad my soldering skills were. Overall though not too bad and once completed it was time to mount the GPS on the microstack and the subassembly onto the Pi.


Once powered up I followed Charles Mao's second Geocaching blog post (link)  and updated the O/S, PI firmware and installed app software. Unfortunately I missed a step which was to cause some pain later...


After configuring the GPS Daemon and rebooting the system I looked at the port the GPS was supposed to be outputing text on (/dev/ttyAMA0) and found nothing. Not to be deterred I powered down, removed the shim and tried again... nothing. Powered down again, looked carefully at the config, ensured the microstack was located correctly and the GPS daughter board mounted correctly and tried again... nothing.


Hmmmm. At this point I remembered reading the MicroStack documentation about the GPS Board. I went back and followed their instructions to see if there was anything there that might shed light on the problem. Their instructions included using the config utility to turn off serial port access to the Pi ( the step I had missed earlier). I did that and rebooted the Pi and ... voila... NMEA strings pouring out of the serial port...


So the moral of this story is (1) follow the posts of others more carefully and (2) sometimes looking at other documentation can give you a lead on what you might have missed.




Anyhow the GPS hardware is now up and running (with the patch antenna) and the software loaded for a Python dev environment, next step (for me as a non-Python person) is to run through the dev process with some simple apps to read the GPS data.


Getting Started

Posted by dmedlow Aug 16, 2015

Finally got to unboxing the hardware and seeing what was supplied for the geocaching build.


The Pi2 looks good, particularly with the additional USBs and the reduced footprint with the micro-SD card. I mounted the Raspberry on a board that I can use as a prototyping platform until I decide what the physical packaging of the end result is. Using a wireless keyboard/mouse (logitech) allows more physical flexibility. Its awesome how much processing capability is now available in the platform of that size.


The Pi is very easy to set up with the supplied SD software. Charles Mao has documented this very well (see It all fired up first time without a problem...


First time the PI Powers up.


In addition to his steps I added a spare WiPi USB 802.3 dongle to enable wireless comms. This requires you to edit the interfaces file in Linux which takes about 5 minutes and restart the networking processes. Once up I was on the net and able to update the Raspberian software (only 173 MB). This is clearly a faster platform than the previous P'is I've owned.


I initially wasn't sure which way to solder the Pi Face Shim (but the other blog posts have made this clearer) and will be looking at this job next, along with mounting the GPS & Display and loading the necessary drivers for the display & GPS. I will be looking at other postings for guidance on the best dev environment to use. The final application for the kit is still not clear, but now that I am clear on the hardware supplied I can start to consider the options.


Geocaching Build

Posted by dmedlow Jul 20, 2015

Being selected for the geocaching build is fairly awesome.

It does raise the challenge of exactly what to build.

My partner is a geocaching fanatic - but is often cursing at the handheld dedicated GPS unit she uses.

Often it fails to provide a good position fix, its hard to download web based cache location, the UI is rubbish and the batteries drain faster than you can say 'do we have any more batteries'.


My initial thoughts are to use the Pi + GPS (obviously) combined with one of the very scrumptious 4DSystems touch-sensitive displays and a PAN board to get internet access from a mobile, add a camera to this to allow the user to take photos for earth caches and other requirements where imagery is required.


I'll mull over these challenges and solicit some customer input....