Lowrance MCC saved data structure.

Here's what I know (and think)

I am working with a Lowrance LMS-525C DF Sonar/GPS Chartplotter Combo. I am attempting to use it for Echo Sounding in an industrial waste pond.

I have analyzed the raw binary slg file produced by this machine in light of the very helpful starting information provided in this forum.

Here's what I know / think:

An SLG file consist of a file header followed by some number of records.

The File Header contains the following information:

Bytes 0x00 - 01 is a 16 bit integer. probably the revision number of the file. (I get 0x0100 for now)

Bytes 0x02 - 03 are unknown to me -- currently set to 0x00

Bytes 0x04 - 0x05 are a 16 bit integer giving the size of any single record within the file. I'm my case 0x07B2 or 1970 (base10) bytes.

Bytes 0x05 - 0x06 are unknown to me -- currently set to 0x00.

Here ends the information to be found in the header for the binary file.


The rest of the file is a sequence of records all having the byte-size given above.

A record has a (short) header followed by the data.

In terms of offsets into a record, A record's header is

0x00 - 01 is unknown to me currently set to 0x00.

0x02 - 0x03 is a critically important 16-bit quantity which enumerates which 'optional fields' are to be found in this record. More on this in a minute. For now, let's call this the "Manifest Variable."

0X04 - 0X07 is a 4 byte float value giving the "Lower Limit"

Here endeth the definition of a record's header.


The Data in a record consists of up to 13 optional fields followed by the ping data. As near as I can tell the optional fields follow the same sequence as in the file created by reading an slg file into Lowrance's SonarViewer.exe and then outputting a CSV (which, in all likelihood, is equivalent to that file produced by their slg2txt.exe utility.) Specifically, the sequence of the optional fields appears to be:

Depth: 4 byte float
Water Temp: 4 byte Float
Temp2: 4 byte float
Temp3: 4 byte float
Water Speed: 4 byte float
Position X: 4 byte Integer in Mercator Meters
Position Y: 4 byte Integer in Mercator Meters
Surface Depth: 4 byte float
Top of Bottom Depth: 4 byte float
Time offset: 4 byte integer
Speed: 4 byte float
Track: 4 byte float
Altitude: 4 byte float

following these optional fields is the ping data.

The ping data consists first of a 16 bit integer giving how many 'listenings' are present in this record, and then of that many unsigned characters (255 to 0 in value) giving the intensity / volume of the sound heard at a particular instant.

Any remaining space in the record is padded with 0x00.

Now, which optional fields are present in a given record? Sadly, I failed miserably in my attempts to logically decipher the Manifest Variable. I can, however, say that in my particular data, the following values have the following meanings (all cases are using 200khz mode for pinging):

Manifest Variable = 0x112C, raw (or 0x2C11 if x-lated to a short int) means
Depth: present
Water Temp: present
Temp2: absent
Temp3: absent
Water Speed: absent
Position X: absent
Position Y: absent
Surface Depth: present
Top of Bottom Depth: present
Time offset: present
Speed: absent
Track: absent
Altitude: absent

Manifest Variable = 0x012C, raw, means
Same as 0x112C except Water Temp absent.

Manifest Variable = 0x146D, raw, means
Depth: present
Water Temp: present
Temp2: absent
Temp3: absent
Water Speed: absent
Position X: present
Position Y: present
Surface Depth: present
Top of Bottom Depth: present
Time offset: present
Speed: present
Track: present
Altitude: present

Manifest Variable = 0x146D, raw, means
Same as 0x046D with Water Temp Absent

