Hi ! I've set up this page to provide information to those wishing to use GPSS with the GSM Short Message Service (SMS). At least two GPSS PARTNERS (Yuri in Ukraine and Lindsey in Philippines) have been using GPSS with SMS for some time, but the majority of GPSS remote tracking users do not use SMS. Before going into detail on the GPSS software interface, I've included a few general words for those who are still at the stage of deciding if SMS is suitable for their tracking application. Most SMS tracking solutions seem to use their own proprietory message formats, built into the vehicle hardware, and this is why matching interface software must be written. However, it is possible that in the future, this page will permit download of interface software to support particular sets of GPS/GSM/SMS hardware - if the makers of this hardware choose to collaborate. One example is the THURAYA GPS/GSM/Satellite 'phone, which includes the capability to send GPS locations as an SMS message. The same product can be used as a GSM modem, attached to the GPSS PC.

If you do decide to test GPSS with SMS, I suggest you do as follows:

1) test GPS-->Laptop PC running GPSS in it's default in-car mode.
2) register with me, using the Quiz in Part 2 of the DOWNLOAD Page.
3) add mapping and use the tips and support from me.
4) test GPSS remote tracking in simple "dial up" mode as on the CHASE Page.
5) test the GPSS software interface (see below) - or use SMSH :-)
6) implement the required interface software for your hardware - or use SMSH :-)

You have two approaches on writing the interface software:
a) do it yourself, with limited help from me and others, and keep it for your own use.
b) work with me and others to produce "free" SMS support, for upload to www.gpss.co.uk that supports your own hardware and message formats. See the SMS Handler Page :-)

Is SMS needed ?

Over the years I've found that many potential solution providers go for an SMS solution before they have gathered sufficient information about the remote tracking system market. One reason is that they start by thinking of selling a service rather than a solution. Another is that they think of taxi/emergency services/anti-theft type applications, where minute-by-minute tracking may be required.

My experience is that, in most countries, over 95% (maybe 99%) of the systems purchased are haulage fleet operators (trucks and vans) who want to know where a vehicle HAS BEEN every minute of the day, and OCCASIONALY, where it is NOW.

This is often to gather information on the performance and honesty of drivers. Investment of 1000USD/vehicle can often be recovered in less than a year. e.g. 20 vehicles and drivers deployed to fulfill a particular delivery contract. After gathering detailed information, one or two of these vehicles and drivers can be re-deployed.

Their overwhelming criterea is usually COST: aquisition cost (vehicle hardware), and running cost (GSM air time + any "services").

SECRECY is often important. They are often nervous about any other organisation doing the tracking for them: they would prefer to do it themselves, with their own system.

So in summary: select the right solution for the application. A good application for SMS might be minute-by-minute tracking of a fleet of taxis. Other applications, such as road haulage, might benifit from "intelligent" GPS/GSM hardware that stores minute-by-minute movement of the vehicle, for access from the base PC when needed.

You will need a GSM Modem

Simple "dial-up" use of GPSS can be done using a normal modem, such as that found on any Internet-capable PC. However, access to GSM SMS messages requires a GSM modem to be used. There are many alternatives for these, including products from Siemens or Falcom in Germany, or Wavecom in France. See "components" on the CHASE Page.

GPSS Software Interface: GPSS.LLD/LLF

Messages can be "injected" into GPSS from another DOS or Windows application, running in the same PC, which handles the (GSM) modem, and translates the incoming SMS messages into one of the standard formats recognised by GPSS.

Format of message injected into GPSS

The best, and perhaps the simplest format of message for injection of GPS location and velocity into GPSS, is the standard NMEA $GPRMC message, as it appears direct from the GPS:
e.g.
$GPRMC,113248,A,5130.78,N,00013.51,W,54,030,280601,,*33

In a typical application, there will be more than one vehicle being tracked. The incoming messages will therefore need to be identified, so that GPSS knows which vehicle symbol and data to update. There are two alternatives for this:

1) Modification of the NMEA "Sender ID" by replacing GP:
$03RMC,113248,A,5130.78,N,00013.51,W,...etc
- where 03 is a two (printable) character identifier.
- note that the checksum at the end should (ideally) be re-calculated.
- source code for this re-calculation of checksum is on the MVTECH Page.

