Re: [wsjt-devel] Possible feature request, time skew notification?

[John Nogatch via wsjt-devel]

> 2. In outdoor setting (sounds like it is more applicable) you can get a 
> trusted time from a GPS receiver.

I had some experience with this recently, using this USB GPS
https://www.ebay.com/itm/284227196983
with GPS2time 
https://vk4adc.com/web/index.php/software-projects/55-vk4adc-utils/181-gps2time
on a Win10 laptop.

We got this to work well, but there were some problems:
1. An older USB GPS works on linux, but because it has the Prolific
chip, it does not work on Win10.
2. When the GPS was unplugged, the RF noise level dropped several S-units.
 This was mentioned on the VK4ADC page, and the GPS does not need
to remain connected after the time has been set.
3. Several turns around a ferrite bead on the GPS cable reduced the
noise, but the GPS cable is only 2m long.
4. A USB extender cable was needed so that the GPS could be outside,
on the other side of the wall.
5. GPS2time has a checkbox for Daylight Savings Time, which must be
checked appropriately.
6. GPS2time can set the grid square before starting wsjtx, which would
be useful for a rover station.

-John AC6SL


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problems building on MacOS X 11.1 Intel

[Alex Lelievre via wsjt-devel]

Hi Bill,

Thanks for the quick response.  I tried to roll back to pre-v8 gfortran, 
couldn’t find v7 pre-built and didn’t want to go down that rabbit hole of 
building it.  
I tried again with gfortran 6.3.0 and got the same error however-
[ 17%] Building Fortran object CMakeFiles/wsjt_fort_omp.dir/lib/packjt.f90.o
gfortran: error: unrecognized command line option ‘-Xclang’

grey>:/Users/alex/wsjtx-2.5.0-rc1$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin16/6.3.0/lto-wrapper
Target: x86_64-apple-darwin16
Configured with: ../gcc-6.3.0/configure --prefix=/usr/local/gfortran 
--enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin16 
--with-gmp=/Users/fx/devel/gcc/deps-static/x86_64 
--with-mpfr=/Users/fx/devel/gcc/deps-static/x86_64 
--with-mpc=/Users/fx/devel/gcc/deps-static/x86_64 
--with-isl=/Users/fx/devel/gcc/deps-static/x86_64
Thread model: posix
gcc version 6.3.0 (GCC) 

This might be a stupid question but is there a build-guide for MacOS X?  I feel 
like I’m missing something simple here unless there is only one person in the 
world who can build the Mac code.  :)

In the meantime if I can motivate myself to enter the hell that is CMake, I 
will see if I can suppress this option from the gfortran make.  
It’s been awhile since I’ve had the misfortune of working with CMake.  ;-)  A 
necessary evil for truly cross platform work. 

Thanks again for your help,
alex K6LOT


> On Jul 18, 2021, at 11:25 AM, Bill Somerville via wsjt-devel 
>  wrote:
> 
> Hi Alex,
> 
> thanks for that. We currently do not recommend using a gfortran version >= 8 
> on macOS, this is due to some known issues with our code for which fixes are 
> a WIP. With gfortran v7 that compiler diagnostic message is only a warning, 
> which is how our build gets passed it. The passing of -Xclang to the Fortran 
> compiler is not done directly by us, I guess it is a CMake issue which we 
> have not been too concerned about yet.
> 
> 73
> Bill
> G4WJS.
> 
> On 18/07/2021 19:18, Alex Lelievre via wsjt-devel wrote:
>> Hi Bill,
>> 
>> Thanks for getting back to me.  This is what I get:
>> 
>> grey>:/Users/alex$ which gfortran
>> /usr/local/bin/gfortran
>> grey>:/Users/alex$ gfortran -v
>> Using built-in specs.
>> COLLECT_GCC=gfortran
>> COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.1.0_1/libexec/gcc/x86_64-apple-darwin20/11.1.0/lto-wrapper
>> Target: x86_64-apple-darwin20
>> Configured with: ../configure --prefix=/usr/local/Cellar/gcc/11.1.0_1 
>> --libdir=/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11 --disable-nls 
>> --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran,d 
>> --program-suffix=-11 --with-gmp=/usr/local/opt/gmp 
>> --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc 
>> --with-isl=/usr/local/opt/isl --with-zstd=/usr/local/opt/zstd 
>> --with-pkgversion='Homebrew GCC 11.1.0_1' 
>> --with-bugurl=https://github.com/Homebrew/homebrew-core/issues 
>>  --enable-libphobos 
>> --build=x86_64-apple-darwin20 --with-system-zlib --disable-multilib 
>> --without-build-config --with-native-system-header-dir=/usr/include 
>> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
>> Thread model: posix
>> Supported LTO compression algorithms: zlib zstd
>> gcc version 11.1.0 (Homebrew GCC 11.1.0_1) 
>> 
>> alex K6LOT
>> 
>>> On Jul 17, 2021, at 11:51 PM, Bill Somerville via wsjt-devel 
>>> >> > wrote:
>>> 
>>> On 18/07/2021 03:31, Alex Lelievre via wsjt-devel wrote:
 Hi there,
 
 I’m running into an error in the fortran portion of the WSJT-X project on 
 MacOS X.   I’m reaching out to see if anyone has bumped into this:
 
 [ 17%] Built target record_time_signal
 [ 17%] Automatic MOC for target fort_qt
 [ 17%] Built target fort_qt_autogen
 [ 17%] Built target fort_qt
 [ 17%] Building Fortran object 
 CMakeFiles/wsjt_fort_omp.dir/lib/packjt.f90.o
 gfortran: error: unrecognized command-line option '-Xclang'
 make[5]: *** [CMakeFiles/wsjt_fort_omp.dir/lib/packjt.f90.o] Error 1
 make[4]: *** [CMakeFiles/wsjt_fort_omp.dir/all] Error 2
 make[3]: *** [all] Error 2
 make[2]: *** [wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
 make[1]: *** [CMakeFiles/wsjtx-build.dir/all] Error 2
 make: *** [all] Error 2
  
 I’m not sure why -Xclang is being passed to the fortran compiler.  Calling 
 gfortran with a test file and -Xclang option generates the same error.
 I’m wondering if I misconfigured the project or perhaps I’m using the 
 wrong tool chain?
 
 Any help would be appreciated,
 alex K6LOT
 
>>> Hi Alex,
>>> 
>>> which Fortran compiler are you using and what version?
>>> 
>>> 73
>>> Bill
>>> G4WJS.
>>> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> 

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Bill Frantz via wsjt-devel]

On 7/18/21 at 3:56 PM, wsjt-devel@lists.sourceforge.net (Tom via 
wsjt-devel) wrote:


Of course this is solved by putting in Run as Administrator in 
the shortcut for WSJT. But the question is why all of a sudden?


And, of course, running general normal applications as 
Administrator flies in the face of every sane computer security policy.


73 Bill AE6JV

-
Bill Frantz| Government is not reason, it is not 
eloquence, it is force; like
408-348-7900   | a fire, a troublesome servant and a fearful 
master. Never for a
www.pwpconsult.com | moment should it be left to irresponsible 
action. Geo Washington




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Possible bug between wsjtx and net Hamlib

[alawler mudhawk.com via wsjt-devel]

HI Kari,

  That was a worthwhile experiment, but unfortunately,  I also get the exact 
same behavior between 2  wsjtx 2.4 instances (compiled from source)  with 
rgctld-wsjtx showing  hamlib v4.2.

  I'm pretty sure this is not a hamlib problem, but rather wsjtx  improperly 
assuming that the get frequency command was safe to use on any radio type as a 
basic connectivity test.  (And 25 years later, the misery of the FT-736r cat 
implementation continues...  )

  I'm pretty sure I can hack the code to remove this command from the "Test 
Cat" routine  (after a crash course in c++),   or could insert an impersonator 
between wsjtx and rictld-wsjtx if the situation got truly dire,   so I'm not 
blocked, but wanted to mention it in case anybody else goes down this path.

--al
WB1BQE



From: Kari Sillanmäki via wsjt-devel 
Sent: Sunday, July 18, 2021 7:56 PM
To: alawler mudhawk.com via wsjt-devel 
Cc: Kari Sillanmäki 
Subject: Re: [wsjt-devel] Possible bug between wsjtx and net Hamlib

Hi Al,

Your WSJT-X version 2.2.0  is quite old.

Also, your Hamlib must be even older as you are using the short model numbers.
Hamlib shipped with WSJT-X 2.2.0 use new longer model numbers, for example  
FT-736R is now model number 1010
and FT-890 is 1015.

Suggest you upgrade to current WSJT-X version 2.4.0 and also make sure that 
correct version of Hamblib are being used.

73's de Kari, oh2gqc



On 18.7.2021 17.44, alawler mudhawk.com via wsjt-devel wrote:
 HI Folks,

  I've encountered what seems to be a bug in how wsjtx uses the network hamlib 
functionality.I'm going to start with a simple symptom statement, then will 
include more supporting detail and the specific configuration etc.

The problem:
wsjtx does not work with a remotely connected Yaesu FT-736r using the Net 
Hamlib option.

Symptom:
During setup, when I set Hamlib NET Rigctl in the radioconfiguration 
information and click"Test Cat",  I get an error message box saying "Rig 
Failure"  "Hamlib error:  Feature not available while getting current 
frequency".


  What I think is happening is that for a locally connected radio,  wsjtx is 
"smart enough" to not send a "get frequency" command to the FT-736r,  however, 
in the Net Rigctld mode,  it makes an assumption that this is a relatively safe 
and widely supported way of testing basic communications and sends the command 
without first checking rig capabilities.

I believe this is the expected behavior from Hamlib,   since the FT-736r does 
not support this particular option.

  Configuration:
wsjtx-2.2.0 running on Ubuntu
The radio server is a Raspberry Pi running either rigctld 3.0  or rigctl-wsjtx 
4.0 (the behavior is the same.)

rigctld command:  rigctld-wsjtx -m 110 -r /dev/ttyUSB0 -s 4800 -t 10006 -v

Other test notes:
I am using port 10006 on purpose, but I don't believe that is related to the 
problem.

My raspberry Pi/rigctld server works fine with other FT-736r code that I have 
written, so I'm pretty sure the hardware and configuration are correct.

hamlib trace:
igctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
client lock disengaged

Trying the idential experiment using my FT-890 (ritctld -m 115)  which DOES 
have  a bidirectional CAT interface works fine.

  I am looking at the code with the hopes of just bypassing the frequency set 
