[MacLoggerContest] MLC compared to MLDX
jbastin at sssnet.com
Wed Feb 16 12:29:08 EST 2005
On Feb 13, 2005, at 1:54 PM, Jonathan G0DVJ wrote:
> Hi all,
> Wanted to just comment on a few things Ted brought to the table
> (thanks Ted).
> My original posting in this thread was intended to be a straight high
> level feature comparison not a list of priorities!
> I do concur with Ted's noting of priorities of some of the points.
> I hope we can have a specific thread about the actual priorities soon
> - perhaps after any other more detailed debates.
> On Feb 12, 2005, at 7:42 pm, Ted Brattstrom wrote:
>>> MLDX good for MLC:
>>> - DX Clusters Pane and functions (with added links to scoring
>>> potential etc. as per separate thread - e.g. identifying new mults
>>> that have been spotted)
>> Note - if implemented, this should be able to be turned off - or made
>> one way... (I'd leave it out, personally :-) )
>> The reason, using any cluster changes you from Single Op to Assisted -
>> there are enough people who are "assisted" who are submitting as
>> Single Op.
It depends on the contest. Some contests put you in a different class
if you use a packet cluster, others just don't allow it. On the other
hand, many contests in which I participate _encourage_ the use of
packet (RTTY contests frequently do this) because they believe it
helps increase participation.
>>> - Map Pane (should concentrate of what has been worked as an
>>> indicator of propagation etc. maybe coloured by band etc. but
>>> secondary nice-
>>> if rather than essential) - also only really of use when HF contest
>>> selected unless we can have loadable more localised maps
I would regard this as a waste of precious display real estate and
processor cycles. Give me a small box showing short path and long path
beam headings, and possibly sunrise and sunset times (in UTC) based on
the prefix currently in the log field.
>> I'd add - the ability to do a quick edit on a QSO - How many times
>> I entered the info quickly, hit return twice, then noticed that I
>> mis-typed the call - Post contest editing is fine - (and important),
>> long as you keep a pad of note paper next to you (which I do)
The ability to edit QSO info at any time, during the QSO, after the QSO
is logged, or after the contest, is a must-have for me.
>>> Memory map of what you have heard/logged per band e.g. on S&P mode)
Since I'm not a "big gun" and so spend a lot of my contest time
S&P'ing, it's nice to have a place where one mouse click will store the
current callsign, frequency, mode, filters, etc. so I can leave it and
with one click a few minutes later immediately come back to it to give
the pileup another try.
>> I don't know how this is implemented - but, the ability to enter a
>> and band that you can come back to... because you didn't get through
>> I envision something like entering the call, trying to call for a
>> or 20 - then hitting a function key to put it over on the side with
>> freq and call... it can be gone back to later.
> I have seen this scratchpad/recall type facility within loggers such
> as SD and it is very useful. Thanks for saying so too!
John E Bastin, K8AJS
jbastin at sssnet.com
More information about the MacLoggerContest