Orlaam

Lateral tracking issue?

Recommended Posts

I have noticed the lateral tracking is very unsteady.  The plane will list from side to side between waypoints.  This is maybe a 3-5 degree deviation back and forth, as if it never really stays on the path correctly.  This is with the CDI/HSI slaved to GPS and GNS flight plan entered manually, not imported.  It's not a weather-related anomaly either.  

Is anyone else noticing this problem?

A2A Comanche, if that matters. 

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Didn't have this problem in the A2A 172. Stayed right on course even thru some wind turbulence.

  • Upvote 1

Share this post


Link to post
Share on other sites

Weird.  I've done two flights so far, and both had this issue.  It's subtle, but noticeable enough to be abnormal.  Never had this before with any add-on, including the original RXP GNS.  It's FSX:SE I'm using.  I'm not sure how this could be corrected... ??

Share this post


Link to post
Share on other sites

Hi Chris,

My initial tests with the S-TEC System 30 in the Cherokee/Comanche were pretty brief (just following a GPS track to a convenient VOR). However, I've just tested in the Comanche with the KHQM RNAV 06 procedure loaded into the GNS 530, and the S-TEC 30 in TRK HI mode seemed to work as advertised (the test was carried out with a negligible crosswind component I'll admit).

The S-TEC 30 is pretty limited in terms of its lateral tracking capabilities remember. From the user manual "maneuver the aircraft to within ±1 CDI needle width and ±10° heading of each successive course segment. Engage the high track mode."

Did you happen to note your FPS when this happened?

Nick

  • Upvote 1

Share this post


Link to post
Share on other sites
45 minutes ago, Nick M said:

Hi Chris,

My initial tests with the S-TEC System 30 in the Cherokee/Comanche were pretty brief (just following a GPS track to a convenient VOR). However, I've just tested in the Comanche with the KHQM RNAV 06 procedure loaded into the GNS 530, and the S-TEC 30 in TRK HI mode seemed to work as advertised (the test was carried out with a negligible crosswind component I'll admit).

The S-TEC 30 is pretty limited in terms of its lateral tracking capabilities remember. From the user manual "maneuver the aircraft to within ±1 CDI needle width and ±10° heading of each successive course segment. Engage the high track mode."

Did you happen to note your FPS when this happened?

Nick

Hi Nick, essentially what it does is S-Turns, but they are slow 3-5 degrees.  Like a drunk person flying basically.  FPS is locked at 30, totally not the issue.  Later today I'll post the map view and show you.  I meant to screencap it last night for posting, but was tired and forgot once the flight was over.

Share this post


Link to post
Share on other sites

The A/P coupling is independent of the actual A/P gauge you are using. It goes deeper than that, and overrides directly the H/V coupling. So, whatever the A/P gauge is doing, as long as it is basically arming default A/P modes behind the scene, our A/P coupling is taking over, and overrides the H/V coupling.