command in my own local setup, but figured I'd mention this in case other folks 
might find it useful.

  Thanks for any consideration

--al
WB1BQE





___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[tom via wsjt-devel]

HiYes the other threads are in relation to log4om. Anyways, seems nothing can 
be done right now about this other than to run as admin.Thanks, TomSent from my 
Galaxy
 Original message From: Bill Somerville via wsjt-devel 
 Date: 2021-07-18  4:16 p.m.  (GMT-05:00) To: 
wsjt-devel@lists.sourceforge.net Cc: Bill Somerville  
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server 
Hi Tom,


OK, so there something else going on as
  well. You state below that old versions of WSJT-X have also
  started showing this issue, that would seem to rule out the WSJT-X
  code *and* any Qt libraries as we package them along with WSJT-X.


I am surprised you state that this
  issue has been reported before, I must have missed that. Can you
  provide a link to a list message that reports the same issue
  please? All the message threads I can find on the WSJTX Groups.io
  group about a "Failed to start OmniRig COM server" error are
  either down to running Log4OM with administrator rights (which
  forces Omni-Rig to require other clients to run elevated), or due
  to incorrect registry contents due to not installing Omni-Rig
  correctly. 



73
  Bill
  G4WJS.


On 18/07/2021 20:56, Tom via wsjt-devel
  wrote:


  Hi
  I
  already did this.  It made no difference in my case.  I have
  also given all groups full control.
  Logging
  in with an account in the local administrators group will only
  work as well if WSJT is run in administrator mode.
  Something
  has been changed with a Windows update since this always
  worked without issues in the past.
  It
  all of a sudden started happening with the older version of
  WSJT.  There has been no update of Omni-rig either.
   
  I
  would say this may have  to do with some update somewhere
  (QT?) since you I am sure have many users that never had to
  modify permissions in the past.
   
  I
  have seen several reports of this in your groups.io group in
  the past.  
   
  Of
  course this is solved by putting in Run as Administrator in
  the shortcut for WSJT. But the question is why all of a
  sudden?
  73
  Tom
   
  

  From: Bill Somerville via wsjt-devel
   
  Sent: Sunday, July 18, 2021 3:29 PM
  To: wsjt-devel@lists.sourceforge.net
  Cc: Bill Somerville 
  Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig:
  Failed to start Omni Rig COM server

  
   
  
Hi Tom,
  
  
 
  
  
I think I have reproduced the issue. I have
  an account on my Windows PC, I use for testing UAC matters,
  that is not a member of the local administrators group. If I
  use this account I cannot have WSJT-X use Omni-Rig, even
  though I can start the Omni-Rig server by running its
  executable. It would seem that members of the local
  administrator group have the necessary rights via group
  policies. I can fix the problem by granting a full control ACL
  to the Omni-Rig executable for the user that is not a member
  of the local administrators group, like this:
  
  
 
  
  
Start an Administrator CMD prompt and type
  the following command:
  
  
icacls "C:\Program Files (x86)\Afreet\OmniRig\omnirig.exe" /grant 
:F
  
  
where  is the user name (or
  SID) to be granted the right. Use /remove to remove the ACL
  entry to prove it is working.
  
  
 
  
  
Granting full control like this seems like
  a sledge-hammer to crack a nut, but I am not sure exactly
  which access right is required to start an out-of-process COM
  server like Omni-Rig. It could be that the Omni-Rig installer
  is not setting up Omni-Rig correctly for it to be started by
  users outside of the local administrators group, but I am not
  sufficiently knowledgeable on Windows security system to be
  sure.
  
  
 
  
  
73
  Bill
  G4WJS.
  
  
 
  
  
On 18/07/2021 19:37, Tom via wsjt-devel
  wrote:
  
  
Hi
Exactly the same for all
users.
Don’t know where to go
from here….
73 Tom
 
 

  
From: Bill
Somerville via wsjt-devel 

Sent: Sunday, July 18, 2021 2:22 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 

Re: [wsjt-devel] Possible bug between wsjtx and net Hamlib

[Black Michael via wsjt-devel]

Could you please try the master repo to see if has already been fixed?
https://github.com/Hamlib/Hamlib


 Mike W9MDB
On Sunday, July 18, 2021, 12:10:29 PM CDT, alawler mudhawk.com via 
wsjt-devel  wrote:  
 
   HI Folks,
  I've encountered what seems to be a bug in how wsjtx uses the network hamlib 
functionality.    I'm going to start with a simple symptom statement, then will 
include more supporting detail and the specific configuration etc.
The problem:  wsjtx does not work with a remotely connected Yaesu FT-736r using 
the Net Hamlib option.
Symptom:During setup, when I set Hamlib NET Rigctl in the radioconfiguration 
information and click    "Test Cat",  I get an error message box saying "Rig 
Failure"  "Hamlib error:  Feature not available while getting current 
frequency".
   What I think is happening is that for a locally connected radio,  wsjtx is 
"smart enough" to not send a "get frequency" command to the FT-736r,  however, 
in the Net Rigctld mode,  it makes an assumption that this is a relatively safe 
and widely supported way of testing basic communications and sends the command 
without first checking rig capabilities.
I believe this is the expected behavior from Hamlib,   since the FT-736r does 
not support this particular option.  

  Configuration:wsjtx-2.2.0 running on UbuntuThe radio server is a Raspberry Pi 
running either rigctld 3.0  or rigctl-wsjtx 4.0 (the behavior is the same.) 
rigctld command:  rigctld-wsjtx -m 110 -r /dev/ttyUSB0 -s 4800 -t 10006 -v
Other test notes:I am using port 10006 on purpose, but I don't believe that is 
related to the problem.
My raspberry Pi/rigctld server works fine with other FT-736r code that I have 
written, so I'm pretty sure the hardware and configuration are correct.
hamlib trace:igctl(d): v 'currVFO' '' '' ''rig_get_vfo calledclient lock 
disengagedclient lock engagedrig_strvfo calledrigctl(d): f 'currVFO' '' '' 
''rig_get_freq calledclient lock disengaged

Trying the idential experiment using my FT-890 (ritctld -m 115)  which DOES 
have  a bidirectional CAT interface works fine.
  I am looking at the code with the hopes of just bypassing the frequency set 
command in my own local setup, but figured I'd mention this in case other folks 
might find it useful.
  Thanks for any consideration
--alWB1BQE ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Bill Somerville via wsjt-devel]

Hi Tom,

OK, so there something else going on as well. You state below that old 
versions of WSJT-X have also started showing this issue, that would seem 
to rule out the WSJT-X code *and* any Qt libraries as we package them 
along with WSJT-X.


I am surprised you state that this issue has been reported before, I 
must have missed that. Can you provide a link to a list message that 
reports the same issue please? All the message threads I can find on the 
WSJTX Groups.io group about a "Failed to start OmniRig COM server" error 
are either down to running Log4OM with administrator rights (which 
forces Omni-Rig to require other clients to run elevated), or due to 
incorrect registry contents due to not installing Omni-Rig correctly.


73
Bill
G4WJS.

On 18/07/2021 20:56, Tom via wsjt-devel wrote:


Hi

I already did this.  It made no difference in my case.  I have also 
given all groups full control.


Logging in with an account in the local administrators group will only 
work as well if WSJT is run in administrator mode.


Something has been changed with a Windows update since this always 
worked without issues in the past.


It all of a sudden started happening with the older version of WSJT.  
There has been no update of Omni-rig either.


I would say this may have  to do with some update somewhere (QT?) 
since you I am sure have many users that never had to modify 
permissions in the past.


I have seen several reports of this in your groups.io group in the past.

Of course this is solved by putting in Run as Administrator in the 
shortcut for WSJT. But the question is why all of a sudden?


73 Tom

*From:*Bill Somerville via wsjt-devel 
*Sent:* Sunday, July 18, 2021 3:29 PM
*To:* wsjt-devel@lists.sourceforge.net
*Cc:* Bill Somerville 
*Subject:* Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni 
Rig COM server


Hi Tom,

I think I have reproduced the issue. I have an account on my Windows 
PC, I use for testing UAC matters, that is not a member of the local 
administrators group. If I use this account I cannot have WSJT-X use 
Omni-Rig, even though I can start the Omni-Rig server by running its 
executable. It would seem that members of the local administrator 
group have the necessary rights via group policies. I can fix the 
problem by granting a full control ACL to the Omni-Rig executable for 
the user that is not a member of the local administrators group, like 
this:


Start an Administrator CMD prompt and type the following command:

icacls "C:\Program Files (x86)\Afreet\OmniRig\omnirig.exe" /grant :F

where  is the user name (or SID) to be granted the right. Use 
/remove to remove the ACL entry to prove it is working.


Granting full control like this seems like a sledge-hammer to crack a 
nut, but I am not sure exactly which access right is required to start 
an out-of-process COM server like Omni-Rig. It could be that the 
Omni-Rig installer is not setting up Omni-Rig correctly for it to be 
started by users outside of the local administrators group, but I am 
not sufficiently knowledgeable on Windows security system to be sure.


73
Bill
G4WJS.

On 18/07/2021 19:37, Tom via wsjt-devel wrote:

Hi

Exactly the same for all users.

Don’t know where to go from here….

73 Tom

*From:*Bill Somerville via wsjt-devel


*Sent:* Sunday, July 18, 2021 2:22 PM
*To:* wsjt-devel@lists.sourceforge.net

*Cc:* Bill Somerville 

*Subject:* Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start
Omni Rig COM server

Hi Tom,

thanks for that. So it seems that something is blocking COM
communications between WSJT-X and Omni-Rig that is resolved by
running WSJT-X with elevated rights. The Windows security model,
in general, blocks IPC between processes running at different
security levels. If that is the issue then perhaps somehow
Omni-Rig can only be started using elevated rights. Is it possible
that the OmniRig.exe file has a security restriction applied? On
my system if I check the effective rights for my non-administrator
user to the omnirig.exe file I see this:

which includes read and execute. Is it the same on your system?

I am not sure why you are asking about how WSJT-X accesses serial
ports, when using Omni-Rig it doesn't access serial ports. To
access COM services we use a Qt library Active that allows us to
access COM services without the low level details of handling COM
in C. We also use a Qt tool called dumpcpp which generates Active
Qt COM wrappers by querying the COM server via its GUID to
enumerate its COM API.

