Hi all,
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.
But, I did the build looking for JT65C for the EME group.
So, can one use WSJT-X for JT65C?
73
Alan VK2ZIW
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
