date:20170729

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread C. Gary Rogers

This doesn’t seem to be working either:

Last login: Sat Jul 29 20:55:29 on ttys004
Charless-MacBook-Pro:~ charlesrogers$ cd ~/wsjtx-prefix/build
Charless-MacBook-Pro:build charlesrogers$ rm -r *
rm: *: No such file or directory
Charless-MacBook-Pro:build charlesrogers$ FC=gfortran-mp-5 \
>cmake \
>-D CMAKE_PREFIX_PATH=~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local \
>-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
>-D 
> CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
>  \
>~/wsjtx-prefix/src
CMake Error: The source directory 
"/Users/charlesrogers/wsjtx-prefix/build/CMAKE_PREFIX_PATH=/Users/charlesrogers/Qt/5.7/clang_64"
 does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
-bash: /Users/charlesrogers/hamlib-prefix: is a directory
-bash: /opt/local: is a directory
Charless-MacBook-Pro:build charlesrogers$ 



> On Jul 29, 2017, at 5:13 PM, Bill Somerville  wrote:
> 
> $ rm -r *

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] JTSDK install on Win10 fails

2017-07-29 Thread ki7mt via wsjt-devel

Hi Pete,

In order to keep JTSDK traffic off the WSJT/WSJT-Devel lists, I've setup a
message list to deal with JTSDK issues.  If you don't' have a Groups.io
account, you'll need to create it first at ( Groups.io ), then join
jt...@group.io

I'll forward your message to the group, and address it there.

73's
Greg, KI7MT

-Original Message-
From: Pete [mailto:pete...@shaw.ca] 
Sent: Saturday, July 29, 2017 2:51 PM
To: WSJT software development 
Subject: [wsjt-devel] JTSDK install on Win10 fails

I'm trying to get JTSDK installed on Win10. I've downloaded and installed
all the files (in the order prescribed) but run into a problem when I do the
update involving JTSDK Maintenance. As shown below, this step ends with the
message  "'C:\JTSDK\version.jtsdk' not resolved". 
Doing a 'version' after that gives me 2.0.3 instead of 2.0.5.

This is actually my second attempt at the install. I didn't notice this
problem the first time through and proceeded to try compiling WSJT-X but got
compilation errors in genmsk144.f90 so I'm trying again and noticed the
earlier failure this time.

Anyone know how I can fix this - preferably without having to uninstall
everything and start again :)

Thanks
Pete VE5VA



Dscripts\help\pyenv-help-wsjt.cmd
Dscripts\help\qtenv-help-map65.cmd
Dscripts\help\qtenv-help-wsprx.cmd
C version.jtsdk
Uscripts\cyg32\jtsdk-cyg32-install.cmd
Ascripts\build-hamlib3.cmd
Uscripts\qtenv-build-map65.cmd
Uscripts\qtenv-build-wsprx.cmd
Ascripts\svn-checkout.cmd
Ascripts\help\jtsdk-help.cmd
Uscripts\pyenv-build-wsjt.cmd
Uscripts\pyenv-build-wspr.cmd
Uscripts\qtenv-build-list.cmd
Uscripts\qtenv-build-wsjtx.cmd
Uscripts\README.md
Uscripts\docenv-alias-list.sh
Uscripts\docenv-header.sh
Uscripts\docenv-help-build.sh
Uscripts\docenv-help-co.sh
Uscripts\map65-toolchain.cmake
Uscripts\msys-alias-list.sh
Uscripts\msys-build-fftw.sh
Uscripts\msys-build-hamlib3.sh
Uscripts\msys-build-portaudio.sh
Uscripts\msys-build-samplerate.sh
Uscripts\pyenv-info.cmd
Uscripts\qtenv-info.cmd
Uscripts\wsjtx-util.cmd
Uqtenv.cmd
Upyenv.cmd
UChangeLog
Umaint.cmd
Cupdate.cmd
  U   .
Updated to revision 704.
Resolved conflicted state of 'update.cmd'
svn: E155027: Tree conflict can only be resolved to 'working' state;
'C:\JTSDK\version.jtsdk' not resolved

C:\JTSDK>



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread C. Gary Rogers

OK will try and report back probably tomorrow…Thanks for your help!

> On Jul 29, 2017, at 5:13 PM, Bill Somerville  wrote:
> 
> Hi Gary,
> 
> the Hamlib part looks fine. The error message from the cmake configuration 
> shows something is messed up. Cmake will not change some things when you 
> re-run the configuration pass so I think you need to delete the WSJT-X build 
> directory and start from the cmake configuration command again:
> 
> $ cd ~/wsjtx-prefix/build
> $ rm -r *
> $ FC=gfortran-mp-5 cmake -D CMAKE_PREFIX_PATH= ...
> 
> 73
> Bill
> G4WJS.
> 
> On 29/07/2017 21:28, C. Gary Rogers wrote:
>> Bill, i followed the instructions in your install directions:
>> 
>> $ mkdir -p ~/hamlib-prefix/build
>> $ cd ~/hamlib-prefix
>> $ git clone git://git.code.sf.net/u/bsomervi/hamlib 
>>  src
>> $ cd src
>> $ git checkout integration
>> Then
>> 
>> $ cd ~/hamlib-prefix/build
>> $ ../src/autogen.sh \
>>--enable-static \
>>--disable-shared \
>>--disable-winradio \
>>--prefix=$HOME/hamlib-prefix \
>>CFLAGS="-mmacosx-version-min=10.7 -I/opt/local/include" \
>>LIBUSB_LIBS="-L/opt/local/lib -lusb-1.0"
>> $ make
>> $ make install-strip
>> 
>> I can see them at users/charlesrogers/hamlib-prefix
>> 
>> 
>>> On Jul 29, 2017, at 4:15 PM, Bill Somerville >> > wrote:
>>> 
>>> On 29/07/2017 19:27, C. Gary Rogers wrote:
 I still don’t have it right…I took out the two quotation marks…Here is 
 what i did:
 
 Last login: Sat Jul 29 14:15:13 on ttys001
 Charless-MacBook-Pro:~ charlesrogers$ cd ~/wsjtx-prefix/build
 Charless-MacBook-Pro:build charlesrogers$  FC=gfortran-mp-5 \
 >cmake \
 >-D CMAKE_PREFIX_PATH=~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local \
 >-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
 >-D 
 > CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
 >  \
 >~/wsjtx-prefix/src
 CMake Error: The source directory 
 "/Users/charlesrogers/wsjtx-prefix/build/CMAKE_PREFIX_PATH=/Users/charlesrogers/Qt/5.7/clang_64"
  does not exist.
 Specify --help for usage, or press the help button on the CMake GUI.
 -bash: /Users/charlesrogers/hamlib-prefix: is a directory
 -bash: /opt/local: is a directory
 Charless-MacBook-Pro:build charlesrogers$ 
 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread Bill Somerville


Hi Gary,

