Taking it at your word that documentation cannot be obtained, that leaves reverse engineering the data.

There's not that much to the packet, so most of it can probably be guessed based on what data you expect to be provided.

• Id? (Serial number?)
• Timestamp?
• Longitude?
• Latitude?
• Altitude?
• Speed?
• etc

Things to know:

• Learning how integer and decimal numbers are stored by computers (2s complement and floating point) would be useful.

• Familiarity with different representations of longitude and latitude could be useful.

I was about to say that reverse engineering data is possibly more art than science, but that's not true at all. To reverse engineering data, apply scientific principles:

1. Create a hypothesis as to the value of a byte or collection of bytes.
2. Devise an experiment to prove the hypothesis.
3. Execute the experiment.
4. Rinse and repeat.

Things to look for:

• Which numbers change as you move the unit? That could be the coordinates.

• Are some number ever increasing? Then it's surely a counter, maybe a timestamp.

1. post the Perl code of your UDP server.
2. post the details of the GPS unit (make, model, link to online docs, etc.)
3. most importantly, post a *useful* output example. Perhaps by writing the "results" to a file, and then running `hexdump` or `od -t x1` on the file, and then posting *that* output, inside <pre></pre> tags.

I cannot seem to post my reply, just posting this to test.

\Thank you for the quick response.

1) Here is the Perl code I am using:



#!/usr/bin/perl

use IO::Socket::INET;

$| = 1;

my ($socket,$received_data,$peeraddress,$peerport);

$socket = new IO::Socket::INET (LocalPort => '26',Proto => 'udp') or d
+ie "ERROR in Socket Creation : $!\n";

while(1) {

    $socket->recv($recieved_data,1024);

    $peer_address = $socket->peerhost();
    $peer_port = $socket->peerport();

    print "\n($peer_address, $peer_port) said : $recieved_data";

    $data = "data from server\n";

    print $socket "$data";

}

$socket->close();
[download]



2) The GPS unit is made by CalAmp (http://www.calamp.com/products/cellular-a-gps/fleet-tracking-units/236-lmu-1200-gprs). There isn't much information online about it unfortunately.

3) Here is the Hexdump results from one of the transmissions:



0000000 0583 3112 7900 0197 0101 0002 4e01 e6c6
0000010 00fc 0000 0000 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 022c ffd0 2fcd 0f00
0000030 0208 0019 0000
0000035

Additionally if you want to reverse engineering, try to capture subsequent requests and see what changes. If your device is statically positioned the position is not likely to change much - GPS have a jitter - but still you should be able to identify a field or a portion that increments steadily it could be a timestamp or ID which I'd expect both of them to be integers

Okay, okay... maybe we have to “reverse engineer” this stuff, but maybe we don’t.   What does this hardware vendor say about the packets that their equipment is designed to produce?

A quick search for “gps” on http://search.cpan.org certainly points out a lot of material.   (Take no offense at my asking this, but ...) Have you looked at all of this already?   Does any of it apply?

Perl functions such as pack() can make short work of dealing with binary packets like this one ... but of course, there’s no sense in doing anything only to discover that it has already been done.   :-)   And I’m sure that they don’t consider the format to be secret.

(If it comes to that... sure are looking forward to a new CPAN module from you!)