Jump to content
The simFlight Network Forums

Flight Director


Recommended Posts

Hi Pete,

So I've just searched what's up on the forum here on the FD matter. Indeed I know 2EE8 and 2EF0 don't give the needle position but a direction in which the needles should point the aircraft.

Either way, when I read them from FSUIPC I get wierd stuff. The value changes on each read and goos from very large to very low (below 0) numbers.

When I make the plane turn a lot (like from 0° to 100° or 200°) with the autopilot, the bank stabilises on 000008.

These numbers are nothing like what I get from FSInterr.

I suspect I am doing something wrong here.

I'm new at C++ but I have managed to make this work in OpenGL (all you see on the img works)

Fokker50EASIOpenGL.jpg

So I guess I'm not such a n00b as you might suspect. I am reading other stuff and using it proprely.

Ok so for this FD thing, I declare:

double _fdpitch;
double _fdbank;
int _fdflag;

_fdflag works super. I tried changing the data type from _fdpitch and _fdbank to float or int and though the numbers get different each time, I get nothing like I see in FSInterrogate.

Then I got this in the FSUIPC code:

!FSUIPC_Read(0x2EE8, 8, &_fdpitch, &dwResult) ||
!FSUIPC_Read(0x2EF0, 8, &_fdbank, &dwResult) ||
!FSUIPC_Read(0x2EE0, 4, &_fdflag, &dwResult) ||
//etc..

At the moment I show the values in the green text you see on the picture above. Maybe it gets screwed up while showing it as text ?

One other thing. I was working last night on those GS and LOC bugs. The GS was working good but I had a lot of issues with the LOC. It showed me values in the texbox from 0 to 127 and then jumped to 255 and counted backwards to 128. Even if I used double as type it didn't want to show negative values, so I just use an if/else and substract 256 from the value if the value is higher than 127. That works though probably unclean sollution.

I hope you can give me some tips here.

Cheers,

Link to comment
Share on other sites

Either way, when I read them from FSUIPC I get wierd stuff. The value changes on each read and goos from very large to very low (below 0) numbers.

When I make the plane turn a lot (like from 0° to 100° or 200°) with the autopilot, the bank stabilises on 000008.

These numbers are nothing like what I get from FSInterr.

I suspect I am doing something wrong here.

It sounds like you are not reading them as 64-bit double floating point numbers, that's all.

double _fdpitch;
double _fdbank;
int _fdflag;
...
!FSUIPC_Read(0x2EE8, 8, &_fdpitch, &dwResult) ||
!FSUIPC_Read(0x2EF0, 8, &_fdbank, &dwResult) ||
!FSUIPC_Read(0x2EE0, 4, &_fdflag, &dwResult) ||
//etc..

At the moment I show the values in the green text you see on the picture above. Maybe it gets screwed up while showing it as text ?

The code looks okay to read them as doubles. What are you doing to display them as text? It sounds like your print formatting is wrong. Let's see that.

One other thing. I was working last night on those GS and LOC bugs. The GS was working good but I had a lot of issues with the LOC. It showed me values in the texbox from 0 to 127 and then jumped to 255 and counted backwards to 128. Even if I used double as type it didn't want to show negative values

Was offsets are you talking about there? If this is something containing a signed byte then 255 is -1 and 128 is -128. It should run 127 to 0 then -1 to -128, in one direction, reverse in the other. It sounds like you are typing a signed byte as unsigned. Re-define it as signed.

Incidentally, I see that you have 218 warnings from the compiler. This generally means that the compiler had to make decisions which by right you should be doing. For instance, your double values may be getting offered to a function as a different type, and so on. It's best to check all warnings and work on reducing them to zero. You'll be surprised at how many problems that process solves.

Regards

Pete

Link to comment
Share on other sites

	glPrint("goodADF2 %05d", (double)_fdbank);

That's what I got at the moment. I tried with the (double) and without with the same result.

The ofsets I was refering to is the 0C48.

I think I did try to declare it as "signed double" but I'll check again if it changes anything.

I know 'bout the warnings. However I don't know how to fix this :oops:

Most of them are:

warning C4244: 'argument' : conversion from 'double' to 'float', possible loss of data

And the line it refers to is something like this:

// 20° up line
	glBegin(GL_QUADS);
		glVertex3f( 0.4f, ((double)_pitchrate/1800)-1.43, 0.0f);
		glVertex3f(-0.4f, ((double)_pitchrate/1800)-1.43, 0.0f);
		glVertex3f(-0.4f, ((double)_pitchrate/1800)-1.40, 0.0f);
		glVertex3f( 0.4f, ((double)_pitchrate/1800)-1.40, 0.0f);
	glEnd();

Link to comment
Share on other sites

glPrint("goodADF2 %05d", (double)_fdbank);

I changed that to

glPrint("goodADF2 %05f", _fdbank);

And it works now.

I don't seem to find those % things on the net. I understand that the 05 indicates the number of digits to use ? But what is the d or the f behind ? And what other choises are there ?

Link to comment
Share on other sites

	glPrint("goodADF2 %05d", (double)_fdbank);

That's what I got at the moment. I tried with the (double) and without with the same result.

I don't know this "glPrint", But if it is based on the standard library printf routine the formatting directive %d tells that routine that the value is a 32-bit integer, not floating point. You need %f. Please look up the definitions for printf formatting.

// 20° up line
	glBegin(GL_QUADS);
		glVertex3f( 0.4f, ((double)_pitchrate/1800)-1.43, 0.0f);
		glVertex3f(-0.4f, ((double)_pitchrate/1800)-1.43, 0.0f);
		glVertex3f(-0.4f, ((double)_pitchrate/1800)-1.40, 0.0f);
		glVertex3f( 0.4f, ((double)_pitchrate/1800)-1.40, 0.0f);
	glEnd();

The notation 0.4f tells the compiler that the 0.4 is a 32-bit float. For doubles, as this should be, you don't append the 'f'. Please check with a C programming book on these matters.

Regards,

Pete

Link to comment
Share on other sites

I think I nailed it; you can see that the image in my first post has changed to the current state.

What I did is take the FD LOC (0C48) and substracted the current turn rate and used this to position the LOC needle.

Then took the FD GS (0C49) vanlue and substracted the current pitch value to position the horizontal needle.

Don't know if this is precise, but it does seem to do the trick. Especialy for the turn. Not sure yet it the horizontal needle shows good ofset but it can't be far off.

Tnx Pete, I'm on a roll again :)

Link to comment
Share on other sites

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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.