Menu Sign In Contact FAQ
Welcome to our forums

KLN94 RS232 output data stream, waypoint names and their coordinates?

10 Posts

I have a KLN94 feeding a KMD550 and two SN3500 EHSIs.

Everything works and the KMD550 shows everything in the KLN94; the whole loaded flight plan, and every waypoint without fail even where e.g. you have SAM both in the UK and Greece.

I have captured the data with Teraterm, from power-on onwards, and a logfile is here. 9800, 8, N, 1. It’s a strange format…

I have been trying to debug an issue with the ADL150 which doesn’t seem to accept the above data (i.e. the FPL IN feature does not do anything). The Golze company says the data doesn’t contain any coordinates, and thus uses a waypoint database in the/each display unit to position them. But I have not updated the KMD550 since 2010 so would expect to see loads of issues by now in European IFR, with names like KONAN being around since forever but others changing frequently. Hence my feeling is that the coordinates must be in the data stream.

The KLN94 can be configured for STANDARD or ENHANCED output and I will check this out, but the more basic point is whether the above logfile contains the waypoint coordinates.

I reckon the sequence

EGKA 22Sÿöw02 SFD [email protected]$^w04TRACA23:w05CMB2E w06VERMA2<w07BILGO16Sw08REM 1FHw09DIKOL1_w10VATRI

is showing the waypoints EGKA SFD RINTI TRACA CMB VERMA BILGO REM DIKOL VATRI and probably not showing encoded coordinates next to each (not enough characters).

Looking in the KLN94 IM I indeed see the STANDARD format not including waypoint data and the ENHANCED one includes them, so how would the KMD550 show the route correctly with a database from 2010?

Shoreham EGKA, United Kingdom

The mystery continues

I created a user waypoint at 50N0E and it shows up on the KMD550 and on the Sandel boxes, despite none of these possibly having it in the database. So the enhanced format is as it should be.

Shoreham EGKA, United Kingdom

Maybe you can decode the format by looking at the description of the ENHANCED RS2323 format on pages A-15 and A-16 in


I did look in the IM, and it doesn’t look like the coordinates are in this data stream. The new logfile with the user waypoint is here.

But they might be in there somewhere… this is in notepad

They must be because the data is definitely from the KLN94 (we buzzed the wire through, from pin 2 of the KLN94, by pulling it out of the panel, the KLN94 has no other outputs (except pin 6 which is a raw GPS one, no flight plan) and the other display devices show the route fine together with the user waypoint shown in the right place.

This is in a proper hex editor

I can’t work out what they mean by “packed binary”.

Shoreham EGKA, United Kingdom

This data doesn’t seem to fit any of the descriptions in the KLN94 IM. Clearly, there is a sequence of repeating data fields identified with “w”, but the format doesn’t fit either the definition of either the standard nor enhanced RS232. In the enhanced format there should be 17 bytes of data but there are only 13 here. The description of the standard format doesn’t make sense — it seems like a major mixup, possibly copy/paste error.

Also, according to the IM page A-11, the data should be sent in blocks beginning with ASCII STX (hex 02), but I can’t see any such characters in the dump.

The description in the IM is very sloppy. E.g. on page A-11 they are abbreviating ASCII End of text character with “STX” in two places!

Last Edited by Airborne_Again at 06 Mar 16:09
ESKC (Uppsala/Sundbro), Sweden

It is possible there is a data capture issue at my end. However I can’t see any config in Teraterm; just this:

However in the log file form they have this

If you select this option, received characters are written without any modifications. Otherwise, new-line codes are converted and escape sequences are stripped out.

Whoops… I did notice CRLFs appearing on the terminal window but the logfile has none.

I will have another go this week But currently it does still point to the ADL150 not picking up the data stream, for whatever reason.

Shoreham EGKA, United Kingdom

Peter wrote:

If you select this option, received characters are written without any modifications. Otherwise, new-line codes are converted and escape sequences are stripped out.

Whoops… I did notice CRLFs appearing on the terminal window but the logfile has none.

Yes… Your hex dump does not include any ASCII control characters (00-1F) except newline (0A) — that suggests such characters are stripped.

The lat/long for Shoreham is N50°50’08" W000°17’50" (N50°50.13’ W000°17.83). According to the KLN94 IM, this should be coded as 32 32 08 00 11 53. Stripping control characters you get 32 32 53, which is exactly what follows the five-character string "EGKA " in your hex dump!

So it appears certain that the software you use to record the data stream strips out control characters, rendering the data useless.

ESKC (Uppsala/Sundbro), Sweden

New (binary) file is here.

It should now be OK but apparently the last waypoint of the route doesn’t contain the coordinates so the ADL would reject it. However the various devices show it OK, so that is another mystery. The last WP is always an airport and it is conceivable that can come from a database, but I recall, c. 2003, flying to LEAX which back then was not in the KLN94 so I created a user WP and got there OK with it showing correctly on the KMD550

A quick look suggests the stuff after LFLP changes late into the file, presumably when the GPS fix is obtained. How strange! That however correlates with my observation that the flight plan details (distances, ETAs etc) don’t get filled-in until a GPS fix is obtained. That is as expected. In this case the plane is in a hangar so the acquisition delay is much longer than normal.

This logfile starts with a long portion where there was no GPS fix. Then I restarted the KLN94 and after a while the sat geometry improved and it got a fix.

Shoreham EGKA, United Kingdom

The 10 bytes after LFLP don’t vary. It is only after that it provides your altitude and lat/lon.

After LFLP we have 20 2D 37 55 00 06 06 27 00 20 everytimes.
A space to pad the waypoint name to 5 char
0×2d = 45 => 45 deg north
0×37 = 55 = 55 min
0×55 = 85 = 0.85 min = 51 sec
0×00 E
0×06=6 = 6deg
0×06=6 = 6 min
0×27 = 39=0.39min =23 sec
0×00 and 0×20 is the variation

So N45:55:51 E006:06:23 which matches with Annecy’s ARP

But that doesn’t explain why the ADL isn’t happy

Nympsfield, United Kingdom

This has now been sorted. The latest firmware update on the ADL150 works fine with the KLN94 data stream

Shoreham EGKA, United Kingdom
10 Posts
Sign in to add your message

Back to Top