Magnetic Ground Track Formula

[Engjell Berisha]

Hello Folks,

I have been trying to create a formula to get the aircrafts magnetic ground track like the variable "GPS GROUND MAGNETIC TRACK." While this variable is great it creates a very annoying and unattractive stutter as it updates (it does not updates smoothly). I would like to create a variable that provides the same information but updates much more smoothly. I figure it's as simple as figuring out the WCA and adding it to the GYRO HDG but this isn't working out well. I have searched google, avsim panel design forums, and here but nothing has come up. Anyone whiling to share or teach?

This is what I've been using (got the formula from a E6B emulator):

(A:PLANE HEADING DEGREES GYRO,radians) (A:AMBIENT WIND VELOCITY,knots) (A:PLANE HEADING DEGREES GYRO,radians) (A:AMBIENT WIND DIRECTION,radians) - sin * atg + rddg

 

[rpmc]

Hello Engjell,

It's stuttering because of the 1 second update rate of (A:GPS GROUND MAGNETIC TRACK, degrees).

One approach to use would be to compute the true ground course using changes in (A: PLANE LATITUDE, degrees) and (A: PLANE LONGITUDE, degrees) from one Update cycle to the next using (C:fs9gps:GeoCalcBearing, degrees) and then subtract magnetic variation (A:MAGVAR, degrees) to get the magnetic ground track.

Bob

with no space between : and P in those A:Var names. Arno ... we need some editing abilities here ...

 

[rpmc]

Like this, in an <Update> section:

(A:PLANE LATITUDE, degrees) (>C:fs9gps:GeoCalcLatitude2, degrees)
(A:PLANE LONGITUDE, degrees) (>C:fs9gps:GeoCalcLongitude2, degrees)
(L:PlaneLatitudePreviousCycle, degrees) (>C:fs9gps:GeoCalcLatitude1, degrees)
(L:PlaneLongitudePreviousCycle, degrees) (>C:fs9gps:GeoCalcLongitude1, degrees)
(C:fs9gps:GeoCalcBearing, degrees) (A:MAGVAR, degrees) - dnor (>L:GroundTrackMagnetic, degrees)
(A:PLANE LATITUDE, degrees) (>L:PlaneLatitudePreviousCycle, degrees)
(A:PLANE LONGITUDE, degrees) (>L:PlaneLongitudePreviousCycle, degrees)

where (L:GroundTrackMagnetic, degrees) is what you are looking for.

It's a good approach because it's a gps solution that avoids wind correction altogether and gets the true ground track from the plane's lat and lon.

An alternative is to use (A:VELOCITY WORLD X, knots) and (A:VELOCITY WORLD Z, knots) solving for true ground track degrees using Law of Cosines, then subtract (A:MAGVAR, degrees) to get magnetic. This one is also a gps solution that avoids the wind correction. The XML is simple:
(A:VELOCITY WORLD X, knots) (A:VELOCITY WORLD Z, knots) / atg rddg (A:MAGVAR, degrees) - dnor (>L:GroundTrackMagnetic, degrees)
Ooops, I need to debug that one ... Velocity X and Z sign changes not adequately accounted for...

For an E6B-type calculation involving Wind Correction Angle, you might look at Aviation Formulary V1.46 by Ed Williams. There, you will find:

WCA=atan2(WS*sin(HD-WD),TAS-WS*cos(HD-WD))
CRS=MOD(HD+WCA,2*pi) The MOD part in XML should be something like

HD WCA + rnor

WCA = Wind Correction Angle, radians
WS = (A:AMBIENT WIND VELOCITY, knots)
HD = (A: PLANE HEADING DEGREES TRUE, radians)
WD = (A:AMBIENT WIND DIRECTION, radians)
TAS = (A:AIRSPEED TRUE, knots)
atan2 = atg2 in XML
CRS = Course = Ground Track True, radians
MOD = XML dnor (or rnor) operator

So, Ground Track Magnetic should equal CRS - MAGVAR

This is the XML:

