FS2004 EGT units with FSUIPC 3.04

[hsors]

Pete

>EGT for props. It seems that the units used for this value for props are not the same as those used for Jets. Only the latter appears compatible with FS2002 and before. Until we know more about this, I have derived an approximate conversion formula empirically so that the Prop values, too, are more like their FS2002 values<

Could you here clarify..most experienced designers know that EGT, as it is reported for jet aircrafts by FS2002 token (and previous FSUIPC versions) is grossly wrong (a much better approximation from corrected N1 value was provided some time ago by Ian Kerr and Ron Freimuth and I advise all interested designers to have a look to the posts on the subject at

http://www.avhistory.org/scripts/MegaBB?forumid=5

We didn't test it yet in FS2K4 due to the necessary test program updates

Many "test" applications have used FSUIPC so as to discover and report what MS has programmed too badly..no more but not less..so changing the values FSUIPC will report will surely complicate the process unless we use a non-FSUIPC approach (through XML or gauge C programming)

I suppose the "empirical conversion formula" you intoduced in 3.04 was suggested by some panel designers. Is it a simple temperature conversion or a more complex approximation and, if so, could you give us more details?

Thanks Pete for the help you could provide on this point, so as to correctly interpret what the future FSUIPC readings mean

Hervé Sors

[Pete Dowson]

Could you here clarify..most experienced designers know that EGT, as it is reported for jet aircrafts by FS2002 token (and previous FSUIPC versions) is grossly wrong

To clarify:

The value provided for Jets, with the old FS98 assumption on units (16384 = 860C), gives the same figures as FS2002, and the figures shown on external gauges, such as Project Magenta's EICAS for example, match those shown in the FS panels.

So, it seemed correct. But then folks using external EGT gauges for Props told me that the values were far too high.

Investigating I did, indeed, find that compared with FS2002 the Prop EGTs were much too high. Through experimentation I arrived at a very approximate conversion of

y = 1450 + (x/3.6)

where x would have been the value I place in 08BE (for example) but y is the value I now place (for props only). After doing this and comparing, side by side, FS2002 running a Cessna and FS2004 running the same, I get similar values for similar settings of throttle and prop and so forth.

It is not accurate, but it's the best I could do for now and it works.

Please understand. It is NOT FSUIPC's job to provide *correct* values if FS does not, but it is supposed to provide compatibility across FS2000-FS2002-FS2004. That is my first aim. Better or fixed values, should they arise, will have to find alternative offsets if they would make FSUIPC incompatible with existing gauges and so on.

Many "test" applications have used FSUIPC so as to discover and report what MS has programmed too badly

FSUIPC really is not a good vehicle for such testing. In all three versions I do a lot of manipulation to make things look like FS98. If you want real FS values you can use FSLook, which reads a subset of the Gauge SDK's Token Variables, or write a Gauge to investigate these things. FSUIPC is manipulating values to make them the same as FS98, whether they are good or bad. Except for newly discovered values of course, which can go to new offsets.

I suppose the "empirical conversion formula" you intoduced in 3.04 was suggested by some panel designers.

Not at all. By empirical I mean I experimented and made a table of values read in FS2002 and those read for similar settings in FS2004. Then I derived the simplest formula which would take me from the latter to the former.

Regards,

Pete

[hsors]

Pete

Thanks for these precisions. However, I still think the EGT problem for prop aicrafts remains unclear and probably will need to be reinvestigated. I always trusted the RECIP_ENGINE1_EGT_DEGR token (which is in degrees Rankine) since its value (after converting it to °F or °C) was concordant with what default MS gauges showed ; also, the value was available from FSUIPC at &H3B70 (for 1st engine) and didn't change in FSUIPC versions from 2.9xx to the latest and also didn't change in FS2004 as compared to FS2002

Comparing it to the integer mapped at &H8BE showed a problem in FS2002 (if assuming here that 16384=860°C). As an example 1524.19°R (from &3B70 - which is 1064.52°F and 573.6°C) was corresponding to an integer of 4545 at &H8BE (which is only 238.5°C)..clearly wrong..

Now it seems that FS2004 changed (corrected?) something that FSUIPC before 3.04 reported at &H8BE but it could have been OK since (using FSUIPC 3.03) both &H3B70 and &H8BE were concordant..An example

1567.71 °R was 11391 (597.8°C and 597.9 respectively..)

May be, you reversed back the MS error, because panel designers who initially used the wrong &H8BE were of course far out of their initial FS2002 gauge values with the new value FS2004 provided? But who is right?

I will be glad if you could compare both EGT locations (ie &H8BE and &H3B70 only applicable to prop aircrafts) and may be also compare them to some other sources, including published real EGT values in MS default aircrafts which are available in some engine data sheets and/or POH. But may be I'm wrong and missed something..let me know

Regards

Hervé

[Pete Dowson]

I always trusted the RECIP_ENGINE1_EGT_DEGR token (which is in degrees Rankine) since its value (after converting it to °F or °C) was concordant with what default MS gauges showed ; also, the value was available from FSUIPC at &H3B70 (for 1st engine) and didn't change in FSUIPC versions from 2.9xx to the latest and also didn't change in FS2004 as compared to FS2002

That's where I get it from for the FS98 areas, but converting it to the FS98 units. But in FS2004 this makes it too high, compared with the readings on the panels and compared to FS2002.

Comparing it to the integer mapped at &H8BE showed a problem in FS2002 (if assuming here that 16384=860°C). As an example 1524.19°R (from &3B70 - which is 1064.52°F and 573.6°C) was corresponding to an integer of 4545 at &H8BE (which is only 238.5°C)..clearly wrong..

Well, FSUIPC was doing the same for both Props and Jets, and they both came from the same place. I really don't know what the final values should look like, but the value FS gives me is quite clearly different, for Props only, than that given by FS2002.

May be, you reversed back the MS error, because panel designers who initially used the wrong &H8BE were of course far out of their initial FS2002 gauge values with the new value FS2004 provided? But who is right?

Quite possibly, and I don't know who is right. I can only go by what the panel/gauge designers tell me, and the value I gave for FS2004 was wrong for them. I have to keep things compatible. If it has been wrong all the time since FS98, then it has to stay wrong, at least in the FS98-compatible position.

BTW how do you read the values on, say, the Cessna default EGT gauge. It is marked in 25C ticks, but starting from 0 or what?

I will be glad if you could compare both EGT locations (ie &H8BE and &H3B70 only applicable to prop aircrafts)

Since 08BE is derived from the same place as 3B70, both for Jets and Props (the same location is also used for "GENERAL_ENGINE1_EGT" too, in case you didn't notice), there's no point in me "comparing" them. All I'd do is discover that I was converting them for props by the formula I gave you! :lol:

and may be also compare them to some other sources, including published real EGT values in MS default aircrafts which are available in some engine data sheets and/or POH.

Sorry, it really is NOT FSUIPC's job to make things "as real as it gets". As far as the FS98 locations are concerned my only aim is to make it "as compatible as it gets".

Regards

Pete

[hsors]

Thanks

Right, it's not your job to test everything and I fully understand the compatibility requirements although your statement that it should remain compatible even if it's false (and even if MS corrected it) could be a background discussion ;-)..FS98 is so distant..

BTW, I will perform extensive tests with 3.03 and 3.04 and send you a report privately..I need some time for that but I'm sure you are even more busy than I am

Again, thanks for your very quick answers and help

Regards

Hervé

[Pete Dowson]

FS98 is so distant..

Yes, I know. But I made FS2000 readouts compatible and then FS2002 .. and now FS2004. Really, FS2002 is not distant, many still use it and most current add-ons and hardware were made for it.

If the value needs adjusting to make it TRULY correct in real terms, and if it is a simple conversion from the value provided, then the way to deal with it is for me to publish the correct formula in the SDK.

Currently it says 16384 = 860C. I didn't derive that, it was obtained from some earlier document, lost in time, and probably for FS5 or something. Maybe it is just that this isn't true for props and never has been. If there's a better expression for props, tell me what it is and I'll publish it. I would have done that several years ago if you had told me, but no one bothered.

I see no need to make the actual numerical values there muck up existing applications and hardware gauges, no matter what the units are. Please try to see this point of view. It is quite important.

Regards,

Pete