Heading indicator Gyrodrift compensation problems

[Adrie]

L.S.,

I am driving from/to FS2004 via FSUIPC an (external to MS FS) Heading Indicator instrument with a Gyrodrift Compensation knob.

FSUIPC is version 3.201 of 16 Febr. 2004.

My software reads 3 values via FSUIPC: True Heading in $0580,4 Magnetic Variation in $02A0,2 and Gyrodrift in $0C3E,2.

It calculates 'Indicated Heading'

(Indic.Hdg = True Heading + Gyrodrift - Magnetic Variation) and sends this regularly to the instrument; this goes fine.

I encounter difficulties when the user turns the Gyrodrift Compensation knob on the instrument and i want to send the altered value to FS via FSUIPC.

I observe the following:

- the start situation is: Gyrodrift=0 degr, Magnetic Variation=-3.0 degr and True Heading=231 degr; the Indicated course is 234 degr, all ok,

- my s/w reads the given Gyrodrift Compensation value from the instrument, lets say 0.5 degree, converted to FS 16 bit smallint this gives 81,

- my s/w writes via fsuipc this value of 81 in $0C3E,2

- the next time that my s/w reads the 3 values, the Gyrodrift repeats my value of 81,

- the problem is that the next time thereafter (16 ms later) my s/w reads a Gyrodrift of 0, so 'something' has overwritten my input.

Only when I increase the given value over 192 (is > 1 degr) a non-zero value is read back in the 2nd cycle, but it is still lower than the given value.

I have tried the same by:

- setting the FS in slew-mode, then update the value, then set back to normal mode, but the same effect,

- setting FS drift-simulation OFF, but the same effect.

- I have not tried this with a newer version of FS.

My questions are:

- Do you know about this 'problem'?

- Is this solved in newer versions of FS?

- Is there another way to in/de-crease the Gyrodrift value in FS?

- Is there any other way that you can help me?

Thanks in advance and Regards,

Adrie

[Pete Dowson]

FSUIPC is version 3.201 of 16 Febr. 2004.

I am sorry but there is no way I can or will support such an old version! The current version is 3.70 (or you can get 3.709 in the Announcements above -- that will be released as 3.71 soon).

My questions are:

- Do you know about this 'problem'?

- Is this solved in newer versions of FS?

- Is there another way to in/de-crease the Gyrodrift value in FS?

- Is there any other way that you can help me?

Answers:

- No

- Don't know

- Don't know

- Only if you use the currently supported version. Please re-test with that. If you think there is still some problem I'll want a suitable Log file with IPC reading/writing and 0C3E monitored, please.

Regards

Pete

[Adrie]

Pete,

Thanks for your rapid reply.

I've installed FSUIPC 3.70 and re-run my tests.

The behaviour is the same.

I've made 2 test-runs with logging, both with FSUIPC logging (suffix AV1 and AV2) and also my s/w internal logging.

I have annotated my 2nd test-run log (AV2) in a word document, so please have a look at that.

I hope this will give you enough information to see why i am confused.

Thanks in advance and Regards,

Adrie

FSUIPC logs and AV logs.zip

[Pete Dowson]

I've made 2 test-runs with logging, both with FSUIPC logging (suffix AV1 and AV2) and also my s/w internal logging.

Unfortunately, whilst you did correctly Monitor 0C3E for me (and very odd it certainly looks), you forgot to enable IPC read and write logging as requested. I wanted to see the relationships between what you wrote and what was happening to 0C3E.

So, could you do that, please? Whilst you are at it, please enable Event logging too. Looking in the code I see that there is no direct way to set the drift, or at least I couldn't find one. The code I have actually uses the FS control GYRO DRIFT SET.

[Later ....]

Hmmm it isn't just a matter of using this control to set the absolute value of the drift amount. It looks like the value which has to be set is the DIFFERENCE between the current value and the one required.

Or at least it looks that way from the code I have.

It is quite possible that this was true in FS2002 but fixed in FS2004. No one has mentioned any problem for the past 3 years, but maybe you are the first one to actually write to this offset in FS2004!

Looking through my History document, I see that the last change in this area was this:

The operation of changing the gyro drift value (offset 0C3E) is made more consistent, though reading this will still only show the current FS value not the last value set, which may still be in the process of being applied.

That was in FSUIPC 2.96, one of the later versions for FS2002.

Looking at the Monitored values it does seem plausible that this was changed in FS2004 -- if so then I'll need to change FSUIPC as well.

I'm out tonight. Meanwhile, do you think you could assign a Key to the

GYRO DRIFT SET control, with a non-zero parameter, and see if it changes it correctly? If so then I'll change FSUIPC to do the same. I'll try it myself later, but it will be in the wee hours or tomorrow morning now.