If the aircraft is "swinging", this means that either you are not flying at 1:1 time scale (we are working to enhance this case but we've not devised a sound solution yet), or, your aircraft A/P parameters are too loose. More specifically, in the aircraft.cfg file:

nav_proportional_control=9.00
nav_integrator_control=0.25
nav_derivative_control=0.00
nav_integrator_boundary=2.50
nav_derivative_boundary=0.00
gs_proportional_control=9.52
gs_integrator_control=0.26
gs_derivative_control=0.00
gs_integrator_boundary=0.70
gs_derivative_boundary=0.00

These are the parameters which condition how fast, and how tight, the changes will occur for the aircraft to follow a set bank/pitch.

I wish there was a way to override the F/D with the SDK but there is none. As a matter of fact, internally, the F/D is a byproduct of the A/P logic (weird, but this is how they have coded this), whereas in X-Plane, the F/D is what drives the A/P guidance, and their SDK offers overrides.

Nevertheless, the GNS V2 A/P coupling is much better than the older one. For example, when flying a curved track, you can adjust your speed and see how it commands a different bank angle to stay on the curve!

Besides, is this happening in all your aircraft or one in particular?

Share this post


Link to post
Share on other sites
55 minutes ago, RXP said:

The A/P coupling is independent of the actual A/P gauge you are using. It goes deeper than that, and overrides directly the H/V coupling. So, whatever the A/P gauge is doing, as long as it is basically arming default A/P modes behind the scene, our A/P coupling is taking over, and overrides the H/V coupling.

Guys - here's where some clarification may help. The A2A products in question do not use the default FSX/P3D autopilot; instead, they include custom standalone simulation of rate-based autopilots (the Honeywell KAP 140 and S-TEC System 30). As such, the autopilot behaviour is driven directly by inputs from the turn-coordinator, DG/HSI and so on, just as in reality.

As mentioned above, in the tests I've done the both the A2A KAP 140 and S-TEC 30 seem to perform as expected when the GNS 530 is in GPS mode: the former in both lateral and vertical modes; the latter in TRK HI as described above. (No advanced vertical modes in the old S-TEC 30!)

However - this perhaps demonstrates why a good working dialogue between RXP and prominent developers like A2A is good when it comes to integrating these products.

58 minutes ago, Orlaam said:

essentially what it does is S-Turns, but they are slow 3-5 degrees.  Like a drunk person flying basically.  FPS is locked at 30, totally not the issue.  Later today I'll post the map view and show you.

Okay, thanks Chris. Are you following the guidance in terms of using TRK HI in GPS mode that I quoted above? Because the S-TEC 30 lacks an intercept routine, you'll need to manually change course for all but the shallowest changes in desired track. The easiest way to do this is in stabilizer (ST) mode.

Nick

  • Upvote 1

Share this post


Link to post
Share on other sites
11 minutes ago, Nick M said:

this perhaps demonstrates why a good working dialogue between RXP and prominent developers like A2A is good when it comes to integrating these products.

You are perfectly right! And this is why the GNS V2 now exports SO MUCH more information for third party developers, all documented in the User's Manual as well!

For example, the GNS V2 Master Device exports this data (page 13):

rxp.hsi.bearing_deg_mag_pilot     degrees
rxp.hsi.flag_from_to_pilot        number 
rxp.hsi.hdef_dots_pilot           number 
rxp.hsi.vdef_dots_pilot           number 
rxp.hsi.has_dme_pilot             number 
rxp.hsi.dme_distance_nm_pilot     miles  
rxp.hsi.dme_speed_kts_pilot       knots  
rxp.hsi.dme_time_sec_pilot        seconds
rxp.hsi.flag_glideslope_pilot     number 
rxp.hsi.display_horizontal_pilot  number 
rxp.hsi.display_vertical_pilot    number 
rxp.gps.course_degtm              degrees 
rxp.gps.cross_track_nm            miles   
rxp.gps.time_sec_eta              seconds 
rxp.gps.discrete_out              number  
rxp.gps.nav_id                    number

These shall be sufficient to connect any A/P or EFIS, otherwise, it is still possible to read the default sim vars which we override with the same data as well (except the rxp.gps.discrete_out which has no equivalent).

Share this post


Link to post
Share on other sites

Just wanted to add that integration into the A2A fleet hasn't gone quite as smoothly as I first thought. I now realise that the A2A KAP 140 isn't following vertical guidance during the LPV and LNAV+V approaches that I've tried. The reason I first though it was doing so is because—through force of habit—I had a valid ILS frequency tuned into NAV1. It appears that the autopilot is intercepting this glideslope, not the GPS vertical guidance (despite the GTN CDI setting being 'GPS').

Not sure if there are any thoughts as to why this could be the case from RXP's end. And sorry, I realise that this is somewhat OT.

Nick

Share this post


Link to post
Share on other sites
27 minutes ago, Nick M said:

(despite the GTN CDI setting being 'GPS').

Not sure if there are any thoughts as to why this could be the case from RXP's end.

Please understand Reality XP GNS 530W/430W V2 and upcoming Reality XP GTN 750/650 Touch have nothing to do with another GTN product you are referring to. There is no point inferring the behaviour of one because of the behaviour of the other, because their implementation details are different and these are two different products.

These products are from two different companies that have nothing to do one with the other, F1 is only an e-commerce partner handling the C/C procurement for Reality XP retail business.

Having said this, we're working on some enhancements to the A/P right now!

 

Share this post


Link to post
Share on other sites

Sorry - pure finger trouble! I don't have the F1 GTN; I meant despite the GNS CDI being set to GPS. All my comments here most definitely relate to the RXP GNS 530W V2! (The only 'proper' GPS I have in the sim.)

Nick

Share this post


Link to post
Share on other sites
25 minutes ago, Nick M said:

The only 'proper' GPS I have in the sim

Until we release our GTN maybe ;-) 

Nevertheless, if they have implemented a custom A/P, which works based on normal simulator data (such as LOC/VOR radial signal, HSI needle deviation etc.., the reason it doesn't work in LPV might just be they have not accounted for any GPS LPV because the default GPS is not offering vertical capabilities.

However, if they only rely on 'radio-like' signals to feed their A/P code, then, it might be as simple to do vertical guidance as they do horizontal guidance when using our GNS V2, because we do override HSI, NAV and GPS sim variables (and module_var as well).

By the way, have you tried this A/P when you enable "Connect GPS to VOR indicator" in the settings panel?

This settings makes the GNS V2 override all 'NAV' related variables.

This works the same way "Connect GPS to HSI" makes the GNS V2 override all 'HSI' related variables.

NB: your GNS V2 must be the 'Master' otherwise it won't override the variables!

 

Share this post


Link to post
Share on other sites

I haven't attempted this in any other aircraft yet.  Here's what it's doing, back and forth about 5 or 6 degrees.  I have no idea what you mean by my time scale.  I don't use compression, and my values in the aircraft.cfg match yours posted exactly.

2017-9-1_14-22-33-722.jpg

 

2017-9-1_14-42-34-694.jpg

2017-9-1_14-43-2-17.jpg

 

2017-9-1_14-49-24-72.jpg

 

2017-9-1_14-49-38-861.jpg

Share this post


Link to post
Share on other sites

Thank you for the additional information. It is not clear from the screenshot what the problem is, but I can tell you the A/P is being worked on right now to make it better.

Share this post


Link to post
Share on other sites

I know it's hard to tell, but essentially wanted to show how I had it set up and the modes.  The second and third shot, where the GNS are popped up, are displaying that the desired track is 172, but the plane is wavering between 168 to 175 all the way from the 50 mile mark; the point in which I activated the approach.  It never really settles on a HDG, rather fumbles around as if it can't capture it completely.  In motion, you can see the plane list from side to side, like a boat in the water.  Everything else is working fine.  LPV is displaying on the G/S for vertical guidance and the CDI is being driven by the GPS.  It's just the tracking that is unsteady.

Thanks for looking into it! :cool:

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now