Storage of GPS variables

[COBS]

I have a need to store some GPS Variables for subsequent independant use.

Is it possible to force them to L:Variables as shown below.

<!-- Airport -->
((@c:WaypointAirportName) (&gt;L:TooName))
((@c:WaypointAirportCity) (&gt;L:TooCity))
((@c:WaypointAirportIdent) (&gt;L:TooIdent))

<!-- Runway -->   
((@c:WaypointAirportRunwayDesignation) (&gt;L:TooDesignation))    
((@c:WaypointAirportRunwayLength, feet) (&gt;L:TooLength, feet))
((@c:WaypointAirportRunwayWidth, feet) (&gt;L:TooWidth, feet))
((@c:WaypointAirportRunwayElevation, feet) (&gt;L:TooElevation, feet))

((@c:WaypointAirportRunwayDirection, degrees) (&gt;L:TooDirection, degrees))
((@c:WaypointAirportRunwayLatitude, degrees) (&gt;L:TooLatitude, degrees))
((@c:WaypointAirportRunwayLongitude, degrees) (&gt;L:TooLongitude, degrees))

I already have all the above GPS Variable values showing up .
What I want is to capture and store the displayed values .

Cheers
Karol

 

[WarpD]

I don't think L:vars can store strings.

 

[COBS]

WarpD

Thanks for that.
I was afraid that might have been the case , my tests were not successful.

I just had a look at reply #15 at the following link,

http://www.fsdeveloper.com/forum/posts/652522/

specifically,
" if you really need to store the airport Ident that the user selects as the alternate airport, then I would suggest use of a simple shift register technique
rather than Robbie's string storage macros. There is a description of it in the GPS Guidebook."

That shift register would be fine for the 4 character airport ICAO , but the 'Airport Name' and 'Airport City' can run to very long character strings.
The Runway Designation runs to 5 characters.

Cheers
Karol

 

[EduHir]

Karol,
Tom A. wrote a module to save also strings!!

http://www.fsdeveloper.com/forum/resources/xmlvars-for-fsx-and-fs2004.122/

I have the some task as you. But i had no time to to rewrite my gauge.

btw, did you upload your panel ?

Edi

 

[rpmc]

I agree with Edi, XMLVars is a good way, the best way, to store those names. Alternatives, if one decides to not install XMLTools, are to use Robbie's macros or use a 5 place shift register to store airport Ident and then return airport name, runway info, etc from the GPS database as needed.

By the way, using ord, chr, scat and the shift register technique, a single L:Var can 'hold' up to 6 string characters. So, two L:Vars can accommodate a complete 12 character ICAO, but if you are only dealing with airport information, then you need only one L:Var to store the (up to) 5 character airport Ident and then use that to retrieve other information from the gps database as needed.

The smart step is for XML gauge programmers to install Tom Aguilo's XMLTools as Edi suggests. XMLTools now incorporates the LOGGER class in case one has the need to read and write strings or numbers to HDD. As a stand alone module, LOGGER is still available in the BlackBox website. The XMLVars class in XMLTools is powerful - can store strings and can be used to easily create arrays. Very handy.

Doug Dawson also provides a string storage module and that can be found on Doug's website.

Bob

[edit] There's a wiki in FSDeveloper on Storing Strings, but it's time for a little bit of updating. I'll get around to that this evening.

 

[COBS]

By the way, using ord, chr, scat and the shift register technique, a single L:Var can 'hold' up to 6 string characters.

Hi Bob

Only 6 characters ?
I need about 22 characters in a L:Var for the instrument that I'm doing.

Both Name and City need at least that capacity.
I want to keep the instrument an independant entity without resorting to the aforementioned tools.
I feel positive that I can get what I'm after .

Cheers
Karol

 

[rpmc]

Hey Karol,

How's it going? Your gps work is always great and I'm looking forward to the next thing out.

Yeah, a single L:Var can accommodate only 6 string characters utilizing the shift register technique.

As I see it, without using an external module, you have this option:

1) Use Robbie's string storage macros. It's made up of several macros, but its small compared to the size of a macro section in a typical gps gauge, and it works fine, FS9 and FSX, and I'm sure, P3D. Behind the scenes, Robbie's macros create 16 L:Vars for each string 'variable' you want to name and it uses bit shift operators to keep track of everything. Each L:Var that is created receives 4 ascii character codes, therefore, the max string length that can be stored is 16 x 4 = 64 characters, which is quite sufficient for your needs. It even has Backspace and Clear functionality.

