New Optional Comm Frequency f4.csv Scenery Extraction for Airports

[ronzie 21]

First let me say this has been an independent project outside of the development staff of jdtllc which will not take any responsibility of its use. It is up to the user who takes responsibility in optionally using it.

 

Pete Dowson (FSUIPC and makerwys developer) has generously updated makerwys.exe, starting with version 4.611 to produce an f4.csv file that extracts frequencies from installed scenery in the same manner as other airport data. This is in response to requests for allowing RC4 to take into account changes made by new add-ons or user modified afd data (afcad type files).

 

It is located in the usual location for updating makerwys:

http://forum.simflig...ional-programs/

 

Here is how to safely use it.

 

From within RC run the scenery database update in the usual fashion (including first running makerwys.exe in your FS folder if running RC on a network client to an FS host over WideFS). A few seconds after the last RC dialog comes up about a4.csv being completed close RC.

 

For safety do two things for the first time you use this procedure:

 

In your main RC4 folder(s) copy and paste rcv3.dat file and rename the copy to Safety rcv3.dat. Occasionally on data errors this file can get corrupted and RC will not start yielding an error 62. This provides a safety copy to restore it.

 

Now go into the \data folder under your RCv4 and\or RCv4X folders. Rename the f4.csv file staticf4.csv Do not start RC yet after doing this. It will crash without an f4.csv file.

 

This completes the preparation for the first time use and now the following procedure can be used each time after completion of the scenery update process.

 

If you have a dual RC installation, one for FS9 and one for FSX repeat this operation for each version.

 

Using Windows Explorer go into your FS9 or FGSX folder. Find f4.csv (not f5.csv) highlight it. Use Explorer to open a window of the \data folder under your RCV4 or RCV4X main folders.

 

Drag the f4.csv file from each fs9 or FSX folder into the RCv4 or RCv4X \data folder for the FS version you are updating from. If asked to overwrite the file OK it.

 

Note:

Remember that there will be a an RC folder with a data folder under it for each version of FS you are working with. Be sure you have entered the correct FS path for each FS version when updating the scenery in the RC version for that specific FS version.

 

Now run RC and load a flight plan that has your new\modified airport as the departure field. Open the controller tab and check out the frequencies. They should check out with your scenery additions and modifications. Remember after modifying, adding, or deleting scenery to close and restart FS so it reindexes its scenery.cfg file. The in RC rebuild its scenery database. Then copy the new f4.csv file in your FS folder to the proper rc\data folder.

 

I have shortcuts to my FS9 folder and to my RCv4-data folder for easy access to the f4.csv file.

 

I have tested this with my FRF KMSP scenery, the installed 9 Dragons freeware Kai-Tak retro Hong Kong airport, and two stock small non-controlled airports, and all seems OK. On large airports the RC controller tab may not show a Unicom entry. It will show a Multicom entry as Unicom. This is not used in RC version 4 anyway.

 

For those Windows savvy users you may have noted a .bat file in the RC folder called makerwys.bat. Unfortunately if you modify it to add a line to copy f4.csv it may not be retained on the next scenery rebuild. This has to do with passing the FS path you enter each time you run the scenery rebuild. This manual operation is really just a simple drag and drop between two folders that you can create shortcuts to.

 

Thanks again to Pete Dowson for making this available.

 

There should be no risk to RC doing this but as instructed you can restore the original f4.csv static version if needed and if an RC crash occurs you have a backup rcv3.dat file required to start RC. This is an optional voluntary procedure to perform at your own risk.

 

If there are any problems post details in this thread for now.

[ronzie 21]

Hold everything. Don't use the f4,csv from your fs9 folder yet. A very obscure bug has surfaced. (What's new.)

 

Just continue to use the original f4.csv file from you installation.

 

We'll figure it out.

[Pete Dowson 558]

Hold everything. Don't use the f4,csv from your fs9 folder yet. A very obscure bug has surfaced. (What's new.)

 

What is it, Ronzie? I've no information on it here.

 

