[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 483: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4752: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3887)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4754: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3887)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4755: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3887)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4756: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3887)
Fsbuild-2 Flight Planner • View topic - 1.8 Settings Problems

Fsbuild-2 Flight Planner

Fsbuild 2 support forum
It is currently Sat Apr 27, 2024 10:41 am

All times are UTC




Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Sat Sep 08, 2012 1:08 am 
Offline

Joined: Thu Sep 06, 2012 12:25 am
Posts: 26
On the subject of WptProcChg and WptChg...

What I have discovered is it's speed dependent. Above a certain speed (unknown at this time) both the Dist and Secs values get ignored and a default Dist of 3.0 is used instead. DIST will not work on the 727, so it's fast enough to prevent the Dist settings, but Secs will work. On the Concorde, neither will work until near normal airliner speed where at some point the Secs values are accepted. To find out the exact failre speed will require having many waypoints near the failure point and I don't have patience to do that.

It may be you're not testing with enough speed to trigger the faults.

-Pv-


Top
 Profile  
 
PostPosted: Sat Sep 08, 2012 2:01 am 
Offline

Joined: Thu Sep 06, 2012 12:25 am
Posts: 26
Here is an image proof it's possible for the program to use less than the 4.0 miles as the turn/active distance for a waypoint.
Relevant settings from ISG aircraft cfg file:
WptProcChgSecs=10
WptChgSecs=20

I also tried:
WptProcChgDist=3.5
WptChgDist=7.0

Both these are being ignored when the aircraft is flying about a certain unknown speed. The Secs get ignored at a lower speed than the Dist values. Even if I did this all wrong, the default 4.0 should be used, yes?

See image conc_30TURN.jpg showing the aircraft is about to cross the waypoint at 3.0 miles. At mach 1.37 and 755 ground speed, the turn should begin a LOT further out than this.

Note: The seconds calculation seems off. When it works, I cross the waypoint in about 1/3 of the calculated time. A setting of 20 crosses the waypoint in 7 seconds or less.
-Pv-


Attachments:
File comment: Image demonstrating above certain speeds WptProc and WptSecs distances and time get ignored.
conc_30TURN.jpg
conc_30TURN.jpg [ 253.85 KiB | Viewed 15687 times ]
Top
 Profile  
 
PostPosted: Sat Sep 08, 2012 6:27 pm 
Offline

Joined: Thu May 19, 2005 3:45 pm
Posts: 3903
Location: NJ, USA


Top
 Profile  
 
PostPosted: Sat Sep 08, 2012 9:48 pm 
Offline

Joined: Thu Sep 06, 2012 12:25 am
Posts: 26
"Regarding WptProcChg and WptChg...

It still works for me , just fine.

But then I don't have the original 1.8 version anymore and several changes have been made since then
to the version I have. So we will accept that at this time it works in my version, and not in your version."

Ahh... We are not using the same version. That explains a lot. I cannot get the distance variables to work at all no matter
the circumstances and using two different profiles. I will have to strip out all the variables and use only those and see if there is an unexpected interaction.

"I wish the the program would command smaller than 1500 when close to the target altitude. Otherwise the pilot is
forced to override the VNAV close to the target to avoid the sudden jerk as the AP tries to pull the plane out
of the sharp dive at the last moment.

I looked in the code, there are 2 .cfg items MinVnavClimbRate=, MaxVnavDescRate=, that should change that.
The max .cfg settings apparently made it into the settings doc, but not the corresponding Min settings."

Beautiful. Will see what I get when using the Min setting for the climb. There wouldn't happen to be an undocumented
MinVnavDescRate I can use to solve this particular problem?

"The default descent speed for all the aircraft I fly is set myself in the FS aircraft.cfg file. None of my
aircraft have 1500 set as the default vertical speed. In the case of the Concorde where this fault has been observed twice,
the default VS is 1200...

There is no fault here.

It is auto-correcting the altitude deviation.

It will automatically return to the cruise alt if you deviate from it while in cruise.

