Content-Transfer-Encoding: 8bit
Message-ID: <3.0.1.16.20010207112258.2c8f0b36@mail.cc.kuleuven.ac.be>
Date: Wed, 07 Feb 2001 11:22:58
To: rsgb_lf_group@blacksheep.org
From: "Rik Strobbe" <rik.strobbe@fys.kuleuven.ac.be>
Subject: LF: QRS software
In-reply-to: <3A7EDD33.5AECC6BB@bellatlantic.net>
References: <3A7EC25C.23669.13BB591@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
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