With Bill's continued patience, we have discovered that I had my wires
crossed.
This MicroHAM III interface does not use DTR for PTT as I had believed
but instead uses RTS. I had it exactly backwards and so selecting
"PTT is DTR" in the software of course didn't do the right thing.
"PTT is RTS" works much better. The non-existent schematic for the
interface would have helped me see this light myself :-)
I prefer to use CAT control for as much of this as possible so I will
probably continue to run with my own patched version but I totally
understand that the patch is probably not for general consumption.
That was really not my intention anyway but I sent it to illustrate how
I resolved the problem for myself.
Thanks guys. I appreciate all the effort you put in to make this software
available on Linux.
73 Chris N0JCF
On Sunday (11/23/2014 at 10:50PM +0000), Bill Somerville wrote:
> On 23/11/2014 22:43, Chris Elmquist wrote:
> > Hi Bill,
> Hi Chris,
> >
> > The following fixes it for me completely. I am then able to use CAT
> > for PTT control without DTR being permanently asserted,
> >
> > As I suspected, an assumption was being made at initialization that if DTR
> > and RTS were not forced on, that they would then be off. Not the case.
> > So, this patch deasserts them if they are not chosen to be explicitly
> > asserted at initialization.
> I'm sorry, that patch is not acceptable. It might work for you but it
> will break WSJT-X for anyone who has a serial interface that requires
> full modem control. Again I state, there is no justification for
> breaking the RS-232 protocol by forcing control lines unless the control
> lines are being used exclusively for non-standard purposes.
>
> Please run the test version I sent you and send me the trace log please.
> The code as it stands should work if you set the "PTT Method" to DTR and
> I want to know why it is not working.
> >
> > Thanks for your help. I appreciate it.
> >
> > 73, Chris N0JCF
> 73
> Bill
> G4WJS.
> >
> > % diff -c wsjtx.orig/HamlibTransceiver.cpp wsjtx/HamlibTransceiver.cpp
> > *** wsjtx.orig/HamlibTransceiver.cpp 2014-11-23 16:27:15.315429327 -0600
> > --- wsjtx/HamlibTransceiver.cpp 2014-11-23 16:29:39.899203879 -0600
> > ***************
> > *** 196,205 ****
> > --- 196,213 ----
> > {
> > set_conf ("dtr_state", "ON");
> > }
> > + else
> > + {
> > + set_conf ("dtr_state", "OFF");
> > + }
> > if (TransceiverFactory::handshake_hardware != cat_handshake &&
> > cat_rts_always_on)
> > {
> > set_conf ("rts_state", "ON");
> > }
> > + else
> > + {
> > + set_conf ("rts_state", "OFF");
> > + }
> >
> > switch (ptt_type)
> > {
> >
> >
> > On Sunday (11/23/2014 at 06:27PM +0000), Bill Somerville wrote:
> >> On 23/11/2014 14:45, Chris Elmquist wrote:
> >> Hi Chris,
> >>> On Saturday (11/22/2014 at 07:08PM +0000), Bill Somerville wrote:
> >>>>> I confirm that my PTT method is "CAT", that I am actually invoking the
> >>>>> new version you sent, which the "About" box says,
> >>>> PTT method CAT is definitely not correct if you have DTR connected to
> >>>> PTT on the CAT port.
> >>> OK. This is where there is a difference between how FLDigi is able to
> >>> use hamlib and CAT. With FLDigi, I do use PTT method is CAT and do not
> >>> have this issue. So, there must be a way to get the CAT port open and
> >>> talking without asserting DTR (or RTS).
> >> As I stated before, forcing modem control lines to non-standard states
> >> is undesirable and a violation of the RS-232 protocol. It should only be
> >> done when there is a specific reason for it. For example when a control
> >> signal is to be used for a non-standard purpose. WSJT-X provides for two
> >> non-standard purposes of modem control lines:
> >>
> >> 1) One of DTR or RTS may be used for controlling PTT on a transceiver,
> >> this may be done either on the CAT control serial port or a separate
> >> serial port dedicated to PTT control only. In this case the hamlib rig
> >> initialization routine forces the control line being subverted to an OFF
> >> state just after the serial port is opened.
> >>
> >> 2) One or both of DTR or RTS on the CAT serial port may be forced high
> >> while the serial port is open for CAT control. This option is
> >> specifically for certain interfaces that draw power from the RS-232
> >> control line(s).
> >>> Since I have LEDs on the DTR and RTS signals (labeled as "PTT" and "CW"
> >>> on the MicroHam interface), I can see that when FLDigi is sending CAT
> >>> commands to the radio, these LEDs are NOT lit. So it is able to open
> >>> the CAT port (/dev/ttyUSB0) and have a CAT chat without raising either
> >>> of those two handshake signals.
> >> OK but that is a subversion of the RS-232 protocol for no good reason.
> >> It is not possible to open a serial port on Linux without raising DTR
> >> and RTS, it is possible to force either or both of those control lines
> >> off after opening the port. Fldigi may well be doing that, as does
> >> WSJT-X via hamlib in the two specific cases above.
> >>> Ideally, this is the solution I am looking for.
> >> I see no reason to subvert the RS-232 modem control protocol for this
> >> scenario, the hamlib library already deals with this situation by
> >> forcing either DTR or RTS low when they are assigned to PTT.
> >>> I am not a GUI programmer but from a functionality standpoint, in the
> >>> ws(jt, pr) configuration where there is an ability to force DTR and RTS
> >>> active, it seems that for my situation, having a setting to force them
> >>> inactive would be what I need. You could nail them high or nail them
> >>> low and then the application does not change their state ever if any of
> >>> these "forcers" are set.
> >> Sorry but that is not necessary and I would not propose such a change to
> >> the hamlib developers.
> >>>>> I have also tried PTT method is DTR with this version and I have the
> >>>>> same issue.
> >>>> OK, just to be sure, please confirm you had "PTT Method" set to "DTR"
> >>>> and the "PTT Port" was set to the same COM port as the CAT serial port?
> >>> Yes. Right. I did two experiments, first was to use PTT method is CAT,
> >>> same as what I use for FLDigi and the second experiment was to use PTT
> >>> method is DTR. In both cases, I get the same behavior with the rig
> >>> going into transmit as soon as "wsjtx" is invoked.
> >> Again I state, "PTT Method" of CAT is not going to work if you also have
> >> the DTR (or RTS) modem control line connected to your rigs PTT line.
> >>>>> So, will have to do some digging. Thanks for taking a look. I will
> >>>>> start looking at source myself and see what I can figure out.
> >>>> If the above settings are as stated then I can build a version with some
> >>>> diagnostics that you can try for me to see what is really going on.
> >>> That would be great if you are up for it. I certainly am and am happy
> >>> to run tests and provide feedback.
> >> OK, here is an RPM with diagnostic tracing enabled:
> >>
> >> https://dl.dropboxusercontent.com/u/4192709/wsjtx-1.4.0-rc3.x86_64-r4633.rpm
> >>
> >> install it and run up to the failure (you need to set "PTT Method" to
> >> DTR) then exit. It will create a trace log file called:
> >>
> >> /tmp/WSJT-X_trace.log
> >>
> >> send me the file for analysis please?
> >>> Chris N0JCF
> >> 73
> >> Bill
> >> G4WJS.
> >>
> >> ------------------------------------------------------------------------------
> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> >> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> >> Get technology previously reserved for billion-dollar corporations, FREE
> >> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> wsjt-devel mailing list
> >> wsjt-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Chris Elmquist
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
