Jump to content
The simFlight Network Forums

hsors

Members
  • Posts

    35
  • Joined

  • Last visited

Posts posted by hsors

  1.  

     

    962589 Monitor IPC:0E8C (S16) = -14435

       962589 SimRead: 0E8C="AMBIENT TEMPERATURE" [also 34A8]

                FLT64: -56.3924792267

       962620 Monitor IPC:11D0 (S16) = -9662

       962620 SimRead: 11D0="TOTAL AIR TEMPERATURE"

                FLT64: -37.7458117115

     

    Seems ok to me at first glance. Did you check the TAT you've read matched the formula? (TAT=SAT*(1+0.2*Mach*Mach)) [sAT and TAT both in °K in this formula]; you'll have to add mach number to the records (&H35A0). This would be a definitive confirmation.

    Personally I use &H34A8 for SAT but it should be the same as E8C after rescaling

    I think this is also valid in slew mode but I'm not absolutely sure about that 

  2. From the tests I performed with P3D v2 with FSUIPC v4.923, there is no problem with TAT on my side

    As an example a record made at 13250 ft AMSL at a mach number of 0.7299

    - FSUIPC reported TAT (offset &H11D0): 17.4°C   (raw unscaled value 4456)

    - Identical to calculated value from SAT  [TAT (°K)=SAT(°K) * (1+0.2*mach*mach)]  [here SAT=-10.6°C that is 262.55°K)

    Different other records gave similar concordant values

    I made raw tests without any special met conditions (different P3Dv2 weather themes) and without any addon (other than FSUIPC)

    I could suggest reported values are compared to calculated ones so as to sort out any possible discrepancies (that is you'll have to report recorded SAT and mach number)

     

    I cannot answer for P3Dv1.4 I do not have

  3. I will have a look if I'm able to extract a readable file with that info

     

    You should be able to do that simply by reading the BGL files containing the navaids you are interested in. As mgh pointed out there is no way to read that another way

    For information default FS (and standard ranges) are tabulated below. ILSs FS default ranges are always 27 NM

    http://www.flightsimaviation.com/aviation_theory_6_Navaid_Service_Volumes.html

    VOR ranges (NM)

    High Altitude: 195 NM (standard 130 NM)

    Low Altitude: 60 NM (standard: 40 NM)

    Terminal: 37.5 NM (standard 25 NM)

     

    NDB ranges (NM)

    High power NDB (HH): 112.5 NM (standard: 75 NM)

    NDB (H): 75 NM (standard 50 NM)

    Medium power (MH): 37.5 NM (standard: 25 NM)

    Low power (L): 22.5 NM (standard: 15 NM)

  4.  

     

    The ILS for the freeware Prague airport for FSX was about 30 degrees out. I checked the airport BGL and found the author had made an error in one of the ILS definitions with a decimal point -- a magvar of 30 instead of 3 (if I remember the numbers correctly). This did affect the ILS alignment. Maybe those are corrected by Herve Sors updates, but at the time Ihadn't discovered those, so edited the BGL instead.

     

    Agree Pete but it is a separate field included in each ILS definition (<Ils magvar). This value is indeed of importance for properly displaying ILS magnetic tracks on GPS and map views

    It is not the airport magnetic variation that is included in the parent <Airport definition. That's what I ment

     

     

     

    Those who really need up to date data all the time will really need to either stick to those airports which are relatively frequenty updated, or learn to use one of the airport editors to update their data

     

    Yes. What I wanted to say is that keeping most airport sceneries up to date is probably unachievable especially considering the monthly changes worldwide in ILSs, runway identifiers, taxiway signs, instrument approaches, etc..

    What I've done in my updates is correct all navaids (including their magnetic declination because they also have a specific one that is important for properly aligning on a specific radial) ) even if it raises some problems in the flight plan generator (most don't use anymore btw). I also corrected European ILSs and runway information for FS9 on a regular basis but didn't do that worldwide neither I did it for FSX (except France) since it is a never ending painstaking task that requires decompilation/recompilation of stock BGL files (with also possible side effects). Agree that selective airport exclusion/edition with appropriate software is a better way for most.

     

    Regards

     

    Hervé       

  5.  

     

    Well, if the MagVar is wrong in the Airport data, the MakeRunways files will be wrong too

     

    That's often the case now, even for FSX. Note that the airport magnetic variation as coded in the BGLs is probably only used internally for calculating mag data for AI trafic..I'm not aware of any other effect changing it.

    Magnetic runway heading is calculated by FS from true heading and magnetic variation at airport position from the magdec.bgl file

    However, even taking this approach doesn't ensure it will fit charts as far as in real life, airport aeronautical data make use of a "local" magnetic variation value that may differ a bit from any "calculated" one at a given time (e.g. some airports in US and Asia still use 2005 values, most European airports use 2010, UK now use 2013, etc)

    Consequently there is no simple solution for correcting FS data as a whole

  6. There is not a single FSUIPC offset that can change turbine engine thrust (and most are designed to be read only). Effective engine thrust is only determined, from throttle position, by engine characteristics, atmospheric data and several lookup aircraft tables that are defined in the aircraft.cfg and air files. These parameters can only be changed by editing the files appropriately

    Except for the throttle command, the only switch I know about that is able to decrease engine thrust (on some models) without change in the trottle position is the structural/engine deice command

    A short summary of the process is available here

    http://www.mudpond.org/jet_flow_chart.pdf

  7. But If the virtual pilot change realism ingame, FS9 doesn't update fs9.cfg automatically, unfortunately.

    FS9 updates fs9.cfg only when we exit the simulator

    Yes, so the only solution I found to get round this problem was to write at regular interval an appropriate value (0xFF000800 in this case) at offset 32F0, so as to disable the "Aircraft" menu. See the meaning of the different Bytes in the Programmers documentation. Be sure to enable it again (by writing 0) when leaving your application so as the options and menus return to normal. Unfortunately this possibility doesn't exist in FSX.

    Regards

  8. There is some mathematical techniques to determine whether a point is inside a polygon. have a look here

    http://alienryderflex.com/polygon/

    http://local.wasp.uwa.edu.au/~pbourke//nsidepoly/

    Alternatively, you can try to use surface type FSUIPC information at offset x31E8. Withe some precautions, it can help determining if the aircraft is on or off the runway. However some third party sceneries may lead to deceptive results.

    Regards

    Hervé

  9. Hi Luke,

    As Pete said you can only retrieve via FSUIPC the absolute body angle of attack (at offset 0x2ED0). Since FS9 and FSX disregard wing incidence, it is also the wing AoA. Calculating AoA relative to maximum AoA will require you programmatically read Table 404 (or 1545 if it exists) of the air file and determine the AoA for max CL coefficient. This is not insurmountable since FSUIPC provides you the path of the air file. All you will have to do is to build an adequate extract routine (air file is a coded binary file). It seems this information was already extensively discussed in 2003 in the link you provided..how time flies!

    Hervé

  10. Hi Björn,

    You're right. My mistake is that I own and use an English FS9 version. In the French FS9 version, this subfolder is named "Fichiers Flight Simulator". Now, I didn't find a single registry key with it neither I could find a reference to this folder in the FS9.cfg file (except as part of the [uSERINTERFACE] Situation= item). May be someone else or Pete, could tell us if there is a way to retrieve the proper localized name of this subfolder. As regard FSX, the same could be true. Again I only own an English version.

    Regards

    Hervé

    [Edit]: here is the answer and the way to proceed by Pete : http://www.fsdeveloper.com/forum/archiv-4243.html

  11. Hi Björn,

    Indeed FSUIPC will not help you retrieving the "My documents" path. Rather than reading the registry, I will suggest you use the SHGetSpecialFolderLocation API with the adequate idl structure (&H5 for folder item). This is a more general approach that will also work on Vista. You will then have to append the "Flight Simulator Files" (FS9) or "Flight Simulator X Files" subfolder to complete the work

    Hervé

  12. Hi Thomas,

    I think there is no fault about that.

    The [NAV CSI] variable (localizer deviation) mapped by Peter at offset 0x2AAC full range is -127 to + 127 while the [NAV GSI] at 0x2AB0 is -119 to +119 ; this is described in the MS SDK. Don't ask me why ± 119 ;-)

    There is also in FSX a [NAV GLIDE SLOPE ERROR] variable (degrees) but to my knowledge, Pete didn't map it (yet).

    You could also try the byte variables at offset 0xC48 (localizer) ans 0xC49 (GS) whose ranges are ± 127

    Regards

    Hervé

  13. Hi

    I'm affraid you will not find any documentation about that

    Typically, full ILS localizer deflection is 5° (2.5° each side). So, as far as FS modelizes things as it should, you will have a localizer scale of 128 = 2.5°

    However I suspect this scaling will depend on the localizer beam width which is a known ILS FS parameter (distinct for each ILS).

    The glide slope signals also consists of 2 overlapping beams (90 and 150 Hz). Since the thickness of the overlap is 0.7° above and below the defined ILS glideslope, I suppose the GS needle shows full deflection at top/bottom of the overlap area. This would result in a glide slope scale of 128 = 0.7°. Some tests (using aircaft & GS coordinates/elevations and trigonometry) could confirm that or not ;-)

    Hervé

  14. Just to add to this discussion, this problem was discussed on the IVAO forum here

    http://forum.ivao.aero/index.php/topic,67666.0.html

    All reserved IvAp FSUIPC offsets work correctly with FS9, FSUIPC 3.75 and IvAp 1.3.4.1842

    However, there were known bugs in FSX IvAp version 1.9.4

    It seems it has been corrected with the release of version 1.9.5 See here: http://www.ivao.aero/softdev/IvAp/changelog.asp

    So be sure you use the latest IvAp version for your tests (by now 1.9.6.2039)

    BTW, this is only an IvAp problem

    Hervé

  15. Hi Ray. Pressure Altitude (PA) is not related to any Kohlman window setting (except when set to 1013 hPa/29.92 inHg in which case altimeter will read PA). PA is by definition the altitude above MSL of an International Standard model at which air pressure is the same as the current measured air pressure.

    There is no offset in FSUIPC3 giving directly pressure altitude. What you can do is recalculate it from ambient air pressure (0x28C8) and the ISA model formulas for pressure vs altitude. Alternatively you can approximate it from Altitude above mean sea level and current QNH (both available via FSUIPC)

    For FSUIPC4, pressure altitude is directly available at offset 0x34B0

    Hervé

  16. Roland,

    I monitored &H3BFC offset that appears to work correctly when payload is changed within FS. I didn't test it after directly changing payload weights at assigned FSUIPC offsets &H1400 and following. May be there is a dysfunction here and Pete will surely check that. Writing at &H3BFC has little sense (even if it's marked OK in the SDK) since this offset adds total payload weight to basic empty weight (a fixed aircraft.cfg value)

    Regards

    Hervé

    PS: Zero fuel weight at &H3BFC (marked ?) doesn't appear to work correctly in FSX. It only reports basic empty weight and doesn't add payload

    Edit:PS

  17. Hi Milan,

    First check that payloads stations are defined in your aircraft.cfg file in the [Weight_and_balance] section, otherwise FS and FSUIPC will not be able to write/retrieve any. Definitions of stations are for example:

    station_load.0 = 170.0, 46.3,-1.5,0.0

    station_load.1 = 120.0, 46.3, 1.5,0.0

    Then, check that you can read 170 lbs at offset &H1400 and 120 at offset &H1430. These are doubles and you will need to provide a corresponding 8 bytes value for read/write (I don't know which language you use for that)

    Check for changes after you write and process new values at the same offsets

    Hope, it will help

    Hervé

  18. Thanks for your immediate answer Pete

    If you think it would be useful I could simply set 11D4 zero when 3364 or 3365 are non-zero and vice versa. Would that help? I'm not really sure what you mean by "post-read processing errors". Are you getting invalid values in some offsets?

    No, it will be ok checking 3364 and 3365 since it works for both. Indeed I had once a division by zero error while repositioning the aircraft in another part of the world (at this time the ambient air pressure at &H3498 was 0 and it was a FSUIPC3 problem).

    Are you suggesting it isn't desirable? I could strip off the FS part if present, or leave it intact if not, but I would think it more generally usable as supplied.

    Of course, the less code we have to adapt to the FS version, the best it is but it's not a problem to add a If Else ;-). My applications are planed to work on both FS9 and FSX. Apparently, the aerodynamic maths didn't change a lot

    I assume you are working from the latest list, downloadable above and updated for FSUIPC 4.067?I assume you are working from the latest list, downloadable above and updated for FSUIPC 4.067?

    Yes

    Regards

    Hervé

  19. Hi Pete,

    Is there any possibility with FSUIPC4 to check for the validity of variable reads? A "busy" internal flag was provided in FSUIPC3 (&H11D4) that was convenient so as to avoid post-read processing errors.

    Also, "air file path" zone at &H3C00 appears to include the full file path (including FS path) with FSUIPC4 while it only included the partial path with FSUIPC3. Is it a wanted behaviour?

    Finally, it appears after testing that many FSUIPC4 offsets you marked as ?-Intl or ?-SimC are working properly. I will send you the list as soon as it will be completed.

    Thanks for the great job!

    Hervé

  20. Is that what that does? Strange name for it! :-). How do you specify which joystick? Or is that any and all joystick axes and button connections?

    Yes..I agree the name is inappropriate. But I didn't discovered that. You mentioned it as a possibility somewhere..I tried and it works as a ON/OFF command. Since I only have one joystick I cannot answer the second part ; may be the second at H3114 has something to do with that ; in my case writing 0 or 1 here didn't change the result. I confirm all axes AND buttons are either enabled or disabled

    If you ever find out, let me know and I'll add a flag somewhere for it.

    Nothing with FSInterrogate. If you have a range of values to look at, I know how to do that :)

    Regards,

    Hervé

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