Planning ahead for retiring VRC

[Jeremy Peterson]

On 5/21/2021 at 1:55 AM, Ross Carlson said:

I may use an established format such as GeoJSON, which should allow FEs to use existing GIS tools for creating new maps.

This would be a much-appreciated feature. Would it be possible to have a (or have someone other than yourself make) .sct2 to .geoJSON convertor? This would speed up the transition process immensely.

I do have a few questions about how large-area-wide surveillance will be performed (i.e., TMU or supervisory duties). From the TMU side, these features (though not limited to just these) are really useful from VRC:

• simultaneous display of scopes at different scales (en route, terminal, and ASDE-X views; sometimes multiple of each)
  • with this, different color and radar profiles for different windows
  • I presume whatever new TDM capability is will cover this
• the compactness of the ATC chat on the bottom of the screen (with a configurable number of lines to display)
• custom sector file (just one all-in-one file needed currently) due to the scope of what we're doing
  • especially during CTP or inter-divisional events, it allows us to have visibility beyond the confines of the U.S.

These are just a few things I could come up with in this moment but I am curious how this capability will/can be transferred via a new radar client (also recognizing that controlling functionality is the priority).

[Ross Carlson]

9 hours ago, Jeremy Peterson said:

Would it be possible to have a (or have someone other than yourself make) .sct2 to .geoJSON convertor?

Most likely, the final format will be something compressed so that it downloads quickly when an update is available. GeoJSON support will probably come in the form of an importer, and an importer for sct2 will also exist. (In other words, no need for an sct2 to geojson converter, unless people want to load the sct2 into a GIS application for modification before importing into the facility definition file for the new client.)

This plan is not set in stone yet, but that's what I'm currently envisioning.

9 hours ago, Jeremy Peterson said:

I do have a few questions about how large-area-wide surveillance will be performed (i.e., TMU or supervisory duties)

I think the plan is for SUPs to use vatSys since it has special functionality for SUP communication.

As for TMUs, you could probably use the new client in Generic mode and load a "fake" facility definition for the entire globe, with a world map.

10 hours ago, Jeremy Peterson said:

simultaneous display of scopes at different scales (en route, terminal, and ASDE-X views; sometimes multiple of each)

This will definitely be possible.

10 hours ago, Jeremy Peterson said:

• with this, different color and radar profiles for different windows

Why is this necessary for TMUs?

10 hours ago, Jeremy Peterson said:

• the compactness of the ATC chat on the bottom of the screen (with a configurable number of lines to display)

The new client will use a separate window for text comms, similar to vERAM/vSTARS.

[Jeremy Peterson]

13 hours ago, Ross Carlson said:

Why is this necessary for TMUs?

I don’t want my ASDE-X windows to look like my approach windows 😛 but I assume this will be automatic in a new client.

 

Thanks for hitting the other points 👍🏼

[Ross Carlson]

I'm asking why the different UIs are useful for TMU purposes.

Edited June 7, 2021 at 03:16 PM by Ross Carlson

[Jeremy Peterson]

On 6/7/2021 at 11:15 AM, Ross Carlson said:

I'm asking why the different UIs are useful for TMU purposes.

We care about surface congestion (ASDE-X), the approach airspace and final boxes, and of course the en route flows, as an example. We need the NAS-wide perspective.

[Ross Carlson]

6 hours ago, Jeremy Peterson said:

We care about surface congestion (ASDE-X), the approach airspace and final boxes, and of course the en route flows, as an example. We need the NAS-wide perspective.

But you said specifically different color and radar profiles. Why does the color matter for TMU purposes? And I'm not sure what you mean by "radar profiles". I assume you meant the different radar modes that you can select from in VRC, which really just changes the data block.

If what you need is to be able to see surface targets, and to be able to see approach airspace and final boxes, then yes, that will be doable in the new client. As I described earlier, you'll be able to have multiple windows, each in a different radar mode, as these are necessities for not just TMU, but also top-down controllers.

Edited June 8, 2021 at 09:57 PM by Ross Carlson

[Lee Sacharin]

Out of curiosity, will it be feasible to run this on a laptop at all?   I know any client technically can operate on laptops without multi-screens, etc., but the question is more of is it realistic to.  Personally I can/do operate VRC in center ops on a laptop and enjoy the experience without the need for larger monitors and keyboards.  vSTARS as well...although vERAM is difficult with that setup.  It is one thing I will miss about loosing VRC....the ability for anyone/everyone to use, even with laptops, without the need for a larger setup. 

