Errant Squawk Codes

[Adam Vianna 1159285]

Sometimes I'll QB a callsign and type it in wrong, either because a pilot calls ups as "DAL123" when he's logged in as DVA123 or I just mishear it. This puts the squawk in the code window and removes it from the pool of those available to [Mod - Happy Thoughts]ign. Is there a way to reverse this? I've tried using QX but I get a not tracking error. QB only toggles the highlight feature without removing the code.

[Dominic Nguyen]

Have you tried:

 

QB(CODE)... Add or remove codes to/from beacon code list.

 

 

 

then,

 

AM (CALLSIGN) BCN (NEW BEACON CODE) [Mod - Happy Thoughts]igns a new beacon code. Must be a discrete code.

 

or

QB(CODE) [Mod - Happy Thoughts]ign specific beacon code

[Adam Vianna 1159285]

QB (CODE) only toggles the manual highlight and won't remove the code from the list and I can't slew the target whose code I want to recycle since it doesn't exist.

 

I'll have to try the amendment method, but I don't suppose vERAM will take 0000 like VRC does?

[Benton Wilmes]

QB_(code)_ should remove any code from your code list or will add it to the list if not already in it. At least it works on my side.

 

I.E. QB 1200 will put the code in the list or remove it if entered again.

 

What do you mean by "manual highlight" though? If you mean you can see that code on the scope and it dwells, then the code is in your list and if it isn't dwelled it is not so not sure what you mean.

[Ross Carlson]

What's happening is that the QB command will create a tentative flight plan for the erroneous callsign, and [Mod - Happy Thoughts]ign a discrete beacon code to that plan. In the real system, I imagine they would use the RS ("remove strips") command for this, but since there is no way to delete a flight plan in the VATSIM world, I did not implement RS in vERAM.

 

"QB 0000 DAL123" will work, but only once. If you try it again on another callsign, you'll get a "beacon code in use" error. So you'll have to use 0001 etc.

 

Note that such flight plans will be purged by the system after 30 minutes if no target or track appears.

[Ryan Geckler]

The real beacon code time out period is much shorter than that. I'll try and get you a firm number.

[Ross Carlson]

That's the flight plan timeout ... is there a separate timeout for a beacon code?

[Ryan Geckler]

Yeah, a beacon code will time out if it's not picked up on radar after some short amount of time. A flight plan will time out after 30 minutes.

[Ross Carlson]

Okay cool, I'll implement that ... let me know what the real one is. Thanks.

[Ryan Geckler]

120 seconds.

[Ross Carlson]

Thanks, I've added it to the to-do list.

[Cardin Pelletier]

Sometimes I'll QB a callsign and type it in wrong, either because a pilot calls ups as "DAL123" when he's logged in as DVA123 or I just mishear it. This puts the squawk in the code window and removes it from the pool of those available to [Mod - Happy Thoughts]ign. Is there a way to reverse this? I've tried using QX but I get a not tracking error. QB only toggles the highlight feature without removing the code.

 

I have the same problem all of the time when using STARS or ERAM. An aircraft calls up, I attempt to [Mod - Happy Thoughts]ign a beacon code to that aircraft and, in the case of ERAM, I end up not acquiring the aircraft under the callsign I entered because the callsign I entered was different from that which the pilot signed on to the network with. This can get pretty tricky if, for example, you have a "UAL42" call up, but they've signed on to the network as "UNITED42." Or, a CFBDX call up who has signed on to the network as "C-FBDX". If you don't put the dash, you will not get a track. It shouldn't matter where or not I enter "UAL42" or "UNITED42" -- once a flight plan is created with that ACID and a code is [Mod - Happy Thoughts]igned and subsequently squawked by an aircraft, it should tag it accordingly. Of course, I realize this is a technical limitation of VATSIM caused by how everything works on the back end.

 

Any thoughts?

[Ross Carlson]

Any thoughts?

 

My thoughts are that this is mainly a side-effect of users doing something they shouldn't. They shouldn't connect using callsigns with a hyphen, and they shouldn't connect using callsigns with invalid airline code prefixes.

 

