GFDisplay: Math Functions

[Skittles]

I'm sorry, you're going to hate me for this... I have two more problems.

As the User Guide states, "These two arithmetic operations are the only ones supported, and you can only have one of each". Referring to multiplication and division.

In my other post, the "Heading" offset (02CC) is actually the "Whiskey Compass". I didn't realize that until last night, I guess I wasn't paying attention when I found the offset.

There is a "Heading" Offset (0580), but it does not take into account MagVar (02A0).

The Heading and MagVar offsets require formulas for proper display.

So basically I need to add the MagVar to the Heading and have two multiplication & division operations so this can work...

D1= X0580 U32 *360 /4294967296 +X02A0 S16 *360 /65536 D302

Is it possible to eventually include this operation and have two of each? Or is it possible some other way to make the calculations? Can you think of another method?

Thank you for considering my request.

Joe

[Pete Dowson]

In my other post, the "Heading" offset (02CC) is actually the "Whiskey Compass". I didn't realize that until last night, I guess I wasn't paying attention when I found the offset.

That gives the magnetic heading, subject to flying level. Isn't that what you wanted? The only other headings are non-drifting exact simulated values. Is that what you want? Otherwise, for the correct gyro reading you'd have to add the drift value (a separate offset again).

There is a "Heading" Offset (0580), but it does not take into account MagVar (02A0).

The Heading and MagVar offsets require formulas for proper display.

The same formula, though.

So basically I need to add the MagVar to the Heading and have two multiplication & division operations so this can work...

D1= X0580 U32 *360 /4294967296 +X02A0 S16 *360 /65536 D302

Ah, no. For your accuracy you only need the upper half of the 0580 offset, so it's the same multiplication for both:

X0582 U16 * 0.0054932

You can combine the mult/div into one number too, as shown. That's 360/65536.

So, it might have been possible to allow + or - as one of the two operations, with the understanding that it would be a strict left-to-right parsing, but ...

... the big problem is having references to two offsets, both of which may change independently, in one statement. The whole (simple) way GFDisplay works is to process statements only when THE offset they depend upon changes. To make this work with two offset references is pretty much a rewrite, maybe introducing local variables to make my data structures reasonably simple. It's all geared to maximum efficiency in processing, I'm afraid, not maximum user flexibility.

Anyway, I'm not sure you get anything useful this way. Unless you also added in the drift you aren't getting a proper instrument readout -- or are you making a GPS display?

Perhaps you should tell me exactly what it is you are trying to do. For FSX, at least, it would certainly be much easier to provide an offset in FSUIPC4 for it -- SimConnect provides the Gyro reading directly, I just need to map it to an offset, a moment's work really.

Regards

Pete

[Skittles]

360/65536 huh? Well, you got me with that. I did take 65535*65535 into consideration for getting the Heading, I just didn't continue thinking.

I'm constructing a small generic cockpit. Basically just a small dashboard with some GF units behind it to go under a monitor. Switches & buttons mostly. But I wanted the GF46 right on top of my CH yoke and the rotary knob interferes with the yoke's throttle lever.

The GF46 would be behind a thin sheet of plywood and I had hoped to remove the button and rotary. GFConfig initializes the unit to the first instrument setting (Altimeter) and I have to manually select the Gyro instrument.

When I realized GFDisplay could set the unit for me, that's when I wrote you about the formatting so I could get the unit placed just right, amongst the other units.

I'm not too concerned about gyro drift, I always have that turned off. I suppose I'm not a hard core simmer. I do want a Magnetic Heading, but not one that shifts 15 degrees as I roll.

Is FSUIPC4 compatible with FS9? I do have FSX but since I can even get the airport terminals to show up without going below 10fps... I've gone back to FS9 until I get a new machine and haven't even looked at FSUPIC4.

If this involves a complete re-write of GFDisplay then never mind, I'll work out another placement scheme.

[Pete Dowson]

Is FSUIPC4 compatible with FS9?

No, but that's not relevant in any case. The gyro heading is easy in FSX because SimConnect provides it ready-made and FSUIPC4 is completely table-driven around SimConnect's variables.

