Back To Home

A GPS Display for Headless GPS Units.

By Simon Watt-Wyness ZL1SWW.

Amateur Radio has so many aspects to it  that  an amateur has to decide what he or she wants to do when it comes to what direction they want to go in. For me, I would like to have a go at  most anything within practicable limits.

APRS has been one of the facets that brings together a bit of radio technology with digital technology. I have been interested for some years as to doing GPS positioning and being able to see my location on computer screen  as well as  announcing position over the air.

I have been in the process of putting some building blocks together to from a permanent system that would run in the car at the time I switched the ignition on.
My first hurdle was to get a small GPS module together that was inconspicuous in the sense that the antenna was not easily noticed. Some of my friends have the GPS "Mushrooms" while they work well, they take up a bit of space on the parcel tray for instance.
I was lucky to procure a new GPS module  made by Ashtech that is a subsidiary of Magellan. All I had to do with this was to put some outside logic to drive RS-232 signaling levels as well as a monostable circuit to stretch out the 1 second output that pulses at 1mS. This was to primarily drive an LED  for indication of  satellites.

The module was built up  with  two RS-232 ports, one to feed the APRS Tiny Track unit and the other to bring into the car cabin  to feed the laptop or some form of readout.

The idea  of having readout in the car would be great. I have the need to take GPS coordinates in the actions of my day to day work so parking up by a site and taking AD HOC readings would be useful.

I decided it was time to have a go at building one myself. With Murray ZL1BPU  encouraging us to get into micro related projects, I decided upon the Atmel Micro, in this case, an AT90S2313. It has just the right amount of code space and has enough pins to drive an LCD.

Having never done much  Micro programming before (have altered a few others before though), I decided to have a look at the high level programming approach. Many Micro controller code writers use either C or BASIC or Assmbler compilers, which leave the harder work of coding up machine code to the  compiler.

My choice was to have a go at BASCOM AVR. There is a flavour of this for AVR as well as the 8051 series processors. It can be pulled of the net  for free but has a limit on a 2kb program space, after that, one has to register for a fee to get the full-blown version.

Having programmed in basic for a few years back, this seemed like a good idea to have a go at this. I went through a few steps first to get  things running.

Step 1). Make the programming cable for parallel port to AVR programming.
A standard old PC serial port cable supplied the 10 way header and the DB-9 Male was kept for the serial input of the display project.

Step2).Make up the AVR board with the display connector etc. HERE IS THE SCHEMATIC

Step3). Write a small basic program to write to the LCD display. This is very easy by initializing the display, selecting the cursor position, in this case using the "upperline" command.

An example of this is:-

Cls
Home
Upperline
Lcd "This is a test"
End

Before compiling, one needs to set some variables.
The type of  AVR used, the speed of the AVR crystal used, the port pins for the LCD, the LCD type (16*2) etc and the speed of the serial port UART.

These can be embedded in the BASIC code, which will override the compiler settings or  leave them out and set the compiler.

Step 4). Compile the code.

Step 5). Check that the programmer cable works. I  first used the Atmel ISP ver 2.56 software to program the chip. The LCD I had to unplug as it was causing some bus contention. I have added resistors (330 ohm) to limit contention.
After that I used the programming system included with  BASCOM AVR. It also worked a treat and didn't have the need to unplug the display.

Following the above steps, gave me a path to getting an AVR development system up and running. From there I was able to cut some code!

The GPS NMEA string.

Most GPS units have the ability to output a standard ASCII string that conforms to NMEA 0183. The NMEA-0183 standard has details for electrical specifications as well as protocol conventions. The electrical specifications actually recommend using the RS-422 standard, which is slightly different than the RS-232 standard.  Most output at 4800 baud and will generally have a string that starts with $GP.......

A Breakdown of the string is as follows:

GGA - Global Positioning System Fix Data
 $GPGGA,071409.00,3650.11000,S,17452.41093,E,1,08,02.4,00073.12,M,030.741,M,,*45

071409   Fix taken at  07:14:09 UTC
3650.11000,S  Latitude 36 deg 50.11' S
17452.41093,E Longitude 174 deg 52.41093' E
1    Fix quality: 0 = invalid 1 = GPS fix 2 = DGPS fix
08    Number of satellites being tracked
02.4   Horizontal dilution of position
00073.12,M  Altitude, Metres, above mean sea level
030.741,M  Height of geoid (mean sea level) above WGS84 ellipsoid
(empty field)   time in seconds since last DGPS update
(empty field)   DGPS station ID number

The pieces in bold are what I deem useful for the GPS display.

Several methods could be used to pull the information out of the string  and display it. The two methods are: -  Read character as it appears in the UART and display it on screen, or, read in the whole string into a dimensioned array and the do the post processing and pick out the fields.

