On 24/11/2014 05:48, Alan VK2ZIW wrote:
> Hi all,
Hi Alan,

It helps if you can start a new mail thread for a new subject. Adding 
unrelated questions to existing threads can cause your request to be 
missed by those of us using thread mail readers.
> O/S: Fedora release 20 (Heisenbug) x86_64
> Hardware: ASRock QC5000-ITX AMD Kabini & GPU
>
>
> jt9.f90:(.text+0x9b1): undefined reference to `export_wisdom_'
> jt9.f90:(.text+0x185e): undefined reference to `import_wisdom_'
>
> Because these functions are "export_wisdon_to_file" and
> "import_wisdom_from_file" in "f77_wisdom.f90".
>
> I changed these in "
> f77_wisdom.f90" and the build completes and wsjtx runs.
That sounds as if you used make and qmake, there are probably some 
updates to be made to those make and project files. The preferred build 
tool for WSJT-X is CMake.
>
> But, I did the build looking for JT65C for the EME group.
> So, can one use WSJT-X for JT65C?
WSJT-X currently only supports JT65A and JT9 for use on the HF/MF/LF 
bands. You probably need WSJT which supports most of the "JT" modes used 
for EME/MS/Iono and other weak signal VHF and above operation.
>
> 73
>
> Alan VK2ZIW
73
Bill
G4WJS.
>
>
>
> On Mon, 24 Nov 2014 01:39:20 +0000, Bill Somerville wrote
>> On 24/11/2014 01:31, Chris Elmquist wrote:
>>
>> Hi Chris,
>>> 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 :-)
>> No problem, at least a hamlib bug was found in the process and the
>> diagnostics have been improved as well.
>>> 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.
>> One point worth considering; I prefer hard wired PTT control of CAT,
>> all else being equal, the reason being that it is far more likely
>> that a CAT command gets corrupted when transmitting than the state
>> of a serial control line. Of course I would not recommend any set up
>> that is not immune to RFI but many users have limited aerial systems
>> that can be prone to high levels of RF in the shack.
>>> Thanks guys.  I appreciate all the effort you put in to make this software
>>> available on Linux.
>> Thanks for the help testing.
>>> 73 Chris N0JCF
>> 73
>> Bill
>> G4WJS.
>>> 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
>> ------------------------------------------------------------------------------
>> 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
>
> Alan
>
> Man's greatest waste of time: Worshipping the wrong God.
> Consider Jesus.
> ---------------------------------------------------------------------------
> Alan Beard               Unix Support Technician from 1984 to today
> 70 Wedmore Rd.           Sun Solaris, AIX, HP/UX, Linux, SCO OpenServer 5.0.X
> Emu Heights N.S.W. 2750  Routers, terminal servers, printers, terminals etc..
> +61 2 47353013 (h)       Support Programming, shell scripting, "C", assembler
> 0414 353013 (mobile)     After uni, electr
>
>
> ------------------------------------------------------------------------------
> 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

Reply via email to