I suppose I could modify the clients so that if you [Mod - Happy Thoughts]ign a code with "QB UAL123" and then later a target appears with some other callsign (such as UNITED123) squawking the [Mod - Happy Thoughts]igned code, and that callsign (UNITED123) doesn't already have a code [Mod - Happy Thoughts]igned, it would grab UAL123's code and [Mod - Happy Thoughts]ign it to UNITED123, and then the track would auto-initiate. I haven't thought this through enough to say whether or not it could cause unexpected problems such as with pilot's accidentally (or willfully) "stealing" each other's beacon codes.

 

Thoughts?

[1275389]

Thoughts?

Check if anyone within the controller's vis range matches UAL123, UA123, UNITED123. If there is only one, [Mod - Happy Thoughts]ign the beacon to whichever one exists, otherwise throw an error.

[Ross Carlson]

Thoughts?

Check if anyone within the controller's vis range matches UAL123, UA123, UNITED123. If there is only one, [Mod - Happy Thoughts]ign the beacon to whichever one exists, otherwise throw an error.

 

I used permutations of UAL as an example of the larger problem of callsign mismatch. I wouldn't want to come up with all possible permutations of all airline codes and check for them all.

[Cardin Pelletier]

Any thoughts?

 

My thoughts are that this is mainly a side-effect of users doing something they shouldn't. They shouldn't connect using callsigns with a hyphen, and they shouldn't connect using callsigns with invalid airline code prefixes.

 

I suppose I could modify the clients so that if you [Mod - Happy Thoughts]ign a code with "QB UAL123" and then later a target appears with some other callsign (such as UNITED123) squawking the [Mod - Happy Thoughts]igned code, and that callsign (UNITED123) doesn't already have a code [Mod - Happy Thoughts]igned, it would grab UAL123's code and [Mod - Happy Thoughts]ign it to UNITED123, and then the track would auto-initiate. I haven't thought this through enough to say whether or not it could cause unexpected problems such as with pilot's accidentally (or willfully) "stealing" each other's beacon codes.

 

Thoughts?

 

Ross,

 

I agree. Having users sign on to the network with the proper 3-letter airline ID would certainly reduce the amount of occurrences. However, there would still be the issue with tactical callsigns and callsigns from fictitious organizations. For example, if an aircraft calls me up as "Guard 245", I would most certainly enter the callsign as "G245" if I didn't know that the aircraft callsign was part of the Northwest Air Guard unit and uses the "NWAG" callsign and, thus, should be entered as "NWAG245".

 

Out of curiosity, Ross, would it even be possible to have a controller client completely ignore the callsign that the pilot signed on to the network with? For example, if the system does not find a flight plan for a QB'd ACID, the system would create a FP for that callsign, [Mod - Happy Thoughts]ign a beacon code to it, and simply look for and begin tracking the aircraft squawking that code? The next logical question would be, "What if two aircraft are then squawking the same computer-[Mod - Happy Thoughts]igned code?" I'm not sure exactly how the real-world system handles that. I [Mod - Happy Thoughts]ume the first aircraft the system picks up will acquire and "CODE" will be displayed in the DB, signaling that there is a code conflict.

[Ross Carlson]

Yeah, it's certainly possible to correlate a target with a callsign strictly by beacon code, but I do think it would cause problems in some cases, one of which you described. I'm not sure how the real system behaves in these situations where there isn't also a flight plan to help predict the location of the aircraft.

[Dhruv Kalra]

I'm not sure how the real system behaves in these situations where there isn't also a flight plan to help predict the location of the aircraft.

You get a free track instead of a FLAT. If a free track goes into CST status at any point, it coasts along on the last computed track and ground speed, as opposed to a FLAT going CST, which coasts along the flight plan route at the last computed ground speed.

[Ross Carlson]

I'm not sure how the real system behaves in these situations where there isn't also a flight plan to help predict the location of the aircraft.

You get a free track instead of a FLAT. If a free track goes into CST status at any point, it coasts along on the last computed track and ground speed, as opposed to a FLAT going CST, which coasts along the flight plan route at the last computed ground speed.

 

Yeah I figured it would be a free track since you can't have a flat track without a flight plan. What I'm wondering about is the track correlation logic. As I understand it, if a callsign has a flight plan, it will only auto-acquire a track if the target is squawking the [Mod - Happy Thoughts]igned code and it appears to be on or near the flight plan route. Without a flight plan, is there any position-related logic, or will it auto-acquire to ANY target within range of ANY radar site in the entire ARTCC as long as it is squawking the right code? Maybe it only acquires targets that are within the airspace for the sector that [Mod - Happy Thoughts]igned the beacon code?