https://doc.qt.io/qt-5/activeqt-index.html


73
Bill
G4WJS.

On 18/07/2021 18:55, Tom via wsjt-devel wrote:

Hi

Ok.  I did this.  When you run WSJT without 

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Tom via wsjt-devel]

Hi

I already did this.  It made no difference in my case.  I have also given all 
groups full control.

Logging in with an account in the local administrators group will only work as 
well if WSJT is run in administrator mode.

Something has been changed with a Windows update since this always worked 
without issues in the past.

It all of a sudden started happening with the older version of WSJT.  There has 
been no update of Omni-rig either.



I would say this may have  to do with some update somewhere (QT?) since you I 
am sure have many users that never had to modify permissions in the past.



I have seen several reports of this in your groups.io group in the past.



Of course this is solved by putting in Run as Administrator in the shortcut for 
WSJT. But the question is why all of a sudden?

73 Tom



From: Bill Somerville via wsjt-devel 
Sent: Sunday, July 18, 2021 3:29 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



I think I have reproduced the issue. I have an account on my Windows PC, I use 
for testing UAC matters, that is not a member of the local administrators 
group. If I use this account I cannot have WSJT-X use Omni-Rig, even though I 
can start the Omni-Rig server by running its executable. It would seem that 
members of the local administrator group have the necessary rights via group 
policies. I can fix the problem by granting a full control ACL to the Omni-Rig 
executable for the user that is not a member of the local administrators group, 
like this:



Start an Administrator CMD prompt and type the following command:

icacls "C:\Program Files (x86)\Afreet\OmniRig\omnirig.exe" /grant :F

where  is the user name (or SID) to be granted the right. Use /remove to 
remove the ACL entry to prove it is working.



Granting full control like this seems like a sledge-hammer to crack a nut, but 
I am not sure exactly which access right is required to start an out-of-process 
COM server like Omni-Rig. It could be that the Omni-Rig installer is not 
setting up Omni-Rig correctly for it to be started by users outside of the 
local administrators group, but I am not sufficiently knowledgeable on Windows 
security system to be sure.



73
Bill
G4WJS.



On 18/07/2021 19:37, Tom via wsjt-devel wrote:

Hi

Exactly the same for all users.

Don’t know where to go from here….

73 Tom





From: Bill Somerville via wsjt-devel   

Sent: Sunday, July 18, 2021 2:22 PM
To: wsjt-devel@lists.sourceforge.net 
Cc: Bill Somerville   
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



thanks for that. So it seems that something is blocking COM communications 
between WSJT-X and Omni-Rig that is resolved by running WSJT-X with elevated 
rights. The Windows security model, in general, blocks IPC between processes 
running at different security levels. If that is the issue then perhaps somehow 
Omni-Rig can only be started using elevated rights. Is it possible that the 
OmniRig.exe file has a security restriction applied? On my system if I check 
the effective rights for my non-administrator user to the omnirig.exe file I 
see this:



which includes read and execute. Is it the same on your system?



I am not sure why you are asking about how WSJT-X accesses serial ports, when 
using Omni-Rig it doesn't access serial ports. To access COM services we use a 
Qt library Active that allows us to access COM services without the low level 
details of handling COM in C. We also use a Qt tool called dumpcpp which 
generates Active Qt COM wrappers by querying the COM server via its GUID to 
enumerate its COM API.



https://doc.qt.io/qt-5/activeqt-index.html



73
Bill
G4WJS.



On 18/07/2021 18:55, Tom via wsjt-devel wrote:

Hi

Ok.  I did this.  When you run WSJT without being admin, no log is made at all. 
 You get Failed to start Omni Rig COM server in  WSJT

If you run it as admin, then a log appears.

Here are the first few lines…



13:45:51.670  Omni-Rig started: Version 1.19

13:45:51.675  Loading commands from "ZS-1.ini"

13:45:51.691  Loading commands from "TS-930.ini"

13:45:51.707  Loading commands from "TS-870.ini"



If you run Log4OM for example NOT as admin, a log is created as above.



Since this happens with an older version of WSJT and the latest versions 
(production) most likely a library somewhere has been changed.  Perhaps by 
Windows update.

I remember a couple of years ago, that I had a sound device stuck in WSJT even 
though the device wasn’t installed. .  We worked on it a lot to no resolution.  
A subsequent Windows update fixed it.

What libraries are you using for serial port access? Or the com server?



73 Tom



From: Bill Somerville via wsjt-devel   

Sent: Sunday, July 18, 

Re: [wsjt-devel] Possible bug between wsjtx and net Hamlib

[Kari Sillanmäki via wsjt-devel]

Hi Al,

Your WSJT-X version 2.2.0  is quite old.

Also, your Hamlib must be even older as you are using the short model 
numbers.
Hamlib shipped with WSJT-X 2.2.0 use new longer model numbers, for 
example  FT-736R is now model number 1010

and FT-890 is 1015.

Suggest you upgrade to current WSJT-X version 2.4.0 and also make sure 
that correct version of Hamblib are being used.


73's de Kari, oh2gqc



On 18.7.2021 17.44, alawler mudhawk.com via wsjt-devel wrote:

 HI Folks,

  I've encountered what seems to be a bug in how wsjtx uses the 
network hamlib functionality.    I'm going to start with a simple 
symptom statement, then will include more supporting detail and the 
specific configuration etc.


The problem:
wsjtx does not work with a remotely connected Yaesu FT-736r using the 
Net Hamlib option.


Symptom:
During setup, when I set Hamlib NET Rigctl in the radioconfiguration 
information and click    "Test Cat",  I get an error message box 
saying "Rig Failure"  "Hamlib error: Feature not available while 
getting current frequency".


  What I think is happening is that for a locally connected radio,  
wsjtx is "smart enough" to not send a "get frequency" command to the 
FT-736r,  however, in the Net Rigctld mode,  it makes an assumption 
that this is a relatively safe and widely supported way of testing 
basic communications and sends the command without first checking rig 
capabilities.


I believe this is the expected behavior from Hamlib,   since the 
FT-736r does not support this particular option.


  Configuration:
wsjtx-2.2.0 running on Ubuntu
The radio server is a Raspberry Pi running either rigctld 3.0 or 
rigctl-wsjtx 4.0 (the behavior is the same.)


rigctld command:  rigctld-wsjtx -m 110 -r /dev/ttyUSB0 -s 4800 -t 
10006 -v


Other test notes:
I am using port 10006 on purpose, but I don't believe that is related 
to the problem.


My raspberry Pi/rigctld server works fine with other FT-736r code that 
I have written, so I'm pretty sure the hardware and configuration are 
correct.


hamlib trace:
igctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
client lock disengaged

Trying the idential experiment using my FT-890 (ritctld -m 115) which 
DOES have  a bidirectional CAT interface works fine.


  I am looking at the code with the hopes of just bypassing the 
frequency set command in my own local setup, but figured I'd mention 
this in case other folks might find it useful.


  Thanks for any consideration

--al
WB1BQE


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Bill Somerville via wsjt-devel]

Hi Tom,

I think I have reproduced the issue. I have an account on my Windows PC, 
I use for testing UAC matters, that is not a member of the local 
administrators group. If I use this account I cannot have WSJT-X use 
Omni-Rig, even though I can start the Omni-Rig server by running its 
executable. It would seem that members of the local administrator group 
have the necessary rights via group policies. I can fix the problem by 
granting a full control ACL to the Omni-Rig executable for the user that 
is not a member of the local administrators group, like this:


Start an Administrator CMD prompt and type the following command:

icacls "C:\Program Files (x86)\Afreet\OmniRig\omnirig.exe" /grant :F

where  is the user name (or SID) to be granted the right. Use 
/remove to remove the ACL entry to prove it is working.


Granting full control like this seems like a sledge-hammer to crack a 
nut, but I am not sure exactly which access right is required to start 
an out-of-process COM server like Omni-Rig. It could be that the 
Omni-Rig installer is not setting up Omni-Rig correctly for it to be 
started by users outside of the local administrators group, but I am not 
sufficiently knowledgeable on Windows security system to be sure.


73
Bill
G4WJS.

On 18/07/2021 19:37, Tom via wsjt-devel wrote:


Hi

Exactly the same for all users.

Don’t know where to go from here….

73 Tom

*From:*Bill Somerville via wsjt-devel 
*Sent:* Sunday, July 18, 2021 2:22 PM
*To:* wsjt-devel@lists.sourceforge.net
*Cc:* Bill Somerville 
*Subject:* Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni 
Rig COM server


Hi Tom,

thanks for that. So it seems that something is blocking COM 
communications between WSJT-X and Omni-Rig that is resolved by running 
WSJT-X with elevated rights. The Windows security model, in general, 
blocks IPC between processes running at different security levels. If 
that is the issue then perhaps somehow Omni-Rig can only be started 
using elevated rights. Is it possible that the OmniRig.exe file has a 
security restriction applied? On my system if I check the effective 
rights for my non-administrator user to the omnirig.exe file I see this:


which includes read and execute. Is it the same on your system?

I am not sure why you are asking about how WSJT-X accesses serial 
ports, when using Omni-Rig it doesn't access serial ports. To access 
COM services we use a Qt library Active that allows us to access COM 
services without the low level details of handling COM in C. We also 
use a Qt tool called dumpcpp which generates Active Qt COM wrappers by 
querying the COM server via its GUID to enumerate its COM API.


https://doc.qt.io/qt-5/activeqt-index.html 



73
Bill
G4WJS.

On 18/07/2021 18:55, Tom via wsjt-devel wrote:

Hi

Ok.  I did this.  When you run WSJT without being admin, no log is
made at all. You get Failed to start Omni Rig COM server in  WSJT

If you run it as admin, then a log appears.

Here are the first few lines…

13:45:51.670  Omni-Rig started: Version 1.19

13:45:51.675  Loading commands from "ZS-1.ini"

13:45:51.691  Loading commands from "TS-930.ini"

13:45:51.707  Loading commands from "TS-870.ini"

If you run Log4OM for example NOT as admin, a log is created as above.

Since this happens with an older version of WSJT and the latest
versions (production) most likely a library somewhere has been
changed.  Perhaps by Windows update.

I remember a couple of years ago, that I had a sound device stuck
in WSJT even though the device wasn’t installed. .  We worked on
it a lot to no resolution.  A subsequent Windows update fixed it.

What libraries are you using for serial port access? Or the com
server?

73 Tom

