Sabretooth78

member
  • Content Count

    162
  • Joined

  • Last visited

Community Reputation

47 Excellent

About Sabretooth78

  • Rank
    Flight Student - Solo
  • Birthday July 7

Recent Profile Visitors

1704 profile views
  1. Sabretooth78

    Autopilot vs. Horizontal/LNAV Path

    Just to clarify on my last previous post, the particular airport with the problematic approach was UUDD Domodedovo.
  2. Sabretooth78

    Autopilot vs. Horizontal/LNAV Path

    I'm reporting the same problem for the FK 1D approach into Moscow, on the GISIN-BESTA-RUGEL-GEKLA turn. The path ended up a little short on the turn to BESTA and then overcorrected with a sharp left bank just before RUGEL until finally turning back right (once roughly abeam RUGEL) to make GEKLA. This was in the A319 CFM, 1.2.1.5.
  3. Sabretooth78

    Master Caution at ALT*

    Just as the title says, running my first flight of the 1.2.1.4 A320 IAE and every time the FMA has gone enters into a "star" mode (2 ALT * and 1 ALT CST *), the master caution light briefly flashes on with an audible "ding". It lasts maybe half a second. I don't believe I've ever experienced this before, but perhaps this is intended operation - or is it a bug?
  4. Sabretooth78

    flightplan UTC calculation

    Here's a manifestation of this bug that I personally had not seen before - the incorrect ETA showing on the upper right of the ND. However, instead of reading the usual 17XX or 18XX on the MCDU, the ND technically shows the correct time if you subtract 24:00 from it. Upon passage of 0000Z the issue resolved itself and the ND time correctly read 00:59. I'm assuming this is part of the same problem, but in the event it isn't, here is a screen capture of the issue:
  5. Sabretooth78

    Strange Managed Speed problem

    Per response on my thread it is a known issue and being looked at... For now the work-around is to use managed speed mode or "rebuild" the flight plan using SEC F-PLAN.
  6. Sabretooth78

    Strange Managed Speed problem

    This sounds like possibly the same issue I reported here: Ultimately, I wasn't able to successfully use managed speed until final approach. Even at around 10,000 feet, it was still targeting low; about 230 kts even though there was no speed restriction in the FMC. Curiously, in an attempt to solve an unrelated issue, I reloaded an autosave that had been saved during cruise, at a point well after the problems began and just for curiousity's sake I pushed into managed mode and voila - it was working properly (!); targeting either M0.78 or 0.79 (I forget which, exactly). I'll be attempting the return leg to KFLL probably tomorrow, so I'm curious to see if it happens again - or if I should just be boring and put it in manual mode after TOD! I can't discount that the issue is related to the 1.2.1.3 update as I don't believe I had flown an entire flight of the A321 IAE since its initial release (which worked just fine, vertical profile issues notwithstanding, on a similar duration flight of 3+ hours).
  7. Sabretooth78

    Managed Speed at Cruise

    I just encountered an issue with managed speed apparently changing mid-cruise on the A321 IAE, v.1.2.1.3. I had stepped away from the PC to make dinner, and popped back into the room to check to make sure I wasn't flying into a thunderstorm - I wasn't, but I noticed that the a/c was pitched up about 10 degrees and the speed tape was just about down into the yellow hatch. Pushing the thrust levers into TOGA didn't seem to be fixing the situation so I dialed the FCU altitude window from FL340 to FL310. Again, nothing doing, so I pushed the stick forward and nosed over, this time with the speed tape in the red (but somehow avoided a stall), recovering at around FL320 where I was then able to eventually climb back up to FL340. However, at some point during this re-climb I noticed the speed target moved from 278 down to 128 (!) so I set selected speed to M0.80 and have more or less been able to continue merrily along my way. That said, if I try to re-enter managed speed, the target drops to 130 and the engines quickly idle and re-engaging selected speed always starts back in KTS and not MACH. This is my first encounter with an issue of this magnitude with the Pro buses, in some 60+ hours of VA flying (granted, mostly on the A320 IAE). Are there any other reports of this behavior? Some pictures: Note the speed targets, however everything on the CDU appears to be correct!? Flight plan is KFLL N0464F340 BEECH5 BAHMA DCT ZOLLA A301 URSUS UL780 TASNO UL780 GAXER UL780 DALUD STAR5 SEGU. I'm not exactly sure when the behavior started, however, I do know for a fact it didn't occur at a waypoint (somewhere past GAXER), and the issue persists after passing the following waypoints (DAGUD and LIVUD thus far). Perhaps it's just some side effect of the greater problem with vertical profiles? Somehow related to flying above the OPT FL? (The speed target did change somewhere during the recovery, during which I had dropped below OPT.)
  8. Sabretooth78

    Autopilot vs. Horizontal/LNAV Path

    In what seems to be a related issue, I happened into this situation on one of my recent flights: This is on the OOSHN5 arrival into KBOS. On two of the three times I've flown this (made a save at TOD), the autopilot went berserk on the tight LONEY-RODEE-EURRO turn. During the initial flight, I quickly took over in selected mode. The second time it did not happen (I was trying to figure out an ILS issue - which I reported here and resolved), however unlike the first time I was not running in selected speed (I'm not sure if that is important). The third and final time, I was looking to ensure I had solved the ILS problem (which I had) and it went nuts - and this time only being a test, I decided to let it run its course and see what it would do. Note that the managed speed is way too low (there's no reason based on the STAR or MCDU that it should be under the VNAV descent speed at this stage (say 280 kt), but I wasn't necessarily concerned in flying speeds to the tee. I'm suspecting that is occurring as part of the acknowledged STAR/descent speed calculation troubles. Given that getting this to happen seems to be somewhat dependent on managed vs. selected speeds, maybe the two are related and wreaking havoc on the autopilot prediction code. But I digress - on to the pictures. In the absence of video, I took several screen shots in quick progression: After initially turning left per the LNAV path, things start to go off the rails just before RODEE - could it be because the sweeps from LONEY and EURRO were cutting RODEE "off" the path? George finally wakes up and realizes he was heading the wrong way and now overcorrects: Sanity returns: Spoke too soon! Returning to normal: At this point, the Bus rejoined the path and flew the approach properly.
  9. Sabretooth78

    MCDU ILS Selection

    Yes, ILS 33L. Turns out I found the source of the problem and it wasn't the Bus - it appears to have been something with the latest fsAeroData AIRAC, so therefore the actual sim navaids. Once I realized that possibility I checked and sure enough there was an update and that seems to have fixed it on my last re-run of the approach. Too many items upsetting the old apple cart once again, but thanks for considering it!
  10. Sabretooth78

    MCDU ILS Selection

    I have twice run into a problem during ILS approaches to KBOS 33L. I'm not sure if it's the current Navigraph AIRAC (1811 rev 1) or one of the recent Bus updates (running 1.2.1.3) as I know I've handled this approach recently in the past with no problem. Basically, the MCDU is pulling the ILS for runway 15R (IMDC) instead of that for runway 33L (ILIP). Both approaches feature a frequency of 110.70. I've brought this up on the Navigraph forum but between that and my inspection of ../A3XX NavData/PROC/KBOS.txt there doesn't seem to be a problem with the navdata. Can this be replicated on Aerosoft's end? I haven't had the opportunity to see if the issue is specific to this approach or is a common problem with opposing ILSs sharing the same frequency. Note the LS indications on the PFD; the "backward" indication of the LOC diamond (and absence of a GS cue) and the IMDC indication: The MCDU will not allow an override: Proceeding as if on an NPA: Ted was not pleased!
  11. Sabretooth78

    Vertical profile update

    I can confirm that the climb behavior of the A320 IAE is much improved; however the descent behavior still needs work - I still get excess of -5000 fpm in open descent as I've previously noted. That said, I appreciate the fix and one thing at a time!
  12. Sabretooth78

    After Offset lost of Navdatas

    I tried an offset today for storm avoidance and have a question that may be related to the original post. My flight plan was: KLGB N0461F370 FRITR3 CNERY DCT BLH J169 TFD J50 ELP J2 FST DCT DILLO LAIKS2 KAUS Due to thunderstorms at ITEMM, I tried an L10 offset beginning at about TOTEC and set ALIBY as the end waypoint. SSO (San Simon) was the last waypoint prior to ALIBY. What I observed is that the aircraft acquires the offset path rather quickly (as I expected), but is rather lazy in requiring the original flight plan at the exit end of the offset. It began the turn back to the original flight plan at SSO, but didn't acquire until ALIBY, a distance of about 78 nm. Graphical representation thanks to FSXTracker: TOTEC is the point of depature, point of exiting the offset is abeam San Simon. Reacquisition of original path at ALIBY (at A/C position shown). Shouldn't the exit end of the offset be similar in length to the entry? I could see ATC not enjoying such "lazy" progress. Or is this actually as intended/realistic? A320 IAE; 1.2.1.0
  13. Sabretooth78

    No exterior light effects

    Those look a lot more sensible. Come to think of it, I don't know if I've done a night flight in the Pro version at a non-payware airport, which explains why this behavior might be a crapshoot. Turns out the next flight I wanted to do will be a night flight to a default airport so I'll be able to verify at that time.
  14. Sabretooth78

    Cockpit Lighting

    I had an issue last night where the "ambient" cockpit lighting went out during an approach into KLGB. Depending on where I would shift my viewpoint (via sidestick hat switch), the lights would come back on but go off once resetting to the forward view. This appears similar to the exterior shadows problem that seems to plague P3D v4 in general, but I thought I might post it here in the event it's not stemming from a problem that LM needs to address. For example; very dark: But turn your head slightly to the left, and it gets brighter: More or less solved by turning switching the dome light to "bright" to compensate, but really annoying on approach. This was the first time I had experienced this with the Airbus, or any aircraft in P3D4 to my recollection. For what it's worth, I did have ORBX FTX SoCal enabled, so perhaps I was just overloading the lighting calculations? (I usually don't fly airliners over FTX regions but I'm still fiddling with a rebuilt PC and exploring its limits hence why I'm throwing the kitchen sink at everything.)
  15. Sabretooth78

    No exterior light effects

    I have a somewhat opposite problem whereas the ground will be lighted appropriately, but nearby terminal buildings and AI aircraft will be completely washed out. For example: Taxi lights on: Taxi lights off: Airport is KDCA, Drzewiecki Design Washington X. I took these some time ago and forgot to report it so I don't recall exactly what the version number was, but I still get this on 1.2.1.0. Model was A320 IAE.