the Hamlib part looks fine. The error message from the cmake 
configuration shows something is messed up. Cmake will not change some 
things when you re-run the configuration pass so I think you need to 
delete the WSJT-X build directory and start from the cmake configuration 
command again:


$ cd ~/wsjtx-prefix/build
$ rm -r *
$ FC=gfortran-mp-5 cmake -D CMAKE_PREFIX_PATH= ...

73
Bill
G4WJS.

On 29/07/2017 21:28, C. Gary Rogers wrote:

Bill, i followed the instructions in your install directions:

$ mkdir -p ~/hamlib-prefix/build
$ cd ~/hamlib-prefix
$ git clonegit://git.code.sf.net/u/bsomervi/hamlib  src
$ cd src
$ git checkout integration
Then

$ cd ~/hamlib-prefix/build
$ ../src/autogen.sh \
--enable-static \
--disable-shared \
--disable-winradio \
--prefix=$HOME/hamlib-prefix \
CFLAGS="-mmacosx-version-min=10.7 -I/opt/local/include" \
LIBUSB_LIBS="-L/opt/local/lib -lusb-1.0"
$ make
$ make install-strip

I can see them at users/charlesrogers/hamlib-prefix


On Jul 29, 2017, at 4:15 PM, Bill Somerville > wrote:


On 29/07/2017 19:27, C. Gary Rogers wrote:
I still don’t have it right…I took out the two quotation marks…Here 
is what i did:


Last login: Sat Jul 29 14:15:13 on ttys001
Charless-MacBook-Pro:~ charlesrogers$ cd ~/wsjtx-prefix/build
Charless-MacBook-Pro:build charlesrogers$  FC=gfortran-mp-5 \
>cmake \
>-D CMAKE_PREFIX_PATH=~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local \
>-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
>-D 
CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
 \
>   ~/wsjtx-prefix/src
CMake Error: The source directory 
"/Users/charlesrogers/wsjtx-prefix/build/CMAKE_PREFIX_PATH=/Users/charlesrogers/Qt/5.7/clang_64" 
does not exist.

Specify --help for usage, or press the help button on the CMake GUI.
-bash: /Users/charlesrogers/hamlib-prefix: is a directory
-bash: /opt/local: is a directory
Charless-MacBook-Pro:build charlesrogers$



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread C. Gary Rogers

So i see the quotation marks below…I took them out and reran and it seemed to 
work so i tried:

$ cmake --build .
$ cmake --build . --target install
And i got


Last login: Sat Jul 29 17:04:57 on ttys003
Charless-MacBook-Pro:~ charlesrogers$ cmake --build .
Error: could not load cache
Charless-MacBook-Pro:~ charlesrogers$ cmake --build . --target install

Thoughts?

> On Jul 29, 2017, at 4:28 PM, C. Gary Rogers  wrote:
> 
> Bill, i followed the instructions in your install directions:
> 
> $ mkdir -p ~/hamlib-prefix/build
> $ cd ~/hamlib-prefix
> $ git clone git://git.code.sf.net/u/bsomervi/hamlib 
>  src
> $ cd src
> $ git checkout integration
> Then
> 
> $ cd ~/hamlib-prefix/build
> $ ../src/autogen.sh \
>--enable-static \
>--disable-shared \
>--disable-winradio \
>--prefix=$HOME/hamlib-prefix \
>CFLAGS="-mmacosx-version-min=10.7 -I/opt/local/include" \
>LIBUSB_LIBS="-L/opt/local/lib -lusb-1.0"
> $ make
> $ make install-strip
> 
> I can see them at users/charlesrogers/hamlib-prefix
> 
> 
>> On Jul 29, 2017, at 4:15 PM, Bill Somerville > > wrote:
>> 
>> On 29/07/2017 19:27, C. Gary Rogers wrote:
>>> I still don’t have it right…I took out the two quotation marks…Here is what 
>>> i did:
>>> 
>>> Last login: Sat Jul 29 14:15:13 on ttys001
>>> Charless-MacBook-Pro:~ charlesrogers$ cd ~/wsjtx-prefix/build
>>> Charless-MacBook-Pro:build charlesrogers$  FC=gfortran-mp-5 \
>>> >cmake \
>>> >-D CMAKE_PREFIX_PATH=~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local \
>>> >-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
>>> >-D 
>>> > CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
>>> >  \
>>> >~/wsjtx-prefix/src
>>> CMake Error: The source directory 
>>> "/Users/charlesrogers/wsjtx-prefix/build/CMAKE_PREFIX_PATH=/Users/charlesrogers/Qt/5.7/clang_64"
>>>  does not exist.
>>> Specify --help for usage, or press the help button on the CMake GUI.
>>> -bash: /Users/charlesrogers/hamlib-prefix: is a directory
>>> -bash: /opt/local: is a directory
>>> Charless-MacBook-Pro:build charlesrogers$ 
>>> 
>>> Did i misunderstand?
>> Hi Gary,
>> 
>> can your share the commands you used to build Hamlib please?
>> 
>> 73
>> Bill
>> G4WJS.
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org ! 
>> http://sdm.link/slashdot___ 
>> 
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] JTSDK install on Win10 fails

2017-07-29 Thread Pete

I'm trying to get JTSDK installed on Win10. I've downloaded and 
installed all the files (in the order prescribed) but run into a problem 
when I do the update involving JTSDK Maintenance. As shown below, this 
step ends with the message  "'C:\JTSDK\version.jtsdk' not resolved". 
Doing a 'version' after that gives me 2.0.3 instead of 2.0.5.


This is actually my second attempt at the install. I didn't notice this 
problem the first time through and proceeded to try compiling WSJT-X but 
got compilation errors in genmsk144.f90 so I'm trying again and noticed 
the earlier failure this time.


Anyone know how I can fix this - preferably without having to uninstall 
everything and start again :)


Thanks
Pete VE5VA



Dscripts\help\pyenv-help-wsjt.cmd
Dscripts\help\qtenv-help-map65.cmd
Dscripts\help\qtenv-help-wsprx.cmd
   C version.jtsdk
Uscripts\cyg32\jtsdk-cyg32-install.cmd
Ascripts\build-hamlib3.cmd
Uscripts\qtenv-build-map65.cmd
Uscripts\qtenv-build-wsprx.cmd
Ascripts\svn-checkout.cmd
Ascripts\help\jtsdk-help.cmd
Uscripts\pyenv-build-wsjt.cmd
Uscripts\pyenv-build-wspr.cmd
Uscripts\qtenv-build-list.cmd
Uscripts\qtenv-build-wsjtx.cmd
Uscripts\README.md
Uscripts\docenv-alias-list.sh
Uscripts\docenv-header.sh
Uscripts\docenv-help-build.sh
Uscripts\docenv-help-co.sh
Uscripts\map65-toolchain.cmake
Uscripts\msys-alias-list.sh
Uscripts\msys-build-fftw.sh
Uscripts\msys-build-hamlib3.sh
Uscripts\msys-build-portaudio.sh
Uscripts\msys-build-samplerate.sh
Uscripts\pyenv-info.cmd
Uscripts\qtenv-info.cmd
Uscripts\wsjtx-util.cmd
Uqtenv.cmd
Upyenv.cmd
UChangeLog
Umaint.cmd
Cupdate.cmd
 U   .
