Barometric Altitude vs Radar Altitude?

[DirtyFret]

Yes, the reading in the hud is changed, but there are no computing adjustments made after messing with the kolsman setting. I tested it on ccip and ccrp. The solutions are always the same.

 

Apologies I misunderstood what you meant. Did you happen to check the EVE value or the GPS altitude (G ALT) on the POS INFO page? Maybe the accuracy of the solution has something to do with the multitude of compensating mechanisms built-in to the system. E.g. bias correction based on EGI GPS altitude, static port installation error, dynamic lag, nonstandard air temperatures, calibration point values etc. etc.

 

It would be quite logical actually that in an air-frame that has three redundacy NAV systems and a plethora of other safety backups for systems, that an extremely crucial and vital calculation (elevation/altitude) would also have more to it than just a QNH knob to rely on.

[Joni]

I absolutely agree. But that was my original doubt. Since the document says that changing the kolsman will generate an error, then I cant imagine how to adjust pressure altitude when it changes at sea level without affecting the computed geometric altitude.

[DirtyFret]

Good point Piston. It is stated:" ..may cause a bias error as great as 250 feet in the geometric altitude displayed on the HUD." (T.O 1-432)

 

No mention of error to the elevation/altitude that the IFFCC uses. Pure conjecture though - they might possibly be the same thing ( HUD geo alt and computed elevation for the IFFCC).

 

Attempting CCIP and CCRP with degraded GPS aligment (FOM> 4 for example) and baro pressure wrong would certainly give more insight on how the IFFCC target computing is modelled. I'll give it a go once I get back in the virtual pit.:pilotfly:

[Joni]

I actually thought they were the same, but who knows. I got the A-10C module a month ago and still cant believe the amount of things Im getting into, I actually learned tons of stuff by reading and asking.

 

The thing that confuses me the most is when I find not implemented things, because reading dcs manual wont help cause if it isnt modeled then its not there, and by reading the real manual I absorb a lot of information that I cant put in practice in the sim (cause its not implemented :P).

 

But as a real pilot I cant help it, I want to know how every single thing works.

[Joni]

OK, so I JUST test it.

 

EVE is always 22 no matter what crazy thing you do with the aircraft or its systems. FOM is always 1 and so on.

 

The aircraft does not differenciate if you are on nav or ccip or anything.

 

G ALT is WAY off the real altitude, like 2000 ft or so. And when you land it shows negative values (WTH?).

 

So I guess the IFFCC is half or less modeled here.

 

I must confess myself very disappointed-

[DirtyFret]

OK, so I JUST test it.

 

EVE is always 22 no matter what crazy thing you do with the aircraft or its systems. FOM is always 1 and so on.

 

The aircraft does not differenciate if you are on nav or ccip or anything.

 

G ALT is WAY off the real altitude, like 2000 ft or so. And when you land it shows negative values (WTH?).

 

So I guess the IFFCC is half or less modeled here.

 

I must confess myself very disappointed-

 

Indeed it is a possibility that it is "half or less modeled" but I think the possibility also exists that we just don't understand how complex the RL system is and neither we know how the DCS is simulating these systems and their backup/redundacies.

 

What I can tell you is that you can get GPS and INS: FOM 6 which causes a FOM* for the blended mode of EGI navigation(=bad :smartass:). Additionally this causes that no targetting solution (GUN, CCIP or CCRP reticules) are shown on the HUD. The gun fires and bombs pickle but I have no idea where :D

 

 

G ALT also for fine for me, it shows 0 when landed when FOM is 1 and properly aligned. When FOM 6 it shows a good enough approximation to the real value. When disabling the GPS by keeping it on INIT mode and selecting POS SOURCE to GPS , the CCIP, CCRP INVALID error is shown.

 

What I havent been able to alter is the EVE value. According to the DCS manual this is only valid for the NAV mode so at least in the simulation it doesn't play a role for CCIP, CCRP.

 

If I cause a fault on the CADC baro and alt sensor and go with INS FOM 6 and GPS FOM 6 and disable radar altimeter i cannot get a solution just again a CCIP INVALID message. So in conclusion I would speculate that the CADC, IFFCC use all available data presented to them to attain a accurate position and altitude for the aircraft and if this condition is cannot be fulfilled a targeting solution is not presented as a reticule. I haven't found a way to "fool" the virtual IFFCC to providing me a false solution (yet).

 

So I personally concur that while the CADC, IFFCC might not be 100% modeled it might be more than just "half or less". :pilotfly:

 

p.s. If you want to test around, GPS is degraded by ZEROIZE function, and INS is degraded by not letting it align properly. You can also temporarily disable the GPS by forcing it to INIT mid-flight and keeping it as a POS SOURCE anyway.

[Joni]

I find very strange that your G ALT is fine. Did you actually go flying around and then landed?? Cause mine showed 0 when mission started but after taking the a10 to short ride G ALT began to show incorrect information until the point I landed and it showed -41.

 

 

EDIT: I just found out that the G ALT is bugged. http://forums.eagle.ru/showthread.php?t=86075

 

G ALT should not read 0 on the ground (not at least you are on Batumi for example), it should read the corrected barometric altitude, which in my case (Vaziani) was 1492 ft.

Edited August 26, 2015 by JohnnyQ

[DirtyFret]

I find very strange that your G ALT is fine. Did you actually go flying around and then landed?? Cause mine showed 0 when mission started but after taking the a10 to short ride G ALT began to show incorrect information until the point I landed and it showed -41.

 

G ALT should not read 0 on the ground (not at least you are on Batumi for example), it should read the corrected barometric altitude, which in my case (Vaziani) was 1492 ft.

 

I dunno man, I tested it at Batumi which is more or less on the sea so that's probably why.

 

So instead of MSL it shows you AGL similarly like they give you QFE and not QNH on take off. I guess that is wrong but still the other statements I made stand. If the IFFCC cannot give you a proper solution it doesn't give one at all.

[Joni]

Yes, agree on that. Give it a try on Vaziani, go fly around and then come back to land and check the G ALT for me pls. I want to see if im doing something wrong.

[DirtyFret]

Yes, agree on that. Give it a try on Vaziani, go fly around and then come back to land and check the G ALT for me pls. I want to see if im doing something wrong.

 

What I see is that the G ALT is very slow to respond to alt changes(compared to the other methods). As discussed on the runway it shows AGL 0 instead of MSL and in level flight in aprox. 10 sec G ALT = RDR ALT. During maneuvering and landing the difference between the two (RDR ALT & G ALT) gets bigger.

 

On landing G ALT showed -10 and during the rollout stabilized to 0 (AGL) again. So you didn't do anything wrong it can and it went into the negative digits. :thumbup:

[Joni]

Ok thanks. So in Vaziani where the G ALT should read 1492 on the ground it actually reads 0. So the G ALT is behaving as AGL rather than GPS altitude.

 

Perhaps that is why the HUD altitud is always affected by the altimeter settings. The level of modeling does not make adjustments at all, it just sticks to what the altimeter says.

 

Thanks dude.