In 2 days I received 10 logs containing about 400 contacts. Time was of the essence, as people were already throwing away their logs. I used these 400 contacts to seed my next round of requests, using the e-mail addresses from the callsign databases. From 100 email requests I received 57 logs (a higher return than vote in the US Presidential elections). I sent off a 3rd and last round and while the logs were still coming in from the 2nd round, I looked up e-mail addresses for the 500 worked calls and sent off another round of requests. 262 of those people had e-mail addresses in QRZ; 200 of those were valid. (The other 62 hams, about 20%, it seems were using decoy addresses rejected by the host computer, to make sure they don't get e-mail from other hams.) In the end I got back 111 logs, containg 2850 contacts, with 750 hams seen. Almost all logs contained the calls at both ends of the QSO and hams were happy for me to use their logs in any way I thought fit. Having the calls turned out to be usefull - I could correct miscopied calls and gridsquares and I could estimate error rates for logs.
The logs showed (for the most part) time, band, mode, worked call and grid. as are standard procedures for an ARRL sponsored VHF contest. I assumed that the opening looked to the operators as if it were a spontaneously organised contest (as against rag chew).
Most were missing one or more of bands, mode or calls. In the initial round of logs for 2m "unknown" was the preferred mode. I returned these logs asking for the missing info, carefully preserving the log, so that all the information would be together in the reply. The reply would be "yes CW", with the log deleted and I'd have to find the original mail, save it, exit from the mailer, and edit the original log to add the missing information.
Some who'd thrown away their logs sent apologies. Some people don't keep a log, others keep them on paper and send e-mail telling me that they don't have them on the computer. Another send a computer printout of his log rather than e-mailing it. Another more computer savvy person sent a jpeg scan of his hand written log. I got several hand written logs by regular mail. The log was a photocopy of the text he'd handwritten on a unruled piece of 8.5x11 paper. Not on a bound book, with boxes for RST, QSLsent/rcv. One day these people are going to get a card saying "Hooray, you're my 100th grid on 2m AU, plse QSL". Distressing as it was to type in someone's log, when it was already sitting on some OM's disk, to me it was great progress that people were interested in the results of the project and had sent in their logs at all.
Many people sent binary attachments in proprietary formats created by programs I didn't have, which ran on operating systems that I didn't have (some from convicted monopolists), assuring me they were ascii. Being an attachment, I had to exit from the mail program and attempt to look at the attachment. The file being binary would lock up my screen and I'd have to kill the session, log back in, erase their binary file, and mail them asking for the ascii version.
People who sent their ascii logs as attachments would not include their callsign, grid or any identifying information. I would have to return to the e-mail, write down the callsign or figure it out from the callsign databases, go back to the attachment and rename it, then exit from the mail program fire up the editor and put the call, grid and e-mail of the sender into the attachment. It can take ages to link up the log and the e-mail address especially when their callsign, email name and realname are unrelated and you've made a mistake in the callsign (eg q changed to g).
Please don't send logs as attachments, even if the attachment really is ascii. If instead you splice your log into the body of the e-mail, then you can easily tell if it's ascii and I'll get your e-mail address and your notes (eg soapbox) when I save your e-mail as a file. If your log is computer readable, then I can just load the whole e-mail message into my log database directly. The "Hello Joe" and soapbox material will be filtered out.
Some people put an unprintable character into their callsigns, e.g. a zero with a stroke through it. My computer only recognises 0-9 as numbers. I noticed that people who used this symbol were careful not to use it in their email addresses, where their computer wouldn't recognise it. If your computer doesn't recognise these characters and the FCC's database doesn't recognise these characters, then you won't be surprised when I tell you that my computer doesn't recognise them either. It's clear that the use of both "O" and "0" and "I" and "1" in the same character set is a real bad idea and it's quite reasonable to ask your operating system to display characters in a font set of your choosing on your monitor and printer. But until everyone agrees thay we need an 11th number, please create the information (i.e.logs) on your hard disk using the same 10 numbers that everyone else uses.
For logging it seems that many people use table napkins. Although personal computers have been around for 20yrs and used pentium computers are now available for under $100 (I have 12 of these used computers), computers are not the preferred device for logging.
There are good reasons for this
AIRPLANE
The airplane Voyager [don't confuse it with either the lost,
dysfunctional probe or the lost, disfunctional ST show -- this was
the first airplane to circumnavigate the earth on a single load of
fuel] was first planned in a napkin-based CAD system.
BRIDGE
The Guardian newspaper (London) suggests that London's Millennium
Bridge may have first been sketched on the back of a napkin. This
is the pedestrian bridge over the Thames which wobbled so much
when walked on that it has been closed.
NAPKIN SUBSTITUTE
Ken Thompson designed *all* of UTF-8,
the byte-level encoding for Unicode, the 16-bit international
character set, on a paper placemat. It's now an ISO standard.
(The 3.5" floppy disk and the first Compaq luggable computer where supposedly designed on a table napkin.)
While there are problems using computers for logging, if you want to exchange or pool information, work out the best place to rover for the next contest, or track the expansion of hams into higher bands over a period of years, then a computer readable log is the best thing we have at the moment. Presumably we could discuss whether a computer is a required piece of ham gear, but it would probably resemble the spark/CW and AM/SSB arguments. I'll just say that computers are useful.
Only 10 or so of the 110 logs were computer readable. People are using computers to emulate typewriters and entering logs in the table napkin format. No-one is taking advantage of the difference between a typewriter and a computer: computers talk to each other and do so without human intervention. Each record in a machine readable log must be self-contained (each record should have all the information about the contact in it). The information for each field needs an unambiguous format. Once you merge everyone's logs into a single file for an event, all you have are the contacts one line at a time. You can't go back to the table napkin log to find the band, mode, grid and call.
Here's a machine readable log entry -
20000715201500 144 CWA AA3AA FM19ax WW1AA FN32 aa3aa@cw.com
The format has all the information needed in each line to describe the contact and to checkup if something is wrong. Most fields are distinctive enough that you could exchange fields and still be talking about the same contact.
The format I've shown, although difficult for a human to read, is easy for computers. The date is the standard 14 digit timestamp used in databases. The computer's job is to present this information in some easy-to-read user selected format (date and time can be separated out, boxes for constant data like your grid, call, mode, band, e-mail address, can be in a separate area on the screen). When entering a contact, you should only have to enter the worked call and grid in any order.
Here's a bunch of date entries from the submitted logs that aren't machine readable. (They all describe the same date.)
00/5/7 20:15z 5/7 2015 7/5 2015 20:15Z 7:5:00No computer program is going to figure out this date. The computer may not even recognise it as a date. In some countries, even humans can't even tell if this is in May or July.
On the AZ_PROJ website, I have a number of lists, of beacons (from 160kHz to GHz), transmitters and mountain tops, none of which are being maintained by the originators in machine readable format. Bill Brelsford K2DI maintains his dxcc list in machine readable format. For several years I pushed the idea of a machine readable format to the various list maintainers. I once got a reply from a list maintainer who agreed it was a good idea, but he wasn't going to be the first. Clearly ham radio isn't ready for the new list of beacons appearing on the maintainer's site and an hour later generating a map on the the AZ_PROJ website from the new list without any human intervention. I gave up - if people really want out-of-date beacon lists that badly, I decided I was going to let them have them.
W0AH: This was the second best AU from here near Colorado Springs since 1988 when we moved here. The best was in March 1989, when I worked 25 states, running 500 watts to a KLM 16LBX.
n0vsb in DM79rj: I have sat and listened to others work AU too many times watching the S meter at S9+20-30, just because of my lack of CW skills. This was not going to be the case this time so decided to get my feet wet. I listened to many stations for about an hour and saw the pattern in exchanges, etc. and finally got the courage to answer WA4HFN's CQ call in TN and after a couple of minutes the first one was out of the way (what a relief and excitment at the same time). I did manage to work through about 8 CW contacts, although did a lot of listening and recorded about 60-70 station calls.
For those who may be in my shoes, give it a try. My strategy was to find someone that was making several calls on a fixed frequency, which gave me the time to make sure I had the call, especially since they generally send relatively fast for us new guys. It did help if there wasn't a lot of QRM as that can be a little confusing for a new guy. Exchanges were simply RST (55A) "A" for Aurora and most followed with grids, e.g. 55A 55A EM55 EM55, 59A DM79, and even learned that 5NA was the same as 59A, "N" meaning "9". At times I was not copying 100%, but really made it a point to watch for the RST (making sure I had those numbers correct) and grid, as well as making sure I had the call correct. Of course when the RXing station heard my slow CW, they too slowed down so don't be intimated by their initial fast calls. Hopefully this will help some of the new guys next time and hopefully you will step off the sidelines and give it a try.
discussion between WD4KPD, N1BUG and Jordan Arndt: WD4KPD: over the years working as much au as possible, i would like to know why the au in the eastern USA always start in the early afternoon around 2000z. i could guess it all depends on when the cme hits, but have they all hit at the same time? is there a physics reason, or is everyone getting home from work kind of thing?
N1BUG: Up here in Maine we get a LOT of aurora. Well, we used to, before the sun died (cycle 23 hasn't been good...). I've worked aurora at virtually every hour of the day/night. Dawn, mid morning, noon, afternoon, evening, midnight. I've seen CMEs and main phase geomagnetic storms at all hours.
Yet it remains that the strongest signals and the best distances are always worked in the late afternoon. I would put the peak clearly at 2000-2100z, EVEN IF the disturbance is even stronger later in the evening. Surely everyone getting home from work is a factor, but why then do signals fade after 2100 and continue getting weaker all evening? This trend happens time and time again, regardless of storm timing. It often comes back in the late evening approaching midnight, but never with the same signal levels or distances covered...
This seems to fly in the face of what we would expect... best conditions around midnight local time, when the oval dips furthest south. Something is going on here... but what is it? I've seen this so many times I can't help but believe there is some unknown (to me) physics reason for it.
Jordan: I have noticed that here in the west , the times for Au seem to be much more "fixed" than they were back in FN-35... here it is nearly always around 7-8 PM local time that Au will start.. it can go on until around 12 Midnight or 1 AM... Back east Au was heard pretty much any time of day... yes there were times that seemed more prevalent than others, but I recall lots of daytime openings... perhaps it is a question of 'band population' more than anything else, but it is quite noticeable that it seems to be more late evening to midnight that Au will show up out here in DO21
W9FX
KB8U 50,144,222MHz: There's a mix of Au and (on 6m) Au-E's contacts. At one time both propagation methods were observed simultaneously (depending on where I aimed my antenna). I also made a few local contacts under normal tropo conditions which I've omitted. The FP/N1JEZ contact was the highlight of the evening, Woo-Woo!!
Dave N0IT, 2m CW: Only heard two stations attempting SSB contact and I could have completed several CW contacts in the time it appeared to be taking. :-)
During much of the opening, the signals were LOUD (20-40 db over S9). At my lattitude, I dont hear auroral sigs that strong. Usually more like S3. Many of the stronger signals seem to be from the south of me. Not sure if that was propagation or because I was working guys putting out some real ERP.
me (NA3T) to N5WD: haven't found any logs from people west of Texas in 1600 contacts. Do you have any idea if this is real, or am I not getting logs from the western people?
Wayne N5WD (using 70' of RG-8 on 2m with no preamp): Ya know, I don't think there is anyone west of Texas, is there? I never hear any (well, with the exception of those Colorado guys who only THINK they're in the west!).
Mike FP/N1JEZ on dx-pedition in GN16, 6m ph: during the two openings we had, I received various reports of my signal arriving via AU, however all during that time, I heard all stations direct with no discernable AU distortion.
W1RMA, 6m ph: .. others such as W4WRL were heard via pure aurora tone, followed by gradual change to pure E-skip (clear tone) and back to Aurora tone. Later FP/N1JEZ at 0049 utc July 16 (utc) was pure 59 E-skip. Also noted 3-land stations peaking pure aurora, beaming west during the Au opening. CW works best on 6 meter aurora when signals are weak.
Glenn K5GC (who like several others, I mailed requesting his log after finding him in another log, but who apparently wasn't in the contest) I haven't worked any DX stations, or operated on HF, since becoming K5GC on May 9, 2000. The call K5GC was expired from April 1998 until May of this year.
Bob K5IQ EL49vx, 6m CW I have often noticed (on both VHF and HF) very enhanced propagation immediately prior to a major solar event. Incidentally, these were the first AU QSOs of my 31+ years of hamming.
Roger K2SMN ALL were CW (2m and above). There was very little tone in this aurora. There have been some good auroras with a high degree of tonal quality, especially on certain headings. I have worked SSB under those conditions in the past. This one was unusually "white noise" 'ish. Not a hint of tone, and a larger than normal doppler shift.
W0JRP EM27RB, 222 CW I only use a 11 element cushcraft at 25ft no preamp on receiver running 100 watts.
As well as the bulk mailings (300, 400 people) requesting logs, I send 330 e-mails either asking for missing info or QSL'ing received logs. I received back 210 e-mails. It took 7 (12hr) days to reformat the logs into a machine readable format and another 2 weeks to analyse the data. Thanks to all those who typed in their logs for me. I had a draft version of this report ready for the N.E.W.S. conference in Aug 2000 and it has taken most of my spare time between Jul-Nov 2000 to prepare the final version.
Here is the map showing the distribution of US hams from the FCC database.
Most of the western half of the country is empty,
except for a few large cities. The distribution of US hams
seen here in the AU opening is similar to the
the whole US ham population.
Here's the population of VHF contesters as seen in a contest
with comparable number of contacts (2m Spring Sprints 1999, with
3618 contacts, about 25% more contacts than the AU opening).
| band | logs | calls | contacts [ Mode ] | longest CW QSO | longest PH QSO | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| total | CW | PH | UNK | call, grid | dist | call, grid | dist | |||
| 432 | 8 | 15 | 11 | 10 | 1 | 0 | K1TEO FN31JH - K4AR EM76WC | 1108 | W0OHU EN34OA - N0SXW EM39AD | 550 |
| 222 | 19 | 56 | 117 | 113 | 4 | 0 | K1TEO FN31JH - K0KD EN31EN | 1697 | N2BJ EN61AM - K1WHS FN43MJ | 1407 |
| 144 | 73 | 404 | 1739 | 1663 | 71 | 5 | K5CM EM25IR - W3EP FN31UO | 2093 | W7FG EM26AR - K2TXB FM29PU | 1881 |
| 50 | 53 | 423 | 731 | 279 | 452 | 0 | W1RMA FN65BV - W4OC EM95AB | 1688 | KC0BMF EN31BE - W1RMA FN65BV | 2149 |
| total | 110 | 900 | 2598 | 2065 | 528 | 5 | ||||
The ratio of 144:432 contacts is 20:1. In the (terrestrial/tropo) Sprints, the ratio is 5:1. It would seem that AU 432 is 4 times as difficult as is tropo/Es under the same conditions.
Here's the contact rate by band.
Notice the burst of activity on 6m at 2400-2600hr (i.e.0000-0200 Jul 16)
when activity on 2m is dropping at the end of the opening.
These contacts turn out to be an Es opening to N1JEZ in GN16 (see later).
Notice also the small burst of activity about 2900
(i.e.0500 16 Jul 2000), a weaker 2nd opening.
On 432MHz there were only 11 contacts
(although plotted, they can't be seen on this graph).
Others didn't separate their AU from Es contacts.
I hadn't anticipated multiple propogation modes in the one opening.
By the time I realised that this had happened,
I didn't have the heart or stamina to ask everyone again for the propagation modes.
FP/N1JEZ operated from GN16 making 159 contacts
in the time of the AU opening on 6m phone.
All his contacts were Es - there was no AU.
N1JEZ appears in only 3 logs
(ie 2% of these contacts were reported, as against 24% for AU)
without reference to the mode of propagation.
If I had not heard from N1JEZ, I might assume that these 3 contacts were AU.
Because of the low reporting of N1JEZ compared to other operators
(average 24%), I assumed that most
people filtered out non-AU contacts before submitting the logs to me.
Other logs came without callsigns, or without gridsquares.
It's hard to tell how accurate these logs are, so I looked
at other indicators of accuracy.
Clocks powered by public AC have been accurate to within a few
seconds for most of the last century. Now that electric utility
companies can sell power to each other's grids, they are all
synchronised to a small fraction of a cycle.
Home computers can be synchronised to UTC to sub ms accuracy
using the ntp protocol.
Alternatively the
Totally Accurate Clock-2 (TAC-2) by Tom Clark W3IWI
(and see also
http://www.ibiblio.org/pub/Linux/docs/HOWTO/mini/other-formats/html_single/Clock.html#ss4.3,
The Clock Mini-HOWTO - link dead May 2003)
uses a GPS receiver to provide long term stability to a crystal
oscillator which can be interfaced to a computer
and is good enough for astronomical observatories.
(Anyone know how turning off the dithering on the
GPS satellites has affected the accuracy of the TAC?)
A local GPS receiver or WWV can be used to manually set a local clock.
For people away from commercial power, digital watches accurate to seconds/month
have been available for 25-30yrs.
For EME and MS, hams synchronise their changeover from send to receive
and back again, to minute or 15sec edges. Thus VHF hams are already
operating at 1sec resolution.
Hams have not agreed on the time at which a QSO is logged,
but this could be solved by a declaration from the contest committees involved.
It could be the time at the end of the last transmission
between the two operators.
Hams should then be able to record the time of a QSO correct to a second or so.
With current accepted operating procedures, the
expected time error will be the time between completing a QSO and logging it.
At a contact rate of 1/min, the time error for logging will be less than a minute.
For slower contact rates, the error might be several minutes.
Here's the differences in times submitted for contacts,
where I have the logs of both operators,
(125 contacts, y-axis is cumulative fraction).
70% of the QSOs are accurate to 1min or less. 95% are accurate to
5mins or less. 4 QSOs from one log were early by 4hrs. I assume he was using
EDST rather than UTC. Another log, which I received with a note saying that
his clock may have been wrong, had an entry that was early by 3hrs.
A quick e-mail exchange with the operator confirmed that the QSLs cards
he'd received from 2 other hams were also 3hrs off.
This means that all logs were correctable to 5mins accuracy.
Any time fluctuations in the intensity of the aurora,
in the order of 5mins or slower that occur simultaneously across the country,
should be seen in the logs.
With 70% of logs being accurate to 1min,
we should be able to see fluctuations in the aurora on a scale of 1mins.
You at least know your own 6 char locator, so put it in when you send in your log.
I calculated the 6 char grid locator from the zip code of the ham's FCC address,
and the lat/lon of the Post Office of the same zip code,
for all calls found in the logs.
If the 4char locator in the log matched the
the entry in the FCC database, I assumed the ham was at home and
I substituted the 6char gridlocator into the logs.
If the operator gave a 6char locator which disagreed
with the FCC location, I included the 6char locator into the originating
grid, but left the 4 char locator in the received log.
This allowed me to do statistics on people not at their FCC address.
I was hoping to include
as much of the data as possible.
For the logs which had only callsigns and not gridlocators,
Initially I looked up the grids in the databases.
This assumes that all people are at their database address.
and turns out to be a dubious assumption;
I assigned the database gridsquare DM03 (Los Angeles)
to K9AKS in K4EA's log,
giving a remarkable distance of 3000km for a QSO on 2m.
The gridlocator for K9AKS from his own log which
I received later is EN41rl (near Chicago)
giving a revised distance of only 1000km for the contact.
I didn't use contacts for which I couldn't determine the gridlocators.
For hams, the 4 char gridlocator is not unique.
This causes problems when making plots of activity.
To illustrate the futility of using 4char gridsquares
as indicators of location, I saved on
the AZ_PROJ webpage
this map of 6m operators in Europe using their preferred method for
describing their location, the 4 char gridlocator.
Clearly using 4 char gridlocators for your location doesn't work anymore.
There are 41 operators in IO91. If you used 6char resolution you get 576
times more locators and most will have a unique location.
When drawing QSO paths for an opening of 2850
contacts, where 16 operators where in EM79, as happened with this AU opening,
all contacts will appear to come from one place in the center of the gridsquare.
More of the paths will be
unique if each ham is using 6char gridloactors.
While you can't use this 6m data to locate anyone,
you can at least use it to produce density maps such as this one.
To validata a contact, hams exchange a piece of
information unknown to the recipient.
Samuel F. B. Morse for his first public demonstration of
telegraphy, was required to receive the unknown piece of
text "What God hath wraught".
The gold standard for confirmation of the contact,
neccessary for most awards, is the QSL card.
This confirms the call, time, date, band, mode.
Similar (cryptographic) exchanges occur while sending e-mail,
logging onto computers and with secure e-commerce conducted by computer
when the transaction involves parties who cannot directly
check each other's identity. Such methods are used by
businesses to cut costs and increase customers
and has allowed the creation of businesses where none
existed before (increasing the value of the US stock market
4-fold in the last 10yrs).
While these methods were developed to use with computers in the
'50's and deployed in suburban banks in the '60's, they entered
homes in the '90's with the internet and now your mother and children
can securely order merchandise on the internet.
QSL cards can be exchanged and validated electronically
(eg electronic QSL cards)
using these familiar principles.
For ARRL awards, QSLs are not accepted electronically.
They are checked by methods that Hiram Percy Maxim would recognise.
For hams the callsign doesn't validate the contact,
as much of ham callsign space is densely assigned.
Almost any call will be valid whether it's the person you're contacting or not.
For a contest, this extra piece of information is usually RST and/or gridsquare.
The RST could be anything, so RST doesn't validate the contact either.
The 4char gridsquare is a reasonable piece of
information to exchange to validate a contact.
While not unique, it is often unknown and
we put some attention into getting right.
A person analysing the contest can
can look up the gridlocator later
and compare it to the log entry.
For the purposes of analysing a contest,
the 6char gridlocator is more useful piece
of information to exchange.
How good is the gridlocator as a validator of a QSO?
With the state of the FCC database, not very good.
From the 2850 contacts, 400 contacts made by 203 calls
were from gridlocators that disagreed with the entry in
both the callsign databases.
It would appear then that 203 operators out of 718 (28%),
with only at most 3 days notice, managed to get from their FCC address
to their mountain top vacation home and be ready for operation.
One of the more amazing get-aways I saw was by K9AKS,
who managed to get from L.A.
(his FCC address and e-mail address in Jul 2000)
to his mountaintop in Moline, IL a distance of 2500km in 3 days,
and be operational on 2 bands.
I e-mailed K9AKS to ask him for any interesting stories about the trip.
He said he'd been living in IL for a year,
he'd updated his address with the FCC
(license dated 17 Jun 1999, a year earlier)
and had his e-mail in LA because the internet
allowed him to have it anywhere he liked.
The address for K9AKS in Jan 2001 at both
qrz.com and wm7d.net is now correct.
Even though these two servers are updated frequently (wm7d.net nightly),
it would appear that they contain old data.
With people moving every 2-5yrs and there being no real
requirement that hams keep their FCC information current,
and hams only having to update the FCC entry every 10yrs,
it is no surprise that the FCC database is out of date.
This situation would be fixed quickly
if contest organisers subtracted points from hams whose
FCC address has not been updated to their current home
address.
What about the rest of the apparently invalid gridlocators?
Some of the 203 calls were reported
in multiple logs. These calls were
Some of these calls (11) were seen consistently in the same gridsquare.
Clearly someone who appears in several logs at the same gridlocator is real and being copied
correctly, even if the FCC doesn't knows where he is.
There were 192 calls appearing once and not in their database gridsquare.
In the (much larger) CQ HF contests, 80-85% of calls seen only once
are bogus (data from W3ZZ).
Presumably some of these 192 calls are real,
giving an upper limit for invalid contacts of 28%.
In the subset of hams who sent in logs (111), the gridlocator
of 9/111 (8%) could not be verified or was different to
the gridlocator in the databases.
If we assume that people who don't send
in logs have the same interest in having verifiable locations
as people who send in logs, then 8% of the 192 calls are
real and the rest (177) are bogus calls.
Thus 49% (177/361) of the singleton calls
and 23% (177/748) of the calls are likely bogus.
This means that 571 of the 748 calls seen are real.
Clearly it's a problem in a contest if 14% of the contacts
and 28% of the callsigns can't be validated.
The mechanism we have
adopted for validating contacts in events like
this (the gridlocator) doesn't work for 28%
of the participants and 14% of the contacts.
It would be helpful to people who need to validate
logs for hams to check their addresses in the FCC database.
Another approach is to look at the duplicate versions of
gridlocators for hams seen in many logs. W3ZZ was seen in
FM19 (his gridsquare) 22 times and FM18 once.
Results for other calls are:
W4MYA 1/28; W3ZZ 1/22; W9VC 2/30; W9FX 0/25; K1TEO 0/20;
K0KD 1/24; K4QI 1/31; K9AKS 1/21;
W3EME 0/24; W3EP 0/21.
This gives errors of 7/246 (3%).
This is a minimum estimate,
since presumably these well known calls were being worked in pileups,
and the other station would have heard plenty of repeats of the gridlocator.
Some errors are easy to spot - eg
callsigns where numbers replaced letters (K3Z0, VE31EY, AC4T0...).
Likely confused calls are single appearances in the same grid as
another often seen call,
eg K1TEG for K1TEO; K5CA for K5CM; W5HUG for W5HUQ; K0BJ for W0BJ;
N0IPR for N0IPL...
FP/N1JEZ who was doing a DXpedition from GN16 on 6m was found in one log on 2m.
These mistakes were found in 40 of the 110 logs.
Other mistakes eg swapped letters would not be easy to spot.
Conclusion: Between 3-14% of the contacts
contain invalid information.
We don't know how invalid the invalid information is, as our method for checking the validity
(the gridlocator) is not functional.
While having a wrong callsign wrong may not be a big deal when the grid
is correct,
having a wrong gridsquare is a big deal,
as in the case of the 1000km K4EA-K9AKS contact which looked like a 3000km contact.
It is thus possible that 10% or so of the QSO paths in the latter maps are wrong.
Presumably most of them won't be seriously wrong and hopefully extra long
paths in the wrong location will be spotted by inspection of path plots.
(C) Joseph Mack 2000-2002, Joe NA3T, jmack (at) wm7d (dot) net, http://www.wm7d.net/azproj.shtml
Is the data valid?
Log Quality
Some people put lots of attention into their logs, including comments
on the propagation mode (AU, or single or double hop Es).
Others later sent in corrections to entries, correcting them by only a few minutes.
Times of QSOs as reported from duplicate logs
In the 111 logs, there were 125 QSOs reported by both hams.
I looked at the differences in the 2 reported times of the QSO.
For the time of a QSO in logs,
first we need an estimate for the accuracy expected under contest conditions,
then we'll look at the accuracy seen in the logs.
Grid locators as validation of a contact
Hams use 4char gridlocators. This allows you to locate the ham
to within a 100km x 150 km box at 40deg latitude.
If you have errors of this magnitude at both ends of the contact,
you can forget about estimating path length for a 500km contact.
Changing to 6char grid locators reduces the error
by a factor of 24x24 to 4 x 6km,
making it possible to estimate a 500km path length.
So we know that at least 1 of these 203 calls is a
bona-fide away-from-home operation and another has incorrect data,
apparently in the FCC database.
(people who are on the edge of a grid and don't know where they live?
I gave out FM19 for my grid for a while, when I was actually inside FM18 by 100m.)
(people who have moved and they don't want
other hams or the FCC to know where they live, or the FCC hasn't updated their database).
These countries have no Freedom of Information
act and the citizens are required to pay a second time to
obtain information (eg lat/lon for post-codes)
that they've already paid with their taxes for their govt to collect.
(These people: please add your gridlocator info to the callsign databases.)
(KA5AR in EM06 who appeared in 3 logs - forgotten to renew?)
Log Errors