[Dhruv Kalra]

Without a flight plan, is there any position-related logic, or will it auto-acquire to ANY target within range of ANY radar site in the entire ARTCC as long as it is squawking the right code? Maybe it only acquires targets that are within the airspace for the sector that [Mod - Happy Thoughts]igned the beacon code?

As far as I know, ERAM will search the entire center's AOR for the beacon code.

[Ross Carlson]

Cool ... so the question is whether or not we want to have vERAM [Mod - Happy Thoughts]ociate tracks with targets where the callsign doesn't match.

 

And once the beacon code correlates the track with the target, should vERAM update the ACID on the track to match the callsign of the target? If not, vERAM will need to maintain an internal mapping of controller-entered callsigns to the actual pilot-entered callsigns so that it can translate when doing things like sending a flight plan, starting track, sending a handoff, etc.

[Dhruv Kalra]

And once the beacon code correlates the track with the target, should vERAM update the ACID on the track to match the callsign of the target? If not, vERAM will need to maintain an internal mapping of controller-entered callsigns to the actual pilot-entered callsigns so that it can translate when doing things like sending a flight plan, starting track, sending a handoff, etc.

I suspect that having it do the internal mapping would be nice in that it would pave the way towards such things as being able to synchronize ACID/CID data across vSTARS/vERAM clients as well as allowing us to rid our scopes of the DELTA123s of the world

[Ross Carlson]

It doesn't pave the way for those things ... those things are still just as complicated with or without this sort of mapping.

 

I'm also wondering if having a mismatch between what the controller sees and what the rest of the world sees could cause problems such as when coordinating with other controllers or when hailing a SUP.

 

I'm definitely leaning toward having it change the ACID within vERAM.

[Cardin Pelletier]

I'm also wondering if having a mismatch between what the controller sees and what the rest of the world sees could cause problems such as when coordinating with other controllers or when hailing a SUP.

 

This is what immediately came to mind as one of the challenges of having a controller client work in this manner. I would say, a vast majority of the time coordination would not be affected as most of the time we are dealing with the difference between a DAL123 and DELTA123. Regardless of whether the next controller sees "DELTA" or "DAL", we're both going to be on the same page. I'm not sure about how it would work with the SUPS either -- that's another thing. Having the system automatically correct an incorrectly-entered ACID based on squawk code and flight plan correlation sounds like a good compromise. The only issue I would imagine could come from that is if the system corrected the ACID mismatch to one that a controller didn't recognize. I'll use "NWAG" as an example again because it's one of the more obscure callsigns used. [Mod - Happy Thoughts]uming I'm not familiar with the callsign, I'll [Mod - Happy Thoughts]ign "G" as the ACID when the aircraft calls up as "Guard". If I get a track with NWAG, I may be left scratching my head especially if I'm busy and I'm subconsciously keeping an eye out for a "G".

I suppose one way to resolve this issue would be to allow the callsign the pilot signs on to the network with to be only a 'preferred callsign'. The callsigns would have to be editable by the controllers. The preferred callsign could be kept in the background so that SUPs and other controllers could reference the aircraft by it. When a controller QBs for a ACID, the system would look for an aircraft squawking the [Mod - Happy Thoughts]ociated code with the FP. Once it sees that code, it would change the aircraft callsign to whatever the ACID [Mod - Happy Thoughts]ociated with that code is and start a track. The system would keep the preferred callsign in the background so it can be referenced by SUPS or other controllers. Once a preferred callsign is changed, the new callsign would be displayed.

[Ross Carlson]

The different proposed solutions each have their advantages and disadvantages, but I think that any solution that involves changing the actual callsign to the one the controller entered with the QB is going to have consequences that are hard to predict ... things we can't even think of right now. So I think that if I make any change at all here, it will be to have the displayed callsign be the one that the pilot actually entered. So there may be cases where the controller is confused by the change (such as your guard example) but I think those will be few and far between, and such issues are isolated only to the controller ... they don't spill out to other controllers, sups, etc.