2) Use a simple shift register technique to store only the 5 character airport Ident into one L:Var. Then, as needed in your gauge, concatenate A _ _ _ _ _ _ with that Ident to create your airport ICAO, and then query the database for whatever you need. Refer to page 36 of the fs9gps guidebook v1.1. As a matter of fact, this is what I routinely do ... and I already have XMLTools installed anyway! With this technique, you have to deal with the multiple gauge update cycle nature of the gps database query (asynchronous database query) each time you want the information, but that has never been a big hindrance for my stuff.

Bob

 

[COBS]

btw, did you upload your panel ?

Edi

Hi Edi

No I have not uploaded the panel yet , the last upload was about 2 years ago.
I think that I'm being a bit too ambitious with a couple of instruments at the moment.
Hopefully a new update upload soon.

Regards this thread , the following draft screenshot shows what I'm currently trying to do.
Those 4 pages are sub pages of the "NRST" button in the left hand MFD.
I currently have pages 1 , 2 , and 4 implemented and working.
Now I'm trying to get page 3 to work ! ? ?

I use a "Stand Off" arrangement that allows me to project things like the Radar display view to any location
that I desire , there are several ways that I utilise to set that projection , 5 in total at the moment ,
the latest being the Mark Position.

It's a little hard to describe the "Stand Off" function.
What I use it as , is as 'Common rail' or 'Data bus' that communicates through several instruments.

Below is a composite shot that shows 2 pages of the 'NRST' in the LH MFD.
It also shows how I use the "Stand Off" to project the 'Pave Tack' instrument view.
In the case shown the view is about 700 nm away from where I am located.
As you can see from the Red Dot it is not yet accurate .
The crosshairs should be exacly where the red dot is.

Cheers
Karol

 

[rpmc]

Hmmm, Karol,

Looking at your screenshots above, I wonder, is your task to display Airport Name and Airport City on pages 2 and 3 ... and that is why you want to store the name and city into L:Vars?

If it is as simple as that, then just use (c:fs9gps:WaypointAirportName) and (c:fs9gps:WaypointAirportCity) in the display Element of each page. You are going to need one database look-up (to get into the WaypointAirport group) anyway, and when you do that, Name and City will be populated. Those gps vars won't change until you do a new ICAO transfer. Bottom line, I'm not sure there is actually a need to store Name and City into separate L:Vars.

Make sense?

Bob

 

[COBS]

Hi bob

Thanks for the reply.
Still trying to digest the situation and possibilities.

As usual , I'm tackling things that I should stay away from.
I'm fine , I walk around with a glazed look in my eyes , and smoke coming out of my ears .... but that's just the usual for me !

There is a simpler way to get page 3 - APP - Runway approach working ,
however it might reduce the versatility of page 1-2-3 toggle useage.
I did have a thought that I might be able to do a work around by using a 'Geocalc' to trap what I'm after.

Why is it that these gauges are always so complicated and hard !

Cheers
Karol

 

[COBS]

Hmmm, Karol,

Looking at your screenshots above, I wonder, is your task to display Airport Name and Airport City on pages 2 and 3 ... and that is why you want to store the name and city into L:Vars?

If it is as simple as that, then just use (c:fs9gps:WaypointAirportName) and (c:fs9gps:WaypointAirportCity) in the display Element of each page. You are going to need one database look-up (to get into the WaypointAirport group) anyway, and when you do that, Name and City will be populated. Those gps vars won't change until you do a new ICAO transfer. Bottom line, I'm not sure there is actually a need to store Name and City into separate L:Vars.

Make sense?

Bob

Bob

Just saw your latest reply.
Really good (actually fantastic) .... will follow up on that line of doing things.
Thanks for that , occassionally I need to be hit on the head with a hammer to clear away the cobwebs.

Cheers
Karol

 

[EduHir]

Karol,
i wrote a similar Nav - Gauge 6, 7 years ago.

I use the method above shown by Bob!

But there is a small disadvantage!
If you activate the airport list again, it takes about 5 to 15 secs to get an actualized airportlist.

Edi

 

[COBS]

Edi

Please have a look at the above panel screenshot.
On the glare shield just above the Radar you will see a faint 'NAV' and 'MAP' they are call up Icons.
I have been a fan of your "NAV_INFO_MAIN from the time that you first released it.
From my point of view your instrument is one of the most significant available , it is absolutely magnificent.
I have never had a problem with it , I think it's function is quite quick , very cool .
My "NRST" is based on your logic .
I repeat the selected 'Bearing and Distance' in the top right hand of my HUD (see screenshot) ,
the Brg - Dist - Arrow is only visible if Page 2 is last left open , the reason being that it gives the pilot a reference to any airport
that he chooses , thus he is always aware of his location or can use it to return to that airport , it's very handy facility.

I think that I am getting very close to my storage idea for the page 3.

