Re: [wsjt-devel] wsjtx-2.6.0-rc2
On 7/24/22 03:29, jarmo via wsjt-devel wrote: I read a note by Saku here on this list regarding differences among the source availables in Github and in the Website. The git repo at https://git.code.sf.net/p/wsjt/wsjtx seems to be still at rc1. And I used that, that's why I asked, why my update showed RC1. Compiled from TGZ, now shows RC2.. Please make rc2 available on https://git.code.sf.net/p/wsjt/wsjtx too. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx-2.6.0-rc2
On 7/23/22 18:04, Marco Calistri via wsjt-devel wrote: I read a note by Saku here on this list regarding differences among the source availables in Github and in the Website. The git repo at https://git.code.sf.net/p/wsjt/wsjtx seems to be still at rc1. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] SUGGESTION
On 3/6/22 10:28, Charles Suckling via wsjt-devel wrote: Hi Charly & all, I personally find it useful to be able to generate a continuous carrier with WSJT-X using the Tune button. I share this opinion, it's an important feature because many XCVR's do not offer this function in a simple manner. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJTX and QT don't list IC-7300 audio devices
On 12/29/21 4:29 PM, jeff millar wrote: Hi Jeff and all, $ pactl list | grep Name | grep Burr Name: alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo Name: alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo.monitor Name: alsa_input.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00.analog-stereo Name: alsa_card.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00 The question is, Why can't WSJTX see the same thing? As Bill has explained, WSJTX simply uses the enumeration made available at the Qt5 interface. Ensure that you select the right port on pavucontrol and not the ports related to the PC internal soundcard. Verify that the ports are not muted. Verify that the IC-7300 is configured to use the soundcard and not the analogue ports. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJTX and QT don't list IC-7300 audio devices
On 12/28/21 8:11 PM, jeff millar via wsjt-devel wrote: Hi Jeff and all, The problem is that File/Settings/Audio Input and Output no longer list the IC-7300 audio devices. They should be Burr-Brown_from_TI_USB_Audio_CODEC. but they are not in the list. This happened once before a few months back and I don't know how it fixed itself. You will probably see the right interface like on the picture in the attachment. Remember: WSJT-X uses in sequence Qt5, then pulseaudio, then alsa. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.5.3 GA Release (Win64 only)
On 12/14/21 3:09 PM, Joe Taylor wrote: Hi Joe and all, It seems likely that you need to do a --clean-first, to ensure that the packjt77 module is compiled before save_dxbase. After "make clean" and "make", the compilation has run up to the end without errors, but with the usual warnings. Many thanks Joe ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] hamlib repo at git.code.sf.net/u/bsomervi/hamlib
Hi all, What is about the future maintenance of the special hamlib at git.code.sf.net/u/bsomervi/hamlib ? Best whishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.5.3 GA Release (Win64 only)
On 12/8/21 7:25 PM, Joe Taylor via wsjt-devel wrote: Hi, I have tried to build on 64 bit Debian Buster using the repo. This was not successful and ended in this manner: [ 21%] Building Fortran object CMakeFiles/wsjt_fort_omp.dir/lib/ft4/ft4sim_mult.f90.o [ 21%] Building Fortran object CMakeFiles/wsjt_fort_omp.dir/lib/77bit/my_hash.f90.o [ 21%] Building Fortran object CMakeFiles/wsjt_fort_omp.dir/lib/qra/q65/q65_loops.f90.o [ 21%] Building Fortran object CMakeFiles/wsjt_fort_omp.dir/lib/save_dxbase.f90.o /home/claude/ham/JoeTaylor/wsjtx/lib/save_dxbase.f90:6:9: dxbase=dxbase0 1 Error: Can't convert CHARACTER(1) to REAL(4) at (1) make[2]: *** [CMakeFiles/wsjt_fort_omp.dir/build.make:2559: CMakeFiles/wsjt_fort_omp.dir/lib/save_dxbase.f90.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:859: CMakeFiles/wsjt_fort_omp.dir/all] Error 2 make: *** [Makefile:152: all] Error 2 Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] hamlib rigctld and the --vfo argument
Hi Mike, Bill and all, My question is related to the cooperation between a rigctld daemon and multiple clients, especially in relation with the "--vfo" argument. When the rigctld daemon is started with the "--vfo" argument, can clients communicate with it ONLY when they use the "--vfo" argument themself ? When the rigctld daemon is started without the "--vfo" argument, can clients communicate with it even if they use the "--vfo" argument ? What is the arguments to use with rigctld when some clients want to connect, the ones with, the other without the "--vfo" argument set ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Back on the usage of Ref.Spec. for Linux systems
On 10/20/21 1:09 PM, Kari Sillanmäki via wsjt-devel wrote: I'm also using XFCE4 desktop but I get no errors when using refspec.dat. So I believe XFCE is not the problem. The same observation here. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Wsjtx crash
On 10/17/21 6:32 AM, jarmo via wsjt-devel wrote: Hi Jarmo & all, Where this core-file is created, can't find it? On Fedora, probably under /var/spool/abrt, in the problem directories. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Question, FT8
On 10/4/21 1:17 AM, Allan Downie via wsjt-devel wrote: Hi Allen, Bill & all, Technically the return 73 is not required for a valid QSO, however it is the polite thing to do. At the very least if confirms to your operating partner that all was received. I would like to at least see it as an operator option. I support this request. Best wishes, Claude ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Some minor issues.
On 10/1/21 12:38 AM, Marco Calistri via wsjt-devel wrote: Hi Bill, Marco & all, Probably when I set Data/Pkt my radio transmit on a little shifted frequency out of the center of the standard transmission FT8 frequency and this unallow my signal to be heard. I have no experience with the FT-100, but with the FT-2000. There the menu setting "072dATa PKTDISP" (Packet mode frequency display offset) is the important one here. I have used the same value of 1000 as set on "073dATa PKT SFT" (Packet mode carrier point frequency). The factory default is different. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Some minor issues.
On 9/30/21 5:01 AM, jarmo via wsjt-devel wrote: Hi Jarmo & all, I think, it has nothing to do with souncard. Both radios are connected directly via USB so wsjtx uses audio codec as input and output. These rigs may have different USB interfaces and different sound chips, so that they appear as different items in pavucontrol. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Some minor issues.
On 9/30/21 6:19 AM, Marco Calistri via wsjt-devel wrote: Hi Marco & all, 2) _*AFSK is being regularly produced by WSJT-X through the computer sound card*_, then I guess that there is a sort of "*/software muting/*" of this signal which is blocked in some way to feed the rear data connector of my YAESU FT-100 which in turn doesn't transmit any RF. May be if I would attach the AFSK output directly to the radio mic plug, then the RF transmission would be possible. Please verify the settings in "pavucontrol" which is part of pulseaudio. Verify that you have selected the right source, sink and that no one of them is muted. Verify that pavucontrol shows a signal on the selected items. In WSJT-X, verify that you have selected the appropriate "sound card". If you use an USB connected "sound card", you will see a least 2 cards, because there is probably an internal soundcard in the computer. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Some minor issues.
On 9/29/21 5:58 PM, jarmo via wsjt-devel wrote: Hi Marco, Jarmo and all, Unfortunately not working. Compiled hamlib-4.4~git-dd1376be-20210929.tar.gz and same behaviour. If try to use NetHamlib rictl, audio does not go into radio. CAT is not related to Audio. Cat control works ok. This is fine. hamlib does the job. But if chosen Kenwood ts-590SG in WSJTX radio preferences, audio works ok... Please debug the audio matter. My suggestion, at first: aplay -l aplay -L arecord -l arecord -L pactl list Please examine the output. As mentioned previously, if the "sound card" is connected via USB, verify that gpsd (or another program) doesn't grasp the "sound card". The output of dmesg can help. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.5.0-rc6 and MAP65 3.0-rc6 EOL for Ubuntu 18.04?
On 9/7/21 2:05 PM, Black Michael via wsjt-devel wrote: Hi Mike and all, USB is one of those technologies that doesn't stand still. Can't help it if package maintainers are 1.5 years behind the curve. The maintenance managers of the distributions have own rules to appreciate the stability of package releases. I confess that this is an obscure matter for me. I simply can't guarantee future compatibility but will try to maintain it. These new releases will probably be be included in the distributions later or they will be replaced by better releases. That's why I put in the testlibusb.c program to catch this type of thing before it's mandatory and before I implement some things under libusb. Many thanks, Mike. I appreciate this initiative. Hamlib has already been patched to allow this to compile now. Fine ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.5.0-rc6 and MAP65 3.0-rc6 EOL for Ubuntu 18.04?
On 9/7/21 12:36 PM, Kari Sillanmäki via wsjt-devel wrote: Hi Kari, Bill and all, I tried to compile WSJT-X 2.5.0-rc6 on XUbuntu 18.04.5 LTS but got an error: function); did you mean ‘LIBUSB_SPEED_SUPER’? case LIBUSB_SPEED_SUPER_PLUS: speed = "10G"; break; ^~~ LIBUSB_SPEED_SUPER /tests/testlibusb.c:343:2: warning: #warning LIBUSB-1.0.23 will be required in Hamlib > 4.3 [-Wcpp] #warning LIBUSB-1.0.23 will be required in Hamlib > 4.3 In my opinion, the hamlib code should be changed in order to accept libusb in older 1.0 releases, while avoiding to include the additional functionalities provided by 1.0.23. As I can see, many recent distributions have libusb < 1.0.23. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 2.5.0rc5 and FT4 PTT
On 8/27/21 10:06 AM, Saku via wsjt-devel wrote:
Hi Saku & all,
I have noticed a similar problem when using a GPS mouse as time source
for ntpd. The source of the problem is gpsd, especially when using the
"-n" command line flag, which is necessary here, although this
information is not included in the man page.
The solution was to set the "gpsd.service" as disabled with systemctl:
systemctl disable gpsd.service
At next, I have inserted the following line in
/etc/udev/rules.d/99-hamlib.rules:
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60",
ATTRS{serial}=="IC-7300 [0-9]*", TEST!="/dev/rigA", SYMLINK+="rigA"
Now, the IC-7300 appears as /dev/rigA. This was necessary because the
GPS mouse includes the same chip.
Finally, I have created a file "/etc/modprobe.d/my-local.conf" with:
alias pps-ldisc /dev/null
alias tty-ldisc-18 /dev/null
in order to avoid that gpsd try to use any tty device as PPS device.
When beginning, I plug in the XCVR and the GPS mouse on the USB sockets.
Then I start rigctld on /dev/rigA. Then gpsd "systemctl start
gpsd.service". I verify that gpsd is receiving data from the mouse
"gpsmon". After some delay, I verify that ntpd is using the signal from
gpsd via the shared memory: "ntpq -4p 127.0.0.1". Then I can start wsjtx.
Perhaps you have a similar interference with gpsd.
Best wishes,
Claude (DJ0OT)
Now during few days I have noticed that calling cq with FT4 causes PTT
to stay on during RX period. Nearly to end of it. Then small RX gap and
TX starts again to next TX period (at proper time).
This happens at random times after started CQ calling.
When this starts to happen it may also cause error that rig is not
responding. But not always. On other times it may just blink once the
"green dot" besides band selector to yellow and back to green.
After some time of calling cq with these problems TX enable drops away,
no errors, and no receiving any more. Waterfall stays blank while
stations can be heard from speaker I.E. there is traffic.
Stopping and starting WSJTx does not help for long. If PTT problem has
happened it soon continues after program restart. Rebooting PC helps and
gives longer time until the PTT again stays on.
This does not happen with FT8.
It is a random problem, and so hard to reproduce but has happened now
daily when I have started to use FT4 again with these versions of WSJTX
and Hamlib.
I may also be a rigctld problem, it is not the very latest from Git.
Anyway it causes WSJTX to be unstable.
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Idea for "frequency hopping" FT8 to reduce collisions
Hi all, These references are interesting, but we have to remember that we are speaking about HF communication on short-wave bands, in half duplex mode. None of the actors (the stations on the band) has a full knowledge of the whole situation of the communication channel in use. Each station has only knowledge about the stations it can see on its own receiver during the receiving slots. This is not a global view. Further, the situation is continuously changing because of the changing propagation conditions. In this context, with this limited information, it is very difficult to find the good choice in a global sense. PSKreporter is the tool which has a better global overview, but its use is not mandatory, not always possible and PSKreporter displays a view of the past because of the technology used. In the context of continuously changing propagation, this information is of limited usefulness. When my partner station cannot copy me well, it makes sense to try to use another TX frequency which seems to be free according to my own RX. Perhaps, this can help, but it's not sure. If cannot see what the RX of my partner displays. I cannot verify if my decision was good. If the situation persists, I can just try another TX frequency again. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.5.0-rc4 and MAP65 3.0-rc5
On 8/5/21 3:40 PM, Joe Taylor via wsjt-devel wrote: WSJT-X 2.5.0-rc4 has a bug that prevents normal use of messages that include compound or nonstandard callsigns. For this reason we are making a public Release Candidate WSJT-X 2.5.0-rc5 after an unusually short interval. The RC5 release candidate is now ready for download by beta testers. On Windows the installation package also includes MAP65 3.0.0-rc5. Thanks Joe ! Up to now, the rc5 is not available on the git repo. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] My problems while compiling from the source
On 7/17/21 10:02 PM, Kari Sillanmäki via wsjt-devel wrote: Hi Kari, Bill, Adrian and all, This may not comfort you much, but just for fun and giggles I installed Debian Buster onto a virtual machine and then cloned Hamlib and WSJT-X from git. Compiled, and got a working WSJT-X. So *something* may not be right in your system. I have no idea what that could be though, sorry. You are right, numerous problems are open after the migration from 32 bit Fedora to 64 bit Debian. The hardest one is sendmail, which is really different. In the build directory, I have tried to delete CMakeCache.txt and I have run cmake again. Strange error messages from cmake appeared. Then, I have deleted all the files and directories in the build directory and I have run cmake again. No error messages. Then make and the compilation ended without errors. Now, I will have to test the executable. Many thanks to you all ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] My problems while compiling from the source
Hi Bill and all, I'm trying to compile from the source from the git repo: I'm here: commit 7eac85560823e9c53ae5ed876861f73a1258c717 (HEAD -> master, tag: wsjtx-2.5.0-rc3, origin/master, origin/HEAD) Merge: df3da69d2 522f698c6 Author: Bill Somerville Date: Mon Jul 5 20:58:15 2021 +0100 Merge branch 'release-2.5.0' commit 522f698c6300613532dd470f6de5f9c9ca986fbf Author: Bill Somerville Date: Mon Jul 5 20:48:05 2021 +0100 Release note updates commit f067d9472397539e9e1b9247a1d8155e7c768201 Merge: a141b5af3 bada2dd82 Author: Bill Somerville Date: Mon Jul 5 20:43:42 2021 +0100 Merge branch 'release-2.5.0' of bitbucket.org:k1jt/wsjtx into release-2.5.0 ### The compilation ended here: Scanning dependencies of target message_aggregator [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/UDPExamples/MessageAggregator.cpp.o [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/UDPExamples/MessageAggregatorMainWindow.cpp.o [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/UDPExamples/DecodesModel.cpp.o [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/UDPExamples/BeaconsModel.cpp.o [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/UDPExamples/ClientWidget.cpp.o [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/validators/MaidenheadLocatorValidator.cpp.o [ 12%] Building CXX object CMakeFiles/message_aggregator.dir/qrc_message_aggregator.cpp.o [ 12%] Building CXX object CMakeFiles/message_aggregator.dir/qrc_style.cpp.o [ 12%] Building CXX object CMakeFiles/message_aggregator.dir/message_aggregator_autogen/mocs_compilation.cpp.o [ 12%] Linking CXX executable message_aggregator /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_lsetregs' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_pdread' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_lsetfpregs' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_getpid' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_pdwrite' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_lgetregs' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_lgetfpregs' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_pglobal_lookup' collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/message_aggregator.dir/build.make:273: message_aggregator] Error 1 make[1]: *** [CMakeFiles/Makefile2:140: CMakeFiles/message_aggregator.dir/all] Error 2 make: *** [Makefile:152: all] Error 2 ### What is missing or wrong ? The system: Linux defi 4.19.0-17-amd64 #1 SMP Debian 4.19.194-2 (2021-06-21) x86_64 GNU/Linux Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] My problems while compiling from the source
Hi Bill and all, I'm trying to compile from the source from the git repo: I'm here: commit 7eac85560823e9c53ae5ed876861f73a1258c717 (HEAD -> master, tag: wsjtx-2.5.0-rc3, origin/master, origin/HEAD) Merge: df3da69d2 522f698c6 Author: Bill Somerville Date: Mon Jul 5 20:58:15 2021 +0100 Merge branch 'release-2.5.0' commit 522f698c6300613532dd470f6de5f9c9ca986fbf Author: Bill Somerville Date: Mon Jul 5 20:48:05 2021 +0100 Release note updates commit f067d9472397539e9e1b9247a1d8155e7c768201 Merge: a141b5af3 bada2dd82 Author: Bill Somerville Date: Mon Jul 5 20:43:42 2021 +0100 Merge branch 'release-2.5.0' of bitbucket.org:k1jt/wsjtx into release-2.5.0 ### The compilation ended here: Scanning dependencies of target message_aggregator [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/UDPExamples/MessageAggregator.cpp.o [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/UDPExamples/MessageAggregatorMainWindow.cpp.o [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/UDPExamples/DecodesModel.cpp.o [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/UDPExamples/BeaconsModel.cpp.o [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/UDPExamples/ClientWidget.cpp.o [ 11%] Building CXX object CMakeFiles/message_aggregator.dir/validators/MaidenheadLocatorValidator.cpp.o [ 12%] Building CXX object CMakeFiles/message_aggregator.dir/qrc_message_aggregator.cpp.o [ 12%] Building CXX object CMakeFiles/message_aggregator.dir/qrc_style.cpp.o [ 12%] Building CXX object CMakeFiles/message_aggregator.dir/message_aggregator_autogen/mocs_compilation.cpp.o [ 12%] Linking CXX executable message_aggregator /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_lsetregs' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_pdread' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_lsetfpregs' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_getpid' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_pdwrite' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_lgetregs' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_lgetfpregs' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libthread_db.so: undefined reference to `ps_pglobal_lookup' collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/message_aggregator.dir/build.make:273: message_aggregator] Error 1 make[1]: *** [CMakeFiles/Makefile2:140: CMakeFiles/message_aggregator.dir/all] Error 2 make: *** [Makefile:152: all] Error 2 ### What is missing or wrong ? The system: Linux defi 4.19.0-17-amd64 #1 SMP Debian 4.19.194-2 (2021-06-21) x86_64 GNU/Linux Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Message Bit to Request Other Station to QSY to your Frequency
On 7/9/21 7:59 PM, Joe Taylor wrote: Hi Joe and all, But I agree that larger FT8 sub-bands (or multiple sub-bands on a given HF band) are really what is required to relieve congestion. The current bandplans are often unrealistic. The CW only part is often by far too large. See the 2200 m band or the 30 m band as examples. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Message Bit to Request Other Station to QSY to your Frequency
On 7/8/21 9:40 AM, Reino Talarmo wrote: Hi Reino & all, Saku's proposal does exactly the same without any modification of the code or the protocol. If the partner station refuses deliberately to change its frequency or if (s)he cannot copy the QSY free style message, you can only continue to repeat in the protocol sequence. Please remember that what you see on the waterfall of your monitor, can be very different from that what your partner station sees on his/her monitor. This is especially important to remember because your signal can be scrambled by another station, which you cannot see on your own monitor. It can be very helpful to try to change your own frequency if you see that your partner cannot copy your signal. Best wishes, Claude (DJ0OT) There are so many times on FT8 or FT4 that the station you are in QSO with is buried in QRM by a signal they probably don't even know is on their audio frequency. On future releases of FT4 or FT8, if there is ever a spare bit in the message formats, I propose adding a "please QSY to my tx audio frequency" bit. There would be a "Pse QSY: button on the user interface that would be off by default. There would be an indicator to the other op that a QSY is requested, and it is up to them whether or not to hit the up arrow button to sync TX frequencies. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Call for information about PC systems being used for WSJT-X
On 6/9/21 1:38 AM, Bill Somerville wrote: Hi Bill and all, The technology we will use is called AVX and that is present on all Intel CPUs branded Core i3/i5/i7/i9 (circa 2010 to present), it is also present on AMD CPUs since the Jaguar or Puma based CPU models (some late Athlon-II CPUs, all Zen based CPUs, including Ryzen) circa 2013 to present. None of the computers I'm using to run WSJT-X has the AVX extensions. In my opinion, the planed performance enhancements with AVX should be optional and not mandatory. Perhaps a compile time option. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Settings Split operation: Rig vs. Fake It
Hi all, If I understand well, the "Rig" setting uses 2 VFO's which are set to different frequencies, if necessary and the "Fake It" setting uses only one VFO which frequency is changed if necessary. My observation is that some rigs, having more than one VFO, have the ability to be used with the "Rig" and the "Fake It" settings, but the switching time is very different. Often, when using "Rig", the switching time becomes larger, even too large or, at least, marginal. This behaviour has been observed with the ICOM IC-725 and the Yaesu FT-2000. How often does my observation apply to other rigs ? Is this difference in the switching time only related to the rig itself or are there additional reasons ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WST4W-300 2.4.0-rc4
On 5/8/21 12:05 PM, Bill Somerville wrote: Hi Bill and all, the TOT parameter that caused this issue is specific to the rig being used and controlled by the rig. Although WSJT-X may be able to query this parameter on this particular rig I hope you realize that doing so would be a waste of development resources that would only benefit a very small subset of users. I'm sorry, it was my misunderstanding. I ignored that it's a rig specific value that is concerned here. Sorry ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WST4W-300 2.4.0-rc4
On 5/7/21 7:55 PM, Thomas Mills wrote: Thanks Gary you were correct. TOT set for 3 minutes, I never thought about that!Problem solved! Hi Tom, Bill and all, I suggest to the developers to introduce a pop-up window which will appear when the mode is changed in a manner which is not compatible with the current timeout setting. This window can then offer to… - do nothing - change the timeout to an reasonable value, compatible with the new selected mode. I suggest to populate the entry field for the new proposed value of the timeout with a reasonable value which the operator can change or accept as is. Best regards, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FST4 submodes
On 4/19/21 10:01 PM, Joe Taylor wrote: Hi Joe and all, Look at the current Guide. FST4 and FST4W have no submodes with larger tone spacings. In the sample directory, there are two "wav" files. The one is 1 minute long and the other one is 30 minutes long. What is their mode ? FST4 or FST4W ? Which are the settings necessary to decode these samples ? How many signals should be decodes well, using these two samples ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFO's and sub-VFO's
On 4/6/21 1:29 PM, Black Michael via wsjt-devel wrote: get_vfo_info -- single call to retrieve freq mode width and split status for any VFO -- come to think of it should probably add satmode status too.Rig command: \get_vfo_info VFOAFreq: 14500Mode: FMWidth: 15000Split: 0 If I understand well, the "SAT mode" is simply the "full duplex" mode, having a VFO assigned to the TX and another one to the RX. Right ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] VFO's and sub-VFO's
On 4/4/21 3:18 PM, Black Michael via wsjt-devel wrote: Hi Mike and all, You find "VFOs.txt" in the main hamlib directory that tries to describe the abstraction.The differences are rig-dependent along with rig mode. It was exactly the contents of this file which has triggered my question. Life isn't simple:-) Oh yes ! You are right. But my question remains open: What is the difference between a VFOx and a subVFO ? Is it simply a matter of definition or is there a difference in the function too ? Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] VFO's and sub-VFO's
Hi all, Please explain me: What is the difference between VFO-A, VFO-B, VFO-C, etc. and the subVFO's. Thanks ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] F/H reply frequency shift
On 3/19/21 5:10 PM, Bill Barrett wrote: Hi Bill and all, Was transferred to 441 to reply to A25RU but after one transmit segment the app shifted me to 741. Looks like a busted Q. Is there a reason the app shifted to 741? According to the picture, you are using the DXpedition mode. Therefore it's normal, in my opinion. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] lotw-user-activity.csv file
Hi Bill and all, I have this file stored locally here because it's used for different tasks. I have tried to insert an URL beginning with "file://" in the field "Users CSV file URL" in Settings --> Colors. This did not worked well, although no error message has been generated. I have returned to the default value. Then, I have created a symbolic link from the locally stored file to ~/.local/share/WSJT-X/lotw-user-activity.csv. This has only worked well after I have clicked "Fetch now", but a new fetch was not necessary because the contents was already up to date. Was is the recommanded way here ? A further question: What is the line ending character or character sequence in the lotw-user-activity.csv file when stored locally ? Is this OS dependant ? Thanks a lot ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Additional Problem with Mac Version WSJT-X v2.4.0-rc2
On 3/9/21 4:45 PM, John Stengrevics wrote: Hi John, I have never had this problem previously. And, it appeared only when I downloaded v2.4.0-rc2 several days ago. I suspect it is a problem specific to Macs (my operating system is Big Sur 11.2.2). If I remember well, the problem has been reported in relation with various releases, various OS', various modes. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Additional Problem with Mac Version WSJT-X v2.4.0-rc2
On 3/9/21 3:23 PM, John Stengrevics wrote: Hi John and all, I reported a problem with the Mac version some days ago while operating Q65. The PTT continued to key the amplifier but with no audio output. Erratic missing audio output has been reported here by some users, since a long time yet. I cannot remember that a solution or a fix have been mentioned. I ignore what the reason of such silent cycles is. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Release candidate: WSJT-X 2.4.0-rc2
On 3/6/21 5:28 PM, Charles Suckling wrote: Hi Charles and all, I just built it here. What differences do you see? I started my investigation at the time as I have got an error message while trying to build the user manual using asciidoctor-pdf. The message says that the image file ./doc/user_guide/en/images/Q65_6m_ionoscatter.png is missing. I have tried to get this file using git in order be in synchronisation with the repo. This file was not on the repo. Then I have examinated the user guide on… https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.4.0-rc2.html. I was looking to the place where this missing file should be inserted on. On the document from the www.physics.princeton.edu site, there is an image at this place, but it's related to 2m, not to 6m. Therefore, it's not the same image. Further, I have found, that the text just above the image is different. My conclusion was that the two documents are different. Joe has just confirmed my observation in his previous message. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Release candidate: WSJT-X 2.4.0-rc2
On 3/6/21 5:25 PM, Joe Taylor wrote: Hi Joe and all, For any reason unknown to me, the doc generated from ./doc/user_guide/en/ is different from the doc found here: https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.4.0-rc2.html There is not only this image missing, there are other differences too. Anybody knows why ? At any time the version of WSJT-X User Guide posted on the WSJT web site may be more recent than one built from the published source code tarball. This is especially true during a Release Candidate phase, when new text and corrections are being added. Many thanks for this information, which was not known to me previously. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Release candidate: WSJT-X 2.4.0-rc2
On 3/6/21 9:06 AM, Claude Frantz wrote: Hi, I cannot find the file ./doc/user_guide/en/images/Q65_6m_ionoscatter.png in the source code from the repo. It's needed to build the doc. For any reason unknown to me, the doc generated from ./doc/user_guide/en/ is different from the doc found here: https://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.4.0-rc2.html There is not only this image missing, there are other differences too. Anybody knows why ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Release candidate: WSJT-X 2.4.0-rc2
On 3/6/21 10:59 AM, Reino Talarmo wrote: Hi Reino and all, Simply said WSJT-X logs Q65 QSOs, but in future it would change logging format. OK, but when WSJT-X is logging an ADIF record, which MODE and SUBMODE is inserted in this record, at the present time ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Release candidate: WSJT-X 2.4.0-rc2
On 3/5/21 2:54 PM, Joe Taylor wrote: We are pleased to announce release candidate WSJT-X 2.4.0-rc2, which includes the new digital mode Q65. Hi Bill and all, I cannot find the file ./doc/user_guide/en/images/Q65_6m_ionoscatter.png in the source code from the repo. It's needed to build the doc. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Release candidate: WSJT-X 2.4.0-rc2
On 3/6/21 2:07 AM, Neil Zampella wrote: Hi Neil, Reino and all, I wouldn't go there yet. The ADIF committee has not yet met to add this mode to the ADIF standard. Is WSJT-X unable to log Q65 QSO's ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Release candidate: WSJT-X 2.4.0-rc2
On 3/5/21 2:54 PM, Joe Taylor wrote: Q65 is designed for two-way QSOs over especially difficult propagation paths such as ionospheric scatter, troposcatter, rain scatter, TEP, EME, and other types fast-fading signals. Details and recommendations concerning the Q65 submodes are provided in the "Quick-Start Guide to Q65", available here: https://physics.princeton.edu/pulsar/k1jt/Q65_Quick_Start.pdf Hi all, When logging a Q65 QSO, which mode and submode are set in the ADIF log ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] clock offset / fudge adjustment, automatic/manual
On 3/4/21 11:43 AM, Alan wrote: In my experience portable operation does indeed have a problem with drifting clocks due to temperature variations, and particularly wind. Internet connectivity may well be unavailable, so I've bought a cheap GPS dongle that does the job just fine. A good idea ! Averaging received time differentials to provide a correction is an interesting thought though, but in my view providing that was done only inside WSJT-X and only for the current session - no changes to the system clock itself, or permanent config changes. If you are using a GPS dongle, in portable operation, you have solved the problem as long as you have a sufficient sight to the satellites. When using ntpd or chrony, you have the opportunity to use multiple time signal sources. Use some sources in the Internet and your GPS dongle and you will be able to set the needed parameters related to the USB dongle. When the Internet connection will not more be available, in portable operation, you have the right parameters set for your USB dongle. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] clock offset / fudge adjustment, automatic/manual
On 3/4/21 1:53 AM, David Smith wrote: Proposal: Add an adjustment that allows you to manually adjust an offset to the system clock. Being able to simply enter +/- seconds at the 100ths of a second would be helpful, ie: "-2.3s" or "+0.9s" Hi David and all, If you use ntpd or chrony, you have the ability to insert this data in the appropriate config of these pieces of software. This has no place in the software using the time services. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-x and pulseaudio TX trouble
On 2/17/21 4:50 PM, ve...@napan.com wrote: Hi Glenn and all, ... I can set Audio to Pulse for both Rx and TX in wsjtx settings. Rx now works and decodes OK. I can switch modes no problem. I can see wsjtx in the recording tab of pavucontrol. If attempt to Tx via the Tune button (or Tx enable) the rig will switch to TX but there is no Tx audio. Please ensure that the right port has been selected as "Output Devices" in pavucontrol. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X v2.3.0 Oc42df.
On 2/10/21 10:58 AM, Adrian wrote: Hi Adrian and all, The top RTTY contesters have learned that -- they have abandoned dual peak filters and now use 500 Hz bandwidth, narrowing only in the presence of very strong signals in the passband. The bandwidth alone is not the whole story. Although I'm not a top RTTY contester, I have developed and used a constant delay discriminator over many years. You can find details here: http://dj0ot.darc.de/discri.pdf. The picture on the tuning scope display is here: http://dj0ot.darc.de. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] TS-450S
On 2/9/21 9:10 AM, Reino Talarmo wrote: Hi Reino and all, A piece of wire between RTS and CTS at rig end may also work as then rig thinks that a hardware handshake is there. May not work in all case and all situations, but worth of try. Normally PC does not care as long as WSJT-X handshake None is selected. The reason of the use of the handshake is the synchronisation of the data exchange between both sides. CAT is a data exchange, therefore a suitable form of handshake is necessary. Only in the case of a duplex data flow of independent data streams, the handshake is not necessary. Not using any handshake on an interface which has the ability of handshaking is bungling. You have to work with timeouts and resending data in the hope that the other side will be ready to accept and decode them well. Really, avoid this in any possible situation. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] TS-450S
On 2/8/21 9:33 PM, Black Michael via wsjt-devel wrote: Hmmm..that's 4-wire...so ground, tx, rx, and 5V and wouldn't work with hardware flow control. Mike W9MDB Hi Mike and all, RTS/CTS is the same as HARDWARE. Here these lines are not present, as you explain well. XON/XOFF (aka DC1/DC3, aka Ctrl-Q/Ctrl-S, aka software flow control) is possible in this constellation, but the support is necessary at BOTH ends of the line. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjtx configuration for setting PC audio IN (microphone)
On 2/1/21 10:10 AM, Maurizio Brameri wrote: Hi Maurizio and all, is there a way to set automatically at launch the gain of audio IN (from RTX to PC) or PC microphone, similar to slider on the right of wsjtx main window that sets the audio gain sent by PC to RTX? My question is coming from different audio levels needed by 2 different apps that I use with my RTX (IC-9700). Some hams have suggested to use the software named "ear-trumpet". https://ear-trumpet.software.informer.com/ Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.3.0-rc3
On 1/6/21 11:59 AM, Bill Somerville wrote: On 06/01/2021 10:53, Claude Frantz wrote: so that shows you have deleted the files in the debian sub-directory, was that by accident or deliberate? Hi Bill, It was not deliberate, probably by accident. Now, I have run: $ git checkout -B master origin/master M CMakeLists.txt D debian/CMakeLists.txt D debian/changelog.in D debian/copyright.in Branch 'master' set up to track remote branch 'master' from 'origin'. Reset branch 'master' Your branch is up to date with 'origin/master'. $ git reset --hard origin/master HEAD is now at 580363c29 Merge branch 'release-2.3.0' I hope that it was the right sequence. Then I have changed to the build directory… make -k The problem related to xsltproc occurred again. The executable "wsjtx" has not been rebuilt. Using cmake-gui, I have disabled the generation of the man pages. make -B wsjtx Now, I have the executable. Please note this warnings: [ 89%] Generating qrc_wsjtx.cpp /home/claude/ham/JoeTaylor/wsjtx/build/wsjtx.qrc: Warning: potential duplicate alias detected: 'qt_it.qm' /home/claude/ham/JoeTaylor/wsjtx/build/wsjtx.qrc: Warning: potential duplicate alias detected: 'wsjtx_it.qm' [ 89%] Building CXX object CMakeFiles/wsjtx.dir/qrc_wsjtx.cpp.o At next: make -k. The run goes to end. Now, I have to run the executable. Many thanks, Bill ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.3.0-rc3
On 1/6/21 11:38 AM, Bill Somerville wrote: Hi Bill, I am not sure what has happened, but that directory contains a CMakeLists.txt file in both the master branch and the wsjtx-2.3.0-rc3 tag. Looks like something has gone wrong with your local clone of the WSJT-X repository. What does this print: git -C ~/ham/JoeTaylor/wsjtx status Here is the output: $ git -C ~/ham/JoeTaylor/wsjtx status On branch master Your branch is up to date with 'origin/master'. You are in the middle of an am session. (fix conflicts and then run "git am --continue") (use "git am --skip" to skip this patch) (use "git am --abort" to restore the original branch) Changes not staged for commit: (use "git add/rm ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: CMakeLists.txt deleted:debian/CMakeLists.txt deleted:debian/changelog.in deleted:debian/copyright.in Untracked files: (use "git add ..." to include in what will be committed) HamlibTransceiver.hpp.orig User_Guide_FOP.pdf build/ doc/user_guide/en/install-linux.pdf doc/user_guide/en/install-mac.pdf doc/user_guide/en/my_Makefile doc/user_guide/en/settings-frequencies.pdf doc/user_guide/en/wsjtx-main.xml doc/user_guide/en/wsjtx-main_via_docpdf.pdf doc/user_guide/en/wsjtx-main_via_pandoc.pdf no changes added to commit (use "git add" and/or "git commit -a") Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.3.0-rc3
On 1/6/21 8:36 AM, Claude Frantz wrote: After having disabled the Debian stuff in CMakeLists.txt, the building process runs up to this output: [ 87%] Generating man/man1/rigctlcom-wsjtx.1.gz a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param man.endnotes.are.numbered 0 --stringparam callout.graphics 0 --stringparam navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" "/home/claude/ham/JoeTaylor/wsjtx/build/manpages/man/man1/rigctlcom-wsjtx.1.xml" returned non-zero exit status 5 make[2]: *** [manpages/CMakeFiles/manpages.dir/build.make:184: manpages/man/man1/rigctlcom-wsjtx.1.gz] Error 1 make[2]: Target 'manpages/CMakeFiles/manpages.dir/build' not remade because of errors. make[1]: *** [CMakeFiles/Makefile2:2010: manpages/CMakeFiles/manpages.dir/all] Error 2 Error number 5 is: Error in the stylesheet Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.3.0-rc3
On 1/5/21 11:30 PM, Dave Slotter wrote: Hi Dave, Bill and all, Unfortunately, I was not successful while trying to install from the source code from the git repo. Here is the output: $ make -- ** -- Building for for: Linux-i686 -- ** -- Building wsjtx v2.3.0.0-rc3 -- Found hamlib -- hamlib_INCLUDE_DIRS: /usr/local/include;/usr/include/libusb-1.0 -- hamlib_LIBRARIES: -L/usr/local/lib;-lhamlib;-lm;-lusb-1.0;-ludev;-pthread -- hamlib_LIBRARY_DIRS: /usr/local/lib -- Asking qmake for QT_PLUGINS_DIR and got /usr/lib/qt5/plugins -- Asking qmake for QT_TRANSLATIONS_DIR and got /usr/share/qt5/translations -- Asking qmake for QT_IMPORTS_DIR and got /usr/lib/qt5/imports -- Asking qmake for QT_DATA_DIR and got /usr/lib/qt5 CMake Error at CMakeLists.txt:1500 (add_subdirectory): The source directory /home/claude/ham/JoeTaylor/wsjtx/debian does not contain a CMakeLists.txt file. -- Configuring incomplete, errors occurred! See also "/home/claude/ham/JoeTaylor/wsjtx/build/CMakeFiles/CMakeOutput.log". See also "/home/claude/ham/JoeTaylor/wsjtx/build/CMakeFiles/CMakeError.log". make: *** [Makefile:14885: cmake_check_build_system] Error 1 The directory /home/claude/ham/JoeTaylor/wsjtx/debian is present but empty. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] DXCC entities list
On 12/28/20 11:36 PM, Loyd via wsjt-devel wrote: Hi Lorenzo and all, I wort to make a Python Class to get entities by prefix (dxcc number). Some one know if exists a file than contains a full list of entities, prefix, dxcc number? You can find the list of entities, including the number, at the ARRL site http://www.arrl.org/dxcc. Please note that there is NOT a one to one relationship between the prefixes and the DXCC entity number. Further, we have to consider that some assignations are only valid in a specific time range. Some stations are outside of the supposed entity. This is not a simple matter. Using the "cty.dat" file and the tables from ARRL, its possible to build database tables which provide a way to find the DXCC entity number of a given callsign. I have programmed some utilities allowing me to do this job using mariadb MySQL. I confess, in the current state, its a mess. In the attached file, you can see the output of a job asking the database. Although the prefix suggests that the entity is West Malaysia, the station is operating in the East Malaysia entity 46. Best wishes, Claude (DJ0OT) $ /home/claude/ham/ReqCS.sh 9M2/G3TMA/6 +++-+--+---+---+--+--+ | prefix | keylen | DXCCcty | WAE | textual | continent | CQZ | ITUZ | +++-+--+---+---+--+--+ | 9M | 2 | 9M2 |0 | West Malaysia | AS| 28 | 54 | +++-+--+---+---+--+--+ +-+---+-++---+---+--+--+ | name| name | DXCCcty | ARRLnumber | textual | continent | CQZ | ITUZ | +-+---+-++---+---+--+--+ | 9M2/G3TMA/6 | East Malaysia | 9M6 | 46 | East Malaysia | OC | 28 | 54 | +-+---+-++---+---+--+--+ 9M2/G3TMA/6: ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Yaesu FT-DX101D + WSJT-X 2.2.2
On 12/26/20 3:25 PM, Bill Somerville wrote: Hi Bill, Joe and all, He will also need to set the "MODE PSK/DATA-DATA SHIFT: 0 Hz" to get the VFO dial frequency aligned as per normal USB operation to get correct frequency readout. Please allow me to insist to mention that this 0 Hz shift is usually NOT the factory default used by Yaesu. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Question about QRZ Integration
On 12/3/20 8:23 PM, DG2YCB, Uwe wrote: Hi Uwe & all, Personally, I would really appreciate it if WSJT-X had this function. This additional data would significantly enhance the wsjtx_log.adi file. In addition to QRZ.com, hamQTH.com should be supported (free xml access). My opinion is that this function should be outside of WSJT-X and programs like fldigi. At my station, I get ADIF logs from WSJT-X, fldigi, xlog, LoTW and eQSL. They are merged and processed further in order to insert additional information, e.g. if the contacted station is willing to accepted paper QSL cards. I'm using own USERDEF fields in the ADIF log files, e.g. in order to track returned paper QSL cards and in order to save the "PSE QSL" or "TNX QSL" information found on received QSL cards. This helps to decide about sending paper QSL cards. I'm not using the information found on hamQTH.com because it's not reliable. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.3.0-rc2
On 11/16/20 2:24 PM, Richard Shaw wrote: Hi Richard, I know re-installation can be a pain, but I wonder how many people running a 32bit distro in 2020 are doing it on 64bit hardware... Likely most? No doubt, it's a pain, especially when we are not running a vanilla installation. At first, on this machine here, it was not recommanded to run the 64 bit mode, because of the many issues of the 64 bit OS. Therefore, I have installed the the 32 bit mode software and I have upgraded nearly on every release change. Then came GNOME 3 and I have switched to xfce because I have a computer and not a big circus game console. Now, the 32 bit software is not more available on Fedora. If a reinstallation is necessary, I think I will prefer the 64 bit Debian, although Debian is still available for the 32 bit architecture. The short lifetime of a Fedora release is a problem for me. With Debian, the problem is different, because many packages are really outdated. I confess, that a reinstallation is not a very exciting job for me. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.3.0-rc2
On 11/16/20 1:32 PM, Bill Somerville wrote: Note that Fedora 30 is EOL and Fedora 31 will go EOL in the near future now that Fedora 33 is released :) No, Fedora 30 is the latest release supporting the 32 bit architecture. That's the problem ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.3.0-rc2
On 11/15/20 4:01 PM, Joe Taylor wrote: Hi Bill, Joe & all, I'm on a 32 bit Fedora 30 here and I have tried to build using the git repo, as usual. There is a problem, which is probably not located in WSJT-X itself. [ 87%] Built target debian [ 87%] Generating man/man1/wsjtx.1.gz a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param man.endnotes.are.numbered 0 --stringparam callout.graphics 0 --stringparam navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" "/home/claude/ham/JoeTaylor/wsjtx/build/manpages/man/man1/wsjtx.1.xml" returned non-zero exit status 5 make[2]: *** [manpages/CMakeFiles/manpages.dir/build.make:134: manpages/man/man1/wsjtx.1.gz] Error 1 make[2]: Target 'manpages/CMakeFiles/manpages.dir/build' not remade because of errors. make[1]: *** [CMakeFiles/Makefile2:1974: manpages/CMakeFiles/manpages.dir/all] Error 2 Scanning dependencies of target fmtave ### The error 5 is "Error in the stylesheet". Here, /etc/asciidoc/docbook-xsl/manpage.xsl is part of the package asciidoc-8.6.10-0.9.20180605git986f99d.fc30.noarch It's interesting to note, that when I rerun "make", the error concerning "wsjtx.1.gz" has gone, but the same problem occurs now with "rigctld-wsjtx.1.gz". Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] compilation using Debian Stable
On 10/26/20 8:47 PM, Paul Bramscher wrote: Hi Paul, Christoph & all, Many thanks for this very interesting information. I'm a long time user of the Red Hat, then Fedora distribution. At the decision time of the distribution to use, this was probably not the wrong choice, but time has gone and I'm less and less convinced that this is not more the best choice for me. Today, Fedora is really an experimental distribution. The introduction of pulseaudio and systemd have been difficult. Now, the introduction of btrfs as standard filesystem is planned for the next release. Further, the support dropping of the i386 architecture is another problem. Now, the question which occurs for me is "is it better to switch to Debian stable ?". The sublevels (stable, testing, etc.) are not the same in Debian and Fedora. For me, it's difficult to understand which are the matching sublevels. At the present state, I think that the switching to Debian stable, with the backports option, could be a good choice. Today, I'm not more a big software designer, but I'm only a little one. Many thanks to you for your valuable advice. Best wishes, Claude (DJ0OT) I've recently added wsjtx 2.2.2 to buster-backports. So you can just install from there, or "apt build-dep wsjtx". I've compiled WSJT-X for a number of years now on Debian without significant issues. I was able to resolve all dependencies from within the regular repo. Currently running Debian 10 Buster, fully patched to the current version. If you search the forum archives for my callsign you should be able to see a couple related discussion threads with specific information. Yesterday I compiled 2.3.0-rc1 on my Debian 10 machine that runs WSJT-X 2.2.2 and encountered no new dependency issues. So once you get the initial dependencies met, it becomes smoother sailing. I am currently working 30M FT8 with a Kenwood TS-590. No issues encountered yet. 73, KD0KZE / Paul ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] compilation using Debian Stable
On 10/24/20 4:10 PM, Bill Somerville wrote: Hi Bill, which problems do I have to expect when trying to compile the source code from the git repo using Debian STABLE ? Which are the solutions available ? I haven't tried but do not expect anything that cannot be resolved by installing a package from the official repos. Ubuntu 20.04.1, which I use for development, is based Buster which is Debian stable. Thanks Bill ! That is interesting. My opinion was that Ubuntu is based on the UNSTABLE Debian distribution. This was the reason of my question. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] compilation using Debian Stable
Hello all, which problems do I have to expect when trying to compile the source code from the git repo using Debian STABLE ? Which are the solutions available ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Fwd: WSJTX on Ubuntu 20.04
On 10/12/20 11:32 PM, Maurizio Carosi wrote: Hello, I have checked the audio devices, "default", anyway I select specific audio devices "alsa_output.pci-_00_1b.0.analog-stereo" or "pulse", save and restart every time but not solve the problem. Hi Maurizio & all, If you are using pulseaudio, please verify that you have selected the right input and audio devices. Please use the program named "PulseAudio Volume Control" (pavucontrol). This is not the same as the selection of a sound card. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Release Candidate: WSJT-X 2.3.0-rc1
On 9/27/20 10:23 PM, Joe Taylor wrote: The first public candidate release of WSJT-X 2.3.0 is now available for download and use by beta testers. Hi Joe and all, While trying to build from the source, I found the problem which is reported in the attached file. Best wishes, Claude (DJ0OT) [ 80%] Built target wsjt_qtmm_autogen [ 81%] Built target wsjt_qtmm [ 81%] Generating man/man1/message_aggregator.1.gz a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param man.endnotes.are.numbered 0 --stringparam callout.graphics 0 --stringparam navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" "/home/claude/ham/JoeTaylor/wsjtx/build/manpages/man/man1/message_aggregator.1.xml" returned non-zero exit status 5 make[2]: *** [manpages/CMakeFiles/manpages.dir/build.make:150: manpages/man/man1/message_aggregator.1.gz] Error 1 make[2]: Target 'manpages/CMakeFiles/manpages.dir/build' not remade because of errors. make[1]: *** [CMakeFiles/Makefile2:2883: manpages/CMakeFiles/manpages.dir/all] Error 2 [ 81%] Automatic MOC for target encode77 [ 81%] Built target encode77_autogen ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] r2.2.2 Minor Issue with "short" calls that use DX
On 8/19/20 4:12 PM, Neil Zampella wrote:
The logic would need to be able to
distinguish between a valid callsign, and something that LOOKS like a
valid callsign but isn't.
As I have mentioned previously, I'm using the following regex test in perl:
if ( $hash{"CALL"} =~
'^((([A-PR-Z][A-Z]*[0-9]*[A-Z]?)|([1-9][A-Z]+[0-9]*))\/)?(([A-PR-Z
][A-Z]*[0-9]+[A-Z]+)|([1-9][A-Z]+[0-9]+[A-Z]+))(\/([PMA0-9]|MM|(([A-Z]+[0-9]*[A-Z]?)|([1-9][A-Z]+[0-9]*?
$' ) {
}
else {
say STDERR '=== Probably an erroneous callsign ', $hash{"CALL"} ;
}
This will not work well for ANY callsign, but for most ones.
Best wishes,
Claude (DJ0OT)
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] rigctld and itu_region
On 7/24/20 3:15 PM, Black Michael via wsjt-devel wrote: I've been looking for somebody who cares about the itu_region stuff. Claude -- why are you using that parameter? It really doesn't do anything. I know some are using frequency ranges but nobody using the itu_region option. Hi Mike, Bill & all, I was using this option because it was available and I have supposed that there is a good reason for it. Now, that you reveal that it really doesn't do anything, I suggest to remove it. What you have done, in fact. Thanks ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] rigctld and itu_region
Hi Mike, Bill and all, In the past, I was able to start with: /usr/local/rigctld -m129 -s4800 -r/dev/ttyUSB0 --dcd-type=RIG --setconf=timeout=500,retry=2,write_delay=5,post_write_delay=50,itu_region=1 When using the new hamlib, the "itu_region=1" is not more accepted. Of course, "-m129" must be changed. What is the reason of the rejection of this argument ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FW: CAT problems with FT817, FT857 and FT897
On 7/2/20 9:01 PM, Stephen VK3SIR wrote: Hi Steve, Bill and all, Bill and Claude (and my SINCEREST apologies for hitting the “d” rather than “s” and referring to you as you Clause), No problem, Steve ! The “dialout” group access is needed as a minimum for USB access to device such as the SCU-17. As you are working primarily with a “tty” group - and for the purposes of being “generic” across system versions – it is always traditionally ‘safer’ to add “tty” in when using local systems. This matter is often different, depending on the Linux distribution. Here, I'm using Fedora, it was necessary to become member of the dialout group, but tty and audio were not necessary. The video group is not defined here. Claude I primarily run the FT-991 (not A model) here – that for all purposes is identical – and note that all compiles and works fine at this point with Linux and Windows x64 (but will not promise). Fine to read this ! Yesterday, I have found that the FT-991 is using the newCAT technology. Therefore, it's different than the FT-8?7 series. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] CAT problems with FT817, FT857 and FT897
On 7/2/20 2:11 PM, Bill Somerville wrote: there are several issues with that series of rigs (you can include the new FT-818ND in the list too), as there are with almost all rigs. All have workarounds, why are you asking please, that will help focus on how to answer? Many thanks again, Bill ! Just an additional question: Is the FT-991(A) concerned too ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] CAT problems with FT817, FT857 and FT897
On 7/2/20 1:27 PM, Bill Somerville wrote: Many thanks, Bill ! there are several issues with that series of rigs (you can include the new FT-818ND in the list too), as there are with almost all rigs. All have workarounds, why are you asking please, that will help focus on how to answer? I do not have any rig from this series. I'm only asking in order to remain informed. I have observed many work, in the recent past. Thank you ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FW: CAT problems with FT817, FT857 and FT897
On 7/2/20 11:25 AM, Stephen VK3SIR wrote: Many thanks, Stephen, for this very interesting information and for your tips. i.e. sudo usermod -a G adm,tty,disk,dialout,audio,video,plugdev In my own environment, using Fedora, it was important to add "dialout". Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] CAT problems with FT817, FT857 and FT897
Hi all, Can anyone here give us a short but precise description of the problems related to the equipment mentioned in the subject, please ? Thanks you ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FD FT4 crashing
On 6/28/20 5:03 PM, Larry B. via wsjt-devel wrote: I’m seeing the same thing. Seems to crash just as someone comes back to me. Which operating system are you using ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Need some suggestions to discover audio feedback cause.
On 6/20/20 11:10 PM, Marco Calistri wrote: Hi Marco and all, I have finally found the root cause of the audio feedback described above. I've not mentioned into the anomaly description that I'm using Linux as O.S. and that the sound system is managed by pulseaudio, a Linux sound framework which in turns can be regulated by alsamixer. Many thanks for reporting about this strange effect. I think that it's important to understand the strange relationship between alsa and pulseaudio. At the side of the interface to the sound card, pulseaudio is using alsa modules. But when a client want to connect to the audio system in the ALSA style, it has to use a compatibility interface of pulseaudio. Nevertheless, the recommanded way to connect is the native pulseaudio interface. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsjt-devel Digest, Vol 76, Issue 93
On 6/9/20 3:39 PM, Steven Franke via wsjt-devel wrote: Hi Steven, Using a 2.2.x version, decoding on a busy band has the following behavior: first decode in cycle picks up a few messages, second decode a few, then the third decode runs a long time (well into the next cycle) and the majority of messages get decoded on that third decode. What are your typical DT values, i.e. what is the median DT value for a cycle that has a good number of decodes? Normally, we expect to see the bulk of the decodes produced by the first decoding segment (say, 80%) and only a small number of decodes produced during the third segment. However, if there is significant receiver latency, this can push most of the decodes into the third segment. FWIW, no decoding is done during the second decode segment. This segment is used to subtract all of the decodes that were obtained during the first segment. Fine to learn how it should work, but here, there is always the same crash, even in 2.2.1, trying to decode FT8 on the air or from a wav file. In contrast, FT4 decodes well. Program received signal SIGSEGV, Segmentation fault. 0x080bed38 in gen_ft8wave (itone=..., nsym=79, nsps=1920, bt=2, fsample=12000, f0=0, cwave=is more than max-value-size>, wave=more than max-value-size>, icmplx=1, nwave=151680) at /home/claude/ham/JoeTaylor/wsjtx/lib/ft8/gen_ft8wave.f90:48 48wave=0. type = integer(kind=4) (79) type = complex(kind=4) (151680) type = real(kind=4) (151680) value requires 606720 bytes, which is more than max-value-size value requires 1213440 bytes, which is more than max-value-size #0 0x080bed38 in gen_ft8wave (itone=..., nsym=79, nsps=1920, bt=2, fsample=12000, f0=0, cwave=is more than max-value-size>, wave=more than max-value-size>, icmplx=1, nwave=151680) at /home/claude/ham/JoeTaylor/wsjtx/lib/ft8/gen_ft8wave.f90:48 #1 0x0809ef9d in subtractft8 ( dd0=more than max-value-size>, itone=0x0>, f0=0, dt=0, lrefinedt=0x0>) at /home/claude/ham/JoeTaylor/wsjtx/lib/ft8/subtractft8.f90:45 #2 0x in ?? () Best wishes and stay@Ω ! Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.2.0 GA release: crash of "jt9" executable
On 6/4/20 2:32 PM, Claude Frantz wrote: Hi all, Is anybody here, able to run 2.2.0 or 2.2.1 and to decode FT8 signals, while running on Linux 32 bit ? Many thanks for your help. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X 2.2.1: output of the jt9 executable
Hi Bill & all, The output of the decoding of a ".wav" file, using jt9, has additional columns now. What is the meaning of these columns ? Best wishes and stay@Ω ! Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.2.0 GA release: crash of "jt9" executable
On 6/4/20 3:00 PM, Claude Frantz wrote: Thread 2.1 "jt9" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb34223c0 (LWP 25577)] 0x0809ee28 in subtractft8 ( dd0=more than max-value-size>, itone=memory at address 0x0>, f0=0, dt=0, lrefinedt=0x0>) at /home/claude/ham/JoeTaylor/wsjtx/lib/ft8/subtractft8.f90:47 47 ldt=lrefinedt If I see this well, no value has been assigned to lrefinedt before. Right ? Sorry, I'm wrong. This variable is in the parameter list. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 2.2.0 GA release: crash of "jt9" executable
On 6/4/20 2:43 PM, Bill Somerville wrote: Re Bill, I am not sure what you mean by "When feeding a wav file to this jt9 executable, no crash occurs." Are you saying that you have a .WAV file causes a crash when playing back in WSJT-X but not when passed to the command line jt9 executable? If so then can you provide the .WAV file please? Please excuse my imprecision. The attached picture is displayed when trying to run the usual way, decoding signals on the air. But when calling jt9 with a wav file as argument, then jt9 decodes as expected. I have just tried gdb with "set follow-fork-mode child". Here is the interesting part of the output: Thread 2.1 "jt9" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb34223c0 (LWP 25577)] 0x0809ee28 in subtractft8 ( dd0=more than max-value-size>, itone=memory at address 0x0>, f0=0, dt=0, lrefinedt=0x0>) at /home/claude/ham/JoeTaylor/wsjtx/lib/ft8/subtractft8.f90:47 47ldt=lrefinedt If I see this well, no value has been assigned to lrefinedt before. Right ? Best wishes, Claude ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X 2.2.0 GA release: crash of "jt9" executable
Hello Bill & all, Please consider the attached picture. When feeding a wav file to this jt9 executable, no crash occurs. What can I do to investigate further ? gdb is available. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] exporting from adi
On 5/22/20 7:22 PM, Paul Bramscher wrote: Hi Paul & all, What I've done is maintain two local logs: WSJT-X's native log and XLog for everything else. fldigi will auto-ingest into XLog, and I can easily enough create Phone and other entries manually in XLog. Please note that fldigi is able to change entries in its log. Unfortunately such updates are not passed to Xlog. I periodically use TQSL to upload WSJT-X contacts to Logbook of the World. To make this more efficient, I examine my past activity date on LoTW's interface and use my last upload date as the cut-off date for new QSO's to upload. I also upload XLog logs there, so LoTW is the place where they all get combined. Then I occasionally export those and upload them into QRZ for good measure. adifmerg is an excellent program to merge ADIF log files. Unfortunately, LoTW is not a good place to combine logs files because only a limited number of ADIF fields are maintained. Please remember that paper QSL exist too and many other things which are ignored by LoTW. Finally, only a locally maintained ADIF file can help to maintain all the information. And adifmerg can help you to do it. This is the way I'm going. With the optional addition of few user defined fields, such a locally stored ADIF file can be the base from which one an appropriate program can automatically generate detailed paper QSL cards. Of course, received QSL cards have to be mentioned in the appropriate records of the ADIF file. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Coming soon: WSJT-X 2.2.0-rc1
On 5/10/20 11:58 AM, Bill Somerville wrote: Which releases of hamlib can be used to compile ? although it is still recommended to use my fork of Hamlib, currently my fork integration branch is the same as its master branch which in turn is close to the current Hamlib master branch at commit 320b2552. Hi Bill, Can this fork of Hamlib replace the "normal" Hamlib in any situation ? Can I use it to compile and build any pieces of software using Hamlib ? Best wishes, Claude ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Coming soon: WSJT-X 2.2.0-rc1
On 5/5/20 6:17 PM, Joe Taylor wrote: This message is to let you know of some important WSJT-X development plans. We plan to make a first candidate release of WSJT-X 2.2.0 next Monday, May 10. WSJT-X 2.2.0-rc1 will be a beta-quality release candidate providing a number of new features and capabilities. Hi Bill & all, Which releases of hamlib can be used to compile ? Is the use of the special wsjt style hamlib mandatory ? What are the differences vs. "standard" hamlib ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] version as seen by pskreporter
Hi Bill & all, While pointing my mouse to my own station on the pskreporter window, I observe that the "Using:" has the "-dirty" suffix. Please explain me why and explain us how the version string is build. Thanks ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Lost red Lotw user in band activity
On 4/3/20 5:47 AM, Barry Bowman wrote: Hi Neil Problem is solved. 73’s Barry Please say us how you have solved the problem. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Unusual TX on delay
On 3/16/20 5:45 PM, Black Michael via wsjt-devel wrote: Hi Mike, If you're using a device other than "Hamlib NET rigctl" in WSJT-X...yes.You do need to rebuild hamlib first of course Of course, I have to rebuild hamlib, but my question was related to the rebuild of wsjtx. I have seen previously, that I had to rebuild wsjtx after the rebuild of hamlib, in order to have the modifications applied. Try again...I removed a new function that was in test...will have to move it to a different place. Do I have to rebuild wsjtx after this change ? I have rebuilt hamlib only and I have seen no change in the behaviour. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Unusual TX on delay
On 3/16/20 5:23 PM, Black Michael via wsjt-devel wrote: Try again...I removed a new function that was in test...will have to move it to a different place. Do I have to rebuild wsjtx after this change ? The "Rig busy" should only be at rigctl startup... Yes, I have seen this warning twice at the start. Not more later. if it shows elsewhere I'd like to see where it so if you could provide some debug with "-v -Z" it would help. Contact me off-list please as this is not a WSJT-X problem. de Mike W9MDB OK, Mike ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Unusual TX on delay
On 3/16/20 3:32 PM, Claude Frantz wrote: On 3/16/20 2:52 PM, Black Michael via wsjt-devel wrote: Try again...I fixed it. de Mike W9MDB Many thanks, Mike. "make test" passes all 4 tests now. I will continue my test with WSJT-X. What I have done further: (as user root, in the hamlib directory) make install ldconfig (using my normal account, in the wsjtx/build directory) make (as user root, in the wsjtx/build directory) make install ldconfig Now, on the air... This unusual delay is still present. The console output "Hamlib: newcat_get_cmd: Rig busy" also. I returned to wsjtx/build directory, then "make clean", make and the same as above. Now, on the air again... The console output "Hamlib: newcat_get_cmd: Rig busy" is still here. At the program start, the frequency is set as expected, now. The delay seems to have a normal value now. Calling CQ results in some reports on pskreporter. Many thanks, Mike ! Many thanks, Bill ! Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Unusual TX on delay
On 3/16/20 2:52 PM, Black Michael via wsjt-devel wrote: Try again...I fixed it. de Mike W9MDB Many thanks, Mike. "make test" passes all 4 tests now. I will continue my test with WSJT-X. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Unusual TX on delay
On 3/15/20 8:57 PM, Black Michael via wsjt-devel wrote:
Try checking out hamlib in a new directory.
I'm seeing that the build-aux directory isn't being cleaned.
de Mike W9MDB
OK, Mike. I have got the stuff in a new directory.
Then:
./bootstrap
LD_RUN_PATH=/usr/local/lib PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
CXXFLAGS="-march=core2" CFLAGS="-march=core2" ./configure
--with-xml-support --disable-winradio --with-perl-binding
make
make -k check
make check
This is the end of the output:
Making check in tests
make[1]: Entering directory '/home/claude/hamlib/tests'
make dumpmem testrig testtrn testbcd testfreq listrigs testloc
rig_bench testrig.sh testfreq.sh testbcd.sh testloc.sh
make[2]: Entering directory '/home/claude/hamlib/tests'
make[2]: 'dumpmem' is up to date.
make[2]: 'testrig' is up to date.
make[2]: 'testtrn' is up to date.
make[2]: 'testbcd' is up to date.
CC testfreq.o
testfreq.c: In function ‘main’:
testfreq.c:35:54: error: invalid application of ‘sizeof’ to incomplete
type ‘struct rig’
35 | printf("RIG size: %lu\n", (long unsigned) sizeof(struct rig));
| ^~
make[2]: *** [Makefile:1058: testfreq.o] Error 1
make[2]: Leaving directory '/home/claude/hamlib/tests'
make[1]: *** [Makefile:1693: check-am] Error 2
make[1]: Leaving directory '/home/claude/hamlib/tests'
make: *** [Makefile:604: check-recursive] Error 1
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Unusual TX on delay
The first lines of the output are:
$ make clean
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.16 -I macros --install
aclocal-1.16: overwriting 'macros/ax_pkg_swig.m4' with
'/usr/share/aclocal/ax_pkg_swig.m4'
cd . && automake-1.16 --gnu
CDPATH="${ZSH_VERSION+.}:" && cd . && autoconf
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ./configure --with-xml-support
--disable-winradio --with-perl-binding --no-create --no-recursion
checking for gcc... gcc
checking whether the C compiler works... yes
Later, there are the following lines:
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/home/claude/hamlib/build-aux/missing: Unknown `--is-lightweight' option
Try `/home/claude/hamlib/build-aux/missing --help' for more information
configure: WARNING: 'missing' script is too old or missing
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports the include directive... yes (GNU style)
checking whether make supports nested variables... yes
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Unusual TX on delay
On 3/15/20 7:02 PM, Bill Somerville wrote:
Hi Bill,
I'm not sure why that is happening. The aclocal tool should not be
trying to copy in the system version of that m4 macro if it is already
there. Try a 'make clean && make' and see if that goes any better?
In order to synchronize with the repo, I have done:
git checkout -- macros/ax_pkg_swig.m4
git pull
make clean
The first lines of the output are:
$ make clean
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.16 -I macros --install
aclocal-1.16: overwriting 'macros/ax_pkg_swig.m4' with
'/usr/share/aclocal/ax_pkg_swig.m4'
cd . && automake-1.16 --gnu
CDPATH="${ZSH_VERSION+.}:" && cd . && autoconf
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ./configure --with-xml-support
--disable-winradio --with-perl-binding --no-create --no-recursion
checking for gcc... gcc
checking whether the C compiler works... yes
For any strange reason, even "make clean" overwrites macros/ax_pkg_swig.m4.
Best wishes,
Claude (DJ0OT)
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Unusual TX on delay
On 3/15/20 5:52 PM, Bill Somerville wrote:
Hi Bill,
Please see the first few lines of the output of "make" in the hamlib
directory:
$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.16 -I macros --install
aclocal-1.16: overwriting 'macros/ax_pkg_swig.m4' with
'/usr/share/aclocal/ax_pkg_swig.m4'
cd . && automake-1.16 --gnu
CDPATH="${ZSH_VERSION+.}:" && cd . && autoconf
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ./configure --with-xml-support
--disable-winradio --with-perl-binding --no-create --no-recursion
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
This may be the reason of the modified 'macros/ax_pkg_swig.m4'.
Best wishes,
Claude (DJ0OT)
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Unusual TX on delay
On 3/15/20 5:52 PM, Bill Somerville wrote: Hi Bill, unless you specifically edited macros/ax_pkg_swig.m4 for some reason I suggest you run this command: git checkout -- macros/ax_pkg_swig.m4 then try the 'git pull' again. I have not changed macros/ax_pkg_swig.m4. 'git pull' has applied many changes: 280 files changed, 1139 insertions(+), 543 deletions(-) I will try to recompile and test again. Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Unusual TX on delay
On 3/15/20 5:17 PM, Black Michael via wsjt-devel wrote: Hi Mike, Can you please run rigctld with "-Z -v" and redirect the log to a file. Then send me the file. This file is attached. Are you running one of the split modes? What happens with no split? I was using the split mode as usual. I have not tried no split. Best wishes, Claude (DJ0OT) 2020-03-15:16:49:56.442129: rigctld, Hamlib 4.0~git 2020-03-15:16:49:56.442173: Report bugs to 2020-03-15:16:49:56.442189: rig_init called 2020-03-15:16:49:56.442217: initrigs4_dummy: _init called 2020-03-15:16:49:56.442238: rig_register called 2020-03-15:16:49:56.442252: rig_register: rig_register (1) 2020-03-15:16:49:56.442259: rig_register called 2020-03-15:16:49:56.442266: rig_register: rig_register (2) 2020-03-15:16:49:56.442297: rig_register called 2020-03-15:16:49:56.442305: rig_register: rig_register (4) 2020-03-15:16:49:56.442312: rig_register called 2020-03-15:16:49:56.442319: rig_register: rig_register (5) 2020-03-15:16:49:56.442369: dummy_init called 2020-03-15:16:49:56.442409: rig_passband_normal called 2020-03-15:16:49:56.442417: rig_passband_normal called 2020-03-15:16:49:56.442430: rig_open called 2020-03-15:16:49:56.442438: port_open called 2020-03-15:16:49:56.442446: dummy_open called 2020-03-15:16:49:56.442453: rig_get_vfo called 2020-03-15:16:49:56.442461: dummy_get_vfo called: VFOA 2020-03-15:16:49:56.442468: rig_set_parm called 2020-03-15:16:49:56.442475: rig_has_set_parm called 2020-03-15:16:49:56.442483: rig_setting2idx called 2020-03-15:16:49:56.442491: rig_strparm called 2020-03-15:16:49:56.442499: rig_strparm called 2020-03-15:16:49:56.442505: dummy_set_parm called: SCREENSAVER 0 2020-03-15:16:49:56.442515: Backend version: 0.7, Status: Stable 2020-03-15:16:49:56.442522: rig_close called 2020-03-15:16:49:56.442529: dummy_close called 2020-03-15:16:49:56.442536: port_close called 2020-03-15:16:50:26.759113: main: select 2020-03-15:16:50:26.759152: sync_callback: client lock engaged 2020-03-15:16:50:26.759168: rig_close called 2020-03-15:16:50:26.759180: sync_callback: client lock disengaged 2020-03-15:16:50:26.759196: rig_cleanup called 2020-03-15:16:50:26.759209: dummy_cleanup called Recommend using --vfo switch for rigctld rigctl and netrigctl will automatically detect vfo mode Opened rig model 1, 'Dummy' Closed rig model 1, 'Dummy - will reopen for clients' ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Unusual TX on delay
On 3/15/20 5:11 PM, Bill Somerville wrote: Hi Bill, which Hamlib git repository are you using? I ask because the one on SourceForge is a bit behind the one on GitHub. This is mainly due to the volume of changes recently. I have just pushed the latest changes to the SourceForge repo, if you are using that one try a 'git pull' and see if that helps. Please see... $ git remote -v origin git://git.code.sf.net/p/hamlib/code (fetch) origin git://git.code.sf.net/p/hamlib/code (push) $ git pull remote: Enumerating objects: 4060, done. remote: Counting objects: 100% (1155/1155), done. remote: Compressing objects: 100% (132/132), done. remote: Total 790 (delta 660), reused 787 (delta 657) Receiving objects: 100% (790/790), 109.45 KiB | 285.00 KiB/s, done. Resolving deltas: 100% (660/660), completed with 321 local objects. From git://git.code.sf.net/p/hamlib/code 48833e22..cf118799 master -> origin/master Updating 48833e22..cf118799 error: Your local changes to the following files would be overwritten by merge: macros/ax_pkg_swig.m4 Please commit your changes or stash them before you merge. Aborting Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Unusual TX on delay
Hi Bill, Mike & all, I'm testing WSJT 2.1.2 from git repo using Hamlib 4.0~git from the git repo, last hamlib commit: commit 48833e2263b940e706d8a0a94d9d32753f73996f. I'm using the Yaesu FT-2000, the PC is synchronized via NTP. The OS is 32 bit Fedora 30. When CAT switches the TX on, there is a delay which I estimate to 1 to 2 seconds before the TX goes on the air. I'm hearing the other stations clearly before my TX goes on at my station. I have seen this behaviour when using FT8 and FT4. Sometimes, the following message is displayed at the terminal window: "Hamlib: newcat_get_cmd: Rig busy". The same WSJT-X config has worked well a long time before. Another observation: In the past, when I have started WSJT-X, the frequency has been set well at the program start time. Now, this frequency is wrong at the start time and I have to set it using the BAND selector. What is wrong ? Best wishes, Claude (DJ0OT) ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
