Guest jcardana Posted April 30, 2009 Report Share Posted April 30, 2009 I hate to bother anyone with this... I've been through the docs several times, I'm just not getting it. I'm setting up 8 switches to control the lighting (offset 0D0C U8). The part I'm not understanding is using the Mask. Mxxxx: MaskThis element provides a hexadecimal value to be used as a mask on the value selected by an Xxxxx or IXxxxx element. This is most often used to test individual bits in an array of flag bits. The result of an offset value and a mask is the logical AND of the two. Yeah, I don't understand. This element provides or requires a hex value. I understand it to require one. I don't know HEX well enough to know what to use to look at certain bits. I've been through the GFdisplay guide and there's a few references which I used to try to figure this out. 4=X3300 U16 M0100 ; FS LOC acquired 8=X3300 U16 M0080 ; FS NAV CRS acquired 44=X3300 U16 M0002 ;Active Nav1 45=X3300 U16 M0004 ;Active Nav2 The examples in the GFDisplay.ini show M0002 either looking at bit 1 or 4 / M004 looking at bit 2 or 5 / M0080 looking at bit 7 and M0100 looking at bit 8 0 = reserved 1 = good NAV1 2 = good NAV2 3 = good ADF1 4 = NAV1 has DME 5 = NAV2 has DME 6 = NAV1 is ILS 7 = AP NAV1 radial acquired 8 = AP ILS LOC acquired (incl BC—see 10) 9 = AP ILS GS acquired 10=AP ILS LOC is BC 11=good ADF2 (FS2004) 12=NAV2 is ILS 13–15 reserved (hex 8000, or bit 15, the top-most bit in the 16-bit word). I don't understand how M8000 looks at bit 15. I just don't understand the hex sequence between bit 0 and bit 15. Link to comment Share on other sites More sharing options...

Pete Dowson Posted April 30, 2009 Report Share Posted April 30, 2009 I don't know HEX well enough to know what to use to look at certain bits. Time to learn, then, as it is really very very simple. Hex is like decimal, but instead of using 10 digits (0-9) it uses 16 (0-9 then A-F). So each position in a number can be any one of 16 values instead of 10 values. Letters A-F represent values 10-15. Now, in decimal, each digit in a number represents 10 times the next digit. i.e. 123 = 1 x 100 + 2 x 10 + 3 x 1. In hex, because the digits go up to 16, each digit represents 16 times the next digit. i.e. HEX 123 = 1 x 256 (16x16) + 2 x 16 + 3 x 1. Okay so far? That's Hex. Now to bits. In binary there are only 2 digits, 0 and 1. But the principle still applies. Now each digit represents 2x the next one. Remembering this it is easy to see that Decimal Hex Binary 0 0 0000 1 1 0001 2 2 0010 3 3 0011 4 4 0100 5 5 0101 6 6 0110 7 7 0111 8 8 1000 9 9 1001 10 A 1010 11 B 1011 12 C 1100 13 D 1101 14 E 1110 15 F 1111 See how one HEX digit represents exactly 4 binary digits, or bits? That is VERY useful, and why it makes HEX so useful and easy as you'll now see: For a 16-bit value, like offset 0D0C (the lights), there are 4 x 4 bits (4 x 4 = 16, easy). So, these can be written as 4 HEX digits. A pattern of bits like this: 0 0 1 0 0 1 1 0 1 1 1 0 1 0 0 1 would be written in HEX as 26E9, because 0 0 1 0 = 2 (see table above) 0 1 1 0 = 6 1 1 1 0 = E 1 0 0 1 = 9 Now all you need to know is how the bits in a 16 bit value, like 0D0C, are numbered, and you then have the whole story. By convention, bits are normally numbered according to their "power of 2". In effect this means that the LAST bit, the one worth a measly 1, is bit 0 (2^0 = 1). The next one up is bit 1 (2^1 = 2 ), the next 2 (2^2 = 2 x 2 = 4) and so on, up to the first, or "topmost" bit 15 (worth 2^15 = 2 x 2 x .... = 32768). So that hex pattern above, 26E9, which as we saw represents these bits: 0 0 1 0 0 1 1 0 1 1 1 0 1 0 0 1 the numbers of the bits which are set are, from left to right: 13, 10, 9, 7, 6, 5, 3 and 0. Finally, if you ever need the DECIMAL equivalent of such a HEX number, you'd probably do better with a calculator, but the method is: e.g. 26E9 Step 1: 2 x 16 = 32 Step 2: Add the 6 = 38 Step 3: x 16 = 608 Step 4: Add the E (= 14): 622 Step 5: x 16 = 9952 Step 6: Add the 9 = 9961. Answer = 9961. I have to do a lot of such conversions as a programmer, so i use a special calculator that does Hex to Decimal and Decimal to Hex conversions. ;-) I don't understand how M8000 looks at bit 15. I just don't understand the hex sequence between bit 0 and bit 15. Well, I hope that's clear now. If not, then I'm sorry but that's the best I can do. You need a basic guide to computers. Regards Pete Link to comment Share on other sites More sharing options...