(A:PLANE HEADING DEGREES TRUE, radians) (A:AMBIENT WIND DIRECTION, radians) - sin (A:AMBIENT WIND VELOCITY, knots) * (>L:Atan2Argument_1, number)
(A:AIRSPEED TRUE, knots) (A:PLANE HEADING DEGREES TRUE, radians) (A:AMBIENT WIND DIRECTION, radians) - cos (A:AMBIENT WIND VELOCITY, knots) * - (>L:Atan2Argument_2, number)
(L:Atan2Argument_1, number) (L:Atan2Argument_2, number) atg2 (>L:WindCorrectionAngle, radians)
(A:PLANE HEADING DEGREES TRUE, radians) (L:WindCorrectionAngle, radians) + (A:MAGVAR, radians) - rnor rddg (>L:GroundTrackMagnetic, degrees)

Cheers,

Bob

 

[rpmc]

my previous response significantly edited .. additions and errors

 

[Engjell Berisha]

Bob,

I am greatly indebted to you!

I had looked through the aviation formulary before posting here. I don't know how I missed those calculations. Must have been really late.

Anyhow, I first tried your idea to use the velocity x and z. While this worked well and was stable I could not get the numbers to be normal angels at the right time. I was convinced it was a lack of ability on my part and have been trying to fix that since your post. Thank you for letting me know I was chasing my tail.

As for the method using the geocalc I had tried this before and even gave your code a run. It works well but the problem is that I need the update to run at a frequency of at least 8. Updating the code that fast often results in a jumping back and forth from 350 to the actual value of the mag gnd trk.

Lastly the approach I was trying to do which you very kindly posted right before I got my own code working was the WCA method. This seems to be working perfectly. I think you very much for your help.

Here is my final code simply with my own variables:

(A:PLANE HEADING DEGREES TRUE,radians) (A:AMBIENT WIND DIRECTION,radians) - sin (A:AMBIENT WIND VELOCITY,knots) * (>L:FMC-IRS-GND-TRK-MAG-ATG1,number)

(A:AIRSPEED TRUE,knots) (A:PLANE HEADING DEGREES TRUE,radians) (A:AMBIENT WIND DIRECTION,radians) - cos
(A:AMBIENT WIND VELOCITY,knots) * - (>L:FMC-IRS-GND-TRK-MAG-ATG2,number)
(L:FMC-IRS-GND-TRK-MAG-ATG1,number) (L:FMC-IRS-GND-TRK-MAG-ATG2,number) atg2 (>L:FMC-IRS-WCA,radians)
(A:PLANE HEADING DEGREES TRUE,radians) (L:FMC-IRS-WCA,radians) + (A:MAGVAR,radians) - rnor rddg (>L:FMC-IRS-GND-TRK-MAG,degrees)

Thank you again! Without your GPS guide books the momentous task of making a very functional FMC would have fallen VERY VERY short of where it is today.

P.S. I had sent you an email a few months ago as I had some questions about the gps module that I was hoping you could help me with. Did you ever receive it? I may have sent it to your son by accident. I got the address of the blackbox site I believe.

 

[rpmc]

Anyhow, I first tried your idea to use the velocity x and z. While this worked well and was stable I could not get the numbers to be normal angels at the right time. I was convinced it was a lack of ability on my part and have been trying to fix that since your post. Thank you for letting me know I was chasing my tail.

I know what's going on there and it's a simple fix but will increase the number of lines of code. I'll get around to that later, maybe.

As for the method using the geocalc I had tried this before and even gave your code a run. It works well but the problem is that I need the update to run at a frequency of at least 8. Updating the code that fast often results in a jumping back and forth from 350 to the actual value of the mag gnd trk.

I cannot replicate your issue using the GeoCalc method. The chart below is a LOGGER recording of A:GPS GROUND MAGNETIC TRACK plus the three other methods: GeoCalc, VELOCITY_WORLD, and WCA. The X axis is time and this is a recording as my aircraft turned through 360 degrees. Update frequency was 18 and LOGGER recording was 18 records per second using Blackbox3.

