The usefulness, requirements and design of intercepting GPS data streams.
Background
With the trend where cell phones have become an important and integral part of our live, the cell phone will have a GPS receiver in the near future (or may be connected to via Bluetooth). Whether the requirement is for clandestine monitoring of a GPS’s current location, or a commercial tracking system, the ability to remotely monitor a given device is achievable. To such an extent that more than one device can receive data from a central GPS that acts like a server.
This article will look into the architectural design of a system that facilitates for the reception of remote GPS data via a network. It is not intended as a complete specification, neither is code available.
Systems that might qualify as candidates for this technology can include anti-theft devices, mobile beacons, search and rescue, fleet management and of course people and pets as well.
Requirements
Broad requirements for the implementation of broadcasting or receiving GPS Data Streams:
A GPS receiver, physically connected or disconnected, but able to communicate to a computer.
Two Computers (server/client), Single Board Computer, PC104, PDA, Cell phone, Laptop.
Connectivity radios (WiFi, GPRS, Bluetooth, 3G, 4G etc.) for both the server and client.
Navigation software for the client receiving the stream.(Navman , Pocket streets, Microsoft Maps)
Optional navigation software for the server sending the stream.(Navman , Pocket streets, Microsoft Maps)
The simplest implementation of the system will only require a small WAP/Bluetooth enabled cell phone and a Bluetooth GPS.
Conceptual Design
The following diagram illustrates the subsystems and relation to each other, with an explanation below. Click on the image for better quality.
Explanation
The GPS receiver connects and sends data to a COM port as usual, but instead of the Client GPS software a server application connects to the port and reads the GPS stream. This application acts as a splitter, broadcasting the data to the original GPS client software on the server system and sending the same data over a network LAN/WAN to a remote IP address.
The splitting (duplication) of the stream is only necessary if a client on the server system is connected.
Virtual ports has been originally used to emulate a COM port, this enabled programmers to write test data to software applications that expects hardware to send data to a COM port. The application receiving the data thinks that it is actual hardware sending the data.
This same principal is used to intercept the GPS data and resending it in different directions, while the original GPS software is unaware of the delegation.
The host application(s) on the client system(s) listens on a TCP/IP port for data, and writes any received steams to a virtual port (emulating a real GPS). Normal GPS client software on the same system plots the remote data received.
Notification is discussed in detail later in this article.
Dynamic IP addresses
When the client or server system disconnects from the network, the original IP address used for the transfer of the steam may not be the same any more. This is due to dynamically assigned IP addresses usually used by service providers.
This disadvantage maybe overcome by routing data through a web service hosted on a server with a static IP address, or obtaining a static address for the computer the client system is running on.
Remote notification
In the event of disconnection of either the server or the client, a mechanism is needed for the systems to notify each other of the new IP addresses in effect. This can be achieved via SMS, or email.
Even a normal HTTP web server has the ability to be scripted to display the new addresses of clients that has requested a certain page (excluding of course your own IP). A timer control might come in handy. A simple shift cipher is advisable as well.
When a client disconnects without notification to the server to stop the broadcast, and the IP is renewed by the service provider and allocated to a new computer, the server will continue to send data to the newly connected computer. This new computers firewall will most probably make some noise.
In the event that the broadcast from the server is not stopped, and the service provider does not renew the address, the service provider might mistake our server address as the origin of a DoS attack, since data is streaming into oblivion.
Legal
A legal aspect of the solution is perceived to be only applicable to the monitoring of people. The reason for this is the ability to monitor someone without the person being aware of the fact. Local law should be adhered to in this regard.
Conclusion
A simple system with wide application that can be implemented in small embedded appliances. Levering the usage of the internet, the data can be retrieved literally anywhere.
Links
http://blogs.msdn.com/coding4fun/archive/2006/10/31/912287.aspx
http://www.developerfusion.co.uk/show/4798
http://www.dotnet247.com/247reference/msgs/50/254910.aspx
http://www.downloadjunction.com/product/software/114107/index.html
https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=165325&SiteID=1
https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1664678&SiteID=1
http://franson.com/gpsgate/guide.asp?section=NetworkShare
http://www.kbanswers.com/viewtopic.php?t=12906
http://www.peterfoot.net/BluetoothSocketOptionsOnWindowsXP.aspx
http://port-forwarding.qarchive.org/utilities.html
http://www.serial-port-communication.com/virtual-activex
Tags: GPS DataStream Intercept Mobile Client Server Split Com Port
