TRLog
[Top] [All Lists]

Re: [Trlog] Trlog Digest, Vol 246, Issue 2

To: trlog@contesting.com
Subject: Re: [Trlog] Trlog Digest, Vol 246, Issue 2
From: "Wayne, W0ZW" <w0zw@fastmail.com>
Date: Wed, 08 May 2024 14:30:15 -0600
List-post: <mailto:trlog@contesting.com>
Tree - Thanks so much for the clarifications.

Besides a new LOGCFG command for the RTTY PORT speed (thanks!), I don't know 
what other program changes to request yet (if any).   At this point I am not 
able to explain why TRLog behaved the way it did when I hooked it up to my 
DXP38 external modem.   But I will investigate further.

An example of behavior by my modem that TRLog may not be expecting is that the 
DXP38 sends "Stream Switch Status Reports" to the application program to 
indicate whether data characters on the serial line are received characters or 
echoed transmit characters.  This is so the application can process them 
differently if so desired (N1MM+ displays transmit characters in a different 
color, for example).  These status characters are 0x8030 (indicating rx chars) 
and 0x8031 (indicating echoed tx chars).  I don't know what TRLog does 
programatically when it encounters non-printable characters in the RTTY Port 
data stream.  Does that somehow mess with the X-window terminal used in the 
TRLog Linux version?  I don't know the answer to that.  But the echoed Transmit 
characters appeared to display OK in the TRLog window so maybe this is not an 
issue. 

Another question is why executing the F1 CQ message did not cause the DXP38 to 
return to Receive mode at the end of the message (described in my original 
posting).  The RTTY RECEIVE STRING was set correctly yet the modem did not 
return to receive mode.  I'm not expecting you to know the answer to this but 
it is another piece of the puzzle.  Obviously RTTY works for you and others so 
I just need to figure out what is different about the behavior by the DXP38 
from other TNCs.  

As I said, I am encouraged by the progress I have made so far.  I am willing to 
dig further to get it to work (I must really like my HAL modem).   Any ideas or 
suggestions in the mean time would be very welcomed.

73,
Wayne, W0ZW

> Message: 2
> Date: Wed, 8 May 2024 11:28:54 -0700
> From: Tree <tree@kkn.net>
> To: "Wayne, W0ZW" <w0zw@fastmail.com>
> Cc: trlog@contesting.com
> Subject: Re: [Trlog] TRLog Linux Operation with HAL DXP38 Modem
> Message-ID:
>       <CAKF9HhbmmmkTg_JLo_48ONve0nDZ4sm49py5vyxFXnOiUFnNFA@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
>
>
>

> End of Trlog Digest, Vol 246, Issue 2
> *************************************

_______________________________________________
Trlog mailing list
Trlog@contesting.com
http://lists.contesting.com/mailman/listinfo/trlog

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [Trlog] Trlog Digest, Vol 246, Issue 2, Wayne, W0ZW <=