*From:*Bill Somerville via wsjt-devel


*Sent:* Sunday, July 18, 2021 1:32 PM
*To:* wsjt-devel@lists.sourceforge.net

*Cc:* Bill Somerville 

*Subject:* Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start
Omni Rig COM server

Tom,

I did have a minor typo in the first path I wrote below, other
than that it most certainly is where the Omni-Rig configuration
file is found:

C:\Users\bill\build>dir "%AppData%\Afreet\Products\OmniRig\"

  Volume in drive C is Windows8_OS

  Volume Serial Number is 56CD-82B3

  


  Directory of C:\Users\bill\AppData\Roaming\Afreet\Products\OmniRig

  


20/04/2017  15:16      .

20/04/2017  15:16      ..

18/07/2021  08:38   762 OmniRig.ini

14/08/2016  00:16   282 OmniRig.ini~

18/07/2021  08:36    18,617 OmniRig.log

    3 File(s) 19,661 bytes

    2 Dir(s)  62,254,145,536 bytes free

Note Products, not Produxts as I 

Re: [wsjt-devel] Possible feature request, time skew notification?

[Gary McDuffie via wsjt-devel]

> On Jul 18, 2021, at 09:26, Carey Fisher via wsjt-devel 
>  wrote:
> 
> If you simply look at the waterfall, it's clearly obvious whether your clock 
> is off or not.

You and George are correct.  Simply looking at the waterfall will get you 
within the two seconds required.  After that, the df will give you all you need 
over a couple minutes time of monitoring.

If you run your waterfall so narrow that you can’t tell, you merely need to 
expand it for a few minutes.  I’ve seen some postings that show some people run 
their waterfall so narrow (vertically) that they can’t tell a thing about the 
timing or quality of incoming signals.  That’s the cost of setting up that way.

Use the tools within the program itself.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Tom via wsjt-devel]

Hi

Exactly the same for all users.

Don’t know where to go from here….

73 Tom





From: Bill Somerville via wsjt-devel 
Sent: Sunday, July 18, 2021 2:22 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



thanks for that. So it seems that something is blocking COM communications 
between WSJT-X and Omni-Rig that is resolved by running WSJT-X with elevated 
rights. The Windows security model, in general, blocks IPC between processes 
running at different security levels. If that is the issue then perhaps somehow 
Omni-Rig can only be started using elevated rights. Is it possible that the 
OmniRig.exe file has a security restriction applied? On my system if I check 
the effective rights for my non-administrator user to the omnirig.exe file I 
see this:



which includes read and execute. Is it the same on your system?



I am not sure why you are asking about how WSJT-X accesses serial ports, when 
using Omni-Rig it doesn't access serial ports. To access COM services we use a 
Qt library Active that allows us to access COM services without the low level 
details of handling COM in C. We also use a Qt tool called dumpcpp which 
generates Active Qt COM wrappers by querying the COM server via its GUID to 
enumerate its COM API.



https://doc.qt.io/qt-5/activeqt-index.html



73
Bill
G4WJS.



On 18/07/2021 18:55, Tom via wsjt-devel wrote:

Hi

Ok.  I did this.  When you run WSJT without being admin, no log is made at all. 
 You get Failed to start Omni Rig COM server in  WSJT

If you run it as admin, then a log appears.

Here are the first few lines…



13:45:51.670  Omni-Rig started: Version 1.19

13:45:51.675  Loading commands from "ZS-1.ini"

13:45:51.691  Loading commands from "TS-930.ini"

13:45:51.707  Loading commands from "TS-870.ini"



If you run Log4OM for example NOT as admin, a log is created as above.



Since this happens with an older version of WSJT and the latest versions 
(production) most likely a library somewhere has been changed.  Perhaps by 
Windows update.

I remember a couple of years ago, that I had a sound device stuck in WSJT even 
though the device wasn’t installed. .  We worked on it a lot to no resolution.  
A subsequent Windows update fixed it.

What libraries are you using for serial port access? Or the com server?



73 Tom



From: Bill Somerville via wsjt-devel   

Sent: Sunday, July 18, 2021 1:32 PM
To: wsjt-devel@lists.sourceforge.net 
Cc: Bill Somerville   
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Tom,



I did have a minor typo in the first path I wrote below, other than that it 
most certainly is where the Omni-Rig configuration file is found:

C:\Users\bill\build>dir "%AppData%\Afreet\Products\OmniRig\"
 Volume in drive C is Windows8_OS
 Volume Serial Number is 56CD-82B3

 Directory of C:\Users\bill\AppData\Roaming\Afreet\Products\OmniRig

20/04/2017  15:16  .
20/04/2017  15:16  ..
18/07/2021  08:38   762 OmniRig.ini
14/08/2016  00:16   282 OmniRig.ini~
18/07/2021  08:3618,617 OmniRig.log
   3 File(s) 19,661 bytes
   2 Dir(s)  62,254,145,536 bytes free

Note Products, not Produxts as I mis-typed.



At this point I think that running anything here with elevated rights causing 
different behaviour is coincidental.



I also think the "Failed to start Omni-Rig COM server" is somewhat bogus too as 
you have proved that if you stat the server manually WSJT-X still fails to hook 
up with it. I am hoping the Omni-Rig debug log has some entry that tells me 
what is actually happening.



73
Bill
G4WJS.



On 18/07/2021 17:19, Tom via wsjt-devel wrote:

Hi

There is no such path.  I am using omni-rig 1.19 just downloaded from the web 
at dxatlas.



The use of administrator mode only works for the 64 bit WSJT. The 32 bit fails 
with both user and administrator mode.  Always failed to start the omnirig com 
server.

Tom







From: Bill Somerville via wsjt-devel   

Sent: Sunday, July 18, 2021 3:39 AM
To: wsjt-devel@lists.sourceforge.net 
Cc: Bill Somerville   
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



thanks for the clarification. You didn't confirm which version of Omni-Rig you 
are using.



It would be interesting to see the Omni-Rig debug log for a test where WSJT-X 
claims it is unable to start the Omni-Rig COM server. To enable Omni-Rig debug 
logging put the following into the main Omni-Rig settings file 
"%AppData%\Afreet\Produxts\OmniRig\OmniRig.ini" at the top:

[Debug]
Log=1

The log file is called OmniRig.log and appears in the same 

Re: [wsjt-devel] Problems building on MacOS X 11.1 Intel

[Bill Somerville via wsjt-devel]

Hi Alex,

thanks for that. We currently do not recommend using a gfortran version 
>= 8 on macOS, this is due to some known issues with our code for which 
fixes are a WIP. With gfortran v7 that compiler diagnostic message is 
only a warning, which is how our build gets passed it. The passing of 
-Xclang to the Fortran compiler is not done directly by us, I guess it 
is a CMake issue which we have not been too concerned about yet.


73
Bill
G4WJS.

On 18/07/2021 19:18, Alex Lelievre via wsjt-devel wrote:

Hi Bill,

Thanks for getting back to me.  This is what I get:

grey>:/Users/alex$which gfortran
/usr/local/bin/gfortran
grey>:/Users/alex$gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.1.0_1/libexec/gcc/x86_64-apple-darwin20/11.1.0/lto-wrapper
Target: x86_64-apple-darwin20
Configured with: ../configure --prefix=/usr/local/Cellar/gcc/11.1.0_1 
--libdir=/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11 --disable-nls 
--enable-checking=release 
--enable-languages=c,c++,objc,obj-c++,fortran,d --program-suffix=-11 
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr 
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl 
--with-zstd=/usr/local/opt/zstd --with-pkgversion='Homebrew GCC 
11.1.0_1' 
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues 
 --enable-libphobos 
--build=x86_64-apple-darwin20 --with-system-zlib --disable-multilib 
--without-build-config --with-native-system-header-dir=/usr/include 
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Homebrew GCC 11.1.0_1)

alex K6LOT

On Jul 17, 2021, at 11:51 PM, Bill Somerville via wsjt-devel 
> wrote:


On 18/07/2021 03:31, Alex Lelievre via wsjt-devel wrote:

Hi there,

I’m running into an error in the fortran portion of the WSJT-X 
project on MacOS X.   I’m reaching out to see if anyone has bumped 
into this:


[ 17%] Built target record_time_signal
[ 17%] *Automatic MOC for target fort_qt*
[ 17%] Built target fort_qt_autogen
[ 17%] Built target fort_qt
[ 17%] Building Fortran object 
CMakeFiles/wsjt_fort_omp.dir/lib/packjt.f90.o

*gfortran:* *error: *unrecognized command-line option '*-Xclang*'
make[5]: *** [CMakeFiles/wsjt_fort_omp.dir/lib/packjt.f90.o] Error 1
make[4]: *** [CMakeFiles/wsjt_fort_omp.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
make[1]: *** [CMakeFiles/wsjtx-build.dir/all] Error 2
make: *** [all] Error 2
I’m not sure why -Xclang is being passed to the fortran compiler. 
 Calling gfortran with a test file and -Xclang option generates the 
same error.
I’m wondering if I misconfigured the project or perhaps I’m using 
the wrong tool chain?


Any help would be appreciated,
alex K6LOT


Hi Alex,

which Fortran compiler are you using and what version?

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Bill Somerville via wsjt-devel]

Hi Tom,

thanks for that. So it seems that something is blocking COM 
communications between WSJT-X and Omni-Rig that is resolved by running 
WSJT-X with elevated rights. The Windows security model, in general, 
blocks IPC between processes running at different security levels. If 
that is the issue then perhaps somehow Omni-Rig can only be started 
using elevated rights. Is it possible that the OmniRig.exe file has a 
security restriction applied? On my system if I check the effective 
rights for my non-administrator user to the omnirig.exe file I see this:

which includes read and execute. Is it the same on your system?

I am not sure why you are asking about how WSJT-X accesses serial ports, 
when using Omni-Rig it doesn't access serial ports. To access COM 
services we use a Qt library Active that allows us to access COM 
services without the low level details of handling COM in C. We also use 
a Qt tool called dumpcpp which generates Active Qt COM wrappers by 
querying the COM server via its GUID to enumerate its COM API.


https://doc.qt.io/qt-5/activeqt-index.html

73
Bill
G4WJS.

On 18/07/2021 18:55, Tom via wsjt-devel wrote:


Hi

Ok. I did this.  When you run WSJT without being admin, no log is made 
at all.  You get Failed to start Omni Rig COM server in  WSJT


If you run it as admin, then a log appears.

