Data storage – The central module (Part 4)

Make your own GPS system with Google Maps!

Please read part 1 to 3 to get the introduction and idea overview.

I assume you would like to have several tracking devices that transmit the position reports to an online server. The server will act as a  central module in the system, which means it collects all data from every tracking device and makes these reports available for other systems or applications to read. Maybe you would exclude the server and transmit the position reports directly from the GPS/GSM devices to the end-users? If you would like every internet-user to easily access your system, you may solve many difficulties to avoid pushing software to each terminal, only let them go directly to your web-server to access information.

I suggest the following few steps in order to collect the data from the tracking devices:

1. Prepare and receive data reports

2. Extract each section of the position report, and make necessary re-calculations

4. Access the database and store the data

You might do all these steps with a Python or Java application. For test purposes you might set up a fixed IP address that all tracking devices connects to, then you might sort each incoming report in several sockets. Off course, you must make the ability to receive 1 or more reports, at the same as you are prepared to receive even more incoming reports. For security reasons you should close each socket after end of report.

Requirements:

Like the mobile module (the GPS/GSM application) you may identify a lot of requirements about an application that initially seems to be pretty easy to make. I think the success lies in your ability to sort these requirements, make them even more clear, and prioritize them. If you imagine the different cases about your mobile units (tracking devices), you see how flexible the applications must be to handle driving into tunnels, power failure, interference, etc.

It is different to make it work in your lab, if you compare it with the real world. Off course, you need to test your system to identify most of the challenges you will meet.

Capacity:

System capacity will most probably be a topic. For this server application I think your requirements about the position report frequency is important. Lets assume that you would like to update the position of each mobile module every 10-15.second, then you can multiply the resulting data-traffic with the number of active mobile devices. Your application and server processing capacity must meet these requirements, unless you accept less report frequency.

Re-calculations:

Why would you need to make re-calculations of your data. You need to know what you are going to do with the data – where is it going to be used? If you would like to present the data in a Google Map, you must understand which format Google is using for longitude and altitude. If these elements aren’t correct you might end up in Antarctica when you should be in New York city. There are a lot of different formats to choose among when presenting a geographic position. Google Maps uses longitude and latitude in decimal-degrees numbers. The mobile module (GE-863GPS) uses longitude and latitude in degrees, decimal and minutes. Re-calculation is necessary, but why can’t it be done in the mobile module application before transmitting to the server? I think you should never process more than is strictly necessary in the mobile module application if you plan to make a system that depends on battery capacity. If you plan to make a portable mobile module you should make the application very simple in order to save as much battery power as possible.

Store your data in the database:

As soon as you have organized you data, you’ll need to store your data in a log file or database. Databases are excellent to store and structure data, especially when you later want to access them with one or several search criteria. In part 3 I presented the different data sections you may make from your GPS tracking device:

(1) the unique mobile identity number

(2) date

(3) time (UTC)

(4) latitude

(5) longitude

(6) altitude

(7) speed (km/h & knots)

(8) course

(9) the number of satellite in view

You may configure a MySQL database that store all these sections, that collect the data from your server application. If using Python you’ll need a Python MySQL update of your version. The image shows an example of a database table based on data from the GE-863 GPS.

  1. No trackbacks yet.

Legg igjen et svar

Fyll inn i feltene under, eller klikk på et ikon for å logge inn:

WordPress.com-logo

Du kommenterer med bruk av din WordPress.com konto. Log Out / Endre )

Twitter picture

Du kommenterer med bruk av din Twitter konto. Log Out / Endre )

Facebookbilde

Du kommenterer med bruk av din Facebook konto. Log Out / Endre )

Kobler til %s

Følg med

Få nye innlegg levert til din innboks.