ILS suddenly dies in FSX

Hi everyone,

Could there be a bug in the PM-MCP software or in the handshake with FSX? I tried to be as specific and as detailed as possible.

Use Case:

While in final ILS-approach with the glide-slope bug almost in the middle, I push the APP button. Nine times out of ten the plane stays on the same altitude, while the glide-slope bug starts moving downwards. It looks as if FSX doesn't (always) get the message that it should follow the glide-slope. Several re-select attempts do not change the behavior of the plane in any way.

Since only the APP button has this problem, and f.i. the VOR LOC never, I am thinking of a software- or handshake bug. The button lits and when we run the CPFlight test software, the button works 100% of the time, so I don't think it is a hardware issue.

It happens (not always) on crowded airports with heavy scenery like EGLL and EHAM and on desolated ones like EHGG ILS RWY23.

I tried to overrule by pushing Ctrl+A on the FSX-keyboard to see what happens, but since I have deleted all gauches in the config file, I am not surprised that FSX cannot handle the Ctrl+A. Perhaps it should, what might prove something.

As I understood from a friend, who is a professional captain and instructor for KLM on the 737, when it comes to ILS following, the VOR LOC and APP buttons should always overrule any other signal or system when selected.

I fly FSX with automatic generated weather. When in level flight, weather changes sometimes make the altimeter swing like mad. The autopilot and autothrottle do everything to correct the situation. My guess is, that when weather change happens during final approach, the APP button signal gets lost somewhere, because I hear and see the same kind of actions. Since I am on local QNH that should not happen, but it does. First I thought it had something to do with the scenery, so I started to test at EHGG ILS RWY23. Same problem. When I keep up the automatic real world weather generation the problem exists on every approach. When I switch to No weather-Clear sky's the bird follows the glide path like it should. So if I am right, and the problem does not come from another dark corner of all software, it seems that the APP button signal does not always triggers FSX to follow the glideslope. Since this never happens with the VOR LOC, which I used just before I click in APP, I think both signals follow different paths to FSX.

Anyone familiar with this behaviour?


My hard- and software configuration can be found on http://www.b737sim.nl/components.html


Greetings,

Benno

Not sure about the PM problems, but it has been a pretty wild ride across Europe for the last few days. The pressure is constantly changing screwing with the altitude hold and the assigned altitude.

One second I'm 300' below assigned and the next five seconds I'm 500 above.

I've tried the pressure smoothing in FSUIPC but it doesn't work. It seems like FS is trying to get data from several WX sources at once and doesn't know which one to use.

Irritating to say the least.

Same here! Try reduce FPS to 20. Go to MCP.ini and check You have 80 in
cycle of milliseconds. There is something in FSX and PM.
Pm stuff says the software is ok. Problem can be a A/C model, but I doubt.
I had this with different models.
I hope a fix comes one day.

...also have You deleted all texts except view config
lines from Your a/c panel.cfg?
try other aircrafts also. When I had deleted fsx sp2 but
kept sp1 some texts started to blink in exam screens?
I suppose the install of rex did not made it?
Never ending misery. I try to solve this g/s problem and
if I cannot fix this I'll go for AST.

Updates in Pm site!!!

Thanks everyone for the replies!
Seems that we're not alone with this problem...

Hi

This problem only relates to FSX. It is known about but only seems to happen on some systems and only sometimes. This makes tracking and solving the problem difficult. It is an on-going issue and we hope to find the cause soon.

Regards
Jonathan Richardson
Project Magenta

Did you try pushing APP well before the glideslope indicator descends toward the middle? It may just not be picking the glideslope up in time, which would cause you to continue at a level altitude. Since you cannot use APP on most APs when you are above the glideslope, try hitting APP before there is any deflection in the glideslope indicator at all. The aircraft should maintain level flight until the glideslope is captured in APP mode, which could be several minutes after localizer capture in APP mode.

I'll give it a try tonight! Thanks for an advice.
I wonder what are those critical commands or acts that has to be
Performed before locking to the g/s path?

Quote:

---

Originally Posted by mmakela

I wonder what are those critical commands or acts that has to be Performed before locking to the g/s path?

---

I am not sure I understand the question--are you talking about checklist items? If so, I am not sure for your particular aircraft. For light GA aircraft, use CGUMPS:

Carb heat (if applicable--normally aspirated engine)
Gas (fuel--fullest tank, etc.)
Undercarriage (landing gear down)
Mixture rich
Power, props, pumps
Seatbelts, safety, switches (lights, pitot heat, etc.)

airbus A320 is my aircraft. I mean that all flight phases are correctly
Made from programming mcdu to fcu handling. Pressing right buttons
at right time. I follow routines from real life videos and manuals
such as great a320 training videos in youtube and manuals from mycockpit
Site.

Got you. :) I know nothing about the A320, but a friend of mine is a Captain for United flying the A320 out of KIAD. I can ask him. What specifically do you want to know?

Thanks David, good to know this option. I'll get back to You
when there is a question that needs some clarifiction. Right now I
have lots of excellent resources to check. Pm has announced they
have checed their software with real pilots. I wonder if they used
FSX thought.
I'll try push APP button right after ap LOC comes alive.
Then I check pm fcu window that all seems ok. We'll see
what happens.

Great. Let us know how it works out!

Hi

Just to clarify, it is an error, which is a random error, it is not generally caused by ops. If you perform a correct procedure for VOR/LOC and eventual GS capture, the GS problem can still happen in FSX (not FS9 [at least I never saw it in FS9]). If you get the error, it is always just at the GS capture point. You will observe the FD going full scale up, and if you don't disengage the AP pretty quick (if it is engaged), the a/c will follow it up. The only option now is to ignore the FD PITCH commad or turn off the FD, and follow the diamonds down. The ILS diamonds are still correct. It is an error in the AFDS. We are still trying to find it and why this only appears to happen in FSX and for that matter for only a few users / customers.

