Re^3: UDP Packet Encoding

\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

Comment on Re^3: UDP Packet Encoding Download Code

Replies are listed 'Best First'.
Re^4: UDP Packet Encoding by mbethke (Hermit) on Nov 22, 2011 at 08:52 UTC
Basically, what ikegami said. Just one frame doesn't help much when reverse engineering this, especially when you don't know what data to expect. Surely there is some software to go with it that displays human-readable data? Check the lat/long/alt values that it reports and try to estimate how much it jitters. From that you can calculate a range of values to expect. Altitude should be easiest as it's most likely a 16-bit integer of meters and you just have to guess little- or big-endian. Lat/Lon could be fixed or floating point. A timestamp should also be fairly easy to spot as it changes by roughly the same amount between two packets. Have you asked the manufacturer at all? Their site is really not very informative but perhaps they're customer-friendly enough to give you the specs.	[reply]

Replies are listed 'Best First'.

Re^4: UDP Packet Encoding
by mbethke (Hermit) on Nov 22, 2011 at 08:52 UTC

Basically, what ikegami said.

Just one frame doesn't help much when reverse engineering this, especially when you don't know what data to expect. Surely there is some software to go with it that displays human-readable data? Check the lat/long/alt values that it reports and try to estimate how much it jitters. From that you can calculate a range of values to expect. Altitude should be easiest as it's most likely a 16-bit integer of meters and you just have to guess little- or big-endian. Lat/Lon could be fixed or floating point. A timestamp should also be fairly easy to spot as it changes by roughly the same amount between two packets.

Have you asked the manufacturer at all? Their site is really not very informative but perhaps they're customer-friendly enough to give you the specs.

[reply]