Date   

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:

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?
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

Bill Somerville
 

On 11/05/2020 16:26, Bill wrote:

I know I'm on the wrong forum, but I don't see how to post on the JTAlert forum.

My question is simple and it has to do with the "All.txt" file.

It is getting very large and would like to know, what happens, if anything if I erase it ?

Bill
K2WH
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)

Bob G8HGN
 

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:

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?
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.

My question is simple and it has to do with the "All.txt" file.

It is getting very large and would like to know, what happens, if anything if I erase it ?

Bill
K2WH


locked Re: Linux Serial Port Issues

Bill Somerville
 

On 11/05/2020 15:30, Mark Erbaugh wrote:

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 have
the 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

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
Bill
G4WJS.


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 have
the 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

Joe
 

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

WB5JJJ - George
 
Edited

Just installed v2.2.0 rc1 and found that the Band Activity window has a "new normal" that I find awkward.  

After the first decode period at 11.8s, the window works exactly as before, but at the conconsulsion of ALL decodes at ~15s, it resets the display to show only those last decoded.  You must scroll up to see the original (larger) list of decodes.  And, if there are just a few decodes in the first pass and the second pass has none, the BA window is now blank as everything is on the previous screen and scrolled up.

Temporary solution under Settings is to uncheck "Start new period decodes at top".  Now you have a continuous flow of decodes (old way).  I really enjoyed the start new decodes with the overflow off the bottom of the BA window, a much smaller list typically.  I have part of the monitor display real estate taken up  by JTAlert with just 3 lines of decodes, docked above WSJTx.  

--
73's
George - WB5JJJ


locked Re: Linux Serial Port Issues

Karza
 

Hi Mark,

On 11.5.2020 15.41, Mark Erbaugh wrote:
..

I did the “usermod -a -G dialout pi” to add my local user (pi) to the dialout group for access to the serial ports.

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?

 

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.

What exactly does not work? How did you test?

 

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.

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

Bill Somerville
 

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 KJ4VPI
Hi 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

Bill Somerville
 

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

Jim Shorney
 

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

Bill Somerville
 

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

Jim Shorney
 

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

Jim Shorney
 

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 is
free software, ACLog is not.
And DXKeeper, part of the FREEWARE DXLab Suite of programs is a VERY
capable logger, far superior to ACLog. The other elements of the suite
include rig control, a spot collection presented based on your needs
(all bands, all modes), a front end for several excellent RTTY programs
that can be set for dual decoders. I've been using it for 17 years.

73, Jim K9YC


locked Re: FT8 Logging Problem!

Reino Talarmo
 

Steve,

Now I read the whole chain and understood your point. Perhaps they did not even wanted participate the contest, but only wished to get a QSO with you? I have had that kind of ‘nuisance’ as those contact do not count as they will not send their log in and of course it is not a valid contest QSO due to the missing locator, hi!

73, Reino OH3mA