Sabretooth78

members
  • Content Count

    207
  • Joined

  • Last visited

Everything posted by Sabretooth78

  1. Sabretooth78

    Version 1.2.3.0 and some thoughts

    1.2.3.0 "base" installation, and obviously the various past times I experienced it would have been certain older versions, so it seems to be a long-running issue (probably not unrelated to the documented issues). I'm on vacation/holiday until the end of next week so I won't get a chance to play around with the recent update until I get back home.
  2. Sabretooth78

    Version 1.2.3.0 and some thoughts

    Some possibly similar behavior I've experienced periodically periodically in the past happened again today. I was descending on the DADES6 arrival into KTPA, passing KOKOH at 250kts (per STAR speed restriction landing south) and 11000 feet when I was cleared down to the IAF for rwy 19L. By this time, I was slightly high on the path, and after dialing the altitude down to 2000 and pushing the button, the Bus entered DES and dove down for the green dot completely disregarding the speed bug, getting up to 280 kts and -4700 fpm while blasting past 10000 feet before I was finally able to arrest it at 9400 feet and regain control. It seems that DES places a higher priority on the green ball than it does the speed - isn't it supposed to be speed protected (or am I misunderstanding it)? For the record, I did manually enter the 250/13000 restriction at OLENE. I've had similar incidents on initial approach when switching to DES prior to G/S capture while a little high, but this was the first time it happened where I was pretty sure it wasn't something I caused to go wrong.
  3. Sabretooth78

    MCDU TOC Calculation

    Here's another example: KBOS N0453F360 PATSS5 PATSS NELIE CMK J75 GSO SLOJO Q75 TEUFL GEEYE JAYJA DADES6 KTPA As can be clearly seen, the CLIMB PERF prediction is way off, especially in terms of the ETA given.
  4. Sabretooth78

    MCDU TOC Calculation

    On my current flight I noticed some error in the TOC calculation on the CLIMB PERF page: Not sure it's a big deal, but notice that it's predicting a much longer time and distance to TOC than the ND indicates (which is in fact much closer to the "EXPEDITE" info). It was waffling a little during the later stages of the climb (to be expected, I'm sure) but shortly after I snapped this picture the time and distance rapidly decayed before the page changed to CRZ just before entering ALT*.
  5. Sabretooth78

    Wind Request from Active Sky

    I went through the 2nd page of the INIT page and entered in the departure runway and SID information before running the wind request and this time it seemed to work properly. I was typically doing the wind request before page 2, so that was probably the problem. Prior to running an actual flight I had tried it not thinking I had loaded a P3D flight plan and it worked that time, but it turned out that a flight plan had loaded (SimStarter was set to load the most recent flight plan). That said, upon opening another (any) flight plan from the FSUIPC Add-Ons menu entry and reloading the wind request, I got the problem of incorrect altitudes again. The only way to fix it at this point was to delete all of the waypoints from the P3D plan from within P3D (or presumably reload a new plan with only the departure and arrival airports) - with such a plan loaded, the weather update behaved again. So there seem to be a couple of ways to "break" the wind request.
  6. Sabretooth78

    Wind Request from Active Sky

    I noticed a possible bug in the MCDU INIT wind request, using Active Sky as my weather engine. For all the waypoints I checked, it seemed to be pulling in the correct wind information, but at an offset altitude. i.e., what Active Sky was reporting as FL240, the bus was reporting as being FL180, etc. See the screenshots: Has anybody else noticed this? I'll be running another flight this afternoon and will check it again.
  7. Sabretooth78

    Wind Request from Active Sky

    AS4 will read a flight plan that has been loaded into P3D. To be honest, the only real reason I load a P3D flight plan (through the FSUIPC menu option) is in conjunction with the FSXTracker app.
  8. Sabretooth78

    Wind Request from Active Sky

    Both instances have been with a SimBrief flight plan (FSX/P3D PLN format) loaded into P3D (and thus picked up by AS) with the FMGS plan being downloaded from SimBrief, cleaned up in the Company Route Editor (*) and then loaded into the Bus. I'll be doing another flight this evening, is there any step you would recommend me exploring further? Given that there's no elevation info imported into the Bus I don't understand why this problem would be caused unless AS is getting messed up somehow and then passing along the wrong info. * The SimBrief-downloaded company brief often has several lat/lon coordinates in the route string when viewed in the Company Route Editor. I typically clear those out, delete the runway and SID/STAR info, and make sure there's a DCT before the first waypoint and between all non-airway points. Not doing that last step seems to mess up the route upload into the FMGS; if you have a string of 3 waypoints, say WYPT1 WYPT2 WYPT3 (without DCTs in between), the MCDU has for me in the past imported this as WAYPT1 -> airway WYPT2 -> WYPT3 which basically skips WYPT2.
  9. Sabretooth78

    Wind Request from Active Sky

    I had the weather source set to sim. Just to check, I set it to one of the other options and then back to sim, and still saw the same behavior on my last flight.
  10. Sabretooth78

    Radio Panel font disappearing

    The behavior has happened twice so far during my current flight. Both times as a result of PF3 changing my COM1 frequency as part of its "Virtual Copilot" feature which I have set to Mode 2. (In other words, I haven't touched the radio since initially setting it to the ATIS and clearance frequencies.) Perhaps this is occurring because PF3 effectively bypasses the standby frequency; i.e. it directly changes the active frequency and the standby frequency does not change. It appears to be purely a graphical glitch, the functionality of COM1 is not affected. Swapping or simply changing either of the frequency dials immediately fixes it.
  11. Sabretooth78

    Fuel used still in KG on engine page of ecam

    I also get this exact behavior, previously reported here: P3D unit setting (hybrid, US, metric) doesn't seem to make a difference. Speaking of which, FS2Crew users, do not use metric because it'll mess up all your altitude-related FO calls (unless you want your US transition altitude changed to FL590)!
  12. Sabretooth78

    Managed speed issues

    I haven't been using the checklist/copilot and I have had the bug several times (though not since updating to 1.2.3.0). However, I do have those features turned on in the MCDU3 Options, I just haven't been initiating them at any time (I use FS2Crew). I don't believe I've changed options settings since the update.
  13. Sabretooth78

    Radio Panel font disappearing

    Something similar to this happened to me as well on my first flight using 1.2.3.0. I didn't notice it when it happened, I just noticed at some time during preflight that the first digit was missing (as was that part of the LCD background). I don't recall exactly how I fixed it; was either by changing frequency or swapping; it hasn't recurred since. I use PF3 for ATC and have it set to have the copilot handle frequency changes, so it seems quite possible the same mechanism at play. Prior to that instance I had never seen this. I'll try to pay more attention to see if it happens again.
  14. Sabretooth78

    Cabin Pressure

    At FL370 cruise and for some reason my Cabin Pressure ECAM is showing a very high delta P due to a cabin altitude of -150. Any idea what might be causing this? I don't recall having seen this behavior before. A320 IAE v1.2.2.1
  15. Sabretooth78

    Version 1.2.3.0 and some thoughts

    Did another flight, this time with a CI of 35 and the behavior was overall similar. The targeted descent speed was 296 knots this time, so the effects were lessened as the a/c didn't have to chase as high a speed above crossover altitude and therefore ended sooner, but it was the same basic behavior. Specifically, my cruise was at FL370 and I was instructed to descend to FL330 somewhat prior to TOD. So I entered DES at 1000 fpm until about just past FL340 when I was instructed to descend to FL280, so I pulled for OP DES (this was incidentally just about at the point where I would have met the VNAV profile - for most of the remaining descent I was only 500-1000 feet below profile). The same behavior as before; the a/c reached a peak rate of descent of 5500 or 5600 fpm until around FL290 when crossover occurred and it leveled out somewhat to maintain 296 kts at a rate of around 3300 fpm. Flight: KFLL/10R N0458F370 BEECH5 BAHMA Y353 ZIN Y398 JOSES UA315 DUSAN TUGUL TUGU1A TNCA/11 ZFW 122.5 klbs Block 19.2 klbs
  16. Sabretooth78

    Managed speed issues

    In the field I work (civil engineering) there's a saying that basically goes "if you have a perfect set of plans, you paid too much for them." The punch line being, of course, that there's no such mythical creature. I would expect software development is much the same.
  17. Sabretooth78

    Version 1.2.3.0 and some thoughts

    I experienced it last night as well; I actually started a descent (ATC instruction) well before the calculated TOD and descended in various steps. While at about FL280 and still below the VNAV path, I was instructed to descend to FL240, upon which I entered OP DES and the a/c dove down to a max of about 6200 fpm - in the yellow so I can't believe that was intended. This was at a CI 60, which commands roughly M0.79/337kts and it required that much of a descent rate just to finally catch the target - once I passed crossover altitude and the target stopped increasing. As I've said before, it seems to me that the a/c loses a little too much speed as the A/T rolls back to idle; it "feels" as though there is too much drag. This "feeling" is based on hundreds of hours flying the FSX version as well as other packages such as the PMDGs, all of which are/were much more slippery at higher altitude. Take that with a grain of salt... For me, I can reproduce it reliably every time. Set CI to 60, cruise at target speed (M0.79-0.80) at FL320-360, dial the altitude back and pull. Happens every time. My usual workaround is a bit similar to the OP's; I usually get instructed to descent early anyway so the first phase is usually a V/S and sooner or later I get speed nags. OP DES with a slower speed (such as say 280kts) does seem to be more reasonable. I might play around with a different CI on my next flight later today and see if/how that affects anything.
  18. I updated to 1.2.2.2 shortly after it was released but after seeing the problems others were having (and confirming at least some of them myself) I decided to roll back to 1.2.2.1. Prior to rolling back from 1.2.2.2, I saved the entire "Aerosoft" add-on folder, as I typically do to preserve my liveries and aircraft.cfg edits. As a result, and after installing v1.2.1.0 as downloaded from the Shop, I've found that although the Updater did download and install some files and now claims that I have the latest version (1.2.2.1), I have discovered at least a few files where my currently installed files are older than my backup files. It seems as though the Updater is installing outdated packages? What led me to discover this was the absence of the "Weight Unit" setting under MCDU3 > Options > Aircraft. For that instance, restoring my backup MCDU2a.xml and MCDU2b.xml files restores the feature. I've also found some other files which aren't being updated (see below). I haven't searched exhaustively, so there may be more? ...\Aerosoft A318-A319 Professional Base\Panel_Fallback\AB_MCDU2\ Backup files: Current "up-to-date" files: ...\Aerosoft A318-A319 Professional Base\Panel_Fallback\DLLs\ Backup files: Current "up-to-date" files: The A320-A321 installation is an identical situation, except MiscD2D.dll has a matching date.
  19. One observation I've made with the Pro (P3D4) version since its release is that the autopilot maneuvering of turns, at least in managed mode, seems to be a little off. I never noticed this in the previous (FSX) version. Generally, all appears good until the AP begins rolling out of the turn; it's as if it is aiming for a path that is parallel to the outbound path, but some distance before it. Hopefully I'm describing it well enough. Anyway, this has only been an observation, no big deal as the AP would eventually smoothly acquire the new path. For all I know, maybe that's how the actual aircraft operates. Since the most recent update, 1.2.1.0, however, this seems to have become a little more noticeable, in fact on my last flight I had a handful of turns (in the 40-60 degree range) where the turn completed with the aircraft somewhat short of the path and the AP corrected with a noticeable reverse bank to acquire the path - i.e. for a left turn (as most of them happened to be for this particular flight plan), it corrected with a short but sharp right bank to acquire the path. I don't recall ever noticing this kind of behavior in the Aerosoft Airbus in any version prior, even on very sharp (acute) turns; nor on any other payware aircraft of this caliber. I haven't noticed this in selected mode, but that's not to say it doesn't. I'm suspecting since a selected turn is not trying to achieve a set path, such an issue won't occur as the AP will simply level out when it achieves the selected heading/track and isn't actually trying to acquire a defined path. Here's a diagram (somewhat exaggerated) to try and explain it visually: Magenta = Plan Blue = Flown Turn begins distance "x" short of waypoint "WAYPT" At same distance "x" past WAYPT, a/c is offset from path by distance "w" A/C acquires plan over distance "y" - smoothly (FSX, P3D4 prior to 1.2.1.0) or with right bank (1.2.1.0)
  20. Sabretooth78

    Autopilot vs. Horizontal/LNAV Path

    Another approach with closely-spaced waypoints which exhibits this problem is the QWENN5 arrival into KSLC Salt Lake City. Waypoints QWENN and FFU are only about 1 NM apart. Upon reaching FFU, the a/c began to veer sharply to the right, when in fact it should have gently turned left. I quickly switched to selected heading mode, so I didn't find out how exactly it would have recovered the situation.
  21. Sabretooth78

    Managed speed issues

    Perhaps equally surprisingly, my long streak of bugged climbs has been broken and my last 3 flights have been free of this bug (nor has it occurred during cruise). Bring on the update, lol.
  22. Sabretooth78

    Cabin Pressure

    Just had a recurrence of the issue tonight, first time in 14 flights (original post). Logs attached! Not sure if it was related, but I had a few other odd things happen after landing; most notably a center fuel tank ECAM message after I had shut down both engines (block was 17.63 klbs so the center tank was not at all utilized during the entire flight). Maybe something just failed to initialize correctly upon load. AB_ND_GDI.log AltProcess.log FMGS.log
  23. Sabretooth78

    KIlo's into Pounds

    Make sure you are allowing experimental updates when updating from your base install (1.2.1.0). One of the developers could answer more precisely but the update that added the kg <-> lb feature was one of the 1.2.1.x experimental updates.
  24. Sabretooth78

    Managed speed issues

    I've reinstalled several times in the past several weeks and at least one of those times I tried deleting those "User" folders (and then restarting) but to no avail in stopping the problem, so apparently it's one of those "your mileage may vary" things that happened to work for you... I also don't run A/V - I don't use my sim PC for anything besides simming (and the attendant downloading that goes with it) so unless SimMarket, ORBX, Aerosoft, etc. get hacked; well, suffice it to say I haven't used A/V on any of my PCs (Mac and Windows) in at least 15 years and haven't got burned; I'm tech savvy enough and back up early and often enough that if I did get a virus I'd just assume wipe clean and restart. But I digress... One area where I differ from your process is that I tend to run P3D and load up whatever particular add-on (particularly in the case of aircraft) immediately after running the installer and rebooting. I'm not sure if that makes a difference. I guess I do it as sort of a holdover from the FSX days, where you had to run FSX on the clean install in order for the sim to create its cfg files and such before installing the service packs, otherwise you could potentially run into problems. All that said, I now almost ALWAYS get the managed speed bug on climb when hitting crossover altitude. Always, as in, at least the last 7-8 flights (beginning around New Year's Day). Before that, it hadn't been happening at all (in that situation). Fortunately, George still seems to obey the "proper" climb speed, and the bug is easily eliminated by either pushing or pulling the altitude knob. As for the random occurrence of the bug during flight, I still get that only sporadically. Say maybe once every 5 flights. For instance it happened to me last night fairly early in cruise on a 4:45 flight; it seems to have a propensity to occur on longer flights (which makes sense; longer flight = greater chance of it happening eventually) at some random point in between waypoints. The first time it ever happened to me was on November 5; about midway through a 5 hour flight. Naturally, that was while running P3D v4.3, and the problem has persisted through the P3D update to v4.4 (for which I updated all components and have since reinstalled the Bus a number of times). Also consider I just performed a clean install of Windows in mid-August 2018 when I effectively rebuilt the PC. I don't know if that rules out the state of my P3D install as a cause or not. My virtual money is on it being an unintended side effect caused by a VNAV update to the Bus sometime in late October/early November, but that's just a hunch and I don't intend that as a dig at the developers; --it happens. So, regarding the upcoming update. The change log for 1.2.2.2 said that the logging would be triggered when the managed speed dropped below 120 kts. Unfortunately, this would not trigger in the vast majority of my situations where it is occurring during climb, where it typically shows up at about FL260, calling for a speed of 180 kts and slowly decaying as the climb progresses. Could I make the suggestion that the logging instead be triggered say when the managed speed drops below 200 while in climb or cruise phase? Or perhaps any situation above say FL200? Naturally it would have to be coded in some way so as best to avoid instances in initial climb with lower speeds such as SIDs with speed restrictions, etc. Of course I may well be the only one having this issue during the climb. At this point I'm sick to death of reinstalling things and I'm content just to throw it into selected speed until the issue is teased out and squashed, which will happen eventually. I have no problem doing some investigative work as part of my normal flying, but I'm done with the reinstalling for now. There's enough to do as it is just in the normal course of updating, regardless of trying to tease out bugs. I have no regrets jumping ship to P3D, but this is why I clung to FSX for as long as I did, why I would still be using FSX were P3D still only 32-bit, and why with most gaming I've usually been a hold out; I appreciate the maturity and stability in the platform!
  25. Sabretooth78

    KGS vs LBS

    Prior to installing (and then rolling back from) the v1.2.2.2 update, my MCDU3 had an option Options>Aircraft>Weight Unit (LSK 5L) under which KGS or LBS could be selected. After rolling back to v1.2.2.1 (by installing from the downloaded v1.2.1.0 for both the A318-A319 and A320-A321 packages and then using the updater to bring both up to v1.2.2.1), I now no longer have that option and in fact I notice on the "What's not available, what's wrong?" thread that the option to change between units is no longer struck through. Would I be correct in assuming that this feature has been rescinded and for some reason past updates did not remove it? I feel like I'm going nuts, because I know it was there and I have screenshots to prove it!