Where are we?
We have studied the Package and Library structures, found the gtsdb.jar and gtsutils.jar to be the fundament of OpenGTS, learned how to configure the system and identified the Database creation and initialization in the Java sources. The next logical step is to look at the communication of Tracking Server with individual Trackers.

Tracking with OpenGTS

Let's recall the mission: Can OpenGTS serve as the platform to implement the Framework to run ROApps for the roaf v.2 ? The RealObject clients should be wrapped around Tracking Devices to receive and transmit information. ROApp server and RealObject clients should become part of one distributed application connected via Java RMI. The distributed ROApp Framework shall not depend on proprietary Tracking Devices.

In a first approach to Tracker - System communication we can identify the OpenGTS server with the two packages gtsdb.jar and gtsutils.jar. Basically every Tracker is a Device sensing its environment and transmitting data by a programmed behavior via a (proprietary) Data Protocol. On the other side OpenGTS provides a standard to store the transmitted data in a well defined Database Model (ERM). Tracking Frontends don't necessarily need to communicate with the Trackers, but rather retrieve the data directly from the Database.

In the ROAF Vision we have initially looked at the NMEA Protocol, which describes information coming directly from the GPS Unit. Vice versa this protocol can only transmit GPS related data and does not define any Events, GSM cell information etc. Since the NMEA Protocol is a vendor neutral standard existing over decades it can be found in many GPS related applications. In OpenGTS the org.opengts.util.Nmea0183 class was already released in 2007 to parse and hold one of the $GPRMC$GPGGA$GPVTG and $GPZDA NMEA sentences. If you have studied the NMEAconverter with the provided NMEA files you can rewrite it to use the OpenGTS class as an exercise.

sentence transmission

This NMEA standard defines twelve specific sentence formats in ASCII for a serial data bus. Trackers provide more than GPS information. A (minimum) Tracking Device can be gereralized to a programmable 'mother board' to control the GPS and the GSM modules. Anyhow we can use the GPRMC sentence to describe the general transmission mechanism via sentences, which holds for all Tracking Devices regardless of the technical protocol.

OpenGTS provides techniques to receive 'sentences', provides a skeleton to implement a parser for every sentence and finally offers methods to store the data in well defined Fields in the Database. Let's look at the anatomy of the GPRMC sentence:

$GPRMC,134030,A,4924.5644,N,00842.8216,E,0.0,191.3,010302,0.2,E,A*1D

For your own Tracker Implementation you first have to take measures to ensure a valid sentence. In case of NMEA (any many other Tracker Protocols) each sentence starts with a $ and ends with a * followed by a two byte checksum. You can find the checksum validation in org.opengts.util.Nmea0183.calcXORChecksum(..) . If the checksum is okay the sentence can be passed to the parser:

GPRMC,134030,A,4924.5644,N,00842.8216,E,0.0,191.3,010302,0.2,E,A

The parser can now switch to case "GPRMC" and split the sentence into information chunks. In this case we are interested in the timestamp (GPS fixtime, logtime, transmission time?) and the (lat,lon) coordinate.

Strings to DB records

The Tracker Sentences can be transferred via different protocols, which basically provide byte streams. These bytes are transferred to a sentence String and you also have to make sure to create the correct types needed to store data. So in the end a String sentence becomes one or more Database Records. For the GPRMC sentence we can identify the GPS Fields in the EventData table (run dbconfig with -schema):

Table: EventData [required]
Class: org.opengts.db.tables.EventData
This table contains events which have been generated by all client devices.
  ## Column        Description    SQL Type      Key     
 --- ------------- -------------- ------------- --------
     :
   3 timestamp     Timestamp      INT UNSIGNED  PRIMARY 
   4 statusCode    Status Code    INT UNSIGNED  PRIMARY 
   5 latitude      Latitude       DOUBLE                
   6 longitude     Longitude      DOUBLE                
     :
   8 speedKPH      Speed          DOUBLE                
   9 heading       Heading        DOUBLE                
  10 altitude      Altitude       DOUBLE                
     :
  22 creationTime  Creation Time  INT UNSIGNED          

So the task is to form the signed latitude and longitude into WGS84 coordinates of Database Type DOUBLE, before writting them into the database. (Note that speed and bearing are implicitly derived from more than one position and don't need to be stored. It is more precise, when you leave it to the GTS to calculate these values as needed.)

In the listing above you can also find a statusCode, which is not really contained in the GPRMC sentence. Nevertheless it is a PRIMARY Field required to store the Record. These Status Codes are part of the mechanism to standardize all events regardless of the Tracker Model. All OpenGTS Status Codes are listed in this pdf document.

Now that we got an idea of what a Device Communication Server does we can look at a first implementation provided with OpenGTS. You won't even need a Tracking Device, an Android Cellphone and the free Android App 'MyLiveTracker' will be used to simulate a Tracker transferring tk102 sentences via tcp.

 

 « Eclipse DC Servers »