Stefan

hi cessna, since my home-location is lowg, i am quite familiar with the routes around LOWG :-). But as you can see, the route LOWG - LOWK covers a wide range of procedure-elements, which are good for training and testing. and you have to fly very exactly an concentrated, because you are flying between high mountains and things happen very quickly. LOWI via RTT LLZ(offset)/DME-approach with visual turn to final is a bit more challenging, also LOWS departures and arrival. Cuzco in Peru is very nice, but my absolute favourite approaches/departures are at LGSM (VOR/DME, visual turn to final, heavy crosswind and turbulence as in real-world...)

Hi Philipp, when departing from LGSM via the ORMO2B.09, a problem occurs with intercepting the R174 SAM. After passing the (420)-restriction, the (INTC)-point gets lost and no further attempts are done, to intercept the radial. the next wpt is the (4000)-restriction. after passing (420) i would expect right turn to hdg 204 until intercept of R174 SAM, but fms continues rwy-hdg until passing (4000). what's a little bit strange for me, is the legs-display, which shows 177deg for the (INTC) - which seems to be the direction to the calculated interception from the current position - instead of 174 (radial). <Sid Name="ORMO2B.09" Runways="09"> <Sid_Waypoint ID="1"> <Name>(420)</Name> <Type>ConstHdgtoAlt</Type> <Latitude>0.000000</Latitude> <Longitude>0.000000</Longitude> <Speed>0</Speed> <Altitude>420</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>above</AltitudeRestriction> <Hdg_Crs>0</Hdg_Crs> <Hdg_Crs_value>092</Hdg_Crs_value> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </Sid_Waypoint> <Sid_Waypoint ID="2"> <Name>(INTC)</Name> <Type>Intc</Type> <Latitude>37.687778</Latitude> <Longitude>26.907500</Longitude> <Speed>0</Speed> <Altitude>0</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>at</AltitudeRestriction> <Hdg_Crs>1</Hdg_Crs> <Hdg_Crs_value>204</Hdg_Crs_value> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <RadialtoIntercept>174</RadialtoIntercept> <Sp_Turn>Right</Sp_Turn> </Sid_Waypoint> a short cross-check with vasFMC also was not succssfull. it does the correct right-turn to 204, but turns left to a 174 deg HEADING on a parallel offset course to the R174 SAM (which may come from an inconsistency of navdata between x-plane and navigraph). the following right-turn is only initiated after passing (4000), the 10 DME-restriction is ignored (maybe not present in the nav-data). Regards, Stefan

i don't no if this "feature" is limited to alt - but for me it looks like, the not yet passed GRZ wpt "hides" the 2200A-point, so that it cannot be triggered. and as you can see at the LOWG-departure, flying above 2200 after GRZ doesn't trigger the 2200A. After my "quicktest-route" LOWG-LOWK works perfectly, i will try some advanced approaches and we'll se, wat the lateral nav does ...

i did some tests with vasFMC (i got it working with XP10! :-)) based on an 11xx-Cycle - and it processed the (2200) wpt correctly immediately after passing GRZ-NDB. I will have to cross-check the nav-data with the 1202 of the CRJ for more detailed information. the second thing i found when engaging the AP on the FMS a little bit late, after passing the 1520A-restriction alt, but before passing GRZ-NDB. FMS did not trigger the 1520A-wypoint anymore. So it seems FMS triggers the Restriction-points only in case of a TRANSITION THROUGH the restriction-alt, but not when it is ALREADY ABOVE the xxxxA-altitude, which IMHO would be the correct behaviour. Then the implementation of the nav-data - as cessna described - would not have any influence on the fms-processing.

cessna729, thx for your investigations. as i can remember, i had these problems never, when using vasFMC - which is based on the same nav-data. i will try to cross-check this and check the nav-data again. but one thing, i am sure, is not correct: that the 2200A waypoint is triggered, when i descend BELOW 2200ft. regards stefan

Hi Javier, i do not mean VNAV - i mean the interpretation of the nav-data. the 2200-above-waipoint is not sequenced (and the following right-turn initiated) , although i'm far above this altitude. Regards, Stefan

Hi Philipp, after some testing, there seem still to be significant issues in the processing of OVFLY- and restriction-Waypoints. maybe the problems i noticed, are the same as in another open thread about STAR-problems. When i fly the ABIRI1G-Departure from LOWG, which consists of an overfly-Waypoint GRZ-NDB followed by an altitude restriction 2200A and a right-turn, (in the chart described as: after passing GRZ and above 2200ft turn right...), the 2200A-Waypoint is not sequenced before i have passed GRZ. After passing GRZ - which happens usually above the 2200-restriction-altitude - the 2200A-waypoint is not sequenced, but acts as a 2200-below-restriction. I tried to descend below 2200-ft, which caused sequencing of the 2200A-waypoint (which is another strange behaviour, because i would have expected, i had to climb again through 2200 to trigger the restriction-waypoint). IMHO the correct behaviour would be: when passing 2200ft before passing GRZ, the 2200A-wpt should be removed from the list, or th 2200A-wpt should be processed immediately after passing GRZ. would you pls have a look at this. i added the flightplan of the ABIRI1G-departure to this post. thanks, Stefan ABIRI1G.txt