First, note the stair-step appearance of the GPS GROUND MAGNETIC TRACK curve. That's the stuttering you were describing and it's due to the 1 second update of that variable within the gps module. The update affects that gps variable and many others, but the GeoCalc group is not affected - its 'instantaneous'.

The other curves all seem 'smooth' (were updated each Update cycle at 18 and exhibit no stair-stepping) and I flew it in a strong cross-wind, so the WCA calcs appear to work just fine. The GeoCalc and Velocity_World curves are nearly superimposed, and the WCA and GPS GROUND MAGNETIC TRACK curves are nearly superimposed (allowing for the stair-step of the A:Var). There's a slight gap between the two pairs when the magnetic track direction flips at 360 degrees, but I would consider them all to be accurate and acceptable. I cannot produce the back and forth behavior that you see, so I don't know whats happening in your gauge.

P.S. I had sent you an email a few months ago as I had some questions about the gps module that I was hoping you could help me with. Did you ever receive it? I may have sent it to your son by accident. I got the address of the blackbox site I believe.

Hmmm, I will check this out. Almost nobody ever sent emails to that address after I published the Guidebooks, so I stopped looking...

Bob

 

[rpmc]

I edited the response above, again, because I omitted dnor from my GeoCalc code at first. Now its there and all seems well behaved.

 

[rpmc]

Engjell,

A couple of additional notes:

Infrequently, I do get 'spikes' in my GeoCalc result when GeoCalcBearing goes to 360 degres true for one Update cycle. This does not occur because PLANE LATITUDE inexplicably goes to zero for one update cycle. Rather, it seems that the fs9gps function itself throws out a 360 true bearing (as if Latitude1 was zero). I don't know why. And I did not try it at Update frequencies other than 18.

The wind direction sometimes changes a little bit, but abruptly, and that causes an aberration in the WCA. See the chart below starting at 70 seconds.

So, even the WCA method may not always be stable. Actually, I prefer GEOCALC over WCA because I have not yet been able to reproduce the back and forth you mentioned.

I have not figured out the fix for the VELOCITY WORLD method yet but I am close. It's a challenge I guess.

Bob

 

[Engjell Berisha]

Bob,

I must say you have an act for making charts.

As for the WCA method I had to add a conditional statement to correct it as it occasionally will give the opposite (180) track.

Here is the code below:

(A:PLANE HEADING DEGREES TRUE,radians) (A:AMBIENT WIND DIRECTION,radians) - sin (A:AMBIENT WIND VELOCITY,knots) * (>L:FMC-IRS-GND-TRK-MAG-ATG1,number)

(A:AIRSPEED TRUE,knots) (A:PLANE HEADING DEGREES TRUE,radians) (A:AMBIENT WIND DIRECTION,radians) - cos (A:AMBIENT WIND VELOCITY,knots) * - (>L:FMC-IRS-GND-TRK-MAG-ATG2,number)
(L:FMC-IRS-GND-TRK-MAG-ATG1,number) (L:FMC-IRS-GND-TRK-MAG-ATG2,number) atg2 (>L:FMC-IRS-WCA,radians)
(A:PLANE HEADING DEGREES TRUE,radians) (L:FMC-IRS-WCA,radians) + (A:MAGVAR,radians) - rnor rddg sp1
(A:GPS GROUND MAGNETIC TRACK,degrees) l1 - abs 5 >= if{ l1 180 + (>L:FMC-IRS-GND-TRK-MAG,degrees) }
els{ l1 (>L:FMC-IRS-GND-TRK-MAG,degrees) }

I'm still tweaking here and there. But I did a short flight last night and the results are promising.

As for the geocalc update method I believe it might have something to do with my system itself. I don't have the best computer to run flight simulator on right now and this results in a modest FPS range from 20-40. I'm not sure if this has a direct affect on it but I suspect it might. On the other hand I have been trying the code at an update frequency of 10. I will give 18 a try and report back. The geocalc method was the most accurate but for whatever reason it would stutter to a value of 350.23 exactly very often. Sometimes the cause of my problems is the extensive code I have. Between the roughly ten XML gauges in the panel there is numerous use of the fs9gps variables including the geocalc. Not sure if it's just one of these things or a myriad of them. But right now the above code works with the package.