That is why you are seeing the positive vertical speed, when you change the altitude.
It is detecting the deviation and correcting it.

If you change the altitude value in the altitude window and the aircraft has a default vertical speed,
that will cause a deviation, which it will not allow while in cruise.

If you wish to pre-select the descent altitude, then you will need to set the aircraft's vertical
speed setting to '0' so's not to cause a deviation when a new altitude is entered prior to reaching
the TOD."

I'm not doing any of the things you suggest here. What I see is the result of a stable cruise to descent transition.
I'm not monkeying around with the AP ALT or VS. Again, that were not flying the same product version is problematic.

"I've also noticed once the VNAV has sent the maximum descent rate (MaxVnavDescRate=2500) to the AP or it's
internal minimum of -1500 to the AP, it disables itself (VNAV button changes from yellow to white.)

I've never experienced this. The only times it should disables itself is if the VNavOffAtLastWpt=1 setting
is made, and the last Wpt is reached, or if the VNavOffOnManAltChg=1, and the alt window value is changed."

Every time the VNAV engages a climb or decent in either of my two aircraft profiles, it shuts off immediately EVERY TIME.
I have to re-engage the button then it will stay on. The behavior gives the impression it's detecting it's own VS submission to the AP as a user input and disabling. After re-engaging, it will continue to send commands. That were not flying the same product version is problematic.


Observed Climb Behavior:
Descent has a "reasonable" behavior within current limitations of the product. A large descent is commanded near the start with decreasing vertical speed values nearer the end.
Climb should mirror this behavior but it doing the wrong thing and setting min near the ground and max near the top. Aircraft have much more climb poser near the ground when full engine power is available and the air density produces maximum lift. Therefore, Large climb rates are used to get above noise abatement altitudes and take advantage of the available lift and power. As the plane climbs, the enginee lose half or more of their Max Static Power so are continually leveling out as they get near cruise. VNAV behaves in the opposite way. It starts out using it's current internal limit of 1500 ft (hopefully MinVnavClimbRate) will fix this and as the TOC error grows continues to add more VS up to MaxVnavClimbRate. Needless to say, this is not possible in ANY aircraft and pilot intervention to turn off VNAV half way through the climb is necessary, negating its usefulness as a feature. Both using climb rate variables and FPA settings behave this way.
-Pv-


Top
 Profile  
 
PostPosted: Sat Sep 08, 2012 11:08 pm 
Offline

Joined: Thu May 19, 2005 3:45 pm
Posts: 3903
Location: NJ, USA


Top
 Profile  
 
PostPosted: Sun Sep 09, 2012 1:25 am 
Offline

Joined: Thu Sep 06, 2012 12:25 am
Posts: 26
"pvarn wrote:
"The descent target altitude is set properly and the vertical speed is set to a positive number instead of a negative causing the plane to climb.
The two times I've experienced this is when VNAV was on during start of cruise....."


You're statement above implies you changed alt while in cruise, and in another post you confirmed your concorde had a default VS
of 1200."

No. VNAV set BOTH these values, not I. This behavior is what VNAV is doing, not I. BTW, it doesn't ALWAYS do it. There is a condition which must be met which will required a lot more time to isolate, but appears to have to do with the speed of the Concorde.

"Every time the VNAV engages a climb or decent in either of my two aircraft profiles, it shuts off immediately EVERY TIME.
I have to re-engage the button then it will stay on. The behavior gives the impression it's detecting it's own VS submission to the AP as a user input and disabling. After re-engaging, it will continue to send commands. That were not flying the same product version is problematic.


Unable to reproduce.

Has nothing to do with difference versions. The VNAV feature has not been touched since version 1.2, the code has never been changed.

Other customers are using the VNAV feature.

The behavior you are describing is so out of line with the feature, its not even worthy of further investigation unless another customer can confirm it."

"VnavSetSpd=0 // Does not set speed when VNAV is on (default is 1) IGNORED. AIRSPEED STILL CHANGES WHEN VNAV ACTIVATED.

