I was asked to look into why 1 of 3 parts of data was 6 days earlier than the other 2 parts. Well it turned out to NOT be IGES data – but it was raw binary data dumps from a LiDAR system. The data was Applanix proprietary data format that is likely written the way it is to allow high speed data writing. First, all the data is bound by $GRPXX and $# where XX is a hex group code. To undo all the data and make some sense of the time stamps it took an awful lot of digging. Here are the links and learning I found.

Here is the header data – the $GRP[XX][LL][T1][T2] which $GRP (4 bytes) XX=datatype or group code (2bytes), LL is the packet length (2 bytes), T1 (8bytes double IEEE744 format)  is the 1st time stamp and T2 is the 2nd timestamp (8 byte IEEE744 format) . Here is the hex for this.

2447 5250 0400 3c00 2bca ed97 0928 2241 2bca ed97 2d28 2241

What is most annoying but understandable is that everything is reversed when it needs to be. 2447 5250 = $GRP (not reversed) , 0004 is the group code (note it is reversed) , 3c00 is the length (not sure if it is reversed) 4122280997edca2b is the BYTE reversed T1 timestamp in IEE 744 format. To get the decimal value from the hex- go to this website to convert it (or this) and it is in seconds from the last time the machine was (re)started. To see what seconds might look like in days, hours, seconds – we use this website. To convert hex/bin/dec all ways I used this website.

There is some NMEA GPS and RINEX data embedded but that was not necessary to decompose it. IF we need to convert etc. the data from any of these formats – the teqc tool and RTKLIB will help.

Did you know that there are many time “0’s”? .NET uses Jan 1, 0001, there is Jan 1, 1970, Jan 6, 1980 etc. Weird – check this sites out.  To get time differences – use this website (most handiest of web tools).