MD82

Well after 0 issues with the original build and update 1 (About 6 or 7 flights). I am now unable to start a flight without the screens WASM-ing out on taxi out.

In the end: Actual Times: 2200 - 2220 - 1229 - 1235 / Block: 1435 / Flight: 1409 OFP Times: 2200 - 2220 - 1231 - 1239 / Block: 1439 / Flight: 1411 A350 Times: 2204 - 2220 - 1231 - 1239 / Indicated Block: 1411 / Indicated Flight: 1347 So, as you can see the block and flight times sensed is no less than 24 minutes less. As additional information block fuel used was 102.100 on an OFP value of 99.200. Meaning only a 2900 Kg difference over 14.5 hours. Which is pretty accurate. Meaning that this difference is not due to any unseen freeze or time compression. It was flown fully in real time.

I have added my "TIMES" page together with my flight's actual off blocks and airborne times. - Off blocks time should start recording when the brakes are released with all doors closed. Not after the first engine is started. - Airborne time correctly starts counting when the main wheel ground sensors release. However, - For both of these you will get an error as the flight progresses. I was pushed back at 2200. For the sake of keeping the time stamps correct I started my 1st engine at 2204 (see 1st item above). This means, that at 0929 UTC (as per picture), - My Block Time should be 11:25 and my Flight Time should be 11:09. - As per the picture however, my Block Time is 11:12 and my Flight Time is 10:55. Meaning, I have lost 13-14 minutes along the way. When I look at my OFP times, I see that over TEFFO I had an error of less than 2 minutes. So, I know that there was no SIM freeze somewhere for 13-14 minutes and that it is most probably the counter that is slow. OIS Settings: Time Compression - OFF, Max Compression 2x, MSFS 2024 - To summarize: 1. Off block time starts counting at 1st engine start instead of the first instance of brake release with all doors closed and 2., the Flight Time and Block Time counters seem to run slow.

I SECOND this BADLY. The way I have always done long flights is to set the time ONCE before the flight leave. After you come back, inevitably due to SIM loading and unloading, you will lose some seconds. I then simply accelerate back to current time. Why? - If you simply SYNC the SIM back to current time everything is screwed. Say your PC hung for 5 minutes. It unfreezes and you are 5 minutes behind. If you accelerate time back to current time, it is as if nothing has happened. If you simply let the clock only get back to current time, you are suddenly 5 minutes of fuel flow ahead. Screwing your whole OFP. - So, if you have lost time in cruise due to any hiccup and time magically jumps back to current time, your flight and block times no longer match reality. PLEASE ini, remove this stupid restriction that NO other airplane has.

If GSX is synchronised, there should be a SimBrief value under all the tank fill percentages.

What the hell. Per waypoint winds did not work for me either yesterday. I just came in to post about it

Hello, regarding these two posts, - https://forum.inibuilds.com/topic/21666-fcu-digits/ - https://forum.inibuilds.com/topic/22223-autopilot-lights-not-working-during-the-day/ where it was noted that the actual digits are not controlled by the FCU lighting knob. Is this still planned for a future update? Because as of 1.1.2 the issue persists. Xander