2) preceed the NMEA sentence by callsign information:
03>GPSS$GPRMC,113248,A,5130.78,N,00013.51,W,54,030,280601,,*33
- where 03 is the identifier (callsign) and >GPSS is fixed text.

My guess is that it will only take a good software engineer an hour to implement the required software to inject this format of data into GPSS, IF he is already familiar with handling the GSM modem and the particular SMS messages used.

The GPSS.LLD & GPSS.LLF Protocol

Here is a simple description of the GPSS software interface, which you can test without writing ANY software. i.e. you can set up data with simple file copy commands.

The interface uses the DOS/Windows Files system, and two files:
GPSS.LLD - into which is written the message to be injected. e.g. $GPRMC.
GPSS.LLF - a simple a "Flag" File. ANY data can be written here (e.g. TIME$)

GPSS sees the presence of GPSS.LLF as meaning "data in GPSS.LLD is ready to be read". After reading the message in GPSS.LLD, GPSS deletes file GPSS.LLF

Here is a simple experiment:
Make a file named GPSS.LLD holding this >>>>>
$GPRMC,082600,A,1432.30,N,12100.11,E,30,114,081299,,*28
and make another file named GPSS.LLF holding this>>>>>>>
anything :-)

Put both these files in same directory as GPSS.EXE
Run GPSS - it should think it is receiving GPS data from Philippines :-)
(the data was taken from PHILIPPI.NME file inside PHILIPPI.EXE mapping)

Here is a simple description of the protocol used to pass $GPRMC messages into GPSS.EXE from another EXE (e.g. SMS.EXE) in same PC.

I will call this program SMS.EXE but you would call it something else.

1) run SMS.EXE which writes 2 files (contents not important) GPSS.LLD (data. normally blank or $GPRMC message) GPSS.LLF (flag. not important, but I often write TIME$ for help in debugging) These files must be in the same directory as GPSS.EXE (e.g. c:\gpss)

The program then opens any COM ports and processing incoming messages. converting them to $GPRMC to be written into GPSS.LLD (see below)

2) run GPSS.EXE GPSS will see GPSS.LLF and display on startup message "reading data from GPSS.LLD" (or similar) then NOT open the COM port.

If GPSS sees a file present with name GPSS.LLF it then reads and processes the ($GPRMC) message in file GPSS.LLD it then deletes file GPSS.LLF to show it has read the data.

3) SMS.EXE waits until there is no file GPSS.LLF - means GPSS is ready for data. converted data is written into GPSS.LLD in $GPRMC format. A new file GPSS.LLF is created to say "data is ready to be read"

DOEVENTS can be a useful call in Visual Basic if looping (instead of using Timer) IF LEN(DIR$("GPSS.LLF"))=0 is the normal way of checking GPSS is ready.

Note that GPSS.EXE switches to the GPSS.LLD/LLF Protocol on startup, when it sees the presence of file GPSS.LLF. Important therefore to ensure this file is present when GPSS starts - or GPSS will open a COM port instead.

Handling the GSM Modem

Please remember that the information below is NOT based on practical experience of implementing this interface software. It is based upon reading documents, exchanging emails with those who have done it (without breaking confidences), and a few simple tests with the Thuraya 'phone.

Your interface program (e.g. SMS.EXE above), will need to handle the GSM modem attached to the PC COM port. This will probably involve sending some extended AT commands to the modem, to put it into the right state. e.g. AT+CMGF=1 to put the modem into plain text mode. It will also need to monitor the memory inside the modem, to see the arrival of incoming SMS messages.

This monitoring of memory might be done with the AT+CMGL=? command. SMS messages that are in memory might then be retrieved with an AT+CMGR command. After retrieval, you will probably need to release memory using AT+CMGR to delete the SMS message.

What you do to process the retrieved SMS messages will obviously depend on the format of these messages, which may be proprietory and peculiar to the particular vehicle system. If you have vehicles fitted with hardware from different suppliers, you will need to process each incoming message in the appropriate way.

When you have extracted important information from the message, such as lat/lon location, identifier, and perhaps other information such as velocity (speed and direction travelling), then this can be converted into a $GPRMC message, to send to GPSS.

The above was written over a year ago - we now have some free software (when used with GPSS) available for test. See section below.

SMSH.EXE - SMS Handler

Please visit the SMSH page.