I chose the first method for several reasons:
1). Smaller code space as dimensioned array takes up memory.
2). Reduction in the time to display the info as it appears out of the GPS unit
3). Easier to program for as there is deviation from GPS to GPS on string length, I see this in the two GPS units I have.

An interesting article I perused regarding GPS time was that although the GPS time standard is very accurate, beware that there can be a deviation on the GPS unit display and the time pips listened to on WWV for instance. This is attributable to the internal software routines used in the GPS to do all the displaying of data and general housekeeping of the GPS, this mainly affects the handheld units and units with display capabilities.

Operation Of The Unit.

The circuit is very simple. RS-232 data is received from the GPS as 4800 baud data. Most GPS output this as standard, although some units may require the NMEA to be turned on. The data is buffered and inverted by the transistor and offers some level conversion from the GPS unit although most put out a 0 to 5v data transition.

The  2313 reads in the inverted data and looks for the occurrence of the   "$GPGGA" string and if it sees any other string which does not start with "$GPGGA" it will wait for another occurrence of the GGA string before it processes the data following.
To be more concise, it actually reads each byte as it arrives at the UART so it will wait to see a "$" and once this criteria is matched, it will then wait for a "G" and repeat the process until the whole "$GPGGA" is read in, from there, I use the commas as delimiters and then work from there with counters.
All this, of course, happens very fast within the micro so no time is lost sorting through the sentence.

The display will show if the fix is not valid by displaying "No Valid Fix..." In my GPS module, it will start displaying the time on seeing one Satellite so the display unit will show time and "No Valid Fix". This is done by checking to see what value is in the "Fix Quality" part of the GGA sentence. If it is Zero, the 2313 deems it as invalid.
As I watched the behavior of different GPS (my own two) I refined the software to cope with the differences. These differences I note are:

* The length of the fields.
* The order in which data appears, (time first and then Lat and Long).
* If the fix goes from invalid to valid, what happens? (Some GPS still output serial data with the FQ string set to "0" and some just stop transmitting data as in the Magellan GPS315).

I have tried to make the unit be as useable on many GPS  but there is the possibility that there will be some that will not read at all or will cause the display to show odd characters like commas for instance. All this could be catered for on a one by one basis.

I did find that with my Magellan handheld unit (GPS315), the time would advance in 2 second increments. This was due to the fact that the unit puts out about 4 sentences at each data burst. At 4800 baud, the volume of data sent exceeds the 1 second interval and hence the micro has to wait for the next consecutive sentence to get the information again. The fix for this is to increase the data rate to 9600 baud.

My circuit started off using a 16*2 LCD  but  as I wanted more info on the screen, I have migrated to a 20*2, and just lately, have procured a 24*2 unit so now have included the number of satellites seen as well.

Construction.
Seeing the circuit is so simple, I decided to build it up on Veroboard. Due to the diverse types of display out there, it seemed and easier option. My displays came from old telephones, line printers and a couple I bought on special from DSE. They all have different connector layouts but the numerical pin allocations all were the same but for one strange unit I have. The micro board has a socket that takes the pins from the display board and it all just plugs together. I recommend this system as it allows programming the micro with the display off the unit. I found that some displays you can program the micro with it plugged in and some you cant. Some of the display data pins also share the programming lines and this was done to save code space. They could be changed from the defaults in the compiler but I opted to leave them at defaults.

Boxing The Unit Up..
The unit only needs 3 wires to run,  +VCC, Ground and the signal for the RS-232. My dilemma was what box to put it in. I was hoping to put it into a slim line case so that it could be velcro'd to the dashboard etc.
I was about to build one out of PCB material but found a box at Dick Smith that has a battery opening at one end and is just right to put the display module and associated electronics in as well. The box is CAT No H-2950. I was able to cut a slot in the front for the display but had to cut out the pillars at the battery end so the display would fit. I fashioned up an "L" bracket from a piece of scrap metal that was threaded with an M3 thread which was then mounted to the end by epoxy to hold the end together as a replacement for the pillars I cut out. 

The cable I used to feed the device was a bit of Audio twin lead. I didn't want a thick piece of cable that forced the box around the place as the unit is very light, and stiff cable would make it very hard to place somewhere.

A breakdown of the pictures supplied are as follows:-

Fig 1). A closeup of the display in a location showing the latitude / longitude / time / altitude and number of satellites visible at the time.  

Fig 2). Display all boxed up in the Dick Smith  H-2950 Box

Fig 3). The Atmel  AT90S2313 on vero. Note the programming header on right hand side. The white thing next to it is a support to separate the board from the display

Fig 4). The GPS only seeing 1 satellite. Note the message generated  as a result of reading the "fix quality" field  in the NMEA sentence

I hope that this unit will be useful for people.

Details and code can be supplied on request.

Email me at 

73's de Simon , ZL1SWW.

Back To Home