Mind you I don't have FS9 installed with any add-on scenery, and not FS9 at all for RC. Is it an FS9-specific problem?

 

Pete

[ronzie 21]

It could be the manner of testing. I was not running RC for the GUI tests with FS running and garbage collection may have been incomplete.

 

Will try again today.

 

To be clear to others it is fine to run makerys as normal.

[nrcapes 0]

It could be the manner of testing. I was not running RC for the GUI tests with FS running and garbage collection may have been incomplete.

 

Will try again today.

 

To be clear to others it is fine to run makerys as normal.

Something strange is happening with f4.csv for FSX. I changed one airport (KEAU) with Airport Design Editor and compiled that airport to \addonscenery\scenery. Started FSX, which saw the scenery change and updated its scenery database. Ran makerwys 4.611 on my FSX system. Ran RC4 on the other system and hit the Rebuild Scenery DB button. Since it was a WideFS system, I gave RC4 the shortcut to the FSX folder on the FSX system. RC finished the rebuild. I copied f4.csv from the FSX folder to the RC4X\data folder on the RC system. Ran RC with a flight plan with the modified airport as departure and KSTP as destination. The changes were there for the changed airport but KSTP's frequencies were also updated to those of the changed airport. Fortunately, I made multiple copies of the f4.csv file that used to be OK,so I could easily fall back.

 

What would you like me to provide to help with diagnosis?

[ronzie 21]

Here is where the problem most easily shows up:

 

Now let me stress that you make a safe copy of rcv3.dat I've had that wiped out on an occasional problem.

 

Set up a flight plan from KROS to let us say KGRB with a GA aircraft. (You will not have to fly it, just park it at the departure airport.) Actually the problem shows without actually starting FS. KROS is an uncontrolled airport. As you bring up the controller tab it correctly shows a Unicom (actually a Multicom frequency which is proper for pilot coordination at non towered airports). KGRB will show the usual controlled airport frequencies. Everything looks wonderful. Shut down RC.

 

Now set up a plan let us say from KMSP to KMDW. Run RC and load the plan. In the controller tab now for KMSP I see the frequency setup for KROS for KMSP. (If you fly it this way it will treat KMSP as not controlled.)

 

Sometimes it will bring up KMSP. Sometimes being on a DP with altitude restrictions makes a difference. The same thing can happen on the destination side.

 

Now reenable the original f4.csv file, run RC, load these same plans, and they work normally.

 

I changed my tests to stock airports only so it is not an ADE, AFX, or AFCAD problem.

 

Even between RC sessions the origin or destination previous airport data is being retained but only using the new f4.csv file.

 

I did try this with an FS loaded parked flight and exited RC with the Quit button after I started it but the problems were the same.

 

I checked the contents in the flight plan folder of the per flight created .rc4 files that maintain some of the airport data for temporary use and even deleted them before another run but that did not help the problem.

 

My next test wil be to run an RC log with the original f4.csv and run a log with RC and on the next run grab a log up to loading the controller tab where the problem shows.

 

Now if the frequencies do appear careful checking will show that's from a previous airport in some cases such as where both are controlled.

 

I checked both f4 files for the airport data line and other than the airport name, the data matches. You will get trailing zeroes in the 4611 f4 file but I eliminated them along with the unused decimal point in those cases and it made no difference. You will see the GND and DEP frequencies swapped but that is for testing another issue. That wil have no bearing on RC running.

 

For the airports I used in testing, I opened each in ADE and exported the comms list copying/pasting the data to a wordpad file as a reference for checking the frequencies that came up. Where multiple frequencies are used for the same function, makerwys grabs the first one of that type.

 

My files for testing are named f4-static.csv for the original and f4-4611.csv for the copy from FS made by makerwys. I then copy paste either to the same data folder and rename the copy to f4.csv. It is easy to tell which f4 is active since the 4611 f4 has less data since makerwys excludes airports with only very small runways in order to exclude those very short pseudo runways used for the crosswind landing technique of making non-parallel runways simultaneously active. I think that cut-off value is 1500 feet.

 

