[Trlog] Trlog Digest, Vol 246, Issue 2

[Wayne, W0ZW]

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 at kkn.net>
> To: "Wayne, W0ZW" <w0zw at fastmail.com>
> Cc: trlog at contesting.com
> Subject: Re: [Trlog] TRLog Linux Operation with HAL DXP38 Modem
> Message-ID:
> 	<CAKF9HhbmmmkTg_JLo_48ONve0nDZ4sm49py5vyxFXnOiUFnNFA at 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
> *************************************