(So, o.k., the first nibble, or the first bit of the first nibble, appears to control water temp, but that's the only sense I could get out of it)


Notes and comments:
1. I saw no field for "Upper Limit." Seems to always be 0.000 in the CSV file.
2. I have not exhaustively tested these Manifest Variable interpretations yet, but I'm pretty sure my data only has 4 possibilities. If I find others, I will write again.
3. In the cases of those optional fields that are always absent from my data, I'm only guessing about their place / sequence among the other optional fields. If you find otherwise, please let all of us know.
4. I've glanced at older versions of the slg files, in the form of sample data supplied by Lowrance. They seem to follow the same general scheme with the following caveats:
A. No version number. They seem to begin at the "Size of Each record" value
B. Their "manifest variable" interpretations or implementations seem to be entirely different from Rev 1. Good Luck.
5. Could someone, please, give me a logical explanation for the interpretation of the Manifest Variable in Rev. 1 of the slg file? I'd learn a lot from hearing it.
6. General meanings of each of the fields can be found on page 153 of http://www.twdb.state.tx.us/RWPG/rpg...ationBrine.pdf
7. I wrote, in C++, an importer for the CSV version of the SLG file sometime ago. I also have adequate binary-read facilities left over from my hack on version 3 of Lowrance's USR file. I've begun work on the importer for this binary slg file. It won't take long (so long as I can keep interested. The professional need has passed for now.) If someone has the web space, I'm willing to post the source code when it is done.
8. Why I bothered: The whole reason I chose to hack the slg was because the speed of sound in the industrial soup that we are surveying is more than different enough from that of normal water to make the reported depths meaningless. I'm hoping to read the ping return times from the slg file for a know depth, back-calc the speed of sound from that, and then go on to survey the rest of the lake. Also, the Lowrance seems to have difficulty in depths under, say, 3.5 feet. (and this pond happens to be a generally shallow evaporation lake.) I hope that I can overcome this limitation as well.
9. Comments, questions, suggestion, are welcome.
10. Thanks again for the great starting point. I hope all this is useful to someone else, too.

Looking for the flag....

This is one example where you see the beginnings of 12 Lowrance-pings (each ping has a column)
The ones which begin with 4 have the GPS data in the string, the ones which begin with 1 do not...
-> pings 5,6 and 11,12 have the GPS data.


It should not be impossible to sort out which pings have the GPS data and which do not, and from that get the position data....


1 1 1 1 4 4 1 1 1 1 4 4
44 44 44 44 109 109 44 44 44 44 109 109
236 236 236 236 236 236 236 236 236 236 236 236
70 70 70 70 70 70 70 70 70 70 70 70
17 17 17 17 17 17 17 17 17 17 17 17
67 67 67 67 67 67 67 67 67 67 67 67
72 72 72 72 72 164 164 144 51 51 51 193
225 225 225 225 225 240 240 194 179 179 179 117
108 108 108 108 108 108 108 108 108 108 108 108
64 64 64 64 64 64 64 64 64 64 64 64
122 122 122 122 61 64 122 122 122 122 64 66
113 113 113 113 153 153 113 113 113 113 153 153
104 104 104 104 128 128 104 104 104 104 128 128
63 63 63 63 0 0 63 63 63 63 0 0
230 159 221 98 219 219 230 230 230 168 219 219
179 20 52 244 187 187 179 179 179 147 187 187
65 54 50 57 42 42 65 65 65 69 42 42
64 64 64 64 0 0 64 64 64 64 0 0
250 159 63 228 122 122 206 110 19 179 122 122
0 1 2 2 113 113 4 5 6 6 113 113
0 0 0 0 104 104 0 0 0 0 104 104
0 0 0 0 63 63 0 0 0 0 63 63
96 96 96 96 36 98 96 96 96 96 106 168
9 9 9 9 212 244 9 9 9 9 115 147
255 255 255 255 61 57 255 255 255 255 73 69
255 255 255 255 64 64 255 255 255 255 64 64
255 255 255 255 132 41 255 255 255 255 88 253
255 255 255 255 3 4 255 255 255 255 7 7
254 253 253 254 0 0 254 253 254 254 0 0
255 255 255 255 0 0 255 255 255 255 0 0
255 255 255 255 78 78 255 255 255 255 68 68
255 255 255 255 29 29 255 255 255 255 154 154
255 255 255 255 5 5 255 255 255 255 7 7
228 230 230 231 64 64 232 233 231 232 64 64
184 186 185 187 0 0 187 188 186 188 236 242
150 150 148 150 0 0 151 149 151 153 98 211
136 139 138 138 0 0 140 142 142 145 199 198
125 125 130 124 0 0 129 133 134 135 64 64
124 121 124 118 152 185 125 127 128 128 185 83
126 125 125 119 67 211 125 128 128 126 211 65
122 118 121 111 161 15 116 120 124 113 15 75
108 90 112 103 192 193 93 112 115 96 193 193
89 86 108 104 96 96 101 110 112 74 96 96
61 92 101 104 9 9 98 93 104 91 9 9
57 94 86 95 255 255 88 80 101 98 255 255
81 89 86 81 255 255 84 83 100 79 255 255
105 90 108 90 255 255 94 94 105 90 255 255
109 89 108 93 255 255 87 102 107 92 255 255
104 86 108 80 254 253 75 102 91 100 254 253
81 98 106 60 255 255 80 96 65 101 255 255
88 98 105 65 255 255 78 90 65 96 255 255
95 67 88 72 255 255 73 91 81 101 255 255
89 72 77 79 255 255 75 100 98 116 255 255
79 85 77 77 231 232 87 103 99 116 229 234
61 85 81 88 187 188 92 100 80 111 184 189
73 78 70 99 150 150 84 77 68 96 151 145
82 94 87 103 140 140 66 67 83 79 139 138
83 102 97 107 129 125 85 64 83 91 129 131

- Henrik

A start...

Hello,

I have come quite far in taking the code apart. Hope you will share back your results! It would be great to get a good viewer taking the position and speed into account!

Here goes:

Before each "ping", a string of data is displayed. It is of different length, depending if the GPS position is included or not (GPS updates 1 time/second, but the pings are usually more frequent). I think it can also be dependent on Lowrance product models.

I will list which byte means what (1 byte = 8 pcs zeros or ones) starting from when each new ping is started. This example is a string where the GPS data is included.

Byte 1 = ?
Byte 2 = ?
Byte 3 = depth limit (low)
Byte 4 = depth limit
Byte 5 = depth limit
Byte 6 = depth limit (high)
Byte 7 = depth (low)
Byte 8 = depth
Byte 9 = depth
Byte 10 = depth (high)
Byte 11 = GPS position, mercator meter, y (low)
Byte 12 = GPS position, mercator meter, y
Byte 13 = GPS position, mercator meter, y (high)
Byte 14 = 0
Byte 15 = GPS position, mercator meter, x (low)
Byte 16 = GPS position, mercator meter, x
Byte 17 = GPS position, mercator meter, x (high)
Byte 18 = 0
Byte 19 = ?
Byte 20 = ?
Byte 21 = ?
Byte 22 = ?
Byte 23 = ?
Byte 24 = ?
Byte 25 = ?
Byte 26 = ?
Byte 27 = Time, milliseconds, (low)
Byte 28 = Time, milliseconds, (high)
Byte 29 = ?
Byte 30 = ?
Byte 31 = speed (low), float
Byte 32 = speed
Byte 33 = speed
Byte 34 = speed (high)
Byte 35 = ?
Byte 36 = ?
Byte 37 = ?
Byte 38 = ?
Byte 39 = ?
Byte 40 = ?
Byte 41 = ?
Byte 42 = ?
Byte 43 = ?
Byte 44 = ?
Byte 45 = Ping listening starts, with full volume 255 (11111111), new ping starts after byte number 2450
Byte 46 = 255 (11111111)
Byte 47 = 255
255
255
255
255
253
255
255
255
255
229
185
150
139
127
119
122
120
108
97
101
106
103
89
69
85
89
89
94
90
68

And so on, towards zero as the echo fades, until a new ping starts at byte number 2450

Good luck, best Regards,

-Henrik

[erikgreen]

Ahh, I see

I see Robert bumped the post. Makes sense now. I'll go back to mumbling to myself.

Weird duplicate thread

Boy, it's odd that I posted this same question just yesterday

Here's what I've found out so far: No response from the various authors of programs that do read/convert the SLG format files. Still waiting. I also contacted Lowrance, no response yet.

I had read in an internet post that somewhere there's an academic paper that lists a lot of information about the format of the file, separate from the limited information that the slg2txt outputs. Still looking for the paper, although I've found another couple that reference SLG2TXT.

If anyone here has any information on the file, please post it, as I'm currently stumbling my way through reverse engineering the binary data, and it's a pain.

Erik

[rgecy]

Henrik,

Could you please post the slg structure you have broken down!

Thanks,

RGecy

Lowrance data structure

Hello Tom,

I have broken the Lowrance data structure, but I have not had the time / knowledge to write a nice software to display the files in a more "sidescan"-convenient way.

I know which bits are displaying the position, speed etc. From this, a software could be made which compensates the scan speed to the depth, so that the images are shown in the right scale (no streching, mosaic possible etc.)

Does anyone want to write a software and share it back to me, if I give you the structure?

Henrik

slg data structure

Hi,

Do you have news about the structure of lowrance slg files?
It would be really interesting to write an alternate software for processing sonar recordings.

tanks,
tom

Lowrance data structure

Thanks for the feedback on my question, interesting stuff. I'd be interested in getting a copy of a data file to look at if possible. I have a LCX15MT but I haven't installed a data card or interfaced my GPS to it yet ... and it's cold so the boats out of the water. My email address is:

mark dot munro at ppo2 dot com

What kind of time is available per meg of storage?

Thanks,
Mark

Good question!!!

That was a good question...

Has anyone tried to get out the other data from the Lowrance MMC file???
It cantains the echo intensities and positions for each ping, so it could be nice to be able to unpack all the data and run in a program of your own...

The sonar viewer is quite good, but when displaying the sidescan image recorded with a modified Lowrance it has its problems. It would be easy to build a mosaic-picture of large areas if one could unpack the lot...

Check out one of my modified-lowrance-sss images on the web (screenshot from the sonar viewer) at the following site (wrecksite in Finland)

http://www.hylyt.net/hylky.jsp?view=...strandin_hylky

If anyone has a clue how to do it, tell me!!!

Henrik

Lowrance Sonar Log Data

Yes, GPS position data is imbedded for each sounding in a Lowrance sonar log (.slg) file. You can use the Lowrance Sonar Viewer application to export the raw data (x,y,z) to a text file for import into Surfer.

http://www.lowrance.com/Software/PCS...nar_viewer.asp

This link may be helpful to you.
http://conserveonline.org/docs/2004/...tudy_Final.pdf

Gary

I'm interested to know the structure of the sonar data recorded on a multimedia card in a Lowrance unit. Is each return geo referenced? I'd like to import the recorded data to Surfer to produce rough bathymetry maps.

Mark