I have printed out my logs, dupe sheet, and multipliers for the
CQ 160 CQ contest. I'm getting ready to make my first ever contest
submission for my first contest attempt. Should I / can I also
submit a disk? Am I missing anything else here? ( I was not a
subscriber to CQ when the complete rules were printed - so I don't
know exactly what they want.) Thanks for any clues here for the
clueless.
73, Kirk WR3O ( WR3O@isd2.tdec.state.tn.us )
>From lvn@fox.gsfc.nasa.gov (Larry Novak) Wed Feb 9 18:21:00 1994
From: lvn@fox.gsfc.nasa.gov (Larry Novak) (Larry Novak)
Subject: CT vs. NA vs. N6TR Summary (LONG)
Message-ID: <9402091821.AA03392@fox.gsfc.nasa.gov>
Last week I posted a question about why people use CT vs. NA vs. N6TR.
Here are the replies I got, mostly unedited except to make them
anonymous. Some of them were posted on the reflector, but I felt that
anyone who email'ed me directly might like to be anonymous. These
comments were reviewed by K1EA and N6TR but not by K8CC (I couln't find
an email address for him either in hams-on-usenet or on the mailing list
for this reflector.
The bottom line seems to be that all three programs are fine programs -
many, many people use at least two of them - lots of people have all
three. Also, W5XD's WriteLog got some good comments if you run Windows.
If you have additional comments, please email me directly - I'm toying
with the idea of a review article for NCJ.
Anyway, here are the comments - enjoy.
Larry, K3TLX
lnovak@cen.com
-----------------------------------------------------------------------
The general answer has been "it's the only show in town". CT has been
around for some years, it supports the major contests, and it has
capabilities that none of the other programs (have) had. NA is picking
up more contests, but it doesn't support large numbers of QSOs. N6TR
is a relative newcomer, but Tree's program may have promise. I've just
ordered it. I've had CT and NA for some years now.
These features distinguish CT from the pack:
1) Large logs (multi-multi stations need this). I don't think NA
supports a log whose size exceeds 10K QSOs or so.
2) Support for networked computers.
3) Rig control for ALL the popular newish transceivers. N6TR has
omitted ICOM support.
4) Integration of packetcluster spots, including filtering spots
thru what you've already worked.
5) Support for the excellent K1EA DVP board (NA and N6TR will
probably add this).
6) Log format supported by a large number of logger's import. Your
K1EA CT log can be easily integrated into several vendors' logs.
7) Rapid response to new features. Ken has been incredibly
responsive to year upon year of request. Not all requests, but many
common requests.
8) Word of mouth. All the top contesters use CT. If you have a
guest op, he probably already knows CT.
9) RAPID check partial and super check partial. This becomes
important when the log size gets quite large.
10) Excellent CW support. N6TR is doing well here, too.
11) Although there are bugs, Ken fixes them, and has on occasion
done a mass mailing prior to a contest because of a serious
data-loss bug.
Some of us would rather have Ken add requested support items rather
than "dig in" and freeze the program to work out the last few bugs.
Most of the bugs have been things we could live with, and over time we
learn to hang on to a few versions of CT. You can usually do the
contest with the program, and fix things later.
-----------------------------------------------------------------------
... (upgrade costs kept going up) and the product didn't seem to be
getting any better.
... [CT] doesn't give you any control over your CW weighting, and N6TR
has done it forever.
... user interface for CT [isn't so good] especially the ... start-up
sequence.
I switched to N6TR and I think it's far superior for a single-op CW
contester. It's much more natural (I don't need to tape pages out of
the manual to remember how to use it, as I did with CT). Now that his
newest version supports the .CTY files, he's fixed the only weakness
(imho) in his program. I've never had a crash or other problem, and
Tree is very responsive to questions and requests.
-----------------------------------------------------------------------
Yeah, CT has bugs...alot for M/S and M/M use. for single op not to
bad. Why did I start with CT? I was not aware of N6TR's package at the
time (almost 4 years ago), and what I got off the internet for NA did
not impress me. For the most part, the bugs that come up have not
affected me and it works quite well and it supports a lot of the
contests that I do. At this time I am not sure of the CT vs NA line of
contests, but my impression is that CT supports more. Both CT and NA
support a DVK on the LPT, N6TR does not. I've heard a lot of good
things about N6TR's package, but for me the lack of support of the DVK
is a factor.
Now, not to put another fly in the ointment, but you left out W5XD's(?)
writelog! I used that for the last NA QSO party since CT did not
support the contest, I did not have NA and N6TR did not support the
DVK. It seemed like a pretty good package. I had some problems getting
it to score correctly, but overall I liked it. I would put it on par
with CT. I have not used writelog for a single op assisted effort yet
so your milage may vary. You can scarf writelog from the
internet...archie on wrtlog60.zip. I forget where I found it. Oops,
forgot, writelog! is a windows app... this might be a BIG factor.
-----------------------------------------------------------------------
I have all three programs, and they all work quite nicely. CT has been
around the longest and is used universally. Log data is easily
transfered to most QSO databases for this reason, but it has two
problems - code speed is limited on the lower end to 22 wpm. It does
not support some of the important contests for contester, such as NA
QSO and Sprint. NA and N6TR Log fill that hole, the former goes down
to 12 wpm and the latter to 5 wpm. The latter also supports the use of
two rigs, but is not very good in transfering data to QSO databases.
We are not talking about a lot of money with this software, if you can
afford to bear the expense of optimizing your station for contest it
makes little sense to constrain yourself on the cost of software. I
would suggest that you get them all, and then you only have to worry
about updates. If one program crashes terminally, then you will have
two others to get you through any of the "big" contests and if you get
to guest op, you won't have to go thru any "learning curve".
-----------------------------------------------------------------------
I think the answer is "whoever gits there fustest with the mostest" ;-)
CT was such a cut above the other programs available at the time that
it became a de facto standard. N6TR's software has a somewhat
different interface design and uses more intelligence. NA is basically
a close variant of CT.
Yes, CT's upgrades tend to have more bugs than would be allowable in
commercial software. However, given the limited resources available to
the programmers (repeat after me...it IS a hobby...) a
less-than-complete testing program is to be expected. That said, I'm
surprised that 8.52 went out with busted "check-partial", if true as
reported...it's kind of a major function.
My personal preference would be to have fewer upgrades with better
testing of each version. The option to beta test new revisions could
then be up to the operator who would be more aware of the risks.
"never buy version 1.0 of anything if you're not willing to do some
troubleshooting"
I see that N6TR version 4.10 accepts .CTY files now...good move. In
this turbulent time, having one standard reference format for
country/zone/etc data is the right way to go.
-----------------------------------------------------------------------
Here is my opinion on why everyone uses CT...
It was first. It works (except when it doesn't). People are used to it.
Getting people to change is like getting someone to switch word processors.
You will use what you are comfortable with even though you know there is
something better on the market.
I hear lots of reasons why people won't use [N6TR]. Most of them fit
into the cateogry of someone who hasn't tried it, picks on one negative
feature and then uses that to be comfortable in their decision. [N6TR]
still won't do summary sheets for example. It's focus has been what
happens during the contest (ie: instead of hitting the INSERT key, hit
RETURN instead and keep your hands in the same place).
-----------------------------------------------------------------------
I am a former die hard user of CT, but I got tired of buying upgrade
after upgrade and finally quit at version 6. [NA] does everything I want
as a single operator, except for handling a couple of contests. It
also has a good dxpedition mode for just logging stations. I have also
used NA in the past for NA QSO party, Sprint, etc. However, I am
evaluating N6TR's package and W5XD's WriteLog. I think when I get the
hang of the N6TR package, I'm going to like it and stick to it. It's
cheaper than CT, too!
It must be very frustrating to want to download a new copy of a
program, and to have it constantly have bugs. I guess CT was (almost)
first, and everyone got used to it.
-----------------------------------------------------------------------
CT generates the greatest number of bug reports largely because it has
the greatest number of users, and they eventually find everything.
Also, it has more function than the others (packet, multi-op, multi-
computer, etc.), and has been around longer. The current release
probably has very few bugs. NA and CT are very easy to use. NA is a
clone of CT. I avoided NA for years because it didn't have the "type
ahead" feature. That's where you don't have to finish typing the
callsign before you start sending the callsign. You can press the
button that sends the callsign and exchange, then finish typing the
rest of the call as long as your ahead of the outgoing CW.
CT supports the K1EA DVP board, which is probably the best on the
market since it can also *record* signals off the air for later
playback.
N6TR's is much more "configuration file" driven than CT. If you are
comfortable with DOS and know how to edit text files, the N6TR program
should work fine. However, it is much harder to learn than either CT
or NA, though you end up using a lot fewer keystrokes to do the same
thing.
If you are a Windows or OS/2 user, you might also want to consider
WriteLog by W5XD. Unlike the rest, you can use it for free, then pay
up after you make 100 QSOs.
I still use CT for most contests. It seems to be the most stable and
the most reliable, notwithstanding the bug redports.
-----------------------------------------------------------------------
I use NA. I do like the CW practice option. Have used CT in the
past. My reason for going NA was because it was the domestic
equivalent to CT. Since then, I've stayed, for no particular reason.
Have never tried the N6TR software. Was going to download it last
weekend, but Tree's bbs was off during the 160 test.
-----------------------------------------------------------------------
This is a reasonable question. Speaking as a Minor-League software
author and a non-user of any of the popular logging programs (ie. an
unbiased observer), here are my answers:
1) ALL software has bugs. The more ambitious a package is, the more
likely it is to have a bug or two. Packages that play it safe usually
don't have all the bells'n whistles that people want. So, the fact
that CT has a burp or two is no big surprise. I'll bet that the other
"big" logging programs have 'em too.
2) People remain loyal to the software that they already know how to
use. The best software pkg. (for you) is the one you're familiar
with. For example, a ba-zillion people still use WordStar even though
it's awful and has been superceded by many better programs. Why?
Because these people already know WordStar, it works for them, and they
have no need/time/desire to climb another learning curve. I can't
blame them.
-----------------------------------------------------------------------
Well Larry, lets see. I paid over $75 for it. I guess I am trying to
get my moneys worth out of it. Just like paying too much for a new car
and driving it until the doors fall off. You would think after 8 major
revisions the S/W would be Bug-free? NOT!!!
it is useful for the small number of contests it supports, however.
-----------------------------------------------------------------------
Right on. I *want* the bells and whistles...the more new ones I have
to play with, the happier I am. Using new gizmos, be they hardware
(antennas, DSPs, headsets, radios, etc.) or software, is what keeps
contesting interesting for me. We recognize the risk in using
the "latest and greatest" version of CT, which is why we ALWAYS have
instantly available an older, known to be reliable, version to which we
can revert if the need arises. And it has occasionally. I *like* the
fact that K1EA has decided to be progressive with his updates, and
accept willingly the risks involved.
After 5 years of experience with CT, I have finally mastered the
keystrokes. I need neither a keyboard template nor reference to the
built in help screen to operate efficiently, and there surely is
benefit in that. From reading the reflector, I know that N6TR's
program has some nifty bells and whistles missing in CT, and I'd like
to play with it some time to see for myself. However, there would have
to be some extremely useful feature to lure me away from CT, since I am
so high on the CT learning curve.
-----------------------------------------------------------------------
[N6TR] does about 35 different contests, about 3 times as many as CT.
Also, it does networking and packet.
-----------------------------------------------------------------------
[CT] works. It works well, for the most part. Obvious bugs like this last
one we're hearing about with super-check-partial are just stupid little
flubs that can be fixed pretty easily. MAJOR bugs -- like not scoring
the contest correctly -- are rare. And it's the default lingua franca
of contesting. Granted, Microsoft is not well liked these days,
either.... but if the new revs get buggier and buggier (unlikely) then
someone new can always try to muscle in with a new package.
Ever think of what CT's doing while you're running 20?. Lots of info
going out lots of ports. Coordinating all the computers and rigs for
multis. All happening real-time while you're sending CW. As Tony
LaRussa said, 'There's a lot of stuff goes on'.
This is off on a tangent, but stop a minute and think. When do people
whine about these bugs? Seems like it's usually just before a contest.
Great timing. Would you buy the latest new version of your
word-processing package and attempt to use it the day before an
important document is due? Or would it be better to install it (of
course, WITHOUT deleting the previous version) and give it a test run
when nothing's happening? You can always go back to an earlier rev of
CT - 6.26 is available as shareware if you don't own any.
MINOR revisions usually remove bugs. MAJOR revs add them. Software
becomes bug-free (after bug fixes, of course) when no new features are
added anymore. And, as Ward N0AX pointed out, there is not an army of
beta testers that debugs every minor rev. Ken makes each available as
quickly as possible -- this is a tradeoff.
Version 8.31 shows 16 contests + DXpedition mode. That's almost all my
operating with exception of NAQP (which NA supports) and the RTTY
contests. I know one of the big pushes for v9 is user-defined contests.
That would end that discussion, right?
Look, K1EA isn't paying me to write this. I just think that overall CT
is a good package which does a lot. The bottom line is still supply and
demand. Write a better one. Sorry, I'll stop flaming.
-----------------------------------------------------------------------
I don't want to waste a lot of bandwidth on this ...
As mentioned by others, CT supports a bewildering array of options:
- Lots of contests
- Lots of modes (single, M/S, M/M, M/2, DXpedition, ... )
- Lots of radios
- Multi-computer networking
- PacketCluster support
- Post-contest stats, QSL's, logs ,...
Here's one not mentioned - For the inexperienced op, it has an
easy-to-learn human interface (the same can be said for NA). When you
run small-time multi's, with operators who don't do CT with every
contest, every weekend, it is important that your ops get up to speed
quickly. Yes, it requires a lot of keystrokes for simple operations,
but that's a small price to pay for simplicity.
I too, get frustrated at the little bugs that are introduced in each
release (and subsequently get fixed). When I am doing single-op, no
packet, and don't care about the radio interface, I long for good old
CT 5.08 - It worked great on my dog 8088 computer, and was relatively
bug-free.
-----------------------------------------------------------------------
Observations have been made along the lines of "after 8 major releases,
one would think that CT would be bug-free by now".
Software development doesn't work that way, as many of us who are
involved in that field have learned.
First, one must recognize that the capabilities of CT in release 8 are
substantially beyond what exists in, say, release 2! Whenever new
features are introduced into software, there are two repercussions:
-- the new feature itself may have bugs
-- the interaction between the software associated with the new
feature and older software may also introduce bugs.
Professionally software houses spend a lot of time in "regression
testing", which is intended to smoke out bugs of the second type.
However, it is both expensive and time-consuming to do (and also
BORING!).
As reflector messages show, people also want ADDITIONAL IMPROVEMENTS in
software packages like CT.
So, the choices are:
a) pay K1EA and others much more money, so they can quit their jobs
and work full-time on making CT perfect in every way. [This is
unrealistic.....]
b) if you prefer NOT to deal with bugs, use versions of software
which are OLDER... e.g., release 7 or 6..... and be satisified
with the capabilities associated therein.
c) if you enjoy exercising the newer features, then use the more
recent releases of code AND be prepared for the associated bugs.
Be prepared to "work around" when some bug arises ... and, give
clear feedback to the author(s) explaining the exact
circumstances which can cause a bug to reliably appear. The
clearer and more precise the bug report, the quicker the fix.
All of us who use CT are part of a cycle: software becomes available,
we try it, and report problems as well as wishes for additional
capabilities.
-----------------------------------------------------------------------
About the time that the profits from CT stopped going to YCCC, and the
price charged for the software started to get on up there, I think the
user should have been able to expect something more nearly approaching
"commercial" quality control. Both CT7 and CT8 have had to be fixed
many times, to fix things that were broken in prior revisions, and not
caught before those revisions went on the street. While I'm not
familiar with the source code, my impression is that there must be a
fair bit of "spaghetti" in there, given that things often get broken
when another (seemingly unrelated) function is fixed. I also question
whether it makes sense to integrate all the code required to support
multi-single and multi-multi operation, instead of making it a separate
module for those who want and need it.
I don't suppose this situation is likely to change , and so will
continue to use CT versions that are at least three or four revs
earlier than the current one, so that bugs -- at least bugs I care
about -- are discovered by someone else. Meanwhile, I have just begun
experimenting with N6TR's software, which is commendably compact and
easy to use on the air, though painfully lacking in post-contest
creature comforts.
-----------------------------------------------------------------------
As another "minor league software developer" watching the CT bug
discussion with some interest, I want to find out what it takes to get
contesters to simply try a different software product. I know from
personal experience that its NOT enough to:
1. advertise in NCJ
2. send you a demo floppy with an SASE requesting your comments (20
of you requested such from me last May and ZERO responded)
3. switch to shareware
4. hand carry copies to some of you
Might it actually be in your best interest to give a little feedback to
the masochistic non-conformist developers once in a while? Otherwise
you'll never have anything better than CT.
-----------------------------------------------------------------------
With the ongoing CT vs everything else thread, I thought I'd add my 2
pence worth.
Various contributors to the reflector have rightly suggested that with
increased complexity and functionality comes increased probibility of
software problems or "bugs". As a commercial developer, the method that
we use to overcome this is three-fold:
(1) Strive for zero-defects in the generation of the source code. This
means applying techniques to write good quality code, first time.
(2) Employ first and second software testing and acceptance teams.
(3) Do regression testing using automated testing tools.
We find it works for us, since our bug-rates are thankfully quite good
(but then we spend an awful lot of pounds achieving this).
For CT, which is now a large and well-featured product, it could be
possible to do the above, but it would take time and money. Ken, K1EA,
has already asked _us_ about details and ideas for CT 9.xx.
As an aside, for the "spaghetti" arguement, from what I've seen of the
source code, it is "tight" and well-optimised.
IMHO, the crux of the matter is that we cannot tell Ken what to write
and how to write it (we have to ask _very_ nicely). But, what we could
do to help Ken and our fellow conteters, is be part of a good beta-test
programme for version 9.xx. One that fully pushes the new (and old)
features to the "edge of the envelope". Is there any mechanism like
this in place already? (which at the moment seems to be, wait for a
major contest and use it!) Or in the end is it really worth going to
these lengths?
-----------------------------------------------------------------------
Gee, exactly what CT (or any new program) was about 5 years ago.....
Now, of course, people will ask for more features, and it'll get buggy,
and people will start complaining about it, so everyone will start
using some new program which is compact and easy to use but lacking in
creature comforts, so, of course, people will ask for more features,
and it'll get buggy, and..... :-)
-----------------------------------------------------------------------
This is unfortunately a Catch-22. The best way to test the software is
to use it during a contest. However, who wants to trust their log to a
program that might have some bugs in it?
With Ken's blessing, I hope to use a beta copy of Version 9 during both
ARRL weekends, both multi-op. However, there's no way we'll find
everything that's broken, and if the software starts to give us
trouble, then it's back to an older version (winning is more
important). I encourage other big guns to ask Ken to do the same.
ARRL DX and WPX SSB are the only really big contests where CT can be
tested before it's released.
-----------------------------------------------------------------------
Over the past couple years of adding features and creating bugs, I have
tried to add features that help verify a new version of the software.
First off, a simulator for the major contests was added allowing you to
work random stations and see how they were logged. The next step was
to make the simulator work itself so you can run up big contest scores
while you are sleeping in bed. A recently added step is to let the
program use a log file from some previous contest as input for
re-working the contest (including the exchanges). This feature allowed
my new version of the program to re-work the CQ WW from TI1C (with 6475
QSOs) in about eight hours. Comparing the final scores between the old
version and the new one with .CTY files is a great way to see how
things are working.
All of these testing procedures are available to the end user so they
can also get confidence in a new version before the contest. Of
course, there are still things that can't really be tested, but there
is a lot more that can still be done before we reach the limit.
Tree N6TR
-----------------------------------------------------------------------
ARRL RTTY on CT would be hard ... lots of typing in the packet window,
but for state QSO parties you probably could work over the .CTY file
for CQP. At least it would dupe check your contacts and give you an
indication of mulitpliers and Q's. The scoring probably would be off
and would need some work. KI3V/7 has a CQP.CTY for out-of-state verus
the in-state .CTY file supplied...not sure but it might be on the
distribution list. This probably is not the real answer, but certainly
better than paper and pencil. I did it one year for the PA contest, but
don't know if I have the .CTY file around anymore.
-----------------------------------------------------------------------
I am not interested in having Ken support every little contest; but I
would really like the ability to configure CT to work with most any old
contest, so my wish-list has user configurability at the top. There
are just too many contests to have them built in to a single program,
what with all the QSO parties, foreign radio association contests like
the recent Belgian one. Even if it did little more than log the qsos,
exchanges and multipliers it would be better than what I have now,
which is a piece of paper.
Even so there will be some contests with rules too weird for a what a
user might be allowed to do, and probably even what I have expressed a
wish looks to be pretty hard. Oh well.
-----------------------------------------------------------------------
A quick plug here for some software I think is great in this respect -
Tree's N6TR LOG has user defined contests. You can modify the scoring
to fit your needs. Not to mention it is cheaper than CT :-)!! I highly
reccommend getting the PD version and running the simulator. You have
to give up the CT mind-set to make the learning curve smaller, but once
you get the hang of it it flows alot more naturally than CT (for me at
least).
-----------------------------------------------------------------------
Sorry, CT CTY files will not work with NA. Send an SASE to LTA for the
latest NA CTY files.
-----------------------------------------------------------------------
I am happy with CT (except for the small bugs) for the major contests,
but I run some of the not-so-major contests like ARRL RTTY, PA QSO
party, NY QSO Party, NH QSO party, QRP contests, and others where CT
sits on the shelf useless because it doesnt support them, and I have no
(user) power to make it understand the smaller contests. I can handle
small bugs, but when a fine piece of equipment (or S/W in this case)
sits on the shelf it is useless!!! Come on CT, let the users support
some of the smaller (and FUN!) contests. If CT doesnt I will search
for something that does.
-----------------------------------------------------------------------
I agree, CT is a good package, but it could be better. This is the
type of input the CT author needs! I hope he is listening.
-----------------------------------------------------------------------
The contests CT supports are based on user demand, and similarity of
rules with already supported contests. CT probably doesn't support the
contests you mention because not enough people have asked for it. You
admit yourself that they're "not-so-major" contests. That very wording
just supports this reasoning - why support those contests if they're
"not-so-major"?
Ken has been thinking of user-defined contests for a while. I have no
idea whether he plans on including them in CT version 9 or not. But
remember, increased functionality often results in increased bugs!
-----------------------------------------------------------------------
>From Danny Eskenazi <0005720561@mcimail.com> Wed Feb 9 16:13:00 1994
From: Danny Eskenazi <0005720561@mcimail.com> (Danny Eskenazi)
Subject: SPRINT WRITE-UP,
Message-ID: <51940209161315/0005720561PK2EM@mcimail.com>
It would be most interesting to know in the SPRINT write-up:
1. Who has the best score running low power. (Power really seems to make a
big difference in how one does, and recognition is due to high scores
done with low power <and QRP, if anyone is nuts enough to do that!..a
friend here in the Vashon area onece did QRP in a NA and has sworn it
off for life!>. Many players are limited by environs to 100W operating and
their performance in a Sprint is so far mostly unrecognized.)
2. Other intersting accomplishments. (usually reserved for soapbox, but
some noteworthy accomplishments never see the light of day, because
most dont want to toot their own horns).
3. We all KNOW how the top end of the listings usually come out. Just like in
the last contest. How many in the top 10 use two radios?. What are the antenna
systems we hear each NA. Inquiring minds want to know.
Most importantly: the NA writeups by K7GM and N6TR are GREAT! Its a thanksless
job doing contest results time after time with little kudos. SO ....
THANKS GUYS! The work of these guys and others, such as score rumor gathering,
(thanks GEO TX) and all the NCJ writers and staff are REALLY APPRECIATED!
(these suggestions are just that, and hopefully taken in that spirit)
73, Danny K7SS (see ya all on SSB this weekend with the LUNATICS)
>From dv736@cleveland.Freenet.Edu (John S. Papay) Wed Feb 9 19:47:09 1994
From: dv736@cleveland.Freenet.Edu (John S. Papay) (John S. Papay)
Subject: [dv736@cleveland.Freenet.Edu: qsl practices]
Message-ID: <9402091947.AA14253@piglet.INS.CWRU.Edu>
================= Begin forwarded message =================
From: dv736@cleveland.Freenet.Edu (John S. Papay)
To: dx@unbc.edu
Subject: qsl practices
There has been a lot of discussion on the hardship of qsl'ing by
contesters and I wanted to give you all a perspective of what it
is like to be a non-contester participating in a contest for the
purpose of confirming states etc.
I support the sase concept. If you want a card, then send an
sase. If someone sends a card to me, my personal view is that
I will qsl no matter what. If a postcard is sent, I return a
postcard. If a card is sent in an envelope, I return an
envelope. But then I am not in a rare place, so it's easy for
me to say.
There are some contesters that are very well known who just don't
seem to have time to qsl. I worked a guy in Georgia in the 160
phone contest and sent an sase with no reply. Then I hear him
the same contest the following year. I work him and ask him
where is my qsl card from last year. He's working on it he
says. There was a certain contester in Michigan who took a
year to reply to an sase and one similar in MA who also took
a year. These guys are big time contesters who don't just
operate for one contest a year. They obviously have time to
put up big antennas and work on their stations all year long
while the pile of cards is over in the corner.
It only takes a few minutes to do a card with an sase. So if
you want to be a big time contester and get your picture on
the front of a magazine because you
are good at it, work on your qsl system or get a manager if
you can't handle it. If contesters only worked contesters,
you wouldn't have very big scores. A non-contester only
works you for fun or for a qsl card.
so lets work on it.....qsl????
--
John S. Papay K8YSE
dv736@cleveland.freenet.edu
I really should have put this on the contest reflector in the
first place instead of the dx reflector. My apologies to those
who are getting it twice.
--
John S. Papay K8YSE
dv736@cleveland.freenet.edu
>From lvn@fox.gsfc.nasa.gov (Larry Novak) Wed Feb 9 20:34:25 1994
From: lvn@fox.gsfc.nasa.gov (Larry Novak) (Larry Novak)
Subject: LU4AA vs. 3Y0PI
Message-ID: <9402092034.AA04138@fox.gsfc.nasa.gov>
I saw at least three spots yesterday afternoon from people who thought
they worked 3Y0PI on 21.025. One of them even commented on what a
good cw op they had! Unfortunately, they weren't listening because
the station they worked was id'ing after every QSO -- and the id
was LU4AA. Maybe people just stopped listening for anything but
their call since 3Y0PI id's so infrequently, but there are going
to be a lot on "not in logs" because the pileup on LU4AA was huge.
I guess he was wondering why he was so popular!
C'est la vie (or la guerre)
Larry, K3TLX
>From Trey Garlough <GARLOUGH@TGV.COM> Wed Feb 9 21:14:46 1994
From: Trey Garlough <GARLOUGH@TGV.COM> (Trey Garlough)
Subject: LU4AA vs. 3Y0PI
Message-ID: <760828486.524018.GARLOUGH@TGV.COM>
> I saw at least three spots yesterday afternoon from people who thought
> they worked 3Y0PI on 21.025.
This is probably a more appropriate topic for the DX@UNBC.EDU mailing
list than for CQ-Contest. Please post follow-ups to the other list.
--Trey, WN4KKN/6
>From Jim Reisert AD1C 09-Feb-1994 1545 <reisert@wrksys.enet.dec.com> Wed Feb
> 9 20:41:34 1994
From: Jim Reisert AD1C 09-Feb-1994 1545 <reisert@wrksys.enet.dec.com> (Jim
Reisert AD1C 09-Feb-1994 1545)
Subject: CT-USER mailing list is now available!
Message-ID: <9402092041.AA06727@us1rmc.bb.dec.com>
I have set up a reflector (similar to CQ-CONTEST) for users of K1EA's
contest logging software, CT. If you are interested in joining the list,
send a message to "MajorDomo@sttng.mlo.dec.com" and put this text in the
*BODY* of your mail message:
info ct-user
It will send you the Frequently Asked Questions (FAQ) list, which will tell
you how to subscribe.
73 - Jim AD1C
|