Regards

Pete

[Pete Dowson]

[

Meanwhile, do you think you could assign a Key to the

GYRO DRIFT SET control, with a non-zero parameter, and see if it changes it correctly? If so then I'll change FSUIPC to do the same. I'll try it myself later, but it will be in the wee hours or tomorrow morning now.

I've checked tihs, and it is still as I thought in FS2004. As far as I can tell the code in FSUIPC is correct. I tested writes to 0C3E with the Cessna loaded, and using only FSInterrogate. All the writes had the desired effect, directly and with no problem. Certainly no alternating of values as we see in the log you sent.

Please check it yourself using FSInterrogate.

In order to take this further, if you should still think it is not your program, please supply the log with not just the monitoring but also the IPC reads and writes, so I can see what you are doing in FSUIPC.

Regards

Pete

[Adrie]

Dear Pete,

Best wishes for the new year!

Health and happiness and lots of software challenges!

It's been a while ago since i looked into the matter, but i've had many other things to do.

Anyway, i've picked it up again and done a test run with logging.

I've done this run with FS2004 and FSInterrogate 1.8.0.21

It's with a Cessna 172 standing on the ground, FS2004 is not paused.

I've setup the logging (with IPCs now).

The log is attached as a zipped file.

Then i've done reads and writes with FSInterrogate only, not with my software.

I've first read all data a few times,

then i've read 0C3E as Signed16bit three times (values are 31, 32, 33 resp. so drift is ticking ok), see 3 lines at 760375 ev.

Further on in line 788000 the value shown is 34 (drift is ticking ok).

Then i've written 0 (as a Signed16bit) in 0C3E, see line 790000; this seems ok.

(a question though: is it normal that only 1 byte is written?)

In the next line 790016 i've re-read the data, and it shows 0 correctly, but in reading a second time (see next line 790016) the value popped back to 34.

This is exactly the problem i've described previously to you.

Then i've repeated write, read and re-read,

see line 794703, write value 81 = hex51,

reading (next line 794703) shows correctly hex51,

but re-reading a bit later in the second-line 794734 the value popped back to 34 (this is the same value as in 788000, so no drift-increment took place).

Some more re-reading shows that the value continues incrementing from 34.

I hope this gives some insight in the described problem.

Regards from Adrie Voordijk

FSUIPC_log.zip

[Pete Dowson]

Okay. I couldn't sleep so I looked at your log.

then i've read 0C3E as Signed16bit three times (values are 31, 32, 33 resp. so drift is ticking ok), see 3 lines at 760375 ev.

Further on in line 788000 the value shown is 34 (drift is ticking ok).

Then i've written 0 (as a Signed16bit) in 0C3E, see line 790000; this seems ok.

All these values are of course minute1 degree drift would be about 182.

(a question though: is it normal that only 1 byte is written?)

FSInterrogate should write 2 bytes for a 16 bit value. How are you doing the writing? FSI2 has about three ways of doing it. Or maybe it is being clever and not writing bytes after the first if they are the same -- but that would be wrong. No, it can't do that else a lot of things won't work.

In the next line 790016 i've re-read the data, and it shows 0 correctly, but in reading a second time (see next line 790016) the value popped back to 34.

It doesn't here .... The "default" error seems to be around 3. Or maybe that's just because that's what is stored in the Flight file. sorry, I don't know.

This is exactly the problem i've described previously to you.

It that actually a problem? Can you actually measure that on the gauge? It would be about 0.19 degree

Then i've repeated write, read and re-read,

see line 794703, write value 81 = hex51,

reading (next line 794703) shows correctly hex51,

Yes, this is my error. I currently do try to write directly to the FS offset, which doesn't work. I'll change that so where you read is the FS offset and where you write is the place in FSUIPC which I then use to compute the parameter to use in the GYRO DRIFT SET control -- that's the only way I have of altering this.

Note that the GYRO DRIFT SET control takes only degrees as a parameter, and it is the DIFFERENCE between the current drift and the required drift I need to send.

The current drift is 34, you need 51, so I send 17 converted to degrees -- which is 0. So nothing changes.

but re-reading a bit later in the second-line 794734 the value popped back to 34 (this is the same value as in 788000, so no drift-increment took place).

Yes, this is because I can only send increments in degrees and 17 is way too small.

All my tests have been with much larger numbers, which seem to work okay. Are you really concerned with adjustments of less than 1/10th of a degree (which is what 17 is)?

I hope this gives some insight in the described problem.

I can see a misunderstanding, but what is actually the real problem? If you ensure a minimum change of 1 degree then you should be fine. Do you need higher accuracy? I really don't know of any way of getting directly at the obviously more accurate value I am able to read back.

Regards

Pete