[Jeremy Peterson]

14 hours ago, Ross Carlson said:

If what you need is to be able to see surface targets, and to be able to see approach airspace and final boxes, then yes, that will be doable in the new client. As I described earlier, you'll be able to have multiple windows, each in a different radar mode, as these are necessities for not just TMU, but also top-down controllers.

This is fine. I did not mean to make it unnecessarily confusing. 

[Ross Carlson]

9 hours ago, Lee Sacharin said:

Out of curiosity, will it be feasible to run this on a laptop at all?

The Generic mode will be much like VRC, so that's what you'd likely want to use on a laptop. But I am trying to come up with a way to make even the ERAM mode more suitable for top-down controlling on a single screen. It won't be a design priority, though, as the Generic mode will most likely be the best option for that situation.

[Brad Littlejohn]

Quickly revisiting this.

 

@Ross Carlson, do you remember off the top of your head if the latest version of VRC was compiled against the 32bit or 64bit C++ libraries? 

I ask, because with the announcements today from M$, Windows 11's minimum requirements are soon going to start to force our hand. For those not in the know, Windows 11 minimum requirements are:

• a 64bit CPU (or SoC),
• 4GB RAM, and
• 64GB of disk space.

This means that while Windows 11 will not run on 32bit hardware, it still will run 32bit software. So VRC is safe for now if it were compiled against 32bit libraries, but I wouldn't be surprised if they truly go all 64bit, libraries included, putting all 32bit binaries and libraries out to pasture. If VRC is truly 64bit and compiled against 64bit libraries, it's safe until VATSIM makes its decision.

BL.

 

Edited June 25, 2021 at 05:27 AM by Brad Littlejohn

[Ross Carlson]

No, I don't remember. I would guess 32 bit, but I'm not sure. Someone could run a dependency analyzer on it to find out if someone were so inclined.

Edited June 25, 2021 at 03:12 AM by Ross Carlson

[1275389]

Would it be possible to add a feature to quickly re-track aircraft if you accidentally get disconnected?

[Ross Carlson]

2 hours ago, 1275389 said:

Would it be possible to add a feature to quickly re-track aircraft if you accidentally get disconnected?

I'd like to keep this thread to just discussion relevant to the goal of retiring VRC and bringing about a suitable replacement. After that, we can talk about new features, in other threads.

That being said, the feature you suggest is already on my list as it has been suggested before, so it will likely happen at some point, but maybe not with the first release of the new client.

[Lakhbir Singh]

9 hours ago, 1275389 said:

Would it be possible to add a feature to quickly re-track aircraft if you accidentally get disconnected?

this is a fantastic idea; i'm already using vatSys; i'm in the process of geting trained up to be a air traffic controller for YMML; i've read through the Control Tower Moudule already

[Jason Cochran]

I am working on the Miami metroplex impact analysis and realized how easy the sector file format has made my life. Therefore, I wanted to share. I'm not really arguing for or against anything here, just stating how the current VRC and sector file definition format has made this task faster.

We created a "mock up" sector file with the new fixes from the preview AIRAC so we can turn on/off the new procedures with different colors side-by-side with old procedures and sectors. That's super helpful for the analysis phase of large airspace changes. The sector file allows us to "draw" the new diagrams simply and toggle a whole bunch on/off easily.

Without it, I think it would take a lot longer to translate the nav data into geometry for video maps (which might be throw away work) or wait for official maps from whatever source derived. 

[Ross Carlson]

It's pretty likely that there will be a tool to create video maps from sector files, as there is now for vERAM and vSTARS. It's also highly possible that there will be a tool to generate video maps from AIRAC data.

[Edward Sterling]

Question Ross,

With the advent of ADS-B:

• "Real-time ADS-B is now the preferred method of surveillance for air traffic control in the NAS"

is part of your effort to do away with Radar and implement ADS-B for constant coverage?

I was talking with another controller and we came to the conclusion that your VRC was the seed for ADS-B, as on VATSIM you could see everyone all the time anywhere with it. Now with vSTARS & vERAM, it is radar coverage dependent. So now with ADS-B we are going back to the future. So will it be a feature or will radar still be the tool?

Ed

[Ross Carlson]