Updated to revision 704.
Resolved conflicted state of 'update.cmd'
svn: E155027: Tree conflict can only be resolved to 'working' state; 
'C:\JTSDK\version.jtsdk' not resolved


C:\JTSDK>


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread C. Gary Rogers

Bill, i followed the instructions in your install directions:

$ mkdir -p ~/hamlib-prefix/build
$ cd ~/hamlib-prefix
$ git clone git://git.code.sf.net/u/bsomervi/hamlib src
$ cd src
$ git checkout integration
Then

$ cd ~/hamlib-prefix/build
$ ../src/autogen.sh \
   --enable-static \
   --disable-shared \
   --disable-winradio \
   --prefix=$HOME/hamlib-prefix \
   CFLAGS="-mmacosx-version-min=10.7 -I/opt/local/include" \
   LIBUSB_LIBS="-L/opt/local/lib -lusb-1.0"
$ make
$ make install-strip

I can see them at users/charlesrogers/hamlib-prefix


> On Jul 29, 2017, at 4:15 PM, Bill Somerville  wrote:
> 
> On 29/07/2017 19:27, C. Gary Rogers wrote:
>> I still don’t have it right…I took out the two quotation marks…Here is what 
>> i did:
>> 
>> Last login: Sat Jul 29 14:15:13 on ttys001
>> Charless-MacBook-Pro:~ charlesrogers$ cd ~/wsjtx-prefix/build
>> Charless-MacBook-Pro:build charlesrogers$  FC=gfortran-mp-5 \
>> >cmake \
>> >-D CMAKE_PREFIX_PATH=~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local \
>> >-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
>> >-D 
>> > CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
>> >  \
>> >~/wsjtx-prefix/src
>> CMake Error: The source directory 
>> "/Users/charlesrogers/wsjtx-prefix/build/CMAKE_PREFIX_PATH=/Users/charlesrogers/Qt/5.7/clang_64"
>>  does not exist.
>> Specify --help for usage, or press the help button on the CMake GUI.
>> -bash: /Users/charlesrogers/hamlib-prefix: is a directory
>> -bash: /opt/local: is a directory
>> Charless-MacBook-Pro:build charlesrogers$ 
>> 
>> Did i misunderstand?
> Hi Gary,
> 
> can your share the commands you used to build Hamlib please?
> 
> 73
> Bill
> G4WJS.
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread Bill Somerville


On 29/07/2017 19:27, C. Gary Rogers wrote:
I still don’t have it right…I took out the two quotation marks…Here is 
what i did:


Last login: Sat Jul 29 14:15:13 on ttys001
Charless-MacBook-Pro:~ charlesrogers$ cd ~/wsjtx-prefix/build
Charless-MacBook-Pro:build charlesrogers$  FC=gfortran-mp-5 \
>cmake \
>-D CMAKE_PREFIX_PATH=~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local \
>-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
>-D 
CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
 \
>~/wsjtx-prefix/src
CMake Error: The source directory 
"/Users/charlesrogers/wsjtx-prefix/build/CMAKE_PREFIX_PATH=/Users/charlesrogers/Qt/5.7/clang_64" 
does not exist.

Specify --help for usage, or press the help button on the CMake GUI.
-bash: /Users/charlesrogers/hamlib-prefix: is a directory
-bash: /opt/local: is a directory
Charless-MacBook-Pro:build charlesrogers$

Did i misunderstand?


Hi Gary,

can your share the commands you used to build Hamlib please?

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread C. Gary Rogers

Part of the problem must be that i’m using QT 5.9.1

> On Jul 29, 2017, at 2:27 PM, C. Gary Rogers  wrote:
> 
> I still don’t have it right…I took out the two quotation marks…Here is what i 
> did:
> 
> Last login: Sat Jul 29 14:15:13 on ttys001
> Charless-MacBook-Pro:~ charlesrogers$ cd ~/wsjtx-prefix/build
> Charless-MacBook-Pro:build charlesrogers$  FC=gfortran-mp-5 \
> >cmake \
> >-D CMAKE_PREFIX_PATH=~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local \
> >-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
> >-D 
> > CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
> >  \
> >~/wsjtx-prefix/src
> CMake Error: The source directory 
> "/Users/charlesrogers/wsjtx-prefix/build/CMAKE_PREFIX_PATH=/Users/charlesrogers/Qt/5.7/clang_64"
>  does not exist.
> Specify --help for usage, or press the help button on the CMake GUI.
> -bash: /Users/charlesrogers/hamlib-prefix: is a directory
> -bash: /opt/local: is a directory
> Charless-MacBook-Pro:build charlesrogers$ 
> 
> Did i misunderstand?
> 
> 
>> On Jul 29, 2017, at 1:01 PM, Bill Somerville > > wrote:
>> 
>>> $ cd ~/wsjtx-prefix/build
>>> $ FC=gfortran-mp-5 \
>>>cmake \
>>>-D CMAKE_PREFIX_PATH="~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local" \
>>>-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
>>>-D 
>>> CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
>>>  \
>>>~/wsjtx-prefix/src
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread C. Gary Rogers

I still don’t have it right…I took out the two quotation marks…Here is what i 
did:

Last login: Sat Jul 29 14:15:13 on ttys001
Charless-MacBook-Pro:~ charlesrogers$ cd ~/wsjtx-prefix/build
Charless-MacBook-Pro:build charlesrogers$  FC=gfortran-mp-5 \
>cmake \
>-D CMAKE_PREFIX_PATH=~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local \
>-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
>-D 
> CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
>  \
>~/wsjtx-prefix/src
CMake Error: The source directory 
"/Users/charlesrogers/wsjtx-prefix/build/CMAKE_PREFIX_PATH=/Users/charlesrogers/Qt/5.7/clang_64"
 does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
-bash: /Users/charlesrogers/hamlib-prefix: is a directory
-bash: /opt/local: is a directory
Charless-MacBook-Pro:build charlesrogers$ 

Did i misunderstand?


> On Jul 29, 2017, at 1:01 PM, Bill Somerville  wrote:
> 
>> $ cd ~/wsjtx-prefix/build
>> $ FC=gfortran-mp-5 \
>>cmake \
>>-D CMAKE_PREFIX_PATH="~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local" \
>>-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
>>-D 
>> CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
>>  \
>>~/wsjtx-prefix/src

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r7969: AP: calls out of the blue

2017-07-29 Thread Jay Hainline

Will this information be placed in the User Guide? I think it would be an 
excellent reference on what the indicators mean.

 

73 Jay KA9CFD

 

From: Steven Franke [mailto:s.j.fra...@icloud.com] 
Sent: July 29, 2017 14:33
To: Joe Taylor 
Subject: Re: [wsjt-devel] r7969: AP: calls out of the blue

 

