Deciphering data from a device

Hi All,

I have a memory dump from a device which records speeds and times. It stores the following information

Date, Time, Split, Distance, HR etc

28 Nov 2008, 12:01, 2:04, 50m, 155 28 Nov 2008, 12:02, 2:01, 100m, 152 28 Nov 2008, 12:04, 2:02, 150m, 157

What I'm trying to do is to work out how it stores the above in the following memory dump. Or more specifically how to take the below and convert it to the above.

IAgQFwkkNolBSlJEYXSlpQAABlQAAyAAFTMACACSAAAAAAZYAAMgABh3AAgBAAAAAAAFEAADIAAbfwAJAJkAAAAABFYAAyAAFMoABgEIAAAAAAQoAAMgABI1AAUBFAAAAAAEZQADIAARwgAFARUAAAAABAMAAyAAEk0ABQEYAAAAAAPHAAMgABF0AAQBIQAAAAAEEwADIAAT1gAEASMAAAAABBIAAyAAD/ UABAEkAAAAAAOvAAMgABGmAAQBJQAAAAADxwADIAARcAAFASgAAAAAA

+EAAyAAEK0ABAEpAAAAAAPNAAMgABC0AAQBMQAAAAAD1AADIAARhgAEATEAAAAAA9kAAyAAEXEABQEzAAAAAAOuAAMgABDfAAQBNgAAAAADywADIAARCgAEATUAAAAABBkAAyAAD0gABAEzAAAAAAPrAAMgAA
  • ...etc

Notice in the above that there are high incidences of AA etc being repeated regularly. Given that nearly all rows of data will have a common year etc you would expect this to help give it away.

Any takers? Or is this impossible?

Stewart

Reply to
windsurfing_stew
Loading thread data ...

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.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

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

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

--
Clint Sharp
Reply to
Clint Sharp

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

Reply to
Ben Bradley

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.

Reply to
Tom

.......

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.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

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

Reply to
windsurfing_stew

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.