Ok, since some people showed interest in the CWReader program, I now have
completed it (wrote the document, or actually just completed it).
I doubt it's OK to send a binary-file to the reflector, so if you want
CWReader, send me a request. I will then mail you an uuencode'd and pkzip'd
version containing CWR.COM, CWR.DOC and CWRCONF.EXE. Please mention if
you are not able to pkunzip, in which case I can send the files just
uuencode'd.
For now: FORGET the section marked 'registration' in the document! As of
now, you are NOT required to register CWReader in any way; I just wrote the
section in case there will sometimes be greater interest for CWReader.
All who get CWReader from me will be kinda beta-testers; I have never used
my CWReader in a contest! All input from you is more than welcome.
Included here is a part of the document, which should tell you quite clearly
what CWReader can do and what it can't.
------------------------ From CWR.DOC, start ---------------------------
THE 'INTELLIGENCE' OF CWREADER
This section explains how CWReader interprets some characters,
words, spacings and combinations of them. You should know this
information in order to send CW in the most optimum way for
CWReader. In the discussion below, the contest-program is assumed
to be CT. (note that all of these features can be enabled and
disabled with CWRCONF)
Receiving a 599-report:
When you send a station's call with your paddle, it is copied
to the CT's call-field. Then, after the call, you immediately
send the report, "5NN", at which point CWReader wakes up. It
deletes the characters "5NN" after the call from the call-
field, moves the cursor to the number-field and commands CT
to send the exchange-number.
Sometimes you may send 599, by mistake, as "HNN". But don't
worry, CWReader detects this as well and actually handles
"HNN" just like it would "5NN".
CWReader's 599-detection is not always active. You can, for
example, work station VK5NN not having to worry about
CWReader thinking the "5NN" part of the call was a report.
The logic CWReader uses is simple: begin monitoring for 599
after at least one number and at least one letter have been
received. However, if the number is the first character of
the call, begin counting from the second character. There is
one exception: when a question mark is received, 599-
detection is immediately enabled. This makes sending the
following call impossible: "V?5NN", so you should probably
use question marks only at the end of the partial call.
After receiving 599, there is a little pause in copying
characters from the keyer. This pause is there so that you
can manually send the exchange number, if you, for example,
prefer to use your keyer's serial-number logic instead of
CT's. Be careful, however, when you make a mistake in sending
the number and keep a too long pause before sending an error
character: the whole log-line, including the call, will be
deleted!
Receiving TU:
Imagine you have just finished entering the number the other
station gave you and are ready to confirm the QSO. Provided
you do not use the keyboard to do this, you will send
something like "TU OH3LIM" with your paddle (or perhaps
simply "TU", if the pileup is heavy). CWReader can detect
both of these cases and take actions accordingly.
Let's begin with the reception of a simple "TU". After
receiving this character combination and a resonably long
space, CWRreader deletes the TU from the log and confirms the
QSO like you would do it with ENTER. The delay after TU is
necessary, because otherwise calls like N2NTU would be
seriously mistaken. For the same reason there must also be a
resonably long space BEFORE receiving the TU or otherwise it
will not be acted upon.
If you send your own call (set with CWRCONF) after the "TU",
CWReader doesn't even print the call on the screen: if it
appears to be your call, the action is same as TU's alone
(without the delay at the end, however), but if it is not,
the call is displayed and no actions are taken. For examplw3e,
with a call like "N2TUO" (and if your call began with an
"O"), the last "O" would not display immediately when you
send it, but later after the 5 of 599 has been sent. When the
TU is followed by your call, there need not be the space
neither in the beginning nor in the end of the sequence.
TU is sometimes given without the space between T and U,
making it effectively X. From CWReader's point of view, the
TU can be given as X and all actions apply to it as well.
However, it's not suggested that you make it a habit giving
TU as X, but just in the case it happens to slip from your
paddle...
Skipping CQ-calls
Although you should use CT's F1-key to send CQ-calls, it may
sometimes be necessary to send a CQ with the paddle. When
CWReader detects the sequence "TEST", it erases it from the
screen and does not write anything you send afterwards on the
screen. When CWReader detects another "TEST"-sequence, it
resumes normal operation and write everything following the
sequence on the screen. Be sure to end your CQ's in "TEST"
(or as set with CWRCONF), because otherwise you'll
effectively disable CWReader!
If you make a mistake in sending the CQ and send an error-
character (as described in a later section), CWReader's TEST-
mode is reset. That is, all you send after the error-
character, will be put on the screen. Note, that the error-
character causes its normal action to be executed (normally
the deletion of the current field)!
Entering calls partially by keyboard and partially by paddle
Say you are not a very fast typewriter. When a station is
calling you, you can only enter a few characters of his call.
Say there is EI5ISF calling you and you enter EI5 after which
you must hurry to your paddle to send, NOT the rest of the
call, but the full callsign, of course. CWReader starts
putting the characters on the screen when you have got past
the characters that are already on the screen. If you make a
mistake, however, like sending ES5 instead of EI5, the
mistaken character will be put on the screen where the cursor
points! That ES5 would make it look like EI5S on the screen,
then. In this case, the best action is probably to send an
error-character (and get the whole call wiped out), as
discussed in the next section.
Whenever you press a key on the keyboard, CWReader resets its
'current callsign position'-variable, making it impossible
for you to first enter EI5 by keyboard, then send EI from the
paddle, then enter I (or IS or ISF) by keyboard and lastly
send 5ISF from the paddle. That is, you should not enter more
of the callsign AFTER you have begun sending with your
paddle! Just let CWReader read the callsign directly from the
paddle for you.
Receiving error-characters
CWReader knows three kinds of error-codes: the standard
error-character (...-.), a bunch of dots (........) and a few
dots sent far-spaced. The error-character and bunch of dots
are easy ones; just make sure you send at least 6 dots, since
5 would result in receiving the number '5'.
A minimum of three far-spaced dots is needed to interpret it
as an error-code. There is no maximum, but when you keep a
'long' pause (compared to the spaces between other dots), the
error-code is considered ended. Note that it's impossible to
enter a call like JJ0EEE from the paddle! However, a call
like EA1XX is possible to enter, but you must remember to
keep a long enough pause between the last error-dit and the
callsign's "E". Trying it out is the best way to make your
timing correct!
Remember, that when an error-character is sent, the WHOLE
log-line is emptied. This corresponds the keyboard-entered
Alt-F8 (can be changed with CWRCONF, though). Make sure you
have the stations callsign firmly in your head when having to
issue an error-character!
------------------------- From CWR.DOC, end ----------------------------
--
Mikko Noromaa -- Amateur radio callsign: OH3LIM
email: Mikko.Noromaa@hut.fi -- Pkt addr: OH3LIM@OH3RBA.#HML.FIN.EU
|