Jump to content

Ivan Wong CL

Members
  • Posts

    34
  • Joined

  • Last visited

Posts posted by Ivan Wong CL

  1. Hi Devs,

     

    Here's another report

     

    Load up at RJCC airport.

    Load up this flight plan file generated from Simbrief from the Route Menu in FMS.

    Flightplan seems to have discontinuities here and there.

    I go into arrivals, and try to choose runway ILS27

     

    FMS and all instrument screens hang. 

     

     

    Thanks for your hard work devs. She's a nice bird to fly 😃 Albeit some hiccups here and then. 

     

     

     

     

    RJCCRJSS.flp

  2. Updated to latest, confirm the AP TRIM jolt still happens. 

    Just to reiterate the scenario for developers to understand:
    1. Takeoff
    2. Handfly

    3. Since hand flying, gonna trim nose down to maintain level flight at say 5000ft.

    4. Once stable at altitude, engage autopilot with ALT and NAV

    5. Look at trim display while doing step (4).

    6. You will see the trim jumping back up to default 7.5.......

     

    Seems like AP and Manual trim values are two different persistent values....   <--------------- this is the rootcause. AP only persistently remembers the trim that it changes DURING AP is on. So if AP remembers the last AP changed trim to be 7.5, but currently the plane is flying at trim 3.0(cause user handfly and manually trim it), once AP engages it's gonna go all south LOL. 

    • Upvote 1
  3. 1 hour ago, wafu said:

    You didn't quite understand

     

    1.Starting on the Gate without Msfs Flightplan

    2.Simbrief to crj fms

    3.on the gate, atc Menu, request flightplan from crj fms

     

    Works perfect with Flybywire

    And Msfs never changes the flightplan

     

     

     

    Because Flybywire A32nx is using MSFS internal Nav Data.... Hence it's the same source. 

    CRJ is using EXTERNAL Nav Data... which you will have to update yourself by buying the subscription from Navigraph or Aerosoft.

  4. To devs, here's some info incase no one provided a concise observation, yet :
    Basically what was happening is this:

    Scenario 1: Stabilizer trim 0

    1. fly and adjust trim to let's +5 manually
    2. then engage AP
    3. AP doesn't immediately take over from trim +5, it basically is basing on last AP used trim, which is 0, and then it adjusts onward.
     

     

    Scenario 2: Stabilizer trim +5

    1. assume flying nicely using AP at trim +5
    2. disengage AP, trim remains at +5
    3. then fly aggressively or whatever you want to do, just change the trims manually to let's say -10.
    4. reengage AP

    5. AP doesn't immediately take over from trim -10, it basically is basing on last AP used trim, which is +5, and the it adjusts onward.

     

    I would say this would be a known issue as there were a lot of topics on this (could be because of sim limitations as well). So no need to harp on this. Let's all wait for progressive updates from Aerosoft and be patient. 😃 

     

    Cheers for the amazing airliner. Thanks Aerosoft. 

     

     

    • Like 2
    • Upvote 1
  5. my 2cents...

    IRL, i'm a software developer on a code base that was super legacy and also trying to squeeze out every performance there is while trying to add new stuff/features so that customers would want to buy new refreshed models/software.

     

    Every customer is able to squawk that they have an issue.
    Yes, developers know there might be a bug in the code.
    Yes, IRL in my work, I would try to reproduce it on my end, IF POSSIBLE.

    Yes, IRL in my work, there would be cases where.... no matter what I do, I can't reproduce the same issue that the customer experiences.

    So in that case, we require more CONCRETE/DETAILED information on how is the setup, did the customer did anything that they missed out telling us, no matter how small(yes, even a speaker volume change considered a detail that helps)
    All else fails... we might just declare it's this way, or provide a workaround, or some other way, THAT DOESN'T BREAK FUNCTIONALITY FOR OTHER HAPPY CUSTOMERS.....

     

    It's not that developers do not care.... It's that this is a nightmare not only on customer's end, but also on the dev's. How could I solve something that I have no clue about~...... On a framework that was 40 years old, and every little change you do, there might be happy customers turning into riots because they are specifically using the loophole as a feature. 

     

    Yes there are developers that really have no passion for what they are doing. But it's not the majority. 

     

    So.. my 2cents.

    When giving bug reports, be as concise and clear, and detailed as humanly possible. But understand that... devs are not geniuses that can solve something with wave of the wand. 

     

     

     

    and edit:
    If you're asking why cant we just start fresh on a new code framework and be efficient?
    Then the answer is, can you accept that Windows 10 cannot be compatible your Adobe Photoshop software that you bought 5 years ago? and if yes, are you willing to wait 10 years for the thing to be ready? 😃 It's not a black and white clear cut thing. 
     

    • Like 3
    • Upvote 1
  6. I've

    21 hours ago, Thx1137 said:

    Oops, I didn't see that it was a typo. Sorry to the OP, that I missed that.  I found a bug but I don't think it is yours unless there was more to it than you describe in your original comment.

     

    One other person (I'm pretty sure he was a real world CRJ person) mentioned that for him, VS could be used above FL300, but not below, so I tried it and it climbed fine at about half max weight and there weren't any issues with getting near overspeed or getting slow. I think it is clear that it is more risky than just using SPD mode though.

     

    Right now I started off right at max weight and am in SPD mode at Mach .81 and so far it is going OK. My target was FL400 but I can't really get there. I'm at M.74 at 39,000 feet.

     

    As for the POH. I was reading two sets of material supposedly taken from a "flight manual" I thought that was a POH but since your query I'm not so sure. I found a copy of some CRJ 700 flight manuals and I can't find anything in there about managing the climb yet. For VS, the flight manual goes on about "capturing a preselected altitude" a number of times which is generic. It also says "Climb or descent rate is achieved by moving the rotary switch on the flight controlpanel.". That to me implies that climb is a proper use for it. Now whether it is allowed by an operator of course is a different question! But nothing about gotchas when using it AFAICS. So maybe "flight manuals" are different to a POH?

     

    Since I started writing this, I can recreate an issue. I was flying along fine at FL390. After about 20 mins I thought I'd see if I could get that last 1000 feet. I'm not 100% sure of the sequence of events, but I got an AP disconnect (while typing here so I didn't see what happened unfortunately) and could see I was at 140kts with a high nose and descending.

     

    I think there may be two issues:

    1. Letting the aircraft get slow on the climb can cause it to stop climbing with a high AOA. I can kind of reproduce this but only as what appears to be a pilot speed management error. I'm sure I read that if you get "under the curve" (I read that as too slow) it won't climb until you can get some more speed up.

    2. If we stall I think the AP gets itself into a state where it is hard to recover. I think this is a sim issue. This is the first time I've had it and it was the first time I pushed the AP to get higher than I think the plane wanted to go, just 1000 feet more...

     

    Stall recovering was "interesting". I did the following:

    1. I'm at 140kts, stalling, so go nose down to pick up a bit of speed, engines to TOGA. It is *seriously* slow to pick up speed so I go to MAX.

    2. Start trimming to take yoke pressure off. It was on 15.

    3. At FL320 (lost almost 7000 feet!) and 200kts. I'm flying on a very slight climb. The aircraft seems stable with hands off with the nose at around 2.5 degrees.

    4. I enable SPD (200kts) and NAV modes. The aircraft goes full pitch UP. Stall. It most certainly was not following the flight director.

     

    What appears to be happening is that when re-enabling the AP, the AP trim value at stall is used, not the current trim value. So the behaviour is:

    1. The aircraft pitches full nose up to get the current trim back to 15.

    2. The trim starts coming down but it can't get to a more appropriate value because the aircraft stalls again.

    3. Try again and go back to step 1. Rinse an repeat. First at 200kts the others at 220kts. Each time able to fly with no AP with hands off.

     

    I did the above 3 times in a row.

     

    On the 4th attempt, I held the nose low at step one using the yoke until the trim came down to around 3 I think it was. All of a sudden there was this quick pitch down, like the AP stopped fighting me. Instantly the AP starts working as I'd expect again.  I was able to use SPD and leveled off at FL390 at M.74 and am continuing the flight. The stench of vomit is rife in the cabin.

     

    What the AP was having trouble using SPD mode was a disaster and increasing speed by just 20kts, even level with a 2.5 degree pitch took minutes. It seemed like it was acting as if it was on a climb but it was flying level. So, if the OP stalled first and had this issue, then gaining speed again to continue the climb would seem to be an issue. Hard to know without details.

     

    I'll see if I can make a reliable repro with video.

     

     

    I've just had the same experience last night, using SPD mode to climb to FL260, then at around 1000ft from target, speed was slowing down and ATC was asking me why was I descending without clearance(VATSIM). I noticed the speed was barely 140knots, and stab trim was at 14.0. 
    I disconnected AP and manually fly the plane and manually trim the stab to a sane position for level flight. 

    I then reengage AP on SPD mode to FL260, but it INSTANTLY used the former stab trim 14.0 value. I saw it with my own eyes that it instantly jumps back. HAHA

     

     

     

  7. To devs that concern:
    Here's another hang/CTD that i reproduced for you additional debugging purposes.

    Steps:
    1. Load into airport: VTSP, one of the parking areas, AIRAC2103

    2. Use EFB and put aircraft state to "READY FOR TAXI"

    3. POS Init as normal
    4. Got to route menu and load up the attached flight plan file. VTSPVTBD

    5.  Press "ACT STORE" button to load it

    6. Press "ACTIVATE" for the stored flightplan

    7. Press "EXEC" to execute the flightplan

    8. Go to flightplan page 3/4

    9. Delete the last line, by pressing LSK 5

    10.  Sim hangs, and my processor has basically one thread 100% used, kinda like a forever loop. 

     

    Thanks devs! Hope the information is able to help you guys solve some of the issues. 

    VTSPVTBDFlightPlanPage.png

    VTSPVTBD.flp

  8. 3 minutes ago, JRBarrett said:

     

    Yes, you are 100 percent correct on all points. 
     

    The CRJ’s FMS database (which is derived from real world Jeppesen data) is simply a record of what “should” exist in the sim navaid scenery BGLs, (but may or may not, based on how accurate the core scenery is).

     

    This applies to physical navaids, but it does not apply to procedures. The core sim nav data does contain information on RNAV waypoints, but since these are not physical navaids, but merely a list of waypoint names, each with a specific latitude/longitude coordinate, the CRJ does not access or use the core sim nav data for waypoints - it uses its own FMS AIRAC data for that. 
     

    Likewise procedures like SIDS and STARS, simply consist of a series of named waypoints which are interconnected. Although the core sim nav data does contain information on these procedures (for use by default MSFS aircraft), the CRJ uses its own FMS AIRAC for those procedures - since the waypoints contained therein are not physical objects.
     

    An ILS approach will typically contain waypoint names for the Initial and final approach fixes, which are defined as points on the localizer a specific distance from the runway threshold. If you load an ILS approach in the CRJ, the approach IAF and IF fixes that appear on the MFD come from the FMS database, but the actual ILS transmitter itself that the Nav radio tunes to, is contained in the scenery BGLs. 
     

    The scenery BGL files will contain information on the latitude/longitude of an ILS localizer transmitter, its frequency and identifier, the magnetic heading and width of the localizer beam, its reception range, and the specific airport runway it is linked to.

     

    Likewise for the associated glideslope transmitter, it will have lat/lon coordinates, frequency, the angle of the glideslope and the reception range.

     

    My experience has been that the navaid data in the Navigraph beta replacement core data is quite accurate - and generally more up-to-date than the MSFS default data.

     

    At present there is no easy way to directly edit the data in the core scenery navaid BGLs for things like VORs, NDBs etc. Rather than changing the data in the core BGLs, the Navigraph beta data provides its own set of BGL files that override the default files.

     

    The SDK airport scenery editor that can be accessed from within  the sim in DEV mode can modify airport ILS data, but the process is not very straightforward. 

     

     

    That is some golden nuggets of info here. Thanks for the knowledge download. 

     

    Yes, it's not very straightforward at the moment to directly edit a localizer's data, as there are package priorities being loaded, as well as overwritten, as well as navigraph's data is in BGL format. Asobo's SDK need to mature more for the community to start fixing their airports (they have alot of auto gen airports, but it'll take better tools available to the community to make it easier for a public effort to correct them to real life, be it scenery or nav data)

     

    I'm using Navigraph's data, whether the ILS localizer coordinates is really wrong or not in IRL, most probably not? =). But either way, I'm just messing around with the Nav datas in the core and CRj's folder in an attempt to shift localizer to it's IRL antenna position. Your explanation directly correlates with what i find, which is editing CRJ's nav data for the localizer's position does nothing to CRJ's nav receiver. 

     

    Thanks for alleviating my curiosity and i can rest well tonight.

  9.  

    19 minutes ago, JRBarrett said:

    No. Navaids in the sim are embedded in the scenery in BGL files. This includes all VORs, localizers, glide slopes, DMEs, NDBs and marker beacons. In the default sim, they are based on the core nav data supplied by NavBlue. If you use the Navigraph beta replacement core nav data for MSFS, then the navaids will come from that data instead of default. The Navigraph beta sim data contains replacement scenery BGL files (specifically for the navaids) that overrides the default data when placed in the Community folder.
     

    The FMS database in the CRJ simply contains information on the various navaids in the sim world, but it does not affect them in any way. 

     

    Hi @JRBarrett

     

    Thanks for the explanation.
    Just to clarify my understanding:
    1. FMS AIRAC Data updated to the CRJ are used for FMS inputs and planning

    2. AIRAC Data from Navigraph may also update MSFS's base BGL scenery to their new definitions

    3. When planning a flight plan, for example, entering Origin/Dest, and also waypoints, these all gets referenced from the CRJ's internal FMS Nav Data(for example an airway, and what navaids are included in that airway). 

    4. However, when actually flying in the sim, and let's say i'm tuned to a VOR/ILS somewhere, that VOR's coordinates/course/height/frequency/etc are all based of MSFS Navigraph Updated database(NOT the crj's internal one, though both by right should be same if both are updated correctly)

     

    So,

    In summary, the CRJ will follow the VOR from MSFS Core Nav Data, and not the numbers from CRJ's internal nav data. 

     

    and in for a second additional summary:
    If i find that a VOR or ILS beacon;s coordinates in the sim is different from IRL, and i wanted to "correct" it, I should not dissect CRJ's nav data, rather, i should start on dissecting MSFS Core Nav Data(it's BGL and scenery files) 

    Is my understanding correct?

  10. Hi,

     

    Scenario : Navigraph data AIRAC 2103 downloaded installed. 

     

    I see I the nav data folder, that there are text files with airport info n etc. together in the airport text file, there are definitions and coordinates of various stuff , including ILS coordinates. 

     

    Question : If I change the ils localizer coordinates, could it reflect on the CRJ's ils approach and where it detected it in the sim ?

     

    I tried but seems no effect. 

  11. Just reporting in.

    FMC locks up the whole sim.

    Steps;
    1. Fly out of KDEN RWY08
    2. Flight plan origin KDEN, flight plan destination KDEN

    3. after departing on a SID, and far enough, enter the arrival data, in this case, ILS26
    4. Go to DIR/INT page, press direct to an arrival fix(i forgot did i use arrows to change the page numbers or not)
    5. Sim locks up. 

     

     

    Note; the arrival fix i think was a history. A passed arrival fix. 

  12. @Secondator

     

    I've just had another FMS related freeze. 

    Thus time I've correctly input origin and destination, and the route. 

     

    Upon reaching destination, there's an approach change by ATC, hence I tried to change approach.

     

    It hanged/stuck when I chose an approach. 

     

    seems like not limited to origin-less flight plans. 

  13. 7 hours ago, Fisu said:

    mmmm, this is not the way. The problem is CTD when you are manipulating the MFS, in the DEP/ARR config, only in de ARR, whe choosing the star and the aprox type.

    Very anoying when you are in a fly 1,5 hours ago, and the ATC tells you, a different aprox (IVAO, VATSIM) not configured in the dep airport. For play off line no problem because you dont go to change nothing infly.

    just a question, your flightpan has origin n destination targets?. 

     

    wondering.

    my crashes mostly is when I fill in without origin . hmm. maybe it's just one of the symptoms

  14. @Secondator

     

    Yeah, it seems so this way. I think what mostly triggered this observation from me was starting a flight mid air, and then entering destination data. Because i started mid air, there isn't an origin, so no origin entered. 

     

    For me I am ok with the condition now for Origin and Dest must be filled.  Thanks Secondator.

    • Upvote 1
×
×
  • Create New...