That should not cause a problem unless one of those airports is in the flight plan in which case no a4.csv or r4.csv files will have those and rc will generate an error.

 

The original f4.csv had frequencies for 22,982 airports. I do have a few add-ons but the 4611 f4 has 11789 airports listed of suitable capability for RC's use. I do not know the frequency source for the original f4.csv fixed file. It appears to be converted from the same data used in RCv3 developed for FS2002.

 

I've also used KANE for testing as another controlled airport. Before ADE came out I stretched with AFCAD 9/27 and added the ILS for 27 as was done a few years ago. but generally I insured I used unmodified stock for the tests I ran.

 

That is where I am at this point.

 

The next step is for the test airports to copy\paste in the new f4 the airport names from the original f4 to see if that has an effect.

 

Here's an example but it is George Grimshaw's (Fly-Tampa) freeware legacy Boston version:

 

Static

 

KBOS,Boston - Logan Intl,135,121.65,134.05,119.1,122.95,0,127.2,133

 

4611

 

KBOS,Logan Intl,135.00,121.65,121.75,119.10,122.95,0,118.25,133.00

 

grimshaw comms:

 

Airport, Type, Name, Freq, Comments

,APPROACH,BOSTON,118.250,

,APPROACH,BOSTON,120.600,

,APPROACH,BOSTON,127.200,

,ATIS,KBOS,135.000,

,CLEARANCE,BOSTON,121.650,

,DEPARTURE,BOSTON,133.000,

,FSS,BRIDGEPORT,122.100,

,FSS,BRIDGEPORT,122.400,

,GROUND,BOSTON,121.750,

,GROUND,BOSTON,121.900,

,GROUND,MASSPORT,131.100,

,GROUND,BOSTON,134.050,

,APPROACH,BOSTON APPROACH,124.100,

,APPROACH,BOSTON APPROACH,124.400,

,TOWER,BOSTON,119.100,

,TOWER,BOSTON,128.800,

,UNICOM,LOGAN INTL,122.950,

 

is the ADE export of the version picked up by makerwys 4611. You can see makerwys used for f4 the first instance of the relative types.

[nrcapes 0]

Something strange is happening with f4.csv for FSX. I changed one airport (KEAU) with Airport Design Editor and compiled that airport to \addonscenery\scenery. Started FSX, which saw the scenery change and updated its scenery database. Ran makerwys 4.611 on my FSX system. Ran RC4 on the other system and hit the Rebuild Scenery DB button. Since it was a WideFS system, I gave RC4 the shortcut to the FSX folder on the FSX system. RC finished the rebuild. I copied f4.csv from the FSX folder to the RC4X\data folder on the RC system. Ran RC with a flight plan with the modified airport as departure and KSTP as destination. The changes were there for the changed airport but KSTP's frequencies were also updated to those of the changed airport. Fortunately, I made multiple copies of the f4.csv file that used to be OK,so I could easily fall back.

 

What would you like me to provide to help with diagnosis?

I just repeated this whole sequence. Now KEAU has the correct modified frequencies and all frequencies for KSTP are blank. I'v attached the f4.csv file.

[ronzie 21]

I ran several more tests that continue to be inconclusive.

 

I then tried a different tactic;

 

Leave the original f4.csv file in the rc\data folder. Make a safe copy of it. Be sure you have a safe copy of rcv3.dat as well.

 

Open the new f4.csv located in the FS folder in Wordpad. Copy the new line to the clip board. Close wordpad. Open RC's original f4.csv file in Wordpad. Paste over the line with the modified line or insert the modified line in alphabetical order in RC's f4.csv. Make sure the file is saved in MSDOS text format and does not append the .txt extention to the file name. I found that this problem does not then occur.

 

Not quite as easy as a whole file copy but at least that works and you do not have to type in the corrections. See if that works for you. I ran the same sequence including a plan with the modified line and it worked.

 