This setting works. Its been confirmed many times."

"I just tried it, and you are right 'VnavSetSpd=0' does not work, its not accepting VnavSetSpd=0 for some reason, we must have
broke it in the 1.8 update.

As a workaround use VnavSetSpd=3, that should work in place of 0 with the same effect."

I hope other customers using V1.8 are using your reporting system and letting you know their experiences.

"If it doesn't work for you , then I recommend not using the VNAV feature, it doesn't work like a real VNAV function anyways, it was intended to be simplified.

A real VNAV would have thrust ref settings for Climb, and adjust pitch for speed."

I had no idea until now the product was unable to work like a reasonable FMS would work and control the plane at least to the level a competent pilot would. If a tool cannot simplify the workload of a pilot, it's not helpful. The free GPS will track and turn on a flight plan with the same precision I get out of this product since I cannot get the Dist and Secs variables to work reliably (Dist never) and being able to control altitude is half the product.

On a positive note, I have it working well on descent now that I discovered MinVnavDescRate works. Ascents are cleaning up also since discovering the MinVnavClimbRate which also works. As long as I leave VnavSetSpd=3 set and manage the speeds myself, the worst of the problems are avoided, but the remaining problems cause additional workload instead of reducing it.

I've noticed also there isn't a lot of Net traffic with customers creating aircraft profiles they like and distributing them (other than the few samples that com with the product which are bare bones and primitive in operation.)

My goal with all this was an attempt to discover if there is enough control in the "Settings" values that a more refined aircraft profile could be created which the pilot can rely on for certain workloads. I could then provide for free the resulting refined profiles for the many simmers out there begging for them. My investigation so far is it's so much work, I suspect few people try it and I've seen a lot of messages of people failing. Maybe they experience what I have and I suspect my time in the sim, gauge coding, FS SDK knowledge, etc provides me with more background than most people who would buy the product and expect after learning the control interface, it would be click and go would have. While I wasn't expecting a product even after years of development to be perfect, I did expect it to approach the TOC with less VS than at the BOC. I can manage the speed, but to have the program do the opposite of what is required just to keep the plane from stalling out is pretty basic. A newbie pilot would stop doing what the VNAV does on a climb after crashing a time or two.

I also get the impression there is a whoopty do version out there which is not 1.8. Maybe THAT version where the Dist and Secs waypoint turning work would be better than what I have.

Thanks for your support and patience.
-Pv-


Top
 Profile  
 
PostPosted: Sun Sep 09, 2012 2:55 am 
Offline

Joined: Thu May 19, 2005 3:45 pm
Posts: 3903
Location: NJ, USA


Top
 Profile  
 
PostPosted: Mon Sep 10, 2012 8:57 pm 
Offline

Joined: Thu Sep 06, 2012 12:25 am
Posts: 26
I'm a new user so I'm not as knowledgeable of the limitations of the product and real world products as your seasoned customers.

In FS9 I used an add-on FMS which is not available for FSX. It had an extensive aircraft profile API similar to yours. It worked very well when the aircraft was fully customized. Likewise, MS also provides some AP customization in their .air and .cfg files which when set correctly, goes a long way toward refining pitch and bank speeds as well as very fine and effective control over ILS and GS performance. This is what these cfg files are all about, providing "certified" (in lose FS simulation land) customization of AP behavior for different aircraft. If you weren't making ANY attempt at aircraft customization, there would be no cfg profile files and no variables to tweak. Learning these variables, what they do and their limitations has been the learning process for me. Seeing them described and actually trying to use them is a trial and error process. I suspect few of your customers attempt it since I see no other profiles except which come with your product being distributed on the net.

Try this experiment:
737 at cruise altitude ans 380 KIAS in Smiths FMS and as far away from a TOD as you can get.

In the cfg file set the following variables:
CruiseIasMax=250
CruiseIasMin=250

DescentIasMax=280
DescentIasMin=280

Click the VNAV button and see which speed the program sets the AP speed bug to. My observation is it sets cruise speed to the value(s) of Descent.