It's hard to explain what I am after , basically it's as follows ,
- at 'Page 2 - Runway Detail' select from the list the specific Runway that you wish to use for an ILS style Approach in 'Page 3 - ILS Approach Details' .
- then at 'Page 3 - ILS Approach Details' you can toggle either end of the selected Runway (ie; 147 or 327) , these are the precise runway centerline headings at each end ,
the rest of the Page 3 logic enables ILS precision approach in a similar manner to that used in the Mark Position page , that's why P3 and P4 look similar in the draft shot.

I want to be able to keep the current Page 3 selection stored and active even if I go back to Page 1 to select and interrogate a different airport.
That increases the versatility of the instrument.
The Page 3 selection remains locked (stored) at your initial runway selection until such time that you go back to Page 2 and make a new Runway selection.

I'm sorry if my description is confusing , I really want to give the pilot the maximum of both use and information.
Being able to toggle freely between the first 3 pages is in my opinion an important capability.

Cheers
Karol

PS: Just a little background.
The actual F-111 aircraft had "AILA" - ( Airborne Instrument Landing Approach) system , this is what I have been trying to implement for some time now ,
the above instrument is as close as I can get to the real deal.
The logic in the real F-111 was that in a war after it returned from it's mission it's airbase of departure would no longer exist due to battle damage.
The AILA system enabled it to generate a runway anywhere ie; road or other flat and firm surface and then conduct an ILS style landing.
The aircraft had high floatation landing gear that could tolerate a less than perfect landing surface , it also had high lift wings that enabled
it to land slow on short runways , it can land on most short GA runways , that's rather good for a M2.5 aircraft.

 

[rpmc]

Karol,
i wrote a similar Nav - Gauge 6, 7 years ago.

I use the method above shown by Bob!

But there is a small disadvantage!
If you activate the airport list again, it takes about 5 to 15 secs to get an actualized airportlist.

Edi

How big is your MaximumItems and MaximumDistance?

 

[EduHir]

Bob,
that's the code.

<!-- APT -->
(L:NavM_WPT_Select,number) 5 &lt;
if{
  (A:GPS POSITION LAT,Radians) (&gt;C:FS9GPS:NearestAirportCurrentLatitude,Radians)
  (A:GPS POSITION LON,Radians) (&gt;C:FS9GPS:NearestAirportCurrentLongitude,Radians)
  200 (&gt;C:FS9GPS:NearestAirportMaximumItems)
  250 (&gt;C:FS9GPS:NearestAirportMaximumDistance,NMiles)
  }

The point is if i switch from airport-list to airport-detail the airport-list will not be updatet.
if i switch back to airport-list i see for several time the old list .
The nrst airport may be hundred of miles away.
It seems, that GPS needs some time to update the airport-list.

Edi

 

[EduHir]

Karol,
i totally understand you.
I'm always thinking of installing Tom's XMLVars and updating my gauges. But time...

IMHO you have to install XMLVars and write the wanted airport in the vars and work with them. You could save the last 5 airports in the Vars.
And in the back you leave the airport list active.

So airport-list page -> select airport-> write airport data into the vars -> make airport-list unvisible-> change to airport-detail page and show airport details
Thats the way i would like to do it. Of course a lot of work.

I updated old my gauge a little bit. So i can select the runway end.
I also added an alternate airport. So i have to save some GPS-vars into L:vars. See above problems!!

Edi

PS Are you at FS9 or FSX?

 

[rpmc]

Bob,
that's the code.

<!-- APT -->
(L:NavM_WPT_Select,number) 5 &lt;
if{
  (A:GPS POSITION LAT,Radians) (&gt;C:FS9GPS:NearestAirportCurrentLatitude,Radians)
  (A:GPS POSITION LON,Radians) (&gt;C:FS9GPS:NearestAirportCurrentLongitude,Radians)
  200 (&gt;C:FS9GPS:NearestAirportMaximumItems)
  250 (&gt;C:FS9GPS:NearestAirportMaximumDistance,NMiles)
  }

The point is if i switch from airport-list to airport-detail the airport-list will not be updatet.
if i switch back to airport-list i see for several time the old list .
The nrst airport may be hundred of miles away.
It seems, that GPS needs some time to update the airport-list.

Edi

For sure. Its not the 250 miles, its the 200 Items. Why isnt 10 Items good enuf?

Take a look at pg 14 in the guidebook. That was for a simple NearestVOR search in a simple gauge. 200 Items is a big wait.

Bob

 

[EduHir]

Sorry, i was wrong. Looked into my coding again.