So the current recommendation is to use the f4.csv file in your FS folder as a source of the modified lines. This reduces the chance of typing errors and format errors.

 

It is best not to delete airports from the f4.csv file unless you are substituting a replacement. The file can be longer but not shorter (for now) than the original.

 

If you are changing a number of airports at once copy from the FS f4.csv file the lines of interest into a temporary wordpad document (saved as MSDOS.txt format). Then use that temporary document to copy each line to the clipboard for pasting each line into the RC f4.csv file as an overwrite or insert new line (in alphabetical order).

 

Other than the reduced size of the f4.csv file in the FS folder nothing we think may have such an effect.

 

This procedure should be done whenever an airport is added or frequencies are modified by a new airport or replacement add-on.

 

When using the control panel just for viewing frequencies just cancel out of it. If not it will create an .rc4 file named with the flight plan where modifiable data (not frequencies) will be recalled from.

 

For adding a new ICAO coded airport there is another file that needs to be update. You will need the information from published charts or elsewhere. m4.csv contains the ICAO code, MSA value, and the transition altitude (in feet). Adding a new airport with this information needs to be inserted into that file in alphabetical ICAO order. This information is not in the afd properties of FS scenery so it can't be extracted. If unable to get this data look at an adjacent airport if close enough and use that MSA and transition level data. Again, you do not want to shorten this file length. It doesn't hurt to my knowledge to leave unique coded obsolete airports in there. I did this with Kai-Tak and the user did not have a problem. Wikipedia can give you the airport altitude in most cases. Then add a few hundred feet for that MSA which is used for the GS intersect altitude in RC.

 

For example http://en.wikipedia.org/wiki/St._Paul_Downtown_Airport shows an AMSL of about 700 feet. RC's m4.csv entry is KSTP,1036,18000. The ILS approach chart shows an MSA or 3500 feet at 25 miles out. The GS intersect is shown at 3,000. The MSA data RC uses is averaged from data closer to the airport. (Don't forget on a chart the 25 mile MSA in this case includes the Shoreview TV towers which top out at about 2400 feet MSL) but RC uses a measurement closer to the airport averaged from the surrounding quads and the airport elevation. I don't know the formula but probably includes a 3% glide slope. The FAA makes for descent a 200 foot margin over any obstructions in the path. That could account for the additional 300 feet above the airport AMSL adjusted for the inner marker.

 

I thought I'd mention this for the addition of airports not in the m4.csv database probably from data obtained in 1998 or so. I don't know the source that was used to interpolate that figure.

[Pete Dowson 558]

Hi Ron et al,

 

After writing an extra little program to analyse the F4.CSV file, I find that the one produced by MakeRunways 4.611 has 4 bad entries. These are due to airport names containing commas. You will notice that in the F5.CSV file the names are enclosed in "" so commas within don't matter. So I hadn't stripped them out.

 

The four culprits are 9D1, CSJ2, KLXL and SBRF.

 

Really these shouldn't have any adverse affect unless actually used, but there's a possibility that RC reads the whole file into an array, and if it doesn't check field lengths it might be corrupting things internally.

 

I've now uploaded MakeRunways 4.612 to the Support Forum, and this replaces any commas in the names with dashes. Please see if this fixes the problems.

 

Regards

Pete

[agutz 13]

Hi Peter,

I didn't find the new makerwys file on your support forum so I edited the "four culprits" in f4.csv produced by 4611.

I just checked my home airport (LFSB by FranceVFR) and RC4 now has the correct frequencies. Using makerwys 4611 I saw the same symptoms nrcapes described above.

Thanks and regards, Andreas

[ronzie 21]

In your RC main folder(s) please make a safe copy of rcv3.dat. I called mine safe-rcv3dat.

 

Version 4.612 has been "stress tested" by me and it works just fine. It is now up in the FSUIPC support forum under the useful addition programs section.

 

http://forum.simflig...ional-programs/

 