For now, I have no functionality changes planned. The goal for phase 1 of CRC is to merge VRC, vSTARS, and vERAM into a single client. After that, I'll consider new features. The STARS and ERAM modes will likely be updated to reflect the level of ADS-B integration that exists in the real world systems currently. The Generic mode will work like VRC does currently.

[Kyle Sanders]

5 minutes ago, Ross Carlson said:

…CRC…

Aww *sadness*…. I thought TripC was gonna be a hit! Haha

[Ross Carlson]

Hi all,

I thought I would post a summary of design decisions that have been made since my last long post in this thread.

And it's not just design at this point ... I have actually started coding. The first release version is still many months away, but progress is being made.

So the plan is still very similar to my previous long post. FEs will build an "ARTCC Data File" using an "ARTCC Editor" application, to be developed by Nathan Rankin, ZBW FE. (Thank you, Nathan!) The ARTCC Editor will be a separate executable from the actual CRC client.

The ARTCC Data File will contain all of the data for an ARTCC, including a single ERAM facility definition, any STARS facility definitions, and any ATCT (tower) facility definitions. Every towered airport in the ARTCC will need an ATCT facility defined, however the ATCT facility definition is just an airport ID and one or more video maps, so it will be very easy to create the necessary ATCT facility definitions for all towered fields in the ARTCC.

The data file will contain a single collection of video maps. When creating the ERAM facility definition, those video maps can be grouped into "GeoMaps" as you can do now with vERAM. The video maps can also be assigned to any of the STARS facility definitions. Same for ATCT facilities.

For ASDEX displays, one of the video maps in the master map collection can be assigned to each airport that supports ASDEX. The video map format will include syntax for identifying polygons as various elements of an ASDEX map. The list of elements includes Runways, Taxiways, Aprons, and Structures. When the user creates an ASDEX display, they'll be able to set it in day or night mode, and the client will render the polygons in the appropriate color based on which of those four element types the polygons are assigned to.

Video maps will be categorized, so that when the user pulls up a list of video maps in Generic mode displays, the list will be grouped by category with expand/collapse buttons, to make the list manageable.

Each facility in the ARTCC data will include a list of "Position Definitions". These are analogous to POF entries. One key difference is that instead of a single "sector ID" entry as with POF files, there will be a 2D matrix of facility ID to sector ID. This way, for a given position entry, different sector IDs can be defined for each relevant facility in the ARTCC. For example, an FE might want "Boston Center Sector 47" to appear as "47" for any ZBW controller, but "C47" for any A90 (Boston TRACON) controller. If there is no matching entry in the list, the current logic will be invoked. (Where the client just generates a suitable sector ID.)

Squawk code ranges will be removed from the facility definitions, and the ranges defined in the position list will be used. (Same as VRC.)

Each entry in the position list will have a visibility range associated with it. This will determine the visibility range used by the client. If no matching entry is found, then the max visibility range (per VATSIM policy) will be used, based on the callsign the user specified when connecting.

ARTCC data files will also contain "external" facility definitions. These are nothing more than a facility ID and a list of positions. (Essentially just POF entries for neighboring facilities.) The position list for external facilities will not need to include a squawk code range or visibility range, since they will not be "staffed" by the user. (These external facilities will not be selectable when creating a profile.)

For primary frequency selection, CRC will use the AFV position database for fetching the frequency that matches the callsign that the user connected with. The user will be able to override this frequency if necessary, or if there is no matching position defined in the AFV position DB.

ERAM, STARS, and ASDEX displays will have a user-configurable option to enable "Generic Mode" tools, such as the right-click menu and the double-click-and-drag ruler.

Top-down mode will still be a thing in ERAM and STARS modes. The right-click menu will always be enabled for TDM datablocks. TDM datablocks will be shown for all targets not within radar coverage, regardless of distance from an airport or altitude.

ARTCC data files will be hosted on ARTCC web sites, using a special URL format: crcartcc://www.artcc.org/path/to/file ... clicking on such a link will launch the client which will download the file to the user's computer, making it available for use in CRC profiles. Each time the client is launched, it will check the same URL for updates to the ARTCC data file.

When creating a profile, the user will first choose which ARTCC to use. Then they will select which type of display to use for the primary display (ERAM, STARS, ASDEX, Generic.) Then they will select which facility to use for that primary display. As I mentioned earlier, only certain facility types will be available for each display mode. ERAM display modes will only work with the single ARTCC facility. STARS displays will only load TRACON facilities. ASDEX displays will only load ATCT facilities, and only those ATCT facilities that have an ASDEX video map configured. Generic displays will be able to load any facility type.

