Need information on gyro slaving.

[Guest]

HiMy EHSI is now "working" what I _think_ is correctly in conjunction to a on/off speed slaving switch. If switch is off, it will drift like any other cheap gyro based indicator, if is is on it will be in close sync only affected by excessive yawing action (g's to follow).However, the checklist that comes with the POH I'm using (Cessna 421 :(, calls for a HI or LO speed on the slave switch.So I'm starting to think I've misunderstood this whole slaving option. Can anyone explain to me what this system actually does, and how a slaved HSI should respond under different circumstances?

[Guest]

BumpAnyone that could point me to a website that describes a slaved gyro in full?

[Guest bartels]

As far as I know, if you have a directional gyro you need either to compensate precession manually or automatically by slaving to the magnetic compass. At least this is how Miocrosoft implements it in it's usual "all or nothing" way. One additional detail is that there is this "ticking" approx. once a second in DG and HSI if you hav a close look in FS2002 (FS2000 didn't have it). I assume this is the "slaving" action that realigns the directional gyro to the magnetic compass. In reality (I assume this I know only 2 or 3 books, but no real world DG) you might be able to adjust a slaved gyro to speed up the realign procedure. E.g. the slaved gyro of a Cessna 210 (G-504A) or HSI (IG-832A) have additional adjustment knobs to align gyro with magnetic heading faster then the automatic alignment.As far as I know it is also normal to have one directional gyro slaved to magnetic heading and RMI and suchlike slaved to this DG.Unfortunately only a small amount of detail can rebuild with FS2002, but that's normal with MS.Arne Bartels

[Guest]

If it only takes precession into account, I guess I have managed to work this out after all. Except I don't slave to magnetic compass reading within FS2002 variables, as they would be very wrong during turns, only the builtin precession/drift. If these readings should be used, I can always change the code.Yes, I've seen an "index" knob on some HSI's, just wasn't sure what it actually controlled.I found the clue to get it to work was by setting the directional indicators in aircraft.cfg to pure electrical instead of electromag slaved (fully slaved all the time), which is default in most aircrafts I've seen, and enabling gyro drift within realism setting. If slave is active, correct according to (A:Gyro Drift Error,radians) = if slave is active, it behaves just like an electroslaved gyro. If slave is turned off, it drifts like any cheap DG. direction_indicator.0=2,0direction_indicator.1=1,0Setting the number 1 indicator here ensures that the right hand side vacuum driven DG will fail with a separate system of the left hand side electrically driven EHSI.I'm still not 100% sure my code is actually what goes on in the real world in regards to slaving, but at least it feels more "complex" than what MS put into it. Code available if you'd like to check the "workability" of it.One question though; what variable used within the code triggers the gauge to qualify as a "directional_indicator" within the list in aircraft.cfg?

[Guest bartels]

>Except I don't slave to >magnetic compass reading within FS2002 variables, as they >would be very wrong during turns, only the builtin >precession/drift. Sorry I was not precise enough here, the slaving system does NOT use the magnetic compass, but electromagnetic devices called fluxvalves usually mounted on the wingtips, which are able to measure the magnetic field vector in an electromagnetic fashion, so they aren't influenced mechanic disturbances like turns and accelerations. A variable that seems to show this might be PLANE HEADING DEGREES MAGNETIC.Arne BartelsP.S. have you tried HEADING INDICATOR 0 to HEADING INDICATOR 3? I don't know which purpose they have.

[Tom Allensworth 1,532]

I can pontificate about gyros all day long. :) No gyro, regardless of cost, is without "drift". That applies to spinning/ballistic wheels as well as newer Ring Laser and Fiber Optic systems. More expensive gyros just drift less. "Slaving" a gyro refers to connecting it to another position sensing source, such as another, more accurate gyro, GPS or other inertial system. Slaving is also used to provide "rapid align" and that is usually associated with an inertial system rather than a simple gyro. Inertial and gyro systems can drift for a variety of reasons, and are also impacted by pure physics, such as Schuler Drift, precession, gyro bias errors, velocity errors, common mode error build up, rapid temperature swings, etc. etc. Gyrocompasses are not typically slaved to simple magnetic compasses. What you seem to be indicating is that the gyro is "velocity damped"; that is, by turning on or off a "speed slaving switch". Velocity damping from an accurate speed reference keeps the gyro from building up velocity errors over time (decreasing accuracy over that period) by inputing relatively better velocity data from some other source. A two speed velocity input would indicate to me that the electronics allow for a slow and high speed velocity damping system forced by the filtering or computational systems used. It sounds like there are two range selections allowing for less complex computations. The net result however is that the gyro, with velocity damping, remains more stable over time than does one without. Flipping from "high to low" or vice versa, should not make much difference in the total scheme of things as long as there is some form of damping and will always be better than with none at all. Finally, with a damped gyro, your HSI is going to be much more stable than without that damping, especially with large changes in a/c velocity over time. Quantitatively, I couldn't begin to tell you how much that damping translates into actual performance stability for the HSI.Don't know how much any of that helps...

[Guest]

Thanks. I think this information covers all I could possibly need about slaving, drifting, errors, and whatnot. Since an off/low/high switch doesn't seem to make much of a difference, I think I'll just go with the off/on slaving instead.With slaving off, it will be subject to precession (gyro drift?) like a normal DG. Slaving turned on will make it behave like a normal FS-type HSI, but with possible errors in the system during some "crazy" manouvers until it catches up.Arne: I'll look into those Heading Indicator n stuff. Currently my righthand side simpler DG is also slaved :-A side question. When the VOR2 needle of an RMI looses its signal, shouldn't it go to a "locked" position (needle head at 3 o'clock) instead of being locked to a position on the card (which still follows aircraft direction)? Does the Barons RMI have a fault?

[Guest]

I have found the above helpful - Now I know why my gyro wouldn't drift. Now that I've set the aircraft.cfg parameter to =2,0 It drifts but I can't reset the drift.None of: (A:GYRO DRIFT ERROR,radians) 0.1 - (>K:GYRO_DRIFT_SET) (A:GYRO DRIFT ERROR,radians) 0.1 + (>K:GYRO_DRIFT_SET) 1 (>K:GYRO_DRIFT_DEC) or 1 (>K:GYRO_DRIFT_INC) have any effect on the gyro drift which continues on its merry way at its own pace:-hmmm can anyone help?Regards Trevor

[Guest]

0 (>K:HEADING_GYRO_SET) will reset the gyro, same as pressing D on the keyboard while flying.I haven't (yet) investigated if it is possible to slow down the drift (which seem far too speedy compared with those GA's I've been in), but a possible solution would be to add a fraction of (A:GYRO DRIFT ERROR,radians) to the mechanisms that drive the slaved cards, IF your custom (L:GyroSlaved,bool) is not on (and not gyro not failed and power available etc).An electrical gyro (type 2) should also be subject to drifting, but will continue to work during a vacuum failure (more common than a complete electrical failure). Also, be sure that drifting is enabled in the realism menu ;)What GYRO_DRIFT_SET is supposed to do I'm not sure, I haven't used it before I think. It could also be one of those events that Microsoft simply forgot to make work (such as certain audiopanel functions).

[Guest]

Karl,Thanx for your info. I'm sure you right that its just another M'soft failure. Like the fact that (A:Max G Force,GForce) and (A:Min G Force,GForce) always return zero making it necessary to define local variables such as:(A:G Force,GForce) s0 (L:G Force Max,GForce) max (>L:G Force Max,GForce) l0 (L:G Force Min,GForce) min (>L:G Force Min,GForce) I was trying to run a system using (A:Plane Heading Degrees Gyro,radians) as the heading reference and use calculated routines to reduce the drift value (or not) at a rate set according to the setting of (L:Gyro Slaving,enum) using values of 0 = off, 1 = normal, 2 = fast.I guess I will just have to set my own gyro heading reference (L:Gyro Heading,radians) and set up the routines to control it using the references available.Trevor.