Hi Richard and Bill,

Adding to what BIll has said.

(i) The attached screenshot of the waterfall shows that the false decode at 
1055 Hz was produced based on a signal that existed for less than half of the 
interval.

 



Thus, at least half of the symbols were missing. Nevertheless, the signal was 
strong enough so that sync was achieved - probably on the basis of only the 
tail-end group of sync symbols.

(ii) The “a3” indicator tells us that for this decode the decoder hypothesized 
that the first 28-bits (the “MyCall” bits) of the 87-bit message frame were 
known, and were equal to your callsign, G4DYA. This is what Bill means by 
“masking” — we “mask” the 28 MyCall bits and temporarily fix them at “known” 
values. We then let the decoder do its thing and see if it can come up with a 
codeword that contains the hypothetical AP bits and that has few differences 
from the rest of the received bits. Any codeword that is produced as a result 
of this operation is going to have MyCall bits that map to G4DYA, because those 
bits were “hardwired” for the decoding attempt in question.

For the hypothetical bits we use only information that is known intrinsically 
(MyCall) or that is gathered during an ongoing QSO when applying AP decoding. 
Such information includes DxCall and the current state of the QSO. For example, 
after we have sent a “R-20” report, we know that a likely response is RRR, 73, 
or RR73. No reference is made to any other information.

For reference, here is the table of possible AP decoding types:

iaptype

  1CQ ??????
  2DE ??????
  3MyCall ??????
  4MyCall DxCall ???
  5MyCall DxCall RRR
  6MyCall DxCall 73
  7MyCall DxCall RR73
  8???DxCall ???

At present, types 2 and 8 are not used. The “a3” designator says that an AP 
type 3 attempt produced the decode. As already noted, type 3 looks for decodes 
of the form “MyCall ??? ???”. Thus, any decode that is produced as a result of 
a type 3 attempt is going to contain “MyCall”. Similarly, any decode that 
results from a type 4, 5, 6, or 7 attempt is going to contain MyCall and 
DxCall, where DxCall is whatever callsign is currently in the Dx Call box. In 
fact, an AP type 5 decode will always be of the form “MyCall DxCall RRR”, etc.

Back to the "? a3” decode in question. A type 3 AP decoding attempt does not 
use any information from the DX Call box. Thus, the DXCall found in a false 
“a3” decode is usually implausible and rarely corresponds to the printed 
4-digit locator. Richard's example is a rare case, indeed, as both the callsign 
and grid locator were plausible. I would wager that VE3SMB, if s/he exists, was 
not transmitting at the time that this decode was produced. Instead, in this 
case, the printed DxCall is a spectre, produced by random chance, along with 
the plausible grid locator.

As to why we might be willing to tolerate these potentially confusing false 
decodes; it is inevitable that when we dig deepest to decode the weakest (or 
most garbled by interference or truncation) received words the ratio of good to 
bad decodes is going to go down. For regular “non-AP” decodes, that ratio is 
very large, maybe 10^5 or even larger. Down near the decoding threshold, when 
the deep decoder and AP are in use, the good/bad ratio may fall to 100 or so. 
Nevertheless, eliminating the AP decoding attempts would remove hundreds of 
good decodes for every bad decode that is removed. Rather than do that, we 
provide the “?” quality indicator. The presence of the “?” in the decode tells 
you to watch out — it should be interpreted as meaning that this decode has a 
higher-than-you-are-used-to chance of being incorrect, and that you should 
consider context, the “type” of AP that was in use, and any other available 
information (such as the appearance of the signal on the waterfall) to decide 
whether or not to trust the decode.  When in doubt, you may want to wait for a 
second decode from the station in question before transmitting in response to a 
questionable AP decode. 

I’ll end this with an example showing a QSO that I made last night that 
benefited from the use of AP:



In this example, the “Roger” and “73” messages from VA6SP had SNRs of -20 dB 
and -22 dB, respectively. The “RRR” decode was obtained using AP type 4, 
meaning that the decoder used the known values of MyCall and DxCall, and it 
found a codeword that was consistent with these values *and* that contained an 
RRR. It did not assume that “RRR” would be present. There was no “?” printed, 
so this means that the decoder was

[wsjt-devel] QRA64 Auto-sequence Patch

2017-07-29 Thread Charles Suckling

Hi All

 

I have posted a small  patch to allow QRA64 to operate with auto-sequencing
here:

 

https://drive.google.com/file/d/0B116IwQIUFNTT1hLTU9Idjl5UDQ/view?usp=sharin
g

 

It is compatible with r7970.

 

Having seen autosequencing work very well on FT8, I felt that this facility
could also be of benefit for microwave EME,  where solo operator workload
can at some times be quite  high.  

 

It was tested satisfactorily this morning between VK7MO and myself on 10GHz
EME, with auto-sequencing operating at my end.  Normal QSO procedure
including answering a CQ call was tested.

 

Rex was also  able to determine his 'current' signal at my end by sending a
[call call report] message], to which auto-sequencing replied with [call
call R report] indicating his level at my end for the previous decode.  

 

While reports sent are not sticky, I don't see any issue with this as
averaging is not used on QRA64. 

 

73

 

Charlie

 

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r7969: AP: calls out of the blue

2017-07-29 Thread Steven Franke

Ady,

The title of this thread begins with “r7969”. As such, reports about “r7959” 
are not particularly relevant.

If you read the commit messages and study the associated code changes between 
r7959 and r7969 you will notice that AP decoding has been extensively revised 
since r7959. As such, I believe that your observation probably does not apply 
to the current version. If you find otherwise, let me know and I’ll be happy to 
take a look.

FYI, in r7959 Bill had not yet implemented his nifty QSO Progress 
state-machine, which is a key component of how AP works in the latest 
revisions, as the state-machine informs the decoder about what type of AP 
decoding makes sense, given the current “state” of the QSO. Prior to the 
existence of this state-machine, the only information that was used was whether 
or not the Dx Call box was empty. Thus, the behavior that you are seeing. Also, 
AP types were numbered differently back in that early revision…

Steve k9an