Once a profile is created, it can be expored as a JSON file. FEs can create standard profiles and upload them to their ARTCC's web site. Another special URL scheme (crcprofile://) will be used to allow users to click a link to download and import the profile into their local CRC installation. These profiles will not be automatically updated, since the user is likely to make significant changes to the profile (adding more displays, changing settings) after initially importing it from the ARTCC web site.

So, that's where the design currently stands. Any feedback is appreciated!

 

[Ira Robinson]

Feedback,,,?   Heck, Ross, I'm still catching my breath !!    

I do have to say that as someone who has been pretty quietly opposed to this, it is clear that there has been more thought put  into this than I think anyone realizes.  I'm still not crazy about it, and I hope when you get to testing that you try long and hard to break it, including not just giving copies to the atc gurus who already know what they are doing, but you allocate some time to see if the newbies can catch on and some of the old and cranky can make the switch as well.

It can't be a good idea if "ONLY" 90% of the controllers catch on.   Meanwhile, it certainly sounds like there is a plan so, Good Luck!!

Edited September 4, 2021 at 04:14 AM by Ira Robinson

[Edward Sterling]

Hi Ya Ross,

What an update, wow. In it you indicated that:

"For primary frequency selection, CRC will use the AFV position database for fetching the frequency that matches the callsign that the user connected with. The user will be able to override this frequency if necessary, or if there is no matching position defined in the AFV position DB."

One question, I seem to remember that AFV has transmitters assigned for ID'd freqs. and in the new trial version of AFV that it will not assign or make a transmitter for a freq not in the data base. Does something need to change with AFV to make it work for your new client?

Thanks, ed

[Ross Carlson]

55 minutes ago, Edward Sterling said:

I seem to remember that AFV has transmitters assigned for ID'd freqs. and in the new trial version of AFV that it will not assign or make a transmitter for a freq not in the data base. Does something need to change with AFV to make it work for your new client?

CRC will use the AFV position database to provide the user with a list of frequencies to select from in order to set their primary frequency. The behavior of the AFV client itself is not relevant, as there will be no integration between CRC and the AFV client. CRC will only use the AFV position database, which is a web-based thing, not part of the AFV client.

[Mark Galbraith]

On 6/2/2021 at 9:01 AM, Ross Carlson said:

...I was also thinking there could be a row of buttons across the top of the window which would serve the same function as the bookmarks, but they would have a label such as the airport ID. 

Perhaps the buttons on this row could also be dynamic.  Those airports with traffic within the Control Zone (within the surface area, and altitudes below the top of the airspace) could be highlighted.  The button could also show the number of aircraft within the CZ.  Might require a bit more configuration for each control zone, but could be a very useful addition.

I know all about Scope Creep (I'm a Software Developer with 42 years experience), so I'm not saying it should be part of the first release.  Something to think about for the future.

[Jason Cochran]

Ross-

I just read through your design above- and there are several elements I'm super excited about. Thanks for the forethought. 

May I humbly request some kind of API, plug-in architecture, or user exit of some kind that would allow for customization? I don't suppose it needs to be super complicated, but it would be really cool to be able to extend the system with custom code. At minimum, it would be cool to be able to issue commands to the app, and in the best case it could also read data from the application's data model.

There are many uses for such a thing- and there's no way I could come close to dreaming up a comprehensive list. But, for a few examples of things I would do with such a capability:

• Create a graphical utility to update routes with preferred routes with a button press. It could even recommend the preferred route by reading the flight plan of aircraft that are visible, or perhaps only those with a specific departure airport in the flight plan, etc. 
• Help new controllers by building a "flight plan validator" feature to double-check their work and recommend corrections.
• Create a graphical utility that allows the controller to draw certain fixes and geometry based on a facility quick reference.
  • For example, a controller could use his mouse to drill-down to KMIA in my quick reference guide application and choose ILS09. Of course, my app might show the FAA chart and provide some other details from facility SOPs, but then they could click "SHOW FIXES" and the utility would communicate to your application to essentially perform a .FF GRITT INESS.
  • Of course, we can use aliases to do this today, but then someone has to remember something like .miai09 and there are other limitations of the alias architecture (such as recursive stuff or performing more than one command with a single alias) that could be overcome with such an architecture.

These are just some of my ideas, I am sure there are many more lurking in the back of the minds of folks around VATUSA and other places.

Jason