Weight displays:
As mention earlier, it's better to get totals from FS provided variables than to try and calculate thme by gather bits of data from various sources. Between the unknown number of station loads available in FS9 and FSX and the many tanks you have to gather data for and add all this up, it's much much easier to gather only three variables from FS and no matter the aircraft configuration your totals will always be right. Zero Fuel weight, Total fuel weight, and Gross Weight. Gross weight already does all the hard lifting by totaling XFW, all the unknown station loads, and total of ALL the tanks and does so accurately.

Positives:
I now have working profiles for the 727 and Concorde with the following attributes and limitations:
1) Both, the pilot manages all speeds (VnavSetSpd=3).
2) Concorde climbs at a fixed rate in Smiths until 50K ft cruise climb where the pilot disengages VNAV and sets the 100ft/min cruise climb profile.
With the discovery of undocumented features: MinVnavClimbRate and MinVnavDescRate, I can now control the descent perfectly from 60K ft right down to any altitude limits set in the MCU or calculated in the FMS. The FPA of 1.9 is working very well with the TOC representing the beginning for Cruise Climb and the TOD representing 300 miles out at 350 KIAS (M1.65.) The Mach climb is at a fixed rate of +1500 which covers the 0-50K mach climb profile very well at which time the pilots turn off VNAV and sets +100ft/min. Pilot is performing 100% of the speed, 60% of the climb (the easiest part) 0% of the descent, and 0% of the navigation. When flying in an intense Vatsim ATC environment where one person has to do the work of three crew, any workload relief is welcome.
3) In the 727 FPA is disabled and I'm using DescentTas for the TOD calculation instead of FPA and the plane will perform a perfect descent to any altitude (again thanks for the discovery of MinVnavDescRate.) Climb is at a fixed rate until the pilot disables VNAV to start gradual level off. Pilot is performing 100% of the speed, 40% of the climb (above 25K ft) 0% of the descent and 0% of the navigation. Again, ANY workload relief while flying online in ATC control is welcome.

I like the navigation displays for the approach in HSI very much. I wish features on the display such as current heading at the top, track error at the bottom, and (when in descent or ILS mode) the glideslope error on the right side did not cover up to 110 degrees of the compass markings.

Updates:
I'll be encouraged with any improvement(s) you make at whatever timetable.
Thanks for your responses.
-Pv-


Top
 Profile  
 
PostPosted: Fri Sep 14, 2012 12:05 pm 
Offline

Joined: Thu Sep 06, 2012 12:25 am
Posts: 26
"Even with the default settings. It will change waypoints at about 3 miles. I can't see any real reason why that
wouldn't work for you."

In answer to this question, it doesn't work and I spent a few days pondering this and observing the LNAV behavior and I need to type a lot of characters here explaining my answer because there are some principles and terms which I don't want misunderstood. I also want to make sure you understand this is not an emotional "I own and defend this with my life" nor am I asking you to defend the program. I'm simply describing what I see when I use the program and why I have trouble with it. I also take the risk in offering some suggestions near the end.

In the subsequent narrative, I pursue these four objectives:
1) Describe an ideal (turn-only) autopilot-to-aircraft model behavior.
2) Describe some terminology which I hope will make follow-on explanations clearer.
3) Describe current LNAV behavior and why it's undesired.
4) Describe a potential solution which should preserve much of the current LNAV code yet make a dramatic improvement to the turn performance.

1) Ideally, a generalized auto pilot should behave correctly on a correctly behaving aircraft. Explanation:
When it comes to turning, a correct FS flight model which represents a passenger aircraft where the passengers are not wearing G suits and helmets and the pilot is not performing snap rolls or competitive air show maneuvers, should turn smoothly and evenly to the defined bank limit with no instability at the end of the roll. To put a finer point on it, the passenger aircraft when commanded to a 90 degree turn should turn smoothly and professionally approximately 5-8 degrees per second and at the end of the roll, there should be no bouncing back and forth (no instability.)
2) An autopilot should not be trying to correct a poor flight model which when commanded to a large turn angle, turns too fast (snap rolls) and/or bounces (unstable) at the extremes of the roll. At this point I'm not concerned with advanced corrective autothrottle corrections which are more of a discussion for VNAV.

