Updated: 2023-05-04 --- # Check In Procedure Check In procedures allow aircraft control units to establish contact will controlled assets and pass them updated information, before passing them to a final controller.  Aircraft should conduct an initial call in, then a complete check in should be passed once the ACU is ready to copy, an alpha check should be completed, then finally the aircraft should be passed information for their final controller. # Alpha Check An alpha check is a check that the aircraft has the correct bullseye and their navigation is working properly. An aircraft requests an alpha check by stating “Alpha Check” then the name of the bullseye The controller will respond with the bullseye name and bearing and distance The aircraft should respond with “Good Alpha Check” >[!example] >`A/C`: “Closeout, Camelot 1, alpha check Laura” >==ACU==: “Camelot 1, alpha check Laura 180/60” >`A/C`: “Camelot 1, good alpha check” # MNPOPCA Check In The default format for an aircraft check in is the MNPOPCA check in - Mission number-Unique identifier for the mission/event - Number and type of aircraft- “single hornet” “two tomcats” “four harriers” - Position and altitude-Usually given as marking moms, but GEOREF or WP can be used - Ordnance-number and type of ordnance - Playtime-time on station in hours+minutes - Capabilities-if all systems functional then “No alibis”, otherwise describe systems that are nonfunctional - Abort code- usually only given if operating plain voice At the end of the check in, ask for tasking or give current tasking %% ## Ordnance Presented as 0/0/0-, Model Numbers or Names ## Playtime 1+10 %% # Controller response First log the information provided by the checking in aircraft. Locate the aircraft on the scope and if able to do so, report radar contact, if unable, report negative contact If the aircraft reported standing by for an alpha check, do that first, if the aircraft has not done an alpha check, have the aircraft stand by for one at the end of the transmission Verify the aircraft has the current sitrep or provide the aircraft the new sitrep and any “words” (updates to the situation) Pass the aircraft to the appropriate final controller/frequency Give tasking/instructions/ask for reports as appropriate, if the controller has any relevant information either pass it to them or have the final controller pass it. >[!example] Full MNPOPCA checkin Example: >`A/C`: “Closeout, Camelot 1 with check in” > ==ACU==: “Camelot 1, Closeout, loud and clear, go ahead” >`A/C`: “Camelot 1, checking in DCA1101, section of charlies, marking mom’s 050/55 angels 22, 4/0/2, 1+10, no alibis, holding sitrep tango, enroute to set the Miami CAP, alpha check laura” > ==ACU==: “Camelot 1, Closeout, radar contact, alpha check laura 080/40, sitrep tango is current, no words to pass, contact me on 264.0. >`A/C`: “Camelot 1, good alpha check, no words, switching 264.0” > > _New freq_ > >`A/C`: “Closeout, Camelot 1” > ==ACU==: “Camelot 1, Closeout, loud and clear, report Miami set” >`A/C`: “Camelot 1” # As Fragged/with Exceptions As fragged can be used when something was pre briefed with both the controller and the aircraft checking in. As fragged can only be used for the actual elements pre briefed, it is not enough for the controller to know someone in a squadron would be doing CAP for the entire check in to be “as fragged”. This is where mission numbers start to show their value, a mission number has a certain assigned MNPOPCA, so only the elements that have changed need to be given in the check in, known as exceptions. Mission numbers also have assigned check in locations, so positions are only given if they differ from the brief. > [!example] As Fragged Example > `A/C`: “Closeout, Camelot 1 checking in DCA1101 as fragged” > ==ACU==: “Camelot 1, closeout, loud and clear, radar contact, no words, standby alpha check laura” > `A/C`: “Camelot 1, no words, ready alpha check” > ==ACU==: “Camelot 1, laura 080/40, contact me on 264.0” > `A/C`: “Camelot 1, good alpha check, switching 264.0” >>_New Freq_ > > `A/C`: “Closeout, Camelot 1” > ==ACU==: “Camelot 1, Closeout, loud and clear, report Miami Set” > `A/C`: “Camelot 1” >[!example] Partial Fragged Example > `A/C`: “Closeout, Camelot 1 with check in” > ==ACU==: “Camelot 1, Closeout, loud and clear, go ahead” > `A/C`: “Camelot 1, checking in DCA1101, Fragged plus 1, marking mom’s 050/55 angels 22, rest as fragged, enroute to set the Miami CAP, standing by for alpha check laura” > ==ACU==: “Camelot 1, Closeout, radar contact, alpha check laura 080/40, sitrep tango is current, no words to pass, contact me on 264.0. > `A/C`: “Camelot 1, good alpha check, no words, switching 264.0” >> _New freq_ > > `A/C`: “Closeout, Camelot 1” > ==ACU==: “Camelot 1, Closeout, loud and clear, report Miami set” > `A/C`: “Camelot 1” >[!example] As Fragged with exceptions Example > `A/C`: “Closeout, Camelot 1 checking in DCA1101 as fragged with exception, playtime 1+00” > ==ACU==: “Camelot 1, closeout, loud and clear, radar contact, no words, standby alpha check laura” > `A/C`: “Camelot 1, no words, ready alpha check” > ==ACU==: “Camelot 1, laura 080/40, contact me on 264.0” > `A/C`: “Camelot 1, good alpha check, switching 264.0” >>_New Freq_ > > `A/C`: “Closeout, Camelot 1” > ==ACU==: “Camelot 1, Closeout, loud and clear, report Miami Set” > `A/C`: “Camelot 1” # Abbreviated Check In Once the aircraft has passed a full check in to a controller, if the aircraft get passed to another controller only an abbreviated check in is owed. An abbreviated check in, is simply the remaining playtime and any alibis. If the most updated ordnance state was not passed to the previous controller, pass that as well. The controller should have passed all your check-in information to the new controller The aircraft does not owe any check in when being passed between multiple closeouts controllers, because they are all passing information internally. >[!example] Example Abbreviated Check in: >“Assassin, Camelot 1, 1+00, No alibis, ready for tasking” # State STATE is a brevity term for remaining ordnance and fuel. For air to air tasking, the preferred way is for the aircraft to report the state in terms of how many commits they are capable of accepting. - “Green” State means enough fuel or ordnance to accept multiple commits - “Yellow” State means enough fuel or ordnance to accept one or two commits - “Red” State means not enough fuel or ordnance to accept a single commit The report is passed with two colors, first ordnance then fuel, ie “Green, Yellow” means enough ordnance for multiple commits, but only enough fuel for one. One report can be passed for the entire flight. For air to ground operations, simply give air to ground ordnance and playtime for the flight. # WHAT STATE If a more complete accounting of state is required, the brevity term WHAT STATE will be used. The response to a WHAT STATE is the full ordnance load and fuel of an aircraft The reply to what state is the air to air ordnance followed by air to ground ordnance followed by fuel. - Air to air ordnance is given with 3 numbers, the first representing active, the second semi-active, and the third IR. Guns are reported only if there is not sufficient ammo remaining by adding “Minus” after the third number. - Air to ground ordnance is listed in plain language - Fuel is given either in thousands of lbs or playtime Each member of the flight should reply in order with their state >[!example] > ==ACU==: “Camelot 1, Closeout, WHAT STATE” > `A/C 1`: “Camelot 1-1, two, zero, two, minus two times GBU-38, by One plus zero” > (2-120s, 0-7s, 2-9s, low/no guns, 2x GBU, 1 hour of playtime) > `A/C 2`: “Dash 2, four, zero, two, one by GBU-38, One time Mav-E, by one plus ten” > (4-120s, 0-7s, 2-9s, guns, 1x GBU, 1x Mav, ,1 hour and 10 minutes of playtime)