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
