CDU391ee

[mauriceb]

I did a long flight yesterday between New Delhi & Hong Kong using all the PM latest Boeing builds including CDU391ee.

Entering a SID for the departure worked great. Then the flight was uneventful but about 2/3 of the way, the plane started to descend when it wasn't supposed to. All I had done was lower the altitude on the MCP so that the plane would be able to descend when called by the CDU. Anyway, it went down 3000', so I forced it to climb back to cruise altitude and restarted VNAV.

After that, I changed some of the calculated altitudes & speed further on since I always end up too fast if I leave thing alone. I was cruising at 33,000 ft at that time and just lowering the altitude for a later waypoint also changed the altitude on the CDU for my current next waypoint which I did not want to change. However, even though the altitudes for my next 3 waypoints had also been lowered (which I did not ask it to do), the plane remained at the current altitude and did not follow the new CDU altitudes.

Eventually. I got back on a normal expected path somehow (at a lower altitude than what I had planned). When I got closer to destination, I selected a STAR and as soon as I did that, the plane started to turn. I did not let it continue the turn so I pressed Exec before I was ready, to see what would happen. The plane then resumed the expected course.

I think one way to get around this problem when the plane changes course when you add a STAR is to temporarily used heading hold, add the STAR & transitions, check that they were added correctly and then hit Execute and resume LNAV.

Anyway, the STAR waypoints got added correctly but not at their correct altitude based on the charts. I corrected everything and the rest of the flight was uneventful.

So, I think we are getting there, but it seems to me there are still many bugs which need to be resolved. Some I'm afraid may be due to my inexperience with real procedures and what is to be expected in a real aircraft, but I will submit my findings anyway to PM support and see what develops.

Maurice

[rippey]

I think one way to get around this problem when the plane changes course when you add a STAR is to temporarily used heading hold, add the STAR & transitions, check that they were added correctly and then hit Execute and resume LNAV.


I am not familiar with the FMS in the 737 (besides the PM version), but in real aircraft I have flown, if I had already passed the initial fix of a star, and I had to change the runway, transition etc, I would go into heading mode before executing the change or else the aircraft wanted to go back to the initial fix on the star and start over. This happened with both GNS-Xls, and Honeywell FMZ series FMS, maybe this is normal behaviour for the boeing FMSs as well. Anyone drive real 737s out there and want to shed some light on this?

[mauriceb]

I am not familiar with the FMS in the 737 (besides the PM version), but in real aircraft I have flown, if I had already passed the initial fix of a star, and I had to change the runway, transition etc, I would go into heading mode before executing the change or else the aircraft wanted to go back to the initial fix on the star and start over. This happened with both GNS-Xls, and Honeywell FMZ series FMS, maybe this is normal behaviour for the boeing FMSs as well. Anyone drive real 737s out there and want to shed some light on this?


This is quite interesting indeed. This is not quite the same as what I described, but it might behave the same way as well the way I did it, which was to add the STAR before approaching the initial fix for the STAR instead of after as you described.
So, it could indeed be normal behaviour and it would really be good if a 'real' 737 'driver' (or other Boeing driver) would jump in here & comment.

Thanks,
Maurice

[michelmvd]

if I had already passed the initial fix of a star, and I had to change the runway, transition etc, I would go into heading mode before executing the change or else the aircraft wanted to go back to the initial fix on the star and start over.

This looks very logic to me, as the IAF is already behind you and you reprogram it at the moment you change the STAR, but this certainly shouldn't be the case, if you put the STAR in during your pre-descend, as then the IAF is still well ahead.
I notice that as soon you set the expected landing RWY, the aircraft starts to turn...

Have send last weekend 2 reports to Enrico, hopes they will be helpfull.

B. Rgds
Michel

[touwersl]