It isn't so easy in FS2004 because it isn't available ready-made in the same way, and each new variable "mapped" from FS2004 and before needs extra code specifically written to compute it.

I do have FSX but since I can even get the airport terminals to show up without going below 10fps... I've gone back to FS9 until I get a new machine and haven't even looked at FSUPIC4.

Eryou've got something really set up wrong for FSX if you are getting such poor performance on your PC, a 3.2 gig machine with a Radeon 9800? FSX can be made to run pretty smoothly on such a machine. I know this, I've done it. You should be able get up to 20 fps at airports, certainly rarely if ever single digits.

You can't have all those sliders up full -- turn off autogen completely, and turn down Traffic or invest in a faster traffic set like MyTrafficX. There are lots of good hints on getting the most out of FSX, and they are worth following. See the FSX forum.

If this involves a complete re-write of GFDisplay then never mind, I'll work out another placement scheme.

Yes, sorry.

Anyway, in FSUIPC 4.086 (or whatever the next interim release will be) I've added the gyro compass value as a 64-bit float in FSX/FSUIPC4, at offset 2B00, so it will be ready for you when you do move on to FSX! ;-)

Regards

Pete

[/img]

[Skittles]

I have all my settings to minimum on FSX so I'll investigate my problem there.

Thank you for adding the offset to FSUIPC4, I'm positive when I get FSX working right, I'll be using it.

And an overall "Thank you" for everything you do regarding Flight Simming. Your impact on this community is unmeasurable.

Joe

[Pete Dowson]

Thank you for adding the offset to FSUIPC4, I'm positive when I get FSX working right, I'll be using it.

I've just checked, and it looks pretty easy to add it to FSUIPC3 (for FS2002 and FS2004 only, not FS2000 or CFS), so I'll do that in the next increment (3.732) which I'll post in the "Other Downloads" announcement above, probably later today ...

Regards

Pete

[Skittles]

Wow, didn't expect this coming. Thanks.

This is what I'm using in GFdisplay

[GF46.0]
NEEDS=B E A ; HEADING DISPLAY
D0= ="HEAD"
D1= X2B00 F64 D302

The reason I'm showing you this is when I'm in the middle of a turn (with high turn rate) the display updates normally. When I'm near the desired course and I start leveling out (with low turn rate), the display stops updating. When I'm steady on course, the displayed heading is up to 7-9 degrees off. If I manually save the GFdisplay.ini, it jumps to the correct heading.

At first I thought it was all the other stuff in the ini file so I removed it and had only the Connections and what's above. I got the same result.

Any ideas?

[Pete Dowson]

The reason I'm showing you this is when I'm in the middle of a turn (with high turn rate) the display updates normally. When I'm near the desired course and I start leveling out (with low turn rate), the display stops updating. When I'm steady on course, the displayed heading is up to 7-9 degrees off. If I manually save the GFdisplay.ini, it jumps to the correct heading.

At first I thought it was all the other stuff in the ini file so I removed it and had only the Connections and what's above. I got the same result.

Any ideas?

No, sorry. The 2B00 offset is updating normally,, at the same rate as most of the other fast-update stuff in FSUIPC, and it certainly says it's the gyro compass value. If the FS panel gyro compass display isn't suffering then the problem must be that GFDisplay is not getting the processing time. A dual core CPU should fix that. Not sure how you'd do it in your PC.

Regards

Pete

[Skittles]

...then the problem must be that GFDisplay is not getting the processing time. A dual core CPU should fix that. Not sure how you'd do it in your PC.

I though as much. I have a dual core, but I wonder what upgrading the affinity will do. I have to run now, but I'll check later.

Thanks again,

Joe

[Pete Dowson]

I though as much. I have a dual core

Hmmm. That's strange. It shouldn't have a problem keeping up then. I'm afraid I'm at a bit of a loss on that. Did you get the same thing happening when you tried using the whiskey compass?

Pete

[Skittles]

I meant priority, not affinity, sorry. I thought I could set the priority of GFDisplay using FSAutoStart but I was wrong, so I did it manually. Anyway...

