Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: QRS software

To: [email protected]
Subject: Re: LF: QRS software
From: "Mike Dennison" <[email protected]>
Date: Wed, 7 Feb 2001 12:03:31 -0000
In-reply-to: <[email protected]>
References: <[email protected]>
Reply-to: [email protected]
Sender: <[email protected]>
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



<Prev in Thread] Current Thread [Next in Thread>