Site Navigation

In addition to the obvious links on each page (each with a tooltip window that is displayed when the mouse is positioned over the link), each of the letters in the AE7Q callsign on any page have a navigation function (displayed in a tooltip window when the mouse is positioned over the letter). On any page, click on the:

• A   to go to the AE7Q application notes .
• E   to go to the AE7Q explanatory notes .
• 7   to go to the AE7Q other tools main page .
• Q   to go to the AE7Q query tools main page .

Processing

When license data is changed at the FCC, it is immediately reflected in the FCC's online ULS license database. However, when a vanity application is received or changed, the FCC normally processes it according to the following schedule:

Day 1:

The application is placed in a Pending 1 status until the FCC's overnight batch processing. Applications in this status can be deleted by the applicant, without ever showing up in the ULS online application database.

Day 2 overnight batch processing (Tue–Sat, between 00:00 & 02:00 ET):

All applications received the prior day are:

• posted to the ULS online application database;
• are given a last action date  of "day 2"; and
• are placed in a Pending 2 status.

After 02:00 ET, these applications will be visible to ULS online searches.

Day 2 early morning batch processing (Mon–Sat, 08:00–09:00 ET):

The FCC scans the ULS databases and collects all license and application data with a last action date  of "day 1", and posts the data in .ZIP files on its HTTP and FTP sites. Note that applications received on day 1 are not included, because they have a last action date  of "day 2".

Day 3 early morning batch processing (Mon–Sat, 08:00–09:00 ET):

Applications received on day 1 (and thus have a last action date  of "day 2") are included in the downloadable files.

Like most non-FCC amateur radio database sites, the AE7Q servers automatically download & apply the FCC's daily update files to its license & application databases each morning around 08:00 & 9:00 ET, respectively. The downloaded license data is current as of 23:59 ET on the previous day, but the downloaded application data is in effect two days old. Note that paying for or amending an application after its received date changes its last action date  and thus may further delay the appearance of the application in the downloaded data.

Data that is one day newer than what is reflected in the downloadable files, can be retrieved by using the ULS database search web pages:

• License data that was posted to the ULS license database immediately prior to the search.
• Applications granted or dismissed as a result of the latest overnight batch processing.
• Applications received, amended, or withdrawn prior to the latest overnight batch processing.

The AE7Q servers frequently query the ULS databases for more current data:

• The ULS license database is queried roughly every four hours, for any recent changes (e.g., as a result of the FCC's nightly batch processing of vanity callsign grants, or any manual cancellations):
  • the morning after each Federal workday, around 02:10 & 05:10 ET.
  • each day around 09:10, 13:10, 17:10, & 21:10 ET.
• The ULS application database is queried roughly every eight hours, the day after each weeknight batch run for vanity applications:
  • received, amended, or withdrawn the previous day. These queries are performed around 03:25 & 10:25 ET (a duplicate query to insure against FCC schedule variations).
  • granted or dismissed during the previous night's batch processing. This query is intentionally delayed until around 18:25 ET, in order to allow the results of those applications to remain visible in the pending application lists for a day.

The results of these queries are immediately applied to the local databases. The net effect of all this is:

• The license data from the AE7Q servers is current (including license grants & cancellations) as of 02:10, 05:10, 09:10, 13:10, 17:10, & 21:10 ET daily, and is complete as of the moment of the query.
• The application data from the AE7Q servers is current (except for grants & dismissals) as of immediately prior to the latest FCC weeknight batch processing. Granted/dismissed vanity applications are current as of 18:25 ET daily.

FCC Numbers

A Licensee ID  is assigned to each licensee and displayed as a substitute for the licensee's Taxpayer Identification Number (TIN).  For individuals, this is the person's Social Security Number (SSN).  For employers and organizations, this is the organization's Employer Identification Number (EIN).

An FCC registration number (FRN)  is assigned to each entity filing applications in the FCC system. Each FRN   is associated with exactly one TIN.  Therefore, each individual licensee should have a unique FRN, and each club licensee should have a unique FRN  that is different from anyone else's FRN.  Unfortunately, some licensees have not understood this, and have shared a FRN  with other licensees, or with clubs for which they are a trustee.

Note that sharing a Licensee ID  and/or FRN  between a club trustee and the club, will create problems if the club changes the trustee. It can also indicate to the FCC that the club is not a legitimate club, but rather a "pocket" (ie, personal) club. Sharing a Licensee ID  and/or FRN  may also result in undesirable consequences if the FCC takes action against one of the licensees, based on the TIN  from a death notice, or a financial or other legal obligation (e.g., a criminal conviction). See also the Red Light Display (RLD) System and The Debt Collection Improvement Act of 1996.

A Sub-Group Identification Number (SGIN)  may be assigned by an organization to sub-groups of the organization (which would each have their own FRN), to allow the sub-groups to share the same Licensee ID. The intended use appears to be as follows:

Say a media conglomerate has one TIN, but owns 100 television & radio stations. Each TV & radio station would use the same TIN, but a different SGIN  and a different FRN  (typically one for each station callsign). That way, each station could conduct its own licensing transactions with the FCC, under the umbrella of the parent organization's TIN.

A File Number  is assigned to each application when it is received. However, the license database apparently only contains the File Number  of the application when each licensee was first licensed or entered into the ULS system. A File Number assigned after the FCC conversion of amateur license data to the ULS (during the week of August 8–15, 1999) begins with a zero; one assigned prior the conversion begins (with a few exceptions) with the last two digits of the year in which they were assigned (apparently starting in 1994), and in many cases the first six digits match the grant date exactly.

A File Number  background in pending application lists is colored:

• Green, for applications that are predicted to be granted to the applicant.
• Blue, for applications that may or may not be granted to the applicant (typically due to competition).
• Yellow, for applications that are predicted to be dismissed, unless outside action occurs.
• Red, for applications that are predicted to be dismissed.

Dates

The action date  (also called the last action date) is the last date that any change was made to a license or application. For applications that are not pending, it is usually the date the application was granted, withdrawn, or dismissed.

For licenses:

• The grant date  is the date the license was originally granted or renewed. The assignment of a new vanity callsign is a new grant (with a new expiration date); the assignment of a new sequential callsign or a change in operator class is not.
• The effective date  changes when the grant date  changes, when a new sequential callsign is assigned, or the operator class is upgraded, or an "administrative" change (eg, change of address) is made.
• The expire date  is the date the original grant or renewal is scheduled to no longer be valid. It does not change if the callsign is subsequently canceled or terminated.
• The cancel date  has a mixed meaning in the ULS:
  • When the FCC cancels a license (typically due to death or callsign change), it sets:
    • The license status  to "Canceled".
    • The last action date  to the current date.
    • The cancel date  to the effective date of the cancellation. Originally, this was the date of death or callsign change. However, in order to enforce the FCC's US Title 47 CFR §97.19(c)(3) "30-day visibility" rule in the case of any callsign cancellation or termination, the FCC sometimes sets the cancel date  to the last action date , plus 30 days, minus two years.
    The callsign will be available two years and one day after the cancel date, or 31 days after the last action date,  whichever is later.
  • When a license expires, the FCC waits until two years and one day after the expire date, and then sets:
    • The license status  to "Expired".
    • The cancel date  and last action date  to the current date.
    The callsign is immediately available.
• The end date  (not present in ULS data) is the date that the license was (or will be) no longer active. It is computed as follows: If the license has been canceled, it is the cancel date, otherwise it is the expire date.
• The available date  (not present in ULS data) is the date that the callsign will be available. It is computed as follows:
  • If the license has been canceled, it is two years and one day after the cancel date, or 31 days after the last action date,  whichever is later.
  • Otherwise, if the license is expired, it is the cancel date.
• The as of date  (for pre-ULS licenses) is the date that the license data was originally collected.
• The start date  and ending date  are the first and last valid dates for a special event (1x1) callsign.

For applications:

• The receipt date  of an application is the first Federal workday on or after the day the FCC (or their bank, if a paper application is filed with a payment) actually receives the application (for online applications, up until 23:59 ET).
• The entered timestamp  of an application is the date & time (presently 00:00:00) that the application was entered into the ULS system. It may be before the receipt date  (in the case of an online application filed on a weekend) or after the receipt date  (in the case of an application mailed to the FCC's bank). The exact time that the application was entered into the ULS system may be viewed by clicking on the application's Show  data button to view the application detail web page, and then clicking on the "Reference Copy" link.
• The payment date  is the last history record date for a confirmed payment for the application.
• The batch date  (not present in ULS data) is computed as the first Federal workday after 17 days beyond the receipt date. Note that in practice, the actual batch date  can occasionally be delayed. On the batch date, the FCC batches for its nightly processing, all vanity applications with the same receipt date.
• The process date  (not present in ULS data) is an estimate of when the application will be processed, and is computed as the next day after the batch date. Early that morning, between 00:00 & 02:00 ET, the batch of vanity applications with the same receipt date  are processed in a random order (without regard to the time of day that the application was received). A process date  matching today has a Yellow background, a process date  in the past has a Red background, and an unknown process date  has a Blue background. The following table summarizes the above (assuming no Federal holidays). However, the estimated process dates  that are computed on the various web pages here do take Federal holidays into account.
  
  

  Submitted on:	Sun	Mon	Tue	Wed	Thu	Fri	Sat
  Receipt date:	Mon	Mon	Tue	Wed	Thu	Fri	Mon
  (wait 17+ days)
  Batch date:	Thu	Thu	Fri	Mon	Mon	Mon	Thu
  Process date:	Fri	Fri	Sat	Tue	Tue	Tue	Fri
  Days of delay:	19	18	18	20	19	18	20

Color-coded fields

License Status backgrounds do not reflect any superceding licenses, and are colored (from the viewpoint of the licensee):

• Green, for licenses that are active (not expired or canceled).
• Blue, for pre-ULS licenses that are active (not expired). This may not be accurate, as pre-ULS records are not updated by subsequent cancellations.
• Yellow, for licenses that ceased to be active less than two years ago (note that the FCC does not mark a license as expired until two years have elapsed). These may only be reaassigned to a previous holder (e.g., renewed) or certain other persons if any previous holder is deceased (e.g., relatives).
• Red, for licenses that ceased to be active more than two years ago. These may no longer be renewed by the prior holder, and are available to anyone.

Availability backgrounds are colored:

• Green, for callsigns that are available.
• Blue, for callsigns that are available, but may be assigned to a pending application.
• Yellow, for callsigns that are expired but not yet available. The callsign is potentially available for a Silent Key cancellation.
• Red, for callsigns that are canceled but not yet available.
• Gray, for active callsigns.

ULS file number backgrounds in pending application lists are colored:

• Green, for applications that are predicted to be granted to the applicant.
• Blue, for applications that may or may not be granted to the applicant (typically due to competition).
• Yellow, for applications that are predicted to be dismissed, unless outside action occurs.
• Red, for applications that are predicted to be dismissed.

Application status backgrounds are colored:

• Green, for applications that have been granted.
• Blue, for applications that are pending.
• Yellow, for applications that have been withdrawn or amended.
• Red, for applications that have been dismissed.
• Gray, for other applications.

Predictions

Prediction backgrounds are colored:

• Green, for callsigns that are predicted to be assigned to the applicant.
• Blue, for available callsigns that may or may not be assigned to the applicant (typically due to competition).
• Yellow, for callsigns that are predicted to be unavailable to the applicant. The application will be dismissed, unless outside action occurs.
• Red, for callsigns that are predicted to be unavailable to the applicant. The application will be dismissed.
• Gray, for available callsigns that are predicted to not be needed by the applicant.

Prediction descriptions (note that the prediction algorithm will not resolve highly complex situations):

• Assigned: The callsign has been assigned to the applicant.
• Assignment: The callsign is predicted to be assigned to the applicant.
• Available: The applicant has no competition for the callsign, but the callsign may not be assigned. See "Note #1" below.
• Competition: The callsign is requested by multiple applicants, and is predicted to be assigned to one of them.
• Pending: A prediction cannot reasonably be made with partial data for this receipt date. A prediction will be made when all online applications with a matching receipt date have been downloaded.
• Unknown: The callsign may not be assigned to any of the competing applicants. See "Note #1" below.
• Offlined by FCC: The application has been taken offline for FCC manual review.
• Active Callsign: The callsign is currently assigned to another licensee. Applicant error. The application will be dismissed.
• Applicant Callsign: The callsign is currently assigned to the applicant. Applicant error. The application will be dismissed.
• Duplicate (…): The application violates US Title 47 CFR §97.19(d)(1) regarding multiple same-day applications. Applicant error. The application will be dismissed. See "Note #2" below.
• Inactive (…): The callsign of the applicant is no longer active. This usually occurs because the applicant has previously been assigned another callsign. The application will be dismissed. See "Note #2" below.
• Insufficient Class: The application does not show the required operator class license for the callsign. See the   Call Sign Systems. Applicant error. The application will be dismissed.
• Invalid Format: The callsign has an invalid USA amateur radio callsign format. This includes callsigns with a slashed letter "oh" instead of a "zero". See the   Call Sign Systems. Applicant error. The application will be dismissed.
• Not Deceased: The callsign of a claimed deceased close relative or club member has not been canceled. Applicant error. The application will be dismissed.
• Reserved Callsign: The callsign is reserved and is not available for assignment. See the   Call Sign Availability. Applicant error. The application will be dismissed.
• Reserved Region: The callsign is reserved for a region that has no US Postal Service, and thus is not available for assignment. See the   Call Sign Systems and   Vanity Request Types: By List (FAQ). Applicant error. The application will be dismissed.
• Restricted Region: The applicant does not live in the required region for the callsign. See the   Call Sign Systems and   Vanity Request Types: By List. Applicant error. The application will be dismissed.
• Taken: The callsign has been assigned to another (competing) applicant. The application will be dismissed.
• Too Early/Canceled: The application receipt date is not more than two years after the callsign's cancellation date, or not more than 30 days after the cancellation was recorded. Applicant error. The application will be dismissed.
• Too Early/Expired: The application receipt date is not more than two years after the callsign's expiration date. Applicant error. The application will be dismissed.
• Too Late: The callsign will be (or has been) assigned to a prior applicant. The application will be dismissed.
• Unneeded (…): The applicant will be (or has been) assigned another callsign. See "Note #2" below.

• Note #1: A prediction cannot be made due to competition for the applicant's other, higher priority callsign requests.
• Note #2: This prediction supercedes an "interim" prediction (part of an iterative process) which follows in parentheses.

Vanity Request Types

For individuals:

• E: Primary station preference list – This is the normal vanity request type to use when requesting a callsign from a prioritized list of one or more vanity callsigns.
• A: Former primary station holder ("By checking this box, I certify that the call sign being requested was assigned to my station within the past 2 years and that I can provide documentation, if requested.") – This is the vanity request type to use when requesting a callsign that you have previously held, and you have documentation to prove it.
• B: Close relative of (deceased) former holder ("By checking this box, I certify that the call sign being requested was shown on the primary station license of my deceased spouse, child, grandchild, stepchild, parent, grandparent, stepparent, brother, sister, stepbrother, stepsister, aunt, uncle, niece, nephew, or in-law within the past 2 years and that I can provide documentation, if requested.") – This is the vanity request type to use when requesting the callsign of a deceased close relative who previously held this callsign, and you have documentation to prove it. You must also be eligible for the callsign according to your amateur operator class.

For clubs:

• F: Club station preference list – This is the normal vanity request type to use when requesting a callsign from a prioritized list of one or more vanity callsigns.
• C: Former club station holder ("By checking this box, I certify that the call sign being requested was shown on the license for this club station within the past 2 years and that I can provide documentation, if requested.") – This is the vanity request type to use when requesting a callsign that your club has previously held, and you have documentation to prove it.
• D: Club station with consent of close relative of (deceased) former holder ("In memoriam") ("By checking this box, I certify the call sign being requested was shown on the primary station license of a person now deceased within the past 2 years. I certify I am acting with written consent of the deceased person's spouse, child, grandchild, stepchild, parent, grandparent, stepparent, brother, sister, stepbrother, stepsister, aunt, uncle, niece, nephew, or in-law and I can provide documentation, if requested.") – This is the vanity request type to use when requesting the callsign of a deceased amateur who was a legitimate member of your club, and you have documentation to prove it. You must also have the written permission of a close relative of the deceased amateur, and your club must be eligible for the callsign according to the amateur operator class of the club's trustee.

Derived Fields

The following fields are not present in the FCC ULS or archival data, and are thus not changeable. They are derived from other values in the ULS or archival data:

• County. This value is derived from the ZIP code.
• Maidenhead. This value is derived from the ZIP code.
• Callsign Group. This value is derived from the Callsign.
• Operator Group. This value is derived from the Operator Class.
• Call Region. This value is derived from the Callsign.
• Geo Region. This value is derived from the State code.
• Phonetic Weight. This value is derived† from the Callsign.
• Morse Weight. This value is derived† from the Callsign.

The following fields are not present in the FCC ULS or archival data, and are thus not changeable. They are derived from both the ULS history and archival history. The accuracy of these fields may depend upon the accurate linking of archival data to ULS data (see below):

• Code Proficiency.
• Next Callsign.

The following fields have been added to archival data, in order to link archival data to ULS data. They are derived from both the ULS history and archival history. A best attempt is made to match archival records with those from the ULS database, but if the names are different, the automated software cannot make a match. These values may be changed in archival data upon request:

• Licensee ID.
• FCC Registration Number (FRN).

†These use the following SQL statement, plus a simple database table of characters and their phonetic & Morse equivalents (in dots and dashes):

  SELECT SUM( CHAR_LENGTH( REPLACE( morse_code, '-', '==' ) ) * 2 + 2 ),
	 SUM( CHAR_LENGTH( REGEXP_REPLACE( phonetic, '[^-]', '', 'g' ) ) + 1 )
    FROM	     "CharMap"
	NATURAL	JOIN (SELECT SUBSTRING( callsign
					FROM GENERATE_SERIES( 1, 6 )
					FOR 1) AS char_id) AS dummy

1. The PostreSQL GENERATE_SERIES function is used to generate the string offsets of 1 through 6 in turn.
2. The string offsets are used with the SQL SUBSTRING function to extract each individual character from the callsign in turn.
3. Each extracted character from the callsign is used to lookup the equivalent phonetic & Morse code pattern in the database table.
   For phonetic syllables:
   1. The PostreSQL REGEXP_REPLACE function is used to remove all non-hyphen characters from the phonetic name.
   2. Next, the SQL CHAR_LENGTH function gives the length of the result, which is just a count of the number of hyphens in the phonetic name.
   3. Next, 1 is added to the count of hyphens, to give the number of syllables in the phonetic name. This now correctly computes the phonetic syllable weight of a single character.
   For Morse code:
   1. Each dot has a weight of two (the dot and the space after it), and each dash has a weight of four (the dash and the space after it). Therefore, a dash and its space is weighted twice as long as dot and its space. As a result, the SQL REPLACE function replaces each dash in the Morse code pattern with two (not three) "equal signs" (the actual character is unimportant) to give the proper relative weighting (in terms of length).
   2. Next, the SQL CHAR_LENGTH function gives the length of the modified (above) Morse code pattern.
   3. Next, the length is multiplied by 2 (remember that dots have a weight of two, and dashes have a weight of four), to give the actual weight.
   4. Next, 2 is added to the single space after the last dot or dash in each character, to give the weight of the space (three) between characters. This now correctly computes the Morse weight of a single character.
4. The SQL SUM functions total the phonetic & Morse weights of each character, giving the correct total.

Note that this Morse weight computation includes the weight of the trailing character space after the last character. Thus, the total weight is too high by "3" for just sending the callsign; however, if you consider the callsign as a word in a message, it is too low by "2", since a word space is "5". Since the whole purpose of determining the Morse weight is to compare the counts between different callsigns, any constant offset does not matter, and this offset provides for consistency with the Morse weight computations of other amateur web sites.