I set up the aircraft on a Direct-To route. Once I was steady on course, I updated (resaved) the GFDisplay.ini so the GF46 matched the Shift-Z info readout.

I would then shift from GPS NAV hold to HDG hold. and I would change course left or right in 10 degree increments. The GFDisplay never changed. I had it up to 90 degrees off. I then updated the GFDisplay.ini to match things up.

I then did 90 degree turns. Here's what I found...

When ever the aircraft's bank is less than 15 degrees, the GF46 did not change. Now, there's something to make one say "Hmm!" And this is consistent. If I use Auto-Pilot or manually, the GF46 will not change with less than 15 degrees of bank. (15 is a guess due to the rounding of numbers.)

So there's something to throw a wrench in the whole works.

[Pete Dowson]

When ever the aircraft's bank is less than 15 degrees, the GF46 did not change. Now, there's something to make one say "Hmm!" And this is consistent. If I use Auto-Pilot or manually, the GF46 will not change with less than 15 degrees of bank. (15 is a guess due to the rounding of numbers.)

So there's something to throw a wrench in the whole works.

Seems that GFdisplay isn't working properly at all then? I may have to withdraw it if so, as there's no way I can debug it here with no displays. Could it be I messed it up with my alignment changes? Can you test with the previous version?

Can you also test with the Whiskey compass instead, just to make sure it isn't something strange with the FS value rather than GFdisplay? (Though if it was I don't see that re-writing the INI would magically "fix" it).

Pete

[Skittles]

Can you test with the previous version?

Previous version of... GFDisplay I assume since FSUIPC wouldn't be looking at x2B00?

Can you also test with the Whiskey compass instead, just to make sure it isn't something strange with the FS value rather than GFdisplay?

I wouldn't know if the problem lies with the bank angle (why would it) or the rate of turn, or even the rate of bank, but...

Still using GFdisply 1222 and looking at the Compass I get the following results,

1. High rate of bank, GF46 updated regardless of bank angle or rate of turn.

2. Low rate of bank (1-2 degrees per 5 seconds), GF46 did not update until about 18-20degrees of bank angle.

I think I remember you say that GFDisplay only executes a line when the offset value changes? Is it possible it also take into account the rate of change?

ADDED

Same thing with GFDisplay 1.10

ADDED

Even while taxiing, GF46 did not change until I was turning more than about 2 degress per second. Wierd.

[Pete Dowson]

Can you test with the previous version?

Previous version of... GFDisplay I assume since FSUIPC wouldn't be looking at x2B00?

Of course. FSUIPC is certainly okay. The variable at 2B00 is changing continuously when I turn, in FS2004. I've checked this using both the FSUIPC monitor (Logging page, right-hand side -- select "Advdisplay" option for real-time on screen updates) and using FSInterrogate.

So it has to either be GFdisplay, or possibly the GFdev.dll.

Can you also test with the Whiskey compass instead, just to make sure it isn't something strange with the FS value rather than GFdisplay?

I wouldn't know if the problem lies with the bank angle (why would it) or the rate of turn, or even the rate of bank, but...

Please, can you check it with the whiskey compass? I am going through a process of elimination.

I think I remember you say that GFDisplay only executes a line when the offset value changes? Is it possible it also take into account the rate of change?

For all the values it's just a simple comparison of previous displayed value to the current value, to the number of fractional places you specify, and a half (i.e. greater than 0.5 difference for zero fractional places).

By all means, try increasing the number of fractional places -- if displaying it as D33 "fixes" it, try D32 and D31, see if each needs a faster and faster rate of change. If so it points to something wrong in the way I'm storing the "previously displayed value".

ADDED

Same thing with GFDisplay 1.10

Okay. Good. I've not messed anything up in GFdisplay, then.

If it doesn't update with 'slow' changes here, maybe it doesn't with any displays of anything? Maybe it's a 5 year old bug and no one has ever noticed?

ADDED

Even while taxiing, GF46 did not change until I was turning more than about 2 degress per second. Wierd.

It needs testing with other variables, like the whiskey compass and so on. Please. Also, maybe its a problem with GFDEV. Try different versions of that (are you using the latest or an older one?).

