Re: [wsjt-devel] FT8 Roundup, 1-2 December 2018
Just to double check, you mean December 2018 right? On Wed, Nov 14, 2018, 21:53 Ed Muns Don AA5AU and I are pleased to announce the FT8 Roundup to be held on 1-2 > December 2019. Rules, tutorials and other information can be found at: > > https://www.rttycontesting.com/ft8-roundup/ > > This is the weekend of the Ten-Meter RTTY Contest that we've sponsored for > the past 8 years. Given the state of 10 meters and the explosive adoption > of FT8, we decided to use the 2018 contest weekend for the first full-blown > FT8-only contest. The contest format in 2019 and beyond is yet to be > determined, but will surely be influenced by the results of the 2018 FT8 > Roundup. > > The rules are the ARRL RTTY Roundup rules with the following changes: > > 1. FT8 mode only. Must use WSJT-X 2.0, rc4 > 2. 100 watts maximum power. > 3. Logs submitted to ft8...@cqww.com. > 4. Single-Operator Unlimited only (no Single-Operator non-assisted). > 5. All entry classes may use "multi-streaming" within the same receiver > audio passband, whereby multiple QSOs are run in parallel. In the DX world > an example of multi-streaming is the DXpedition mode with "Fox and Hound" > capability. (CURRENTLY, THERE IS NO WSJT-X, OR OTHER, SOFTWARE SUPPORT FOR > MULTI-STREAMING IN THE ARRL RTTY ROUNDUP CONTEST MODE. THEREFORE, IT IS > NOT > EXPECTED TO EXIST IN THIS YEAR'S CONTEST. THE PURPOSE OF THE RULE AT THIS > TIME IS TO ENCOURAGE SOFTWARE DEVELOPERS TO DEVISE AN APPROPRIATE > MULTI-STREAMING CAPABILITY FOR FT8 CONTESTING.) > > Note, however, that rc4 does support the classic "TU, NW" technique whereby > rolling QSOs can be achieved with only two transmission cycles (30 seconds) > per QSO. In theory, an SO2R station could achieve 240 QSOs/hour, though > this is extremely difficult to obtain in practice. It requires the running > station, and its 240 QSO partners, to operate in perfect harmony for a full > hour! > > WSJT-X 2.0, rc4 creates a proper Cabrillo format file for log submission > following the ARRL RTTY Roundup Cabrillo 3.0 specification. The contest > name in the header is CONTEST: ARRL-RTTY, same as for the RTTY Roundup. > Therefore, logging programs can use the existing ARRL RTTY Roundup contest > configuration, though WSJT-X 2.0, rc4 is the recommended software. N1MM+ > now has some WSJT-X integration for those users. Hopefully, other > mainstream logging software will follow suit. > > Please carefully study the WSJT-X 2.0, rc4 Quick-Start Guide: > > https://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf > > Practices: The next FT8 Roundup mock contest will be Tuesday, 20 November, > 0200-0300 UTC (Monday evening, NA time). Please see Joe Taylor's > announcement posted on the [wsjt-devel] mail list on Wednesday, 14 > November. > > Don and I will schedule at least one other practice prior to the actual > contest on 1-2 December. > > Ed W0YK > Don AA5AU > > > > > ___ > 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] FT8 Roundup, 1-2 December 2018
Don AA5AU and I are pleased to announce the FT8 Roundup to be held on 1-2 December 2019. Rules, tutorials and other information can be found at: https://www.rttycontesting.com/ft8-roundup/ This is the weekend of the Ten-Meter RTTY Contest that we've sponsored for the past 8 years. Given the state of 10 meters and the explosive adoption of FT8, we decided to use the 2018 contest weekend for the first full-blown FT8-only contest. The contest format in 2019 and beyond is yet to be determined, but will surely be influenced by the results of the 2018 FT8 Roundup. The rules are the ARRL RTTY Roundup rules with the following changes: 1. FT8 mode only. Must use WSJT-X 2.0, rc4 2. 100 watts maximum power. 3. Logs submitted to ft8...@cqww.com. 4. Single-Operator Unlimited only (no Single-Operator non-assisted). 5. All entry classes may use "multi-streaming" within the same receiver audio passband, whereby multiple QSOs are run in parallel. In the DX world an example of multi-streaming is the DXpedition mode with "Fox and Hound" capability. (CURRENTLY, THERE IS NO WSJT-X, OR OTHER, SOFTWARE SUPPORT FOR MULTI-STREAMING IN THE ARRL RTTY ROUNDUP CONTEST MODE. THEREFORE, IT IS NOT EXPECTED TO EXIST IN THIS YEAR'S CONTEST. THE PURPOSE OF THE RULE AT THIS TIME IS TO ENCOURAGE SOFTWARE DEVELOPERS TO DEVISE AN APPROPRIATE MULTI-STREAMING CAPABILITY FOR FT8 CONTESTING.) Note, however, that rc4 does support the classic "TU, NW" technique whereby rolling QSOs can be achieved with only two transmission cycles (30 seconds) per QSO. In theory, an SO2R station could achieve 240 QSOs/hour, though this is extremely difficult to obtain in practice. It requires the running station, and its 240 QSO partners, to operate in perfect harmony for a full hour! WSJT-X 2.0, rc4 creates a proper Cabrillo format file for log submission following the ARRL RTTY Roundup Cabrillo 3.0 specification. The contest name in the header is CONTEST: ARRL-RTTY, same as for the RTTY Roundup. Therefore, logging programs can use the existing ARRL RTTY Roundup contest configuration, though WSJT-X 2.0, rc4 is the recommended software. N1MM+ now has some WSJT-X integration for those users. Hopefully, other mainstream logging software will follow suit. Please carefully study the WSJT-X 2.0, rc4 Quick-Start Guide: https://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf Practices: The next FT8 Roundup mock contest will be Tuesday, 20 November, 0200-0300 UTC (Monday evening, NA time). Please see Joe Taylor's announcement posted on the [wsjt-devel] mail list on Wednesday, 14 November. Don and I will schedule at least one other practice prior to the actual contest on 1-2 December. Ed W0YK Don AA5AU ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.0-rc4 on CentOS7
Hi, Bill. I snooped at the patch … aha! It was pkgconfig. :-) Anyway, I applied that patch and built from scratch. Success! Thanks! 73 de km6aow --- Mark Klein km6...@markklein.org signature.asc Description: Message signed with OpenPGP ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.0-rc4 on CentOS7
Ok, I downloaded the newest version of WSTJ-X release and have nothing but problems . I am not the greatest computer wizard but can get around pretty good. Out of frustration I went back and reloaded the original 1.9.1 and now nothing decodes, under “generate Std Msgs” all blank except the CQ selection. I hear ton of signals, sound cards are all set properly as before but now nothing is decoded. Been back and forth a dozen times with the different versions today with no luck. The latetes Beta version is evidently a whole new coding as I cannot get it to work as well. I do not need a bunch of “elmer techs” to tell me I am an idiot, just want to know what is happening here please. I have enjoyed the WSTJ-X FT8 program a great deal until today. What am I doing wrong here??? Bob AA7CT Sent from Mail for Windows 10 From: Mark Klein Sent: Wednesday, November 14, 2018 4:52 PM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] wsjtx-2.0-rc4 on CentOS7 Hi Bill, > hanks for the info. I have a CentOS VM up now and am investigating why the > Hamlib package find is failing. We have a home brew CMake package finder for > Hamlib as no one has contributed the required CMake scripts to ship with > Hamlib. I really should sort that out and contribute upstream ;) Don’t forget to install the hamlib RPMs too to match my config. > Your CMake configure line could include '-DWSJT_SKIP_MANPAGES=ON > -DWSJT_GENERATE_DOCS=OFF' which saves having to install many dependencies not > needed for the core application build. Thanks for the hints … I’ll add the to my notes for the next build! 73 de km6aow --- Mark Klein ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Colors Still have Bugs
On 14/11/2018 19:14, Marco Calistri via wsjt-devel wrote: -- Build files have been written to: /home/marco/WSJT-X_build/jtsource/wsjtx-2.0.0-rc4 Hi Marco, this output is unexpected. I believe it may be due to the source directory containing build files. I suggest that you remove the source tree and recreate it from the downloaded sources tarball, then try again. I think the most likely cause of the Hamlib package errors are that you do not have all the dependencies installed to build Hamlib. The recipe and patch file I sent to Mark, KM6AOW, here https://sourceforge.net/p/wsjt/mailman/message/36467441/ may be relevant to your build issues on OpenSuSE. Package names will be different and of course you will be using YaST or Zypper rather than yum to install them. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.0-rc4 on CentOS7
On 15/11/2018 00:49, Mark Klein wrote:
Hi Bill,
hanks for the info. I have a CentOS VM up now and am investigating why the
Hamlib package find is failing. We have a home brew CMake package finder for
Hamlib as no one has contributed the required CMake scripts to ship with
Hamlib. I really should sort that out and contribute upstream;)
Don’t forget to install the hamlib RPMs too to match my config.
Your CMake configure line could include '-DWSJT_SKIP_MANPAGES=ON
-DWSJT_GENERATE_DOCS=OFF' which saves having to install many dependencies not
needed for the core application build.
Thanks for the hints … I’ll add the to my notes for the next build!
73 de km6aow
---
Mark Klein
Hi Mark,
any Hamlib RPMs installed have no bearing on a WSJT-X build from our
source tarball.
I am now able to build on CentOS 7 with the following recipe:
My starting point was a VM install of CentOS 7 with the GNOME Desktop
group installed, the system was fully updated with 'sudo yum update'.
1) Install required dependencies to build Hamlib and WST-X (without
manpages and manual):
sudo yum install gcc-gfortran cmake fftw3-devel libudev-devel
libusbx-devel qt5-qtserialport-devel git gcc-c++ make autoconf automake
patch libtool texinfo qt5-qtmultimedia-devel
2) Fetch the source tarball:
mkdir -p ~/wsjtx-prefix/build
cd !$/..
wget
https://sourceforge.net/projects/wsjt/files/wsjtx-2.0.0-rc4/wsjtx-2.0.0-rc4.tgz
tar xf wsjtx-2.0.0-rc4.tgz
3) Insert patches:
copy the attached patch to ~/wsjtx-prefix/wsjtx-2.0.0-rc4/ overwriting
the empty file with the same name.
4) Configure the build tree:
cd build
cmake -DCMAKE_INSTALL_PREFIX=.. -DWSJT_SKIP_MANPAGES=ON
-DWSJT_GENERATE_DOCS=OFF ../wsjtx-2.0.0-rc4
5) Build and install the application:
cmake --build . --target install -- -j
6) Run WSJT-X (I found that the default native GUI widgets were nasty so
I selected the Qt cross platform fusion sytle, YMMV):
~/wsjtx-prefix/bin/wstx -style fusion
The patch file is only necessary for WSJT-X v2.0.0 RC4 and earlier, I
will apply the changes to our repo so the next release will not require
them.
73
Bill
G4WJS.
diff --git a/CMake/Modules/Findhamlib.cmake b/CMake/Modules/Findhamlib.cmake
index 1590f05..e880d84 100644
--- a/CMake/Modules/Findhamlib.cmake
+++ b/CMake/Modules/Findhamlib.cmake
@@ -16,8 +16,9 @@ set (hamlib_LIBRARY_DIRS)
# pkg-config?
find_path (__hamlib_pc_path NAMES hamlib.pc
- PATH_SUFFIXES lib/pkgconfig
+ PATH_SUFFIXES lib/pkgconfig lib64/pkgconfig
)
+
if (__hamlib_pc_path)
set (ENV{PKG_CONFIG_PATH} "${__hamlib_pc_path}" "$ENV{PKG_CONFIG_PATH}")
unset (__hamlib_pc_path CACHE)
diff --git a/qt_db_helpers.hpp b/qt_db_helpers.hpp
index 3f159a8..da823b0 100644
--- a/qt_db_helpers.hpp
+++ b/qt_db_helpers.hpp
@@ -25,7 +25,7 @@ class ConditionalTransaction final
{
public:
explicit ConditionalTransaction (QSqlTableModel& model)
-: model_ {model}
+: model_ (model)
, submitted_ {false}
{
model_.database ().transaction ();
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc4
The band was really up and down here, with some rapid QSB also. A few times I saw signals with gaping holes in them, other times somone would disappear entirely only to come back a couple minutes later. Propagation is a harsh misteress! 73 -Jim NU0c On Wed, 14 Nov 2018 00:30:13 -0600, Stan Gammons wrote: >Could have been band conditions, but it seem like I had a few decode >problems with stations that the exchanged signal levels should have >decoded on both ends. -- The universe we're in will reach absolute zero in three hours. Safe is relative. - Idris, "The Doctor's Wife" ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.0-rc4 on CentOS7
Hi Bill, > hanks for the info. I have a CentOS VM up now and am investigating why the > Hamlib package find is failing. We have a home brew CMake package finder for > Hamlib as no one has contributed the required CMake scripts to ship with > Hamlib. I really should sort that out and contribute upstream ;) Don’t forget to install the hamlib RPMs too to match my config. > Your CMake configure line could include '-DWSJT_SKIP_MANPAGES=ON > -DWSJT_GENERATE_DOCS=OFF' which saves having to install many dependencies not > needed for the core application build. Thanks for the hints … I’ll add the to my notes for the next build! 73 de km6aow --- Mark Klein signature.asc Description: Message signed with OpenPGP ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc4
Well, it did but obviously I missed it probably because I was looking for a check box instead of an entry box. And it was late. In my defense I also did a text search of the QSG and the online manual. Thanks for your answer. 73 -Jim NU0C On Wed, 14 Nov 2018 08:46:22 -0500, Joe Taylor wrote: >Hi Jim, > >On 11/14/2018 12:54 AM, Jim Shorney NU0C wrote: > >> The only little nit I have os Operator call isn't sticky in the logging box. >> Not that big a deal since I rarely do mutli-op, but I like to fill it in for >> completeness if it is there and having to enter if for each QSO gets old. Am >> I >> missing something? I've searched the settings. > >Did your search include the Upper-right of the Settings | Reporting tab? > > -- 73, Joe, K1JT -- Hold tight and pretend it's a plan. - The Doctor, "The Doctor, the Widow and the Wardrobe" ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] fyi ft8v2rc4 ran ovr nite..
fyi ft8v2rc4 ran ovr nite.. win10 v1803 Precision M6800 i7-4710MQ 2.5GHz just fine. (no mem leak. no prob.) pskRep spot 40m. will let it run agn 2nite. BCNU DE N2LO~> ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.0-rc4 on CentOS7
On 14/11/2018 21:11, Mark Klein wrote: What CMake configure command did you you use for the first attempt that you only show errors from in your OP? cmake .. cmake —build . I’ve attached a bzip of the full build output up to the hamlib error. I’m not up to speed on cmake, so I don’t know how it is doing its dependency resolution, but it isn’t finding the local one provided in the wsjtx tarball. My setting the property is to explicitly point to the one built from the tarball, not the native one on CentOS7. Hi Mark, thanks for the info. I have a CentOS VM up now and am investigating why the Hamlib package find is failing. We have a home brew CMake package finder for Hamlib as no one has contributed the required CMake scripts to ship with Hamlib. I really should sort that out and contribute upstream ;) CMake depedency resolution is basically driven by the "usual" system library paths plus the CMake path variable CMAKE_PREFIX_PATH which can override the "usual" paths, the latter is used in our packaged CMake scripts and should be enough but clearly there is a problem on this platform. Your CMake configure line could include '-DWSJT_SKIP_MANPAGES=ON -DWSJT_GENERATE_DOCS=OFF' which saves having to install many dependencies not needed for the core application build. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.0-rc4 on CentOS7
Hi, Bill.What CMake configure command did you you use for the first attempt that you only show errors from in your OP?cmake ..cmake —build .I’ve attached a bzip of the full build output up to the hamlib error. I’m not up to speed on cmake, so I don’t know how it is doing its dependency resolution, but it isn’t finding the local one provided in the wsjtx tarball. My setting the property is to explicitly point to the one built from the tarball, not the native one on CentOS7. This is what’s installed (primarily for fldigi):[mklein@km6aow wsjtx-2.0.0-rc4]$ yum list installed hamlib\*Loaded plugins: fastestmirror, langpacks, nvidiaDetermining fastest mirrors * base: mirror.sjc02.svwh.net * elrepo: repos.dfw.lax-noc.com * epel: mirror.sjc02.svwh.net * extras: sjc.edge.kernel.org * updates: mirror.sjc02.svwh.netepel 12708/12708Installed Packageshamlib.x86_64 3.3-1.el7 @epelhamlib-c++.x86_64 3.3-1.el7 @epelhamlib-c++-devel.x86_64 3.3-1.el7 @epelhamlib-devel.x86_64 3.3-1.el7 @epelhamlib-doc.noarch 3.3-1.el7 @epelI have changed my mind on this, your patch is valid. It is needed due to a compiler problem but your change is equivalent to the intended behaviour.It should be … I only changed from brace initialization to the older parenthetical initialization. They should be equivalent. There does seem to be an issue with that version of the GNU compiler.What version of Qt is available from the CentOS 7.5 repositories?[mklein@km6aow wsjtx-2.0.0-rc4]$ yum list installed qt5\*Loaded plugins: fastestmirror, langpacks, nvidiaLoading mirror speeds from cached hostfile * base: mirror.sjc02.svwh.net * elrepo: repos.dfw.lax-noc.com * epel: mirror.sjc02.svwh.net * extras: sjc.edge.kernel.org * updates: mirror.sjc02.svwh.netInstalled Packagesqt5-qtbase.x86_64 5.9.2-3.el7 @baseqt5-qtbase-common.noarch 5.9.2-3.el7 @baseqt5-qtbase-devel.x86_64 5.9.2-3.el7 @baseqt5-qtbase-gui.x86_64 5.9.2-3.el7 @baseqt5-qtdeclarative.x86_64 5.9.2-1.el7 @baseqt5-qtdeclarative-devel.x86_64 5.9.2-1.el7 @baseqt5-qtmultimedia.x86_64 5.9.2-1.el7 @baseqt5-qtmultimedia-devel.x86_64 5.9.2-1.el7 @baseqt5-qtserialport.x86_64 5.9.2-1.el7 @baseqt5-qtserialport-devel.x86_64 5.9.2-1.el7 @baseqt5-qtxmlpatterns.x86_64 5.9.2-1.el7 @baseqt5-rpm-macros.noarch 5.9.2-3.el7 @base[mklein@km6aow wsjtx-2.0.0-rc4]$ build.log.bz2 Description: BZip2 compressed data Hope that helps.73 de km6aow---Mark Klein signature.asc Description: Message signed with OpenPGP ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJTX 2.0 RC4 Db Gain?
Hi Bill: I mean my Kenwood 480 TX meter. Windows 10. Not sure if this makes sense. Pevious versions of WSJTX used to set Split mode to 'none' with RC4 and setting Split to radio TX meter looks a bit further into the right. 73' Edfel KP4AJ On Wed, Nov 14, 2018 at 3:48 PM Bill Somerville wrote: > On 15/11/2018 01:24, Edfel Rivera wrote: > > Hi: > > I am not sure if this could be a change in my settings or if is > > improvement with 2.0 RC4. I have the impression that the meter is > > going a bit further into the right. Yes I know to be sure I have to > > compare with 1.9.1. Maybe in next days could do the comparison. > > > > Could be wrong. > > > > Regards and 73' > > > > Edfel > > KP4AJ > > Hi Edfel, > > which meter? Which platform? Tx or Rx? > > 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] WSJTX 2.0 RC4 Db Gain?
On 15/11/2018 01:24, Edfel Rivera wrote: Hi: I am not sure if this could be a change in my settings or if is improvement with 2.0 RC4. I have the impression that the meter is going a bit further into the right. Yes I know to be sure I have to compare with 1.9.1. Maybe in next days could do the comparison. Could be wrong. Regards and 73' Edfel KP4AJ Hi Edfel, which meter? Which platform? Tx or Rx? 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Colors Still have Bugs
Maybe those will be helpful to find an issue. Sometimes after e finished (and stored) QSO a new CQ still is present as new. See here 9A2JK as example. But in other cases it work correctly (here G6NHU). I am using rc4 on Windows-10. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJTX 2.0 RC4 Db Gain?
Hi: I am not sure if this could be a change in my settings or if is improvement with 2.0 RC4. I have the impression that the meter is going a bit further into the right. Yes I know to be sure I have to compare with 1.9.1. Maybe in next days could do the comparison. Could be wrong. Regards and 73' Edfel KP4AJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] MOCK CONTEST TEST
Hi Joe For the "official practice mock contest" can we please extend this to also run in parallel on 14.078? This will provide a better opportunity for propagation to ZL/VK in our early afternoon, than 40m. 73 Gavin ZL3GAV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] wrong time logged
( RC4 ) 2018-11-14,19:12:15,2018-11-14,19:17:00,K1HK,FN42,14.076397,FT8,-01,+06,40,FT8 Sent: -01 Rcvd: +06, 2018-11-14,19:17:33,2018-11-14,19:42:00,W8NNX,EL98,14.076377,FT8,-09,+06,40,FT8 Sent: -09 Rcvd: +06, In the contact with W8NNX the start time should have been 19:41:15 .. After the QSO with K1HK I called CQ for 3 minutes.. and then was idles until again calling QSO at 19:41 when W8NNX answered. AL, K0VM ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.0-rc4 on CentOS7
On 14/11/2018 19:42, Richard Shaw wrote: To clear this up. The official Fedora and Fedora EPEL packages I maintain use the version of hamlib in Fedora since bundling is highly discouraged. The version for both is the current 3.3 release. Hi Richard, the version of Hamlib shipped with WSJT-X is v4 from their master branch. I see no reason why those building from sources should not follow our recommendation. As for various distribution official packaging requirements, however dumb (bundling a static linked library avoids the issues they are afraid of), we have no problem with using an older system version of Hamlib but official support is limited for this non-recommended configuration. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.0-rc4 on CentOS7
On Wed, Nov 14, 2018 at 1:01 PM Bill Somerville wrote: > On 14/11/2018 18:43, Mark Klein wrote: > > Hi group. > > > > I had some issues building wsjtx-2.0-rc4 on CentOS7.5. First note that > > I have fldigi and the standard hamlib RPM installed on that VM. My > > understanding is that there is an incompatibility between that version > > and the one wsjtx-2.0 uses. In trying to build wsjtx with the version > > of hamlib provided, the build couldn’t find the local hamlib: > > > Hi Mark, > > there should be no Hamlib incompatibility, the Hamlib supplied in the > WSJT-X sources tarball is built into an internal directory and linked > statically into WSJT-X. Please do not override the use of this > recommended Hamlib version unless you are sure you know what you are doing. > To clear this up. The official Fedora and Fedora EPEL packages I maintain use the version of hamlib in Fedora since bundling is highly discouraged. The version for both is the current 3.3 release. I have made almost 1000 contacts in JT65 and FT8 since circa version 1.8 this way. Thanks, Richard KF5OIM ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Colors Still have Bugs
Il 14/11/18 15:45, Bill Somerville ha scritto: > On 14/11/2018 17:17, Marco Calistri wrote: >> **GOOD PROCEDURE*** >> cd jtsource/wsjtx-2.0.0-rc4/ >> /usr/bin/cmake -Dhamlib_INCLUDE_DIRS=/usr/include \ >> -Dhamlib_LIBRARIES=/usr/lib64/libhamlib.so \ >> -Dhamlib_LIBRARY_DIRS=/usr/lib64 \ >> -DWSJT_GENERATE_DOCS=OFF \ >> -DWSJT_SKIP_MANPAGES=ON \ >> -D CMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx . >> >> /usr/bin/cmake --build . --target install >> > > Hi Marco, > > this procedure is not recommended, you are directing WSJT-X to be > built with your system Hamlib package but we ship WSJT-X with a > snapshot of a recent Hamib sources which we recommend. > > I see the issue in that our CMake script may not be taking proper > account of the lib64 style library directory names. I can fix this. I > need to know what the first error message is from the command sequence: > > mkdir -p ~/WSJT-X_build/build > cd !$ > cmake -D CMAKE_INSTALL_PREFIX=../.wsjtx ../jtsource/wsjtx-2.0.0-rc4 > cmake --build . --target install > > Also please do not build in the source directory, it is untested and > not recommended. > > Once you have the build working correctly with the correct sources for > Hamlib, you can make an RPM package by making the package target. > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel Hello Bill, Many thanks to enlighten me on these rules. Here we go with step by step results of the commands you indicated: marco@linux-turion64:~/WSJT-X_build/jtsource/wsjtx-2.0.0-rc4> mkdir -p ~/WSJT-X_build/build marco@linux-turion64:~/WSJT-X_build/jtsource/wsjtx-2.0.0-rc4> cd !$ cd ~/WSJT-X_build/build marco@linux-turion64:~/WSJT-X_build/build> cmake -D CMAKE_INSTALL_PREFIX=../.wsjtx ../jtsource/wsjtx-2.0.0-rc4 CMake Warning (dev) at CMakeLists.txt:165 (add_custom_target): Policy CMP0037 is not set: Target names should not be reserved and should match a validity pattern. Run "cmake --help-policy CMP0037" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The target name "install" is reserved or not valid for certain CMake features, such as generator expressions, and may result in undefined behavior. This warning is for project developers. Use -Wno-dev to suppress it. -- Configuring done -- Generating done -- Build files have been written to: /home/marco/WSJT-X_build/jtsource/wsjtx-2.0.0-rc4 marco@linux-turion64:~/WSJT-X_build/build> marco@linux-turion64:~/WSJT-X_build/build> cmake --build . --target install Error: could not load cache marco@linux-turion64:~/WSJT-X_build/build> -- 73 de Marco, PY1ZRJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.0-rc4 on CentOS7
On 14/11/2018 18:56, Bill Somerville wrote: Your patch is invalid an breaks WSJT-X, you cannot randomly comment out code and expect the result to be a working application! Just because it compiled and linked does not mean it is correct. The compile error is due to the age of the g++ compiler on RHEL/CentOS 7 (gcc-4.8.5). Hi Mark, I have changed my mind on this, your patch is valid. It is needed due to a compiler problem but your change is equivalent to the intended behaviour. I note that Qt5.6 is in the CentOS 7.5 repos. I am downloading the ISO and will spin up a VM and see if I can address any issues build Hamlib and WSJT-X with the sources and CMake scripts we provide. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.0-rc4 on CentOS7
On 14/11/2018 18:43, Mark Klein wrote: Hi group. I had some issues building wsjtx-2.0-rc4 on CentOS7.5. First note that I have fldigi and the standard hamlib RPM installed on that VM. My understanding is that there is an incompatibility between that version and the one wsjtx-2.0 uses. In trying to build wsjtx with the version of hamlib provided, the build couldn’t find the local hamlib: Hi Mark, there should be no Hamlib incompatibility, the Hamlib supplied in the WSJT-X sources tarball is built into an internal directory and linked statically into WSJT-X. Please do not override the use of this recommended Hamlib version unless you are sure you know what you are doing. What CMake configure command did you you use for the first attempt that you only show errors from in your OP? Your patch is invalid an breaks WSJT-X, you cannot randomly comment out code and expect the result to be a working application! Just because it compiled and linked does not mean it is correct. The compile error is due to the age of the g++ compiler on RHEL/CentOS 7 (gcc-4.8.5). I will try and get a fix in for the next release. What version of Qt is available from the CentOS 7.5 repositories? 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 2.0.0-rc4 FT8 bugs
Hi Bill, Thank you for clearing that up for me! 73 Scott W6SDD > On Nov 14, 2018, at 11:38, Bill Somerville wrote: > > Hi Scott, > > there is a facility in WSJT-X to send RR73 as a final QSO message rather than > RRR, it is intended to be used when you are almost certain that it will be > received, first time, by your QSO partner. It indicates to anyone waiting to > call you that you have logged the QSO, are not expecting a 73 message, and > they can safely tail-end the QSO. This can save considerable time if you are > a popular station that often has many callers. > > To toggle this facility on and off double-click either the Tx4 "Next" radio > button or the Tx4 "Now" button. Hover the mouse over them for details. > > 73 > Bill > G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] wsjtx-2.0-rc4 on CentOS7
Hi group.
I had some issues building wsjtx-2.0-rc4 on CentOS7.5. First note that I have
fldigi and the standard hamlib RPM installed on that VM. My understanding is
that there is an incompatibility between that version and the one wsjtx-2.0
uses. In trying to build wsjtx with the version of hamlib provided, the build
couldn’t find the local hamlib:
-- checking for module 'hamlib'
-- package 'hamlib' not found
-- Found hamlib
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:108
(message):
Could NOT find hamlib (missing: hamlib_LIBRARY_DIRS) (Required is at least
version "3")
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:315
(_FPHSA_FAILURE_MESSAGE)
CMake/Modules/Findhamlib.cmake:81 (find_package_handle_standard_args)
CMakeLists.txt:853 (find_package)
I couldn’t make things build seamlessly, so I ended up using (from my build
directory):
1036 cmake ..
1037 cmake --build . --target hamlib
1038 cmake -D hamlib_LIBRARY_DIRS=./hamlib-prefix/lib --build .
1039 cmake --build .
I then ran into a compilation error:
[ 87%] Building CXX object CMakeFiles/wsjt_qt.dir/models/FoxLog.cpp.o
In file included from
/home/mklein/Documents/Software/wsjtx-2.0.0-rc4/build-2/wsjtx-prefix/src/wsjtx/models/FoxLog.cpp:13:0:
/home/mklein/Documents/Software/wsjtx-2.0.0-rc4/build-2/wsjtx-prefix/src/wsjtx/qt_db_helpers.hpp:
In constructor â:
/home/mklein/Documents/Software/wsjtx-2.0.0-rc4/build-2/wsjtx-prefix/src/wsjtx/qt_db_helpers.hpp:29:24:
error: invalid initialization of non-const reference of type â from an rvalue
of type â
, submitted_ {false}
^
gmake[5]: *** [CMakeFiles/wsjt_qt.dir/models/FoxLog.cpp.o] Error 1
gmake[4]: *** [CMakeFiles/wsjt_qt.dir/all] Error 2
gmake[3]: *** [all] Error 2
gmake[2]: *** [wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
gmake[1]: *** [CMakeFiles/wsjtx-build.dir/all] Error 2
gmake: *** [all] Error 2
[mklein@km6aow build-2]$
and applied the following patch:
*** wsjtx-prefix/src/wsjtx/qt_db_helpers.hpp- 2018-11-14 09:45:22.032214892
-0800
--- wsjtx-prefix/src/wsjtx/qt_db_helpers.hpp2018-11-14 09:45:37.784214917
-0800
***
*** 25,32
{
public:
explicit ConditionalTransaction (QSqlTableModel& model)
! : model_ {model}
! , submitted_ {false}
{
model_.database ().transaction ();
}
--- 25,32
{
public:
explicit ConditionalTransaction (QSqlTableModel& model)
! : model_ (model)
! , submitted_ (false)
{
model_.database ().transaction ();
}
After that, I was successful in the build. I managed to make one QSO on 40M.
I’ll play around more over the next few days.
Here’s the details from my CentOS7 VM:
[mklein@km6aow build-2]$ cat /etc/centos-release
CentOS Linux release 7.5.1804 (Core)
[mklein@km6aow build-2]$ uname -a
Linux km6aow 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux
[mklein@km6aow build-2]$ c++ --version
c++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
73 de km6aow
---
Mark Klein
signature.asc
Description: Message signed with OpenPGP
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.0.0-rc4 FT8 bugs
On 14/11/2018 18:09, Scott Davis wrote: I have noticed that rc4 won't let me send RRR. On tab 2, the message grid shows RRR, but if I click RRR, Gen msg is populated with his-call my-call RR73. See the second screen snapshot below. On tab 1, if a QSO is underway and I change message 4 to say RRR instead of RR73, the software changes it back and transmits RR73 anyway. Hi Scott, there is a facility in WSJT-X to send RR73 as a final QSO message rather than RRR, it is intended to be used when you are almost certain that it will be received, first time, by your QSO partner. It indicates to anyone waiting to call you that you have logged the QSO, are not expecting a 73 message, and they can safely tail-end the QSO. This can save considerable time if you are a popular station that often has many callers. To toggle this facility on and off double-click either the Tx4 "Next" radio button or the Tx4 "Now" button. Hover the mouse over them for details. 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 2.0.0-rc4
On 14/11/2018 17:00, Svend Aage Jessen wrote: The option of LOTW is giving me an error. I do not use LOTW. Is there an option of turning it off? -- 73 de LA6YJA la6...@savednet.com Hi Svend Aage, please refer to the latest Quick Start Guide to WSJT-X v2.0 https://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf , specifically the section headed "LoTW Download Errors". The instructions there are a one time fix and are not necessarily specific to LoTW. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Colors Still have Bugs
On 14/11/2018 17:17, Marco Calistri wrote: **GOOD PROCEDURE*** cd jtsource/wsjtx-2.0.0-rc4/ /usr/bin/cmake -Dhamlib_INCLUDE_DIRS=/usr/include \ -Dhamlib_LIBRARIES=/usr/lib64/libhamlib.so \ -Dhamlib_LIBRARY_DIRS=/usr/lib64 \ -DWSJT_GENERATE_DOCS=OFF \ -DWSJT_SKIP_MANPAGES=ON \ -D CMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx . /usr/bin/cmake --build . --target install Hi Marco, this procedure is not recommended, you are directing WSJT-X to be built with your system Hamlib package but we ship WSJT-X with a snapshot of a recent Hamib sources which we recommend. I see the issue in that our CMake script may not be taking proper account of the lib64 style library directory names. I can fix this. I need to know what the first error message is from the command sequence: mkdir -p ~/WSJT-X_build/build cd !$ cmake -D CMAKE_INSTALL_PREFIX=../.wsjtx ../jtsource/wsjtx-2.0.0-rc4 cmake --build . --target install Also please do not build in the source directory, it is untested and not recommended. Once you have the build working correctly with the correct sources for Hamlib, you can make an RPM package by making the package target. 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 2.0.0-rc4
Hi Svend, On 11/14/2018 12:00 PM, Svend Aage Jessen LA6YJA wrote: The option of LOTW is giving me an error. I do not use LOTW. Is there an option of turning it off? Please follow instructions in the "Quick-Start Guide to WSJT-X 2.0", https://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf on page 5 under "LoTW Download Errors". In Norwegian: http://physics.princeton.edu/pulsar/k1jt/WSJT-X_2.0_no.pdf -- 73, Joe, K1JT ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X 2.0.0-rc4
The option of LOTW is giving me an error. I do not use LOTW. Is there an option of turning it off? -- 73 de LA6YJA la6...@savednet.com ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Colors Still have Bugs
Il 14/11/18 12:15, Bill Somerville ha scritto: > On 14/11/2018 13:32, Marco Calistri via wsjt-devel wrote: >> This is an example of "cmake sequence" commands I used: >> >> cmake -D CMAKE_CXX_COMPILER=/usr/bin/g++-8 \ >> -D CMAKE_Fortran_COMPILER=/usr/bin/gfortran-8 \ >> -D >> CMAKE_hamlib_LIBRARY_DIRS=/home/marco/WSJT-X_build/jtsource/wsjtx-2.0.0-rc4/hamlib-prefix/lib64 >> \ >> -D CMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx . >> > Hi Marco, > > firstly building in the source directory is not recommended, I > strongly recommend that you should create a build directory somewhere > then configure and build WSJT-X from that directory. > > You should not need to specify the compilers used, CMake should find > them itself. What do the commands: > > g++ -V > gfortran -V > > print? > > In order for the WSJT-X to find the Hamlib installation it built you > would add it's location to the CMake variable CMAKE_PREFIX_PATH, but > it looks like you are using the sources tarball we provide which has a > special CMake script that deals with all of this automatically as it > builds both Hamlib and WSJT-X. You should not need to specify where > Hamlib is as it is built as part of the process. Your configure and > build commands should look like: > > mkdir -p ~/WSJT-X_build/build > cd !$ > cmake -D CMAKE_INSTALL_PREFIX=../.wsjtx ../jtsource/wsjtx-2.0.0-rc4 > cmake --build . --target install > > please post the first error, if any, from this command sequence. > > 73 > Bill > G4WJS. > > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel Hi Bill, Sorry: in the meanwhile you were sending these directions, I was experimenting with the hints I received by the opensuse developer which is an Ham as well (DK3JF). Now I've finally been able to built WSJT-X from source. Additionally I had to update my libusb too, which was at version 1.0. I used this sequence: **GOOD PROCEDURE*** cd jtsource/wsjtx-2.0.0-rc4/ /usr/bin/cmake -Dhamlib_INCLUDE_DIRS=/usr/include \ -Dhamlib_LIBRARIES=/usr/lib64/libhamlib.so \ -Dhamlib_LIBRARY_DIRS=/usr/lib64 \ -DWSJT_GENERATE_DOCS=OFF \ -DWSJT_SKIP_MANPAGES=ON \ -D CMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx . /usr/bin/cmake --build . --target install Install the project... -- Install configuration: "RELEASE" -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/wsjtx -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/udp_daemon -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/message_aggregator -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/jt9 -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/wsprd -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/fmtave -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/fcal -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/fmeasure -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/ft8code -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/jt65code -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/qra64code -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/qra64sim -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/jt9code -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/jt4code -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/msk144code -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/rigctl-wsjtx -- Installing: /home/marco/WSJT-X_build/.wsjtx/bin/rigctld-wsjtx -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/doc/WSJT-X/README -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/doc/WSJT-X/COPYING -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/doc/WSJT-X/AUTHORS -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/doc/WSJT-X/THANKS -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/doc/WSJT-X/NEWS -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/doc/WSJT-X/INSTALL -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/doc/WSJT-X/BUGS -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/wsjtx/JPLEPH -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/applications/wsjtx.desktop -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/applications/message_aggregator.desktop -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/pixmaps/wsjtx_icon.png -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/doc/WSJT-X/changelog.Debian.gz -- Installing: /home/marco/WSJT-X_build/.wsjtx/share/doc/WSJT-X/copyright [100%] Built target wsjtx-install Scanning dependencies of target install [100%] Built target install Next task I would try to built a RPM package ;-) Thanks and all the best! -- 73 de Marco, PY1ZRJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Auto sequence RC4 TX6 to TX5 and back
I tried a search but came up dry on this particular issue with this level of detail: using FT8 when calling CQ, if I switch from TX6 to TX5 to send FFT (such as “QRM PSE AGN?” or “SRI NO DECODE”) and then for the next cycle I return to TX6 to return to calling CQ, if I get a decode in any subsequent cycle that should trigger my Auto Sequence to respond ( , for example) it won’t trigger the auto sequence like expected. I have “Call 1st” checked. Thanks, Jim S. N2ADV ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Band Activity Highlights
The highlights are weirding me out. I worked two stations in rc-4 and completed the Q's. Watching the band activity I saw them both again... still Green. So I went into setup and unchecked the CQ... box. Now they are Brown and I don't see any CQ's in Band Activity. I am sure you will figure this out for the next rc. Thanks Joe! Rory, K5CKS ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc4
> >> On Nov 13, 2018, at 14:23, Marco Calistri via wsjt-devel >> wrote: >> >> Despite my great interest of testing RC4, I'm a bit worry about the >> possibility to meet other stations in my area using the new FT8 >> protocol, may be this being easy in the USA but I guess will be more >> difficult in other countries like Brazil. > Perhaps you could explain why being in Brazil would make it harder to use the > new FT8 protocol over the older version? > > Gary - AG0N Hi Gary, That is _not_ specifically due the fact I'm in Brazil or even better we could consider in this aspect all the Latin America, where in any case there are certainly less stations using most recent WSJT-X releases, in comparison with USA*, which are "almost always beyond the others in this kind of matters" and are numerically greater in terms of ham-stations, but further due the fact my antenna system is really modest and it doesn't allows me to receive everyone from everywhere. Just for your information, yesterday after I installed latest RC4 on my Linux box, I have been able to decode just _one_ US station on 14 MHz (NS9I), despite many signals were present on band, for this reason I rolled back to 1.9.1 (temporarily). (*) Go to http://www.pskreporter.info/ and check yourself how many stations are using RC4 so far and from where they are. -- 73 de Marco, PY1ZRJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Congrats to the WSJT-X development team
Congratulation on the rc4 release of WSJT-X v2. The only thing I’ve noticed is a decrease in decoded traffic. Since we are now using FT8 77 bit, that seems normal to me. As far as I’m concerned, everything is fine and you guys are on track for a final release. Keep up the good work. __ Dan – K4SHQ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] "FT8 Roundup" mock contest
I'll have a radio on 20 meters with an antenna pointing west during the test.
Don AA5AU
From: Gavin Bennett
To: WSJT software development
Sent: Wednesday, November 14, 2018 8:55 AM
Subject: Re: [wsjt-devel] "FT8 Roundup" mock contest
Hi Joe
For the “official practice mock contest” can we please extend this to run
parallel on 14.078?
This will provide a better opportunity for propagation here to ZL/VK in our
early afternoon, than 40m.
73
Gavin
ZL3GAV
*Sent from my iPhone*
> On 15/11/2018, at 02:19, Joe Taylor wrote:
>
> A one-hour "practice contest" will be held next week using the FT8 mode and
> the ARRL RTTY Roundup rules.
>
> Tuesday, November 20, 0200-0300 UTC (Monday evening, NA time)
>
> Dial frequency 7.078 (and higher, in 2 kHz increments, if too much QRM).
> Everyone works everyone.
>
> To participate you must use WSJT-X 2.0.0-rc4. Installation packages for
> Windows, Linux, and macOS can be found near the bottom of this web page:
> https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>
> Note that this Release Candidate 4 ("RC4") is a beta-test version. A full
> release of WSJT-X 2.0 is targeted for release on December 10, 2018.
>
> A revised Quick-Start Guide to WSJT-X 2.0 for RC4 is posted here:
> https://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf
>
> Be sure to read this entire document before using WSJT-X 2.0. You will find
> many changes since RC3.
>
> IMPORTANT FOR THE MOCK CONTEST:
>
> 1. On the *Settings | Advanced* tab, be sure to check the
> *Special operating activity* and *ARRL RTTY Roundup* options. In the field
> labeled "Exch" enter the 2- or 3-letter abbreviation for your state or
> province (US/Canadian stations) or DX if you are not in the US or Canada.
>
> 2. Be sure that 7.078 appears in your drop-down frequency list for FT8 mode.
> You might need to do a *Reset* on the *Settings | Frequencies* tab. If the
> sub-band starting at 7.078 becomes over-crowded we suggest moving to higher
> dial frequencies in 2 kHz increments: 7.080, 7.082, etc. Type Ctrl+Shift+F12
> to move up by 2 kHz, Ctrl+Shift+F11 to move down by 2 kHz. You might want to
> change Bins/Pixel or adjust the width of the Wide Graph so as to limit the
> range of frequencies displayed to 0 - 2000 Hz.
>
> 3. Do not use a compound or nonstandard callsign in this event.
>
> Note that planning is underway for one or more dedicated FT8 contests to be
> held in the next few months. The ARRL RTTY Roundup, January 5-6 2018,
> encourages FT8 as well as RTTY participation.
>
> Post results and comments here so we can all learn from an actual FT8
> contest-like experience.
>
> If you are not already subscribed, you may wish to join the email list
> wsjt-devel:
> https://sourceforge.net/p/wsjt/mailman/?source=navbar
> That list is the best way to communicate directly with the WSJT Development
> Group.
>
> -- 73, Joe, K1JT
>
>
> ___
> 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] RC 4 not coming up with auto seq checked
> On Nov 13, 2018, at 09:51, Al Flapan wrote: > > You have to remember to check it manually. Why the change? And you have to check all of your different configurations for the change. I’ve found a few things in configuration that changed, including the rig parameters. All configurations need checked to see that they are still correct. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] v2.0.0-r4
On 14/11/2018 14:32, Jesús Gutiérrez Rodríguez wrote: Good afternoon, I have been using the new version r4 since its announcement (going through all the previous ones), however, I still do not condify any station. I understand that we are already in FT8 with 77 bits of general character and, likewise, many stations are using version r3 or earlier than 75 bits. I am following all the comments of defects and suggestions, but today, at least it should have some decoding, but negative. I use windows 10 and the program ran without any problem Please some help if you have changed any configuration regarding r3 Anyway, thank you very much for your work Cordially, Jesus, EA1YR Hi Jesus, we are recommending that beta testers of WSJT-X v2.0.0 RC4 using FT8 on HF return to the "normal" FT8 frequencies but restrict their activity to above 2000Hz Tx audio offsets. This is a move towards the eventual full GA release of v2.0.0 where we expect all users to upgrade and then this restriction due to incompatible versions of the FT8 protocol will become unnecessary. As always, do the other usual no decode checks: 1) Do you have your rig's audio correctly connected and at a suitable level? 2) Is your PC time synchronized with UTC with accuracy better than ±1 second? 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] "FT8 Roundup" mock contest
Hi Joe
For the “official practice mock contest” can we please extend this to run
parallel on 14.078?
This will provide a better opportunity for propagation here to ZL/VK in our
early afternoon, than 40m.
73
Gavin
ZL3GAV
*Sent from my iPhone*
> On 15/11/2018, at 02:19, Joe Taylor wrote:
>
> A one-hour "practice contest" will be held next week using the FT8 mode and
> the ARRL RTTY Roundup rules.
>
> Tuesday, November 20, 0200-0300 UTC (Monday evening, NA time)
>
> Dial frequency 7.078 (and higher, in 2 kHz increments, if too much QRM).
> Everyone works everyone.
>
> To participate you must use WSJT-X 2.0.0-rc4. Installation packages for
> Windows, Linux, and macOS can be found near the bottom of this web page:
> https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
>
> Note that this Release Candidate 4 ("RC4") is a beta-test version. A full
> release of WSJT-X 2.0 is targeted for release on December 10, 2018.
>
> A revised Quick-Start Guide to WSJT-X 2.0 for RC4 is posted here:
> https://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf
>
> Be sure to read this entire document before using WSJT-X 2.0. You will find
> many changes since RC3.
>
> IMPORTANT FOR THE MOCK CONTEST:
>
> 1. On the *Settings | Advanced* tab, be sure to check the
> *Special operating activity* and *ARRL RTTY Roundup* options. In the field
> labeled "Exch" enter the 2- or 3-letter abbreviation for your state or
> province (US/Canadian stations) or DX if you are not in the US or Canada.
>
> 2. Be sure that 7.078 appears in your drop-down frequency list for FT8 mode.
> You might need to do a *Reset* on the *Settings | Frequencies* tab. If the
> sub-band starting at 7.078 becomes over-crowded we suggest moving to higher
> dial frequencies in 2 kHz increments: 7.080, 7.082, etc. Type Ctrl+Shift+F12
> to move up by 2 kHz, Ctrl+Shift+F11 to move down by 2 kHz. You might want to
> change Bins/Pixel or adjust the width of the Wide Graph so as to limit the
> range of frequencies displayed to 0 - 2000 Hz.
>
> 3. Do not use a compound or nonstandard callsign in this event.
>
> Note that planning is underway for one or more dedicated FT8 contests to be
> held in the next few months. The ARRL RTTY Roundup, January 5-6 2018,
> encourages FT8 as well as RTTY participation.
>
> Post results and comments here so we can all learn from an actual FT8
> contest-like experience.
>
> If you are not already subscribed, you may wish to join the email list
> wsjt-devel:
> https://sourceforge.net/p/wsjt/mailman/?source=navbar
> That list is the best way to communicate directly with the WSJT Development
> Group.
>
>-- 73, Joe, K1JT
>
>
> ___
> 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] Inconsistency in color scheme logic - PSE name it "Worked before" instead of "New Call"
Hey, this a hobby of experimental nature. Joe and his team are providing all of this free of charge! In plain old German: „mal die Füße still halten Uwe!“ 73, Georg > Am 14.11.2018 um 15:15 schrieb Joe Taylor : > > Uwe -- > >> On 11/14/2018 6:29 AM, DG2YCB, Uwe wrote: >> >> *And PLEASE FIX ALL COLOR SCHEME BUGS BEFORE THE GA VERSION IS ANNOUNCED!!! >> *I don’t want to be impolite, but we have been discussing the color scheme >> issues at least for one and a half months now and rc4 is still full of bugs >> ... > > There is no need to SHOUT at us. > > In case you haven't noticed, there has been significant effort toward an > efficient and flexible color-highlighting scheme. This feature is closely > connected to the logging scheme, which also has evolved significantly owing > to the program's new support for contesting. Bugs will be fixed. > >-- 73, Joe, K1JT > > > ___ > 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] Inconsistency in color scheme logic - PSE name it "Worked before" instead of "New Call"
On 14/11/2018 13:57, DG2YCB, Uwe wrote: Status now (= only 4-6 weeks from deadline when ALL users in the world have to switch to v2.0.0) is that (A) most of the new highlighting ideas are not operational, and (B) the ones which worked very well until in v1.9.1 are now at least partly broken. I am really disappointed about that! (I’ve personally been in charge of dozens of development projects, so I am fully aware of all the threats and drawbacks. But here we have a quite simple decision tree. It should be not that difficult to bring it to work.) Hi Uwe, the decode highlighting has been virtually re-written, this is due to the prior implementation not being suitable for scaling up to add the new categories. Rest assured that your worries about performance and impact on decoding speed are absolutely topmost with the new implementation. I expect the impact of worked before computation on decode printing speed to be negligible, this is due to a design that builds optimally efficient in-memory indexes of the various categories that can be looked up with minimum CPU cycles. Of course there is no free lunch and there must be a cost somewhere for this high performance, that lies in updating the indexes with new entries. The update cost of adding new index entries for a new logging event is low and carried out without any impact on decoding since it is done at "user" speed. The initial cost of build the indexes is paid at application start up and there may be a point at which the size of the user's ADIF log becomes an issue, if that becomes troublesome it is not hard to offload that initial load to a separate CPU thread with decode highlighting disabled for, perhaps, the first decode period. Another cost is the memory footprint of the lookup set (there is only one table), this will be proportional to the users log file size to an extent, there are mitigating strategies available if this becomes an issue e.g. currently there is the possibility of listing QSO details of worked before matches and this may prove to be unnecessary or perhaps could be offloaded from RAM to a database table or simply not stored. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] v2.0.0-r4
Good afternoon, I have been using the new version r4 since its announcement (going through all the previous ones), however, I still do not condify any station. I understand that we are already in FT8 with 77 bits of general character and, likewise, many stations are using version r3 or earlier than 75 bits. I am following all the comments of defects and suggestions, but today, at least it should have some decoding, but negative. I use windows 10 and the program ran without any problem Please some help if you have changed any configuration regarding r3 Anyway, thank you very much for your work Cordially, Jesus, EA1YR ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc4
> On Nov 13, 2018, at 14:23, Marco Calistri via wsjt-devel > wrote: > > Despite my great interest of testing RC4, I'm a bit worry about the > possibility to meet other stations in my area using the new FT8 > protocol, may be this being easy in the USA but I guess will be more > difficult in other countries like Brazil. Perhaps you could explain why being in Brazil would make it harder to use the new FT8 protocol over the older version? Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Colors Still have Bugs
On 14/11/2018 13:32, Marco Calistri via wsjt-devel wrote: This is an example of "cmake sequence" commands I used: cmake -D CMAKE_CXX_COMPILER=/usr/bin/g++-8 \ -D CMAKE_Fortran_COMPILER=/usr/bin/gfortran-8 \ -D CMAKE_hamlib_LIBRARY_DIRS=/home/marco/WSJT-X_build/jtsource/wsjtx-2.0.0-rc4/hamlib-prefix/lib64 \ -D CMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx . Hi Marco, firstly building in the source directory is not recommended, I strongly recommend that you should create a build directory somewhere then configure and build WSJT-X from that directory. You should not need to specify the compilers used, CMake should find them itself. What do the commands: g++ -V gfortran -V print? In order for the WSJT-X to find the Hamlib installation it built you would add it's location to the CMake variable CMAKE_PREFIX_PATH, but it looks like you are using the sources tarball we provide which has a special CMake script that deals with all of this automatically as it builds both Hamlib and WSJT-X. You should not need to specify where Hamlib is as it is built as part of the process. Your configure and build commands should look like: mkdir -p ~/WSJT-X_build/build cd !$ cmake -D CMAKE_INSTALL_PREFIX=../.wsjtx ../jtsource/wsjtx-2.0.0-rc4 cmake --build . --target install please post the first error, if any, from this command sequence. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Inconsistency in color scheme logic - PSE name it "Worked before" instead of "New Call"
Uwe -- On 11/14/2018 6:29 AM, DG2YCB, Uwe wrote: *And PLEASE FIX ALL COLOR SCHEME BUGS BEFORE THE GA VERSION IS ANNOUNCED!!! *I don’t want to be impolite, but we have been discussing the color scheme issues at least for one and a half months now and rc4 is still full of bugs ... There is no need to SHOUT at us. In case you haven't noticed, there has been significant effort toward an efficient and flexible color-highlighting scheme. This feature is closely connected to the logging scheme, which also has evolved significantly owing to the program's new support for contesting. Bugs will be fixed. -- 73, Joe, K1JT ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Candidate release WSJT-X 2.0.0-rc4
Hi Jim, On 11/14/2018 12:54 AM, Jim Shorney NU0C wrote: The only little nit I have os Operator call isn't sticky in the logging box. Not that big a deal since I rarely do mutli-op, but I like to fill it in for completeness if it is there and having to enter if for each QSO gets old. Am I missing something? I've searched the settings. Did your search include the Upper-right of the Settings | Reporting tab? -- 73, Joe, K1JT ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Colors Still have Bugs
Il 14/11/18 10:54, Bill Somerville ha scritto: > On 14/11/2018 11:07, Marco Calistri via wsjt-devel wrote: >> The fact WSJT-X being a 32-bit application could then explain my >> repetitive failures during source compiling on my Linux 64-bit system? >> Do I need to install all 32-bit dependencies in order to succeed? >> >> Thanks! >> >> -- >> 73 de Marco, PY1ZRJ > > Hi Marco, > > sorry, I should have been more careful in my statement above. On MS > Windows WSJT-X is a 32-bit application. On Linux and Mac systems it > builds as a native bit-width application, i.e. on 32-bit Linux it is > 32-bit and on 64-bit Linux it is 64-bit. > > You do not need 32-bit dependencies to build WSJT-X on Linux. I will > be glad to help with resolving the issues you are seeing, please post > your questions here so that others can find the results as well. > > 73 > Bill > G4WJS. > > Hi Bill! Very glad for your feedback! Thanks for your clarification, I get confused about your statement about 32-bit. The error I always get by attempting to compile WSJT-X from source, is related to "hamlib not found" (no matter which "cmake parameter" I use) [ 50%] Built target hamlib-install [ 57%] Performing configure step for 'wsjtx' -- Building wsjtx-2.0.0-rc4 -- ** -- Building for for: Linux-x86_64 -- ** -- Boost version: 1.63.0 -- Found hamlib CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find hamlib (missing: hamlib_LIBRARY_DIRS) (Required is at least version "3") Call Stack (most recent call first): /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) CMake/Modules/Findhamlib.cmake:81 (find_package_handle_standard_args) CMakeLists.txt:853 (find_package) This is an example of "cmake sequence" commands I used: cmake -D CMAKE_CXX_COMPILER=/usr/bin/g++-8 \ -D CMAKE_Fortran_COMPILER=/usr/bin/gfortran-8 \ -D CMAKE_hamlib_LIBRARY_DIRS=/home/marco/WSJT-X_build/jtsource/wsjtx-2.0.0-rc4/hamlib-prefix/lib64 \ -D CMAKE_INSTALL_PREFIX=/home/marco/WSJT-X_build/.wsjtx . cmake --build . --target install I have just sent one email to an opensuse developer which is providing latest WSJT-X releases as rpm packages, (RC4 has been already made available) and I hope to discover something more that could be related specifically to the distribution I use which is Opensuse Tumbleweed. Regards, -- 73 de Marco, PY1ZRJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] "FT8 Roundup" mock contest
A one-hour "practice contest" will be held next week using the FT8 mode
and the ARRL RTTY Roundup rules.
Tuesday, November 20, 0200-0300 UTC (Monday evening, NA time)
Dial frequency 7.078 (and higher, in 2 kHz increments, if too much QRM).
Everyone works everyone.
To participate you must use WSJT-X 2.0.0-rc4. Installation packages for
Windows, Linux, and macOS can be found near the bottom of this web page:
https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
Note that this Release Candidate 4 ("RC4") is a beta-test version. A
full release of WSJT-X 2.0 is targeted for release on December 10, 2018.
A revised Quick-Start Guide to WSJT-X 2.0 for RC4 is posted here:
https://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf
Be sure to read this entire document before using WSJT-X 2.0. You will
find many changes since RC3.
IMPORTANT FOR THE MOCK CONTEST:
1. On the *Settings | Advanced* tab, be sure to check the
*Special operating activity* and *ARRL RTTY Roundup* options. In the
field labeled "Exch" enter the 2- or 3-letter abbreviation for your
state or province (US/Canadian stations) or DX if you are not in the US
or Canada.
2. Be sure that 7.078 appears in your drop-down frequency list for FT8
mode. You might need to do a *Reset* on the *Settings | Frequencies*
tab. If the sub-band starting at 7.078 becomes over-crowded we suggest
moving to higher dial frequencies in 2 kHz increments: 7.080, 7.082,
etc. Type Ctrl+Shift+F12 to move up by 2 kHz, Ctrl+Shift+F11 to move
down by 2 kHz. You might want to change Bins/Pixel or adjust the width
of the Wide Graph so as to limit the range of frequencies displayed to 0
- 2000 Hz.
3. Do not use a compound or nonstandard callsign in this event.
Note that planning is underway for one or more dedicated FT8 contests to
be held in the next few months. The ARRL RTTY Roundup, January 5-6 2018,
encourages FT8 as well as RTTY participation.
Post results and comments here so we can all learn from an actual FT8
contest-like experience.
If you are not already subscribed, you may wish to join the email list
wsjt-devel:
https://sourceforge.net/p/wsjt/mailman/?source=navbar
That list is the best way to communicate directly with the WSJT
Development Group.
-- 73, Joe, K1JT
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Inconsistency in color scheme logic - PSE name it "Worked before" instead of "New Call"
Uwe, as stated recently, the worked before highlighting is broken in WSJT-X v2.0.0 RC4. This is true for all worked before highlighting. A fix is in place. Please remember that RC releases are beta quality and not expected to be defect free. We have every intention to fix reported issues that are deemed to be serious enough to impact the suitability for GA release. This highlighting issue is such an issue. With respect to multiple matches for highlighting, the way they are handled is by users defining their own priorities by re-odering the list of highlighting customizations, further up the list is higher in priorty. We do not intend to set these priorities in stone as it is very much an user choice as to what type DX'ing goals they wish to pursue. 73 Bill G4WJS. On 14/11/2018 11:29, DG2YCB, Uwe wrote: Hi, In addition to the already discussed “worked before” bug, there is another inconsistency in the color scheme logic, which from my point of view is a more general issue: How is a new call highlighted, which is also a new CQ zone (and eventually also a new ITU zone, et cetera)? According to my Color scheme settings “New Call” should have not been highlighted at all, but it should have been highlighted as “CQ” unless the “New CQ Zone” was detected. All these settings did not work! In practice the call was first time highlighted as “New Call” and then as “New CQ Zone” (see screenshot). (Btw. I don’t believe that it was a new CQ zone, because I’ve already worked all of them. Means that recognition of CQ zones doesn’t work correctly either.) Unfortunately I could not work this station, so that I could not see whether it had changes anything. (RX3DHR was the only station this morning using the V2 protocol). *My proposal: Instead of “New Call” name it “Worked Before” or “Already Worked”, and make the algorithm behind it the other way round, so that it is highlighted when the station was worked before. This way round logic makes sense, because a station worked before cannot be a new call, nor a new DXCC, nor a new continent, nor a new CQ zone, nor new ITU zone, nor a new grid. *I made this proposal already on October 18^th , but didn’t get any reply until today. ** *And PLEASE FIX ALL COLOR SCHEME BUGS BEFORE THE GA VERSION IS ANNOUNCED!!! *I don’t want to be impolite, but we have been discussing the color scheme issues at least for one and a half months now and rc4 is still full of bugs regarding this (and still contains this general inconsistency)! As you want ALL FT8 USERS to change from v1.9.1 to v2.0.0 in December 2018^, this issue must NOW been solved. Otherwise it will lead to a great deal of chaos! 73 de Uwe, DG2YCB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Colors Still have Bugs
On 14/11/2018 11:07, Marco Calistri via wsjt-devel wrote: The fact WSJT-X being a 32-bit application could then explain my repetitive failures during source compiling on my Linux 64-bit system? Do I need to install all 32-bit dependencies in order to succeed? Thanks! -- 73 de Marco, PY1ZRJ Hi Marco, sorry, I should have been more careful in my statement above. On MS Windows WSJT-X is a 32-bit application. On Linux and Mac systems it builds as a native bit-width application, i.e. on 32-bit Linux it is 32-bit and on 64-bit Linux it is 64-bit. You do not need 32-bit dependencies to build WSJT-X on Linux. I will be glad to help with resolving the issues you are seeing, please post your questions here so that others can find the results as well. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Inconsistency in color scheme logic - PSE name it "Worked before" instead of "New Call"
Hi, In addition to the already discussed "worked before" bug, there is another inconsistency in the color scheme logic, which from my point of view is a more general issue: How is a new call highlighted, which is also a new CQ zone (and eventually also a new ITU zone, et cetera)? According to my Color scheme settings "New Call" should have not been highlighted at all, but it should have been highlighted as "CQ" unless the "New CQ Zone" was detected. All these settings did not work! In practice the call was first time highlighted as "New Call" and then as "New CQ Zone" (see screenshot). (Btw. I don't believe that it was a new CQ zone, because I've already worked all of them. Means that recognition of CQ zones doesn't work correctly either.) Unfortunately I could not work this station, so that I could not see whether it had changes anything. (RX3DHR was the only station this morning using the V2 protocol). My proposal: Instead of "New Call" name it "Worked Before" or "Already Worked", and make the algorithm behind it the other way round, so that it is highlighted when the station was worked before. This way round logic makes sense, because a station worked before cannot be a new call, nor a new DXCC, nor a new continent, nor a new CQ zone, nor new ITU zone, nor a new grid. I made this proposal already on October 18th, but didn't get any reply until today. And PLEASE FIX ALL COLOR SCHEME BUGS BEFORE THE GA VERSION IS ANNOUNCED!!! I don't want to be impolite, but we have been discussing the color scheme issues at least for one and a half months now and rc4 is still full of bugs regarding this (and still contains this general inconsistency)! As you want ALL FT8 USERS to change from v1.9.1 to v2.0.0 in December 2018 , this issue must NOW been solved. Otherwise it will lead to a great deal of chaos! 73 de Uwe, DG2YCB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Colors Still have Bugs
Hi Bill, > Hi Mike, > > thanks for the ADIF record, clearly something is not right, looking > into it right now. > > The reason the 32-bit version of the OpenSSL libraries are needed is > because WSJT-X is a 32-bit application. > > 73 > Bill > G4WJS. > The fact WSJT-X being a 32-bit application could then explain my repetitive failures during source compiling on my Linux 64-bit system? Do I need to install all 32-bit dependencies in order to succeed? Thanks! -- 73 de Marco, PY1ZRJ Il 13/11/18 21:33, Bill Somerville ha scritto: > On 13/11/2018 23:28, Mike wrote: >> I don't think we can be much clearer. The Quick Start Guide has a >> clickable link to the right version and it explicitly mentions that >> the 32-bit version is the right version even if you are running a >> 64-bit version of Windows. >> >> You can't be much clearer, but it still sounded like a mistake >> because I don't have Windows 32 bit. When something makes no sense to >> me I try what does first, in this case I wasn't as smart as you >> fellows are. :-) >> >> Mike N5INP > > Hi Mike, > > thanks for the ADIF record, clearly something is not right, looking > into it right now. > > The reason the 32-bit version of the OpenSSL libraries are needed is > because WSJT-X is a 32-bit application. > > 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
[wsjt-devel] Any chance of a Mac OS compile with Hamlib / SDR Kit enabled?
Hi Bill, Hope all’s well at your end. When you’re next doing a compile of the Mac OS version of WSJTZ is there any chance of enabling the SDR Kit in Hamlib. I’d love to be able to test the latest version with my Funkamateur FA-SDR kit. Thank you in advance for any help, Sean. G0OAN ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