deleted - sorry wrong forum

Cameron, thanks a lot! - i had an old Xplane-Version! (I thougth, when i use the updater, i would get the latest Version. After running Update to 10.05r1 everything works ok) Regards, Stefan

Hi, i have set up a second installation of x-plane10 on the same computer, but another harddisc for testing different configurations. everything works well on the second configuration, except the CRJ-200. The XP-Log says: Loading airplane number 0 with Aircraft/X-Aviation/CRJ-200/CRJ200.acf. I tried to open the following plane, but could not: Aircraft/X-Aviation/CRJ-200/CRJ200.acf This smacks of a corrupted airplane file, or a file that is not REALLY an airplane file, or a missing airplane file altogether! I will open the default plane now so you can still fly though. (init_pln.cpp:881) any suggestions, what the problem is?

Yes, i had this problem aftere entering a complete flightplan including sid and star. i simplified the scenario a little bit for documentation. when i remember this correctly, after entering the sid i got a PPOS-Entry on top of the flightplan, which was 3xxxnm away, the distances in the plan between LOWK and LOWG then were correct, but i could not start tracking because of the far away PPOS-entry (which is undeleteable). i will try again tonight and save the data. what is so annoying for me ist, that i found NO way out of this problem and cannot fly at the moment using fmc. suddenly - i could not identify the exact reason so far - everything is ok again. EDIT: you are right, in my simple examples the correct distances appear after entering the departure runway. the doubling of the distance without a departure runway is a little bit strange, but doesn't matter. so forget my testdata now. i will submit more significant data, when the problem occurs on a complete flightplan. @cessna729 thx for the informations, i will try to uncheck the two boxes and test again. it seems there is also a problem with the xp10.

Now i have it! After a flight in greece i changed Position to LOWG, turned off IRS and on again after a minute, then performed SET POS. After IRS init i entered a flightplan from LOWK to LOWG. For the result see attachments, flightplan KK1.txt and screenshot. FMS indicated more than 3860nm from LOWK to LOWG instead of about 60nm. The very annoying thing ist, that the problem persits after reloading the airplane. after moving the airplane to LOWG, i tried to enter a flightplan from LOWG to LOWK, which looked quite good, but nur there was a PPOS-entry at the beginning, with 50nm from LOWG. i saved this situation in flightplan GG1.txt and another try with 50nm from LOWG (blue) to LOWG (magenta) in GG2.txt and GG2.jpg. Today i found no way get the fms working - i always had a incorrect entry at the beginning of the flightplan regardless of moving the plane, initializing the IRS, reloading the plane ... KK1.txt GG1.txt GG2.txt

Solved in 1.4.5! thx!

Solved in 1.4.5! thx!

Solved in 1.4.5! thx!

Resolved in 1.4.5! thanks, Philipp!

yes, 6 works, but this was the first try, next try were the parameters of the 777, which result in smaller changes of the default crj-settings and also provide good results. i want to keep the changes as small as possible, but have not tested all combinations of settings so far, because it needs a lot of time. it seems the prediction-time and the pitch-error are the most important parameters here, and maybe the outhers need not be changed - but i'm still testing...

yes, 6 sec is to much - the 777 has 2.6

Javier, i can understand your doubts regarding to changes of the default settings of the CRJ - but the changes do NOT affect the flight-dynamics - which i think are very good (as far as i can estimate this) - but only affect the AP-controller, which should perfectly match the flight-dynamics of a specific plane. i will do some tests with reduced changes of the default-settings, because i think the parameter which is mainly involved in the problem is the pitch-error-parameter. my modifications result in a faster response of the elevator, which would be very reasonable for this "nervous" plane - as you call it. the oscillations result from an controller, which is responding to slowly and so always overshoots the correct elevator-trim position. the controller-response cannot be made faster by increasing the res/frame, because it's based on real-time. (but the problems, which occured in the 10.x.beta-releases COULD be fixed by higher res/frame - but they seem to be fixed now in the release-version) unfortunately the solutions per frame have no influence on the oscillation-problem in my configuration. at the moment i use 3 res/frame@60(!)fps, which means 180 resolutions/sec, i think. but as you say, there may be a drop of the framerate from xp9 to xp10, which may affect the autopilot in some way. or may be the evaluation of the flight-dynamics have changed in some way, making the plane respond faster. but i have no xp9 - and no time - at the moment to do investigations on this.