> On Jul 29, 2017, at 12:28 PM, Adrian Fabry  wrote:
> 
> Hi all,
>  
> Speaking of AP types, just got an “a3” for a CQ:
>  
> 171230 -16  0.4  494 ~  CQ PA0O JO33   a3
>  
> PA0O was into the DX call box.
> If I clear DX box, decode the wav with a1:
>  
> 171230 -16  0.4  494 ~  CQ PA0O JO33   a1
>  
> Put back PA0O in the DX box, decode again a3.
>  
> Using R7959 on Win Xp SP3
> The wav file attached.
>  
> 73 Ady,
> YO2NAA
>  
> From: Steven Franke [mailto:s.j.fra...@icloud.com] 
> Sent: Saturday, July 29, 2017 5:33 PM
> To: Joe Taylor
> Subject: Re: [wsjt-devel] r7969: AP: calls out of the blue
>  
> Hi Richard and Bill,
> 
> Adding to what BIll has said.
> 
> (i) The attached screenshot of the waterfall shows that the false decode at 
> 1055 Hz was produced based on a signal that existed for less than half of the 
> interval.
>  
> 
> 
> Thus, at least half of the symbols were missing. Nevertheless, the signal was 
> strong enough so that sync was achieved - probably on the basis of only the 
> tail-end group of sync symbols.
> 
> (ii) The “a3” indicator tells us that for this decode the decoder 
> hypothesized that the first 28-bits (the “MyCall” bits) of the 87-bit message 
> frame were known, and were equal to your callsign, G4DYA. This is what Bill 
> means by “masking” — we “mask” the 28 MyCall bits and temporarily fix them at 
> “known” values. We then let the decoder do its thing and see if it can come 
> up with a codeword that contains the hypothetical AP bits and that has few 
> differences from the rest of the received bits. Any codeword that is produced 
> as a result of this operation is going to have MyCall bits that map to G4DYA, 
> because those bits were “hardwired” for the decoding attempt in question.
> 
> For the hypothetical bits we use only information that is known intrinsically 
> (MyCall) or that is gathered during an ongoing QSO when applying AP decoding. 
> Such information includes DxCall and the current state of the QSO. For 
> example, after we have sent a “R-20” report, we know that a likely response 
> is RRR, 73, or RR73. No reference is made to any other information.
> 
> For reference, here is the table of possible AP decoding types:
> 
> iaptype
> 
>   1CQ ??????
>   2DE ??????
>   3MyCall ??????
>   4MyCall DxCall ???
>   5MyCall DxCall RRR
>   6MyCall DxCall 73
>   7MyCall DxCall RR73
>   8???DxCall ???
> 
> At present, types 2 and 8 are not used. The “a3” designator says that an AP 
> type 3 attempt produced the decode. As already noted, type 3 looks for 
> decodes of the form “MyCall ??? ???”. Thus, any decode that is produced as a 
> result of a type 3 attempt is going to contain “MyCall”. Similarly, any 
> decode that results from a type 4, 5, 6, or 7 attempt is going to contain 
> MyCall and DxCall, where DxCall is whatever callsign is currently in the Dx 
> Call box. In fact, an AP type 5 decode will always be of the form “MyCall 
> DxCall RRR”, etc.
> 
> Back to the "? a3” decode in question. A type 3 AP decoding attempt does not 
> use any information from the DX Call box. Thus, the DXCall found in a false 
> “a3” decode is usually implausible and rarely corresponds to the printed 
> 4-digit locator. Richard's example is a rare case, indeed, as both the 
> callsign and grid locator were plausible. I would wager that VE3SMB, if s/he 
> exists, was not transmitting at the time that this decode was produced. 
> Instead, in this case, the printed DxCall is a spectre, produced by random 
> chance, along with the plausible grid locator.
> 
> As to why we might be willing to tolerate these potentially confusing false 
> decodes; it is inevitable that when we dig deepest to decode the weakest (or 
> most garbled by interference or truncation) received words the ratio of good 
> to bad decodes is going to go down. For regular “non-AP” decodes, that ratio 
> is very

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread C. Gary Rogers

Ok will give it a try. Thanks 

Sent from my iPhone

> On Jul 29, 2017, at 1:01 PM, Bill Somerville  wrote:
> 
>> On 29/07/2017 17:34, C. Gary Rogers wrote:
>> Hello all, i’ve been following Bill’s instructions on compiling WSJT-X on 
>> MacBook Pro OS X 10.12.5
>> 
>> All is successful until i attempt:
>> 
>> $ cd ~/wsjtx-prefix/build
>> $ FC=gfortran-mp-5 \
>>cmake \
>>-D CMAKE_PREFIX_PATH="~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local" \
>>-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
>>-D 
>> CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
>>  \
>>~/wsjtx-prefix/src
> Hi Gary,
> 
> the issue is the quotation marks on the CMAKE_PREFIX_PATH variable 
> assignment, they should not be there and are turning it into a single string 
> rather that a path list separated by ';' characters.
> 
> 73
> Bill
> G4WJS.
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread Richard Bown

ignore, Bill posted same time


On Sat, 29 Jul 2017 18:09:11 +0100
Richard Bown  wrote:

> Hi Gary
> there are two ways to get around this
> 
> when you build hamlib use the switches to set the install to where the wsjtx 
> build is expecting to
> find it.
> or 
> in the directories its looking for hamlib, use a symlink to point to the 
> actual location of where
> hamlib is installed.
>  Hope you understand what I mean, GL
> 
> 
> On Sat, 29 Jul 2017 12:34:06 -0400
> "C. Gary Rogers"  wrote:
> 
> > Hello all, i’ve been following Bill’s instructions on compiling WSJT-X on 
> > MacBook Pro OS X
> > 10.12.5
> > 
> > All is successful until i attempt:
> > 
> > $ cd ~/wsjtx-prefix/build
> > $ FC=gfortran-mp-5 \
> >cmake \
> >-D CMAKE_PREFIX_PATH="~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local" \
> >-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
> >-D
> > CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
> > \ ~/wsjtx-prefix/src This is the result:
> > 
> > Last login: Sat Jul 29 11:56:56 on ttys001
> > Charless-MacBook-Pro:~ charlesrogers$ cd ~/wsjtx-prefix/build
> > Charless-MacBook-Pro:build charlesrogers$  FC=gfortran-mp-5 \  
> > >cmake \
> > >-D CMAKE_PREFIX_PATH="~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local" \
> > >-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
> > >-D
> > > CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
> > > \ ~/wsjtx-prefix/src
> > -- Building wsjtx-1.7.1-devel
> > -- **
> > -- Building for for: Darwin-x86_64
> > -- **
> > -- Boost version: 1.63.0
> > -- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) 
> > (found version "1.0")
> > -- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS 
> > OpenMP_CXX_LIB_NAMES) (found version
> > "1.0") -- Checking for module 'hamlib'
> > --   No package 'hamlib' found
> > hamlib_INCLUDEDIR=hamlib_INCLUDEDIR-NOTFOUND
> > hamlib_LIBRARY=hamlib_LIBRARY-NOTFOUND
> > hamlib_EXTRA_LIBRARIES=/opt/local/lib/libusb-1.0.dylib;m;dl
> > CMake Error at CMake/Modules/LibFindMacros.cmake:87 (message):
> >   Required library hamlib NOT FOUND.
> > 
> >   Install the library (dev version) and try again.  If the library is 
> > already
> >   installed, use ccmake to set the missing variables manually.
> > Call Stack (most recent call first):
> >   CMake/Modules/Findhamlib.cmake:69 (libfind_process)
> >   CMakeLists.txt:848 (find_package)
> > 
> > 
> > -- Configuring incomplete, errors occurred!
> > See also 
> > "/Users/charlesrogers/wsjtx-prefix/build/CMakeFiles/CMakeOutput.log".
> > Charless-MacBook-Pro:build charlesrogers$ 
> > 
> > Log is attached here:
> > 
> > 
> > 
> > I rebuilt hamlib which indicated that it was OK and reran with same 
> > result…Not exactly sure how
> > to:
> > 
> > use ccmake to set the missing variables manually.
> > Call Stack (most recent call first):
> >   CMake/Modules/Findhamlib.cmake:69 (libfind_process)
> >   CMakeLists.txt:848 (find_package)
> > 
> > Any suggestions as to how to resolve?
> > 
> > Thanks Gary KO3F
> > 
> > 
> >   
> 
> 
> 