UPDATE: Abrupt wind changes do not seem to be causing the issue. I tested the code in no wind conditions and I still get the same error. I also don't believe the issue to be with update frequency as I have tried a bunch of different frequencies and I still get the same result. The only thing frequency changes is the smoothness of the updates - as expected. Also tested agsint the use of other gs9gps variables and the multiple uses of geocalc I have in my panel. But after removing that code I still got the same result. This leaves the computer. I will test on another computer and see how that works. I have noted that when pausing the sim I got the exact same value : 350.23.

Attached is a photo of what the PFD and ND. As you can guess this code is primarily for the ND. In the photo the compass rose is not set to track but rather mag gyro heading. I have updated that since.

 

[rpmc]

Bob, I must say you have an act for making charts.

The charts are trivial once the desired variables have been written to file in .csv format, and that's very simple to do with Blackbox3 ... you can select .csv file output as an option. When I need to see what variables are doing and how they interact from one update cycle to the next, especially when trying to understand something that is transient, then BB3 is the way to go.

As for the WCA method I had to add a conditional statement to correct it as it occasionally will give the opposite (180) track.

Very strange and I wonder why that would be? The WCA calculation uses only Heading, True Airspeed, and Wind direction and speed. If it was me, I would record the following using BB3:

(A: PLANE HEADING DEGREES TRUE, radians)
(A:AIRSPEED TRUE, knots)
(A:AMBIENT WIND DIRECTION, radians)
(A:AMBIENT WIND VELOCITY, knots)
(A:GPS GROUND MAGNETIC TRACK,degrees)
(L:FMC-IRS-GND-TRK-MAG,degrees) your original before you introduced the conditional correction

Then, whenever (L:FMC-IRS-GND-TRK-MAG,degrees) gives you the opposite track, take a look at the Heading, Wind, and Airspeed values. What are they doing?

Even though your conditional statement correction appears to patch things, it should not be necessary, right? A puzzle.

The WCA aberration I pointed out in the earlier post looks like it's due to a bug in FSX's weather generator, IMHO. The composite chart below shows what was going on. During the flight, the ambient wind was changing direction, starting out coming from the Northeast, then shifting to come out of the Northwest. When it came out of the North, however, it sure looks like FS ran into a MOD or dnor-type problem. As the wind shifted to come from the North, it turns out that for 4.22 seconds, the wind came out of the Southwest, and that seems "buggy" to me.

Below is an enlargement:

My takeaway is that the WCA approach may have more instability than the GeoCalc approach. The other takeaway is that I'm reasonably sure I may be the only person in the world that enjoys getting into the bowels of Flight Sim navigation details like this.

As for the geocalc update method I believe it might have something to do with my system itself. I don't have the best computer to run flight simulator on right now and this results in a modest FPS range from 20-40. I'm not sure if this has a direct affect on it but I suspect it might. On the other hand I have been trying the code at an update frequency of 10. I will give 18 a try and report back. The geocalc method was the most accurate but for whatever reason it would stutter to a value of 350.23 exactly very often.

It's hard to know, isn't it? Multiple gauges competing for gps.dll resources? That's beyond my knowledge base and maybe someone else could add a comment.

As for the 350.23 degree value - check your MAGVAR, and check what that value would be in degrees TRUE. I'm betting it's 360. That's kind of a default 'error' value when something gets screwed up in GeoCalc, like Latitude1 = 0.

Concerning the comments on Update frequency, I'm not sure that's really what is behind this. I would like to see an in-depth Wiki on Update frequency and what different Update frequency selections really do, if anything, to something like the gps.dll module. With my limited understanding, I believe the Flight Sim gauge cycle is 55ms, which is 18 Hz, and AFAIK, the gauge code begins anew every 55ms no matter your selection of Update frequency. If you select a frequency of 10, for example, my understanding is that the 55ms cycle is not changed - it does not slow it down, but something else is going on. The code in the <Update> section is not evaluated every gauge cycle, or something like that. Would that affect the gps.dll? Maybe. Would it alleviate problems caused by multiple gauges using the gps.dll? That, I really don't know.

