Lowrance SLG format?

[erikgreen]

Hello, all;

I'm the owner of a Burton Electronics M1, which most of you know is based on the Lowrance LMS-480 fishfinder sonar.

The computer application that Lowrance supplies for download, Sonar Viewer, is ok, but not a fantastic program. The Yellowfin viewer is much better, for instance, feature wise. I want to either write a file converter (similar to rgecy's work on the Humminbird output) or a viewer program.

I'm looking for someone who has information on the format of the Lowrance SLG files. I've looked at the Lowrance SLG2TXT utility, but it seems to cut out a lot of information from the SLG files when it does a translation.

I've contacted the authors of various programs that can process the SLG files, and so far no one has responded positively.

Does anyone here have or know of someone who has any information on the SLG file format produced by Lowrance sonars?

Erik
erikBLUEBANANAgreendragon.org (replace the blue fruit with an @ symbol)

[rgecy]

I have looked the Lowrance file before and if anyone knows the structure, I could easily adapt my program to convert the format to YellowFin or DeepView viewer.

It takes some time to do comparisons and look at the data to see what is changing.

My first suggestion would be to download a hex editor and look at the files in hex format. What you are trying to do is locate the beginning and end of each ping. I think Lowrance uses a fixed length which will be easy to see. The you will try to figure out what bytes are for what information. This is the difficult part. Now, someone out there I am sure has already done this!

Hopefully we can find out what the structure is and just create a reader/converter from that info.

Good Luck,

Robert Gecy

[rgecy]

After a quickdownload and looking at the file structure, there is an 4 byte file header and each ping is 2000 bytes in length. The 4 bytes { D0 07 00 00} = 2000 which is the length of each ping.

Send me one of your slg files and I will break it down. I have already found the upper limit, lower limit, depth, longitude, and latitude. Some other key fields would be speed, heading, etc.

Give me a few days this weekend and I can create this program no problem!

Robert

[erikgreen]

Got my reply from Lowrance

I got my reply from Lowrance. Worthless. Now I want to find out their file format just because they don't want to tell me, and then never buy any more lowrance stuff.


> The software is proprietary, so we cannot give out the codes, but if you
> go to our website at Lowrance.com and click on downloads, we do have a
> sonar log viewer that will read SLG files. Below is a list of the things
> that you can do with the sonar log viewer. If you have any other
> questions or concers feel free to email or call us.
>

[rgecy]

The format is not like some industry secret. I have downloaded their slg2txt converter and it details the read format. I will have this in no time.

Robert

[gwzd]

I searched through their website but couldn't find the converter. Could you post the link to download it?
thanks
RA

[erikgreen]

slg2txt converter

It's a part of the sonarviewer package - get that and you'll get slg2txt too. Unfortunately the converted text file leaves out quite a bit of information.

Robert, I'm certainly rooting for you. Let me know if/how I can help any, I haven't done any significant reverse engineering in about 15 years though :\

Erik

[rgecy]

Ok, the format is a lot more complicated than the Humminbird, but the code is almost done to read the data from the file. The Humminbird format will just write zero to a byte if the data is not present, whereas the Lowrance format will not write the data at all. So each header is different in length and the data contained in it. They use a unique binary flag to determine what bytes to read and what is valid. Sometime the GPS data is in the header and sometimes its not.

So each header contains this flag. The flag is broken down into a binary number (1's and 0's) that basically is used to determine True or Flase or in other words, if the data is stored in the header.

Once I get past fiddling with that part, the rest is a walk in the park. All the other code is essentially complete.

I spent a number of hours on it the other night, but may not get to it again until Sunday.

Robert

[erikgreen]

Nice

You rock, Robert.

You're bringing back memories of writing a GIF decoder years ago... at least the SLG format isn't compressed, that would be a pain in the butt.

The default output format of your program is .872, isn't it? I'm going to start working on some experiments writing mosaic software and doing some GIS imports, so I'll write some C code to read that. Unless you think another format would be a better place to start?

Erik

[Unregistered]

Data structure

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

[Unregistered]

Aha, OK, I see Robert has come further than I have already

It is a nice problem. Making a universal script is not easy, I think.
It seems a lot of things depend on the sonar models... even the length of the "pings" vary.

- Henrik

[Unregistered]

Did it help at all?

Any progress on the script Robert?
It is truly great work if you find out a simple key for the code!

- Henrik

[erikgreen]

Nice, Robert

I'm watching your work with great anticipation... I've also decided to pick up a Humminbird unit this spring to complement my towfish

I've been starting work on a viewer application that does what I want... it probably won't be as nice as even the yellowfin viewer for a while... but it'll do exactly what I want, and thanks to you I'll be able to read the data files.

Erik

[erikgreen]

Any luck?

Hey Robert - just wondering how your program is coming? Any luck getting the translation to work?

Erik

[rgecy]

I am so close, but just haven't had time to finish. Maybe an hours worth of work left.

I will try to work on it this week if I get the time.

Robert