One of the major components of the new ATC system in X-Plane v10 are the taxi layouts. We sometimes internally refer to this as the “taxi network” because what it’s REALLY comprised of is a network of taxi segments attached to other segments at taxi nodes. The concept is pretty simple, a node connects two or more segments together and it’s a place where a decision could be made by the ATC system in order to change directions. Every single land-based towered airport in the world has it’s own taxi network.
To give you an idea of what a network looks like, here’s one for Seattle (click to see it clearer)
White segments are runways, green-ish (my wife would say “seafoam”) segments are taxiways, red segments are taxiways inside of an active-zone* and the white dots are the nodes. For ground operations, this is what ATC knows about and it’s the ONLY thing ATC knows about. It doesn’t know about buildings or obstacles in the way, it only knows about the pavement. Anytime ATC wants you to get from one point to another, it has to give you a routing composed of a connected list of these segments. The only exceptions are the start and end segments. ATC is only allowed to go “off the grid” to get you onto or off of the network. So if you’re at a gate and you request a taxi to runway 34L, it first tries to figure out the fastest way to get you onto the network. It does this by calculating whether you’re closest to a node or a segment on the network, choosing the closest one and then giving you a straight line to that point. Now you’re on the network. The opposite happens for end points.
So that’s how you get in and out of the network, but what happens along the way? It’s not all that different than the GPS in your car. ATC analyzes essentially every possible routing from your start/end nodes and chooses the one with the lowest cost. Note that I said lowest cost, not shortest distance. Think about the best way to get to work in the morning. Do you take all back roads? Do you maximize highways? Do you avoid tolls? Your decisions are based on far more criteria than the mere distance. The ATC system is no different. Distance is just one of the contributing factors that goes into it’s cost calculations.
Some (but not all) of the other things in the costs are segment type, segment usage, segment angle and the aircraft’s mode of operation. These can be fairly complicated so I’ll summarize them quickly. Segment’s have different types. They can be one way or two way just like streets in a city. Obviously the cost of using a one way street depends entirely on the direction you want to go. If you want to go the legal direction, the cost is nothing out of the ordinary. If you want to go the wrong way, the cost is REALLY high. In other words…only do it if you have no other options! The final segment type is “runway”. ATC tends to avoid taxiing you on the runways because that’d be terrible for airport efficiency…especially if the runway is an active runway. Another contributor to cost is whether or not the segment is already marked to be used. In other words, if another aircraft is taxiing southbound on a particular segment and you want to taxi northbound, that’s a potential problem, so the cost is high. If you’re going in the same direction, it’s no big deal. Segment angle is important as well. ATC does it’s best not to issue routings that result in steep taxi angles. 747’s have trouble making 150 degree turns for instance. Lastly, there’s your mode of operation. Remember how I said ATC hates using runways for taxi purposes? There’s an exception. When you land, it’s often beneficial to continue taxiing on the runway since you’re already on it and you’re already going quite fast. All of these factors contribute to the cost weighting and the route chosen for you is the one with the lowest cost at the time.
So where do these networks come from? Where does the metadata come from? Well, there are thousands of airports in the world that need these taxi networks so that ATC can provide service. It was important to us that ATC would function at any airport out of the box so Ben wrote some insanely cool algorithm that runs “on-the-fly” when you load up an airport. The algorithm looks at the pavement, erodes it inward leaving the “average” center points of all of the edges. This works pretty well but it’s not without it’s problems. The first problem is that it has no clue what the pavement is to be used for. Is it an apron? Is it a taxiway? Is it an access road? Is it a shoulder on a runway? Pavement is generic in X-Plane so there’s no way to know. The result, as you can see in the screenshot above, is that sometimes you get routings on small access roads. Another problem is algorithmic “noise” that’s causes the taxi lines to be quite zig-zagged and wavy. This is why the AI planes often look drunk when they’re taxiing. Often, the segments are not “reduced” or “smoothed” as much as we’d like. You can see the entrances to each runway tend to have a “Y” shape to them because of the “fillet” on the taxiway. This is a byproduct of the erosion code. There is code in there to reduce it as much as possible and “snap” the edges to the runway but it has to be generic enough to work reasonably well at thousands of different airports. Most of the time it causes no problems but there are cases where the “Y” becomes extremely wide because the runway has a thick shoulder created with a strip of pavement. One final problem is the lack of metadata. The active-zones are stamped out around the runways proportional to their size so seldom do they line up with any painted hold-short lines. We have no clue what the taxiways are named. I know what you’re thinking “Why not use the painted taxi markings and signs to aid in the algorithm’s decision making”. That was actually one of the first things we tried and found the data to be too sporadic to be useful and it made the algorithm very slow and complicated.
So if the algorithm has so many problems, why are we using it? Two reasons. First, the alternative is that no airports would have ATC capabilities on the ground until a user made a custom layout by hand. Second, the algorithm was created to be a stop-gap solution, not a substitute for human data! The REAL taxi networks need to come from a human! Once they are made, they’ll be added to the apt.dat and distributed with the sim moving forward. This means that over time, human data will replace the algorithm’s data and taxiing will get better. The taxi network generation is one of the major features of WED v1.2 which will be released in the coming weeks. Authors can create a network for their airports relatively easily. In my first time using WED, it took me only 2-3 hours to create the network and I’m completely clumsy using any kind of CAD type software. Someone who knows what they’re doing could do an equally complex airport in about an hour I would guess.
The layout in the first screenshot above is an autogenerated one. That’s NOT what you’ll be using if you go to KSEA in the simulator and that’s because I made a custom layout. If the sim sees a custom layout, it always prefers to use that. Here’s what my custom layout looks like.
So you’ll notice the lines are straight! There are no taxi segments through buildings anymore, there are no taxi segments on the access roads, there are no “Y” branches at the runway entrances/exits. Also, not visible from this height, the segments are lined up perfectly with the taxi paint and the active-zones perfectly coincide with the hold-short markings as well. I’ve also named each segment properly so that ATC can tell you exactly how to get to your destination e.g. “Taxi via Alpha Charlie Two Foxtrot Delta”.
There really is no substitute for human data. It definitely results in a much more realistic and far less problematic experience.
*An active zone is a taxi segment that’s protected by ATC because it’s adjacent to or in some way affected by an active runway. This is how ATC knows what to protect with hold-shorts and it’s also how ATC knows when it’s time to talk to Ground vs. Tower.
Will scenery developers be able to edit the networks? I’ve noticed with the supplied aerosoft scenery that aircraft like taxing through buildings.
Read the article! There’s a whole paragraph talking about this. 🙂
As far as aircraft taxiing through buildings, they will do that if the shortest path between them and the nearest node/segment is through a building. The solution is for the network to extend closer to each gate.
Chris,
Thank you so much for this long awaited post. A lot of my questions have been answered. 🙂
A couple questions:
First, are there any airports right now other than KSEA that have a custom ATC layout?
My second question is kind of broad, but what is the future for AI aircraft navigation to/from gates? Right now, they seem to spawn at a gate, then taxi through the terminal and to the nearest node/segment (like you mentioned). Will there every be a way to directly connect the gate to the taxi lines so the AI plane can be pushed back and onto the taxi network? I know XP10 is designed to grow and this may be a ways down the road, but any info is appreciated.
Thanks for all your hard work on both the ATC and FB. 🙂
1) Not that I’m aware of but I could be wrong as I’m not sure what Aerosoft has done with their custom airports.
2) My Seattle layout was built before there were really gates or buildings in final locations. What I’ll do is bring some segments closer to the gates which will drastically minimize the amount of “through building” taxiing that occurs. The future solution may involve each gate getting it’s own entrance to the network with some pushback logic but that’s completely pie-in-the-sky right now.
It will be good to clean up airports were you know what routes they take, but what if many people all submit say a KJFK?…which one would be the default…
On the current AI, and they are really great fun to watch…I feel the separation on the ground is far too close, a B747 takes up the same space as a A320 so that means that the smaller aircraft are crushed closer to the larger ones, ditto in the air, if you have several on approach you get far to many call offs as they are too close together, one has just landed before the other is already being called off,
If you start on a runway (or Taxiway) and just standing there then cause the rest to stop also until you finally move again?
Finally an idea I had, on the flightplan, why not have an input of your flight number
say “United 655” so when the controller calls up it can use your call sign “United 655, you are cl…” , it is also useful in the fact that if you change liveries you won’t have the correct rego number on the callsign?
Can’t wait for WED…thanks great job…
Regarding multiple submissions, that’s up to Robin I believe. He’s been the gatekeeper of the default apt.dat and I don’t think we’ve had many collisions so far but this may prove to be different.
Your other points are off-topic here so I won’t address them but there’s plenty of work to be done. I’m aware of the issues you mention.
Sounds great Chris. And relatively easy! Any idea how contributions will be coordinated? Eg what if 2 people are updating an apt at the same time? A register at the org or wherever? What if someone improves a previous version, how will that be assessed or agreed. Hopefully it’s mature, where someone may politely ask the original author to fix. Again, an easy to search register will be important.
That’s up to Robin I believe. He’s been the gatekeeper of the default apt.dat and I don’t think we’ve had many collisions so far but this may prove to be different.
Thanks Chris for an excellent post and for describing the concept with images. That makes things so much easier to understand and also makes the posts more fun to read. Keep on working on that nice atc code, and thanks a lot for what we have to day!
Great news! I can’t wait to try the new WED.
Are you planning a system to create paths to each gate (maybe with pushback) for AI aircraft?
It’s something I’ve pondered yes. It’s still undecided at this point.
Pondered? Are you talking about in relation to auto-generated layouts only?
I ask because I would assume that there is nothing to stop authors doing this for custom layouts straight away and that the tendency will be for them to assume they are supposed to do so for the sake of completeness and bearing mind not all stand entries are straight lines. Is there a downside to doing this?
The pushback functionality is what’s been pondered. Users are free to bring the taxi segments right up to the gate if they wish but keep in mind that AI planes will still cut the nosewheel hard and likely taxi through some jetways to try and line up with the segment underneath/behind them.
Ah right. I understand the issue now. Allow me to add to your pondering…. consider creating a special category of ‘stand’ taxi segments which, like active-zone segments, provoke a different behaviour in the AI. You could attach all sorts of information to this or the associated start-up position such as max wingspan, type of stand, max wingspan, whether self-maneuvering or taxi-in/push-out, etc.
I have thought about gates, at first i thought it couldn’t be done, but if you put in say “active” gates in WED, then when the AI makes up it’s flight plan it then checks the active gates on the departure/destination airport then a sub check on that no other AI aircraft are assigned to that gate/s, from there it is code to code, when you put in a flightplane it will you give a choice of open active gates (assigned) then no AI coming will be able to take that gate….
Hi Chris, great article as usual! Can’t wait for WED 1.2, I may end up having more fun with that than Sim it’s self!!
Cessna729.
looking forward for some hands on with the new wed.
ok. i understand with generic layouts, the system creates segments which might go through buildings. but with your custom layout, how does atc gets an ai acf on the netnork without running through buildings now?
regards,
heiko
It sometimes taxiees them through buildings because the network needs to extend into the terminal area better. I build the KSEA layout before the building placement was finalized so technically it’s incomplete. Once I get a free moment here I’ll update it which will drastically cut down on that issue at KSEA.
Hi Chris,
Interesting insight, particularly the approach taken in the algorithm for the auto-generated layouts.
Couple of questions regarding manual-defined layouts:
You’ve listed a few cost factors that can be associated with individual taxiway segments. I can think of some other real world taxiway limits such as maximum weight, wheel base width and wingspan limits that could be incorporated. Are these considered or in the plans?
Do taxi segment names have to be unique? I am hoping not. I ask because at some airports there may be more than one valid route over a particular piece of named tarmac. For example, at Dublin (EIDW) there are four taxiway junctions close to the main apron that are named ‘Link 1′, Link 2’, etc. and there are multiple routes through some of these from the various converging taxiways. So, two aircraft could be issued the following routings (hopefully at different times!): 1) “Taxi … B3, A, Link 2, Apron 1 to stand 402C”
2) “Taxi … F2, Link2, F1, E1 and hold short Rwy 28”
Each aircraft’s route would pass through Link 2 at a right-angle to the other’s. This, as far as I can tell, could be facilitated in the X-Plane layout scheme as long as you can create two segments called ‘Link 2’.
I am right in thinking that different traffic patterns can be defined depending on which runway is active? If so, given it is defined as ajoined up network, does this require reproducing the entire network for the airport for each case?
Can authors define rules for which runway is to be active at an airport based on wind speed/direction and/or time of day?
1) Yes we toyed with those at first…especially wheelbase and weight but decided to “keep it simple” and see how it goes. The idea was getting really out of hand quickly but I’m not sure what the future plans for this are just yet.
2) I’m having trouble visualizing your example but no, segments names are definitely NOT required to be unique. They can however have only ONE name per segment.
3) Another idea we toyed with in the beginning which got REALLY complicated really fast. Right now there is one network and it’s properties do not change as the runways change (With the exception of active zones).
4) Yes, authors can decide, with quite a high level of granularity, which runways become active for which aircraft and which weather conditions, time of day etc. That’s a topic for the next blog post.
Great post! Will it be possible to reserve a taxi segment for departures or arrivals only? At some airports with parallel taxiways, one may be reserved for arrivals and another for departures. ESGG (Gothenburg) is one such example.
Not at this time no. It was in our original plan which was growing in complication quickly.
Regarding 2), looks like it’ll be fine if non-unique naming is allowed. But for the sake of clarity, here’s an illustration of my example on a section of the EIDW parking chart. The two routings I gave are in purple and green. The ‘Link 2’ junction incorporates all the taxiway centrelines enclosed in the red dashed line.
http://dl.dropbox.com/u/37140664/EIDW_Link2_routing.jpg
In that case, i’d just name both edges LINK2.
Cormac, might I inquire where you obtained this from and are there other airports available? This would be an awesome reference point for building the ATC system up.
Thanks!
Hi Brian,
Aviation charts, including airport parking layouts, for most European countries are available through Eurocontrol’s EAD website. You need to register (free), then login-> Enter Applications -> Pams Light [AIP] -> search by country, chart type, etc…
http://www.ead.eurocontrol.int/publicuser/public/pu/login.jsp
Worldwide, aviation authorities of individual countries may or may not make their charts available through their own websites too.
A question about “cost”: Will ATC ever route a plane down a one-way taxiway in the wrong direction? Is the cost infinite or just very high?
Yes it will give a taxi opposite a one-way. The cost is REALLY HIGH but never infinite. There always must be a routing better than “infinite” or the plane will be stuck.
Interesting post, thanks Chris!
Great post Chris! Looking forward to putting in “networks” for some of the smaller airports I fly in that usually won’t make the commercial products and submitting them to Robin.
When I set up my home airport with a good network with proper segment names, (e.g. A, B, A3, etc.) in WED1.2, I am assuming ATC will speak the correct paths (per the network design) automatically as you suggest.
1) Can you consider outputting the ATC decision process to a devlog that would allow us to improve the routing as we work from “.taxiRwy(32|)” to “Runway 32 Left via Alpha, Charlie”? I can see this being an iterative process for us.
2) KSEA is not a good example, but many airports have crossing runways with one active and one not active, depending on the wind direction. Will there be a way to include this variable in the network design so we don’t have to switch to tower to cross a non-active runway?
Yes, if ATC has proper taxiway names, it will say them and display them in text.
1) Your network has to be built to mirror the real pavement. No consideration needs to be made for cost calculations. Those calculations change depending on the activity on the ground at the moment so it’s really only useful to us for development purposes.
2) Well, this gets into the FAA’s new rules on taxiing but for simplicity, I’ll say that you don’t ever have to switch to tower to cross a non-active runway. If you make your network properly, you tag segments as being active under certain conditions. Those conditions are “arrival/departure/ils” for the runway you specify. So a segment may be active for an arrival into 4R but be inactive for a departure for 4R for example. There are strange airports that need this kind of granularity for their hold shorts.
Hi Chris
2 things quickly…it would be great to have a very user friendly interface to edit or make a custom layout from scratch exactly like FS, this way not only the developer could make this happen but anyone with little or no clues about how to use a cad program.
I noticed that if I give up the atc, because they make me wait too long for a T/O clearance I will be followed by the arrows wherever I go even when I land in my destination airport! Don’t know if you are aware of this but just thought that this is a waste for the sim, making such an effort, and maybe the ATC should just dismiss these cases after you leave the airport.
The bug of not receiving clearance at the gate because of a runway change has not been fixed as claimed in beta 7, happened to me with beta 10.
This is just a suggestion for future development of the Atc, I thought that it would be great to expand the AI choice with planes that are going to be static only, this way the user can gain a lot in fps without giving up the feel of a busy airport.
David
WED v1.2 will be the interface tool to create the networks. It’s not really that complicated at all, I was merely making a point that I’m clueless, it was my first time using WED and it only took me a few hours.
The other things you mentioned are known issues.
Hey Chris,
Quick question about the ATC system. Absolutely loving it, but not sure I’m using it correctly. Right now I’ve been practicing flight from KSEA-KLAX with the ATC, and the ground at SEA is perfect. My question is when I’m in the air, I’m not getting contacted at all. In the real world I only have VFR experience, so not sure if this is normal for planned flight routes. When I get in the air, I get on the Departure Center frequency, but then my communication stops. Is that normal? I would think as I pass through other airspaces I would get told to change frequencies, but that hasn’t been happening.
Thanks for the great articles you’ve been posting!
-Brian R.
Note: I apologize that this isn’t really specific to the article, but I wasn’t really sure how else to contact someone that would have so much information about the new ATC system.
Definitely off-topic but the ATC boundaries are quite large right now so you’ll only get handoffs if you fly outside of the ARTCC’s jurisdiction. They’re not talking to you because if you’re on course and at the right altitude, there’s nothing else to be said. They’ll give you descents as you get closer and set you up for arrivals.
Hi Cormac,
When we thought about getting ‘real world’ traffic flow right, there were two ideas we looked at: (1) providing different layouts for different flow (so that authors could then ‘mark up’ the layouts with one-ways to encourage flow) and (2) providing “preferred routes” – that is, pre-defined canned routings from one destination to another that X-Plane would try first (and use if the route was available) before running the ‘cost’ function.
In the end we thought that choice 2 (canned routes) was viable enough that we didn’t need to include per-flow layouts (and the ensuing complexity). For example, what if you are on a segment that exists in the layout for your flow but is (for some reason) not included in a new flow and the weather changes? Then the segment you are on has disappeared!
In the end there are a huge number of factors that influence real-world procedure; a “canned route” system can get most of these right using a very simple structure; the complexity we’d have to add to the basic ‘automatic’ routing system would be unbounded and there’d be no guarantee that authors could “manipulate” the cost system into getting correct results.
Hi Ben. Yes, it did occur to me that handling of the moment of a traffic pattern change would be interesting.
By the way Chris, do you employ an A*/Dijkstra-type algorithm in parsing the taxi network?
Yes that’s correct.
Just as a quick update to Chris & Ben’s comments:
I am working on updates to my master database to accommodate the new ATC taxi layouts. It’s not a trivial task. It gets sucked into another major initiative for improving the key structure of the nav-aid and waypoint data in the sim (but that’s another long story!). I also need to completely understand the detailed specifications for all the new data options for these taxi layouts (I think I have reached that point now!). So I hope to be able to accept updates to taxi layouts within a few weeks, using the same process as for the current apt.dat airport updates.
As a Seattle resident and someone who gives both Alaska Airlines and American Airlines a lot of money each week for the privilege of flying out of KSEA (and I live under the approach to runway 16L – see the waypoint “ROBIN”), I am quite familiar with the taxi & approach flows at SEATAC! One of my first tasks will be to replicate the common traffic patterns that are used at KSEA, both for the approach flows and for the taxi routes. (There are some interesting nuances, preferred runways, and several one-way flows – usually clockwise around the north and south satellite terminals.) And, of course, approach flows at KSEA also dictate the traffic flows for KBFI. I’ll replicate all this ASAP.
I will post a proper entry here when I am approaching the stage to accept data updates.
– Robin
I’m thinking a little about the active zones. When you tag them as active for a particular runway, is it like saying “on this segment there will be planes headed to/from this runway”, or is it like “if there are planes on this segment, departing and/or arriving planes on this runway cannot be given a clearance to takeoff/land”?
Another issue regarding custom layouts. Must all pavements be part of the taxi network, or only the ones that I want to be used? Or to put it another way, will the auto-layout algorithm fill in the blanks for me, and possibly do a sloppy job?
It’s neither of those. When you tag a segment as active for a particular runway, ATC knows that it has to make a safety decision before allowing anyone to make the transition from non-active to active. As long as someone’s on an active segment, ATC has them in a queue which is used in the logic to decide what operations are safe etc.
No, of course not. You can see in my custom layout that none of the terminal areas have any networks. If an airport has a custom layout, not auto-gen one is created.
Chris, is it actually supposed to display instructions such as “taxirwy(16C)” on the ATC screen? Because I’m getting some when flying out of KSEA and it looks weird…
You should not see that anywhere, it’s a known bug when taxiway names are missing however this should NEVER be the case at KSEA since all taxiways are named. If this is something you can reproduce, take a screenshot of the ATC text and submit a bug with the Log.txt (in the X-Plane folder) attached and submit it to http://www.x-plane.com/bugreport
Why were the taxi layouts built based on the airport pavement outlines and not using the taxiways in texture on the pavement? I assume it should have been possible to detect the yellow lines on the pavement textures, they’re pretty much straight lines or arcs of circle and they’re yellow, a color that is probably easy to distinguish from the rest of the pavement.
I’ve been taxiing around some airports (KSAN, KLAX, KSFO) as directed by ATC and some of the taxiways are really awful. I guess it’s better than nothing and somewhat works for the AI planes, but when taxiing around the airports, it’s not very nice to try follow the zig-zagging arrows given by ATC when the actual taxiway markings are clearly visible right beside you.
So here’s my feature request: on airports where there are taxiway markings on the pavement, build the taxiway network based on them if possible. This would a lot nicer for taxiing and AI but also could serve as a baseline for building custom taxi layouts in world editor.
If you’re able to pull off a good algorithm to build the taxi network, the user would only have to assign names to taxiways (and fix mistakes made by the algorithm) to build a realistic real world taxi layouts.
This was addressed in the original blog post.
Using some kind of computer vision algorithm is surely more expensive. You said you tried using the yellow lines, but you ran into problems. Can you elaborate a little what kind of problems there were? Did you get far enough to see actual results? Were the results bad? Or was the algorithm just too expensive?
Would it be possible to run the taxiway detection algorithm ahead of time? If not to provide automatic taxiway generation, at least to provide a baseline for creating real taxiways in WED.
Subject: Rules for ATC responses
I don’t find a place for comments about ATC that promises to provide some answers to difficulties with dealing with XP10.03r2 other than this one and I would very much like to get Chris to comment on the rules for responses to the ATC controller comments and commands that occur in a normal take-off sequence.
My question is with regard to the sequence that starts with taxi instructions at the point where the aircraft triggers the end of the taxi and ground instructs cutover to the tower and gives the tower frequency.
At that point the normal procedure is:
Retain the ground frequency and respond to ground with an acknowledgement….
Then shift to tower frequency and report to the tower on that frequency. if this is not done in time (due to slowness in setting the tower frequency) you can get either a repeat of the contact tower instruction, or in a case of extended delay, and possibly just after the tower frequency is selected, a query from (somebody) Are you with me?
Question: who is it that I am responding to, and who is doing the inquiry. Is the ATC communication received being sent from the source Com1 is set to? If so, have I missed a response that should have been made to the second ground control message to contact the Tower?
It seems that I can get a response from the Tower without a response to ground confirming the second message repeat. The same situation seems to occur after the take-off sequence with the Tower and the switch over is made to center. The same problem exists here, but tends to be even more prone to repeats if frequency switches are taking more time than the ATC repeat periods and other interrupting transmisions of altitude and off course comments are also injected into the problem.
At switch to center time, I believe that one can get a response from the center controller without acknowledging the last repeat of the contact center instruction and this seems to place the ATC system in agreement with the flight plan… until you get to your destination.. at which point you get no notifications at all and it seems that the ATC has lost contact … possibly at the time you left the starting airport airspace?
Could you describe the expected sequence you expect in the transmissions, and what responses are expected in normal conversations with ATC in the situations that I have described. Also, what are the prerequisites for obtaining communications and instructions at the destination end. I normally set ATIS on the COM2 dials, and switch to COM2 to listen to the arrival airport data. This switch occurs only for the time necessary to obtain this information and I then return to COM1 and the current center frequency. Could this cause a problem in the detection/notification conversation of ATC at the destination end.
A bit more information about the normal sequences you expect and a conversation on the possible difficulties with out of sequence operation on the part of the pilot would be very helpful.
Much of this is being improved but currently, “handoffs” from one controller to another are the only commands that you don’t HAVE to readback. You can and probably should readback “Contact Tower on 128.80” but you can also just DO IT and switch your radios to 128.80 and contact the new controller. If you tune your radio to the new frequency but don’t “checkin” the new controller will do his best to reach you and ask “are you with me” on the frequency.