The behaviour of the aircraft when selecting the landing RWY was also spotted by me and reported back to Enrico. He replied to me that this should be solved in one of the latest releases.
I also saw that this behaviour is not always present. Some days ago I made some flights from EDDL to EHAM during which I didn't see this behaviour.
So it looks like it also depends on the kind of NavData that is present in the CDU for a certain airport. e.g sometimes I select an RNAV approach and nothing happens and sometimes when I select an ILS approach the aircraft starts turning. On one occasion I let the aircraft turn and it flew back to a point somewhere 180 degrees to the orginal course while the active waypoint was still the same as before selecting the RWY.
By the way; I always select the STAR before the first waypoint in the STAR.
Due to these problems I first revert to HDG mode, then select whatever I want, correct the mess (if it occurs) and then revert back to LNAV.
Not the nicest way to operate the aircraft but at least it prevents all kind of strange behaviour (especially if you'r online).

Regards,

Theo Ouwersloot

[mauriceb]

By the way; I always select the STAR before the first waypoint in the STAR.
Due to these problems I first revert to HDG mode, then select whatever I want, correct the mess (if it occurs) and then revert back to LNAV.
Not the nicest way to operate the aircraft but at least it prevents all kind of strange behaviour (especially if you'r online).
Regards,
Theo Ouwersloot

Reverting to HDG mode before messing witht the STAR is definitely the way to go it seems. Whether it's a CDU problem or a Navdata problem is the real question here.

On 2 flights now, I inserted a SID before takeoff and this also messed up the route totally. On another flight, it worked perfectly. So, I really think this may have nothing to do with the CDU software and more to do with Navdata. But the jury is still out on that one :???:.

Thanks,
Maurice

[touwersl]

I didn't see the route messed up up due to inserting a SID (I'm lucky I guess...).
But to be a bit positive in spite of all these troubles, it's not all negative on the CDU side in my opinion. Except of these issues I think the CDU is becoming more complete in time and performs well in all other aspects.
I'm convinced a solution of these issues will be found in due time.
Just my thoughts....


Regards,

[pylet]

I just came from the PM web site and the updates page shows the B-CDU to be 390 which I have and is working great. Where did you guys find CDU391ee? I've noticed this quite a bit, everyone seems to have a newer version than me and when I go to the PM web site and click on updates I see I have their most current version. Even when I run pmCheckver.exe I get the same results as those on the PM web page. Are you guys beta testers?

[Bob Reed]

Hi pylet.You have what is considered the latest stable build if you have the version from the updates page. Look at the top of the updates page, left hand side, see the link that says intermediate builds? http://www.projectmagenta.com/downloads/builds/latest/?M=D Thats where this newer version comes from but be warned... It is not always stable, it is there for testing purposes!!

[pylet]

Oh ok... I thought I was stuck in internet cache **** or something. Thanks for the reply.

[michelmvd]

Update of the disappearing route story ...
Did last weekend some flights to Casablance and back from Ostend, with the new Navigraph 0706 for PM. (Version 10 is mentioned on init page)
Setting up the SID to MAK2S, didn't gave any problem.
But the problem with the disappearing route when entering a STAR remains the same.
As soon landing RWY 35R was entered in the DEP/ARR page - not yet EXEC, the aircraft wanted to go back to EBOS and the complete route was visual again in the CDU, inclusive the STAR. (The STAR imput was done at more than 100mls of T/D and long before the IAF.)
After I deleted the previous waypoints again, the situation came back to normal. So no improvement when we comparing with the test NAVDATA. It looks still very difficult to use the PM-CDU with up to date navdata.
Some situation also in the return flight with the FERDI arrival. Here even after deleting the complete upcoming route again, the CDU and the PC become extermely slow in handling data.

Will once again update support.

B. rgds
Michel

[NicD]

We just completed 2 flights: YSSY <> YBCG return. Have all latest PM builds and navdata operating. It all went very well - many of the old issues seem gone and the CDUs are much more stable.

Just have to remember to select rwy, then star - not other way around as that stalls it for a time.

On the Engravity CDU I found that if you press S-EXEC, then exit that page, it wakes up the PM-CDU if its stalled for some reason.

[michelmvd]

Here it looks once again, that the problems are not coming up on all routes and STARs. It clearly depend on which STAR you are using. By informing support about which STAR is concerned, we maybe can narrow the problem.
Only a pitty there is most of the times no reaction when you send the reports to support these days.
Normal procedure for STAR input is of course first the RWY / APPROACH and then only the STARS for that RWY/APPROACH should be available for selection.

B. Rgds
Michel