GPSS has a long history of being used for remote tracking with radio (see the ancient history below), but, with a few exceptions, this has been done by a handfull of amatuer radio enthusiasts in many of the 160+ countries in which GPSS has been used.

In 1999 I was contacted by Roger G7RUH (see below) who lives very near Sunninghill, and so I had the opportunity to see some of this work "first hand". This prompted me to setup this page in 1999, and a lot more has happened since then.

We hope some of you will share your experiences with us - whether your motives are "business" ones, or simply "enthusiasm for the technology". I am particularly keen to spread knowledge of "off the shelf" hardware, since it helps my business contacts to create better or lower cost solutions.

Most of the "serious" applications of GPSS for remote tracking use satellite or mobile 'phone communications - as you will see on the CHASE Page . However, for some applications, like minute-by-minute tracking of taxis within a city, emergency services and police, or in countries where mobile 'phone coverage is still very poor, conventional "radio" can be the answer.

Much of this page is still aimed at the amateur enthusiast, but some will be of use to others also.

Robin Lovelock, Sunninghill Systems. August 2011.

GPS, WSPR and robot boats ...

from Robin on 1st August 2011:

Those words in the introduction above have not changed much since I put them up in 1999. More recent visitors to gpss.co.uk will know of my interest in silly GPS-related hobby projects, such as tracking GPS bottles in the sea, or the one which has become almost an obsession for over three years - the robot boats. Don't miss the "Snoopy Sails!" video :-)

Roger and I have just had a chat about the possible application of WSPR ( Weak Signal Propagation Reporter ) as a low cost solution to track robot boats: maybe lower cost than the more obvious SPOT or Iridium satellite based solutions. Robin has never been a licenced radio amatuer (HAM) and this will not happen. After the chat with Roger, it seems that a low cost WSPR solution is probably doable, but this would need to be operated by a HAM, using his own callsign.

Robin would love to hear from you if you know of a suitable solution, perhaps costing no more than a few tens of pounds sterling, including the GPS (20GBP), and operating from a 5v or 10v robot boat battery-solar cells power supply. Robin's problem is he wants to launch a boat at the end of August - this year ! :-)

You should start by testing GPS-->Laptop PC running GPSS, after downloading GPSS from the GPSS DOWNLOAD Page then register GPSS by following step 2 on this same page. My reply will give you a key code, tips, and information such as change of baud rate. The tips may also tell you who is near you, what mapping to add, and how.

The next step is testing GPS->radio Tx------->radio RX-PC running GPSS, for which you will need a radio modem. But the significant step is when you wish a number of vehicles to report their position regularly, sharing the same radio channel, and with GPSS running in multi-vehicle tracking mode. i.e. each vehicle has it's own symbol on the map.

The best solutions that I've seen so far are from Klaus Hirschelmann in Germany - you may contact Klaus and his web site via the KLAUS Gadgets Page . However, any person with some knowledge of electronics and digital technology should be capable of making similar devices.

These "intelligent radio modems" permit any low cost GPS to be interfaced to a radio, so that the GPS data is transmitted in a "time slot", permitting several vehicles to share the same frequency. They do a similar job to the APRS solutions discussed further down this page, but make use of an "open" protocol, based on the NMEA standard.

They might typically extract the $GPRMC sentence from the stream of NMEA sentences output by the GPS at 4800 baud, modify the $GP to the "Sender ID" for that vehicle (e.g. $01, $02, $AB, $A3, etc), ammend the checksum at the end, and transmit in the assigned time slot, at perhaps 1200 baud, using Frequency Shift Keying (FSK) tones. A matching device is used at the receiver end, to pass the messages into the PC running GPSS in multi-vehicle tracking mode. The pictures above show two hardware products recently sent to me by Klaus. Featured in both pictures is the Transmitter encoder module, which Klaus calls "COD1". Here, on the right, it is shown with a San Jose Navigation GM38 GPS (San Jose are based in Taiwan and a category "A" GPSS Partner ). On the right is Goodmans "PMR Tracker" - one of the lowest cost PMR radios, at only 40 GBP (60USD) end-user price. The top picture shows one of Robin's second hand (100 GBP :-) Laptop PCs, and also shows the De-Coder Module - "DEC1". The picture on the left shows a first range test, with transmitter on roof of the car, driven south, and receiver just 4.7m high, in Robin's back yard. Transmissions were every 2 seconds, so you can see the range extended to somewhere between 500 and 1000 metres. Next time I'll try the receiver on the roof :-)

In a typical "business" multi-vehicle tracking application, there would be more Transmitters than Receivers - hence the logic of not combining both transmitter and receiver functions - to minimise cost.

Note that in many countries, transmission of data over PMR or other radio frequencies may not be permitted, or will require a special licence. However, if the end user is a Government organisation, such as police or military, these things can often be overcome quickly ;-)

Another approach has been used for many years with GPSS: configuration of a "TNC" to preceed the $GPRMC message by text such as 01>GPSS$GPRMC where 01 is the identifier, or "radio call sign" for that vehicle.

