CT Wishlist 950315 AA1AA

[John L Luigi Giasi]

Dear CT and CT-USERS (please direct replies to me, I will summarize
to the list),

While we are on the "I wish for CT" thread. I must applaud Ken for putting
up with the ham community's combined applause/torture for his efforts in
creating such an extensive program for such a niche market.

This is a compilation of features I wish were in CT, originally written this
document after the 1993 ARRL CW contest. I have deleted the things that have
appeared in CT, but I might have missed one or two. I am at a disadvantage
now, as I do not own a X86 machine with DOS/WIN on it. So all my CT >v8
experience is concentrated in the guest opping and the few hours prior.
(When I am changed with resetting all the IRQs or somesuch.. JOY!)

Translation: Do not take below as gospel about a feature existing or not 
existing.

PLEASE! Buffering packet spots (and band map and..) in a scratch or temp
file on the hard drive would allow retaining of spots if the machine
crashes and a reboot is needed.. (or you need to go in and out of CT
for whatever reason.. I rank this above DOS Shell..)

Network via TCP/IP, especially now that freeware stacks are available.
Or custom interface via ethernet would really solve a whole bunch of 
headaches.  Ethernet IS <$40 per card (single medium).

A DOS shell escape would be valuable: would require (write) locking of
critical files (better than a save then reread when returning, as the 
whole reason for a dos shell is to save time; like to copy .bin to a 
floppy to allow a sync/transfer with a machine that has fallen off
the network.

Allow the spot window to contain more than 10 spots? Scrollable perhaps>>??

Any WWV that goes by on packet should be automagically sucked in and
saved in the notes file. Possibly also automagically log both outgoing and 
incoming talks? Packet conversations.. or maybe track the DX spots you send? 
Or all outgoing packet traffic? Incoming for you only? Why not allow you to 
log all of what is on packet for the entire weekend. How big is it? 200K?

If the .bin file could possible be seperated into a station .bin part 
(the .cfg) a qso-logs .bin part? It could be paired with a "write 
configuration into .cfg file" during <control-enter>> or something??
Hey yeah.. thats the ticket!! This would prevent the inadvertant 
conversion that occurs when multis periodically merging .bins, forcing 
you to go through the extra step of checking configurations for each
station instead of just ct -now.

Furthermore, the CT manual does not list any details as to the passing of
station configuration info with MERGE.EXE,  that should at least be clarified,
if not reworked. (I believe the way it stands now, the manual implies that the
first .bins configuration goes into the new .bin, but from testing it seems
that station #1 configs go in.. even if your do a: MERGE STA2.BIN STA1.BIN !!)

Facility/Key to log non-contest qsos into the notes file. (Some <v8 contest
formats REFUSE to allow you to log an invalid qso, others log it as a 0
pointer, but all require you to try to figure out a dummy exchange for them..
in WW it is a nobrainer.. but when a carribean calls during SSCW. I would
prefer the notes option.. because with the 0 pointers the op has to spend 10
seconds, inventing power or qso number or state or portable/XXX just to get it
to take. And you never know which contest will take it and which ones 
won't...  especially at 0800z.

Facility to have "at first boot up" messages and actions.. (like have ct
automatically enter OPON.. so it forces at multi-op op to enter their call?..
then again, you could take it from the scratch file idea listed above..  or
"Do an alt-t and hit return to clear packet buffers" 

EVEN BETTER: macros that would be executed from the .cfg on boot up. 
Extending macro service to include rulesets like  NO JUMP BAND  for 
single band positions at a multi. This would prevent alt-F4s from 
turfing the singlebander to another band... a stricter setting would 
be NO OTHER BAND, meaning NO JUMP BAND + NO OTHER BAND DISPLAY or
somesuch.. Either way the other bands could be still sucked in and stored in
the scratch file.. just incase the op wanted to remove the restriction..

I would love to be able to log just about everything that the op does 
for later perusal, If there was some way to set (via .cfg best)
things like NOTE WWV (meaning autosuck WWV announcements into .not), NOTE
MYSPOTS, NOTE MYTALKS, NOTE ANNOUNCEMENTS, NOTE GABS etc etc. Or even better,
NOTE.xxx MYSPOTS, NOTE.xxy WWV, NOTE.xxz GABS, NOTE.xxx MYTALKS meaning WWV
went into binname.xxy, gabs into binname.xxz, mytalks and myspots into
binname.xxx... on second thought, fixed extension might be easiest..)

Along with an OPON requirement (like no logging till you give CT the ops 
call) could their be away to .cfg the choices DVP defualts YES/Only/No

YES -> Allow default F-keys and Phonetics for all ops, but
allow personalization if op so desires (by recording them)

Only -> Default values creatable, but prohibit personlized op-based recordings
(space saver, allowing op tracking w/o sucking up disk space for multiple DVP
settings... just rerecord whern you sit down..)

No -> prohibiting the default values, forcing OPON to be entered to use DVP.

There is a need on the summary sheets to list both the operators 
correspondence address and the actual operation location address.
I have submitted a few logs when I was at school, always hand printing 
	"operation from school RPI, in Troy, NY"  
or somesuch, yet more often than not I would be listed under the one-landers.
(and therefore subject to the abuses so many choose to heap upon them)
with the new relaxation of call areas coming from vanity calls... 
it will only get worse...

Could partial check and super check partial also get a unique+one option? 
That would be way cool! Even cooler, the option to add it to the call 
check when you hit spacebar??

Split partial checks and give the choice of allowing either/or/and 
	Worked this test this band (REG and +1)
	Worked this test other band (REG and +1)
	Master.DTA (REG and +1)

END (for now!)
Again comments and though email to me  aa1aa@ummed.edu and i will
summarize to the list in a few.

73 de Luigi
-- 
John L. Luigi Giasi, AA1AA			     jlgiasi@umassmed.ummed.edu
System Programmer/Administrator                                 aa1aa@ummed.edu
Information Resources Division        
Univ. of Mass. Medical Center				         (508) 856-UNIX
Worcester, MA 01655                                         FAX: (508) 856-2440

"Canter & Seigel have wasted more human and computer resources than rtm."
"Lock up your news spool! The CanterSeigel has struck again!!"

--
Submissions:              ct-user@eng.pko.dec.com
Administrative requests:  ct-user-request@eng.pko.dec.com
Problems:                 reisert@eng.pko.dec.com