-- 
-- 
Best wishes /73 
Richard Bown

Email : rich...@g8jvm.com
HTTP  :  http://www.g8jvm.com
nil carborundum a illegitemis
##
Ham Call: G8JVM . QRV: 50-432 MHz + Microwave 23 cms 140W, 13 cms 100W & 3cms 5W
Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W
QRV VHF 6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W
OS: Linux Mint 18.1  x86_64 on a Dell Inspiron N5030 laptop
##
 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread Richard Bown

Hi Gary
there are two ways to get around this

when you build hamlib use the switches to set the install to where the wsjtx 
build is expecting to
find it.
or 
in the directories its looking for hamlib, use a symlink to point to the actual 
location of where
hamlib is installed.
 Hope you understand what I mean, GL


On Sat, 29 Jul 2017 12:34:06 -0400
"C. Gary Rogers"  wrote:

> Hello all, i’ve been following Bill’s instructions on compiling WSJT-X on 
> MacBook Pro OS X 10.12.5
> 
> All is successful until i attempt:
> 
> $ cd ~/wsjtx-prefix/build
> $ FC=gfortran-mp-5 \
>cmake \
>-D CMAKE_PREFIX_PATH="~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local" \
>-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
>-D
> CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
> \ ~/wsjtx-prefix/src This is the result:
> 
> Last login: Sat Jul 29 11:56:56 on ttys001
> Charless-MacBook-Pro:~ charlesrogers$ cd ~/wsjtx-prefix/build
> Charless-MacBook-Pro:build charlesrogers$  FC=gfortran-mp-5 \
> >cmake \
> >-D CMAKE_PREFIX_PATH="~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local" \
> >-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
> >-D
> > CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
> > \ ~/wsjtx-prefix/src  
> -- Building wsjtx-1.7.1-devel
> -- **
> -- Building for for: Darwin-x86_64
> -- **
> -- Boost version: 1.63.0
> -- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) 
> (found version "1.0")
> -- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES) 
> (found version
> "1.0") -- Checking for module 'hamlib'
> --   No package 'hamlib' found
> hamlib_INCLUDEDIR=hamlib_INCLUDEDIR-NOTFOUND
> hamlib_LIBRARY=hamlib_LIBRARY-NOTFOUND
> hamlib_EXTRA_LIBRARIES=/opt/local/lib/libusb-1.0.dylib;m;dl
> CMake Error at CMake/Modules/LibFindMacros.cmake:87 (message):
>   Required library hamlib NOT FOUND.
> 
>   Install the library (dev version) and try again.  If the library is already
>   installed, use ccmake to set the missing variables manually.
> Call Stack (most recent call first):
>   CMake/Modules/Findhamlib.cmake:69 (libfind_process)
>   CMakeLists.txt:848 (find_package)
> 
> 
> -- Configuring incomplete, errors occurred!
> See also "/Users/charlesrogers/wsjtx-prefix/build/CMakeFiles/CMakeOutput.log".
> Charless-MacBook-Pro:build charlesrogers$ 
> 
> Log is attached here:
> 
> 
> 
> I rebuilt hamlib which indicated that it was OK and reran with same 
> result…Not exactly sure how
> to:
> 
> use ccmake to set the missing variables manually.
> Call Stack (most recent call first):
>   CMake/Modules/Findhamlib.cmake:69 (libfind_process)
>   CMakeLists.txt:848 (find_package)
> 
> Any suggestions as to how to resolve?
> 
> Thanks Gary KO3F
> 
> 
> 



-- 
-- 
Best wishes /73 
Richard Bown

Email : rich...@g8jvm.com
HTTP  :  http://www.g8jvm.com
nil carborundum a illegitemis
##
Ham Call: G8JVM . QRV: 50-432 MHz + Microwave 23 cms 140W, 13 cms 100W & 3cms 5W
Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W
QRV VHF 6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W
OS: Linux Mint 18.1  x86_64 on a Dell Inspiron N5030 laptop
##
 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trying to compile on OS X for the first time

2017-07-29 Thread Bill Somerville


On 29/07/2017 17:34, C. Gary Rogers wrote:
Hello all, i’ve been following Bill’s instructions on compiling WSJT-X 
on MacBook Pro OS X 10.12.5


All is successful until i attempt:

$ cd ~/wsjtx-prefix/build
$ FC=gfortran-mp-5 \
cmake \
-D CMAKE_PREFIX_PATH="~/Qt/5.7/clang_64;~/hamlib-prefix;/opt/local" \
-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix \
-D 
CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
 \
~/wsjtx-prefix/src


Hi Gary,

the issue is the quotation marks on the CMAKE_PREFIX_PATH variable 
assignment, they should not be there and are turning it into a single 
string rather that a path list separated by ';' characters.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r7969: AP: calls out of the blue

2017-07-29 Thread Steven Franke

Hi Richard,

> So - trying to find an explanation that fits all the known facts - and
> if I've understood correctly - VE3SMB probably called someone but
> probably not me.

I would say “maybe” VE3SMB called someone, not “probably”. Perhaps Bill and I 
differ a bit in our interpretations of this detail — I believe that it is 
purely coincidence (a remarkable coincidence, for sure) that a plausible 
callsign/grid combination was decoded.

Regards,
Steve k9an



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r7969: AP: calls out of the blue

2017-07-29 Thread Richard Lamont

Hi Steve,

On 29/07/17 15:32, Steven Franke wrote:

> (i) The attached screenshot of the waterfall shows that the false decode at 
> 1055 Hz was produced based on a signal that existed for less than half of the 
> interval.
> 
> Thus, at least half of the symbols were missing. Nevertheless, the signal was 
> strong enough so that sync was achieved - probably on the basis of only the 
> tail-end group of sync symbols.
> 
> (ii) The “a3” indicator tells us that for this decode the decoder 
> hypothesized that the first 28-bits (the “MyCall” bits) of the 87-bit message 
> frame were known, and were equal to your callsign, G4DYA. This is what Bill 
> means by “masking”
[snip]
>I would wager that VE3SMB, if s/he exists, was not transmitting at the time 
>that this decode was produced. Instead, in this case, the printed DxCall is a 
>spectre, produced by random chance, along with the plausible grid locator.

VE3SMB is listed on QRZ.com. His grid square isn't, but the street
address shown fits the grid square I received (FN04).

