Many thanks for another update on the A350.
Here are some bugs/issues/errors etc. that are still outstanding.
This is quite a long post and as such it is hard to not make it seem like a big long complaint. It isn't. I write these things because I believe in the potential of the aircraft and want to see it become as good as possible. So please read it with my thanks and love for the A350 in general in mind!
I will do a bullet point of a bug with a description of the issue and some explanation and then follow it with a screenshot exemplifying it. Sometimes there maybe a few bugs mentioned within each bullet point where applicable. I hope it is easy to follow. Please do get back to me if you require more information - this applies to the iniBuilds team, and to anyone who is interested, also happy to discuss things (when I am not tinkering with my AB MSFS Atmos presets...)
GSX PAX numbers still do not match OIS Passenger Numbers. You can see here GSX says it has boarded 367 PAX, but the OIS Loadsheet only shows 357.
You can also see that the seat map has many empty seats and matches neither of these numbers.
The various screen brightnesses are not consistent when on the same brightness setting. This renders the DU Master Brightness useless. You can see that the Lower Displays and OISs are a completely different brightness to the upper displays on the same setting.
The Altitude Predictions (or constraints before Fuel and Load and Perf figures have been inserted) on the F-PLN page do not respect the TRANS ALT/LVL. You can see here that the TRANS ALT is 6000. Therefore, UMLAT should show a constraint of 6000 not FL060.
The throttle detents only make a sound when the levers are moved ‘back’ into the detent, and not when they are ‘advanced’ into the detent. Here is a video demonstrating this, you can only hear the detent sound when the throttle is moved back into the CLB detent. This makes setting thrust for take-off annoying, as there is no audio clue that you have got the lever into the FLX MCT detent.
There seem to be weird pink textures at the base of the windshield wipers, this may only be on this aircraft, or it maybe generic. Either way, the registration is G-XWBM.
The TO THS does not match between the OIS T.O PERF page, the display at the bottom of the PFD, and the TO PERF MCDU page. Here you can see it gives 32.1 on the OIS and MCDU PERF pages, but gives 32.0 on the display below the PFD. However, the aircraft does automatically set 32.1 after engine start as can be seen on the display below the PFD.
The ECON managed descent speed does not match between the DES PERF page and the F-PLN Page. Here you can see the DES PERF page is showing that the ECON Descent speeds will be M0.84 then 322kts on conversion. However, the F-PLN page shows M0.85 at (T/D) and SHAPP, indicating that the aircraft will descend at M0.85 prior to conversion to IAS.
There is a discrepancy between the VSD and the Level-Off arrow on the ND in terms of where the aircraft will level off according to the calculated profile. You can see that the VSD is saying the aircraft will level off before BUR, whereas the magenta level-off arrow on the ND is shown after BUR. Interestingly here you can also see yet another discrepancy. 6000 is in magenta below the Speed Tape, but the predictions on the F-PLN page for BUR, and D356D, and UMLAT, show FL060. As already mentioned above, this FL060 is incorrect because of the TRANS ALT of 6000.
The level-off arrow is in totally the wrong place here. The aircraft is at 6000ft in OP CLB with a FCU Selected Altitude of FL320, and yet the level-off arrow is behind the aircraft.
In general things related to the vertical and speed profile of the aircraft, in terms of predictions displayed on the F-PLN page, or the various PERF pages, or ND Symbology such as circles round waypoints, and the Level-Off arrow are very poor. These, as are all the things mentioned in this topic, are basic level systems. They really should have been correct at release, never mind countless updates later. They are also a mess on iniBuilds other airbus Aircraft. I hope they can be fixed and applied across the fleet.
Whilst on the subject of these PERF pages. The section of the DES PERF page showing SPD CSTR is implemented incorrectly. Here you can see it shows 210 KT / TLA/13. It is showing the final speed constraint on the flight plan. Whereas it should show the next upcoming speed constraint, whether this be the 250 KT restriction at FL100 or a restriction at a waypoint if there is one before the point at which the aircraft is calculating it will decelerate to 250 KT to meet the FL100 restriction. I.e., it should show the restriction or constraint for which the next magenta dot, indicating a speed change, on the route on the ND applies.
Again on this page, later on in the flight the DES PERF shows MACH 0.84 and SPD 322. This is incorrect. When in the DES page, this section should show the current ECON managed speed targets. Prior to conversion to IAS, it should show the MACH target and the conversion speed. Upon conversion it should show the SPD target and the number in the MACH section disappears. Then once the aircraft is targeting a SPD for a restriction or constraint, it should show this targeted speed rather than keep the ECON DES speed. So here it is showing M.84, and 322. This is incorrect in two ways. The aircraft is already through the conversion to SPD so if there was no active restriction or constraint it should simply show 322 with no MACH. However, this would still be incorrect as the aircraft, in fact, is targeting a speed to comply with a restriction or constraint, as it can be seen that it is targeting 250 kts. (Look at 250 in magenta at the bottom of the speed tape on the PFD). Therefore, the DES PAGE should simply show 250 KT (without any Mach shown – it is already through conversion).
Whilst on the subject of SPD/MACH conversion and vice versa, the logic of the iniBuilds aircraft is still incorrect. At the moment, it simply shows SPD on the FCU (and on the FMA if applicable) below FL290 and shows MACH above FL290. This is incorrect. It should show SPD when targeting an IAS speed, and MACH when targeting a Mach Number. Here you can see that the aircraft is targeting 316 IAS in the climb. The conversion is at MACH 0.84 (as can be seen on the CLB PERF PAGE). The aircraft is bang on the target speed as can be seen on the speed tape on the PFD – it is right on the magenta bug, and this 316 is currently equal to M.814, so we have not yet reached the conversion to MACH. Yet the FCU is displaying MACH. Incorrect. The aircraft here is targeting a speed, and, therefore it should show SPD on the FCU.
An even more simple one, and a regression. MORA is missing. Both on the ND and the VSD. Hopefully you don’t need a reminder of the different values displayed. The ND should show the MORA within 40nm range ring, and the VSD the safe altitude along the route.
I think this one is another regression. As can be seen, there is a constraint of AT or ABOVE FL260 at INPIP. The FCU Selected Altitude is below this - FL200. This means that the altitude given below the speed tape should still be FL260 in magenta because it is a constraint, and not FL200 in cyan. It should not show the FCU Selected Altitude unless this is above the constraint altitude. The Level-Off arrow also seems to be indicating the point at which the aircraft will reach FL200 as it is in cyan, again this is incorrect. It should be a magenta arrow showing where it will reach FL260, as this is a constraint above the FCU Selected Altitude.
This example again shows the mess of vertical profile prediction indications. You can see that on the ND there is an Amber circle around INREV indicating that the aircraft will not meet the constraint of AT or ABOVE FL200. However, on the F-PLN page, the aircraft is indicating it will be at INREV and FL200 and the magenta asterisk indicates that the constrain will be met. I would hazard a guess that the ND symbology is correct in this case, and the F-PLN page is wrong given that the aircraft is high on profile and high on speed. Incidentally the FL200 should be in magenta underneath the speed tape as it is a constrain at FL200 irrelevant of the fact that the FCU Selected Altitude is also FL200. The way these indications are displayed and the Level-Off Arrow is implemented is juts really bad I am afraid to say. Please do let me know if you need clarification of the logic behind the level-off arrow in both climb and descent in managed, open, and VS modes. It is different for all three. At the moment it is just a mess. The colours magenta/amber to signify whether a constraint will be made are inconsistent across the various displays and do not match with the F-PLN page predictions. The F-PLN page predications themselves are also often incorrect. So to sum up here, 3 things needed. Proper level-off arrow logic, consistency between magenta/amber across ND circles and F-PLN page asterisks, and F-PLN page ALT and SPD predictions are often miscalculated (as in the example below where the ND is probably the correct one.
By the way, here is an example from another flight. The F-PLN page is predicting the aircraft will be at BREG0 at 50ft... its already at 4800ft and climbing. Clearly completely wrong. This page just needs to be much more robust.
Again on the F-PLN page there are errors with how the (SPDLIM) pseudo-waypoint is sequenced. In this flight it was displayed twice, obviously incorrect. In the above shot the (SPDLIM) should not be there at all. The aircraft is already targeting 250kts as it calculated to slow to 250 kts earlier on in the flight. This is shown in the shot below. The aircraft calculated it needed to slow to 250 kts between SHAPP and ABEVI. This is presumably for the 250KT constraint at ESKDO. Therefore, the (SPDLIM) should not be there at all. The aircraft is never actually going to slow down to meet the 250KT at FL100 restriction because it has already previously slowed to 250 kts to meet a constraint. In addition, there is yet another error. Supposing the aircraft was going to slow for the 250LT at FL100 restriction, the (SPDLIM) pseudo-waypoint should appear on the F-PLN page at the point when it will begin the deceleration, and should be sequenced by altitude. So, in the example above the (SPDLIM) might be in the correct place (this is hypothetical – as previously discussed, it shouldn’t be there at all in this case!), but it has the wrong ALT. If that is the point where it will decelerate the altitude should be something like FL280 (between FL307 at SHAPP and FL271 at ABEVI). Or if it was going to decelerate bang on FL100 (it shouldn’t as it needs to begin the deceleration before this) the (SPDLIM) pseudo-waypoint should be sequenced in the correct place further down the flight plan so that FL100 is in the correct place sequentially and not between FL37 and FL 271. Hopefully this makes sense of the multiple errors at play here.
Once established on the ILS, the F-PLN page and the VSD, and the (FLAP2) pseudo-waypoint are just a complete mess I’m afraid. I mean just look at it. Why is the VSD showing a climb? Why is the F-PLN page saying we were at FI24 at 3580 (we were well below this as can be seen by the fact we have only just passed it and are almost 1000ft below what it says? Why is it predicting we are going to be at the runway threshold at 2520ft? Why is the (FLAP2) pseudo-waypoint only 3 miles before the runway? Just needs sorting out I am afraid.
I also noticed, but didn’t manage to get a video, the aircraft is still adding thrust and trying to level off at some constraints even though the vertical path continues on the same trajectory after the constraint. This is incorrect behaviour. The aircraft should simply continue descending at either idle or with whatever thrust was required to maintain the target speed on the path.
That brings to close various systems type stuff just noticed on one short simple flight. None of this involved delving in detail, just basic Airbus logic that is noticed very easily.
I am slightly running out of energy writing up this report, it has already taken hours and hours typing it, checking things, gathering screenshots, having to find the correct ones and uploading them to a hosting site all the while knowing it will most likely be ignored. So I will be brief on other areas.
In terms of flight model, the aircraft still lifts off the runway at far too shallow a pitch. On this flight the aircraft had a positive rate of climb and was wheel off at only about 3 degrees of pitch. Almost VTOL like.
HUD – I am afraid this is completely useless. As can be seen below there are multiple errors. This is even without going into formatting errors which I guess just have to be considered very low priority given the other glaring mistakes. (Similarly formatting errors in many other things I have simply ignored. Der Michael is doing a great job with these reports anyway).
The pitch scale is completely wrong, as can be seen below it does not match with the pitch of the PFD at all. The aircraft’s pitch according to the PFD is above 10 degrees, whereas the HUD shows about 8 degrees. The FD shows on the PFD about 13 degrees and on the HUD about 9 degrees.
Then on landing, as shown below, there is a discrepancy between the VS indicated. -700fpm on the PFD, -600fpm on the HUD.
The flight path vector is also pointing indicating absolutely nowhere near where the aircraft is actually going. The aircraft is bang on the LOC and GS flying the track perfectly aligned with the runway at the correct VS for a 3 degree GS, and yet the FPV is pointing miles off to the left and of the runway, and beyond it.
I really, really hope we can start to see some progress with this aircraft. I am afraid it has been out a long time now and had countless updates and is simply nowhere near the quality it was priced and marketed as (unparalleled realism etc.). The above are just elementary things noticed in one short flight without pushing the systems at all. I was really hoping with the longest gap between updates some real progress would have been made, but bugs and errors are all still there.
Regardless of the above, as I ever, I thank all the team for their work on the project and appreciate their enthusiasm for taking it forward.
Please do reach out if any of the above is unclear or you require further information.
It would also be amazing to have some way of tracking these bugs, it rather seems that loads of bugs are reported and then people have no idea whether it is actually logged as an issue, or reproducible, or ever going to get fixed and it would be better on our behalf to just give up. As ever I am more than happy to do anything I can to try and help, clearly somewhere in the process all these simple things are being missed. I would be happy to help in any way to make sure they don't get missed!
Thanks as always, and best wishes.
