reported Baro altitude value for calculations not taken from cockpit altimeter

Exactly. Unless I'm mistaken, the aircraft cannot know its true altitude from another source, right? It's up to the pilot to set the correct pressure. As far as the aircraft is concerned, its altitude is the one calculated by the barometric altimeter.

The hornet uses many algorithms to calculate altitude for weapon delivery. Pressure isn't one of the favorites though.

GPS altitude is the main one, corrected with the ADC, INS, pressure and others.

HUD altitude isn't pressure altitude, is calibrated altitude by ADC.

 

The hornet uses many algorithms to calculate altitude for weapon delivery. Pressure isn't one of the favorites though.

 

GPS altitude is the main one, corrected with the ADC and other stuff.

 

HUD altitude isn't pressure altitude, is calibrated altitude.

Ok, fair enough. But that still doesn't explain discrepancies between the indicated ownship altitude in e.g. the Attack page vs the target altitude. At least in that format (as well as SA and AZ/EL), all altitude types should be the same, for both ownship and target, no?

What determines the displayed target altitude (with DL off)? It's exactly the true altitude, as given in F2 view, it's not affected by the pressure setting or anything else. And the altitude difference between the target and ownship always refers to ownship true altitude and not the altitude that the Attack page displays (same as HUD).

As for the BARO altitude warning, it's still really strange that it hits exactly when the true altitude goes through the set floor. It uses neither the calibrated altitude nor the pressure altitude.

The pilot has no way of accessing that altitude, that I know of. It's not the barometric altitude that's shown on the backup altitude indicator in the cockpit and it's not the altitude shown on the HUD. I assumed that the HUD altitude was supplied by the ADC (which takes the manually set pressure setting into account), but apparently that's not the case here.

So the issue remains. Altitude calculations should ultimately be outputted by the ADC and the ADC takes the manual pressure setting into account. But in DCS, none of the functions that use altitude as a source, seem to be affected by any settings in the cockpit and they all use the true altitude, as shown in the F2 view, no matter what.

The pilot has no way of accessing that altitude, that I know of. It's not the barometric altitude that's shown on the backup altitude indicator in the cockpit and it's not the altitude shown on the HUD. I assumed that the HUD altitude was supplied by the ADC (which takes the manually set pressure setting into account), but apparently that's not the case here.

Yes it does come from the ADC, but I guess there is more into it than we can probably know.

So the issue remains. Altitude calculations should ultimately be outputted by the ADC and the ADC takes the manual pressure setting into account. But in DCS, none of the functions that use altitude as a source, seem to be affected by any settings in the cockpit and they all use the true altitude, as shown in the F2 view, no matter what.

By true altitude you mean what you called in OP DCS altitude, right? Then I guess the hornet has been all this time in a cheat state so as the systems can work way before they were simulated, thus making it know stuff magically.

ED presence in the forums is far less than usual these days, I imagine they are hard at work trying to reach the 2020 goals and not let us down again; so I hope BN or NL can jump in here and provide us more in deph information.

Wait, I did some tests and the kollsman setting DOES affect the HUD, attack page, etc. Did I not understand the issue here? :music_whistling:

The deltas in the radar must be calculated with the radar itself I think, cause those didn't change.

EDIT: the "deltas" I was talking about were actually the antenna elevation. The target altitude is indeed magically known and I think that's a bug.

Wait, I did some tests and the kollsman setting DOES affect the HUD, attack page, etc. Did I not understand the issue here? :music_whistling:

No, that's working as intended, the ADC should indeed be affected by the manual pressure setting. The issue is that we don't know what altitude that is, because it's clearly not the altitude that's used for the target alt. calculation on the Radar/SA/AZ/EL pages, FPAS calculations and the BARO altitude floor warning.

All of the above are calculated using the (very exact) true altitude, as it is in DCS (the one you see when you switch to the F2 view).

The target altitude is indeed magically known and I think that's a bug.

That's part of the bug, yes.

I see a big difference between the F2 altitude and the HUD altitude at mission start in the air. With everything correctly set.

One thing to remember here is that target altitude was already shown before GPS was introduced, so that should debunk most of the GPS theories. It could have been updated to use that though, but would that be done if there is a posibility of having a GPS denied/degraded scenario, when you have self-contained air data always available? I don't know the real answer, and it is probably difficult to find in the public systems documentation, but my guess would be that it is likely referenced to ownships's baro altitude.

Probably something for ED to check with SMEs

I see a big difference between the F2 altitude and the HUD altitude at mission start in the air. With everything correctly set.

F2 altitude is just the world Y coordinate, so it is normal that you see a difference between your indicated altitude and true altitude, unless you are at ISA and without any kind of instrument error (if that is simulated).

 

F2 altitude is just the world Y coordinate, so it is normal that you see a difference between your indicated altitude and true altitude, unless you are at ISA and without any kind of instrument error (if that is simulated).

I was under ISA, sorry I thought it was assumed to be logical and I didn't clarify that.

One thing to remember here is that target altitude was already shown before GPS was introduced, so that should debunk most of the GPS theories. It could have been updated to use that though, but would that be done if there is a posibility of having a GPS denied/degraded scenario, when you have self-contained air data always available? I don't know the real answer, and it is probably difficult to find in the public systems documentation, but my guess would be that it is likely referenced to ownships's baro altitude.

 

Probably something for ED to check with SMEs

It is not referenced by that as stated here many times. It doesn't change when changing kollsman window.

It seems that the AI ignore the weather conditions set in the ME and set its altitude based on ISA (15°C and 29.92).

AI flies true altitude

Great discussion.