However, pskreporter has never seen any report of VE3SMB.

So - trying to find an explanation that fits all the known facts - and
if I've understood correctly - VE3SMB probably called someone but
probably not me. He may have been trying WSJT-X for the first time and
hasn't yet got his PC clock and/or CAT working properly. The AP decoder
at my station tried G4DYA for MyCall and got an erroneous match. Nobody
else saw the call because it was heavily truncated and there was nobody
else monitoring 7074 kHz at 0219 UTC with a recent AP-enabled devel
build of WSJT-X and able to receive VE3SMB at the time. (I imagine much
of NA would have been in the skip zone.)

> I hope that this message, along with Bill’s earlier one, helps to explain 
> what’s going on with AP.

Indeed it does. Many thanks to both of you for the explanations. I'm
sure I'm not the only one who will have found it interesting and
informative.

73,
Richard G4DYA

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] [SPAM] Re: Re: r7969: AP: calls out of the blue

2017-07-29 Thread Neil Zampella


Steven,

Will this information eventually show up in the Users Guide ??  I found 
it very helpful.


Neil, KN3ILZ


On 7/29/2017 10:32 AM, Steven Franke wrote:





For reference, here is the table of possible AP decoding types:

iaptype

  1CQ ??????
  2DE ??????
  3MyCall ??????
  4MyCall DxCall ???
  5MyCall DxCall RRR
  6MyCall DxCall 73
  7MyCall DxCall RR73
  8???DxCall ???

At present, types 2 and 8 are not used. The “a3” designator says that 
an AP type 3 attempt produced the decode. As already noted, type 3 
looks for decodes of the form “MyCall ??? ???”. Thus, any decode that 
is produced as a result of a type 3 attempt is going to contain 
“MyCall”. Similarly, any decode that results from a type 4, 5, 6, or 7 
attempt is going to contain MyCall and DxCall, where DxCall is 
whatever callsign is currently in the Dx Call box. In fact, an AP type 
5 decode will always be of the form “MyCall DxCall RRR”, etc.


Back to the "? a3” decode in question. A type 3 AP decoding attempt 
does not use any information from the DX Call box. Thus, the DXCall 
found in a false “a3” decode is usually implausible and rarely 
corresponds to the printed 4-digit locator. Richard's example is a 
rare case, indeed, as both the callsign and grid locator were 
plausible. I would wager that VE3SMB, if s/he exists, was not 
transmitting at the time that this decode was produced. Instead, in 
this case, the printed DxCall is a spectre, produced by random chance, 
along with the plausible grid locator.





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r7969: AP: calls out of the blue

2017-07-29 Thread Steven Franke

Hi Richard and Bill,

Adding to what BIll has said.

(i) The attached screenshot of the waterfall shows that the false decode at
1055 Hz was produced based on a signal that existed for less than half of the
interval.

Thus, at least half of the symbols were missing. Nevertheless, the signal was
strong enough so that sync was achieved - probably on the basis of only the
tail-end group of sync symbols.

(ii) The “a3” indicator tells us that for this decode the decoder hypothesized
that the first 28-bits (the “MyCall” bits) of the 87-bit message frame were
known, and were equal to your callsign, G4DYA. This is what Bill means by
“masking” — we “mask” the 28 MyCall bits and temporarily fix them at “known”
values. We then let the decoder do its thing and see if it can come up with a
codeword that contains the hypothetical AP bits and that has few differences
from the rest of the received bits. Any codeword that is produced as a result
of this operation is going to have MyCall bits that map to G4DYA, because those
bits were “hardwired” for the decoding attempt in question.

For the hypothetical bits we use only information that is known intrinsically
(MyCall) or that is gathered during an ongoing QSO when applying AP decoding.
Such information includes DxCall and the current state of the QSO. For example,
after we have sent a “R-20” report, we know that a likely response is RRR, 73,
or RR73. No reference is made to any other information.

For reference, here is the table of possible AP decoding types:

iaptype

1CQ ??????
2DE ??????
3MyCall ??????
4MyCall DxCall ???
5MyCall DxCall RRR
6MyCall DxCall 73
7MyCall DxCall RR73
8???DxCall ???

At present, types 2 and 8 are not used. The “a3” designator says that an AP
type 3 attempt produced the decode. As already noted, type 3 looks for decodes
of the form “MyCall ??? ???”. Thus, any decode that is produced as a result of
a type 3 attempt is going to contain “MyCall”. Similarly, any decode that
results from a type 4, 5, 6, or 7 attempt is going to contain MyCall and
DxCall, where DxCall is whatever callsign is currently in the Dx Call box. In
fact, an AP type 5 decode will always be of the form “MyCall DxCall RRR”, etc.

Back to the "? a3” decode in question. A type 3 AP decoding attempt does not
use any information from the DX Call box. Thus, the DXCall found in a false
“a3” decode is usually implausible and rarely corresponds to the printed
4-digit locator. Richard's example is a rare case, indeed, as both the callsign
and grid locator were plausible. I would wager that VE3SMB, if s/he exists, was
not transmitting at the time that this decode was produced. Instead, in this
case, the printed DxCall is a spectre, produced by random chance, along with
the plausible grid locator.

As to why we might be willing to tolerate these potentially confusing false
decodes; it is inevitable that when we dig deepest to decode the weakest (or
most garbled by interference or truncation) received words the ratio of good to
bad decodes is going to go down. For regular “non-AP” decodes, that ratio is
very large, maybe 10^5 or even larger. Down near the decoding threshold, when
the deep decoder and AP are in use, the good/bad ratio may fall to 100 or so.
Nevertheless, eliminating the AP decoding attempts would remove hundreds of
good decodes for every bad decode that is removed. Rather than do that, we
provide the “?” quality indicator. The presence of the “?” in the decode tells
you to watch out — it should be interpreted as meaning that this decode has a
higher-than-you-are-used-to chance of being incorrect, and that you should
consider context, the “type” of AP that was in use, and any other available
information (such as the appearance of the signal on the waterfall) to decide
whether or not to trust the decode. When in doubt, you may want to wait for a
second decode from the station in question before transmitting in response to a
questionable AP decode.

I’ll end this with an example showing a QSO that I made last night that
benefited from the use of AP:

In this example, the “Roger” and “73” messages from VA6SP had SNRs of -20 dB
and -22 dB, respectively. The “RRR” decode was obtained using AP type 4,
meaning that the decoder used the known values of MyCall and DxCall, and it
found a codeword that was consistent with these values *and* that contained an
RRR. It did not assume that “RRR” would be present. There was no “?” printed,
so this means that the decoder was confident that the decode was a good one. In
the case of the received “73” message, the decode assumed only “MyCall”, and
came up with the DxCall and “73” solely using the received data.

Note that AP decoding is attempted only after regular decoding has failed. This
means that without AP decoding both the RRR and the 73 responses

Re: [wsjt-devel] r7969: AP: calls out of the blue

2017-07-29 Thread Bill Somerville