I have been using the FMS LNAV on correctly modeled aircraft which when left to themselves without LNAV and the AP heading bug is commanded by the pilot to a 90 deg turn, rolls smoothly and evenly stopping at the limits of the roll without instability until the aircraft is point in the direction of the heading bug without overshooting. This is the behavior of my aircraft without the FMS.

Now, some definitions of terms so what I say next may be understood. These may not be scientifically correct or terms used by real world autopilot engineers, but are intended for clarity by this sorry layman:
1) "Map Track": Describes the direct line between one waypoint and another as if you were drawing a line directly between locations on a flap map. This shows up as the green track line on the HSI map display.
2) "Turn Point": Describes the actual MOMENT when the AP is command to direct the aircraft into a turn. This may have been referred to as "tracking" in the "Settings" documentation.
3) "Ground Track" is the actual path the plane takes over the ground.
4) "Resolve" or "Resolution" is the PROCESS by which the autopilot corrects the plane ground track to the map track over time.
5) "Turn Waypoint" is a waypoint which is not just a pass through in a straight line, but a waypoint over which a turn is expected after which the next waypoint represents a significant change in direction or heading.
6) "Target Waypoint": Waypoint which represents the new turn result target waypoint.

Now is the time to make a observation statement I will attempt to describe in detail afterward:
The Seconds and Distance variables which have greatly confused me do so by not doing what I expected (right or wrong.) They do not ANTICIPATE a turn, but DELAY a turn. In medium to high speed aircraft, anticipation is more helpful than a delay. The faster the speed, the longer it takes to make a turn, so if accuracy is desired (efficiency may be a better desirability) the faster the aircraft, the more anticipation is needed (assuming the roll rate is constant at all speeds- which it mostly is in FS aircraft under AP control) There is less overshoot of the "Map Track" when the turn is started before the "turn waypoint" just as a race car driver will "lead" a turn by turning to the inside of the race track as soon as possible so as to keep the curve of the turn as shallow and long as possible, then moving toward the outside of the turn near the end. The current implementation of DIST and SECS "appears" to have the purpose of making the turn longer (extending the turn) at the cost of increasing track error during the near-term initial stage ( plane is not yet pointed at the next target waypoint.)

When I use LNAV to control my aircraft, here is the set up to the turn:
1) Level flight with no roll approaching a "turn waypoint"
2) The NEXT waypoint represents a 30 degree turn to the left, 100 miles away.
3) The aircraft profile has the setting: WptChgSecs=20

At turn initialization, here is what happens:
Exactly 3.0 miles prior to crossing the "turn waypoint" the first "turn point" command is sent from LNAV and sets the AP heading bug to approximately 90 degrees to the RIGHT of the current aircraft ground track. In other words, the first command of the LNAV AP is to turn the aircraft AWAY in the opposite direction of the next waypoint. At the same time, a yellow dot and attached dotted line is drawn on the ASI representing a position 20 seconds in the future (beyond the green "map track") and the dotted line's far end intersecting the target waypoint. As the aircraft begins to turn away from the desired direction of travel and crossed the "map Track" but still getting closer to the yellow dot and line, the LNAV slowly (at apprx 1 degree/second) begins to straighten out the turn by adjusting the heading bug left, so by the time the aircraft crosses the dot, there is minimal roll (straight and level.) As the plane crosses the dot and the yellow line the LNAV slowly (apprx 1 deg/second) starts turning the plane left toward the target waypoint. By this time the track error as displayed in the FMS Progress page three is significant. In the 727 it's nearly a mile (at mach 0.84) and in the Concord it's nearly 2 miles. As LNAV tries to "Resolve" this error the AP heading bug will be directed increasingly left until it's held about 60 to 90 degrees left of the direction of the target waypoint some 100 miles distant. As the aircraft turns back to the LNAV desired yellow line and the track error drops again toward zero, the AP heading bug will slowly turn right again (1 deg/second) until the bug matches the current heading of the aircraft which is now 20 degrees left of the target waypoint heading. As the track error begins to grow in the other direction (right) the LNAV will slowly try to "resolve" the new growing error again by advancing the heading bug 1 degree/second to the right and by this time the track error is nearly a mile in the other direction when the heading bug stops advancing. Each of these first few corrective resolution turns command the aircraft into its max bank angle. Successive corrections will have smaller bank angles. If I were a passenger on this aircraft, I would think the pilot was drunk. The resulting "ground track" looks like the S turns the Space Shuttle makes slowing down during re-entry interface.