Regards
Jonathan Richardson
Project Magenta

Hello Jonathan, thanks for joining discussion here.
I flew at least half Year without this problem.
It is a pity I did not notice and remember after
what did this come up. I had earlier
versions of pm software, fsx sp1, and ifdg airbus
model. I guess it came after fsx sp2 and some
Fcu update. Just guessing thought.
I hope You can fix this. Fsx looks marvellous
with flight1 European landclass and REX.
-----edit----
... I remember one experience between Helsinki and Stockholm EFHK-ESSA and its route "runen-un872-xilan".
After last waypoint TEB before turning to the left to RWY 01L it is a quite steep turn to the ILS path. The plane is
trying to stabilize to the right ILS direction 008 degree, and it usually misses G/S path.
But, if I turn to the right after TEB and go 10nm further opposite direction (190degree) from RWY then make a turn to
RWY direction, push LOC and push app just before G/S diamond reaches middle, the plane goes down as it should...

All went well. landing rwy was 19R and star was xila3p.
Just before turning to final plane dropped it's altitude agressively.
I heard v/s warning but plane stabilized to 2500ft quite soon.
I pushed app and ap2 earlier than normally. I activated appr
Phase a little bit late thought. I wonder if that caused the alt
drop as I mentioned above.
I'll keep testing...

Succeeded again. Same conditions and procedure.
... keeping on testing...

Now it seems to work. I push app and ap2 right after
Loc comes alive. My speed is 180 and plane descends
to ils vertical path. One thing is that I fly further from
Rwy to make final turns.

... And yesterday it did not. Well, before final turns the plane goes suddenly up
like go around? Then it descends and goes up again and
Then down? It stabilizes ok before
loc and g/s path but stays in altitude
that I did put in fcu autopilot, here 2500ft.
I checked mcdu approach plan and all altitudes
were right. ???

Hi

As a suggestion perhaps the best thing for those of you with this error occuring constantly is to send in the logs. You can do all the flying you like, inside out, upside down, it won't help us to solve the problem, we already know the error is there at random in FSX, but we can't recreate it.

Regards
Jonathan Richardson
Project Magenta

Great idea, can You kindly assist here a bit. How to create and what
log exactly You need? I would be happy to help here.
---
...do I send PmSystems log to You also, it seemed to crash.
It is cold &dark mode now, which I do not want. I have unchecked
those cold and dark mode. Also in pmsystems.ini it says OFF.
But when PmSystems start, overhead is cold and dark, but does not
react to any commands? There is propably some kind of problem with
pmsoftware and my io hardware (opencockpits).

Hi

This is about the MCP, not pmSystems. There is a logging function in the MCP Log=On and this will produce general and a approach log. This might be useful.

Regards
Jonathan Richardson
Project Magenta

For A320 can it be FCU log , not mcp log? I'm in work now so
I cannot check. I'll get back on this tonight.
I'll be most happy to help out here, Jonathan :-)

Yes, the FCU has logging facilities as well. If you send in logs, please be clear to mark them as the FSX G/S capture problem in the subject. As to whether the logs will contain the required specific info needed to track and find the problem I can not say at this stage but it is more likely to help rather than flying various approaches because we already know of the problem.

Regards
Jonathan Richardson
Project Magenta

In our case the GS problem always occurred just after the AP picks up the GS nodding down, the kite has the intention to follow the GS, and stops doing that, adding thrust to stay on the altitude selected in the MCP.
We talked with a KLM Captain/instructor about this. The pro's hit the AP button as soon as the Localizer comes alive, even if the GS isn't alive yet. So we now do the same. When the GS is alive and approaching the middle, we lower the IAS on the MCP with 5 or 10 kts. The plane is lowering it's speed while the GS bug passes the middle and without one exception (so far) it will follow the GS perfectly.
We'll keep on testing....

On the other hand... someone suggested to set the milliseconds in the mcp.ini file at 80 instead of within the range 50-70. We did, but then the anunciators of the gear start to behave in a very strange way. F.i. when we are at the ramp, before engine startup the EGT's start to act like a crazy windmill. So we started to play with the millisecond figure simultaniously with testing the GS problem and are still searching for the right figure in OUR system. Numbers within the range 50-70 give us a better performance.

Hi

The problem is if there is any instability in VS prior to the the GS capture, then the VS might win (depending on some other factors) and the MCP triggers into a VS mode rather than GS capture mode. (It misses what it is supposed to do unfortunately). This won't happen in FS9, only FSX. If your approach is rock solid prior to GS capture you are much less likely to get the problem in FSX, this is why it has been so difficult to trace. Now we understand more the cause, and to some better degree how to recreate it, hopefully we are more on track to find a solution.

Regards
Jonathan Richardson

Hello again,
I hope Pm stuff finds something to cure this overshoot problem.
I noticed one thig just after series of testing my IFDG Alitalia A319 (pm site).
When I make an approach with autopilot lateral and vertical managed (dotted)
sometimes it does overshoot of G/S path, but when I pull HDG to the pilot it
NEVER does overshoot. Is this just a miracle or not, but it seems true.
So, before turning to RWY heading I pull hdg to me while alt and spd are both
managed the plane turns to LOC nicely and finally follows G/S path. That small
magenta circle comes down with magenta diamond like it should.
---
One problem I still have and that is my aircraft goes to cruising level too slowly so
it makes new TOC points to the plan.