Roger, below, used a third approach, of making use of a less "open", but (in the USA and Amatuer Radio circles) more popular APRS protocol. This is discussed in more detail below, and will be of interest to the amatuer users. I've moved this APRS material further down the page, since most new (and all "business") users of GPSS are now using the "open" protocols above.

Roger G7RUH had a Garmin GPS2+ connected directly to a Kenwood TH-D7E handheld radio. The TH-D7E has an inbuilt TNC (radio modem). Roger used his Psion Series 5 Palmtop to configure the TH-D7E to take the standard NMEA strings from the GPS, and transmit these using AX25 amatuer radio protocol to the base. The base was one of the desktop PC computers in Robin's house, running GPSS. We could have used another TH-D7E connected to the serial port, but instead, Roger provided another radio, with it's audio output fed to a Kantronics KPC3 TNC, which plugged into the PC COM2 port, instead of Robin's Internet modem.
Roger and Robin had a walk around Sunninghill village, leaving GPSS to record the received data for later playback. You can see the plots here. GPS SA errors were not that large, so you can see where we went on both the map and the aerial photograph contained in the GPSS baseline software. It was only in the village that we ran out of radio range, despite the fact that the receiver with antenna was simply propped up on the downstairs window ledge. Robin has now erected a more suitable antenna on the roof - following Roger's instructions - and we obtained good signals between our homes, 3.5 miles appart, at only 50mW. Range trials have yet to be done.

The main snag with the current setup is that powering down of the TH-D7E results in it losing the settings set-up with the Psion. However, the required software is now available - see MICE.EXE below - to decode the MIC-E compressed position data which comes out of the TH-D7E or KPC3 by default. This means the hardware can be used immediately - without the need to be setup using the Psion or some other Terminal Emulator. If you want to contact Roger, you can use the e-mail link on list "C" of Partners

Robin had been involved with military radio communications, on and off, since he worked as a programmer-analyst in 1970, implementing the Royal Navy VHF tactical data links, and then in the late 1980s, as a manager, on systems for the British Army which employed Combat Net Radio. This included development of packetised protocols for exchanging data over military radios. The DOS prototype of GPSS was running in 1992, and this linked GPS-PC, both in-vehicle and man-pack, with military radios, using time division access protocols syncronised by GPS. See History and the Barossa Operation

In 1995, GPSS - a Windows application, appeared with SSDEMO (the DOS Prototype) on UK Television, in it's in-car navigation role. The first version of GPSS was released free to the UK Public on PC Magazine CDROMs that summer of 1995. Over 2 million copies were distributed in this way over the next 3 years. The first GPSS contracts, in 1995 and 1996, were used to add capability to the core GPSS.EXE product. One of the first contracts was for GPSS to be used for remote tracking via military radio, in a Demonstrator for RACAL Communications in Bracknell. Other contracts, such as that for a UK Police Constabulary, funded extention to multiple vehicle tracking, two way messageing, and Inmarsat-C satellite communication. In later years, other UK Police contracts funded additions needed for covert tracking using GPS and Mobile Phone Communications GPSS found its way onto exhibition stands, either because mapping on PC was novel at that time, or because it was part of a Prime Contractors solution. One example was the Battlefield Electronics Exhibition at DERE Chertsey, where several contactors, including IBM, demonstrated GPSS.

Over three years ago, GPSS was made available from this web site, and rapidly spread to other countries (although a few individuals in the USA, South Africa and elsewhere had heard about GPSS and purchased copies on floppy disk a year or two earlier) Changes were put in to recognise the callsign information, in response to requests from radio amatuers, using GPSS with a TNC, in Australia. Not long after, GPSS was being used in many countries in this way. In 1999 the first radio based (rather than satellite or mobile phone based) GPSS (contract) system went operational - this permitted a small fleet of 5 buses to be continuously tracked by radio.

The vast majority of people using GPSS with radio are currently 'enthusiasts' - although this may change if good, low cost, hardware solutions become available: not all countries have good mobile phone coverage - and some applications favour a radio 'broadcast', rather than 'point-to-point' communications approach.

To contact Robin, visit the CONTACT Page.
(If you have not already, Robin will ask you to download GPSS and answer the Quiz on the GPSS Download Page He gets a lot of e-mail, so has to prioritise his time with those with a serious interest in GPSS)

Since you are reading this, you will probably also have an interest in the

Within the amatuer radio fraternity - particularly within the USA - the term "APRS" (Automatic Packet Reporting System) has become associated with a family of software products, and related compatible hardware, for use with GPS and the Amatuer Packet Radio System. The 'Father' of APRS is Bob Bruninga, WB4APR, who retains the Intelectual Property on these APRS products.

APRS® is registered to Bob Bruninga, WB4APR. Mic-Encoder™ is a trademark of Bob Bruninga, WB4APR. Parties interested in commercial development and commercial sales of the MIC-E both within and outside of the amateur community should contact APRS Engineering, whose address is: APRS Engineering LLC, 115 Old Farm Ct, Glen Burnie MD, 21060, USA.