The entire process described above is repeated over and over again with the track errors and bank angles slowly getting smaller. In the Concorde, the point where the heading corrections are down to two degrees is approx 50 miles after the turn process was initialized (the yellow intercept line created.) In the 727 about 18 miles are required. BTW: the B777 and B747 cruise at the same speeds as the 727-200 so their turn behaviors are similar.

If I were to attempt to write this VNAV myself, there is how I would describe a successful turn and intercept (based on commanding the AP heading bug myself):
1) Change the WptChgSecs and WptChgDist variables so they were predictive rather than delays. The "turn point" (turn initialization) or what you may have referred to in documentation as "tracking" will now trigger before the actual "turn waypoint" by the variable distance or time.
2) At the calculated "turn point" (the newly predicted ANTICIPATED point) the AP heading bug will be immediately (not gradually as it is now) positioned so it points DIRECTLY at the target waypoint (match heading bug to target direction.)
3) Throughout the initial turn bank, the AP heading bug will be corrected as necessary to keep pointing directly at the target waypoint heading.
3) When the aircraft heading exactly matches the current target waypoint heading the code will then analyze the track error and make appropriate gradual adjustments to the heading bug to resolve the ground track to the map track.

I believe this is the process the GPS NAV program uses to great success except there is no effective prediction distance other than ALL aircraft at ALL speeds are turned at 3.0 miles or less. Aircraft faster than mach 0.70 suffer from increasingly snaking turns. After all, FS is by philosophy intended to be a general aviation simulator with jet aircraft as a concession. With the introduction of turn prediction added to a refinement of the existing code to resolve the ground track to the map track, a very effective LNAV could be created which would work with ALL aircraft at ALL speeds and the purchaser would have a much more powerful tool to customize the behavior of the LNAV to the dynamics and speed of the model.

Positive results of the three step process above:
1) LNAV will take the most efficient ground track to the target.
2) LNAV will use the aircraft's maximum bank angle at the BEGINNING of the turn (instead of in the middle as it does now) to minimize the number and intensity of successive corrective banks.
3) After having immediately turned the aircraft directly at the target waypoint, the resulting track error is as small as possible in the shortest time possible.
4) The resulting corrective turns and bank angles after pointing at the target waypoint will be 90% or more smaller than they are under the current procedure.
5) The current aircraft profiles distributed with the product will not require any change.
5) Much of of the current LNAV code can be retained. I tested this myself by:
a) waiting for the LNAV turn trigger and yellow dotted line.
b) immediately disabling LNAV and use the AP heading bug to point directly at the next waypoint target.
c) when the plane was pointing directly at the waypoint target, re-enable LNAV. The result was LNAV then made small corrective banks to resolve the track.

Again I will stress, the above procedure requires the aircraft model to behave correctly as described at the beginning of this narrative where input from the pilot to the heading bug manually does not result in snap rolls or bank limit instability. If an AP is coded to try and correct bad aircraft modeling, the navigation program becomes self defeating and performs improperly and inefficiently on well made models and only behaves "good enough" but not excellent on very slow and highly maneuverable planes.

