Explanatory Notes

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:

These links open in the same window that you are viewing. You may open them in a new window by
using the right mouse button in your browser.

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.

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.

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.

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.

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.

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.

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):

Explanation: The phonetic & Morse weights (the relative time it takes to key the callsign) is
computed above, as follows:

The PostreSQL GENERATE_SERIES function is used to generate the string offsets of
1 through 6 in turn.

The string offsets are used with the SQL SUBSTRING function to extract each individual
character from the callsign in turn.

Each extracted character from the callsign is used to lookup the equivalent phonetic & Morse
code pattern in the database table. For phonetic syllables:

The PostreSQL REGEXP_REPLACE function is used to remove all non-hyphen characters
from the phonetic name.

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.

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:

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).

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.

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.

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.

For further help, or if you have any problems or suggestions, please use the
AE7Qmessage board.

If you have any questions, comments, or suggestions, please use the
AE7Qmessage board.
I've spent a considerable amount of time documenting the vanity application process and publicly
answering very common questions, so that I don't have to repeatedly answer them.
Private messages on these topics will be rebuffed.