Roger has recently purchased some of the small MiM modules from APRS Engineering, and so we expect to report trials of this with MICE/GPSS in the near future. The MiM supports interfacing of a GPS via Microphone and 'Press To Talk' switch, and implements MicE Protocol.

Bob has kindly given Robin permission to release MICE.EXE as 'freeware' from this web site, without strings attached. This means that hardware from APRS Engineering, such as the MiM, with embedded MicE protocols, can be used with GPSS.

This interfacing of MicE with GPSS has been done by using a small 'driver' program called MICE. The prototype is described in more detail below.

Currently MICE.EXE is intended 'for test and non-business use only' to trusted individuals who have the required facilities, including a GPS and a registered copy of GPSS (see the download page for details of free registration). The latest version of MICE may be downloaded from this web site - see below.

The above picture shows an earlier version of MICE being tested with GPSS v4.91, before being hidden behind the GPSS display. Armitage Court in Sunninghill is marked by the blue diamond in the centre. Roger's house, 3.5 miles west in Bracknell, is marked by a diamond. The test data is decoded into a position marked by the white cross-hair near Roger's Home.

MICE.EXE is put in the same directory as GPSS.EXE. MICE takes Mic-E data from the TEST button, or from the PC COM port (with a TNC connected), decodes the data, and creates a $GPRMC message which is passed to GPSS.EXE via two text files, GPSS.LLD and GPSS.LLF.

After at least one test or real message is processed, there will be a copy of GPSS.LLF, and starting GPSS will make it read data from GPSS.LLD instead of the COM port.

Here is a brief description of the MICE display (subject to change, with later versions of course): Time is displayed, followed by the 'TEST' button. Each click of TEST injects the next of 14 'canned' sets of Mic-E data from within MICE.EXE. The next two yellow boxes are setup to specify the text that will appear at start and end of the Mic-E message. This is a crude method by which MICE.EXE recognises and buffers the incoming message (we expect to employ a neater solution in future). The next two controls enable the user to specify the TNC COM port, and the OPEN button should result in the port being opened, and TNC data flowing into MICE.

The next two white boxes show the incoming Mic-E message, and the result of MICE decoding it into a $GPRMC message written to GPSS.LLD for GPSS.EXE.

The green light on the low left shows that the GPS data was good. It goes red if you put your hand over the GPS. This corresponds to the ",A,"/",V," field in the $GPRMC message.

G7RUH-9 in the white box is the call-sign extracted from the message. In the example above, MICE/GPSS are operating in single vehicle tracking mode. For multivehicle mode, GPSS needs the $GPRMC message to be preceeded by the callsign, and the callsign flag (e.g. >GPSS or >APRS). The callsign flag text defaults in GPSS to >GPSS, but can be configured to any text with CALLSIGN.CFG. So if >APRS were put in the yellow box, the output from MICE would be G7RUH-9>APRS$GPRMC...etc. GPSS would be configured with GPSS.MCV to translate the callsign G7RUH-9 into whatever 'user callsign' text and displayed icon was required for the application.

The "Logging OFF" button toggles logging of data into a text file to assist in debugging of MICE (yes - we think there are still a few bugs in MICE - even after a few hours work 'from scratch' :-) The LD control is normally blank. It is there to permit the user to overide MICE with the Longitude Degrees value of 3 digits (e.g. 001) if MICE is calculating the wrong value (should be OK now, see 'bugs' below).

When running GPSS, the MICE display would normally be hidden. Under Windows 95, 98, or NT this can be done with the "-" minimise control at the top. However, under Windows 3.1 or 3.11 this will still result in the MICE icon remaining visible. The 'HIDE' button was therefore provided to completely hide the MICE display.

We will update MICE and/or GPSS in response to feedback from testers, and we hope to put more information onto this page resulting from any discussion with Bob Bruninga and others in the APRS community.

The link below is for those in direct e-mail contact with Robin or Roger. MICE1.EXE is only a few bytes, so will only take a few seconds to download. Put it in the same directory as GPSS.EXE. Run MICE1.EXE from DOS or Windows to self-extract MICE.EXE. Then run MICE.EXE from Windows before GPSS.EXE.

The hardware we are using seems to output data that is different from the Mic-E spec. - so the bugs could originate in MICE.EXE, our reading of the spec., a 'typo' in the spec, or a bug or restriction in the Kenwood software. We obviously expect the bug to be within MICE.EXE, and expect others will soon inform us if it is elsewhere. Right now we have modified MICE.EXE to get good results with our local tests, including some with the GPS in 'simulator' mode, rather than follow the Mic-E spec.

The changes made away from the spec. are as follows:

• Spec. says East/West flag is in bit value 128. MICE tests bit value 32.
• Spec. says 0 = East. MICE says 0 = West.
• Spec. tests for Longitude degrees use 190, 199, 190. MICE uses 90, 99, 90.
• Spec. says if Longitude Minutes >=60 subtract 50. MICE subtracts 60.