Anyway, this may be a topic for guys like Tom Aguilo, Ed Wilson, or Doug Dawson, et. al., to weigh in on.

Bob

 

[rpmc]

Engjell,

As promised, here's the correct way to get magnetic ground track using A:VELOCITY WORLD variables:

(A:VELOCITY WORLD X, knots) (A:VELOCITY WORLD Z, knots) / atg (A:MAGVAR, radians) - rddg
(A:VELOCITY WORLD Z, knots) 0 < if{ 180 + } dnor (>L:GroundTrackMagnetic, degrees)

The VELOCITY WORLD solution is simple and seems not to have the issues plaguing the other three approaches. Here's a summary plot showing how the 4 methods compare:

They superimpose nicely, but VELOCITY WORLD is the best. An enlargement:

You might give the VELOCITY WORLD XML above a try and see how it works for you.

Bob

 

[taguilo]

Concerning the comments on Update frequency, I'm not sure that's really what is behind this. I would like to see an in-depth Wiki on Update frequency and what different Update frequency selections really do, if anything, to something like the gps.dll module. With my limited understanding, I believe the Flight Sim gauge cycle is 55ms, which is 18 Hz, and AFAIK, the gauge code begins anew every 55ms no matter your selection of Update frequency. If you select a frequency of 10, for example, my understanding is that the 55ms cycle is not changed - it does not slow it down, but something else is going on. The code in the <Update> section is not evaluated every gauge cycle, or something like that. Would that affect the gps.dll? Maybe. Would it alleviate problems caused by multiple gauges using the gps.dll? That, I really don't know.

Anyway, this may be a topic for guys like Tom Aguilo, Ed Wilson, or Doug Dawson, et. al., to weigh in on.

Bob

Hi Bob,
Well, you called so I stepped in

fs9gps functions depend on gps.dll, which has its own (global) actualization's frequency, that might or might not coincide with an <Update> frequency of a specific gauge.

In the specific case of GeocalcBearing, a 0 value that is returned intermittently means that the position of the aircraft hasn't change significatively since the previous cycle, then being actual position and previous position exactly the same, delta bearing evaluation will give 0, logically. The fixed value of 350.23 obtained by Engjell is because of the MagVar addition/substraction; as long as Magvar remains the same that value will be the same as well.

You could overcome this situation by doing a geocalc only when

(L:planeLatitudePreviousCycle, radians) (A:pLANE LATITUDE, radians) - abs 0 >
(L:planeLongitudePreviousCycle, radians) (A:pLANE LONGITUDE, radians) - abs 0 > and

Tom

 

[EduHir]

Bob,
thanks for this interesting work!!
And also the possibilities of Blackbox3!!

Edi

 

[rpmc]

In the specific case of GeocalcBearing, a 0 value that is returned intermittently means that the position of the aircraft hasn't change significatively since the previous cycle

Thanks Tom, this might explain why Engjell could alleviate his 'back and forth' GeoCalcBearing method problems by decreasing Update Frequency to 8.

Bob,
thanks for this interesting work!!
And also the possibilities of Blackbox3!!

You're welcome Edi. If I keep showing plots, I might even get Tom Aguilo to start using LOGGER output from BlackBox3!

Bob

 

[taguilo]

You're welcome Edi. If I keep showing plots, I might even get Tom Aguilo to start using LOGGER output from BlackBox3!

Hmmm...know what? Growing older makes me more lazy every day

Tom

 

[rpmc]

Something simple took me days to figure out. Now who's getting old???

To make a long story short .... here's a recap of the 4 methods to calculate Ground Track (degrees magnetic) that have been discussed in this thread:

1. A:GPS GROUND MAGNETIC TRACK METHOD:
    (A:GPS GROUND MAGNETIC TRACK, degrees)

2. GEOCALC METHOD:
    (L:PlaneLatitudePreviousCycle, degrees) (A:PLANE LATITUDE, degrees) - abs 0 >
    (L:PlaneLongitudePreviousCycle, degrees) (A:PLANE LONGITUDE, degrees) - abs 0 > and
        if{
            (A:PLANE LATITUDE, degrees) (>C:fs9gps:GeoCalcLatitude2, degrees)
            (A:PLANE LONGITUDE, degrees) (>C:fs9gps:GeoCalcLongitude2, degrees)
            (L:PlaneLatitudePreviousCycle, degrees) (>C:fs9gps:GeoCalcLatitude1, degrees)
            (L:PlaneLongitudePreviousCycle, degrees) (>C:fs9gps:GeoCalcLongitude1, degrees)  
            (C:fs9gps:GeoCalcBearing, degrees) (A:MAGVAR, degrees) - dnor (>L:GroundTrackMagnetic, degrees)
        }
    (A:PLANE LATITUDE, degrees) (>L:PlaneLatitudePreviousCycle, degrees)
    (A:PLANE LONGITUDE, degrees) (>L:PlaneLongitudePreviousCycle, degrees)

3. A:VELOCITY WORLD METHOD:
    (A:VELOCITY WORLD X, knots) (A:VELOCITY WORLD Z, knots) / atg (A:MAGVAR, radians) - rddg
    (A:VELOCITY WORLD Z, knots) 0 < if{ 180 + } dnor (>L:GroundTrackMagnetic, degrees)

4. WIND CORRECTION ANGLE METHOD:
    (A:PLANE HEADING DEGREES TRUE, radians) (A:AMBIENT WIND DIRECTION, radians) - sin (A:AMBIENT WIND VELOCITY, knots) * (>L:Atan2Argument_1, number)
    (A:AIRSPEED TRUE, knots) (A:PLANE HEADING DEGREES TRUE, radians) (A:AMBIENT WIND DIRECTION, radians) - cos (A:AMBIENT WIND VELOCITY, knots) * - (>L:Atan2Argument_2, number)
    (L:Atan2Argument_1, number) (L:Atan2Argument_2, number) atg2 (>L:WindCorrectionAngle, radians)
    (A:PLANE HEADING DEGREES TRUE, radians) (L:WindCorrectionAngle, radians) + (A:MAGVAR, radians) - rnor rddg (>L:GroundTrackMagnetic, degrees)

Bob

 

[Engjell Berisha]

Bob,

After thoroughly test all three methods on several flights of ~1000nm each I have concluded that the velocity method is the preferred method. I have yet to experience any anomalies with velocity method as opposed to the other two methods which would occasionally give erroneous figures.

I have had to add just a bit of code to stabilize it on the ground especially if the aircraft is pushed back but it is certainly very stable if you ask me.

(A:GROUND VELOCITY,knots) 5 <=
if{ (A:PLANE HEADING DEGREES GYRO,degrees) (>L:FMC-IRS-GND-TRK-MAG,degrees) }
els{ (A:VELOCITY WORLD X,knots) (A:VELOCITY WORLD Z,knots) / atg (A:MAGVAR,radians) - rddg (A:VELOCITY WORLD Z,knots) 0 < if{ 180 + } dnor (>L:FMC-IRS-GND-TRK-MAG,degrees) }

Thank you Bob and everyone who contributed to this thread. Another problem solved.

P.S. - While I needed this for an IRS and ND I was building it has helped greatly in stabilizing/smoothing out the default GPS, and any other gauge that uses a moving map display.

 

[Gypsy Baron]

I use the geocalc method to get the ground track on other aircraft in a multiplayer session. The only issue I have seen with it is occasionally the first and second readings get out of sync. This usually fixes itself within a couple of seconds, but as insurance I have two buttons on my radar gauge to force the first and second readings so hitting those in sequence yields the correct 'answer'.

Paul