The MGL navidata format, explained

1. Overview

A navidata file is a single binary file holding everything the EFIS knows about the aviation world outside your own user waypoints: airports with their runways and radio frequencies, navaids, fixes, airspace and obstacles. MGL EFIS systems load it from the SD card; MGL Central can create, import and edit it.

The file is built for a small embedded computer. Instead of a database, it is a set of sections of fixed-size records, plus small lookup tables that let the EFIS jump straight to the part it needs (for example, “waypoints near longitude 88° W”) without reading the whole file.

The header also has slots for airways, SIDs, STARs and holding patterns, but MGL never defined a format for them. Open-data files set them to zero.

2. Where this description comes from

MGL's written specification is an unfinished draft (March 2014) and is wrong in several places. This description was checked against, in order of authority:

1. Real MGL files (navidataUS.ewd (from Michigan Avionics), navidataZA.ewd (from MGL Avionics), and files re-saved by MGL Central). When the bytes disagree with a document, the bytes win.
2. MGL's “rainier”, the format's author, in the MGL forum thread “NAVIDATA format spec question”.
3. The G4 firmware source, which shows how the EFIS actually reads each field.
4. The draft PDF, “MGL Avionics Navidata file format, version 5”.

Every difference from the draft is listed in section 13.

3. Basics: numbers, positions, strings, dates

4. File layout

Sections appear in this order in files written by MGL Central and by this tool. The EFIS finds each one through the pointers in the header, so the order itself isn't required.

offset 0     +---------------------------------------------+
             | Header                          496 bytes    |
offset 496   +---------------------------------------------+
             | Airport index  (size + 20-byte records)      |
             +---------------------------------------------+
             | Airport info   (frequencies + runways)       |
             +---------------------------------------------+
             | Airspace       (648-tile directory + records)|
             +---------------------------------------------+
             | Obstacles      (grid header + bins + records)|
             +---------------------------------------------+
             | Waypoints      (52-byte records)             |
             +---------------------------------------------+
             | WAT            (361 x 8 bytes = 2,888 bytes) |
             +---------------------------------------------+

5. The three kinds of pointer

A pointer is a number saying where something is in the file. The format measures pointers from three different starting points, and mixing them up is the most common way to produce a broken file.

Waypoint records have one more link, AirportInfoReference, measured from the start of the airport info section.

6. Header (496 bytes)

7. Waypoints

Every point the EFIS can show or navigate to is a waypoint record, including airports and navaids. The airport sections only add extra detail for airport-type waypoints. Each record is 52 bytes:

Waypoint types

What DataField holds

8. Waypoint Allocation Table (WAT)

The WAT lets the EFIS find the waypoints in a longitude band without reading them all. It has 361 entries of 8 bytes, one per degree of longitude from 180° W to 180° E. Each entry holds a count and a start index.

• Waypoints must be sorted by longitude, west to east; equal longitudes are sorted by short name.
• A waypoint's band is its longitude rounded toward zero, plus 180. So 88.6° W (−88.6) is band 92.
• For a band with waypoints, the start index is the position of its first waypoint. Empty bands store 0, not the running total; MGL Central relies on this.
• All counts add up to the number of waypoints.

Example: if band 92 has count 1,250 and start 40,100, waypoints 40,100 to 41,349 all lie between 88° W and 89° W.

9. Airport index and airport info

Airport index

Starts right after the header (offset 496) with a 4-byte number giving the index size in bytes, then one 20-byte entry per airport, sorted by identifier so the EFIS can binary-search it.

Airport info record

Each airport's details: a 20-byte fixed part, then its frequencies, then its runways.

Frequencies follow at the frequency base: a table of 16-bit pointers (from the frequency base), then the records. Each record is the frequency in Hz (4 bytes), a type of up to 4 characters (TWR, GND, CTAF, ATIS…) and a variable-length description.

Runways follow at RunwaysPointer: a table of 16-bit pointers measured from the start of the runway table, then 36-byte records:

Runway designation

For parallel runways the reciprocal swaps L and R: 07L pairs with 25R.

10. Airspace

The world is divided into 648 tiles of 10° × 10° (36 columns × 18 rows, starting at 90° N, 180° W). The section starts with a marker (0xFFFF0001) and one pointer per tile. Each tile holds a linked list of the airspaces that touch it, plus 5° of overlap on each side, so the EFIS only reads the tiles around the aircraft. An airspace that spans several tiles is stored once per tile.

Each airspace record has:

• Fixed part (44 bytes): type, bounding box, pointer to the next record in the tile, pointer to the outline, two frequencies (kHz), upper and lower limits.
• Text: eight variable-length strings: ICAO, name, class, exception, comm name, level, times, weather.
• Outline: a point count, then latitude/longitude pairs. A special point (latitude 200) ends each ring. Arcs and circles must already be turned into points; the format can't store them as curves.

Altitude limits pack a unit code in the low 3 bits and the value in the rest: 0 = surface / unlimited, 1 = feet MSL, 2 = feet AGL, 3 = flight level, 4 = ground, 5 = by NOTAM, 6 = undefined.

11. Obstacles

Obstacles are stored in a grid of 1° × 1° cells covering the area that has obstacles.

• Grid header (14 bytes): version, west edge, south edge, width, height (in degrees), the largest cell count, and a check value 0xAA55.
• Cell index: 6 bytes per cell (pointer + count), row by row from the south-west corner.
• Obstacle records (16 bytes): latitude, longitude, height above ground (ft), height above sea level (ft), kind (tower, wind turbine, building… 0–45) and lighting (0–8). Within a cell they are sorted west to east.

When a file has no obstacles, MGL Central still writes a fixed empty grid (385,580 bytes) with a negative width and height. This tool writes the same thing so MGL Central reads it the same way.

12. How the EFIS reads the file

From the MGL iEFIS G4 firmware source:

13. Corrections to MGL's draft specification