falcon71

Hello, I selected the SID SADA1B (Runway 27) with the IZA transition at DAAG. That intercept point is not correct, it should be to the north of the airport, not 30 miles south: I'm using Navigraph AIRAC 2501.

I have just tried it out again after the last update and the INIT B page is no longer getting filled by the acars request. I assume this was actually a bug and not the intended behavior. It now works again like it used to and is fine for me. If you have an open issue on your side, it can be closed. Sorry for the fuss!

Turn on the APU master switch and press the start button. Then turn the APU master switch off again, while the ACCEL light is shown. The APU now keeps its current RPM and consumes fuel for hours: It resumes the start process where it left off when the master switch is turned on again and start is pressed. Instead, I would have expected the APU to turn off when the master switch is set to off.

Hello, I just started flying the A300 again and in my last two flights, the INIT B page got filled with some nonsensical values: I'm not using the acars function anymore and this screenshot was taken after the INIT A page was filled an nothing else. Where do these values come from and what can I do to prevent the init B page from getting filled?

Hello, I made some landing calculations for EKCH. This is flaps 40: And this is flaps 20, otherwise with the same parameters: I Is it correct that flaps 20 requires less landing distance than flaps 40, despite the approach speed being about 10 knots faster?

Have you considered using the CO Route field to load the route? It would be ok, if it would load a locally stored flight plan. It just gets really annoying having to input long routes manually for every single flight.

I always found it weird, that the APU page is not displayed automatically. This is caused by the ECAM door warnings, giving the DOORS page a higher priority. Now, I'm not sure if I'm correct, because this issue should have been noticed by the advising A300 pilots, but the way how I interpret the FCOM, the door warnings should be inhibited until the second engine is started:

I have programmed the SID GMMN/RW35R SADI1D. Scrolling through the waypoints in PLAN mode, I noticed that the CBL VOR on the ND jumps around. In the first screenshot, it is to the north of the runway, in the second screenshot, it is close to the runway threshold and in the third screenshot it is southwest of the runway. It looks like the relative distance to the center of the ND uses a wrong factor.

Back in the old days, requesting Simbrief data from the ACARS page only filled the route. Now it seems that it fills out everything. Is there any way to request the route only?

I think this makes the problem worse. Before you could just ignore the ILS and make a safe visual landing. Now you need to ignore the ILS and the PAPI as well and this makes visual landings even more difficult. Since landings in VMC are much more common, I would prefer if the PAPI is right for that.

I agree. I would also really appreciate, if all gates would be available please.

I flew a holding and then wanted to leave the holding. I pressed IMM EXIT* on the LEGs page. What happend was that the VERT REV page opened and the aircraft continued to fly the holding. I would have expected it to leave the holding. I was able to leave the holding with a direct to the next waypoint.

I added a holding to my STAR. Based on the charts, the inbound course would be 265° magnetic and right on the track of the previous leg. I noticed, that 258° were suggested in the FMC and I changed it to 265°. I then noticed, that the hold was a bit rotated from my previous leg: The hold was then actually flown at about 270° inbound course: Could it be, that the holding was constructed using true course instead of magnetic? The holding was around DGAA with a magnetic variation of 4°W.

I just noticed that the FLT CTL title is missing on the ECAM page: The FCOM shows the page title in the upper left corner: It is also visible in this video at 13:15: https://youtu.be/CSgVmpgHmpQ?si=fHr6X5xSUhpggSB5&t=795

Yes, it was Navigraph AIRAC 2405.

Thanks Crabby for clarification. This is a misunderstanding, my issue description was not clear. Let's try again: I'm well aware that it does not draw curved segments. This is how the procedure is drawn during preflight: This looks absolutely correct to me, just like in the charts with a leftwards turn to final. Once I arrived, the procedure looks different and it became a rightwards turn: I would have expected it to still look like in the first screenshot. Again, I fly these procedures using raw data when this stuff happens, but I assume this may be a bug which iniBuilds may want to fix or at least be aware of.

Well, that's exactly what I did. What are you trying to tell me? Should we not report bugs anymore, because these bugs may or may not exist in the real aircraft?

I flew to ZMCK with the ILS Y 29 approach via SER 1. It has an outbound leg to the right at 129° with a left turn towards final. During preflight, the drawing on the ND looked correct for the procedure. However, when flying, the INTC waypoint moved to the left instead of right: I am using Navigraph AIRAC 2405.

That stuff is copyrighted, we shouldn't share those here. But search for the A310, you will find a manual with the same FMC as the ini A300.

With packs on, TO thrust and FLEX TO thrust is 104.4%: Turning the packs off increases TO thrust to 105.1%, this is correct. However, I would have expected FLEX TO thrust to increase as well, but it remained at 104.4%: Turning the FLEX TO TEMP up and down via the dial refreshes it to 105.1% as well:

During cruise, lower the MCP altitude. Go to the F-PLN page. LSK 1R will display IMM DESC, this is correct. However, an immediate descend is also initiated, when any of the other right LSKs is pressed for any other waypoints. I would have expected, that the vertical revision page is displayed for any other waypoint.

Thank you very much for you explanation. I ran a few more tests and I think I understand it now. This example is the same as the headwind example, but with the runway length reduced to 3000 meters. What put me off was that, if for flaps 15/0, flex 58° a rotation at a 3000 meter runway was possible at 158 knots, then it should surely be possible at the same speed for a 4000 meter runway as well. I assume the iniBuilds takeoff calculator uses up as much runway as possible to gain as much speed as possible, which then results in a higher climb gradient? If this is the case, then it would very well explain why a head- and tailwind have such large effects that I'm seeing, as this is not much different than changing the runway length.

I'm still trying to make sense of the takeoff performance figures. Let's take it step by step and only look at the effect of wind for now. This image assumes a tailwind of 5 knots: And this image is under the same conditions, but with a headwind of 5 knots: I would expect engine thrust to have an effect on V2, but not the wind? Why does the wind have such an effect on V2 while the thrust and flaps stay the same? Since the flaps, the weight and the thrust settings are the same, I'm curious why the wind affects VR? I would have expected VR to stay the same in these conditions. It does make absolute sense, the V1 is very much influenced by the wind, since it changes the GS. It also make sense that it is higher with a headwind. However, since VR was already possible at 157 knots in a tailwind, I would have assumed that V1 would also remain at 157 knots, since it must be less than VR. Is there a bug, that the higher V1 pushes VR instead?

Load the aircraft empty: Next, enter an incorrect ZFW of 130 tons on the INIT B page. The aircraft calculates a GW of 184 tons as expected: Start an engine and go to the fuel prediction page. It will now show the actual GW of 143.5 tons: Since the aircraft cannot know the actual ZFW, I would expect it to display 184 tons.

I recently flew to GOBD via SAKL3D ILS Z 01. I noticed, that the outgoing radial was off. I tried the approach again today with raw data: It still shows the VOR capturing mode, but that is another bug that is already reported and logged. The VOR was tracked well and I confirmed this with third party mapping tools. As you can see, the outgoing leg was drawn to the left of the actual VOR radial. The navdata was from Navigraph, AIRAC 2402. The airport scenery is from FSDG. The A310 already had issues at airports with large magnetic variation: I suspect, that this issue is still not fixed in the A300 either.