[Trlog] TRLog Linux Operation with HAL DXP38 Modem

[Wayne, W0ZW]

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 at fastmail.com or w0zw at arrl.net