Glideslope and Localizer Needles

[hastim]

Hi Pete,

Currently the localizer and glideslope needles (offsets 0C48 & 0C49) are single byte values of -127 to +127.

Are floating point versions of these values available with more precision.?

I am calculating the 'rate of change' of the needles.

Thanks

Mark

[Pete Dowson]

Currently the localizer and glideslope needles (offsets 0C48 & 0C49) are single byte values of -127 to +127.

Yes, the resolution of even the best gauges presumably never needed more than 256 steps.

Are floating point versions of these values available with more precision.?

I am calculating the 'rate of change' of the needles.

Hmm. I don't know if the raw data I'm using to populate those is any more accurate. Just being in floating point format doesn't mean more accuracy -- there are lots of cases in FS where floating point resolution is is just as low as that shown in the old FS98-compatible ways.

I'll check the raw values for you and let you know.

Regards,

Pete

[Pete Dowson]

Are floating point versions of these values available with more precision.?

Ok -- the raw values are changing rather more frequently than the 256-graduations which the variables you use indicate.

In the updated FSUIPC attached I've provided the values in 32-bit floating point format (float or FLOAT32) as follows:

offset size meaning

2AAC 4 VOR1 Localiser needle value in 32-bit floating point format

2AB0 4 VOR1 Glideslope needle value in 32-bit floating point format

2AB4 4 VOR2 Localiser needle value in 32-bit floating point format

2AB8 4 VOR2 Glideslope needle value in 32-bit floating point format

I'm also updating these more frequently (at least every frame) than the FS98-compatible values.

This applies to FS2002 (untested) and FS2004 (tested ok), but nothing before these.

Let me know if this does the job you want.

Regards,

Pete

FSUIPC3509test.zip

[hastim]

Thanks brilliant. I didn't expect that kind of response... :D

I'll test it tonight... and let you know the results.

Thanks

Mark

[hastim]

Pete,

Thoses offsets work fine. thanks

But the update rate hasn't increased.

You can see this by placing 'Altitude' in the FS title bar using the 'logging' functionality and comparing the update rate to the localizer value update rate.

Altitude looks like it's updating every frame where as the VOR needles only seem to update every 500ms or so....

I guess there must be a update rate limit set by FS...

Mark

[Pete Dowson]

But the update rate hasn't increased.

I have no idea what FS's update rate for these things are. I said that I'd changed FSUIPC's priority, for those only, to make them update on every frame. In other words I read the values and place them in those offsets on every frame. Whether FS changes them on every frame I've no idea.

I guess there must be a update rate limit set by FS...

Possibly, or equally possible, the resolution is still quite limited so you don't see small enough changes.

If they definitely are only changing every 500 mSecs then I can put them on my lowest priority -- a 440 mSec update rate I think -- along with the FS98 equivalents at 0C48 etc (I think those are on a 110 or 165 mSec rate at present. Apart from my frame-related rates, others are all multiples of timer ticks which, at 18.2 Hz, are 55 mSecs apart).

I don't like to waste time unnecessarily! ;-)

Regards,

Pete

[hastim]

I don't think it was a resolution issue. I was getting decreasing values like :

114.63

112.37

109.60

ie the value was making relativly large jumps.

It points to an internal FS update rate limit.

I'll see if I can get some proper timing numbers for you. The 500ms was just a rough visual guess.

[Pete Dowson]

It points to an internal FS update rate limit.

I'll see if I can get some proper timing numbers for you. The 500ms was just a rough visual guess.

Where are you looking at the Needle values? You cannot necessarily judge it by the on-screen monitor display facility as I think that will be affected by the FS display logic (though if you are using the same for the altitude I suppose that's discounted already).

FSUIPC's Monitor operates up to 4 times the frame rate, so maybe logging to the Log file will work. FSInterrogate's update rate isn't all that fast, but faster than 500 mSecs by default I think.

However, if any of the methods "look" like as much as half a second then it seems that it must be pretty sssslllloooowwww.

I could send a test version of FSUIPC which updates those locations as much as 4 times the frame rate (varies) but I don't know how you'd monitor it fast enough to check, and it would be an even bigger waste of time if indeed FS is limiting them somehow.

If FS is limiting the update for these values it is probably a performance thing, based on the assumption that the only thing which needs them is the gauge and its resolution wouldn't support a faster rate in any case.

What exactly are you needing this for in any case, BTW? Are you trying to control landings using the GS/LOC? Wouldn't simply maintaining the correct V/S and Heading, once engaged, be better if so? The values for these (GS angle, correct and accurate heading) are available.

Regards

Pete

[hastim]

Yes, LOC intercept.

It is working as is,.. but could be better. :?

I will change it to use offset 0870 instead.

I have successfully used 0872 for the GS capture.

Thanks for your help.

[Graham Pollitt]

Is there a certain amount per degree?

ie the range for Glide slope is -127 to +127 with 0 being centred.

How many of those units would be needed for 10degrees below? and are these 10degree steps linear?

thanks

[Pete Dowson]

Is there a certain amount per degree?

ie the range for Glide slope is -127 to +127 with 0 being centred.

How many of those units would be needed for 10degrees below? and are these 10degree steps linear?

No idea, sorry, but if I wanted information like that I guess I'd do some measurements and work it out. You could, for example, find out what the numbers are on each GS mark on the AI, then just refer to an aircraft text to see what the marks actually indicate. I'm sure there's a direct and probably linear (angular linearality of course) relationship.

Regards

Pete