My hunch is that DCS has basically been "fudging" correct altimetry for some time. Seems the underlying code all uses "DCS true" altitude, and only in some specific cases, such as player/client aircraft altimeters, does it appear as though any additional pressure correction is able to be applied. I guess 10+ years ago, when the entire ecosystem was no where near as complex or realistic as it is now, this wasn't really noticeable. Unfortunately with the plethora of additional data sources and emphasis on realism that DCS has today, it is starting to become a notable issue.

All aircraft. Including AI, should have the ability to correct their altimeter for changes in pressure, and all systems that use altitude as an input such as radar, datalink etc, should be using this corrected figure.

Unfortunately, I picture this as a hugely complex issue to solve though and almost certainly exists well beyond the F/A-18 alone.. The weather system, AI logic, and individual avionics of almost every aircraft in the game would need to be updated. 

Not to mention procedures and education on altimeter SOPs. A lot of people incorrectly apply civil procedures to a military/combat operations, when it simply doesn't make any sense to use a transition layer in a combat environment. It’s not like I’m going to change my altimeter as I dive from 20k to 10k whilst dropping Mk83s. It's normally keep simple with one (or two if there’s a significant difference) theater wide QNHs. This is sufficient to provide air to air separation as everyone is on the same setting. Almost all combat aircraft have a rad alt, so terrain separation can be ensured that way, even if the theater QNH is slightly different to the the actual, current location pressure. As an example, the entire NTTR uses Nellis QNH, at al altitudes.

Local QNH around the airfield/carrier is the only other setting you need.

As I sad, this is a tough one for ED. There is most likely so much code, both new and old built on top of the original "true alt' concept, that it would be a massive task to change this effectively.

7 hours ago, norman99 said:

Great discussion.

 

My hunch is that DCS has basically been "fudging" correct altimetry for some time. Seems the underlying code all uses "DCS true" altitude, and only in some specific cases, such as player/client aircraft altimeters, does it appear as though any additional pressure correction is able to be applied. I guess 10+ years ago, when the entire ecosystem was no where near as complex or realistic as it is now, this wasn't really noticeable. Unfortunately with the plethora of additional data sources and emphasis on realism that DCS has today, it is starting to become a notable issue.

 

All aircraft. Including AI, should have the ability to correct their altimeter for changes in pressure, and all systems that use altitude as an input such as radar, datalink etc, should be using this corrected figure.

 

Unfortunately, I picture this as a hugely complex issue to solve though and almost certainly exists well beyond the F/A-18 alone.. The weather system, AI logic, and individual avionics of almost every aircraft in the game would need to be updated. 

 

Not to mention procedures and education on altimeter SOPs. A lot of people incorrectly apply civil procedures to a military/combat operations, when it simply doesn't make any sense to use a transition layer in a combat environment. It’s not like I’m going to change my altimeter as I dive from 20k to 10k whilst dropping Mk83s. It's normally keep simple with one (or two if there’s a significant difference) theater wide QNHs. This is sufficient to provide air to air separation as everyone is on the same setting. Almost all combat aircraft have a rad alt, so terrain separation can be ensured that way, even if the theater QNH is slightly different to the the actual, current location pressure. As an example, the entire NTTR uses Nellis QNH, at al altitudes.

 

Local QNH around the airfield/carrier is the only other setting you need.

 

As I sad, this is a tough one for ED. There is most likely so much code, both new and old built on top of the original "true alt' concept, that it would be a massive task to change this effectively.

 

JTACS, combat control or whoever will provide local altimeter for ops area. Usually, civilian traffic is 'chased away' from the area.  Transition alt (whatever it may be for this part of the world) would not be of much concern.

Hello,

Are there any news about this? As the BARO warning is, among other things, used to alert of the floor, the current implementatio where it goes off at the true ("F2") altitude rather than the indicated altitude, looks very wrong. It is described in NATOPS as "Barometric Low Altitude Warning" so it only makes sense for it to be barometric.

EDIT: quick&dirty laptop+keyboard track attached showing it

baro.trk

The issue is indeed still there. At high temperatures and high levels the difference can account to more than 1.000 ft even. I've been thinking about other solutions, but for me the easiest solution was to use the cockpit arguments of the SBY altimeter to get the actual altitude which is shown to the pilot. It is a bit tedious and far from ideal, but hey it works.

Edit: Actually I've stumbled onto another interesting bug/feature here. Altimeter is set and left on 29.92, HUD is on BARO source.

                -- DISCREPANCY IN DCS HUD/SBY ALTIMETER
                -- 0-20.000 ft HUD=SBY
                -- 25.000 ft HUD, SBY 24.820
                -- 30.000 ft HUD, SBY 29.820
                -- 35.000 ft HUD, SBY 34.750
                -- 41.000 ft HUD, SBY 40.710

Persian Gulf, 26 C at sea level.

When checking in with Marshal / reporting "Established" in a CASE3 stack, the pilot reports the mentioned "theatre altitude", which is displayed in the F10 menu.

Example:

F10 menu altitude: 36169

HUD altitude: 34890

Altimeter setting: 29.92

"Marshal, 405 established, angels 36..."

Not ideal.

Hi,

This must be reported already but I can't find it anymore on a forum search.

The Barometric Low Altitude Warning seems to be currently using true world altitude instead of sensed barometric altitude. This makes it unusable on days that are not ISA because, as you can see on the attached track, it triggers are completely different barometric altitudes than set to.

baro_alt.trk

I believe this is the report you're talking about: https://forum.dcs.world/topic/242391-investigating-baro-altitude-value-for-calculations-not-taken-from-cockpit-altimeter/