Re: [wsjt-devel] wspr two-pass decoder status and .c2 file problem
On 28/06/2015 22:08, Steven Franke wrote:
Thanks Bill,
Hi Steve,
For what it’s worth, here a link to the VERBOSE build capture:
https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt
Here’s the CMakeCache.txt:
https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt
OK, the problem wasn't quite what I thought. It is an include directive
ordering issue but it stems from the use of FFTW3 from MacPorts, this in
itself is not an issue but it has the side effect of picking up the Qt4
headers as well. Unfortunately I can't find an easy way of ensuring the
-I/opt/local/include is after the includes for Qt5. That would solve the
issue but the way that the Qt includes are detected by CMake doesn't
seem to have a way to change the ordering. I have posted a question to
the CMake ML but for now you should be able to build by deactivating
qt4-mac before building WSJT-X. It would be wise to add a
'--clean-first' to the CMake build for the first time to ensure any
incorrectly built object files are discarded. Something like:
$ sudo port deactivate qt4-mac
$ cmake --build ~/Builds/wsjtx --clean-first --target install -- -j
$ sudo port activate qt4-mac
$ open ~/Builds/wsjtx_install/wsjtx.app
One the WSJT-X build is complete, it doesn't use the port files as it
has the Qt frameworks bundled, the qt4-mac port can be reactivated.
The --clean-first will only be needed the first time, subsequent builds
can be minimal so long as the qt4-mac port is always deactivated while
building.
Steve k9an
73
Bill
G4WJS.
On Jun 28, 2015, at 4:01 PM, Bill Somerville g4...@classdesign.com wrote:
On 28/06/2015 21:51, Bill Somerville wrote:
On 28/06/2015 21:41, Steven Franke wrote:
John and Bill,
Hi Steve,
On Jun 28, 2015, at 2:24 PM, John Nelson j...@rmnjmn.demon.co.uk wrote:
Steve,
Back with WSJT-X. Running wsprd_exp on my Mac (OSX 10.10.3) and seeing
the improved decodes. Now using .c2 files offline to compare wsprd and
wsprd_exp. Good stuff….
Thanks, John. I’ve been meaning to ask you and/or Bill for advice. I do
all of the wsprd development on my Mac, but I have never been able to get
wsjt-x to compile. I get stuck when compiling /lib/ipcomm.cpp. I have to
resort to an Ubuntu 14.04 virtual machine if I want to test wsjt-x on the
mac.
I think that my problem may have to do with having qt4 installed via
macports (for gnuradio) and a separate installation of Qt5 for wsjt-x.
I’ll include the error messages below. I have Qt5 installed per the
instructions in the “INSTALL” text file. I have no idea why it is looking
in my /opt/local path. I used the following cmake command:
MacPorts installs stuff in /opt/local and it is correctly being picked
up by the compilers.
t
cmake -D CMAKE_PREFIX_PATH=~/local/qt-macx-clang;~/Builds/hamlib3.0 -D
CMAKE_INSTALL_PREFIX=~/Builds/wsjtx_install ~/Builds/wsjtx
Any suggestions would be much appreciated!
The problem seems to be that the compiler is getting the
/opt/local/include path ahead of the stuff included via the
CMAKE_PREFIX_PATH. That shouldn't be happening.
Looks like this is a known issue with the qt4-mac port. I'll install it
on my Mac VM and see if I can find an easy workaround.
I suggest that a fresh build tree and configure with CMake followed by a
CMake build adding ' -- VERBOSE=1' to the end of the build command.
Capture the output and post it somewhere I can have a look at it along
with the CMakeCache.txt file from the build tree root.
Steve k9an
73
Bill
G4WJS.
Here’s the error log:
[ 69%] Building CXX object CMakeFiles/jt9.dir/lib/ipcomm.cpp.o
In file included from /Users/sfranke/Builds/wsjtx/lib/ipcomm.cpp:1:
In file included from
/Users/sfranke/local/qt-macx-clang/lib/QtCore.framework/Headers/QDebug:1:
/Users/sfranke/local/qt-macx-clang/lib/QtCore.framework/Headers/qdebug.h:65:9:
error:
unknown type name 'QMessageLogContext'
QMessageLogContext context;
^
/Users/sfranke/local/qt-macx-clang/lib/QtCore.framework/Headers/qdebug.h:129:1:
error: no
member named 'isDetached' in 'QDebug'
Q_DECLARE_SHARED(QDebug)
^~~~
/opt/local/include/QtCore/qglobal.h:2255:63: note: expanded from macro
'Q_DECLARE_SHARED'
template inline bool qIsDetachedTYPE(TYPE t) { return
t.isDetached(); } \
~ ^
In file included from /Users/sfranke/Builds/wsjtx/lib/ipcomm.cpp:1:
In file included from
/Users/sfranke/local/qt-macx-clang/lib/QtCore.framework/Headers/QDebug:1:
/Users/sfranke/local/qt-macx-clang/lib/QtCore.framework/Headers/qdebug.h:129:1:
error: no
member named 'data_ptr' in 'QDebug'
Q_DECLARE_SHARED(QDebug)
^~~~
/opt/local/include/QtCore/qglobal.h:2257:16: note: expanded from macro
'Q_DECLARE_SHARED'
{ qSwap(value1.data_ptr(), value2.data_ptr()); } \
~~ ^
In file included from
[wsjt-devel] Building WSJT
Hi All Another very basic question. Trying to build WSJT using JTSDK-PY. I did an update on JTSDK v2.0 and then tried to build (package). Got an error python33.dll missing shortly after starting. Any help much appreciated. 73 Charlie -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] [WSJT_SS_ISCAT] RRR bug fixed
Good morning Everyone, I am rolling Joe’s RRR fix into what what will be a numbered version to be (if all goes well) released later today. Instead of ISCAT Experiment Vx it will have a number like other versions of WSJT. This is because as of the changes today I am moving the development over to the source code repository to avoid conflict with any further changes Joe and others might make. This will also allow folks who want to run on other platforms to compile and hopefully run with the new changes. While it was convenient to run the experimental version offline from the repository there is a danger in that in when other developers do something it can sometimes be at odds with what you are working on. The fixes Joe made to how WSJT reports ISCAT decodes are a case in point, I had already done that in order to pass multiple decodes to the auto sequencer, it is looking for exact text so it was one way to sometimes get around the RRR issue. Now that Joe has also done this I need to merge what I did, what he did and at the same time make sure I do not break the fix. Because I have already dealt extensively with reporting ISCAT the decoder routing will go back to always placing all decodes into file that is processed by higher level routines. At the decode level it will only write the “best” decode into All.txt. Up at the auto sequence level I have added at a “Report All ISCAT Decodes” to the Setup menu that will cause all of the decodes to be reported and written to all.txt. As before if a decode was used by the auto sequencer to advance it will be marked with an ‘a’. The Sync setting will not affect this. I am excited to see how the changes work. And remember Joe has put out a call for wav files showing when the decoder was not working. Remember to include comments about what you were expecting to RX, what you did RX and screenshots showing context are always helpful. 73 de Bill ND0B From: mailto:wsjt_ss_is...@yahoogroups.com Sent: Saturday, June 27, 2015 12:49 PM To: 'WSJT software development' ; wsjt_ss_is...@yahoogroups.com Subject: [WSJT_SS_ISCAT] RRR bug fixed Hi all, I have found and corrected a problem that several have noticed in the ISCAT decoder in WSJT. The bug was especially troublesome in messages containing a single repeated character, such as the message RRR. The problem is fixed in the WSJT code repository as of revision 5634. Bill (ND0B) should update his code branch accordingly, so that the ISCAT_SS test version of WSJT will use the improved decoder. Note: Up to now the ISCAT decoder has made its own decision about the most reliable decoded message and displayed only that one. For testing, at least, I have changed the logic so that if the Sync limit is set to 0, many decodes (based on different parts of the received signal) can be displayed. With higher Sync settings only the best will be displayed, as before. This is a good time also for me to make a special request of all those using ISCAT with Bill's recent program improvements. Further improvements to the ISCAT decoder are possible. The necessary work will be easier and the results more reliable if I have a good collection of *.wav files containing real over-the-air ISCAT signals. The most useful files will be ones where the signal is weak and barely decodable or not quite decodable. If you are testing ISCAT and this is easy for you to do, please zip up a collection of several such files and send them to me. Many thanks! -- 73, Joe, K1JT __._,_.___ Posted by: Joe Taylor j...@princeton.edu Reply via web post • Reply to sender • Reply to group • Start a New Topic • Messages in this topic (1) Visit Your Group a.. New Members 30 • Privacy • Unsubscribe • Terms of Use . __,_._,___-- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wspr two-pass decoder status and .c2 file problem
Hi Steve, I use a script to make life easy. The working part of the script is this: cmake -D CMAKE_BUILD_TYPE=$ctype -D CMAKE_INSTALL_PREFIX=~/G4KLA/Rev$1/$rel \ -D CMAKE_PREFIX_PATH=~/Qt5.4.0;/usr/local/hamlib \ -D CMAKE_OSX_DEPLOYMENT_TARGET=10.9 \ -D CMAKE_C_COMPILER=clang -D CMAKE_CXX_COMPILER=clang++ \ -D CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk \ -D WSJT_SKIP_MANPAGES=ON -D WSJT_GENERATE_DOCS=OFF ~/G4KLA/Rev$1/wsjtx cmake --build . --target $btype -- -kj $ctype is either Debug or Release $1 points to the current location of the downloaded software $rel can be either rel, the directory for a release version; or rel_deb the directory for the debug version $btype is eitherinstall to produce a local version or package to produce a full-formed .dmg for distribution. I use the latest Qt version I have downloaded Bill's hamlib which I keep uptodate. I do not use Macports. So, for me,wsjtx_comp X5636 Release installbuilds a local package. Hope this helps... --- John G4KLA -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RRR bug fixed, WSJT crash on Fedora 21
Hi Joe and Bill, I compiled WSJT SVN r5635 on my Ubuntu 14.04 LTS x86_64 box and yes, the fast modes JTMS etc do not crash and do not gobble memory. So, I guess, Fedora 21 uses later Python etc. libraries. Earlier this year, when Fedora 21 first came out for ARMv7 (Pi and clones) I did compile up WSJT, but obviously did not adequately test it. I tested it today and the fast modes crash in the same way as the Intel architecture. As I see it, Fedora is THE Red Hat linux flavour. They (Fedora) put a LOT of work into the ARM platform. This allows ultra low power apps for balloons etc.. And, of course, remote sites on solar power. As far as I know, you access to my ARM box here has not changed. You have GUI via RDP. User: wsjtdev Keep Smiling Alan VK2ZIW On Sun, 28 Jun 2015 09:31:40 -0400, Joe Taylor wrote Hi Alan, On 6/28/2015 3:10 AM, Alan VK2ZIW wrote: WSJT compiled from SVN r5635 crashes in modes JTMS, FSK441, ISCAT-A and ISCAT-B. But, is fine on all JT65 and JT4 modes. Crash is a memory leak and, when RES memory (top) runs out, crash. Takes 10 mins or less. Obvious with top system monitor. System: Fedora 21 x86_64 on ASRock QC5000-ITX motherboard. (all standard dev tools) I don't presently have a Fedora-based machine. Under Windows and Ubuntu Linux I see no such bad behavior. All WSJT modes run as expected, over long times and with no evident memory leaks. Perhaps you can make some tests to isolate the code leading to a memory leak on your system. I note that your problem is with the WSJT fast modes -- those for which the waterfall scrolls horizontally. That might be a good place to start your search. Also, idWarn in wsjt.py is not defined. Is this causing a problem for you? As far as I am aware the functions using this variable perform as expected. -- 73, Joe, K1jT -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel Alan Man's greatest waste of time: Worshipping the wrong God. Consider Jesus. --- Alan Beard Unix Support Technician from 1984 to today 70 Wedmore Rd. Sun Solaris, AIX, HP/UX, Linux, SCO, MIPS Emu Heights N.S.W. 2750 Routers, terminal servers, printers, terminals etc.. +61 2 47353013 (h) Support Programming, shell scripting, C, assembler 0414 353013 (mobile) After uni, electronics tech -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Building WSJT
Hi Charlie, First, after running build-wsjt package, and before installing WSJT with the installer, check to see if python33.dll in C:\JTSDK\wsjt\install\bin. You should also see the msvcr100.dll's along with various other binaries / dll's. Once installed, how are you running WSJT, from the Start Menu or other method? 73's Greg, KI7MT On 6/29/2015 5:37 AM, char...@sucklingfamily.free-online.co.uk wrote: Hi All Another very basic question. Trying to build WSJT using JTSDK-PY. I did an update on JTSDK v2.0 and then tried to build (package). Got an error python33.dll missing shortly after starting. Any help much appreciated. 73 Charlie -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Building WSJT
Hi Greg The missing python33.dll came up shortly after starting the build process and the build did not complete. 73 Charlie Hi Charlie, First, after running build-wsjt package, and before installing WSJT with the installer, check to see if python33.dll in C:\JTSDK\wsjt\install\bin. You should also see the msvcr100.dll's along with various other binaries / dll's. Once installed, how are you running WSJT, from the Start Menu or other method? 73's Greg, KI7MT On 6/29/2015 5:37 AM, char...@sucklingfamily.free-online.co.uk wrote: Hi All Another very basic question. Trying to build WSJT using JTSDK-PY. I did an update on JTSDK v2.0 and then tried to build (package). Got an error python33.dll missing shortly after starting. Any help much appreciated. 73 Charlie -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Building WSJT
Hi Charlie, Ok, sorry I misunderstood your post. Well, that can only be one of a couple things then. Start a Maintenance Terminal: Start Programs JTSDK Tools JTSDK Maintenance then type: update upgrade That should ensure the python33.dll is in the Python root directory and the python33 DLLs directory C:\JTSDK\python33\python33.dll C:\JTSDK\python33\DLLs\python33.dll If that does not do what it is supposed to do, let me know. At that point, you can simply copy the dll from the DLLs directory to the python33 root directory, but I'll need to fix the update, as it has been working for others. 73's Greg, KI7MT On 6/29/2015 9:32 AM, char...@sucklingfamily.free-online.co.uk wrote: Hi Greg The missing python33.dll came up shortly after starting the build process and the build did not complete. 73 Charlie Hi Charlie, First, after running build-wsjt package, and before installing WSJT with the installer, check to see if python33.dll in C:\JTSDK\wsjt\install\bin. You should also see the msvcr100.dll's along with various other binaries / dll's. Once installed, how are you running WSJT, from the Start Menu or other method? 73's Greg, KI7MT On 6/29/2015 5:37 AM, char...@sucklingfamily.free-online.co.uk wrote: Hi All Another very basic question. Trying to build WSJT using JTSDK-PY. I did an update on JTSDK v2.0 and then tried to build (package). Got an error python33.dll missing shortly after starting. Any help much appreciated. 73 Charlie -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RRR bug fixed, WSJT crash on Fedora 21
Hi Alan, It appears, Fedora 21 is using python3-pillow 2.6.2 according to RPM find. Pillow 2.6.x has been problematic on several distros I've used / tested. The problems seems to be isolated to those using Pillow v2.6.x ( Debian Jessie, Ubuntu 15.04, etc. ). Distro's using earlier or latter versions of Pillow do not exhibit the same problem. To resolve this on Debian / Ubuntu, I installed the Pillow build dependencies then installed ( compiled ) the latest version of Pillow via Pip3. FWIW, Here's what I used for Jessie / Utopic: * Open a termainl, Ctrl+Alt+T * sudo apt-get update * sudo apt-get install libfreetype6-dev libjpeg-dev liblcms2-dev libtiff5-dev libwebp-dev libwebpmux1 mime-support tcl8.6-dev tk8.6-dev zlib1g-dev * sudo pip3 install --upgrade pillow I'm not entirely sure if the real root cause is Pillow or the combination of Pillow 2.6.x being built against tcl/tk 8.5 or not. But building form Source ( using pip3 ) against tcl/tk-8.6 seems to resolve the horizontal display crashes on Jessie and Utopic. 73's Greg, KI7MT On 6/29/2015 6:14 AM, Alan VK2ZIW wrote: Hi Joe and Bill, I compiled WSJT SVN r5635 on my Ubuntu 14.04 LTS x86_64 box and yes, the fast modes JTMS etc do not crash and do not gobble memory. So, I guess, Fedora 21 uses later Python etc. libraries. Earlier this year, when Fedora 21 first came out for ARMv7 (Pi and clones) I did compile up WSJT, but obviously did not adequately test it. I tested it today and the fast modes crash in the same way as the Intel architecture. As I see it, Fedora is THE Red Hat linux flavour. They (Fedora) put a LOT of work into the ARM platform. This allows ultra low power apps for balloons etc.. And, of course, remote sites on solar power. As far as I know, you access to my ARM box here has not changed. You have GUI via RDP. User: wsjtdev Keep Smiling Alan VK2ZIW On Sun, 28 Jun 2015 09:31:40 -0400, Joe Taylor wrote Hi Alan, On 6/28/2015 3:10 AM, Alan VK2ZIW wrote: WSJT compiled from SVN r5635 crashes in modes JTMS, FSK441, ISCAT-A and ISCAT-B. But, is fine on all JT65 and JT4 modes. Crash is a memory leak and, when RES memory (top) runs out, crash. Takes 10 mins or less. Obvious with top system monitor. System: Fedora 21 x86_64 on ASRock QC5000-ITX motherboard. (all standard dev tools) I don't presently have a Fedora-based machine. Under Windows and Ubuntu Linux I see no such bad behavior. All WSJT modes run as expected, over long times and with no evident memory leaks. Perhaps you can make some tests to isolate the code leading to a memory leak on your system. I note that your problem is with the WSJT fast modes -- those for which the waterfall scrolls horizontally. That might be a good place to start your search. Also, idWarn in wsjt.py is not defined. Is this causing a problem for you? As far as I am aware the functions using this variable perform as expected. -- 73, Joe, K1jT -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel Alan Man's greatest waste of time: Worshipping the wrong God. Consider Jesus. --- Alan Beard Unix Support Technician from 1984 to today 70 Wedmore Rd. Sun Solaris, AIX, HP/UX, Linux, SCO, MIPS Emu Heights N.S.W. 2750 Routers, terminal servers, printers, terminals etc.. +61 2 47353013 (h) Support Programming, shell scripting, C, assembler 0414 353013 (mobile) After uni, electronics tech -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now
Re: [wsjt-devel] Building WSJT
Hi Greg That worked perfectly, thanks. The .dll files were there and the build went fine. Very fast compared to -X. I think my mistake was to use the JTSDK Update in Start Program JTSDK rather than following the route below, which perhaps resulted in no Upgrade step. 73 Charlie Hi Charlie, Ok, sorry I misunderstood your post. Well, that can only be one of a couple things then. Start a Maintenance Terminal: Start Programs JTSDK Tools JTSDK Maintenance then type: update upgrade That should ensure the python33.dll is in the Python root directory and the python33 DLLs directory C:\JTSDK\python33\python33.dll C:\JTSDK\python33\DLLs\python33.dll If that does not do what it is supposed to do, let me know. At that point, you can simply copy the dll from the DLLs directory to the python33 root directory, but I'll need to fix the update, as it has been working for others. 73's Greg, KI7MT On 6/29/2015 9:32 AM, char...@sucklingfamily.free-online.co.uk wrote: Hi Greg The missing python33.dll came up shortly after starting the build process and the build did not complete. 73 Charlie Hi Charlie, First, after running build-wsjt package, and before installing WSJT with the installer, check to see if python33.dll in C:\JTSDK\wsjt\install\bin. You should also see the msvcr100.dll's along with various other binaries / dll's. Once installed, how are you running WSJT, from the Start Menu or other method? 73's Greg, KI7MT On 6/29/2015 5:37 AM, char...@sucklingfamily.free-online.co.uk wrote: Hi All Another very basic question. Trying to build WSJT using JTSDK-PY. I did an update on JTSDK v2.0 and then tried to build (package). Got an error python33.dll missing shortly after starting. Any help much appreciated. 73 Charlie -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Building WSJT
Hi Charlie, OK, glad it's working. It's not a mistake on your part. The method you were using is fine, however, for that particular update, the upgrade script needed to be modified, thus the reason for using the maintenance terminal. As for Speed, the WSJT-X build is doing allot more and we're at the mercy of a couple of functions that are simply slow on Windows, there's not much that can be done about that. You can however, you can build the WSJT-X Debug target for a much quicker turn around, but you need to launch it with the wsjtx.cmd script in order to set the appropriate paths. 73's Greg, KI7MT On 6/29/2015 10:37 AM, char...@sucklingfamily.free-online.co.uk wrote: Hi Greg That worked perfectly, thanks. The .dll files were there and the build went fine. Very fast compared to -X. I think my mistake was to use the JTSDK Update in Start Program JTSDK rather than following the route below, which perhaps resulted in no Upgrade step. 73 Charlie Hi Charlie, Ok, sorry I misunderstood your post. Well, that can only be one of a couple things then. Start a Maintenance Terminal: Start Programs JTSDK Tools JTSDK Maintenance then type: update upgrade That should ensure the python33.dll is in the Python root directory and the python33 DLLs directory C:\JTSDK\python33\python33.dll C:\JTSDK\python33\DLLs\python33.dll If that does not do what it is supposed to do, let me know. At that point, you can simply copy the dll from the DLLs directory to the python33 root directory, but I'll need to fix the update, as it has been working for others. 73's Greg, KI7MT On 6/29/2015 9:32 AM, char...@sucklingfamily.free-online.co.uk wrote: Hi Greg The missing python33.dll came up shortly after starting the build process and the build did not complete. 73 Charlie Hi Charlie, First, after running build-wsjt package, and before installing WSJT with the installer, check to see if python33.dll in C:\JTSDK\wsjt\install\bin. You should also see the msvcr100.dll's along with various other binaries / dll's. Once installed, how are you running WSJT, from the Start Menu or other method? 73's Greg, KI7MT On 6/29/2015 5:37 AM, char...@sucklingfamily.free-online.co.uk wrote: Hi All Another very basic question. Trying to build WSJT using JTSDK-PY. I did an update on JTSDK v2.0 and then tried to build (package). Got an error python33.dll missing shortly after starting. Any help much appreciated. 73 Charlie -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Monitor 25 network devices or servers for free with OpManager! OpManager is
[wsjt-devel] Fw: [WSJT_SS_ISCAT] RRR bug fixed
Forwarded without wav file attachment and embedded screen shot to reduce size, if anyone would like those drop me an email direct From: mailto:wsjt_ss_is...@yahoogroups.com Sent: Monday, June 29, 2015 10:44 AM To: wsjt_ss_is...@yahoogroups.com ; K1JT Subject: Re: [WSJT_SS_ISCAT] RRR bug fixed Good morning Joe, I just completed integrating my changes and have committed them as Rev 5637. Part of the integration process was modifying the version of ISCAT.f90 to encompass both mine and your changes, your change was very close to what I was doing do the changes I had to make were mostly cosmetic although I did move writing all messages up to the wsjt.py level with a Setup check on when to do it. I have noticed an issue with decode of a strong non repetitive signal. The attached wav is a TX2 from W3CP to myself that is pretty much full sequence and very strong. As you will note, with one exception the decode is garbage. The decoder and also my auto sequencer did find the right one but this seemed odd based on the quality of the received signal. To get this dump check Setup/Report All ISCAT Messages. If this is not checked then just the ISCAT decoder selected messages is displayed. Your thoughts appreciated, 73 de Bill ND0B From: mailto:wsjt_ss_is...@yahoogroups.com Sent: Saturday, June 27, 2015 12:49 PM To: 'WSJT software development' ; wsjt_ss_is...@yahoogroups.com Subject: [WSJT_SS_ISCAT] RRR bug fixed Hi all, I have found and corrected a problem that several have noticed in the ISCAT decoder in WSJT. The bug was especially troublesome in messages containing a single repeated character, such as the message RRR. The problem is fixed in the WSJT code repository as of revision 5634. Bill (ND0B) should update his code branch accordingly, so that the ISCAT_SS test version of WSJT will use the improved decoder. Note: Up to now the ISCAT decoder has made its own decision about the most reliable decoded message and displayed only that one. For testing, at least, I have changed the logic so that if the Sync limit is set to 0, many decodes (based on different parts of the received signal) can be displayed. With higher Sync settings only the best will be displayed, as before. This is a good time also for me to make a special request of all those using ISCAT with Bill's recent program improvements. Further improvements to the ISCAT decoder are possible. The necessary work will be easier and the results more reliable if I have a good collection of *.wav files containing real over-the-air ISCAT signals. The most useful files will be ones where the signal is weak and barely decodable or not quite decodable. If you are testing ISCAT and this is easy for you to do, please zip up a collection of several such files and send them to me. Many thanks! -- 73, Joe, K1JT __._,_.___ Posted by: Bill Ockert - ND0B n...@ockert.us Reply via web post • Reply to sender • Reply to group • Start a New Topic • Messages in this topic (5) Visit Your Group a.. New Members 29 • Privacy • Unsubscribe • Terms of Use . __,_._,___-- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Version R 5637 up on Google Driver
Everyone, the latest release, R 5637 is up on Google Drive along with the text file. https://drive.google.com/folderview?id=0B42rF4Jby8-vfjZza0I3VUN6UXFEa2NDdGszajZlOGk0TEhTeTFhSUY3UF81WmV4THVaVE0usp=sharing Note: If you were running with AFC checked (like me) please uncheck it. While the old decoder may or may not have worked better with it checked it should not be checked with the new decoder. If you see anything odd with the decoder please send a wav file and a description of the issue to Joe and myself. If you see anything odd with the auto sequencer or auto configuration please send a wav file and description to me. In both cases screen shots are very helpful. Change Log 1. Starting with this version the source code is being checked into the WSJT source code repository so the changes become part of the next release of WSJT. As a consequence we have gone from ISCAT Experimental versions to R Versions both for discussion and what is shown on the title line of the program. 2. Joe's RRR bug fix is in this version. IF YOU WERE (LIKE ME) RUNNING WITH AFC CHECKED YOU MUST UNCHECK IT. 3. Fixed bug where Auto sequencer was active even if Auto is Off was set. 4. Fixed bug where auto configure was not setting the signal report if appropriate. 5. Added Setup/Report All ISCAT Messages if you want to see all the messages the decoder produces while not in auto mode.If this is not checked only the best message is shown. In auto mode only the message used is shown. Enjoy! 73 de Bill ND0B __._,_.___ Posted by: n...@ockert.us Reply via web post • Reply to sender • Reply to group • Start a New Topic • Messages in this topic (1) Visit Your Group a.. New Members 30 • Privacy • Unsubscribe • Terms of Use . __,_._,___-- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wspr two-pass decoder status and .c2 file problem
Hi Joe, On Jun 29, 2015, at 11:53 AM, Joe Taylor j...@princeton.edu wrote: Hi Steve and all, I have run a new series of tests of various WSPR decoders, with results that may be of interest to others. The test runs all used the same set of 386 *.wav files, processed with the following decoders: 1. wsprd, from WSPR-X (baseline decoder) 2. wspr4 3. wsprd, as built for WSJT-X v1.6.0 r5636 4. wsprd_exp, signal subtraction using symbol-by-symbol coherence 5. wsprd_exp, subtraction with full coherence and test for local maxima 6. wsprd_exp, subtraction with full coherence and snr min_snr For each run the following table gives the number of decodes, the wall-clock running time, the average time per wav file, and the improvement factor for number of decodes and speed. Decodes Time1 AvgTimeImprovement Decoder (s)(s)Decodes Speed 1. 1451 2111 5.5 1.001.00 baseline 2. 1693 1599 4.1 1.171.32 wspr4 3. 2208335 0.9 1.526.30 WSJT-X v1.6.0 r5636 4. 2464413 1.1 1.705.11 partial coherence 5. 2567431 1.1 1.774.90 full coherence 6. 2839 2136 5.5 1.960.99 more candidates Thanks for running these tests. These agree with my results, although I see somewhat more improvement as you go down the list, probably because my test files are all from 20m under crowded band conditions. At some point, we should look at the coherent subtraction lowpass filter. The length (nfilt) and impulse response were chosen without much thought... Steve k9an I think these results show some truly remarkable improvements in performance! Our slowest decoder, that used for run #6, is essentially the same speed as the original decoder packaged with WSPR-X -- yet it produces twice as many decodes! Although it's arguably fast enough already, I am confident that we can make it faster. Run #5, which used the two-pass decoder with full-coherence subtraction of decoded signals, is impressive with respect to *both* speed and thoroughness. -- Joe, K1JT -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-x build problem on OS X
On 29/06/2015 22:30, Steven Franke wrote: Bill, Hi Steve, On Jun 29, 2015, at 4:26 PM, Bill Somerville g4...@classdesign.com wrote: On 29/06/2015 22:17, Steven Franke wrote: Bill, On Jun 29, 2015, at 3:57 PM, Bill Somerville g4...@classdesign.com wrote: On 29/06/2015 21:34, Steven Franke wrote: Bill, On Jun 29, 2015, at 9:00 AM, Bill Somerville g4...@classdesign.com wrote: On 28/06/2015 22:08, Steven Franke wrote: Thanks Bill, Hi Steve, For what it’s worth, here a link to the VERBOSE build capture: https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt Here’s the CMakeCache.txt: https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt OK, the problem wasn't quite what I thought. It is an include directive ordering issue but it stems from the use of FFTW3 from MacPorts, this in itself is not an issue but it has the side effect of picking up the Qt4 headers as well. Unfortunately I can't find an easy way of ensuring the -I/opt/local/include is after the includes for Qt5. That would solve the issue but the way that the Qt includes are detected by CMake doesn't seem to have a way to change the ordering. I have posted a question to the CMake ML but for now you should be able to build by deactivating qt4-mac before building WSJT-X. It would be wise to add a '--clean-first' to the CMake build for the first time to ensure any incorrectly built object files are discarded. Something like: $ sudo port deactivate qt4-mac $ cmake --build ~/Builds/wsjtx --clean-first --target install -- -j $ sudo port activate qt4-mac $ open ~/Builds/wsjtx_install/wsjtx.app This got me past the incorrect headers issue, but now it dies because of an OpenMP problem. I’ve placed the VERBOSE build capture here: https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt and the CMakeCache.txt here: https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt Is your OS X 32-bit or 64-bit? https://support.apple.com/en-gb/HT201948 My processor is 64-bit: Hardware Overview: Model Name: MacBook Air Model Identifier:MacBookAir5,2 Processor Name: Intel Core i7 Processor Speed: 2 GHz Number of Processors:1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache:4 MB Memory: 8 GB Boot ROM Version:MBA51.00EF.B02 SMC Version (system):2.5f9 Serial Number (system): C02J401ADRVG Hardware UUID: 1F7ABB4C-7FB0-5918-8AE6-0CA0AB789A89 and I am running the 64-bit kernel: $ uname -a Darwin Stevens-MacBook-Air.local 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64 OK, looks like the MacPorts libgcc is 32-bit only for some reason. What do the following print: $ grep build_arch /opt/local/etc/macports/macports.conf $ grep build_arch /opt/local/etc/macports/macports.conf #build_arch i386 and: $ grep universal /opt/local/etc/macports/macports.conf $ grep universal /opt/local/etc/macports/macports.conf # CPU architectures to use for Universal Binaries (+universal variant) universal_archs x86_64 i386 and: $ file /opt/local/lib/gcc49/libgomp.1.dylib $ file /opt/local/lib/gcc49/libgomp.1.dylib /opt/local/lib/gcc49/libgomp.1.dylib: Mach-O 64-bit dynamically linked shared library x86_64 Hmm, that is all as expected. I think that means the link is picking up another libgomp from somewhere outside of MacPorts. The only other path that seems likely is /usr/local/lib is there an old libgomp there from some prior build of gcc/gfortran? Also what does: $ nm -gU /opt/local/lib/gcc49/libgomp.1.dylib | grep parallel print? ... 73 Bill G4WJS. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X and FT991 CAT issue
Hello to all Not sure if this report is more relevant to Hamlib or the WSJT team, I am testing a Yaesu FT-991 with WSJT-X release 5636 mainly in WSPR-2 mode : PC : Windows 8.1Intel I7 8GB Memory TRX : Yaesu FT 991 - USB connected Drivers : CP_210X_windows as per Yaesu site Hambib3 Build from G4WJS Public using JTSDK-Mysys (29/06/2015) Issue : CAT not working In setting radio Windows : Rig failure , Hamlib error : feature not available while opening connection to rig . I have tried via command line rigctl an seems to get same issue ! Am I using the correct version of Hamlib3 to build WSJT-X ? is there some further debug information I can provide you to assist with identification of the issue? ( FYI exactly same code work like a charm with an FT897 and an FTDI based interface) Congratulations and thanks to all for the great job done in inclusion of wspr mode in wsjt-x, the enhancements to the wspr decoder are just terrific ! J Best regards Jean Louis F5DJL -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X and FT991 CAT issue
Run rigctl with - and send the results around where the error occurs. 73 Mike W9MDB From: f5djl [mailto:newsl...@f5djl.fr] Sent: Monday, June 29, 2015 4:21 PM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] WSJT-X and FT991 CAT issue Hello to all Not sure if this report is more relevant to Hamlib or the WSJT team, I am testing a Yaesu FT-991 with WSJT-X release 5636 mainly in WSPR-2 mode : PC : Windows 8.1Intel I7 8GB Memory TRX : Yaesu FT 991 - USB connected Drivers : CP_210X_windows as per Yaesu site Hambib3 Build from G4WJS Public using JTSDK-Mysys (29/06/2015) Issue : CAT not working In setting radio Windows : Rig failure , Hamlib error : feature not available while opening connection to rig . I have tried via command line rigctl an seems to get same issue ! Am I using the correct version of Hamlib3 to build WSJT-X ? is there some further debug information I can provide you to assist with identification of the issue? ( FYI exactly same code work like a charm with an FT897 and an FTDI based interface) Congratulations and thanks to all for the great job done in inclusion of wspr mode in wsjt-x, the enhancements to the wspr decoder are just terrific ! J Best regards Jean Louis F5DJL -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results
On 29/06/2015 23:51, f5djl wrote: Bill and Michael Bon Soir Jean-Louis, Thanks a lot for your advice and here below is the result of rigctl-wsjtx . OK, looks like the recently added driver for the FT-991 is incomplete. It is falling over when it tries to check if the CAT command it is about to use is valid for the rig. I will get the official version 1.5.0 installed tomorrow to confirm if I get similar results. I think you will get the same result. We will sort out a patch for Hamlib3 to fix this. Very best regards Jean-Louis - F5DJL 73 Bill G4WJS. C:\WSJT\wsjtx\binrigctl-wsjtx - -m135 -scom5 f rigctl, Hamlib 3.0~git Report bugs to hamlib-develo...@lists.sourceforge.net rig:rig_init called yaesu: initrigs3_yaesu called rig_register (121) rig_register (127) rig_register (110) rig_register (105) rig_register (106) rig_register (107) rig_register (109) rig_register (120) rig_register (101) rig_register (122) rig_register (123) rig_register (111) rig_register (115) rig_register (113) rig_register (114) rig_register (128) rig_register (131) rig_register (116) rig_register (103) rig_register (124) rig_register (104) rig_register (125) rig_register (129) rig_register (132) rig_register (130) rig_register (117) rig_register (119) rig_register (118) rig_register (126) rig_register (133) rig_register (134) rig_register (135) ft991_init called newcat_init called rig:rig_open called newcat_open called newcat_set_trn called newcat_valid_command called newcat_valid_command: 'FT-991' is unknown rig_open: error = Feature not available C:\WSJT\wsjtx\bin *De :*Bill Somerville [mailto:g4...@classdesign.com] *Envoyé :* lundi 29 juin 2015 23:51 *À :* wsjt-devel@lists.sourceforge.net *Objet :* Re: [wsjt-devel] WSJT-X and FT991 CAT issue On 29/06/2015 22:21, f5djl wrote: Hello to all Bon Soir Jean-Louis Not sure if this report is more relevant to Hamlib or the WSJT team, I am testing a Yaesu FT-991 with WSJT-X release 5636 mainly in WSPR-2 mode : PC : Windows 8.1Intel I7 8GB Memory TRX : Yaesu FT 991 - USB connected Drivers : CP_210X_windows as per Yaesu site Hambib3 Build from G4WJS Public using JTSDK-Mysys (29/06/2015) Issue : CAT not working In setting radio Windows : Rig failure , Hamlib error : feature not available while opening connection to rig . I have tried via command line rigctl an seems to get same issue ! To test with rigctl you must use the rigctl-wsjtx.exe that the WSJT-X produces if you want to compare with the same Hamlib 3 rig drivers. Am I using the correct version of Hamlib3 to build WSJT-X ? is there some further debug information I can provide you to assist with identification of the issue? ( FYI exactly same code work like a charm with an FT897 and an FTDI based interface) The easiest way to eliminate build issues is to try with the official v1.5.0 release, this has essentially the same Hamlib 3 code as the error you are seeing is not mode specific. Congratulations and thanks to all for the great job done in inclusion of wspr mode in wsjt-x, the enhancements to the wspr decoder are just terrific ! J It is good! Congratulations to Steve and Joe. Best regards Jean Louis F5DJL 73 Bill G4WJS. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-x build problem on OS X
On 29/06/2015 21:34, Steven Franke wrote: Bill, On Jun 29, 2015, at 9:00 AM, Bill Somerville g4...@classdesign.com wrote: On 28/06/2015 22:08, Steven Franke wrote: Thanks Bill, Hi Steve, For what it’s worth, here a link to the VERBOSE build capture: https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt Here’s the CMakeCache.txt: https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt OK, the problem wasn't quite what I thought. It is an include directive ordering issue but it stems from the use of FFTW3 from MacPorts, this in itself is not an issue but it has the side effect of picking up the Qt4 headers as well. Unfortunately I can't find an easy way of ensuring the -I/opt/local/include is after the includes for Qt5. That would solve the issue but the way that the Qt includes are detected by CMake doesn't seem to have a way to change the ordering. I have posted a question to the CMake ML but for now you should be able to build by deactivating qt4-mac before building WSJT-X. It would be wise to add a '--clean-first' to the CMake build for the first time to ensure any incorrectly built object files are discarded. Something like: $ sudo port deactivate qt4-mac $ cmake --build ~/Builds/wsjtx --clean-first --target install -- -j $ sudo port activate qt4-mac $ open ~/Builds/wsjtx_install/wsjtx.app This got me past the incorrect headers issue, but now it dies because of an OpenMP problem. I’ve placed the VERBOSE build capture here: https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt and the CMakeCache.txt here: https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt Is your OS X 32-bit or 64-bit? https://support.apple.com/en-gb/HT201948 ... 73 Bill G4WJS. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-x build problem on OS X
Steve, I had a look at your output but in cases like this, Bill is the expert. Does seem to be an omp problem. Your compiler picks out the same minor problems in wsprd.c as mine: in readwavfile unsigned long i, j, npoints might better be defined as int i, j, npoints to get rid of compiler warnings. --- John G4KLA -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-x build problem on OS X
Bill, On Jun 29, 2015, at 4:43 PM, Bill Somerville g4...@classdesign.com wrote: On 29/06/2015 22:30, Steven Franke wrote: Bill, Hi Steve, On Jun 29, 2015, at 4:26 PM, Bill Somerville g4...@classdesign.com wrote: On 29/06/2015 22:17, Steven Franke wrote: Bill, On Jun 29, 2015, at 3:57 PM, Bill Somerville g4...@classdesign.com wrote: On 29/06/2015 21:34, Steven Franke wrote: Bill, On Jun 29, 2015, at 9:00 AM, Bill Somerville g4...@classdesign.com wrote: On 28/06/2015 22:08, Steven Franke wrote: Thanks Bill, Hi Steve, For what it’s worth, here a link to the VERBOSE build capture: https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt Here’s the CMakeCache.txt: https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt OK, the problem wasn't quite what I thought. It is an include directive ordering issue but it stems from the use of FFTW3 from MacPorts, this in itself is not an issue but it has the side effect of picking up the Qt4 headers as well. Unfortunately I can't find an easy way of ensuring the -I/opt/local/include is after the includes for Qt5. That would solve the issue but the way that the Qt includes are detected by CMake doesn't seem to have a way to change the ordering. I have posted a question to the CMake ML but for now you should be able to build by deactivating qt4-mac before building WSJT-X. It would be wise to add a '--clean-first' to the CMake build for the first time to ensure any incorrectly built object files are discarded. Something like: $ sudo port deactivate qt4-mac $ cmake --build ~/Builds/wsjtx --clean-first --target install -- -j $ sudo port activate qt4-mac $ open ~/Builds/wsjtx_install/wsjtx.app This got me past the incorrect headers issue, but now it dies because of an OpenMP problem. I’ve placed the VERBOSE build capture here: https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt and the CMakeCache.txt here: https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt Is your OS X 32-bit or 64-bit? https://support.apple.com/en-gb/HT201948 My processor is 64-bit: Hardware Overview: Model Name: MacBook Air Model Identifier:MacBookAir5,2 Processor Name: Intel Core i7 Processor Speed: 2 GHz Number of Processors:1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache:4 MB Memory: 8 GB Boot ROM Version:MBA51.00EF.B02 SMC Version (system):2.5f9 Serial Number (system): C02J401ADRVG Hardware UUID: 1F7ABB4C-7FB0-5918-8AE6-0CA0AB789A89 and I am running the 64-bit kernel: $ uname -a Darwin Stevens-MacBook-Air.local 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64 OK, looks like the MacPorts libgcc is 32-bit only for some reason. What do the following print: $ grep build_arch /opt/local/etc/macports/macports.conf $ grep build_arch /opt/local/etc/macports/macports.conf #build_arch i386 and: $ grep universal /opt/local/etc/macports/macports.conf $ grep universal /opt/local/etc/macports/macports.conf # CPU architectures to use for Universal Binaries (+universal variant) universal_archs x86_64 i386 and: $ file /opt/local/lib/gcc49/libgomp.1.dylib $ file /opt/local/lib/gcc49/libgomp.1.dylib /opt/local/lib/gcc49/libgomp.1.dylib: Mach-O 64-bit dynamically linked shared library x86_64 Hmm, that is all as expected. I think that means the link is picking up another libgomp from somewhere outside of MacPorts. The only other path that seems likely is /usr/local/lib is there an old libgomp there from some prior build of gcc/gfortran? You’re a wizard! That was the problem. Moved the old libraries out of the way and compile completed. Running it now. Thanks!! Also what does: $ nm -gU /opt/local/lib/gcc49/libgomp.1.dylib | grep parallel and just for completeness, and future reference: $ nm -gU /opt/local/lib/gcc49/libgomp.1.dylib | grep parallel 9732 T _GOACC_parallel 32aa T _GOMP_parallel 3240 T _GOMP_parallel_end 256c T _GOMP_parallel_loop_dynamic 24ba T _GOMP_parallel_loop_dynamic_start 2599 T _GOMP_parallel_loop_guided 24d0 T _GOMP_parallel_loop_guided_start 25c6 T _GOMP_parallel_loop_runtime 24e6 T _GOMP_parallel_loop_runtime_start 253f T _GOMP_parallel_loop_static 24a4 T _GOMP_parallel_loop_static_start 3619 T _GOMP_parallel_sections 359d T _GOMP_parallel_sections_start 320e T _GOMP_parallel_start 3432 T _omp_in_parallel 713e T _omp_in_parallel_ Thanks again! Steve k9an print? ... 73 Bill G4WJS. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the
Re: [wsjt-devel] WSJT-X and FT991 CAT issue
On 29/06/2015 22:21, f5djl wrote: Hello to all Bon Soir Jean-Louis Not sure if this report is more relevant to Hamlib or the WSJT team, I am testing a Yaesu FT-991 with WSJT-X release 5636 mainly in WSPR-2 mode : PC : Windows 8.1Intel I7 8GB Memory TRX : Yaesu FT 991 - USB connected Drivers : CP_210X_windows as per Yaesu site Hambib3 Build from G4WJS Public using JTSDK-Mysys (29/06/2015) Issue : CAT not working In setting radio Windows : Rig failure , Hamlib error : feature not available while opening connection to rig . I have tried via command line rigctl an seems to get same issue ! To test with rigctl you must use the rigctl-wsjtx.exe that the WSJT-X produces if you want to compare with the same Hamlib 3 rig drivers. Am I using the correct version of Hamlib3 to build WSJT-X ? is there some further debug information I can provide you to assist with identification of the issue? ( FYI exactly same code work like a charm with an FT897 and an FTDI based interface) The easiest way to eliminate build issues is to try with the official v1.5.0 release, this has essentially the same Hamlib 3 code as the error you are seeing is not mode specific. Congratulations and thanks to all for the great job done in inclusion of wspr mode in wsjt-x, the enhancements to the wspr decoder are just terrific ! J It is good! Congratulations to Steve and Joe. Best regards Jean Louis F5DJL 73 Bill G4WJS. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-x build problem on OS X
On 29/06/2015 22:58, Steven Franke wrote: Bill, Hi Steve, On Jun 29, 2015, at 4:43 PM, Bill Somerville g4...@classdesign.com wrote: On 29/06/2015 22:30, Steven Franke wrote: Bill, Hi Steve, On Jun 29, 2015, at 4:26 PM, Bill Somerville g4...@classdesign.com wrote: On 29/06/2015 22:17, Steven Franke wrote: Bill, On Jun 29, 2015, at 3:57 PM, Bill Somerville g4...@classdesign.com wrote: On 29/06/2015 21:34, Steven Franke wrote: Bill, On Jun 29, 2015, at 9:00 AM, Bill Somerville g4...@classdesign.com wrote: On 28/06/2015 22:08, Steven Franke wrote: Thanks Bill, Hi Steve, For what it’s worth, here a link to the VERBOSE build capture: https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt Here’s the CMakeCache.txt: https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt OK, the problem wasn't quite what I thought. It is an include directive ordering issue but it stems from the use of FFTW3 from MacPorts, this in itself is not an issue but it has the side effect of picking up the Qt4 headers as well. Unfortunately I can't find an easy way of ensuring the -I/opt/local/include is after the includes for Qt5. That would solve the issue but the way that the Qt includes are detected by CMake doesn't seem to have a way to change the ordering. I have posted a question to the CMake ML but for now you should be able to build by deactivating qt4-mac before building WSJT-X. It would be wise to add a '--clean-first' to the CMake build for the first time to ensure any incorrectly built object files are discarded. Something like: $ sudo port deactivate qt4-mac $ cmake --build ~/Builds/wsjtx --clean-first --target install -- -j $ sudo port activate qt4-mac $ open ~/Builds/wsjtx_install/wsjtx.app This got me past the incorrect headers issue, but now it dies because of an OpenMP problem. I’ve placed the VERBOSE build capture here: https://dl.dropboxusercontent.com/u/33211132/k9an_build_capture.txt and the CMakeCache.txt here: https://dl.dropboxusercontent.com/u/33211132/CMakeCache.txt Is your OS X 32-bit or 64-bit? https://support.apple.com/en-gb/HT201948 My processor is 64-bit: Hardware Overview: Model Name:MacBook Air Model Identifier: MacBookAir5,2 Processor Name:Intel Core i7 Processor Speed: 2 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache: 4 MB Memory:8 GB Boot ROM Version: MBA51.00EF.B02 SMC Version (system): 2.5f9 Serial Number (system):C02J401ADRVG Hardware UUID: 1F7ABB4C-7FB0-5918-8AE6-0CA0AB789A89 and I am running the 64-bit kernel: $ uname -a Darwin Stevens-MacBook-Air.local 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64 OK, looks like the MacPorts libgcc is 32-bit only for some reason. What do the following print: $ grep build_arch /opt/local/etc/macports/macports.conf $ grep build_arch /opt/local/etc/macports/macports.conf #build_arch i386 and: $ grep universal /opt/local/etc/macports/macports.conf $ grep universal /opt/local/etc/macports/macports.conf # CPU architectures to use for Universal Binaries (+universal variant) universal_archs x86_64 i386 and: $ file /opt/local/lib/gcc49/libgomp.1.dylib $ file /opt/local/lib/gcc49/libgomp.1.dylib /opt/local/lib/gcc49/libgomp.1.dylib: Mach-O 64-bit dynamically linked shared library x86_64 Hmm, that is all as expected. I think that means the link is picking up another libgomp from somewhere outside of MacPorts. The only other path that seems likely is /usr/local/lib is there an old libgomp there from some prior build of gcc/gfortran? You’re a wizard! That was the problem. Moved the old libraries out of the way and compile completed. Running it now. Thanks!! Good, that was my last guess at a solution. This is related to the liberties we take with OpenMP I mentioned further up this thread. Normally if you use gfortran you would link with the gcc compiler driver or gfortran itself, these know exactly were to get he matching libgcc supporting libraries like libgomp and libgcc_1. Because we have to use the clang++ compiler driver to link since Qt uses that for its C++, we have to manually add the gcc/gfortran support libraries to the link command line. Perhaps I should use the gcc/gfortran compiler/linker driver to discover the correct paths to avoid this kind of issue. It is a PITA that Apple and LLVM don't have a Fortran compiler nor OpenMP support in clang/clang++. ... 73 Bill G4WJS. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today.
Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results
Hi Bill Thanks a lot , I will do a quick test tomorrow but that was my impression too , it seems to fail quite early in the init process . I will be happy to help with testing of driver patch when availaible . Thanks again and best regards JL De : Bill Somerville [mailto:g4...@classdesign.com] Envoyé : mardi 30 juin 2015 01:04 À : wsjt-devel@lists.sourceforge.net Objet : Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results On 29/06/2015 23:51, f5djl wrote: Bill and Michael Bon Soir Jean-Louis, Thanks a lot for your advice and here below is the result of rigctl-wsjtx . OK, looks like the recently added driver for the FT-991 is incomplete. It is falling over when it tries to check if the CAT command it is about to use is valid for the rig. I will get the official version 1.5.0 installed tomorrow to confirm if I get similar results. I think you will get the same result. We will sort out a patch for Hamlib3 to fix this. Very best regards Jean-Louis - F5DJL 73 Bill G4WJS. C:\WSJT\wsjtx\binrigctl-wsjtx - -m135 -scom5 f rigctl, Hamlib 3.0~git Report bugs to mailto:hamlib-develo...@lists.sourceforge.net hamlib-develo...@lists.sourceforge.net rig:rig_init called yaesu: initrigs3_yaesu called rig_register (121) rig_register (127) rig_register (110) rig_register (105) rig_register (106) rig_register (107) rig_register (109) rig_register (120) rig_register (101) rig_register (122) rig_register (123) rig_register (111) rig_register (115) rig_register (113) rig_register (114) rig_register (128) rig_register (131) rig_register (116) rig_register (103) rig_register (124) rig_register (104) rig_register (125) rig_register (129) rig_register (132) rig_register (130) rig_register (117) rig_register (119) rig_register (118) rig_register (126) rig_register (133) rig_register (134) rig_register (135) ft991_init called newcat_init called rig:rig_open called newcat_open called newcat_set_trn called newcat_valid_command called newcat_valid_command: 'FT-991' is unknown rig_open: error = Feature not available C:\WSJT\wsjtx\bin De : Bill Somerville [mailto:g4...@classdesign.com] Envoyé : lundi 29 juin 2015 23:51 À : wsjt-devel@lists.sourceforge.net Objet : Re: [wsjt-devel] WSJT-X and FT991 CAT issue On 29/06/2015 22:21, f5djl wrote: Hello to all Bon Soir Jean-Louis Not sure if this report is more relevant to Hamlib or the WSJT team, I am testing a Yaesu FT-991 with WSJT-X release 5636 mainly in WSPR-2 mode : PC : Windows 8.1Intel I7 8GB Memory TRX : Yaesu FT 991 - USB connected Drivers : CP_210X_windows as per Yaesu site Hambib3 Build from G4WJS Public using JTSDK-Mysys (29/06/2015) Issue : CAT not working In setting radio Windows : Rig failure , Hamlib error : feature not available while opening connection to rig . I have tried via command line rigctl an seems to get same issue ! To test with rigctl you must use the rigctl-wsjtx.exe that the WSJT-X produces if you want to compare with the same Hamlib 3 rig drivers. Am I using the correct version of Hamlib3 to build WSJT-X ? is there some further debug information I can provide you to assist with identification of the issue? ( FYI exactly same code work like a charm with an FT897 and an FTDI based interface) The easiest way to eliminate build issues is to try with the official v1.5.0 release, this has essentially the same Hamlib 3 code as the error you are seeing is not mode specific. Congratulations and thanks to all for the great job done in inclusion of wspr mode in wsjt-x, the enhancements to the wspr decoder are just terrific ! J It is good! Congratulations to Steve and Joe. Best regards Jean Louis F5DJL 73 Bill G4WJS. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RRR bug fixed, WSJT crash on Fedora 21
Hi Alan, This issue seems a bit different for Fedora. I've not specifically checked / monitored RES and VIRT growth on later versions of Debian/Ubuntu, and I'm fairly certain it was only the Horizontal waterfalls causing the crashes. To date, I've not had to work around any other version of PIL other than 2.6.x. Just for completeness, have you built / tried WSPR (python3 version) on Fedora-21? Sorry I can't be more help on this one at the moment. 73's Greg, KI7MT On 06/29/2015 07:26 PM, Alan VK2ZIW wrote: Hi Greg, Not quite resolved yet I did yum remove python3-pillow which removed both: python3-pillow python3-pillow-tk and did pip3 install -I pillow==2.8.2 (2.8.2 is the latest) Still, the same crash in fast modes, JTMS etc.. So, let's try 2.7.0 of pillow pip3 uninstall pillow pip install -I pillow==2.7.0 Sorry, WSJT still crashes. top shows the process grows to RES 1Gb in about 2 mins. So, let's try 2.5.3 of pillow pip3 uninstall pillow pip install -I pillow==2.5.3 Now, WSJT in JTMS mode is much much better. top still shows a slow memory growth (RES and VIRT). == The original Fedora 20 problem === Any mode, as soon as a Waterfall window was drawn, crash. That does not happen. This is a new problem. WSJT does draw waterfalls, both types. Vertical ones gobble memory. 80 Alan VK2ZIW On Mon, 29 Jun 2015 10:25:55 -0600, KI7MT wrote Hi Alan, It appears, Fedora 21 is using python3-pillow 2.6.2 according to RPM find. Pillow 2.6.x has been problematic on several distros I've used / tested. The problems seems to be isolated to those using Pillow v2.6.x ( Debian Jessie, Ubuntu 15.04, etc. ). Distro's using earlier or latter versions of Pillow do not exhibit the same problem. To resolve this on Debian / Ubuntu, I installed the Pillow build dependencies then installed ( compiled ) the latest version of Pillow via Pip3. FWIW, Here's what I used for Jessie / Utopic: * Open a termainl, Ctrl+Alt+T * sudo apt-get update * sudo apt-get install libfreetype6-dev libjpeg-dev liblcms2-dev libtiff5-dev libwebp-dev libwebpmux1 mime-support tcl8.6-dev tk8.6- dev zlib1g-dev * sudo pip3 install --upgrade pillow I'm not entirely sure if the real root cause is Pillow or the combination of Pillow 2.6.x being built against tcl/tk 8.5 or not. But building form Source ( using pip3 ) against tcl/tk-8.6 seems to resolve the horizontal display crashes on Jessie and Utopic. 73's Greg, KI7MT On 6/29/2015 6:14 AM, Alan VK2ZIW wrote: Hi Joe and Bill, I compiled WSJT SVN r5635 on my Ubuntu 14.04 LTS x86_64 box and yes, the fast modes JTMS etc do not crash and do not gobble memory. So, I guess, Fedora 21 uses later Python etc. libraries. Earlier this year, when Fedora 21 first came out for ARMv7 (Pi and clones) I did compile up WSJT, but obviously did not adequately test it. I tested it today and the fast modes crash in the same way as the Intel architecture. As I see it, Fedora is THE Red Hat linux flavour. They (Fedora) put a LOT of work into the ARM platform. This allows ultra low power apps for balloons etc.. And, of course, remote sites on solar power. As far as I know, you access to my ARM box here has not changed. You have GUI via RDP. User: wsjtdev Keep Smiling Alan VK2ZIW On Sun, 28 Jun 2015 09:31:40 -0400, Joe Taylor wrote Hi Alan, On 6/28/2015 3:10 AM, Alan VK2ZIW wrote: WSJT compiled from SVN r5635 crashes in modes JTMS, FSK441, ISCAT-A and ISCAT-B. But, is fine on all JT65 and JT4 modes. Crash is a memory leak and, when RES memory (top) runs out, crash. Takes 10 mins or less. Obvious with top system monitor. System: Fedora 21 x86_64 on ASRock QC5000-ITX motherboard. (all standard dev tools) I don't presently have a Fedora-based machine. Under Windows and Ubuntu Linux I see no such bad behavior. All WSJT modes run as expected, over long times and with no evident memory leaks. Perhaps you can make some tests to isolate the code leading to a memory leak on your system. I note that your problem is with the WSJT fast modes -- those for which the waterfall scrolls horizontally. That might be a good place to start your search. Also, idWarn in wsjt.py is not defined. Is this causing a problem for you? As far as I am aware the functions using this variable perform as expected. -- 73, Joe, K1jT -- Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical virtual servers, alerts via email sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net
Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results
Michael Thanks a lot , I will apply the patch and recompile tonight . I will let you know the outcome . Have a nice day and 73 . Jean Louis -Message d'origine- De : Michael Black [mailto:mdblac...@gmail.com] Envoyé : mardi 30 juin 2015 06:14 À : wsjt-devel@lists.sourceforge.net Objet : Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results I think (i.e. hope) the attached fixes the problem. 73 Mike W9MDB -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RRR bug fixed, WSJT crash on Fedora 21
Hi Greg, WSPR, yes, is running fine, though, it's memory use (top) is growing slowly. RES started at 60,000 and after 1/2 hour is up to 111,000. VIRT is how 787,836, up from the 616,664 at startup. My issue reported a year ago was this slow growth 'killing' it's use on small memory systems such as the Banana Pi. Flying a full PC on a balloon is, out of the question. But, a Pi? 80 Alan VK2ZIW On Mon, 29 Jun 2015 19:48:26 -0600, KI7MT wrote Hi Alan, This issue seems a bit different for Fedora. I've not specifically checked / monitored RES and VIRT growth on later versions of Debian/Ubuntu, and I'm fairly certain it was only the Horizontal waterfalls causing the crashes. To date, I've not had to work around any other version of PIL other than 2.6.x. Just for completeness, have you built / tried WSPR (python3 version) on Fedora-21? Sorry I can't be more help on this one at the moment. 73's Greg, KI7MT On 06/29/2015 07:26 PM, Alan VK2ZIW wrote: Hi Greg, Not quite resolved yet I did yum remove python3-pillow which removed both: python3-pillow python3-pillow-tk and did pip3 install -I pillow==2.8.2 (2.8.2 is the latest) Still, the same crash in fast modes, JTMS etc.. So, let's try 2.7.0 of pillow pip3 uninstall pillow pip install -I pillow==2.7.0 Sorry, WSJT still crashes. top shows the process grows to RES 1Gb in about 2 mins. So, let's try 2.5.3 of pillow pip3 uninstall pillow pip install -I pillow==2.5.3 Now, WSJT in JTMS mode is much much better. top still shows a slow memory growth (RES and VIRT). == The original Fedora 20 problem === Any mode, as soon as a Waterfall window was drawn, crash. That does not happen. This is a new problem. WSJT does draw waterfalls, both types. Vertical ones gobble memory. 80 Alan VK2ZIW On Mon, 29 Jun 2015 10:25:55 -0600, KI7MT wrote Hi Alan, It appears, Fedora 21 is using python3-pillow 2.6.2 according to RPM find. Pillow 2.6.x has been problematic on several distros I've used / tested. The problems seems to be isolated to those using Pillow v2.6.x ( Debian Jessie, Ubuntu 15.04, etc. ). Distro's using earlier or latter versions of Pillow do not exhibit the same problem. To resolve this on Debian / Ubuntu, I installed the Pillow build dependencies then installed ( compiled ) the latest version of Pillow via Pip3. FWIW, Here's what I used for Jessie / Utopic: * Open a termainl, Ctrl+Alt+T * sudo apt-get update * sudo apt-get install libfreetype6-dev libjpeg-dev liblcms2-dev libtiff5-dev libwebp-dev libwebpmux1 mime-support tcl8.6-dev tk8.6- dev zlib1g-dev * sudo pip3 install --upgrade pillow I'm not entirely sure if the real root cause is Pillow or the combination of Pillow 2.6.x being built against tcl/tk 8.5 or not. But building form Source ( using pip3 ) against tcl/tk-8.6 seems to resolve the horizontal display crashes on Jessie and Utopic. 73's Greg, KI7MT On 6/29/2015 6:14 AM, Alan VK2ZIW wrote: Hi Joe and Bill, I compiled WSJT SVN r5635 on my Ubuntu 14.04 LTS x86_64 box and yes, the fast modes JTMS etc do not crash and do not gobble memory. So, I guess, Fedora 21 uses later Python etc. libraries. Earlier this year, when Fedora 21 first came out for ARMv7 (Pi and clones) I did compile up WSJT, but obviously did not adequately test it. I tested it today and the fast modes crash in the same way as the Intel architecture. As I see it, Fedora is THE Red Hat linux flavour. They (Fedora) put a LOT of work into the ARM platform. This allows ultra low power apps for balloons etc.. And, of course, remote sites on solar power. As far as I know, you access to my ARM box here has not changed. You have GUI via RDP. User: wsjtdev Keep Smiling Alan VK2ZIW On Sun, 28 Jun 2015 09:31:40 -0400, Joe Taylor wrote Hi Alan, On 6/28/2015 3:10 AM, Alan VK2ZIW wrote: WSJT compiled from SVN r5635 crashes in modes JTMS, FSK441, ISCAT-A and ISCAT-B. But, is fine on all JT65 and JT4 modes. Crash is a memory leak and, when RES memory (top) runs out, crash. Takes 10 mins or less. Obvious with top system monitor. System: Fedora 21 x86_64 on ASRock QC5000-ITX motherboard. (all standard dev tools) I don't presently have a Fedora-based machine. Under Windows and Ubuntu Linux I see no such bad behavior. All WSJT modes run as expected, over long times and with no evident memory leaks. Perhaps you can make some tests to isolate the code leading to a memory leak on your system. I note that your problem is with the WSJT fast modes -- those for which the waterfall scrolls horizontally. That might be a good place to start your search. Also, idWarn in wsjt.py is not defined. Is this causing a problem for you? As far as I am aware the functions using this variable perform as
Re: [wsjt-devel] WSJT-X and FT991 CAT issue - rigctl-wsjtx results
I think (i.e. hope) the attached fixes the problem. 73 Mike W9MDB yaesu_newcat.patch Description: Binary data -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