Guest jcardana Posted April 30, 2009 Report Share Posted April 30, 2009 Wonderful explaination and thanks for taking the time. I'm good up until this part... this is where I get lost. So that hex pattern above, 26E9, which as we saw represents these bits: 0 0 1 0 0 1 1 0 1 1 1 0 1 0 0 1 the numbers of the bits which are set are, from left to right: 13, 10, 9, 7, 6, 5, 3 and 0. I would have thought this... 2 6 E 9 0010 0110 1110 1001 4 64 16384 512 Is the last bit on the right or left? Am I reading this backwards? It just hasn't clicked yet. Link to comment Share on other sites More sharing options...

Pete Dowson Posted April 30, 2009 Report Share Posted April 30, 2009 I'm good up until this part... this is where I get lost. So that hex pattern above, 26E9, which as we saw represents these bits: 0 0 1 0 0 1 1 0 1 1 1 0 1 0 0 1 the numbers of the bits which are set are, from left to right: 13, 10, 9, 7, 6, 5, 3 and 0. How can you get lost here when all we are doing in numbering the bits. the same as numbering houses in a road or students in a line. Look, if I have a 4 bit number: 0 1 0 1 (which represents 5 in decimal), the LAST bit, the 1 at the end, is bit 0, the one to its left it bit 1, the next is bit 2 and the 4th from the right is bit 3. With a 16 bit number, the 16th bit from the right is bit 15 (it is always one less because we count from 0, not 1). I would have thought this... 2 6 E 9 0010 0110 1110 1001 4 64 16384 512 What system of bit numbering are you using which gets up to 16384 bits in a 16 bit vaslue? And goes up and down? Can you explain what those values, 4, 64, 16384 and 512 are supposed to represent and how you arrived at them. you've got me completely lost. i've no idea how you are thinking, even! :-( Is the last bit on the right or left? Am I reading this backwards? It just hasn't clicked yet. What do you mean by "last" bit, exactly? It isn't a very precise term except in an ordered list. The last bit reading left to right is the right-most bit, the least significant bit, or bit 0. I've no idea how you are using your "English" words I'm afraid. Pete Link to comment Share on other sites More sharing options...

Guest jcardana Posted April 30, 2009 Report Share Posted April 30, 2009 I was looking at the values that the set bits represent, I was looking at the bytes, not the bits. I now understand how the bits are numbered, the numbers of the bits which are set are, from left to right:13, 10, 9, 7, 6, 5, 3 and 0. This just threw me off, I though you were saying we counted starting from the left. I'll keep studying to figure out how the mask in GFdisplay is working. I understand it will allow me to look at specific bits within the offset. Link to comment Share on other sites More sharing options...

Guest jcardana Posted April 30, 2009 Report Share Posted April 30, 2009 IT CLICKED!!! M8000 is looking at the 16th bit because... 8 4 2 1 8 0 0 0 8*8=16 and if I wanted to look at bit 5 I would use M0101??? Link to comment Share on other sites More sharing options...

Pete Dowson Posted April 30, 2009 Report Share Posted April 30, 2009 I was looking at the values that the set bits represent, I was looking at the bytes, not the bits. Well, that's not relevant at all to want you want to do in GFdisplay, but if you want that, then this: 2 6 E 9 0010 0110 1110 1001 4 64 16384 512 still makes absolutely no sense. The highest bit, the "2" is "26E9", is bit 13 so, as I so carefully explained, it represents 2^13, or 2 x 213 times. ie. 8192. There are then 2 bits in the next hex digit (the 6), so how do you get 64? Ditto how do you get 16384 for the 3 bits in the 3rd hex digit, "E"? And the last hex digit is 9, which, wonderfully simply, represents decimal 9 too. But you get 512 from somewhere? How? Even if you are reading right to left for some reason, your numbers make no sense. Can you explain them? Like decimal numbers, binary and hex read with the high values on the left, the low values on the right. why would you think everything was reversed in order just because we use a different base? I really cannot help any further sorry. I suggest you get a simple book on computers. Regards Pete Link to comment Share on other sites More sharing options...

Guest jcardana Posted April 30, 2009 Report Share Posted April 30, 2009 I was doing the powers of 2, i just did it wrong... Dec Hex Bin 2^x 0 0000 0000 1 1 0001 0001 2 2 0002 0010 4 3 0003 0011 8 4 0004 0100 16 5 0005 0101 32 6 0006 0110 64 7 0007 0111 128 8 0008 1000 256 9 0009 1001 512 10 000A 1010 1024 11 000B 1011 2048 12 000C 1100 4096 13 000D 1101 8192 14 000E 1110 16384 15 000F 1111 32768 Link to comment Share on other sites More sharing options...