Here are the first few lines…

13:45:51.670 Omni-Rig started: Version 1.19

13:45:51.675 Loading commands from "ZS-1.ini"

13:45:51.691 Loading commands from "TS-930.ini"

13:45:51.707 Loading commands from "TS-870.ini"

If you run Log4OM for example NOT as admin, a log is created as above.

Since this happens with an older version of WSJT and the latest 
versions (production) most likely a library somewhere has been 
changed.  Perhaps by Windows update.


I remember a couple of years ago, that I had a sound device stuck in 
WSJT even though the device wasn’t installed. .  We worked on it a lot 
to no resolution.  A subsequent Windows update fixed it.


What libraries are you using for serial port access? Or the com server?

73 Tom

*From:*Bill Somerville via wsjt-devel 
*Sent:* Sunday, July 18, 2021 1:32 PM
*To:* wsjt-devel@lists.sourceforge.net
*Cc:* Bill Somerville 
*Subject:* Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni 
Rig COM server


Tom,

I did have a minor typo in the first path I wrote below, other than 
that it most certainly is where the Omni-Rig configuration file is found:


C:\Users\bill\build>dir "%AppData%\Afreet\Products\OmniRig\"
  Volume in drive C is Windows8_OS
  Volume Serial Number is 56CD-82B3
  Directory of C:\Users\bill\AppData\Roaming\Afreet\Products\OmniRig
20/04/2017  15:16      .
20/04/2017  15:16      ..
18/07/2021  08:38   762 OmniRig.ini
14/08/2016  00:16   282 OmniRig.ini~
18/07/2021  08:36    18,617 OmniRig.log
    3 File(s) 19,661 bytes
    2 Dir(s)  62,254,145,536 bytes free

Note Products, not Produxts as I mis-typed.

At this point I think that running anything here with elevated rights 
causing different behaviour is coincidental.


I also think the "Failed to start Omni-Rig COM server" is somewhat 
bogus too as you have proved that if you stat the server manually 
WSJT-X still fails to hook up with it. I am hoping the Omni-Rig debug 
log has some entry that tells me what is actually happening.


73
Bill
G4WJS.

On 18/07/2021 17:19, Tom via wsjt-devel wrote:

Hi

There is no such path.  I am using omni-rig 1.19 just downloaded
from the web at dxatlas.

The use of administrator mode only works for the 64 bit WSJT. The
32 bit fails with both user and administrator mode.  Always failed
to start the omnirig com server.

Tom

*From:*Bill Somerville via wsjt-devel


*Sent:* Sunday, July 18, 2021 3:39 AM
*To:* wsjt-devel@lists.sourceforge.net

*Cc:* Bill Somerville 

*Subject:* Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start
Omni Rig COM server

Hi Tom,

thanks for the clarification. You didn't confirm which version of
Omni-Rig you are using.

It would be interesting to see the Omni-Rig debug log for a test
where WSJT-X claims it is unable to start the Omni-Rig COM server.
To enable Omni-Rig debug logging put the following into the main
Omni-Rig settings file
"%AppData%\Afreet\Produxts\OmniRig\OmniRig.ini" at the top:

[Debug]

Log=1

The log file is called OmniRig.log and appears in the same
"%AppData%\Afreet\Products\OmniRig\" directory.

73
Bill
G4WJS.

On 17/07/2021 00:42, tom via wsjt-devel wrote:

Hi

No, I don't think I said this right.

If you open omnirig while you monitor the serial port, the
serial port opens, then there's a little activity and then the
port closed. 

Re: [wsjt-devel] Problems building on MacOS X 11.1 Intel

[Alex Lelievre via wsjt-devel]

Hi Bill,

Thanks for getting back to me.  This is what I get:

grey>:/Users/alex$ which gfortran
/usr/local/bin/gfortran
grey>:/Users/alex$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.1.0_1/libexec/gcc/x86_64-apple-darwin20/11.1.0/lto-wrapper
Target: x86_64-apple-darwin20
Configured with: ../configure --prefix=/usr/local/Cellar/gcc/11.1.0_1 
--libdir=/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11 --disable-nls 
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran,d 
--program-suffix=-11 --with-gmp=/usr/local/opt/gmp 
--with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc 
--with-isl=/usr/local/opt/isl --with-zstd=/usr/local/opt/zstd 
--with-pkgversion='Homebrew GCC 11.1.0_1' 
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues 
--enable-libphobos --build=x86_64-apple-darwin20 --with-system-zlib 
--disable-multilib --without-build-config 
--with-native-system-header-dir=/usr/include 
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Homebrew GCC 11.1.0_1) 

alex K6LOT

> On Jul 17, 2021, at 11:51 PM, Bill Somerville via wsjt-devel 
>  wrote:
> 
> On 18/07/2021 03:31, Alex Lelievre via wsjt-devel wrote:
>> Hi there,
>> 
>> I’m running into an error in the fortran portion of the WSJT-X project on 
>> MacOS X.   I’m reaching out to see if anyone has bumped into this:
>> 
>> [ 17%] Built target record_time_signal
>> [ 17%] Automatic MOC for target fort_qt
>> [ 17%] Built target fort_qt_autogen
>> [ 17%] Built target fort_qt
>> [ 17%] Building Fortran object CMakeFiles/wsjt_fort_omp.dir/lib/packjt.f90.o
>> gfortran: error: unrecognized command-line option '-Xclang'
>> make[5]: *** [CMakeFiles/wsjt_fort_omp.dir/lib/packjt.f90.o] Error 1
>> make[4]: *** [CMakeFiles/wsjt_fort_omp.dir/all] Error 2
>> make[3]: *** [all] Error 2
>> make[2]: *** [wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
>> make[1]: *** [CMakeFiles/wsjtx-build.dir/all] Error 2
>> make: *** [all] Error 2
>>  
>> I’m not sure why -Xclang is being passed to the fortran compiler.  Calling 
>> gfortran with a test file and -Xclang option generates the same error.
>> I’m wondering if I misconfigured the project or perhaps I’m using the wrong 
>> tool chain?
>> 
>> Any help would be appreciated,
>> alex K6LOT
>> 
> Hi Alex,
> 
> which Fortran compiler are you using and what version?
> 
> 73
> Bill
> G4WJS.
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Tom via wsjt-devel]

Hi

Ok.  I did this.  When you run WSJT without being admin, no log is made at all. 
 You get Failed to start Omni Rig COM server in  WSJT

If you run it as admin, then a log appears.

Here are the first few lines…



13:45:51.670  Omni-Rig started: Version 1.19

13:45:51.675  Loading commands from "ZS-1.ini"

13:45:51.691  Loading commands from "TS-930.ini"

13:45:51.707  Loading commands from "TS-870.ini"



If you run Log4OM for example NOT as admin, a log is created as above.



Since this happens with an older version of WSJT and the latest versions 
(production) most likely a library somewhere has been changed.  Perhaps by 
Windows update.

I remember a couple of years ago, that I had a sound device stuck in WSJT even 
though the device wasn’t installed. .  We worked on it a lot to no resolution.  
A subsequent Windows update fixed it.

What libraries are you using for serial port access? Or the com server?



73 Tom



From: Bill Somerville via wsjt-devel 
Sent: Sunday, July 18, 2021 1:32 PM
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Tom,



I did have a minor typo in the first path I wrote below, other than that it 
most certainly is where the Omni-Rig configuration file is found:

C:\Users\bill\build>dir "%AppData%\Afreet\Products\OmniRig\"
 Volume in drive C is Windows8_OS
 Volume Serial Number is 56CD-82B3

 Directory of C:\Users\bill\AppData\Roaming\Afreet\Products\OmniRig

20/04/2017  15:16  .
20/04/2017  15:16  ..
18/07/2021  08:38   762 OmniRig.ini
14/08/2016  00:16   282 OmniRig.ini~
18/07/2021  08:3618,617 OmniRig.log
   3 File(s) 19,661 bytes
   2 Dir(s)  62,254,145,536 bytes free

Note Products, not Produxts as I mis-typed.



At this point I think that running anything here with elevated rights causing 
different behaviour is coincidental.



I also think the "Failed to start Omni-Rig COM server" is somewhat bogus too as 
you have proved that if you stat the server manually WSJT-X still fails to hook 
up with it. I am hoping the Omni-Rig debug log has some entry that tells me 
what is actually happening.



73
Bill
G4WJS.



On 18/07/2021 17:19, Tom via wsjt-devel wrote:

Hi

There is no such path.  I am using omni-rig 1.19 just downloaded from the web 
at dxatlas.



The use of administrator mode only works for the 64 bit WSJT. The 32 bit fails 
with both user and administrator mode.  Always failed to start the omnirig com 
server.

Tom







From: Bill Somerville via wsjt-devel   

Sent: Sunday, July 18, 2021 3:39 AM
To: wsjt-devel@lists.sourceforge.net 
Cc: Bill Somerville   
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



thanks for the clarification. You didn't confirm which version of Omni-Rig you 
are using.



It would be interesting to see the Omni-Rig debug log for a test where WSJT-X 
claims it is unable to start the Omni-Rig COM server. To enable Omni-Rig debug 
logging put the following into the main Omni-Rig settings file 
"%AppData%\Afreet\Produxts\OmniRig\OmniRig.ini" at the top:

[Debug]
Log=1

The log file is called OmniRig.log and appears in the same 
"%AppData%\Afreet\Products\OmniRig\" directory.



73
Bill
G4WJS.



On 17/07/2021 00:42, tom via wsjt-devel wrote:

Hi

No, I don't think I said this right.

If you open omnirig while you monitor the serial port, the serial port opens, 
then there's a little activity and then the port closed. Omnirig remains open.

Starting wsjt with omnirig open or closed produces the same result. Failed to 
start com server unless you run it as admin.



Tom





Sent from my Galaxy





 Original message 

From: Bill Somerville via wsjt-devel   


Date: 2021-07-16 5:56 p.m. (GMT-05:00)

To: wsjt-devel@lists.sourceforge.net 

Cc: Bill Somerville   

Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



that's not how Omni-Rig behaves for me, if I start it manually the setup dialog 
stays open until it is cancelled or closed with the OK button. Starting WSJT-X 
to communicate with it doesn't change that. What version of Omni-Rig are you 
using?



73
Bill
G4WJS.



On 16/07/2021 22:49, Tom via wsjt-devel wrote:

Hi

Omni-rig connects just fine to the radio.  When you open it there is some 
initial comport activity then it closes.  All this is normal.

It is completely reproducible on my system.  There is no issue with any other 
application that uses Omni-rig.

On the groups.io list, there are people that have reported this in the past.

73 Tom





From: Bill Somerville via wsjt-devel  

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Bill Somerville via wsjt-devel]

Tom,

I did have a minor typo in the first path I wrote below, other than that 
it most certainly is where the Omni-Rig configuration file is found:


C:\Users\bill\build>dir "%AppData%\Afreet\Products\OmniRig\"
 Volume in drive C is Windows8_OS
 Volume Serial Number is 56CD-82B3

 Directory of C:\Users\bill\AppData\Roaming\Afreet\Products\OmniRig

20/04/2017  15:16  .
20/04/2017  15:16  ..
18/07/2021  08:38   762 OmniRig.ini
14/08/2016  00:16   282 OmniRig.ini~
18/07/2021  08:3618,617 OmniRig.log
   3 File(s) 19,661 bytes
   2 Dir(s)  62,254,145,536 bytes free

Note Products, not Produxts as I mis-typed.

At this point I think that running anything here with elevated rights 
causing different behaviour is coincidental.


I also think the "Failed to start Omni-Rig COM server" is somewhat bogus 
too as you have proved that if you stat the server manually WSJT-X still 
fails to hook up with it. I am hoping the Omni-Rig debug log has some 
entry that tells me what is actually happening.


73
Bill
G4WJS.

On 18/07/2021 17:19, Tom via wsjt-devel wrote:


Hi

There is no such path.  I am using omni-rig 1.19 just downloaded from 
the web at dxatlas.


The use of administrator mode only works for the 64 bit WSJT. The 32 
bit fails with both user and administrator mode.  Always failed to 
start the omnirig com server.


Tom

*From:*Bill Somerville via wsjt-devel 
*Sent:* Sunday, July 18, 2021 3:39 AM
*To:* wsjt-devel@lists.sourceforge.net
*Cc:* Bill Somerville 
*Subject:* Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni 
Rig COM server


Hi Tom,

thanks for the clarification. You didn't confirm which version of 
Omni-Rig you are using.


It would be interesting to see the Omni-Rig debug log for a test where 
WSJT-X claims it is unable to start the Omni-Rig COM server. To enable 
Omni-Rig debug logging put the following into the main Omni-Rig 
settings file "%AppData%\Afreet\Produxts\OmniRig\OmniRig.ini" at the top:


[Debug]
Log=1

The log file is called OmniRig.log and appears in the same 
"%AppData%\Afreet\Products\OmniRig\" directory.


73
Bill
G4WJS.

On 17/07/2021 00:42, tom via wsjt-devel wrote:

Hi

No, I don't think I said this right.

If you open omnirig while you monitor the serial port, the serial
port opens, then there's a little activity and then the port
closed. Omnirig remains open.

Starting wsjt with omnirig open or closed produces the same
result. Failed to start com server unless you run it as admin.

Tom

Sent from my Galaxy

 Original message 

From: Bill Somerville via wsjt-devel



Date: 2021-07-16 5:56 p.m. (GMT-05:00)

To: wsjt-devel@lists.sourceforge.net


Cc: Bill Somerville 


Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start
Omni Rig COM server

Hi Tom,

that's not how Omni-Rig behaves for me, if I start it manually the
setup dialog stays open until it is cancelled or closed with the
OK button. Starting WSJT-X to communicate with it doesn't change
that. What version of Omni-Rig are you using?

73
Bill
G4WJS.

On 16/07/2021 22:49, Tom via wsjt-devel wrote:

Hi

Omni-rig connects just fine to the radio.  When you open it
there is some initial comport activity then it closes.  All
this is normal.

It is completely reproducible on my system.  There is no issue
with any other application that uses Omni-rig.

On the groups.io list, there are people that have reported
this in the past.

73 Tom

*From:*Bill Somerville via wsjt-devel


*Sent:* Friday, July 16, 2021 4:03 PM
*To:* wsjt-devel@lists.sourceforge.net

*Cc:* Bill Somerville 

*Subject:* Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to
start Omni Rig COM server

Hi Tom,

OK, I've not see that behaviour. Are you able to reproduce it?
If yes, then does starting Omni-Rig manually before starting
WSJT-X work correctly?

73
Bill
G4WJS.

On 16/07/2021 20:59, tom via wsjt-devel wrote:

Hi

Actually no. When you start wsjt it immediately gives an
error saying failed to start omnirig com server. If you
monitor the serial port traffic, nothing happens at all.
No serial communications at all.

If you start wsjt as administrator it works without an
issue. This doesn't happen with any other software that
uses omnirig. It's strange because this always worked in
the 

[wsjt-devel] Possible bug between wsjtx and net Hamlib

[alawler mudhawk.com via wsjt-devel]

 HI Folks,

  I've encountered what seems to be a bug in how wsjtx uses the network hamlib 
functionality.I'm going to start with a simple symptom statement, then will 
include more supporting detail and the specific configuration etc.

The problem:
wsjtx does not work with a remotely connected Yaesu FT-736r using the Net 
Hamlib option.

Symptom:
During setup, when I set Hamlib NET Rigctl in the radioconfiguration 
information and click"Test Cat",  I get an error message box saying "Rig 
Failure"  "Hamlib error:  Feature not available while getting current 
frequency".


  What I think is happening is that for a locally connected radio,  wsjtx is 
"smart enough" to not send a "get frequency" command to the FT-736r,  however, 
in the Net Rigctld mode,  it makes an assumption that this is a relatively safe 
and widely supported way of testing basic communications and sends the command 
without first checking rig capabilities.

I believe this is the expected behavior from Hamlib,   since the FT-736r does 
not support this particular option.

  Configuration:
wsjtx-2.2.0 running on Ubuntu
The radio server is a Raspberry Pi running either rigctld 3.0  or rigctl-wsjtx 
4.0 (the behavior is the same.)

rigctld command:  rigctld-wsjtx -m 110 -r /dev/ttyUSB0 -s 4800 -t 10006 -v

Other test notes:
I am using port 10006 on purpose, but I don't believe that is related to the 
problem.

My raspberry Pi/rigctld server works fine with other FT-736r code that I have 
written, so I'm pretty sure the hardware and configuration are correct.

hamlib trace:
igctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
client lock disengaged

Trying the idential experiment using my FT-890 (ritctld -m 115)  which DOES 
have  a bidirectional CAT interface works fine.

  I am looking at the code with the hopes of just bypassing the frequency set 
command in my own local setup, but figured I'd mention this in case other folks 
might find it useful.

  Thanks for any consideration

--al
WB1BQE

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Tom via wsjt-devel]

Hi

There is no such path.  I am using omni-rig 1.19 just downloaded from the web 
at dxatlas.



The use of administrator mode only works for the 64 bit WSJT. The 32 bit fails 
with both user and administrator mode.  Always failed to start the omnirig com 
server.

Tom







From: Bill Somerville via wsjt-devel 
Sent: Sunday, July 18, 2021 3:39 AM
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



thanks for the clarification. You didn't confirm which version of Omni-Rig you 
are using.



It would be interesting to see the Omni-Rig debug log for a test where WSJT-X 
claims it is unable to start the Omni-Rig COM server. To enable Omni-Rig debug 
logging put the following into the main Omni-Rig settings file 
"%AppData%\Afreet\Produxts\OmniRig\OmniRig.ini" at the top:

[Debug]
Log=1

The log file is called OmniRig.log and appears in the same 
"%AppData%\Afreet\Products\OmniRig\" directory.



73
Bill
G4WJS.



On 17/07/2021 00:42, tom via wsjt-devel wrote:

Hi

No, I don't think I said this right.

If you open omnirig while you monitor the serial port, the serial port opens, 
then there's a little activity and then the port closed. Omnirig remains open.

Starting wsjt with omnirig open or closed produces the same result. Failed to 
start com server unless you run it as admin.



Tom





Sent from my Galaxy





 Original message 

From: Bill Somerville via wsjt-devel   


Date: 2021-07-16 5:56 p.m. (GMT-05:00)

To: wsjt-devel@lists.sourceforge.net 

Cc: Bill Somerville   

Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



that's not how Omni-Rig behaves for me, if I start it manually the setup dialog 
stays open until it is cancelled or closed with the OK button. Starting WSJT-X 
to communicate with it doesn't change that. What version of Omni-Rig are you 
using?



73
Bill
G4WJS.



On 16/07/2021 22:49, Tom via wsjt-devel wrote:

Hi

Omni-rig connects just fine to the radio.  When you open it there is some 
initial comport activity then it closes.  All this is normal.

It is completely reproducible on my system.  There is no issue with any other 
application that uses Omni-rig.

On the groups.io list, there are people that have reported this in the past.

73 Tom





From: Bill Somerville via wsjt-devel   

Sent: Friday, July 16, 2021 4:03 PM
To: wsjt-devel@lists.sourceforge.net 
Cc: Bill Somerville   
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



Hi Tom,



OK, I've not see that behaviour. Are you able to reproduce it? If yes, then 
does starting Omni-Rig manually before starting WSJT-X work correctly?



73
Bill
G4WJS.



On 16/07/2021 20:59, tom via wsjt-devel wrote:

Hi

Actually no. When you start wsjt it immediately gives an error saying failed to 
start omnirig com server. If you monitor the serial port traffic, nothing 
happens at all. No serial communications at all.

If you start wsjt as administrator it works without an issue. This doesn't 
happen with any other software that uses omnirig. It's strange because this 
always worked in the past.

73 Tom va2fsq







Sent from my Galaxy





 Original message 

From: Bill Somerville via wsjt-devel   


Date: 2021-07-16 3:36 p.m. (GMT-05:00)

To: wsjt-devel@lists.sourceforge.net 

Cc: Bill Somerville   

Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM 
server



On 16/07/2021 20:10, Tom via wsjt-devel wrote:
> I am the author of Win4IcomSuite and have started getting reports of WSJT
> failing to start the Omni-rig COM server.  This does not happen on all
> computers. In addition, it starts happening when no changes have been made
> to Omni-rig and WSJT.  Installing the latest versions does not correct the
> issue.
> To reproduce:
> Reboot your computer and make sure there are no other applications using
> omni-rig.
> Use Omni-rig definition for your Icom radio;. Start WSJT.  You receive the
> above error.
> Run WSJT as Administrator and it works.
>
> All other applications using Omni-rig work without putting them in
> administrator mode.  No other related software is running.  This is with a
> direct connection to the radio.
>
> Details, version 2.4.0 (happens on previous version as well).
> Windows 10, version 19041.1083
> 73 Tom va2fsq

Tom,

I am looking into this issue, you don't need to keep repeating your query.

So far I see one problem with startup when there is a fault condition
like the rig not being accessible, or if WSJT-X is closed down before it
has 

Re: [wsjt-devel] Possible feature request, time skew notification?

[Carey Fisher via wsjt-devel]

If you simply look at the waterfall, it's clearly obvious whether your
clock is off or not.
73, Carey, WB4HXE

On Sat, Jul 17, 2021 at 10:17 PM Paul Bramscher via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I was at a monthly outdoor ham event in the greater St. Paul/Minneapolis
> area that's drawn loyal attendance the past few years.  An operator
> setup FT8 outdoors, but had some issues getting it to decode.  We could
> tell it was getting sound from his port, but there was no decoding.
>
> He was using Windows, whereas I'm Linux only so wasn't much help.
> Another ham suggested he compare his system clock with his cellphone,
> and that fixed it.  I believe he said he was off by 5+ seconds.
>
> I'm wondering whether it might be possible, algorithmically to somehow
> detect that a person's clock may be out of sync and present a
> notification message.  Of course there's the DT/Time Delta column when
> you are able to decode.  But, presumably, he had reached the point of no
> return.
>
> I don't know how this might be possible without an accurate reference
> clock -- but possibly based on the average timing of heard signals, or
> some sort of signature within them, to cause a message to the user that
> s/he may want to check their clock's accuracy?
>
> Just wondering what might be possible in this regard, and I suspect it
> would help portable users, especially those who've been offline for a
> number of days/etc. and their system clocks had degraded.
>
> 73, KD0KZE / Paul
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
Carey Fisher
careyfis...@gmail.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] wsjt-x v2.5.0-rc3

[Conrad PA5Y via wsjt-devel]

This seems to be fixed now. I had to set the CODEC to single channel 48kHz and 
select LEFT in the wsjt audio settings, it has been running for over 24hrs 
without problems.

73

Conrad PA5Y

From: Conrad PA5Y via wsjt-devel 
Sent: 17 July 2021 13:59
To: WSJT software development 
Cc: Conrad PA5Y 
Subject: Re: [wsjt-devel] wsjt-x v2.5.0-rc3

This is a showstopper; the USB hubs are set so that power saving is not active. 
Does anybody have any ideas?

Regards

Conrad PA5Y


From: Conrad PA5Y via wsjt-devel 
mailto:wsjt-devel@lists.sourceforge.net>>
Sent: 17 July 2021 07:52
To: wsjt-devel@lists.sourceforge.net
Cc: Conrad PA5Y mailto:g0...@g0ruz.com>>
Subject: [wsjt-devel] wsjt-x v2.5.0-rc3

Good morning.

I have 2 instances of wsjt-x v2.5.0-rc3 running, one connected to a K3S and the 
other to a recently acquired TS-890S. The K3S audio input runs without problems 
for days, however the TS-890S does not. It fails after a short while. Usually 
stopping and restarting monitor restores the stream. Running the TS-890S on its 
own without the 2nd K3S instance makes no difference to the behaviour. 
Interestingly the 2 radios use the same audio drivers and com port drivers. If 
I use another type of software with the TS-890S the problem does not occur even 
after 30 hrs, which suggests that there is no hardware problem.

Are there some diagnostics I can run or file that I can provide to help with 
debugging? I will start on 6m EME very soon and I will need Q65.

Any help would be appreciated.

Regards

Conrad PA5Y
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Possible feature request, time skew notification?

[George J Molnar via wsjt-devel]

Wouldn’t a simple glance at the Wide Graph provide clear evidence of timing 
errors? Even without WWV, GPS, or software changes, it seems trivial to 
identify the error and walk in a correction.

George J Molnar
College Park, Maryland 
KF2T | FM19ma



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X 2.5.0-rc3 RST_RCVD logging issue

[Saku via wsjt-devel]

Rather good way to get qso one period faster. Important with VHF ES 
DXing (mostly 6m). Conditions change so fast.


There are not so many 4 character grids in Japan. And if callsign's QRZ 
or HamQTH entry is up to date external logger adds the locator, usually 
6 characters, or even more precise.


--
Saku
OH1KH

Derek Turner via wsjt-devel kirjoitti 17.7.2021 klo 9.33:
And why do JAs en mass ignore locators which are fundamental in FT8 
exchanges for the rest of us ?


73 de G4SWY Del +++


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] My problems while compiling from the source

[Bill Somerville via wsjt-devel]

On 18/07/2021 08:31, Claude Frantz via wsjt-devel wrote:

On 7/17/21 10:02 PM, Kari Sillanmäki via wsjt-devel wrote:

Hi Kari, Bill, Adrian and all,

This may not comfort you much, but just for fun and giggles I 
installed Debian Buster onto a virtual machine
and then cloned Hamlib and WSJT-X from git. Compiled, and got a 
working WSJT-X.


So *something* may not be right in your system. I have no idea what 
that could be though, sorry.


You are right, numerous problems are open after the migration from 32 
bit Fedora to 64 bit Debian. The hardest one is sendmail, which is 
really different.


In the build directory, I have tried to delete CMakeCache.txt and I 
have run cmake again. Strange error messages from cmake appeared. 
Then, I have deleted all the files and directories in the build 
directory and I have run cmake again. No error messages. Then make and 
the compilation ended without errors. Now, I will have to test the 
executable.


Many thanks to you all !

Best wishes,
Claude (DJ0OT) 


Hi Claude,

glad you have your build working. The issue was probably because CMake, 
like most build systems, does not track the versions of tool chain 
utilities so it does not know that build artifacts need rebuilding when 
the tools change. Deleting the whole build tree, re-configuring, and 
building again is the correct solution, deleting the CMakeCache.txt file 
is not sufficient.


73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni Rig COM server

[Bill Somerville via wsjt-devel]

Hi Tom,

thanks for the clarification. You didn't confirm which version of 
Omni-Rig you are using.


It would be interesting to see the Omni-Rig debug log for a test where 
WSJT-X claims it is unable to start the Omni-Rig COM server. To enable 
Omni-Rig debug logging put the following into the main Omni-Rig settings 
file "%AppData%\Afreet\Produxts\OmniRig\OmniRig.ini" at the top:


[Debug]
Log=1

The log file is called OmniRig.log and appears in the same 
"%AppData%\Afreet\Products\OmniRig\" directory.


73
Bill
G4WJS.

On 17/07/2021 00:42, tom via wsjt-devel wrote:

Hi
No, I don't think I said this right.
If you open omnirig while you monitor the serial port, the serial port 
opens, then there's a little activity and then the port closed. 
Omnirig remains open.
Starting wsjt with omnirig open or closed produces the same result. 
Failed to start com server unless you run it as admin.


Tom


Sent from my Galaxy


 Original message 
From: Bill Somerville via wsjt-devel 
Date: 2021-07-16 5:56 p.m. (GMT-05:00)
To: wsjt-devel@lists.sourceforge.net
Cc: Bill Somerville 
Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni 
Rig COM server


Hi Tom,

that's not how Omni-Rig behaves for me, if I start it manually the 
setup dialog stays open until it is cancelled or closed with the OK 
button. Starting WSJT-X to communicate with it doesn't change that. 
What version of Omni-Rig are you using?


73
Bill
G4WJS.

On 16/07/2021 22:49, Tom via wsjt-devel wrote:


Hi

Omni-rig connects just fine to the radio.  When you open it there is 
some initial comport activity then it closes.  All this is normal.


It is completely reproducible on my system.  There is no issue with 
any other application that uses Omni-rig.


On the groups.io list, there are people that have reported this in 
the past.


73 Tom

*From:*Bill Somerville via wsjt-devel 
*Sent:* Friday, July 16, 2021 4:03 PM
*To:* wsjt-devel@lists.sourceforge.net
*Cc:* Bill Somerville 
*Subject:* Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start Omni 
Rig COM server


Hi Tom,

OK, I've not see that behaviour. Are you able to reproduce it? If 
yes, then does starting Omni-Rig manually before starting WSJT-X work 
correctly?


73
Bill
G4WJS.

On 16/07/2021 20:59, tom via wsjt-devel wrote:

Hi

Actually no. When you start wsjt it immediately gives an error
saying failed to start omnirig com server. If you monitor the
serial port traffic, nothing happens at all. No serial
communications at all.

If you start wsjt as administrator it works without an issue.
This doesn't happen with any other software that uses omnirig.
It's strange because this always worked in the past.

73 Tom va2fsq

Sent from my Galaxy

 Original message 

From: Bill Somerville via wsjt-devel



Date: 2021-07-16 3:36 p.m. (GMT-05:00)

To: wsjt-devel@lists.sourceforge.net


Cc: Bill Somerville 


Subject: Re: [wsjt-devel] WSJT-X and Omni-Rig: Failed to start
Omni Rig COM server

On 16/07/2021 20:10, Tom via wsjt-devel wrote:
> I am the author of Win4IcomSuite and have started getting
reports of WSJT
> failing to start the Omni-rig COM server.  This does not happen
on all
> computers. In addition, it starts happening when no changes
have been made
> to Omni-rig and WSJT.  Installing the latest versions does not
correct the
> issue.
> To reproduce:
> Reboot your computer and make sure there are no other
applications using
> omni-rig.
> Use Omni-rig definition for your Icom radio;. Start WSJT.  You
receive the
> above error.
> Run WSJT as Administrator and it works.
>
> All other applications using Omni-rig work without putting them in
> administrator mode.  No other related software is running. 
This is with a
> direct connection to the radio.
>
> Details, version 2.4.0 (happens on previous version as well).
> Windows 10, version 19041.1083
> 73 Tom va2fsq

Tom,

I am looking into this issue, you don't need to keep repeating
your query.

So far I see one problem with startup when there is a fault
condition
like the rig not being accessible, or if WSJT-X is closed down
before it
has completed all the retries it attempts before reporting an error
(that takes up to 10 seconds). Is that consistent with what you are
reporting? If so, then if WSJT-X is left for 20 seconds or so to
do its
own thing does an error get reported?

73
Bill
G4WJS.



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] My problems while compiling from the source

[Claude Frantz via wsjt-devel]

On 7/17/21 10:02 PM, Kari Sillanmäki via wsjt-devel wrote:

Hi Kari, Bill, Adrian and all,

This may not comfort you much, but just for fun and giggles I installed 
Debian Buster onto a virtual machine
and then cloned Hamlib and WSJT-X from git. Compiled, and got a working 
WSJT-X.


So *something* may not be right in your system. I have no idea what that 
could be though, sorry.


You are right, numerous problems are open after the migration from 32 
bit Fedora to 64 bit Debian. The hardest one is sendmail, which is 
really different.


In the build directory, I have tried to delete CMakeCache.txt and I have 
run cmake again. Strange error messages from cmake appeared. Then, I 
have deleted all the files and directories in the build directory and I 
have run cmake again. No error messages. Then make and the compilation 
ended without errors. Now, I will have to test the executable.


Many thanks to you all !

Best wishes,
Claude (DJ0OT)



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Possible feature request, time skew notification?

[Alex Deligiannis via wsjt-devel]

I’m using a different approach, with a USB mouse GPS and the NMEATime2

from http://visualgps.net/index.html#nmeatime2-content 



I’m always on time.

73s

Alex

On 18/07/2021 07:58, Wolfgang K. Meister via wsjt-devel wrote:



Yes, there is a utility http://www.dxshell.com/jtsync.html that will
do exactly what you want. It syncs either via ntp or if there is no
network it is using a very clever methode do average received FT8/FT4
signals to set your clock. Extreme late or early transmissions in
time are ignored.

73s
Wolfgang OE1MWW


 Ursprüngliche Nachricht 
Von: Paul Bramscher via wsjt-devel 
Datum: So., 18. Juli 2021, 04:14
An: wsjt-devel@lists.sourceforge.net
Cc: Paul Bramscher 
Betreff: [wsjt-devel] Possible feature request, time skew notification?

I was at a monthly outdoor ham event in the greater St.
Paul/Minneapolis
area that's drawn loyal attendance the past few years.  An operator
setup FT8 outdoors, but had some issues getting it to decode. We could
tell it was getting sound from his port, but there was no decoding.

He was using Windows, whereas I'm Linux only so wasn't much help.
Another ham suggested he compare his system clock with his cellphone,
and that fixed it.  I believe he said he was off by 5+ seconds.

I'm wondering whether it might be possible, algorithmically to somehow
detect that a person's clock may be out of sync and present a
notification message.  Of course there's the DT/Time Delta column when
you are able to decode.  But, presumably, he had reached the point
of no
return.

I don't know how this might be possible without an accurate reference
clock -- but possibly based on the average timing of heard signals, or
some sort of signature within them, to cause a message to the user
that
s/he may want to check their clock's accuracy?

Just wondering what might be possible in this regard, and I suspect it
would help portable users, especially those who've been offline for a
number of days/etc. and their system clocks had degraded.

73, KD0KZE / Paul


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problems building on MacOS X 11.1 Intel

[Bill Somerville via wsjt-devel]

On 18/07/2021 03:31, Alex Lelievre via wsjt-devel wrote:

Hi there,

I’m running into an error in the fortran portion of the WSJT-X project 
on MacOS X.   I’m reaching out to see if anyone has bumped into this:


[ 17%] Built target record_time_signal
[ 17%] *Automatic MOC for target fort_qt*
[ 17%] Built target fort_qt_autogen
[ 17%] Built target fort_qt
[ 17%] Building Fortran object 
CMakeFiles/wsjt_fort_omp.dir/lib/packjt.f90.o

*gfortran:* *error: *unrecognized command-line option '*-Xclang*'
make[5]: *** [CMakeFiles/wsjt_fort_omp.dir/lib/packjt.f90.o] Error 1
make[4]: *** [CMakeFiles/wsjt_fort_omp.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
make[1]: *** [CMakeFiles/wsjtx-build.dir/all] Error 2
make: *** [all] Error 2
I’m not sure why -Xclang is being passed to the fortran compiler. 
 Calling gfortran with a test file and -Xclang option generates the 
same error.
I’m wondering if I misconfigured the project or perhaps I’m using the 
wrong tool chain?


Any help would be appreciated,
alex K6LOT


Hi Alex,

which Fortran compiler are you using and what version?

73
Bill
G4WJS.

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] My problems while compiling from the source

[Adrian via wsjt-devel]

Thankyou, however I see, to be compatible with install instructions ;

git clone git://git.code.sf.net/p/wsjt/wsjtx src

,however I adapted to suit, I note that linquist requires qttools5-dev 
installed.


Also    ;   cmake --build . --target install

should really show ;   sudo cmake --build . --target install


otherwise

CMake Error at cmake_install.cmake:52 (file):
  file INSTALL cannot copy file
  "/home/adrian/Downloads/wsjt-wsjtx/build/wsjtx" to 
"/usr/local/bin/wsjtx":

  Permission denied.


adrian@debian:~/Downloads/wsjt-wsjtx/build$ sudo cmake --build . 
--target install

[  0%] Automatic MOC for target qcp
[  0%] Built target qcp_autogen
[  0%] Built target qcp
[  0%] Getting source control system revision information
-- Checking for revision information
-- Checking for gitrevision information
-- refspec: refs/heads/master - SHA1: 7eac85
[  0%] Built target revisiontag
[  1%] Automatic MOC for target wsjt_qt
[  1%] Built target wsjt_qt_autogen
[ 10%] Built target wsjt_qt
[ 10%] Automatic MOC for target wsjtx_udp-static
[ 10%] Built target wsjtx_udp-static_autogen
[ 11%] Built target wsjtx_udp-static
[ 12%] Automatic MOC for target message_aggregator
[ 12%] Built target message_aggregator_autogen
[ 13%] Built target message_aggregator
[ 13%] Automatic MOC for target udp_daemon
[ 13%] Built target udp_daemon_autogen
[ 13%] Built target udp_daemon
[ 13%] Compressing Debian changelog
[ 13%] Built target debian
[ 13%] Automatic MOC for target wsjt_qtmm
[ 13%] Built target wsjt_qtmm_autogen
[ 13%] Built target wsjt_qtmm
[ 16%] Built target wsjt_cxx
[ 48%] Built target wsjt_fort_omp
[ 48%] Automatic MOC for target wsjtx
[ 48%] Built target wsjtx_autogen
[ 56%] Built target wsjtx
[ 56%] Automatic MOC for target record_time_signal
[ 56%] Built target record_time_signal_autogen
[ 57%] Built target record_time_signal
[ 57%] Built target fmeasure
[ 57%] Built target fcal
[ 89%] Built target wsjt_fort
[ 89%] Built target q65sim
[ 89%] Built target jt49sim
[ 90%] Built target jt9code
[ 91%] Built target test_q65
[ 91%] Built target jt65code
[ 92%] Built target q65code
[ 92%] Built target rtty_spec
[ 92%] Built target sumsim
[ 92%] Automatic MOC for target fort_qt
[ 92%] Built target fort_qt_autogen
[ 92%] Built target fort_qt
[ 92%] Built target jt4code
[ 92%] Built target fst4sim
[ 92%] Built target jt4sim
[ 92%] Automatic MOC for target jt9
[ 92%] Built target jt9_autogen
[ 92%] Built target jt9
[ 92%] Built target ldpcsim240_101
[ 93%] Built target ft4code
[ 93%] Built target ft4sim_mult
[ 93%] Built target ldpcsim240_74
[ 93%] Automatic MOC for target wsjtx_app_version
[ 93%] Built target wsjtx_app_version_autogen
[ 93%] Built target wsjtx_app_version
[ 94%] Built target jt65sim
[ 96%] Built target wsprd
[ 97%] Built target fmtave
[ 98%] Built target wsprsim
[100%] Built target ft8sim
[100%] Built target msk144code
[100%] Built target ft8code
[100%] Built target q65_ftn_test
[100%] Built target encode77
[100%] Built target ft4sim
[100%] Built target wsprcode
[100%] Built target msk144sim
[100%] Automatic MOC for target test_qt_helpers
[100%] Built target test_qt_helpers_autogen
[100%] Built target test_qt_helpers
Install the project...
-- Install configuration: "RELEASE"
-- Installing: /usr/local/bin/wsjtx
-- Installing: /usr/local/bin/udp_daemon
-- Installing: /usr/local/bin/message_aggregator
-- Installing: /usr/local/bin/wsjtx_app_version
-- Installing: /usr/local/bin/jt9
-- Installing: /usr/local/bin/wsprd
-- Installing: /usr/local/bin/fmtave
-- Installing: /usr/local/bin/fcal
-- Installing: /usr/local/bin/fmeasure
-- Installing: /usr/local/bin/ft8code
-- Installing: /usr/local/bin/jt65code
-- Installing: /usr/local/bin/jt9code
-- Installing: /usr/local/bin/jt4code
-- Installing: /usr/local/bin/msk144code
-- Installing: /usr/local/bin/q65code
-- Installing: /usr/local/bin/fst4sim
-- Installing: /usr/local/bin/q65sim
-- Installing: /usr/local/bin/rigctl-wsjtx
-- Installing: /usr/local/bin/rigctld-wsjtx
-- Installing: /usr/local/bin/rigctlcom-wsjtx
-- Installing: /usr/local/share/doc/wsjtx/README
-- Installing: /usr/local/share/doc/wsjtx/COPYING
-- Installing: /usr/local/share/doc/wsjtx/AUTHORS
-- Installing: /usr/local/share/doc/wsjtx/THANKS
-- Installing: /usr/local/share/doc/wsjtx/NEWS
-- Installing: /usr/local/share/doc/wsjtx/BUGS
-- Installing: /usr/local/share/wsjtx/cty.dat
-- Installing: /usr/local/share/wsjtx/cty.dat_copyright.txt
-- Installing: /usr/local/share/wsjtx/JPLEPH
-- Installing: /usr/local/share/doc/wsjtx/example_log_configurations
-- Installing: 
/usr/local/share/doc/wsjtx/example_log_configurations/wsjtx_log_config.ini.simple_verbose

-- Installing: /usr/local/share/doc/wsjtx/example_log_configurations/README
-- Installing: 
/usr/local/share/doc/wsjtx/example_log_configurations/wsjtx_log_config.ini.console
-- Installing: 
/usr/local/share/doc/wsjtx/example_log_configurations/wsjtx_log_config.ini.debugger
-- Installing: