Hey,After nearly 6 hours of trying this and that, I am baffled.It would seem that the ADF_NEEDLE is supposed to provide a negative value to which you can then add 360 to get a relative bearing. If we call 12 o'clock zero degrees relative, I'm thinking of this relative bearing being where the needle should point, no matter the position of the compass card.But seems no matter what I do, my needle just reads zero (0).What is wrong with my code?FLOAT64 FSAPI AdfNeedle_cb(PELEMENT_NEEDLE pelement){ static FLOAT64 rel_bearing; rel_bearing = (pelement->source_var.var_value.n && 0x1FF) * 360/512; return rel_bearing;}#pragma region ADFNONLINEARITY adf_nonLinearity[] = { { {128, 51}, 0, 0 }, { {204, 128}, 90, 0 }, { {128, 203}, 180, 0 }, { { 53, 128}, 270, 0 }, { {128, 51}, 360, 0 }};MAKE_NEEDLE( adfNeedle, BMP_NEEDLE_ADF, adf_Knob_List, adf_needle_fail, IMAGE_USE_TRANSPARENCY | IMAGE_USE_ERASE | IMAGE_USE_LUMINOUS, 0, 128, 128, // Needle center on BG 79, 9, // Center position on Needle ADF_NEEDLE, AdfNeedle_cb, adf_nonLinearity, 6)PELEMENT_HEADER adf_Needle_List[] = { &adfNeedle.header, NULL};#pragma endregion /*NEEDLE*/And as a side question, is it possible to not have a NONLINEARITY? I was hoping that given 12 o'clock is the zero position that I might not need one.Thanks for your input.

var_value.n is a double. Masking bits won't do anything usefull.Hope this helps!

Try this:FLOAT64 FSAPI AdfNeedle_cb(PELEMENT_NEEDLE pelement){ VAR32 rel_bearing; rel_bearing = (pelement->source_var.var_value.d && 0x1FF) * 360;return (FLOAT64)rel_bearing/512;}And no J-L, I'm pretty certain your post was of zero help.

Wow Ed! you can't resist can you? :) I was sure you knew masking bits of a double number was useless indeed, especially in light of your 20+ years of coding experience you mentioned several times in this forum. No problem with me, I'm all ears from the expert, especially when they make fool of themselves in starting personal flame wars in developper-sharing-helping forums!you can do something along these lines too:FLOAT64 FSAPI AdfNeedle_cb(PELEMENT_NEEDLE pelement){ return fmod(pelement->source_var.var_value.n * (360.0/512), 360);}Hope this helps!

Since you have already gotten two perfectly valid answers to the function call, I'll answer the OTHER question that was passed over...Yes, you do need a non-linearity table, else how's the sim know where 180

Ah....Man it was late when I read a previous post about using that mask, and I forgot that I'd have to convert that double before masking it.I knew there was something I was missing that was simple yet invisible to my eye that would explain why I was not getting the result that I "knew" should be there.

Well, for a total noob, his post would have been of little help, true, since he only hinted at how to fix it.But, I understood him thankfully, and I'm sure if I asked he would have told me more.I appreciate your help as well, and see that where I went wrong was using 'n' which meant I was trying to mask a FLOAT (double), and that, of course, won't work. Not sure that asking for 'd' will change this in any way as it doesn't cast it as far as I know.I think my main problem was I needed sleep before I started messing with it again. =)

Thanks Bill.Well, my reading of the SDK was that it would assume the 12 o'clock position lacking a table, but I'll have to test this.Thanks for the tip about reducing it though.Patrick

Of course I know masking is useless for the double. However, rather than state that... I showed him exactly what was incorrect. Stating what is obvious to me doesn't mean it's obvious to others.Helping others means just that. Helping. Saying "you're doing something wrong, now go fix it" is simply stating what they already know. They really want to know exactly what is wrong, not get some arcane hint. This isn't college, and J-L certainly isn't a professor.

Yes, and it certainly wasn't obvious to me! (being the tired noob I am with only a couple of years of pushing bits)Anyway, the needle is finally point, at something, but not the NDB!I did use:FLOAT64 FSAPI AdfNeedle_cb(PELEMENT_NEEDLE pelement){ return fmod(pelement->source_var.var_value.n * (360.0/512), 360);}which now does have the needle pointing.Look here:http://forums.avsim.net/user_files/167385.jpgI am sitting at KCPM (Compton) which has an NDB (CPM) on the field to make testing easy.The ADF_CARD_RADIAL is currently zero(0) with my gauge showing due north simulating a fixed card ADF, and FS's apparently offset/slaved to the aircraft HDG, showing 270 by having HDG added to the radial.The NDB is bearing 247 magnetic according to the GPS, so: HDG 270 degs mag NDB 247 degs mag ------- -23 degs relativeHowever, when I mouse over my gauge to get the dynamic tooltip of the REL bearing, I get -16 degs, and the needle appears to be measuring that -16 from due East.In my needle NONLINEARITY, I have 0 at the N or 12 o'clock position.NONLINEARITY adf_nonLinearity[] = { { {128, 51}, 0, 0 }, { {128, 203}, 180, 0 }};So, I don't understand why I am getting -16 degs reported as the offset, and not -23, and why my needle is not pointing at the NDB.=(

As you have used a Nonlinearity table your needle bitmap must have the needle pointing to the right (ie the 3 o'clock position). In your bitmap resources does your needle point straight up?? If it does you need to rotate the bitmap and re-save it..you'll also have to change the centre coordinatesRegardsJim

Jim,No, the needle is in the correct 3 o'clock position per the SDK.

Patrick I'm confused by the 512..what is it there for? For an ADF needle I would normally do this (and I don't use Nonlinearity because its a linear gauge!)///////////////////// NEEDLE2 ADF ////////////FLOAT64 FSAPI fir_rmi_needle2_cb( PELEMENT_NEEDLE pelement ){ return pelement->source_var.var_value.n;}MAKE_NEEDLE( fir_rmi_needle2, BMP_FIR_RMI_NEEDLE2, &fir_rmi_needle1_list, NULL, IMAGE_USE_ERASE | IMAGE_USE_TRANSPARENCY, 0, 224,223, 22,199, ADF_NEEDLE,fir_rmi_needle2_cb, NULL, 0)PELEMENT_HEADER fir_rmi_needle2_list[] = { &fir_rmi_needle2.header, NULL};RegardsJim

Patrick,Te reason you're getting 16 instead of 23 is that spurious 512 you've included. You're dividing 360 by 512 so youre reducing your value to 70.3% of the value it's supposed to be. Hence 23 x 0.703 = 16.Regardsjim

Yeap,You are right there, as I had forgotten that I was no longer reducing the range with the mask.Thanks.Still the needle is not point the right way. See, the original MODULE_VAR is negative and a counter-clockwise offset. So, I assumed it was a relative offset, and it is, but apparently not relative to what I thought. So, I'm going to just figure out what it is releative to, and then go from there.