Garmin .ADM file format

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Garmin .ADM file format

bryan.cebuliak (Bugzilla)
I am working with a Garmin GPSmap 5012 on my  Linux box attempting to upload some Lowrance USR and other formatted waypoint files to  the machine.  Currently  there is no easy format conversion software available for this  situation. 

Alan Murphy at GPS Utility  has  broken  the  .ADM binary format code. But  it is a painful conversion process to use  his  software via   Wine,  etc.

I  have  no  experience  with reverse   engineering, but if  I  can  be  guided I  am   willing  to  help  with producing the  binary .ADM files  from the  machine from known  example  data  or  whatever it  takes  to help an expert GPSBabeler make this work.

I  note  someone  on  the  Garmin forum has  had  a look  at  the   binary  format:

I have decoded, to a large extent, the ADM format without the help of Garmin. I can usually import waypoints and tracks and export waypoints. There is a lot of unknowns left to decode, but they do not seem to be very important for reading. There appear to be 2 variations of the file with the main changes being where some of the various sections reside.
To start the decoding, I used a Garmin 5212 chartplotter and Mapsource to create files with known data. First, I made a file with a lat/lon ramp that goes from the minimum to the maximum of each in 10-degree increments. Then, I zeroed the latitude of one of the waypoints and saved that as separate file. I did the same exercise for the longitude and every parameter I could change. Then I take my binary file compare program and identify what bytes changed. This utility flags every difference in the base file versus the changed file. That tells me where the parameter is located and how many bytes it takes. Usually Lat and Lon are encoded as 4 byte integers in Mercator projection form for easy display. You have to decide from the numbers whether they are little endian or big endian and what the formula is for the Mercator projection.
The names and descriptions of the points are usually easy to see in a Hex editor. I made the lengths of the names the same in the base file and then increased the length of one of the names to see what happened. In the ADM file, the length of the longest name is used as the record name length and shorter names are null padded. The same goes for the descriptions.
There is a 130 byte header starting the file that contains the text: "DSKIMG" and "USERDATA" amongst other binary data.
Then there is a section starting at either byte 1024 (2*512) or 4112 (depending on the variant) that contains the start of some strange counting numbers. These increment every 16 or 64 waypoints. At 1536 (3*512) or 4608 (9*512), we find the mid header: "USERDATAWPT". If the file has no waypoints, then it might contain: "USERDATARTE" or "USERDATATRK" depending on whether or not there is any data in the missing sections. After another 512 bytes, we get the " USERDATARTE" mid section and another 512 more we get the "USERDATATRK" section. Each of these mid sections also contain the number of bytes in the referenced data section.
For the next 235 or so blocks of 512 bytes, each starts with a null character, some space characters and null characters for 32 bytes. The remainder of the block consists of -1s (0xFF).
Next we get to the important data section starting at byte 122880 (240*512) where there is a 78 byte header. This header gives the size of the section, the length of the file, the length of names, and the length of descriptions. There are many unknown fields in this header and it ends with more counting numbers. After the header, we get the waypoint records that are all the same length. They are 24 bytes plus the name and description lengths. The fields are: lat, lon, name, description, icon, unknown, display, depth, temperature, date, and a null terminator.
We finish the waypoint section with the tail end that is: 9 bytes with a check sum followed by 0xFFs filling out the file to the next whole increment of 512 bytes.
If there is a route or track section, they start again on a whole multiple of 512 bytes.

I am anxious to exchange information I have for information filling in the gaps in my understanding of the format. I haven't given you enough information to decode the format without a lot more work. I need data to fill in things like what the bytes in the header mean, how you tell what variant the file is (the GarminDevice.xml file always seems to say: "ADM version 1.1 default"), what the counting numbers mean, and what is critical in writing versus what is not. There are many curiosities like why do they waste nearly 120,00 bytes getting to the data.
Like I said earlier, reading the format is a lot easier than writing it. You can take shortcuts in reading, but not in writing ADM files. To make the job a little easier, I use template files with one waypoint to fill in with waypoint data and other stuff.

Let me know if you are willing to work with me to finish detailing this format.

How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.;262219672;13503038;z?
Gpsbabel-misc mailing list
[hidden email]
To unsubscribe, change list options, or see archives, visit: