Aerosoft official retail partner for Microsoft Flight Simulator !! 
Click here for more information

Jump to content

Sabretooth78

Members
  • Content Count

    282
  • Joined

  • Last visited

Everything posted by Sabretooth78

  1. In an attempt to root out a possible issue on my end, I reinstalled the buses (A318-21 and 330; with Windows virus protection turned off), repaired all the C++ libraries and ran the Netfx repair tool. The issue still persists identical to as I reported it above.
  2. Since installing the latest full build (1.3.1.0) of the A320, I've noticed that the outer COM dials won't "turn over", i.e. when standby is set to 136.xx, dialing up on the outer dial will not cause the number to cycle over to 118; likewise I can't cycle down to 136 from 118. The minor dial will roll over, i.e. 124.95 -> 125.00 -> 125.05 but again won't cycle past 136.xx or 118.xx. I also seem to be seeing the 8.33 spacing, i.e. x.000 -> x.005 -> x.010, etc.; which I didn't see before this last update. I did a quick search and didn't see that anybody else has reported this behavior. Is it possible there is something I've done that could be causing this?
  3. That sounds like the same issue - when the issue appears during climb, Managed Mode will still honor the correct speed (that shown on the MCDU) but while in cruise it will honor the incorrect PFD-displayed speed. Selected Mode and manual flight will work perfectly OK of course, you just need to have your speed target in mind since the bug will not be correctly set. This all seems to go away when the descent phase is entered - I don't believe I've ever encountered the issue then, while it seems to occur quite frequently especially during climb.
  4. Another takeoff from KJFK, and another instance of the managed speed issue immediately on climb out and persisting through cruise. This again occurred on another departure from KJFK on the JFK5 departure. I followed the same procedure as in the previous flight, excepting that I did not change the acceleration height this time (kept it at the default 1500' AGL). Flight Plan: KJFK F360 DCT WAVEY DCT EMJAY J174 SWL DCT CEBEE DCT WETRO DCT ILM AR15 HIBAC DCT ORL DADES6 KTPA Commanding 204 kts on climb - MCDU PERF calling for 306/0.79 as appropriate. Commanding 106 kts during cruise: Logs attached. Logs3.zip KJFKKTPA_PDF_18Jan20.pdf
  5. While the F-PLN page shows the correct times for flights crossing 0000z, I've noticed the times shown on the various PERF pages, FUEL PRED and EQUI-TIME POINT are still incorrect, as in too high by 1440. PERF CRZ (PERF DES, FUEL PRED and E-T POINT are similar; I noticed it too late to check PERF CLB) F-PLN for comparison:
  6. FYI, I just ran the update for the A318-A319 and A320-A321. They both ran normally, but I now have a "Aerosoft A318-A319 Professional Base" folder in my A320/SimObjects/Airplanes folder. All of the files contained therein have the same modified dates as the files within that A318-A319 folder that I assume they were intended to go into (so in other words, the update seems to have been applied to the A318/A319). However, the same-named files in the corresponding A320/A321 folder appear not to have been updated (modified date 23 Dec). Can I safely assume that the files in the extraneous A318-A319 folder were intended to go into the "Aerosoft A320-A321 Professional Base" folder?
  7. I've noticed what I believe to be the same behavior in the past - posted in this thread from a while back (with some pictures). For example, the OOSHN5 arrival into KBOS tends to give it fits every time - my particular experience is coming in from the SW (MERIT transition) and landing south or west.
  8. More of a curiosity than a problem - the rendering of the weather radar varies depending on whether it is set to manual vs. automatic for a given tilt setting. Is there a reason or mechanic behind this? (Frankly, I think the "manual" looks better!) Examples: Automatic: Manual: ...and a nice comparison as the update sweeps across after changing the setting:
  9. I did have this error recur with the A330 on a recent flight and I've captured logs and a save made before the error but haven't had the opportunity to test repeatability from the save. I'll follow up on that later. Back to the A320 - I just had every flavor (that I've ever experienced so far) of this error both during climb (invalid but ignored target) and cruise (invalid but honored target) I was able to repeat on the same flight plan. (I only repeated because an unrelated issue prompted me to just want to start the flight over.) Flight Plan: KJFK F360 DCT WAVEY DCT EMJAY J174 SWL J121 ISO AMYLU2 KCHS The issue occurred very quickly on initial climb when I lost my managed speed target - I don't recall the exact moment but it seemed to be at the same time each flight after reaching about 4000 feet. Process: Created a custom waypoint (PBD01) before WAVEY - "JFK/156/10" to give me an intercept target per the JFK5 SID. (Call it "self-vectoring") Takeoff runway 04L - JFK5 departure - manual climb out and turn to 99 degree heading per SID - instructed FO to set selected heading. Acceleration height 3000 ft, command FO to set selected speed 240 kts (I like to do this to prevent overshoots); follow procedure to 4000 ft then turn to PBD01. (Error began somewhere around here.) Continued manual tracking to PBD01 and then turn to WAVEY, set managed NAV. Continue manual flight to TOC. (I wanted to fly manual to test new null zones on my "sidestick" controller.) Upon reaching cruise phase, the error persisted and became of the type where setting managed speed would cause an engine rollback to 100-something knots. Attached are some pictures, logs captured after each error instance (numbered per flight) and some pictures. Also attached is my SimBrief OFP in case you want to recreate the exact time and setting with AS historical weather. Fortunately she does fly beautifully manually, and even better with a FO that saves you the work with the FCU! EDIT: The error disappeared upon entering the descent phase. Those logs which had modified times after activating descent are attached. Logs2.zip Logs1.zip Pictures.zip KJFKKCHS_PDF_31Dec19.pdf LogsDesc.zip
  10. Not to pile on a dead horse, but I've seen this behavior as well (using KGS) with the MCDU fuel remaining at destination. Generally speaking, though, the actual fuel burn is consistent and within a few percent of SimBrief from what I've experienced. For instance, on a CYYZ-CYVR flight (with 1.0.0.2 IIRC), my block fuel (from SimBrief with a 1.10 fuel factor) was 33400 kgs. The screenshot was captured 1:16 into the flight (3:15 to go) with a SimBrief EFOB prediction of 21.7k-23.2k kgs. As you can see, the ECAM FOB is slightly high but nearly dead on, while the MCDU is way off. It finally started to correct around Calgary. A quick sanity check by summing the upper ECAM engine fuel flows divided into the FOB shows there is plenty of fuel remaining (almost 5 hours!) Upon arrival at the gate at 20:59 (3.5 hours later), the ECAM reported FOB was 7950 - compared to a SimBrief prediction of 5.3k-6.7k kgs.
  11. Night mode for the EFF PDF viewer on the EFB - It's still black text on white (and thus very difficult to read) even when the EFB as a whole is in night mode. (I posted this in another thread.) More variants as resources permit! i.e engines, -200, etc.
  12. Lately I haven't been using autosave but I'll turn it on for my next A330 flight. Should be sometime this week. Way back (somewhere earlier in this thread probably) when I was having these issues on the A320 I seem to recall doing just that and finding it wasn't always repeatable. Could it be a simple PFD issue? The actual autoflight does not honor it (at least not in these instances, as opposed to the instances during cruise where it does) and the correct data always shows in the MCDU PERF pages.
  13. I was able to complete my flight last night without any further GWCG anomalies. It varied throughout the flight (going as high as 38% but never going red) but finished on the ground at 30.5%.
  14. The "Briefing" page in Active Sky will give you an average winds up at the top - I would use that. Alternately, SimBrief will also provide an average winds.
  15. After executing a step climb on my latest flight, the white box around the ALT CRZ annunciation persisted for about 35 minutes, and counting. I performed the step climb as I always have in the A320 - dial new altitude in the FCU, enter VS (to smooth the transition to climb) and then pull altitude for open climb. I also pushed the altitude knob and entered "400" into the Cruise Perf for good measure after reaching the new cruise level, but that had no effect in eliminating the box. Altimeters are also in agreement, etc. Just before step climb: (note no box while at original ALT CRZ) Some time after step climb (@ YQT): Almost to YWB (Winnipeg): ...and still going strong 6 minutes later. EDIT: I stepped away, but sometime before YDR it finally extinguished. Still, lasted at least an hour. Flight plan, if interested: CYYZ F380 AVSEP5 VIGLO DCT SSM DCT YQT/F400 DCT GERTY DCT YWG DCT YDR DCT OTPUS DCT 51N115W DCT BOOTH CANUC4 CYVR
  16. Suggestion: For the EFF tab "Flight Package" PDF reader, would it be possible to have inverted colors? (i.e. white text on black background or at least sepia) Either part and parcel with night mode, or as a selectable option under either mode? Night mode is a lifesaver, but it's self-defeating when you're trying to read a black text on white SimBrief OFP - the PDF text is narrower and even harder to read than the flows in "day mode."
  17. The unfortunate fact then is that most sim aircraft follow the "majority rule" of let's call it "augmented realism". If the delay is indeed how it operates, then I'm all for that in the sim, although it will conflict with how every other aircraft is modeled - and I suffer enough from jumping between types every day lol. I'm not sure how it could be implemented, but perhaps it would be possible to provide both "feels" and let the user select which one they want, say in the MCDU3 aircraft options? It might be problematic for support (but what isn't) but it would in theory satisfy both the purists and the armchair pilots?
  18. Some observations on the clock glitches - they only seem to appear when loading the aircraft through MCDU3. Both UTC and ET fields show them while loading pax via LSK1R. Only the ET field shows them while loading cargo via LSK2R.
  19. I'm in the process of starting another flight, with the same loading procedure, and the same thing happened. The GWCG shown on the lower ECAM began at 21.3 and moved around a little during refueling but ended at 21.3% again. It then gradually declined as the aircraft loaded pax and cargo. Eventually it dropped down to 14.0% from where it went into the red hundredths starting at .14% and continuing to decline. However, clicking "Load Instant" (LSK4R) seemed to fix it; the ECAM now displays a much more reasonable looking 29.5% (which still doesn't match the Fuel Planner's 30.8% TOW but at least it's in the ballpark). We'll see if it holds into the flight!
  20. I experienced the erroneous "magenta" PFD speed again sometime after the IAS/Mach crossover, this time with the A333. Identical to my experience when it appears on the A320, the aircraft maintained the "correct" speed and the magenta number declined with altitude and simply vanished after reaching cruise.
  21. UDNOX5 arrival into CYYZ, runway 15R. The waypoint DENPI has a speed restriction of 210 kts. This was properly reflected on the MCDU LEGS page and on the ND CSTR annotation, but there was no DECEL waypoint prior to reaching it, so I had to enter selected speed in order to slow down in time. I toggled in and out of managed speed a couple of times to check, and the 210 kts managed speed did not hold until passing the waypoint - so otherwise, I would have crossed at the commanded 250 kts.
  22. Apparently my old friend (which still occurs with the A320 despite a full system rebuild/reinstall) has appeared on the A330: (The viewpoint is towards the back of the cockpit because I didn't pause my TrackIR :))
  23. I found a couple of graphical glitches with some of the instruments. Certainly nothing critical. The clock had some flashing black boxes during preflight. Duration of the flash was maybe half a second, intermittently perhaps a second or more apart. I didn't notice them reappearing during the flight; that's not to say they didn't happen, but they didn't at any time I was looking at it. The Ground Speed indication on the ND had some apparent artifacts that I only noticed after slowing down and losing digits. Pictures below: Normal Clock Clock with glitch: GS artifacts: Same as above, zoomed in:
  24. I experienced something similar last night (except without using GSX); instead of selecting "instant", I selected each line (fuel, pax, cargo, in that order) separately and let them run their course. It all seemingly worked properly - the respective amounts were correct as were the weights (ZFW, MTOW, etc.), but the CG displayed on the lower ECAM was red. There was also quite a discrepancy between the CGs reported by the Fuel Planner, MCDU3 Load and Fuel, and ECAM/FUEL PRED (see pictures below). Similarly, the trim reported in the Fuel Planner and MCDU3 did not match (and interestingly, FS2Crew set the trim wheel to something else entirely). Possibly as a result of all this (I did manually reset the trim wheel to what MCDU3 reported), the aircraft had to be "pried" a bit off the ground and I was already passing 200 kts before gear up and pretty much rocketed off into the climb. I was flying light, near full pax load but only 14600 kg of fuel so I expected the rocketing part, just not quite so immediately into the flight. Nothing that ruined the day, though. I had entered the ZFW/CG (double click LSK1R; verified ZFW matched SimBrief) and block fuel on INIT B - was there something else I should have done? If it's any help, the flight plan was CYUL/24R N0470F400 DCT BOBKI DCT MELTI DCT TORNI UDNOX5 CYYZ/15R Some pictures: Fuel Planner and MCDU Load and Fuel - CG and Trim discrepancy: Lower ECAM and FUEL PRED before takeoff: it appears (ECAM GWCG) = (MCDU GWCG)/100 (?) Lower ECAM and FUEL PRED before descent:
  25. I was simply saying that the controls were more responsive, which was the goal of the fix. I merely referenced the PMDG as an example of another large aircraft with control responses more closely meeting my expectations of what the response should be (and upon which those expectations are partly based). As you said, PMDG knows their stuff and at least has a perception of being very faithful to the prototype - so despite the many differences between the 77x and the A33x there are also many fundamental similarities (size, weight, control surface area, FBW, etc.). I would expect the handling to more similar than diverging based on that demonstrated expertise, that's all. I wasn't being critical - rather this is one excellent add-on with a lot of potential to be even better. Otherwise I wouldn't have implied a comparison to the PMDG! I don't have the authority (by experience or otherwise) to disrespect the end decision if it's based upon feedback from actual A330 pilots! I wasn't one of those complaining about the handling anyway - I did find it a little counter intuitive (why would it be so easy to get ahead of or fall behind the plane - I guess that's why they get paid the big bucks) - but that said, my second attempted landing had a 7 kt crosswind component and I buttered the landing on C/L in the TDZ so the handling couldn't have been too horrible!
×
×
  • Create New...