Hello, on the latest update and without using any import feature, but a full manual entry of the plan, winds and temps, it seems entered winds are not displayed correctly on the F-PLN page. - A : INIT B without cruise wind entered. If I inter the ToC forecast wind, there is no change to the issue. - B / C : F-PLN only shows the exact same wind as the one I have entered into the 1st waypoint after ToC. (218/13). - D : Shows the first waypoint wind entered and all previous and subsequent waypoints showing the same wind in small print. Reference waypoint "DIBIR". - E : Sample waypoint DIBIR, where on the previous picture shows "280/13", shows the planned wind entered manually into its VERT REV page. - Note that the temperature forecast does update as you enter them by waypoint. Furthermore, after the plane is airborne, the winds displayed in the F-PLN temps/winds page per waypoint, seem to have a mind of their own. The change values as the flight progresses. For example, when I started typing this post, the displayed winds at SUPEL was "216/13" whereas now, 6 minutes later, the planned wind over SUPEL is "212/14". (Entered forecast wind over SUPEL is "185/37". Xander

SEC F-PLN and STEP ALTS have been temporarily disabled. Hoping for them soon.

There is no mention of it in the Sperry FMS manual. So, I believe it is not possible.

Hello, SU15 Beta, NaviGraph NavData, 1.1.1 (HotFix) It seems, that after a certain altitude even though the thrust rating panel calculates a certain EPR for CL, the actual EPR values are lower. So, I tried to disconnect the auto-thrust and set it manually. However, even with the engines firewalled, I cannot even achieve CL EPR. In this particular case with CI of 60 and a climb speed of 325 IAS; Altitude: 27500 Climbing Weight: 163.2 Tons Total Air Temp: 6° Outside Air Temp: 24° TRP CL EPR: 1.535 MAX EPR with throttle firewalled: 1.501 This leads to excessive time-to-climb values and a struggle to maintain speed. Can the devs maybe verify this discrepancy between commanded EPR and achievable EPR? Cheers, Xander

Hey @richboy2307. I have done my best not to make VERT REV mods during cruise. I will give it a go and report back if the same happens. Thanks for the heads up.

Thanks Captain Obvious. Notice I didn't say anything about a bug.

Forgot to mention. Navigraph NavData and SU15 Beta (.12) and ini livery N173UP -600F.

On KRFD to KSLC. Via NORDK6, OCS transition. ILS 16L via WEBER. On the ground, I set both departure and arrival. No issues. I removed STAR WEBER and connected ILS 16L WEBER under NORDK. No issues. I took off and flew to about 500 miles to destination. I manually set 15000 at CARTR, then set a speed transition of 250/15000. Total freeze MSFS.

Referencing the A310 Sperry manual p. 38 Chapter 3.2 1st sentence. - The FROM waypoint (or the waypoint you have passed) should be the actual time you crossed it. As of now, the FMC just calculates the estimated time overhead from actual position back to that waypoint. Referencing the A310 Sperry manual p. 38 Chapter 3.3, bullet points 2 and 3. - The distance between the FROM waypoint to the current active fly-to waypoint should display actual distance between the aircraft and the waypoint. As of now, total leg distance remains displayed. - In addition to the leg distance between the waypoints (which ever you have slewed the F-PLN to) in lines 2 and 3 should display the course in addition to the usual distance, in the format of DIS/CRS°. As of now, only distance is shown between all waypoints .... including the ones between lines 2 and 3. Xander

Please the below forum post. It is still the same in 1.10. It's not an install issue. I tested it yesterday, and I don't remember a changelog item where this is addressed.

SU15Beta

Let me correct. it is the same problems as are being reported. Airplane flies, but panel is unresponsive. ini livery N173UP

Hello, planned on doing the SCOLA1 STAR into KRNO. MVA transition. And the RNP Y 17L. - 1st step I did was to edit the 250-knot restriction from 250/FL100 to 250/FL150 as per my preference. No problem. - 2nd step was to connect the STAR to the APPR as it finishes on a heading of 333 after KLOCK. - I deleted KLOCK from the STAR end, and poof. Both FMCs stuck. Airplane flies. Just that I have no FMC's anymore. FMC 1 went blank together with a DSPLY legend light. FMC 2 froze where it was last at F-PLN. - Also, the route is completely gone from the ND and certain instruments are behaving strangely. Xander

To revisit the FCU brightness. Although what the brightness knob controls have been fixed, there is still a misunderstanding of what it actually dims. It dims the FCU Window "LIGHTS" not the FCU window LCD current. Think of the FCU digits as being the same as a classic digital watch. The digits themselves are energized liquid crystals. The A300 FCU is the same as that, but in reverse. The whole display is energized (black) and where a digit is needed, that area is de-energized so the digit forms white. What I am getting at is that the FCU brightness knob does not control that operation, it only adjusts the brightness of the lightbulbs behind and around each of those windows. This means that even if the FCU brightness light is fully turned off, you can read the digits if there is sufficient light to see the window. https://youtu.be/-U60iLommyI?si=9doRFfGqkjyQaHQ0&t=73 https://youtu.be/5rNgIO5b7mQ?si=YSLJcL-q-RSbw3bl&t=78 Look at these time stamps. It is daylight and the sunlight lets you clearly see the digits. It is exactly the same as if I have a simple Casio digital watch on my wrist. In the day, I can see it. If it is pitch black of course I can't see it. Press the light button casts light on the display and I can see it again. Without the FCU brightness, my ability to see the digits should be governed by light or shadow cast onto it. In daylight, turning the FCU brightness fully off, should only remove the yellowish glow of the light bulbs and leave the white over black effect of the LCD.

Hello, the engine reverse sleeves are an open/close operation. Meaning, it does not matter if you have selected idle reverse or full reverse, the sleeves will fully open. As it is now, the amount of reverse sleeve operation is equal to the amount of reverse thrust applied. Xander

Saw this too. Even if the max altitude for TO and LDG was 8000, the minima can never be 8000 as well as MDA is always higher. In the SPerry FMS manual, there is no mention of character limitations in this field.

I can't find any reference to it in the Sperry FMS manual.

That's correct. But now I have no official reference. So you can close this as I can't officially verify.