On 29/07/2017 09:28, Richard Lamont wrote:

021915 -14 -0.3 1055 ~  G4DYA VE3SMB FN04? a3 <-


Hi Richard,

this can happen. Two things you can do to help, firstly the '?' is there 
to notify you that this decode is of low confidence and should be viewed 
with some suspicion and secondly the way AP decoding works depends on 
factors within your control. If the DX Call box has a callsign then that 
call will be fed to the AP algorithm and also the Rx cursor frequency. 
Both are used by the decoder to mask out likely components of decodes. 
For example by masking out your QSO partner when trying to decode a 
signal that is not decodable with the upstream decoder algorithms it is 
possible that a good decode can be achieved. To try and explain that, 
lets say that a decode is deemed good if it can be done by correcting 
less than ten bit errors (using the FEC parity bits) and then passes a 
CRC check. If there are 20 bit errors in the part of the message that 
might contain your DX partners callsign then by masking out that portion 
and assuming it is in fact a message from them and that leaves less than 
10 corrected bit errors and the message passes the CRC check then it has 
a higher probability of being a good decode in the current context than 
some other message. The AP algorithm is not applied to all candidate 
signals, some are only tested around the Rx cursor, particularly at 
certain points during a QSO.


So in summary, if you are not in a QSO or expecting decodes from a 
particular station, keep the DX Call box cleared. The AP algorithm will 
be used to search for CQ calls on all candidates, assuming it is turned 
on in the Decode menu. You will only see 'a1' AP decodes where the CQ 
part is masked and 'a2' candidate signals with your call first i.e. you 
call is masked.


You must always remember that the decoding process is stochastic and 
what you see decoded is based on probabilities for any signals that 
cannot be decoded perfectly using the basic FEC data. False decodes are 
always likely, what matters is how unlikely they are. With AP the false 
decode rate is higher and the decodes can be deceptively real unless you 
understand that parts of the decode are assumed and should be ignored in 
your assessment of validity. For example a false decode of a message 
with a grid that cannot be right for the senders location is relatively 
easy for you to reject but a CQ call may look more attractive. It it is 
marked 'a1' then the decoder has assumed the CQ and built the message 
from the remaining data, if it is marked '? a1' then the decoder was 
less certain.


So is this a real decode, the answer is probably yes *but* he probably 
was not calling you. What has happened is that by masking you the first 
word and assuming he was calling you the message has passed the decoding 
rules and been successfully decoded. All this tells us is that the 
second and third words have been decoded successfully and substituting 
the bits for you call in the first word passes the CRC check, but only 
just as the '?' tells us.


Think of it like a phone or CW op who is in QSO with a station and hears 
only a portion of a message, you don't hear your call but hear the rest 
of the message. The message content makes sense in the current context 
and so you can assume it was addressed to you even though you missed you 
callsign being sent due to QSB, QRM or QRN.


73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r7969: AP: calls out of the blue

2017-07-29 Thread Richard Lamont

On 29/07/17 09:40, Gordon Higgins wrote:

> could he not have seen u spotting on psk reporter @ called on chance
> richard  iff i see dx station  spotting i will call on chance often with
> sussex

Hi Gordon and thanks for the explanation. I do feed psk reporter.

It had never occurred to me that people might call a station they
haven't even heard.


73,
Richard G4DYA

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] r7969: AP: calls out of the blue

2017-07-29 Thread Gordon Higgins

could he not have seen u spotting on psk reporter @ called on chance
richard  iff i see dx station  spotting i will call on chance often with
sussex

On 29 July 2017 at 09:28, Richard Lamont  wrote:

> Ubuntu MATE 16.04 amd64
> 1.7.1-devel-r7969
> 7074 kHz FT8
> Deep decode and AP enabled
> Rx cursor left at 1909 Hz
>
> I left WSJT-X running over night and had a look this morning to see what
> I'd received.
>
> I was a bit surprised to see a station had apparently attempted to call
> me hours after I'd last transmitted:
>
> 021915  -7  0.7  252 ~  KK4ISJ KJ4DHF R-04
> 021915 -10  0.3  416 ~  CQ WP4JLU FK68  Puerto Rico
> 021915   1  0.5  574 ~  EA3NE YV7PMG 73
> 021915  -1  0.3  661 ~  N5WXY KD2DLL -01
> 021915   6  0.1  838 ~  W4PG SV5BYP -05
> 021915 -14 -0.3 1055 ~  G4DYA VE3SMB FN04? a3 <-
> 021915   4  0.7 1437 ~  N9YLE VA3MJR FN03
> 021915  -3  0.2 1495 ~  UA6JQ HK4DEI 73
> 021915   2  0.7 1555 ~  K4EIT W5VE EM85
> 021915 -11  0.9 1646 ~  KG0BK K8YK EM99
> 021915 -19  1.1 1893 ~  KG0BK AH6FF RRR
> 021915   1  0.7 2071 ~  HK4L W4UEF FM15
> 021915 -12  0.1  388 ~  CQ KC9SWV EN60 ~U.S.A.
>
> This is the second time I've seen a station calling me 'out of the blue'
> since building r7969. (Unfortunately I didn't have the presence of mind
> to note the first.) In both cases deep decode and AP were enabled, and
> the attached .wav only decodes the call to me if both are enabled.
>
> 73,
> Richard G4DYA
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Trying to compile on OS X for the first time

Re: [wsjt-devel] JTSDK install on Win10 fails

Re: [wsjt-devel] Trying to compile on OS X for the first time

Re: [wsjt-devel] Trying to compile on OS X for the first time

Re: [wsjt-devel] Trying to compile on OS X for the first time

[wsjt-devel] JTSDK install on Win10 fails

Re: [wsjt-devel] Trying to compile on OS X for the first time

Re: [wsjt-devel] Trying to compile on OS X for the first time

Re: [wsjt-devel] Trying to compile on OS X for the first time

Re: [wsjt-devel] Trying to compile on OS X for the first time

Re: [wsjt-devel] r7969: AP: calls out of the blue

[wsjt-devel] QRA64 Auto-sequence Patch

Re: [wsjt-devel] r7969: AP: calls out of the blue

Re: [wsjt-devel] Trying to compile on OS X for the first time

Re: [wsjt-devel] Trying to compile on OS X for the first time

Re: [wsjt-devel] Trying to compile on OS X for the first time

Re: [wsjt-devel] Trying to compile on OS X for the first time

Re: [wsjt-devel] r7969: AP: calls out of the blue

Re: [wsjt-devel] r7969: AP: calls out of the blue

[wsjt-devel] [SPAM] Re: Re: r7969: AP: calls out of the blue

Re: [wsjt-devel] r7969: AP: calls out of the blue

Re: [wsjt-devel] r7969: AP: calls out of the blue

Re: [wsjt-devel] r7969: AP: calls out of the blue

Re: [wsjt-devel] r7969: AP: calls out of the blue

24 matches

Site Navigation

Mail list logo

Footer information