From: "Mike Dennison" <mike.dennison@rsgb.org.uk>
To: rsgb_lf_group@blacksheep.org
Date: Wed, 7 Feb 2001 12:03:31 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: LF: QRS software
Message-ID: <3A813993.4411.9F9CDD@localhost>
In-reply-to: <3.0.1.16.20010207112258.2c8f0b36@mail.cc.kuleuven.ac.be>
References: <3A7EDD33.5AECC6BB@bellatlantic.net>
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

> At 12:04 5/02/01 -0500, N4ICK wrote:
> >The only limitation would be the ON7YD QRS program: does it allow us
> >to go slower? (I cannot remember its parameters, and the actual
> >software is at the transmitter site, of course, not here in my shack,
> >so I cannot check now how slow it will go).
> 
> So far QRS allows up to 65 seconds 'element length'. Reason for this
> is that the dotlength is calculated in multiples of 0.1 second and are
> handled as WORD values (2 byte). At the time I released this version 3
> sec./dot was common practice with an odd one using 10 sec./dot, so the
> 65 seconds limit seemed fairly save. Laurie pointed out this problem
> to me a few days ago and I made a 'quick fix' that now allows up to 10
> minutes dot length. Whoever is interested in transmitting at very slow
> speed can request a copy of the new version via e-mail.
> 
> In the near future I intend to release a new revision of QRS, giving
> more facilities for very long dotlengths.
> 
> Following 'features' are planned :
> 
> - although meanwhile DELPHI 5 is available I will stick to DELPHI 1 as
> this allows the software to run under WIN3.1 and upward. This will
> allow to use old PC's (even a 386) for beaconing etc ...
> 
> - timing will be more accurate. So far I used the 'internal timer' of
> DELPHI that has the advantage of 100% 'no interference' with other
> software but is not so accurate (few % error). At 3 sec./dot this
> error is neglectible but at 60 sec./dot it can be noticed. Meanwhile I
> managed to work arround this problem and get a accurate timing without
> interference with other software.
> 
> - fast CW facilities will be abandoned, except for the possibility to
> have a fast CW text at the begin and end of your QRSS/DFCW
> transmission
> 
> - dot lengths will be given in seconds instead of milliseconds
> (entering 60000 for 1 minute dotlength is not practical)
> 
> - maximum dot length will be 86400 seconds (= 1 day), this should
> satisfy the needs for even the slowest QRSS (for the time being)
> 
> - possibility to 'synchronize' transmissions to the PC-clock (eg.
> allow to transmit at 60 sec./dot where each dot starts exactly at the
> beginning of the minute).
> 
> In case you have a 'wishlist' of other features that could be usefull,
> please let me know ASAP. If possible I will try to implement them.
> 
> 73, Rik  ON7YD
> 
> 


Mike