at the moment i cannot reproduce this - it seems reloading the xplane cleans something - reloading the crj did not help. when you change position with an active flightplan, the all distances will be recalculated for the new position, which is correct. when you enter now a new depature and destination, there is still a distance displayed which refers to the old position - which is a little bit strange, but may be ok. because after switching to the legs-page the correct distanced for the current positions are displayed - even without realigning irs. but there seems to be a special constellation, where the old position remains the reference for calculating differences - and there is no way to get rid of this. i'll try to find it - i'm sure it happens again some day.

yes, i know the crj200 as a very special plane. i know it very well from many business and holiday-trips, and i like it. that's the reason, why it want to get working very well on my sim. i agree, that's not an crj anymore, when you change the parameters to much, but it's also not an crj, when it' bucking like a wild horse after a turn with 300kn :-) btw. there are in fact very small oscillations on the roll-autopilot in the real crj .you cannot feel them, but when yout watch the ailerons, you can see them permanently oscillating a little bit - i could not see this at a real boeing or airbus. i also thought about the joystick-calibration as a possible source for the problems, because there a very different systems. it makes a big difference wether the joystick centers by spring-force or provides a "floating" center by the feedback force. the second difference is, that some trim-systems shift the center of the joystick, others not - i think the crj does not (at least at my joystick). i have attached a screenshot of my 777-ap-page just for information how it looks like on my system so for the moment as workaround i will try t find a set of parameters, which provide a stable flight with minimum changes of the default in my environment - this is ok for me.

Philipp, i will try to produce some test-data. the situation i had yesterday was, that i did some flights in Jamaica, the changed the position to Greece (LGTS) with turning off and realigning the IRS. When i opened a new flightplan from LGTS to LGSM it showed me the distance to jamaica and i found now way to get rid of the wrong ppos-entry. but i will try again and send you a screenshot, when i have the situation. Thank you. Stefan

removing preferences and setting up solutions did not help. i have tested now the 777 - it's absolutely stable up to vmax -10kn (which are 380kn) and starts to limb a little bit at vmax-5kn. so it cannot be an issue of xplane10, because the AP-parameters are airplane-specific. so i took the autopilot parameters from the 777 which are 17 for the pitch error, 2,0 for the pitch rate 2,6 for the response-time and 2.4 for the prediction time, and used them for the CRJ200, which made the CRJ AP now stable up to 330kn - no more oscillations! maybe crj-development should think about changing the default parameters of the plane for the next release.

I have mentioned this, that i have tested at 330kn for more significant results,. it still occurs at 300kn, which is an usual operating speed for cruising and becomes worse unter heavy wind conditions. and as alex writes, there is a difference between xp9 and xp10 - he says "In XP9 this problem is less noticeable but happens from time to time". the problem was very significant in the beta-releases of xp10, but it still occurs on the release version of xp10.

Hi Japo, first the bad news: i am sure that there is a problem with the AP (i do not fly bad manouvers, and i always try to maintain speed as exactly as possible) - i did a lot of systematical testing to proof this. when you try the following first scenario: speed 330kn (10kn below maximum), vertical mode ALTS at 9000ft, hold HDG, then you initiate an 30 degree turn with the AP, the AP loses control over the airplane, when it should stabilize pitch after rolling out from the turn. second scenario: speed 330kn (10kn below maximum), vertical mode VS 0.1(very slow climb!) for climbing from 9000ft to 10000ft, hold HDG, then you initiate an 30 degree turn with the AP and in this scenario the AP has full control over the airplane, no oscillations - maybe it's not able to hold the climb-rate correctly which does not matter. so, why does the oscillation-problem only occur in the ALTS and ALT CAP mode and not in the VS-Mode? because they use different controllers! and the controller for the ALTS-mode doesn't work correctly, but the controller for the VS does. i used 330kn for better testing, but the problem also occurs at 300kn in some situations. now the good news: i found a solution (i like finding solutions much more than complaining about problems :-), which works pretty good up to 330kn. i changed the parameters for the pitch-controller: special/set autopilot constants/use custom autopilot constants pitch prediction: 2,4 seconds pitch error for full elevator: 28 EDIT: pitch response time: 3 seconds pitch rate: 5 degrees/second. since i found this values using my experience with configuring controllers by trying a little bit, and not using scientific methods, i am sure, there exists a better solution (which has to be computed from the aerodynamical data of the airplane), but this first approach works fine. i have tested this settings in different situations and could not find any side-effects.