Regards

Pete

[Skittles]

Please, can you check it with the whiskey compass? I am going through a process of elimination.

I did, that's what this is...

Still using GFdisply 1222 and looking at the Compass I get the following results,

1. High rate of bank, GF46 updated regardless of bank angle or rate of turn.

2. Low rate of bank (1-2 degrees per 5 seconds), GF46 did not update until about 18-20degrees of bank angle.

Also the same with 1.10

By all means, try increasing the number of fractional places -- if displaying it as D33 "fixes" it, try D32 and D31, see if each needs a faster and faster rate of change. If so it points to something wrong in the way I'm storing the "previously displayed value".

OK, I'll try that.

It needs testing with other variables, like the whiskey compass and so on. Please. Also, maybe its a problem with GFDEV. Try different versions of that (are you using the latest or an older one?).

The latest, but they've screwed up other stuff, so I'll look for an older one.

[Skittles]

Some very interesting results. Reading from the Whiskey Compass offset...

Started with GFD1.222 & GFDev 1.72 (the latest)

I started with a three digit integer and three digit fractal. (xxx.xxx)

Appears to be the same results as before. Since the compass, as you know, is very sensitive and always moving due to the movement/vibrations of the aircraft, I got constant GF46 changes until I put the engines at idle and set the brake. After a while, no more changes.

Then I changed to a single digit heading and used D15 (x.xxxxx)

Constant changes. Even when I put the engines at idle and set the brake. It didn't stop changing until I shut off the engines and waited about 15 seconds.

Then, I used GFD1.222 & GFDev 1.33. Same results as above.

Then I used GFD1.10 & GFDev 1.33. Same results as above.

I don't know about your thought process, but this confirms my theory about the GF46 not changing unless there is a big enough change. I agree with you, what ever the problem is, like you said, it's been there a long time. Leave it to me thinking outside the box to discover this.

So how do we determine which program is causing this? Here's my situation, I'm in the Navy and have been using up my excess leave. Next week I go back to work to do final paperwork and retire. It's a two hour commute each way, so I won't have the time to test further until about Saturday, 24MAR07. But I'll keep at this as long as you do.

[Pete Dowson]

Please, can you check it with the whiskey compass? I am going through a process of elimination.

I did, that's what this is...

Ah, so that proves it isn't the variable but either a GFdisplay bug or GFDev.DLL. The other tests should show which ...

It needs testing with other variables, like the whiskey compass and so on. Please. Also, maybe its a problem with GFDEV. Try different versions of that (are you using the latest or an older one?).

The latest, but they've screwed up other stuff, so I'll look for an older one.

There's an older one in the "Other downloads" announcement above.

Regards

Pete

[Skittles]

Hope you didn't read this previously, I was wrong.

I thought it worked ok, but when I went back, it was acting up again. It was wierd. Let me try a reboot and see what happens.

[Skittles]

From a fresh boot, using Older GFDev and GFD 1.10 I get the same results.

What else can we try?

[Skittles]

Something new... using Older GFDev and using GFD 1.10 & 1.222 the GF46 does not change until about 10 degrees of pitch where as before it was about 15.

[Pete Dowson]

I started with a three digit integer and three digit fractal. (xxx.xxx)

Appears to be the same results as before. Since the compass, as you know, is very sensitive and always moving due to the movement/vibrations of the aircraft, I got constant GF46 changes until I put the engines at idle and set the brake. After a while, no more changes.

Well, the latter must be a function of FS, reducing vibrations to near zero.

But unfortunately this is not really a comparison with your previous results, so it isn't useful. Please do the same tests each time, one with D30, one with D31 then D32 then D33. If it's a bug in GFdisplay, due to something about the way it is checking the changes, this should give progressively better results -- i.e. less heading change needed for each increment in display sensitivity.

Then I changed to a single digit heading and used D15 (x.xxxxx)

Constant changes. Even when I put the engines at idle and set the brake. It didn't stop changing until I shut off the engines and waited about 15 seconds.

Okay, so FS simulates smaller and smaller vibration effects. Nice.

