[MacLoggerContest] 1st draft at consensus of top 5 MLC feature list priorities

[Don Agro]

Hi Jack,

On 13-Mar-05, at 12:24 AM, Jack Brindle wrote:

> We seem to be making feature selections by the perceived difficulty in 
> implementation.

There have been some comments concerning features already existing in 
MLDX etc. but this is not the way we should be selecting features.

> Many might be amazed that some features, such as voice playback are 
> very easy to implement, and others far more difficult. I would suggest 
> that implementation difficulty might be scored by the developers, then 
> a fresh look at priority be made. Examples in my discussion below.

It's a bit early for that. At this point, I think only the impossible 
should be ruled out - for example reverse engineering closed file and 
packet formats and standards is just not reasonable (or dependable) for 
the initial release - but 'difficult' is not a problem.

> Cabrillo is not optional. It is required for submission of contest 
> entries for pretty much all major contests on this side of the pond. 
> Without it a contest program is useless. I would put ADIF in the 
> optional category, but it may be easy to drop it in from some other 
> code piece. Developer?

Cabrillo and ADIF are open standards and well documented - and well 
supported within MLDX.

>> INITIAL BELL & WHISTLE:
>> - A contest CW memory keyer
>
> There are two ways to do this. The first is to output a CW digital 
> open collector/drain signal to key rigs. This requires rather precise 
> timing within the Mac, something not very easy in a non-real time 
> environment. Still, it can be done. Perhaps an existing drop-in 
> facility can be used?

This is already done in MacLoggerDX - and Unix is Real Time within 
reason - not really a problem.
At 32 wpm and assuming an average of 48 dit durations in a word a 'dit' 
would be 1250 / 32 = 39.0625 milliseconds - not a difficult interval to 
handle.

> The second method is to make use of the ASCII CW facility in many 
> contemporary rigs. I would strongly urge the support of this - text to 
> be transmitted is simply sent out the RS-232 port to the rig for it to 
> encode and transmit.

Not all rigs support this and all in a different way - driver dependent 
and impossible to fix if it's 'broken' in the radio. Now that is a 
whole other discussion - what is an appropriate contest rig ? Do we 
support them all ?

> An alternative to this is to adopt one or more of the various keyer 
> systems, such as that from K1EL, which also provide the same service. 
> Probably both should be implemented in the long run.

Within the MacLoggerDX user community - based on what I am hearing from 
those that are using CW keying - most are using the software CW within 
MLDX and the microHAM interfaces to their rigs - but these are 
implementation details and to some extend driver dependent.

But we are getting ahead of ourselves - at this stage we just want to 
know if CW and/or voice keying are essential in most contests.

> I would also move the SSB audio play system to this level. It is 
> amazingly easy to implement. Creation of the audio files can be done 
> with external applications such as Peak LE or the freeware Audacity. I 
> would NOT add audio recording at this time unless the author 
> understands the part of the QuickTime system. When audio recording is 
> added, it should allow for the creation of contest exchange files as 
> well as recording of contest audio from the radio(s).

Once again this is a much lower level implementation level issue - the 
real question at this stage is how important is audio 
recording/playback in a contest situation ? The playback/keying part is 
already in MacLoggerDX and serves as an example for discussion.

If the consensus is that voice and CW keyers are essential, then at a 
later time it might be useful to evaluate what is already in MLDX to 
see if it is appropriate or not for the contest situation. I would 
think that this would be a 2 part discussion - low level functionality 
and UI/usability.

I realize that you are not a MLDX user Jack, and this is not a problem 
- but you might want to take a look at the online documentation for the 
purpose of discussion... 
<http://www.dogparksoftware.com/MacLoggerDX/MacLoggerDX_Manual.html>

Here is the page on the MacLoggerDX keyers...

<http://www.dogparksoftware.com/MacLoggerDX/Manual/Pages/cwkeyer.html>

There will be some code re-use between MLDX and MLC - but not a lot 
since MLDX is PowerPlant-Carbon and MLC will be XCode Cocoa-Objective 
C.



73 Don Agro VE3VRW

D o g   P a r k   S o f t w a r e   L t d .

email: dagro at dogparksoftware.com
   www: http://www.dogparksoftware.com
     iChat AV:dogpark at mac.com