<!-- APT -->
(L:NavM_WPT_Select,number) 5 &lt;   <!-- Main Airport List -->
if{
  (A:GPS POSITION LAT,Radians) (&gt;C:FS9GPS:NearestAirportCurrentLatitude,Radians)
  (A:GPS POSITION LON,Radians) (&gt;C:FS9GPS:NearestAirportCurrentLongitude,Radians)
  200 (&gt;C:FS9GPS:NearestAirportMaximumItems)
  250 (&gt;C:FS9GPS:NearestAirportMaximumDistance,NMiles)
  }

(L:NavM_WPT_Select,number) 9 ==   <!-- Airport List nearby the select airport -->
if{
  (C:FS9GPS:WaypointAirportLatitude) (&gt;C:FS9GPS:NearestAirportCurrentLatitude)
  (C:FS9GPS:WaypointAirportLongitude) (&gt;C:FS9GPS:NearestAirportCurrentLongitude)
  200 (&gt;C:FS9GPS:NearestAirportMaximumItems)
  300 (&gt;C:FS9GPS:NearestAirportMaximumDistance,NMiles)
  }

I'm switching between 2 different listings. And switching pack to main airport list takes the time to get a new list from airplane position.
Using only the Main Airport list it takes about 3 secs, if i switch pack from airport detailed to to Main airport list.

Why isnt 10 Items good enuf?

I'm flying in 37000 feet. Airports with runwaylength less than 3000ft -it's changeable - will not be shown.
But maybe 200 is to much!

But nevertheless i think using Tom's XLMVars would make sense!

Edi

 

[COBS]

Edi

1.

PS Are you at FS9 or FSX?

I had both loaded before Christmas , had a hard drive short , new hard drive only has FSX.
I have to use FSX as it supports both AI aircraft and Custom draw elevations , these are features that I use in my Radar.
I write instruments in both FS9 and FSX schema , most are written in FS9 style , but my Radar and Pave Tack are in FSX style.

2.

IMHO you have to install XMLVars and write the wanted airport in the vars and work with them. You could save the last 5 airports in the Vars.
And in the back you leave the airport list active.

In the above greyscale draft shot at Page 3 there are 4 empty buttons on the left side , my hope is that I can save and store 4 different ICAO/Runways ,
one at each button.
And as you said '...leave the airport list active.'
Basically after Runway heading selection make P3 independant of P1 and P2 , then you could go back to P1 and review other airports without
disturbing what is showing in P3.

3.

I updated old my gauge a little bit. So i can select the runway end.
I also added an alternate airport. So i have to save some GPS-vars into L:vars. See above problems!!

Your updates sound very good .

At the moment in Page 3 I have,
=> STEP 1
next to "RWY button toggle

<String>%((@c:WaypointAirportRunwayDirection, degrees) (A:GPS MAGVAR, degrees) - d360)%!03d!% - %((@c:WaypointAirportRunwayDirection, degrees) (A:GPS MAGVAR, degrees) - 180 - d360)%!03d!%</String>

That gives you both ends of the Runway (eg; 147 - 327).
Initially use the first heading.

=> STEP 2
then in a 'Geocalc' based on

((@c:WaypointAirportRunwayLatitude, degrees))
((@c:WaypointAirportRunwayLongitude, degrees))

thenapply ,
reverse of first heading

((@c:WaypointAirportRunwayDirection, degrees) (A:GPS MAGVAR, degrees) - 180 - d360)

and
90% of half the runway length

((@c:WaypointAirportRunwayLength, feet))

the Geocalc then gives you a Lat/Long that 5% of the runway length down your initial heading end of the runway.

=> STEP 3
You now have all the data to utilise and conduct the usual 2 Geocalcs that are done in the Mark Position instrument,
ie;
"Geocalc 1" near end of runway or first heading.
- first heading - this is the equivalent of 'Mark Heading' in the 'Mark Position' instrument.
- runway elevation

((@c:WaypointAirportRunwayElevation, feet))

- Lat/ Long at 5% of runway length - see earlier Geocalc.

=> STEP 4
A toggle at the "RWY" button initiates
"Geocalc 2" based on
Runway length of 90% of

((@c:WaypointAirportRunwayLength, feet))

this results in a Lat/Long position that is 5% from the end of the far end of you runway - it is at your second heading.

With the above by toggling at the "RWY" button the instrument sets all pertinent data for whichever Runway heading that
you have set as active to provide both information or precise ILS guidance to the selected runway end.

That's the easy part , the hard part is storing the GPS string Variables.

Cheers
Karol

 

[EduHir]

Karol,
perfect!
Nearly same solution!
I'm very curious to your panel. But at first i have to install FSX.
keep us informed, please!
Did you your make the gauge BMP by yoursel? I like it!

Edi