corrupt SDM file - need help

[el-ninio]

due to a spontanius reboot by our computer, the SDL (logbook) file with about 150 dives that my wife has been keeping is currupt. i think that it still contains most of the data, but the SDM crashes when you try to access it, and we can not get to the data.
I have contacted Suunto, but I suspect I would get very little help from them. Does anyone know of a program that can read and write such files (other then the SDM)? is the format known (I can write a decoder/encoder myself, but understanding the format is a major pain). Has anyone succeded in restoring such a file?

and for the others that are using this program - make backups! The program will currupt the file, and you really, really dont' want to be in my shoes.

[miesemer]

I have been in your shoes twice. I did send the sdm file back to Suunto and they did look into it but were not able to repair it. I ended up with three files for my log book. The two that corrupted were still viewable but not editable.

I thought I remember somebody saying the file is actually a mdb (access) file/format. However, I'm old with a feeble mind and may be wrong.

[maractwin]

If you are using SDM 2.0, then the save file is in Access format. Not for version 1. I haven't been able to decode it at all.

-Mark

[String]

v1 is a non standard file format, only v2 is access.

Unfortunately i cant get v2 working here with my custom built serial interface for my vyper so having to stick on v1.

[el-ninio]

it reads the sdl file, deciphers the info and prints it out. I have to say that if the format of this file is, in any way, a representation of the quolaty of programing done by Suunto then I really should reconsider if I want to trust my health to their programers.

some information about the format:
the file is devided into blocks allighned to a 256 byte limits (i.e blocks start at 256*n and is they have content thats not exactly 256*k bytes padding is added so the next block will start in the right place). Each block starts with the address of the block (unsighned integer), followed by an unsigned short holding the size of the block. after this there is some "magic number" that represets the type of block. I did nost of the work on blocks that contain the dive desctription information, where the block is a serialiazation of a struct kept in the memory, using an annoing format where the memory is written in chancks that look like "number of bytes to copy, payload, number zero bytes to write". You have to have an exact copy of the structure that was used to hold the information if you want to read it. very annoing.

on top of this, it seems that blocks are scatterd in an almost random way. I lost a good portion of the end of the file, and now have many dives I with ocaitional 8 depth mesurements in a sea of missing values.

two other "fetures" I liked where the fact that all information was saved in imperial units, and that some of the fields where saved in a "two-decimal-digit-per-byte" format, where you could read the right numbers from a hexal dump, but have to convert the nubmers in order to use them (for example, the number "19" could be represented by 0x19=16+8=27, and 20 would be represented by 0x20=32)

anyway, I have a program capable of reading most of the information, and would be happy to share it's code if anyone here needs it or wants to play with it. I'm still hopping that the next version of the SDM2.X would be usefull, which would allow me to save the dives is some format that would be imported into the new manager.