I realize this is not what you wanted from me in answering this question and it's also a long and fatiguing explanation potentially loaded with defensive triggers. My hope is it increases understanding and contributes to future development refinements. If necessary I can create a series of screenshots or Fraps animations demonstrating the observed LVAV behavior and email them to you. It's also likely my professional software tester technique is showing through where I'm used to exactly explaining what the software is observed to to and what the software should do. Since it's obvious from the displays and actions of the LNAV it's getting all the information it needs from the FS environment and the LNAV has positive control over the heading bug, I believe it can be written to do what I describe with little additional effort. Essentially, reversing two current behaviors:
1) Make the Dist and Secs variables calculate the time and distance TO the turn waypoint (instead of after as it appears to do now.)
2) Make the maximum effort to turn the aircraft at the BEGINNING of the turn rather than at the first and subsequent track corrections as it does now.

Thanks for your patience.
-Pv-


Top
 Profile  
 
PostPosted: Fri Sep 14, 2012 5:51 pm 
Offline

Joined: Thu Sep 06, 2012 12:25 am
Posts: 26
Provided a simplified diagram of what I tried to explain above.


Attachments:
LNAV.jpg
LNAV.jpg [ 45.98 KiB | Viewed 15662 times ]
Top
 Profile  
 
PostPosted: Sat Sep 15, 2012 2:52 am 
Offline

Joined: Thu May 19, 2005 3:45 pm
Posts: 3903
Location: NJ, USA


Top
 Profile  
 
PostPosted: Thu Sep 20, 2012 6:49 pm 
Offline

Joined: Thu Sep 06, 2012 12:25 am
Posts: 26
"I have made a video using the 'default' 747-400 retrofit, with a 90 degree left turn in LNAV at 200 knots, level at 10000 ft."

I would expect your example to work as it does for me because the speed of the aircraft is so slow (close to approach speed) and not anywhere near cruise speed where problems become more apparent due to larger turn radius. Get your 747 up to cruise speed (280-300 knots or Mach 0.84 at 35K ft and set a 30 degree turn and you will see the undesired behavior. I appreciate the work you put into the video. I can replicate that performance at low speed. As speed increases, more lead time is required so, if the DIST and SECS variables worked properly, they would solve that problem. I cannot get them to solve that problem

My Concorde will become available on flightsim.com in the next 24-48 hours. Since it's freeware, it only costs download and installation to test it.
The included panel file already has the FMC coded into it, just needs to have the relevant lines uncommented. The Concorde also performs similar to the 747 at the speed you used since they have the same approach speed at landing weight. Cruise route is where I use the FMC to turn on route 90% of the time. I use APP mode to turn on final which the Conc will do perfectly from 90 degrees off axis using APP mode. Under VATSIM ATC control, rarely do we pilots have the luxury to make procedural turns on FMS.
-Pv-


Top
 Profile  
 
PostPosted: Thu Sep 20, 2012 10:12 pm 
Offline

Joined: Thu Sep 06, 2012 12:25 am
Posts: 26
I see a difference in the video in the appearance of the EHSI display. Perhaps we are not using the same one or version. I'm using the "EFS50_EHSI" in release version 1.8.

In your video, the EHSI creates a RED SOLID line at the turn point BEFORE the turn waypoint (when you cross the 3 mile trigger) and follows this red line through the turn.

In my EHSI, at the 3 mile trigger, a YELLOW DOTTED line is created BEYOND the turn waypoint and the plane follows the dotted yellow line (late.) This difference is shown in my diagram above.

Questions:
1) Are we using the same EHSI? If not, will I get the behavior you get (which I desire) by switching? Which EHSI are you using?
2) If we are using the same EHSI, why do they look and behave differently (yours better?)
3) If we are using the same gauge, and they are different, will the EHSI you're using become available in the next upgrade?

Other than that, as stated above, when near terminal or approach speed, the three mile turn trigger is not a factor. As you stated, most planes can turn OK at three miles at this low speed. What's needed is a way to ANTICIPATE the turn at increasingly longer intervals as speed increases (cruise turns.) There is nothing I've been able to do to make the DIST or SECS variables ANTICIPATE a turn at longer than 3.0 miles and instead of anticipating, a line is drawn BEYOND the turn point instead of AHEAD of it as desired.
-Pv-


Top
 Profile  
 
PostPosted: Fri Sep 21, 2012 11:21 pm 
Offline

Joined: Thu Sep 06, 2012 12:25 am
Posts: 26
Did the following test today:
Using sim reset, flew the exact flight pan over and over with no variation. Same altitude and speed crossing the same turn point. The next waypoint was 160 degrees to the left 160 miles away.

With no SECS or DIST variables, the LNAV turned over the waypoint exactly 3.0 miles every time.
Added the following SECS variable to the cfg file:
WptChgSecs=14.0
Result:
LNAV turned 1.4 miles prior to the turn point (650 knots ground speed)

WptChgSecs=28.0
Result:
LNAV turned 2.8 miles prior to the turn point (same speed and altitude)

WptChgSecs=48.0
Result:
LNAV turned 3.0 miles prior to the waypoint

WptChgSecs=96.0
Result:
LNAV turned 3.0 miles prior to the waypoint

WptChgSecs=192.0
Result:
LNAV turned 3.0 miles prior to the waypoint

This gives me the impression 3.0 miles is not the minimum when there is a WptChgSecs value set, but the maximum. Also, the program appears to insert a decimal
after the first character of the value and uses the result as miles, not seconds. With a value of 14 SECONDS, I should have had between 5 and 10 miles prediction if calculated as seconds.


Did the same test (same plan, waypoint, speed) with WptChgDist:

WptChgDist=1.0
Result:
LNAV turned 3.0 miles prior to the waypoint

WptChgDist=2.0
Result:
LNAV turned 3.0 miles prior to the waypoint

WptChgDist=5.0
Result:
LNAV turned 3.0 miles prior to the waypoint

WptChgDist=10.0
Result:
LNAV turned 3.0 miles prior to the waypoint

Here is the complete configuration used for the last "WptChgDist=10.0" test:

--------------- CUT BELOW HERE ------------------------------
; AEROSPATIALE Concorde
ModelId=AEROSPATIALE_Concorde
MinVnavIas=180
ClimbTas=780
ClimbIas=400
ClimbRate=1500
MinVnavClimbRate=1500
MaxVnavClimbRate=1500

MaxVnavDescRate=2400
DescAltRest=6000
DescSpdRest=250

FPA=1.9

//MaxCruise=60000
VnavSetMachCruiseSpd
CruiseTas=1140

VnavSetAlts=1

VnavSetSpd=3

DescentTas=620
DescentIas=350
DescentRate=1200
MinVnavDescRate=700

VnavSetSpdRestDist=15
WptChgDist=10.0

// Smiths:
// Following 2 items Ignored in v1.8:
CruiseIasMax=515
CruiseIasMin=385
BestHoldIas=225
ClimbIasMax=405
ClimbIasMin=395
// Determines TGT cruise speed on CRZ page:
DescentIasMax=515
CostIndex=100
EngThrust=30650 // Displays as (30K)

V1=180
VR=190
V2=200
Vref=155
VrefMin=155
VrefMid=158
VrefMax=162
TOFlaps=0
TOFlapsRange=0

// Special:
SetMCPCrzAltOnFlightPlanLoad=0
VnavOffAtLastWpt=1
VnavOffOnManAltChg=1
VnavSetSpdOffOnManSpdChg=0
LnavSetEnRouteFreqs=0
SetSpdOffwhenAPMasterSetOff

FlightPlansFolder=G:\Microsoft Flight Simulator X\ISG\ConcordePlans
ParkingFile=isg_Parking.txt
MFDTextAntiAlias=0


-Pv-


Top
 Profile  
 
PostPosted: Fri Sep 21, 2012 11:50 pm 
Offline

Joined: Thu May 19, 2005 3:45 pm
Posts: 3903
Location: NJ, USA


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 133 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group