I don't know about your thought process, but this confirms my theory about the GF46 not changing unless there is a big enough change. I agree with you, what ever the problem is, like you said, it's been there a long time.

It sounds like an original bug in GFdisplay. Just confirm, please, with your original banking tests then I'll start dry-running the relevant bits of code. It'll be tomorrow now -- it's 01:15 am here.

Regards

Pete

[Pete Dowson]

I started with a three digit integer and three digit fractal. (xxx.xxx)

Appears to be the same results as before. Since the compass, as you know, is very sensitive and always moving due to the movement/vibrations of the aircraft, I got constant GF46 changes until I put the engines at idle and set the brake. After a while, no more changes.

Well, the latter must be a function of FS, reducing vibrations to near zero.

But unfortunately this is not really a comparison with your previous results, so it isn't useful. Please do the same tests each time, one with D30, one with D31 then D32 then D33. If it's a bug in GFdisplay, due to something about the way it is checking the changes, this should give progressively better results -- i.e. less heading change needed for each increment in display sensitivity.

Then I changed to a single digit heading and used D15 (x.xxxxx)

Constant changes. Even when I put the engines at idle and set the brake. It didn't stop changing until I shut off the engines and waited about 15 seconds.

Okay, so FS simulates smaller and smaller vibration effects. Nice.

I don't know about your thought process, but this confirms my theory about the GF46 not changing unless there is a big enough change. I agree with you, what ever the problem is, like you said, it's been there a long time.

It sounds like an original bug in GFdisplay. Just confirm, please, with your original banking tests then I'll start dry-running the relevant bits of code. It'll be tomorrow now -- it's 01:15 am here.

Not sure what to make of your subsequent three short messages, sorry. I can't get them to jibe with anything else.

I just need reports of results on your bank testing with the four different precisions. I am expecting you to tell me each one is progressively "better" (i.e. less change needed to register). I'll assume that if I don't hear from you.

Regards

Pete

[Skittles]

Please do the same tests each time, one with D30, one with D31 then D32 then D33.

I've done that, I guess I don't know what you need for feed back.

When I used D30, there was no change unless I had a turn rate equal to 15º bank.

D31, less bank required about 8º

D32, Even less bank required, about 3º.

D33, Even less if any.

Then I changed to a single digit heading and used D15 (x.xxxxx)

Constant changes. Even when I put the engines at idle and set the brake. It didn't stop changing until I shut off the engines and waited about 15 seconds.

I thought this shows the amount of change required for the GF46 to display it. I'm just not explaining making myself very well.

Okay, so FS simulates smaller and smaller vibration effects. Nice.

I thought this was significant. If there is enough change in the decimal numbers beyond what is displayed, the change would register.

I just need reports of results on your bank testing with the four different precisions. I am expecting you to tell me each one is progressively "better" (i.e. less change needed to register).

I'm not sure how to answer. D30 needed more Heading change than D31. D31 more than D32 and so on. Is that what you need to know?

I think my problem is I'm analyzing what's going on and making reports based on my analysis instead of the results.

I'll try to be more accurate in my reports, if you can be more accurate in your requirements.

I am expecting you to tell me each one is progressively "better" (i.e. less change needed to register)

This is just what I needed. Keep in mind, I've never been a beta-tester

Get some sleep. It's almost my bedtime and I have a 16 hour day at work ahead of me.

I'll be back tomorrow night.

Joe

[Pete Dowson]

Please do the same tests each time, one with D30, one with D31 then D32 then D33.

I've done that, I guess I don't know what you need for feed back.

When I used D30, there was no change unless I had a turn rate equal to 15º bank.

D31, less bank required about 8º

D32, Even less bank required, about 3º.

D33, Even less if any.

Okay, that's exactly what I needed to know. I know where to look in my code now. It proves that it is an original bug in GFdisplay. ;-)

Regards

Pete

[Pete Dowson]

I'll be back tomorrow night.

Okay. When you can, please download GFdisplay 1.23 here:

http://fsuipc.simflight.com/beta/GFdisplay123.zip

and let me know if this fixes the problem.

Thanks & Regards

Pete