|
locked
Re: V2.2.0 rc1 error on start up (32 bit)
On 11/05/2020 16:35, Bob G8HGN wrote:
Hi,Hi Bob, as stated on the WSJT-X web page https://physics.princeton.edu/pulsar/K1JT/wsjtx.html and on the SourceForge files area README information https://sourceforge.net/projects/wsjt/files/wsjtx-2.2.0-rc1/ , WSJT-X v2.2.0 is only supported on Windows 7 or later. We have been trailing removal of support for both Windows XP and Windows Vista for a number of releases, and as Windows 7 is now out of support and MS having three later releases of Windows in the field (8, 8.1 and 10); that time has come. We have had to make this choice because supporting the latest versions of Windows, particularly the 64-bit version of WSJT-X, which has considerable performance advantages, makes support back to ancient and insecure operating system versions more trouble that it is worth. Specifically we do not wish to limit features and performance on newer operating systems just to support a few users of older systems. 73 Bill G4WJS.
|
|
|
|
locked
Re: Curved Line in Waterfall
Gary - AG0N
On May 11, 2020, at 09:27, Gary - AG0N <mcduffie@...> wrote:On May 11, 2020, at 05:58, Samuel KJ4VPI <sernstfortin@...> wrote:There’ll be those who say to use the Freq Cal mode, but you don’t even need that if you’re just looking for large drift. Take the VFO and shove it to your nearest friendly neighborhood WWV/CHU frequency, tune off center by 1000 or 1500 (whatever you want), and just leave it. If the radio is drifting, you should be able to see it right away. If it is a long term deal, park it for an hour, or hours, and see what it does over time. If you use the Freq Cal mode, it will read out the tone frequency in decimals of cycles so you can see precisely what it is doing. By the way, drifting should not change anything WSJT-X presents to you in the form of a message. The only thing you should see WSJT-X do is show you a different DF each receive cycle for a given signal that is not really moving. Gary
|
|
|
|
locked
Re: JT Alert Question
On 11/05/2020 16:26, Bill wrote:
Hi Bill, I'm not sure why you think your query has anything to do with JTAlert, the ALL.TXT file in the WSJT-X log files directory is a WSJT-X file. WSJT-X writes all decoded messages along with transmitted messages to that file, it is a journal of your operation, as such I recommend that you keep the contents. There is no need to keep the contents all in the ALL.TXT file, for example you might choose to archive the file to an offline storage media once a year. I recommend keeping the contents of the ALL.TXT file indefinitely as it can be very useful for clarifying future queries about completed, or otherwise, QSOS. WSJT-X only writes to the ALL.TXT file, unlike the wsjtx_log.adi log file which is used to determine which stations and related entities you have worked before. 73 Bill G4WJS.
|
|
|
|
locked
V2.2.0 rc1 error on start up (32 bit)
Hi,
Have just downloaded the new rc1, and the 64 bit version is working on my W10 64 bits PC, but the 32 bit version is not on my Vista 32 bit laptop. I get an error message as in the attached screengrab. Bob G8HGN
|
|
|
|
locked
Re: Curved Line in Waterfall
Gary - AG0N
On May 11, 2020, at 05:58, Samuel KJ4VPI <sernstfortin@...> wrote:There’ll be those who say to use the Freq Cal mode, but you don’t even need that if you’re just looking for large drift. Take the VFO and shove it to your nearest friendly neighborhood WWV/CHU frequency, tune off center by 1000 or 1500 (whatever you want), and just leave it. If the radio is drifting, you should be able to see it right away. If it is a long term deal, park it for an hour, or hours, and see what it does over time. If you use the Freq Cal mode, it will read out the tone frequency in decimals of cycles so you can see precisely what it is doing. Gary - AG0N
|
|
|
|
locked
JT Alert Question
Bill <k2wh@...>
I know I'm on the wrong forum, but I don't see how to post on the JTAlert forum. Bill
|
|
|
|
locked
Re: Linux Serial Port Issues
On 11/05/2020 15:30, Mark Erbaugh
wrote:
Hi Mark, if the "Test CAT " button is not working then you should be getting an error message window. What does that error message window say, including the text revealed by the "Show Details ..." button? 73
|
|
|
|
locked
Re: Linux Serial Port Issues
Mark Erbaugh <mark.election@...>
Kari,
Thanks for the reply. See below. You issuded "sudo usermod ..", right?After that, did you log off and on again?Does command 'id' show 'dialout' as one of your groups now? I’m not sure I had logged off and back on, but I did just now.
Id shows that pi is a member of the dialout group What does command 'ls -ltr /dev/tty*' show when you havethe KUSB cable connected? crw-rw---- 1 root dialout 188, 0 May 11 10:19 /dev/ttyUSB0 What exactly does not work? How did you test?
I retested, and it seems the only thing not working is the Test CAT button.
73, Mark
|
|
|
|
locked
WSJT-X 2.2.0-rc1
WSJT-X 2.2.0 will be a significant program upgrade offering many new features.
The first candidate release, WSJT-X 2.2.0-rc1, is now available for download and use by beta testers. This candidate release is your first chance to test the new features and provide feedback to the WSJT Development Group. A list of program changes since WSJT-X 2.1.2 can be found in the cumulative Release Notes http://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt ... and also in the updated WSJT-X 2.2.0 User Guide here: http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0-rc1.html#NEW_FEATURES Upgrading from earlier versions of WSJT-X should be seamless. There is no need to uninstall a previous version or move any files. You might want to install to a different directory from your WSJT-X 2.1.2 installation. Links to installation packages for Windows, Linux, and Macintosh are available here: http://physics.princeton.edu/pulsar/k1jt/wsjtx.html Scroll down to find "Candidate release: WSJT-X 2.2.0-rc1". You can also download the packages from our SourceForge site: https://sourceforge.net/projects/wsjt/files/ It may take a short time for the SourceForge site to be updated. WSJT-X is licensed under the terms of Version 3 of the GNU General Public License (GPL). Development of this software is a cooperative project to which many amateur radio operators have contributed. If you use our code, please have the courtesy to let us know about it. If you find bugs or make improvements to the code, please report them to us in a timely fashion. We hope you will enjoy using this beta release of WSJT-X 2.2.0. Please report bugs by following instructions found here in the User Guide: http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.2.0-rc1.html#_bug_reports -- 73 from Joe, K1JT, Steve, K9AN, and Bill, G4WJS, for the WSJT Development Group
|
|
|
|
locked
Interesting new display
Just installed v2.2.0 rc1 and found that the Band Activity window has a "new normal" that I find awkward.
|
|
|
|
locked
Re: Linux Serial Port Issues
Karza <kari.sillanmaki@...>
Hi Mark, On 11.5.2020 15.41, Mark Erbaugh wrote:
You issuded "sudo usermod ...", right? After that, did you log off and on again? Does command 'id' show 'dialout' as one of your groups now? What does command 'ls -ltr /dev/tty*' show when you have the KUSB cable connected?
What exactly does not work? How did you test?
No need to do anything like that. 73's de Kari, oh2gqc
|
|
|
|
locked
Waterfall signal Identification
Kermit Lehman
Hi,
One of the fringe benefits of a waterfall display, as in WSJT-X, is sightings of strange signals that occasionally show up. At least I enjoy it as long as they don't interfere too much.
Some of them are other amateur radio signals that we aren't used to seeing in a graphic display. PACTOR, for example. Sometimes someone will accidentally sweep a CW signal across the band. Some are signals from other services that have strayed.
At my QTH there are also many junk signals from devices in my neighborhood which contribute to the overall noise floor but can also stand out as individual signals. These are usually seen as broad noise bands. They often unstable and gradually drift across the waterfall, back and forth sometimes. I've noticed some of these change as people move in and out of the area.
Here is a resource for identifying different radio signal modes:
73,
Ken, AB1J
|
|
|
|
locked
Linux Serial Port Issues
Mark Erbaugh <mark.election@...>
I am building a Raspberry Pi 4 to serve as a portable data terminal. For more information, see KM4ACK’s YouTube video and his pi-build script on GitHub (www.github.com/km4ack/pi-build).
The rig is an Elecraft KX3. The interface is a Timewave Navigator. The Navigator provides multiple FTDI USB/serial ports, one of which provides a CAT interface to the rig. Just to eliminate the Navigator as the problem, I also tried the standard Elecraft KXUSB interface cable, which also provides a FDTI USB serial port. (the Navigator and KXUSB were not connected at the same time).
With the interface cable plugged in to the RPi, I did dmesg and saw that the serial ports were correctly associated with the FTDI drivers.
I did the “usermod -a -G dialout pi” to add my local user (pi) to the dialout group for access to the serial ports.
FLRig is able to access the CAT interface and control the KX3.
I exit FLRig and launch WSJT-X. Under rig setup, I specify the correct serial port (/dev/ttyUSB0) and baud rate. I click the Test CAT button and it doesn’t change color – neither red nor green. Sometimes, this disables the Test PTT button, but when it doesn’t toggling the Test PTT button toggles Tx on the KX3.
Back on the WSJT-X main screen, the frequency mirrors the KX3’s frequency, changes to frequency on the radio change in WSJT-X and vice versa, but the “fake it” split mode doesn’t work.
This is with WSJT-X 2.1.10 which was built from source code. The RPi 4 is running Raspian Buster which has been updated with the latest changes.
For comparison, I installed WSJT-X 2.1.12 from the .deb file on the website onto a desktop computer running Linux Mint 19. I saw the same problems. Again FLRig worked fine.
I did various things such as changing the owner of the serial ports to the local user and changing the group of the serial ports to the local user – no change.
I started WSJT-X using sudo and the Test CAT button worked and turned green, so I think there may still be a permission issue.
Thanks for any suggestions, 73, Mark, N8ME
|
|
|
|
locked
Re: Curved Line in Waterfall
On 11/05/2020 12:58, Samuel KJ4VPI wrote:
Has anyone else noticed some slight variation in received messages in WSJT-X well after warmup? I'm noting a little tilting, and I wonder if the radio is experiencing a little thermal drift. Is there a PC program to measure drift using WWV as a calibrated source?Thx. Sam KJ4VPIHi Sam, you can use WSJT-X Frequency Calibration mode to measure your rig's frequency accuracy over time. 73 Bill G4WJS.
|
|
|
|
locked
Re: Curved Line in Waterfall
Samuel W7STF
Has anyone else noticed some slight variation in received messages in WSJT-X well after warmup? I'm noting a little tilting, and I wonder if the radio is experiencing a little thermal drift. Is there a PC program to measure drift using WWV as a calibrated source?Thx. Sam KJ4VPI
|
|
|
|
locked
Re: WSJT-X to N3FJP AC Log Interface
Jim,
for an application to receive UDP
datagrams from another application is not complex, no more so that
opening a file and reading it. In many ways it is simpler as the
UDP datagrams are sent so the receiving application need only wait
for them to arrive, and there is no ambiguity as to when they were
made available. Note that WSJT-X does not "broadcast" UDP traffic,
broadcast has a very specific meaning with UDP, WSJT-X sends UDP
traffic to a server that is listening for it, so the server must
subscribe to the service port that WSJT-X instances send traffic
to.
You say the "mechanism as a whole" is
important, I don't understand that, surely it is the data that is
relevant. E.g. your work does not depend on how you commute, be it
by public transport, walking, bicyle, car, etc..
73
Bill G4WJS. On 11/05/2020 12:15, Jim Shorney wrote:
I knew someone would say that. :) It's not exactly what I was getting at. I was thinking about the mechanism as a whole rather than just the data format itself because obviously simply broadcasting in ADIF doesn't quite work. This the need for a meeting of minds to resolve the issue for all authors on both sides. It's not just a WSJT-X/ACL thing when you look at the big picture. 73 -Jim NU0C On Mon, 11 May 2020 12:06:59 +0100 "Bill Somerville" <g4wjs@...> wrote:Jim, the standardized data interchange protocol you ask for already exists, its called ADIF. Admittedly ADIF is a file based mechanism but WSJT-X already sends an ADIF file with one record for each logged QSO as a UDP datagram. Any application can choose to subscribe to that UDP message, they would have to ignore other messages in the WSJT-X UDP protocol but other than that it is not onerous to capture that information from WSJT-X. For example a primitive approach might be to ignore all messages that do not contain the <eoh> ADIF end of header marker. 73 Bill G4WJS. On 11/05/2020 12:00, Jim Shorney wrote:Relax, Laurie, no one is trying to force anyone to do anything. As I have said before, both developers are saying the same thing and they have good points. In a perfect world the authors of operating softwares and the authors of data handling softwares would get together and hammer out a common communications standard so anyone could talk to anyone and the users would win. What we will end up with in the real world will be software that only talks to specific other software without external help and the occasional harried developer who tries to support everything. It everyone is OK with that then that's fine too. 73 -Jim NU0C On Mon, 11 May 2020 14:02:18 +1000 "HamApps Support (VK3AMA)"<vk3ama.ham.apps@...> wrote:On 11/05/2020 4:05 am, Jim Shorney wrote:That's a little unfair. Scott's perspective is not unlike that of the WSJT-X developers. He worked to create a functional and useful API geared towards the features of his software that many DO support. He actively supports 100+ software packages (by his count) as well as keeping up with a constant stream of support questions via his support forum and private email. We should walk in the shoes of (all) of the developers before we criticize.The SIGNIFICANT difference between WSJT-X and ACLog is that WSJT-X is free software, ACLog is not. Any enhancements that increase ACLog usage directly affect the "Back-Pocket" of the ACLog developer, that is, he is financially better off. Scott's workload supporting 100+ packages is his own choice, with the financial rewards as a result, it is not a reason to push the WSJT-X team to code an ACLog specific interface. IMHO, it is ACLog that should be implementing an interface to WSJT-X not the other way round. If the ACLog users want direct WSJT-X integration, they should be pushing N3FJP, not the WSJT-X developers. There is no financial incentive for the WSJT-X developers to spend their precious development time (they have day jobs) implementing a one-off integration, while there is financial benefit to N3FJP if he went down that path. If Scott doesn't want to implement WSJT-X integration, that's his choice. JTAlert is there to fill the gap (Scott approached me directly to code the JTAlert/ACLog integration). Those users who are vocal about avoiding JTAlert (there choice) should not expect the WSJT-X team to spend time on code for their benefit when there is an existing alternative that bridges the gap between WSJT-X and ACLog. If users don't want to use JTAlert, they are free to develop their own solution or go "old school" and manually log the QSOs. de Laurie VK3AMA
|
|
|
|
locked
Re: WSJT-X to N3FJP AC Log Interface
I knew someone would say that. :) It's not exactly what I was getting at. I was thinking about the mechanism as a whole rather than just the data format itself because obviously simply broadcasting in ADIF doesn't quite work.
This the need for a meeting of minds to resolve the issue for all authors on both sides. It's not just a WSJT-X/ACL thing when you look at the big picture. 73 -Jim NU0C On Mon, 11 May 2020 12:06:59 +0100 "Bill Somerville" <g4wjs@...> wrote: Jim,
|
|
|
|
locked
Re: WSJT-X to N3FJP AC Log Interface
Jim,
the standardized data interchange
protocol you ask for already exists, its called ADIF. Admittedly
ADIF is a file based mechanism but WSJT-X already sends an ADIF
file with one record for each logged QSO as a UDP datagram. Any
application can choose to subscribe to that UDP message, they
would have to ignore other messages in the WSJT-X UDP protocol but
other than that it is not onerous to capture that information from
WSJT-X. For example a primitive approach might be to ignore all
messages that do not contain the <eoh> ADIF end of header
marker.
73
Bill G4WJS. On 11/05/2020 12:00, Jim Shorney wrote:
Relax, Laurie, no one is trying to force anyone to do anything. As I have said before, both developers are saying the same thing and they have good points. In a perfect world the authors of operating softwares and the authors of data handling softwares would get together and hammer out a common communications standard so anyone could talk to anyone and the users would win. What we will end up with in the real world will be software that only talks to specific other software without external help and the occasional harried developer who tries to support everything. It everyone is OK with that then that's fine too. 73 -Jim NU0C On Mon, 11 May 2020 14:02:18 +1000 "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...> wrote:On 11/05/2020 4:05 am, Jim Shorney wrote:That's a little unfair. Scott's perspective is not unlike that of the WSJT-X developers. He worked to create a functional and useful API geared towards the features of his software that many DO support. He actively supports 100+ software packages (by his count) as well as keeping up with a constant stream of support questions via his support forum and private email. We should walk in the shoes of (all) of the developers before we criticize.The SIGNIFICANT difference between WSJT-X and ACLog is that WSJT-X is free software, ACLog is not. Any enhancements that increase ACLog usage directly affect the "Back-Pocket" of the ACLog developer, that is, he is financially better off. Scott's workload supporting 100+ packages is his own choice, with the financial rewards as a result, it is not a reason to push the WSJT-X team to code an ACLog specific interface. IMHO, it is ACLog that should be implementing an interface to WSJT-X not the other way round. If the ACLog users want direct WSJT-X integration, they should be pushing N3FJP, not the WSJT-X developers. There is no financial incentive for the WSJT-X developers to spend their precious development time (they have day jobs) implementing a one-off integration, while there is financial benefit to N3FJP if he went down that path. If Scott doesn't want to implement WSJT-X integration, that's his choice. JTAlert is there to fill the gap (Scott approached me directly to code the JTAlert/ACLog integration). Those users who are vocal about avoiding JTAlert (there choice) should not expect the WSJT-X team to spend time on code for their benefit when there is an existing alternative that bridges the gap between WSJT-X and ACLog. If users don't want to use JTAlert, they are free to develop their own solution or go "old school" and manually log the QSOs. de Laurie VK3AMA
|
|
|
|
locked
Re: WSJT-X to N3FJP AC Log Interface
Relax, Laurie, no one is trying to force anyone to do anything. As I have said before, both developers are saying the same thing and they have good points. In a perfect world the authors of operating softwares and the authors of data handling softwares would get together and hammer out a common communications standard so anyone could talk to anyone and the users would win. What we will end up with in the real world will be software that only talks to specific other software without external help and the occasional harried developer who tries to support everything. It everyone is OK with that then that's fine too.
73 -Jim NU0C On Mon, 11 May 2020 14:02:18 +1000 "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...> wrote: On 11/05/2020 4:05 am, Jim Shorney wrote:That's a little unfair. Scott's perspective is not unlike that of the WSJT-X developers. He worked to create a functional and useful API geared towards the features of his software that many DO support. He actively supports 100+ software packages (by his count) as well as keeping up with a constant stream of support questions via his support forum and private email. We should walk in the shoes of (all) of the developers before we criticize.The SIGNIFICANT difference between WSJT-X and ACLog is that WSJT-X is
|
|
|
|
locked
Re: WSJT-X to N3FJP AC Log Interface
Please, let's not get into the "my software is better than yours" discussion. It is neither relevant nor productive. I have both your software and N3FJP on my Windows boxen and they each fill a niche.
73 -Jim NU0C On Sun, 10 May 2020 23:32:27 -0700 "Jim Brown" <k9yc@...> wrote: On 5/10/2020 9:02 PM, HamApps Support (VK3AMA) wrote:The SIGNIFICANT difference between WSJT-X and ACLog is that WSJT-X isAnd DXKeeper, part of the FREEWARE DXLab Suite of programs is a VERY
|
|
|