Guest jcardana Posted April 30, 2009 Report Share Posted April 30, 2009 I hate to bother you so much, I don't know why I'm having such a hard time with this. You probably think I'm a moron. But, here's something else I'm confused about. The Programmers Guide states... Offset Size Use 0D0C 2 Lights (FS2k/CFS2), a switch for each one (bits from lo to hi): 0 Navigation 1 Beacon 2 Landing 3 Taxi 4 Strobes 5 Instruments 6 Recognition 7 Wing 8 Logo 9 Cabin According to that, x0D0C should be a type 2 offset. But, according to the GFDisplay manual... S 8: Signed 8-bit byte 1 U 8: Unsigned 8-bit byte 2 S 16: Signed 16-bit word 3 U 16: Unsigned 16-bit word 4 (also 0) S 32: Signed 32-bit double word 5 U 32: Unsigned 32-bit double word 6 F 32: Floating point 32-bit (“float”) 7 F 64: Floating point 64-bit (“double”) 8 STR: Character string (ASCII)* 9 a type 2 offset is a Unsigned 8-bit byte But you wrote For a 16-bit value, like offset 0D0C (the lights), there are 4 x 4 bits Is this messing me up? Link to comment Share on other sites More sharing options...

Guest jcardana Posted April 30, 2009 Report Share Posted April 30, 2009 I doubt you'll read this far Mr. Dowson, but I wanted to say thanks. :wink: Just a few minutes ago time I searched for "GFDISPLAY MASK" and found a post from last year. Enter the wrong keywords and get the wrong answers. GIGO. :roll: It made more sense. You mentioned a calculator earlier... My calc on Win2k has a scientific mode which will convert Binary to Hex To read the fifth bit... I entered 100000 into the calculator and hit the hex button, and got 20, so M0020 now shows me the status of my Instrument lights. So thank you, thank you, thank you for your time and patience. I hope I didn't frustrate you too much. I'll leave you alone for a while, Joe Link to comment Share on other sites More sharing options...

Pete Dowson Posted May 1, 2009 Report Share Posted May 1, 2009 I was doing the powers of 2, i just did it wrong... Powers of 2 apply to individual bits, according to their position in the complete number, the same as powers of 10 applying to decimal digits in a decimal number. For some reason your table lists powers of two for hexadecimal digits 0 - F. Why? One hexadecimal digit represents no powers of anything -- it's just one digit of any hex number, the same as 0-9 are digits in a decimal number! You seem to be wanting to make something very complex and mystifying and completely wrong out of something basic and simple. Please take more time to consider how decimal numbers actually work. Then apply that to binary numbers, where you only have two digit values 0 and 1 instead of 10 (0-9). Once you've got that far, you can simply group 4 bits together to give you hexadecimal. Pete Link to comment Share on other sites More sharing options...

Pete Dowson Posted May 1, 2009 Report Share Posted May 1, 2009 I entered 100000 into the calculator and hit the hex button, and got 20, so M0020 now shows me the status of my Instrument lights. But why not just split the 100000 into groups of 4 bits: 0010 0000 which (as you can see from the first table I gave you) is 20. That's the whole point! Each hex digit represents 4 binary bits, that's all!! Pete Link to comment Share on other sites More sharing options...

Guest jcardana Posted May 1, 2009 Report Share Posted May 1, 2009 I think my expectations got in the way This is all I was looking for... 0000 0000 0001 =0001 0000 0000 0010 =0002 0000 0000 0100 =0004 0000 0000 1000 =0008 0000 0001 0000 =0010 0000 0010 0000 =0020 0000 0100 0000 =0040 0000 1000 0000 =0080 0001 0000 0000 =0100 and I got my self all kinds of confused. Link to comment Share on other sites More sharing options...

Pete Dowson Posted May 1, 2009 Report Share Posted May 1, 2009 This is all I was looking for... But that list is specific for 12 bits. The very first list I gave you is completely general for ANY size - 4, 8, 12, 16 .... 64 bit values, anything! Decimal Hex Binary 0 0 0000 1 1 0001 2 2 0010 3 3 0011 4 4 0100 5 5 0101 6 6 0110 7 7 0111 8 8 1000 9 9 1001 10 A 1010 11 B 1011 Just look up each group of 4 bits. It's so easy! I don't understand why you are still making it more complicated! Anyway, I'm not answering any more here. I've run out of ways of trying to convince you to take the easiest ways. Regards Pete Link to comment Share on other sites More sharing options...

Guest jcardana Posted May 1, 2009 Report Share Posted May 1, 2009 I understand what your saying now. You're right, I made it far to difficult. Thanks for your time. Link to comment Share on other sites More sharing options...

## Recommended Posts

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account## Sign in

Already have an account? Sign in here.

Sign In Now