[MacLoggerContest] MLC compared to MLDX

[John Bastin]

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 
>> have
>> I entered the info quickly, hit return twice, then noticed that I
>> mis-typed the call - Post contest editing is fine - (and important), 
>> as
>> 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 
>> call
>> 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 
>> minute
>> or 20 - then hitting a function key to put it over on the side with 
>> the
>> 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!

73,

John E Bastin, K8AJS
jbastin at sssnet.com
http://www.qsl.net/k8ajs/