AMVI_Rider Posted July 29, 2018 Posted July 29, 2018 Comparing HUD and standby radar altimeter shows a difference of about 70ft every 10000ft of altitude. This happens both in multiplayer and single player session. The problem is present in version 2.5.2.19682 Steps to reproduce: - load a mission (free flight instant action is ok) - fly to 10000 ft (baro) and check stanby - repeat at 20000 and so on [sIGPIC][/sIGPIC] Author of DCSMP and VRK Ryzen 5 3600X - 32GB DD4 3200C14 Win10 64 - Geforce GTX 1080Ti Hotas Warhog + Virpil T-50 base - Saitek Combat Rudder Pedals - Cougar MFCDs - Custom head tracker 35" UWQHD main display + 22" MFCD/Helios display / Rift S 2x256 GB SSD - 2Tb Caviar Green
IvanK Posted July 29, 2018 Posted July 29, 2018 There will always be differences between the HUD and standby Altimeter as they use separate sources. HUD displayed Altitude gets a little more "processing" before display.
AMVI_Rider Posted July 30, 2018 Author Posted July 30, 2018 I completely agree on the cause of the difference, I just thought that the ratio implemented is a little high. Obviously it is not. Thank you for answering. [sIGPIC][/sIGPIC] Author of DCSMP and VRK Ryzen 5 3600X - 32GB DD4 3200C14 Win10 64 - Geforce GTX 1080Ti Hotas Warhog + Virpil T-50 base - Saitek Combat Rudder Pedals - Cougar MFCDs - Custom head tracker 35" UWQHD main display + 22" MFCD/Helios display / Rift S 2x256 GB SSD - 2Tb Caviar Green
Ahmed Posted July 30, 2018 Posted July 30, 2018 Id actually say the opposite. When I first noticed the difference I gave kudos to ED for finally someone modeling these kind of things into a pc sim. Can’t talk about the F-18 as I dont even know what air data sources they use, but 70ft per 10k looks about right to me...
bbrz Posted July 30, 2018 Posted July 30, 2018 (edited) At least in airline ops the stby altimeter can show the altitude within a +300ft window. 70ft per 10000ft would be a too high deviation for a primary altimeter. Edited July 30, 2018 by bbrz i7-7700K 4.2GHz, 16GB, GTX 1070
AMVI_Rider Posted July 30, 2018 Author Posted July 30, 2018 I should have had a look to the performance data before posting :doh: Nice to see that level of detail! [sIGPIC][/sIGPIC] Author of DCSMP and VRK Ryzen 5 3600X - 32GB DD4 3200C14 Win10 64 - Geforce GTX 1080Ti Hotas Warhog + Virpil T-50 base - Saitek Combat Rudder Pedals - Cougar MFCDs - Custom head tracker 35" UWQHD main display + 22" MFCD/Helios display / Rift S 2x256 GB SSD - 2Tb Caviar Green
bbrz Posted July 30, 2018 Posted July 30, 2018 Altimeter position error and altimeter accuracy are two different things! i7-7700K 4.2GHz, 16GB, GTX 1070
Eldur Posted July 31, 2018 Posted July 31, 2018 Didn't notice that one, but I never paid close attention to the steam gauge altimeter. But what I noticed is quite abit deviation in radar vs barometric. Having the BALT clearly set to 0ft on ASL, going up to 3000ft, then switching to RALT on the HUD the indicated altitude is somewhere around 2700ft. That's 10% less. Also, I was kinda expecting the RALT to be measured straight down from the plane, so it would show higher values than the actual altitude at high AoB. I'm questioning this but because I actually don't know how exactly the Hornet's radar altimeter works, just know it from other modules. I mean, is there some radar antennas all around the whole airframe to make it possible to get radalt readouts in any condition like flying upside down? Even if such a sensor would correct for AoB, I'd expect it to cut out at AoB > 90° since it would face upwards anyway.
Alfa Posted July 31, 2018 Posted July 31, 2018 There will always be differences between the HUD and standby Altimeter as they use separate sources. HUD displayed Altitude gets a little more "processing" before display. Not questioning your authority on this, but reading the attached paragraph from the NATOPS manual, you get the impression that the HUD and the Height Indicator are just two different display options for the same radar altimeter set - i.e. they get the data from the same source. You can also initiate BIT checks of the system via either the DDI or height indicator. I would be more inclined to think that an altitude deviance would be down to display "fidelity" - i.e. that the height indicator may have a larger error margin than the digital output? JJ
Alfa Posted July 31, 2018 Posted July 31, 2018 (edited) . Also, I was kinda expecting the RALT to be measured straight down from the plane, so it would show higher values than the actual altitude at high AoB. It does. I'm questioning this but because I actually don't know how exactly the Hornet's radar altimeter works, just know it from other modules. I mean, is there some radar antennas all around the whole airframe to make it possible to get radalt readouts in any condition like flying upside down? Even if such a sensor would correct for AoB, I'd expect it to cut out at AoB > 90° since it would face upwards anyway. There is no cut-out function - with large bank angles the radar altitude indication becomes unreliable and if there is no reflected signal, then altitude indication automatically switches to barometric altitude(HUD indication switches from "R" to "B") Edited July 31, 2018 by Alfa JJ
Alfa Posted July 31, 2018 Posted July 31, 2018 Comparing HUD and standby radar altimeter shows a difference of about 70ft every 10000ft of altitude. But your screenshot does not show the standby radar altimeter(?) - did you mean difference in barometric altitude between HUD and standby pressure altimeter? JJ
Knives Posted July 31, 2018 Posted July 31, 2018 (edited) Id actually say the opposite. When I first noticed the difference I gave kudos to ED for finally someone modeling these kind of things into a pc sim. Can’t talk about the F-18 as I dont even know what air data sources they use, but 70ft per 10k looks about right to me...Additionally to what IvanK said, the Hornet has several sensors on its front fuselage and has also an Air Data Computer which process and calculate lots of data and parameters. Samples: Didn't notice that one, but I never paid close attention to the steam gauge altimeter. But what I noticed is quite abit deviation in radar vs barometric. Having the BALT clearly set to 0ft on ASL, going up to 3000ft, then switching to RALT on the HUD the indicated altitude is somewhere around 2700ft. That's 10% less. Also, I was kinda expecting the RALT to be measured straight down from the plane, so it would show higher values than the actual altitude at high AoB. I'm questioning this but because I actually don't know how exactly the Hornet's radar altimeter works, just know it from other modules. I mean, is there some radar antennas all around the whole airframe to make it possible to get radalt readouts in any condition like flying upside down? Even if such a sensor would correct for AoB, I'd expect it to cut out at AoB > 90° since it would face upwards anyway. The RALT antenna is located at the rear fuselage near the tail. Very important to be near the tail, to measure the ground clearance at high AoA during landing. If your AoB exceeds a certain value you will get a flashing B which means RALT in not valid. Edited for more clear images Edited July 31, 2018 by Knives
maxTRX Posted August 1, 2018 Posted August 1, 2018 Time out! Let's bring it down to a knuckle dragger level... Before I get dizzy looking at the schematics, "phugoids" and 3-page diagrams! Standby altimeter reads from the left static port. ADC uses that data combined with other sources and corrects it for positional and other errors and displays it on HUD. If ADC fails and you're above 5k the altitude box goes blank. There's one thing I need to verify in NATOPS or other sources (including ivanK and others:)): When you go to ADI page and switch between "standby" and "INS" does this also change the altitude source or just the attitude ball? In this sim... it does not make any difference in altitude indication when you switch.
Frederf Posted August 1, 2018 Posted August 1, 2018 See, F-16 isn't instrument rated for the HUD so the altimeter isn't the standby anything. The round gauge is the official altimeter and it's connected to the ADC for the best possible value transmitted over a cable electronically. It's also the backup altimeter by changing to the standby pneumatic source. F/A-18 has an IFR HUD so it doesn't have a physical primary altimeter. The primary altimeter is the HUD readout from ADC data. The standby altimeter is a true standby, independent of ADC data and as such has all the errors and differences from an ADC data source. Apparently the S-ALT is -100 to -400' relative to HUD altitude for medium altitude check (10kft+). It makes sense that ADI page chooses attitude source ADI or whatever the backup is. It's only for that DDI page displaying the ball attitude. I can't find anything specifically about ADC failure and HUD altitude display. It should either completely blank for baro or revert to INS or GPS. I don't think the S-ALT is an encoding data source. The only thing S-ALT tells the jet is the correction knob setting. Selecting the INS or STBY options at the bottom of the display determines the source of attitude information used to generate the display. Upon power-up with WonW, the ADI attitude initializes to STBY (STBY boxed), thus using the standby attitude reference indicator for attitude source information. Selecting the INS option (INS boxed) uses attitude information provided by the INS. Selection of INS or STBY on the ADI does not change the source of attitude data for the HUD.
Knives Posted August 1, 2018 Posted August 1, 2018 I can't find anything specifically about ADC failure and HUD altitude display. It should either completely blank for baro or revert to INS or GPS. I don't think the S-ALT is an encoding data source. The only thing S-ALT tells the jet is the correction knob setting. All the numbers on the HUD and the electronic ADI are corrected numbers from ADC. Any failure in ADC, you will get "AIR DATA" caution. And the output will either go blank or begin flashing. And in no way the altitude is 100% correct. For example the Barometric Altitude on the HUD is a corrected Altitude depending on Barometric setting, the measured static pressure and temperature. The standby altitude depends on barometer and corrected only for baro setting. It will be way off at higher altitude and close enough when you are near MSL. This is why in civilian ops, above a certain level they will switch to standard baro setting (29.92 inMg— 1013hPa) so that all aircraft will see the same altitude (even if it is not corrected).
AMVI_Rider Posted August 1, 2018 Author Posted August 1, 2018 ... This is why in civilian ops, above a certain level they will switch to standard baro setting (29.92 inMg— 1013hPa) so that all aircraft will see the same altitude (even if it is not corrected). Only for the sake of correctness, that's not fully correct: switching to standard pressure is needed because altitude measure with QNH or QFE reference is valid only in proximity of the departure airport (where QNH/QFE is measured). When leaving "local area" your altitude referenced to QNH means nothing compared to other aircraft with different departure location and this is a big safety concern. Compensation and accuracy of the instruments have an influence to the evaluation of the standard vertical separation by the ICAO which must consider all kind of avionics (if any). That's why only special equipped aircrafts may flight into RVSM airspace. [sIGPIC][/sIGPIC] Author of DCSMP and VRK Ryzen 5 3600X - 32GB DD4 3200C14 Win10 64 - Geforce GTX 1080Ti Hotas Warhog + Virpil T-50 base - Saitek Combat Rudder Pedals - Cougar MFCDs - Custom head tracker 35" UWQHD main display + 22" MFCD/Helios display / Rift S 2x256 GB SSD - 2Tb Caviar Green
maxTRX Posted August 1, 2018 Posted August 1, 2018 … This is why in civilian ops, above a certain level they will switch to standard baro setting (29.92 inMg— 1013hPa) so that all aircraft will see the same altitude (even if it is not corrected). That's above 18k for all, isn't it? civilian and military.
maxTRX Posted August 1, 2018 Posted August 1, 2018 … That's why only special equipped aircrafts may flight into RVSM airspace. There's a note in Hornet and Rhino NATOPS that any degradation in equipment status should immediately be reported to controlling agency when in RVSM so I guess both of them are RVSM certified.
AMVI_Rider Posted August 1, 2018 Author Posted August 1, 2018 That's above 18k for all, isn't it? civilian and military. 18k is just for US/Canada, in most countries there are Transition Altitudes when climbing (published on charts) and Transition Levels when descending (given by ATC). https://en.wikipedia.org/wiki/Flight_level There's a note in Hornet and Rhino NATOPS that any degradation in equipment status should immediately be reported to controlling agency when in RVSM so I guess both of them are RVSM certified. Legacy Hornet are not RVSM capable. Only E/F/G have been certified. [sIGPIC][/sIGPIC] Author of DCSMP and VRK Ryzen 5 3600X - 32GB DD4 3200C14 Win10 64 - Geforce GTX 1080Ti Hotas Warhog + Virpil T-50 base - Saitek Combat Rudder Pedals - Cougar MFCDs - Custom head tracker 35" UWQHD main display + 22" MFCD/Helios display / Rift S 2x256 GB SSD - 2Tb Caviar Green
Knives Posted August 1, 2018 Posted August 1, 2018 Only for the sake of correctness, that's not fully correct: switching to standard pressure is needed because altitude measure with QNH or QFE reference is valid only in proximity of the departure airport (where QNH/QFE is measured). When leaving "local area" your altitude referenced to QNH means nothing compared to other aircraft with different departure location and this is a big safety concern. Compensation and accuracy of the instruments have an influence to the evaluation of the standard vertical separation by the ICAO which must consider all kind of avionics (if any). That's why only special equipped aircrafts may flight into RVSM airspace.Exactly what I meant. But I shortened my answer. Atmospheric pressure is not static/fixed, different areas have different pressures. So to enable all aircraft to speak one language, all of them should use the same base for calculating BALT. Higher than transition level, they will use the standard baro, and for lower levels they will use current local area baro setting.
AMVI_Rider Posted August 4, 2018 Author Posted August 4, 2018 I did a test today and the difference between standby and hud altimeter is not related to airspeed/mach number. Seems that the only parameter considered is the absolute altitude, so, what we have is not the altimeter position error. I tried 30 angels from 0.48M up to 1.02M and the standby needle didn't move at all. [sIGPIC][/sIGPIC] Author of DCSMP and VRK Ryzen 5 3600X - 32GB DD4 3200C14 Win10 64 - Geforce GTX 1080Ti Hotas Warhog + Virpil T-50 base - Saitek Combat Rudder Pedals - Cougar MFCDs - Custom head tracker 35" UWQHD main display + 22" MFCD/Helios display / Rift S 2x256 GB SSD - 2Tb Caviar Green
Recommended Posts