Recently I became interested in exploring the use of TRLog Linux for RTTY
contesting. I find TRLog Linux quite enjoyable to use in CW contesting and
wondered if that might also extend to RTTY contesting as well. I realize RTTY
is not the primary focus of TRLog and that Tree implemented only a limited RTTY
feature. But to the extent possible I wanted to see if it could satisfy some
basic capability for me. I wish to report the results of my investigation
to-date on this personal quest.
Running TRLog in RTTY mode assumes the use of an external RTTY
modulator/demodulator. My RTTY hardware modem is the HAL DXP38, which I have
used since 2002. The DXP38 is a multi-mode HF modem that is controlled via
commands sent via an RS-232 serial interface. The command set is extensive but
is well documented in a 62-page HAL interface specification. I really enjoy
the ability of this modem to dig out and decode weak RTTY signals. I use it in
FSK mode with my main rig, the Ten Tec Omni VII.
Interestingly N1MM+ has built-in support for the DXP38 in digital mode and I
have used it in that manner in many RTTY contests over the years. Since
migrating the shack computer to Linux however, I have been searching for a
suitable RTTY logger replacement that can integrate with my trusty DXP38.
In order to use TRLog with the DXP38 I performed the following major steps:
1. Create a suitable LOGCFG.DAT file
2. Initialize the DXP38 for RTTY operation
3. Change the DXP38 serial port data rate to 4800 baud
4. Start TRLog
5. Terminate TRLog
I will describe each of these steps in more detail below.
*** Step 1 ***
I created a test directory for my TRLog RTTY activities and generated the
following config file:
MY CALL = W0ZW
MY NAME = WAYNE
MY STATE = NM
MY GRID = DM65
CONTEST = CQ WW RTTY
DISPLAY MODE = COLOR
RADIO ONE TYPE = rigctld;4532;/dev/ttyS5;16011;57600;38;timeout=500;
SIMULATOR ENABLE = FALSE
DIGITAL MODE ENABLE = TRUE
RTTY PORT = SERIAL /dev/ttyS0
RTTY SEND STRING = <80><0D>
RTTY RECEIVE STRING = <80><0E>
DE ENABLE = FALSE
SHIFT KEY ENABLE = FALSE
LOG FREQUENCY ENABLE = TRUE
BAND MAP ENABLE = FALSE
VISIBLE DUPESHEET = FALSE
The minimum commands required for enabling RTTY in TRLog are (1) DIGITAL MODE
ENABLE and (2) RTTY PORT. I also needed to define RTTY SEND STRING and RTTY
RECEIVE STRING to replace the default strings (CTRL-Y and CTRL-R) with those
required by the DXP38. The latter two commands define the strings which TRLog
sends to the modem to initiate Transmit mode and Receive mode respectively.
More on these commands later.
*** STEP 2 ***
Initializing the DXP38 for RTTY requires sending it about a dozen different
commands each consisting of two or more ASCII characters for functions like:
switch to FSK mode, select Baudot encoding, select the Mark signal high/low,
etc. The DXP38 command set includes non-printable, printable, and extended
ASCII characters. I did not find a facility within TRLog for sending these
modem initialization commands. So instead I sent the required 32 command
characters using a serial terminal window capable of sending and receiving raw
hex data. I used the Linux terminal "moserial" for this purpose. I'm sure
there are other terminal programs which can provide a similar capability. The
DXP38 echos the sent command which indicates it has received and successfully
performed the given command function.
*** STEP 3 ***
TRLog communicates with the external RTTY TNC at a fixed baud rate of 4800 (I
do not know of a way to change this speed). Since the DXP38 serial port
defaults to a power-on speed of 9600, after initializing it in Step 2 I had to
change the serial data rate of the modem to 4800 in order for it to then
communicate with TRLog. Fortunately there is a DXP38 command for selecting the
RS-232 data rate. After issuing the set port rate command I disconnnected
(programatically) the ASCII terminal from the DXP38 serial port. It is now
ready to interface with TRLog.
*** STEP 4 ***
As in normal CW contest mode, TRLog Linux uses an X-Window for presenting the
user interface for RTTY operation. The BigDosTerm class must be used when
invoking xterm as RTTY operation requires the 50-line window in order to
provide an area to display received RTTY characters. Upon entering "trlog" at
the command prompt the familiar TRLog window appears.
Using Alt-M I switched into Digital mode but noticed the Omni VII did not
switch to FSK. It had to change the mode manually even though rig control was
configured. The rig's frequency displayed correctly in TRLog but subsequently
did not update when the VFO was changed. After switching to Digital mode I
could begin to see random receive characters displayed in the receive window
decoded from noise input. The complementary Figs/Ltrs characters appeared in a
smaller window below the main receive window.
I pressed F1 to send the CQ message. The modem switched to Transmit mode and
the CQ message was sent. Because I had enabled Echo Transmit Characters during
the DXP38 set-up I could see the transmitted characters appear in the TRLog
Receive Window. But after the CQ message completed the modem did not return to
Receive mode. I had to press F10 to force it to terminate Transmit mode. Then
it appeared to be in Keyboard mode and any character typed on the keyboard was
sent to the modem. I had to press F10 once or twice to terminate Transmit
mode.
Things got a little confusing after this point. The F1 CQ message failed to
work subsequently. The moment I began to type a call sign in the call sign
window the modem entered Transmit mode and began sending the call I was in the
process of typing. I did not expect this as TRLog does not behave that way in
CW mode. Although I was able to log imaginary QSOs I don't believe my exchange
was ever transmitted. Although TRLog RTTY was partially working, it was
frustrating that I could not control the operation of it as I had expected.
*** STEP 5 ***
Once in RTTY mode TRLog did not terminate normally using Alt-X. It did not
interpret the control string and instead passed it to the modem (I believe). I
was not able to Alt-M out of Digital mode because TRLog kept sending the
keyboard command to the modem. I had to kill power to the DXP38 in order to
leave the Digital mode and finally terminate TRLog with the Alt-X command.
*** CONCLUSION ***
My description of TRLog Linux RTTY operation is not intended in any way to
disparage TRLog. I was actually somewhat encouraged by getting as far as I did
with RTTY operation with TRLog using my DXP38. I used the standard contest CQ
and Exchange messages in this test and have not yet experimented with modifying
them for RTTY operation. I also need to experiment further with the
initialization of the DXP38 as there may be some lurking incompatibility
between it and TRLog.
The RTTY SEND STRING and RTTY RECEIVE STRING commands *appear* to work because
I could initiate and terminate RTTY transmission (sort of) from TRLog. But as
configured the DXP38 will automatically switch to Transmit mode when it
receives any non-command character over the serial interface. I confirmed this
by testing with the serial terminal moserial connected to the DXP38. Is this
behavior incompatible with what TRLog expects? At the same time I need to see
if there is a way to more explicitly command the Transmit function on the
DXP38.
Questions for the Group:
1. Can a control sequence be embedded in a TRLog function key message which is
then passed through to the RTTY TNC? It appears that CW messages accept only a
handful of Control characters which are interpreted by TRLog. What happens
when other Control characters or non-printing characters are included in a
message? Are these ignored and sent to the bit bucket?
2. Does TRLog RTTY operation assume explicit Transmit On/Off control by RTTY
SEND STRING and RTTY RECIEVE STRING? In other words, is the DXP38 default
operation of enabling Transmit upon receiving any non-command character
incompatible with the TRLog RTTY mode operation?
3. Is anyone else in the group using the DXP38 with TRLog for RTTY? How have
you gotten TRLog to work compatibly with the DXP38?
4. Can a new LOGCFG command be created for setting the serial data rate for
the serial connection to the external TNC?
5. Is there an interest in potentially modifying code in order to support
TRLog Linux operation with the DXP38? If so I would be happy to provide user
testing of software changes on my system.
Thanks for reading my rather long posting. Any comments would be greatly
appreciated. Maybe I am the only one using (or wanting to use) TRLog for RTTY.
Or for that matter using the HAL DXP38. Feel free to contact me directly if
so desired but a group thread on the topic might be interesting. I don't
believe there is a thread on the DXP38 in the archives. Thank you for your
thoughts and consideration.
73,
Wayne, W0ZW
w0zw@fastmail.com or w0zw@arrl.net
_______________________________________________
Trlog mailing list
Trlog@contesting.com
http://lists.contesting.com/mailman/listinfo/trlog
|