We got a new video from World of Aircraft: Glider Simulator and are asking for some alpha/beta testers! Check this post.

 

Jump to content

Sabretooth78

members
  • Content Count

    282
  • Joined

  • Last visited

Community Reputation

56 Excellent

About Sabretooth78

  • Rank
    Gliderpilot

Recent Profile Visitors

3293 profile views
  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
×
×
  • Create New...