In several random order sequenced using controlled (towered) and uncontrolled( non-towered) airports alternating them as departure and destination airports none of the aforementioned problems occurred.

 

The problem with the comma in the airport name (as extracted from the airport scenery data) as Pete discovered actually created an extra field throwing the field order off when RC read the file and caused unpredictable behavior. In a .csv file the comma is the field separator and is not to be part of the field entry. Pete has replaced the comma with a hyphen or dash character which is acceptable. The fixed data f4.csv file supplied with RC did not have this problem.

 

Departure and Ground frequencies are no longer reversed.

 

Regarding Unicom RC is actually reading Multicom so you'll see Unicom reading at uncontrolled airports only where the Multicom attribute has been assigned. This is not a feature used in RC4 for pilot position reporting on entering and throughout the airport traffic pattern. In this version CTAF for the same purpose is not used.

 

Follow the procedure in the first post to get things going initially and then for the rest of the uses do the f4.csv copy after doing a scenery rebuild from within RC.

 

Thanks again to Pete Dowson for being persistent and sleuthing this out.

[Pete Dowson 558]

I didn't find the new makerwys file on your support forum so I edited the "four culprits" in f4.csv produced by 4611.

 

Version 4.611 is not available any more! You should delete it. 4.612 replaced it on my Support Forum at least an hour before i posted my message above. If you didn't see it you need to refresh your cache. Try pressing F5 or CTRL+F5 in your browser.

 

Pete

[Taipan 30]

Very nice!

 

Here I have FlyTampa's VHHX Kai-Tak with 4 frequencies for Ground, Tower, Dep/App.

 

Previously it had nothing for VHHX, thanks!

 

Just to clarify the process going forward once it's setup:

1. Execute makerwys.exe

2. Copy the f4.csv from FSX/FS folder to RC4\data folder.

 

Does this mean we no longer need to click the "Rebuild Scenery DB" button because we are doing it manually?

Or do we need to rebuild scenery db AND copy the file?

 

One more question:

The original f4.csv had ~23,000 rows.

The new one has only ~11,000 rows.

 

Does that mean it is missing some?

Or are they redundant entries that aren't used in our current FSX scenery install?

[ronzie 21]

Run the scenery rebuild first from within RC or (makerwys first and then the scenery build within RC is on a network client to an FS host). Either way the modified f4.csv resides in your FS folder. This updates the RC runway and airport information but not the frequencies in the rc\data folder. Then shutdown RC and copy the f4.csv in your FS folder to the RC\data folder to update RC's frequency list.

 

Runways in airports less than 1500 feet are excluded from RC's data base to prevent the work around called the crosswind runway technique which creates a number of pseudo short runways that are not "real" so FS9 and FSX can treat non-parallel runways as simultaneously active especially for ai operation. Airports that do not have any runways longer than 1500 feet are totally excluded from the runways (r5.csv copied to RC as r4.csv) and f4.csv airport list. RC creates its airport location list a4.csv from r4.csv in its data folder. In FS's ATC if you look at one of these airports with these psuedo runways you'll see them in the runway selection list. Not so with RC. RC's original f4.csv runway selection was from I believe an outside source of all airports.

 

It is unlikely that these small airports would have controlled flights, the object of RC.

 

Glad it worked for VHHX for you. It should also work with the new VTBS Bangkok Thailand airport (as freeware):

http://en.wikipedia.org/wiki/VTBS

in addition to its older VTBD Don Mueang International Airport.

 

 

[Taipan 30]

Glad it worked for VHHX for you. It should also work with the new VTBS Bangkok Thailand airport (as freeware):

http://en.wikipedia.org/wiki/VTBS

in addition to its older VTBD Don Mueang International Airport.

 

Yeah I have Ray's AFCADs that use the crosswind runway trick. So I guess the old frequencies list was out of real world data, where FS data is more useful.

 

I have the AFCAD for VTBS, but is there a full freeware airport scenery you are mentioning? I haven't seen one do you have a hint where I can find it?

 

Cheers