So - I will try to shed some light on some of this.
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?
I don't think there is a way to embed a message within a function key
message that can be sent to the RTTY port. You can do this to send to a
radio interface port.
Any character that isn't is some kind of command prefix and doesn't map to
a CW character is just ignored.
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?
Well - when it was originally programmed - you had to send a control-T to
the TNC to get it to go into transmit. That is the default for the RTTY
SEND STRING. Control-R is the default for the RTTY RECEIVE STRING. I
guess you can set the send string to nothing (RTTY SEND STRING =). And
perhaps that does what you want.
4. Can a new LOGCFG command be created for setting the serial data rate
for the serial connection to the external TNC?
Yes.
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.
I guess I am not sure what would need to be changed other than #4?
BTW - I have been using TR Log with RTTY on a K4 quite a bit. It's all low
tech. The RTTY transmissions are sent using the KY serial command. You
type in callsigns and exchanges manually using your eyes on the radio. But
it works well enough to do 2BSIQ and run some pretty good rates.
Tree
On Wed, May 8, 2024 at 10:38 AM Wayne, W0ZW <w0zw@fastmail.com> wrote:
> 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
>
_______________________________________________
Trlog mailing list
Trlog@contesting.com
http://lists.contesting.com/mailman/listinfo/trlog
|