Talk:Gillham code

This is the talk page for discussing improvements to the Gillham code article.
This is not a forum for general discussion of the subject of the article.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

The "Altitude Encoder" and "Decoding the Gillham Code" sections

These two new sections really don't make any sense to a lay-reader, they seem to require a whole bunch of background material to be added to aid comprehension first. The lack of refs leaves some doubt as to the accuracy of this as well as it is not verifiable. I had a search for refs but haven't found anything that explains what these two sections really mean. Unless someone with some expertise in this area can add better background and refs I propose they be removed. - Ahunt (talk) 14:55, 6 December 2010 (UTC)[reply]

Is it actually different from the regular Gray code used to encode 100ft increments? The description implies so, but its not apparent from the data table allegedly coming from the spec. If its exactly the same code (the article says its modified, but I couldn't figure out how), then encoding/decoding discussion is irrelevant and can be removed. (I couldn't follow it, due to the strange bit naming used.) PaulT2022 (talk) 04:39, 14 August 2022 (UTC)[reply]

Correction: I think the explanation in the article, although somewhat backwardly written, is correct, but I can't help feeling that there's a much simpler way to describe it. PaulT2022 (talk) 05:05, 14 August 2022 (UTC)[reply]

The referenced in the article forum has this post that applies "value -= (((value >> 4) * 6) + ((((value) % 16) / 5) * 2));" after decoding Gray to binary. Assuming the code works (I didn't run it, but tried a few values manually), its much simpler than the article makes it. Following is to the best of my understanding.

The expression above gives y=x*10*16/16 for higher bits, basically thousands of feet.

Its a bit more complicated for lower bits, y=x-x*2/5=x*3/5. What these 3/5 does is "spreading" 10 decimal values along 4 bits in a sort of alternative BCD encoding. I suspect the main reason why standard BCD isn't used is to prevent jump from all ones to all zeroes when encoder for 100th of feet completes the circle, it likely was designed with two scales/encoders similar to a mechanical altimeter.

The encoding process simply "multiplies" 100th of feet times 5/3 for the lower four bits, so that Gray code never makes a 'jump' from 9 to 0, which will result in erroneous readings a mechanical encoder would produce while switching. Thousands are likely encoded sequentially, so that's never an issue and a regular Gray code is used for them. The encoding to Gray code is done so as to make -1200 ft the lowest possible code, in other words, 1300 ft are added to the actual reading (as 0000 is unused).

There's nothing else to it. No 500ft increments, no parity checks, no reversal of code. I wonder if a source can be found to correct the OR present in the article. PaulT2022 (talk) 07:30, 14 August 2022 (UTC)[reply]

Thank you for your analysis Paul. The presented algorithm has bothered me for the longest time, and there is indeed a better way of thinking of the data. You were close, except that the encoding process does not seem to be that easy. As we are dealing with integer division, and thus losing any remainders, we cannot interpret encoding as being multiples of 5/3. I did manage to get it to something that requires far less conditionals, but I cannot manage to figure out a way to encode values 1-10 so that they would come out as 1, 2, 3, 4, 7, 8, 11, 12, 13, 14, at least not without conditionals. Here is what I came up with

var a = (alt / 100) + 12

var thousands = a / 10

var hundreds = a % 10

if (hundreds >= 4)

hundreds += 2

if (hundreds >= 8)

hundreds += 2

hundreds++

return binaryToGray(thousands << 4 | hundreds)

Artur.sidorowicz (talk) 19:07, 25 October 2022 (UTC)[reply]

Thank you Artur! I assumed the encoders (originally) used a mechanical encoder producing the Gillham code (modified decimal encoding + Gray) from altimeter sensor position directly, so there's no multiplication or division as such at encoding stage and it's possible that no algorithm that would be simpler than a truth table exists for encoding. Decoding values as described seemed to produce correct numbers without dealing with remainder, but I may have missed something.

My main point was that the encoding likely was designed to prevent a rotary mechanical encoder's contacts going from 1101 to 0000 (9 to 0) as would happen with the regular Gray code as it'd cause spurious readings on switching (if it's not the reason, why would anyone use the Gray code in the first place?), and so it skips some of the 16 possible values to encode ten 0 to 9 possible values as ten different numbers from the 0 to 15 range; there may not be an exact mathematical operation to encode it as using Gray code strongly suggests that the encoder wasn't expected to produce a "regular" decimal reading.

With regards to the article, I think we could make a general statement that Gillham code is a special decimal code encoded with Gray encoding as there's a source for this (see the Google Books link). In terms of practical implementation, the current ICAO spec provides a truth table rather than the algorithm, so probably best not to publish any algorithm in the article. PaulT2022 (talk) 20:53, 25 October 2022 (UTC)[reply]

Origin of name

It's always interesting to learn about the history of a name.

An older 2009 version of this article had a section where it was claimed that the code was named in memory to someone named Ronald Lionel Gillham, presumably a UK representative to the IATA committee, who died in 1968 ([1]). It was (rightfully) removed for being unreferenced in 2011 ([2]). The article meanwhile demonstrates (supported by many reliable references) that the term Gillham code was already established in 1962, although apparently still relatively new at this time.

Since it is always possible that information gets condensed and dates mixed up in personal recollections after so many years, perhaps the bottomline of that story is just that someone named Gillham, who happens to have died in 1968 (possibly an important event in the life of the originally reporting WP editor?), was involved in the definition of the code a couple of years earlier.

While it may be difficult to find references directly supporting the statement, perhaps we can at least find sources indicating that someone named Ronald Lionel Gillham died in 1968 and/or was a UK representative to one of the commitees involved in the late 1950s or early 1960s?

--Matthiaspaul (talk) 10:47, 23 May 2018 (UTC)[reply]

I found some biographical info bits on someone named Ronald Lionel Gillham in another WP article. While not about the code as is specifically, the pieces fit together good enough to at least make the good faith assumption (WP:AGF) that the core of the original contribution was not made up (although, perhaps, slightly confused in the chronology), that this is about the same person, who actually lived in the relevant timeframe, worked in this topic area and was influential enough that the code could have been actually named after him. Hence I reincorported some of the previously removed info, hoping that these new anchors will help to find further background information and proofs. Some bits (the family dinner story, and his sudden death in March 1968) are still left commented out until more information can be found on this.

--Matthiaspaul (talk) 20:11, 5 March 2020 (UTC)[reply]

In further assuming good faith I restored the family dinner story and Gillham's date of death as a footnote (that is, not into the body of the article). Hopefully, this will make these two still unsourced but not implausible claims more visible (in a way not as problematic as in the body of the article) to find more readers (possibly from the UK, and with access to archives) who could be able to find reliable references for these two statements. --Matthiaspaul (talk) 07:30, 16 August 2020 (UTC)[reply]