Deciphering data from a device

AAyAAD/

Looks a bit like Base64 encoding. This also uses A?Z, a?z, 0?9, "+" and "/". I tried a standard Base64 decode on your sample and the output is non-ASCII with lots of null bytes, so I suspect it's a dump of binary records.

Certainly not impossible, the Enigma code was probably a lot harder.

In message , windsurfing snipped-for-privacy@yahoo.com.au writes

Post it as a binary, e-mail it to me if you prefer.

How about posting it as hexadecimal? That's a common ASCII-postable and human-readable 'standard' for memory dumps such as this.

One common method that is used in these kinds of dataloggers is to use two types of binary records. At the start of the log there is one large record that contains the time, date, starting position, etc. Following that, there are smaller records that only contain the difference from the previous record. I noticed that the first 23 bytes of your sample don't contain any AA records. ;)

Not impossible, but can be quite tedious if the record length varies dynamically. I'm assuming you already have something that can decode and display this data. Try feeding it some of your own data and see what it displays. You can create your own data by modifying one or more bytes in an original data file. Hopefully there's no CRC on the file.

.......

Better still have the known text display like above save details of both formats (even if you have to manually create a text file).

Then get the unit to save one more value and save the two formats from the new recordings.

Then compare the files to see what happens and you can learn more that way, including about CRC or checksum. You can see how much is added for each record stored and work from there.

Thanks guys -

I'll have a go at base64 decoding it and looking at it to try and find areas of repetition. Given the month and year of the date is the same I suspect that I can find the length in bits of each logged point, assuming of course that this is how it works. I'll post my results shortly.

Stewart