Date   

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


locked Re: WSJT-X to N3FJP AC Log Interface

Jim Brown
 

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: WSJT-X to N3FJP AC Log Interface

JTAlert Support (VK3AMA)
 

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

neil_zampella <neilz@...>
 

If the WSJT-X developers add an interface for a single logger, they'd have add interfaces for almost every logger.   I'd rather see them continue to improve the existing modes, and add modes as they are doing, rather than make an already complex program even more complex.

Neil, KN3ILZ

On 5/10/2020 11:53 AM, Jim Shorney wrote:
That would be nice but I would understand if Scott does not add this. He already has a perfectly functional API system, the WSJT-X developers just choose not to support it. Only intensive lobbying by ACL users seems likely to change this and with most ops stuck on JTAlert this has not been happening.

An alternative is to use the Python script created by W3DJS, https://github.com/dslotter/wsjtx_to_n3fjp/ . It works great talking cross platform from Linux to Windows, but of course Windows only users would need to install Python.

https://www.python.org/downloads/windows/

73

-Jim
NU0C

On Sun, 10 May 2020 11:41:38 -0400
"Joe Subich, W4TV" <lists@...> wrote:

That's something Scott would need to do.  WSJT-X already broadcasts
the information (using a standard UDP format) - Scott needs to listen
on the appropriate port and log the data when he sees the "Log"
packet.

73,

    ... Joe, W4TV


On 2020-05-10 10:56 AM, Steve Wilson via groups.io wrote:
I know that N3FJP can be interfaced to WSJT-X via JTAlert, but I'd like to toss out my vote for a direct interface. :-)

73!

Steve  K6WW




      

    

Virus-free. www.avg.com


locked Re: FT8 Logging Problem!

Steve Kavanagh
 

I guess I wasn't clear enough, Reino....they sent a signal report as the first transmission....there is no signal report in NA VHF Contest mode.

73,
Steve


locked Re: WSJT-X to N3FJP AC Log Interface

neil_zampella <neilz@...>
 

That would be up to the log program developer, as WSJT-X just offers the UDP connection and that's all.   Whereas  JT-Alert will actually update and read most logger databases directly either using the logger's built-in 'hooks' or direct database insert.

Neil, KN3ILZ

On 5/10/2020 10:56 AM, Steve Wilson via groups.io wrote:
I know that N3FJP can be interfaced to WSJT-X via JTAlert, but I'd like to toss out my vote for a direct interface. :-)

73!

Steve  K6WW

    

Virus-free. www.avg.com


locked Re: WSJT-X to N3FJP AC Log Interface

Jim Shorney
 

Which indeed I have. I have been a satisfied user of N3FJP sofwares for around 20 years. It meets my needs and there are workarounds for minor frills that I don't "need". Do not misunderstand, I am not complaining about a lack of support from either side. As has been pointed out there are multiple solutions for the minor logging issue. Such as it is, both ACL and WSTJ-X both have functions that I do not need, but the ones that I do use serve me well.

73

-Jim
NU0C

On Sun, 10 May 2020 15:49:21 -0400
"Jim Cooper" <JTalert@...> wrote:

We should also pick our software packages
based on the functions they provide vs. the
functions that we want.


locked Re: FT8 Logging Problem!

Reino Talarmo
 

Roger,
That's life. By the way do you have means how to get the grid from a special call station? Of course you don't need to work those at all, hi!
73, Reino OH3mA

Subject: Re: [WSJTX] FT8 Logging Problem!
And a surprising number of them send RRR and later 73 so they're not actually saving a cycle.
I like to receive the grid so I treat them as in incomplete QSO.
Roger G4HZA
On 10/05/2020 16:46, Reino Talarmo wrote:
Hi Steve,

Sending message 2 as the first message does not indicate a contest mode at all. Those users just want to save one timeslot.

Reino OH3mA



From: WSJTX@groups.io [mailto:WSJTX@groups.io] On Behalf Of Steve
Kavanagh via groups.io
Sent: 10. toukokuuta 2020 17:35
To: WSJTX@groups.io
Subject: Re: [WSJTX] FT8 Logging Problem!



I had one case where a station (not in contest mode) called me using message 2, so he never sent his grid. As I understand it, WSJT-X is supposed to switch the non-contest-mode station into contest mode when a contest-mode exchange is received, but this combination of events didn't produce a valid contest QSO. Not sure if there is a software fix.

I think those of us who are interested in VHF contests need to put on a big educational push so that those VHFers who are not particularly interested in contests learn about contest modes and how and when to use them....they only give up a signal report. I think the same is true of HF digital contesting, but I have spent less time at that and don't have as much of a feel for how many contest-mode compatibility problems exist there.

73,
Steve VE3SMA





locked Re: WSJT-X to N3FJP AC Log Interface

Jim Cooper
 

On 10 May 2020 at 13:05, Jim Shorney wrote:

We should walk in the shoes of (all) of the
developers before we criticize
We should also pick our software packages
based on the functions they provide vs. the
functions that we want.

Not smart, if you need a truck, to go buy
a mini-Cooper ... also not wise to ask the
mini manufacturer to adapt their design
so it can be a truck.

If you don't like what any of these ham
software packages do, you can always ask
for a refund ...


locked Re: Curved Line in Waterfall

Dave (NK7Z)
 

Hi,

It looks like a carrier started at the bottom of your screen, (or you came upon it at that point), at around 1230 Hz, higher than your dial frequency, and over the period of one minute moved upwards in frequency. This assumes the graticule marks are 100 Hz apart, and 15 seconds apart on the vertical.

This could be pretty much anything, heater, thermostat, controller for stoves, etc... All you really know is some signal moved up in frequency across a one minute period.

73, and thanks,
Dave (NK7Z)
https://www.nk7z.net
ARRL Volunteer Examiner
ARRL Technical Specialist
ARRL Asst. Director, NW Division, Technical Resources

On 5/10/20 9:17 AM, Brian Wilkins wrote:
I was listening on 17m today. What causes this curved line in the waterfall?
 Link to picture
https://imgur.com/alQtCKV
--
Brian Wilkins
KO4AQF


locked Re: WSJT-X to N3FJP AC Log Interface

Jim Shorney
 

I can appreciate that. I started out with paper logging as well in the mid 70s. I still do a lot manually that today's hams insist on using computer control for, but for logging I find that the software communication improves my accuracy. Yes, I make typos! I always confirm what was logged of course. The software load here is pretty stable, once I set it all up it just keeps running. Of course most of the critical stuff runs in Linux. All bets are off with Windows. What I do see from the volume of support emails in various forums is that the real time sink is keeping CAT running. :)

73

-Jim
NU0C

On Sun, 10 May 2020 18:22:04 +0000
"Chuck K4RGN" <K4rgn@...> wrote:

Personally I choose to run N3FJP ACL independently of WSJT-X (and of fldigi too). It’s little effort to type in the log entry, and it increases the sense of actively operating my station. Also, I’d rather spend my time on other projects than installing even more shack software. I confess that I began with pen and paper logbooks in 1970. But with 7000+ FT8 QSOs I haven’t tired of manual logging yet.

73 Chuck K4RGN


locked Re: WSJT-X to N3FJP AC Log Interface

Chuck K4RGN
 

Personally I choose to run N3FJP ACL independently of WSJT-X (and of fldigi too). It’s little effort to type in the log entry, and it increases the sense of actively operating my station. Also, I’d rather spend my time on other projects than installing even more shack software. I confess that I began with pen and paper logbooks in 1970. But with 7000+ FT8 QSOs I haven’t tired of manual logging yet. 

73 Chuck K4RGN


locked Re: WSJT-X to N3FJP AC Log Interface

Jim Shorney
 

On Sun, 10 May 2020 13:40:27 -0400
"Joe Subich, W4TV" <lists@...> wrote:

Scott has the typical "not invented here" syndrome.
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.

73

-Jim
NU0C


locked Re: WSJT-X to N3FJP AC Log Interface

Jim Shorney
 

On Sun, 10 May 2020 10:24:23 -0700
"Steve Wilson via groups.io" <steve_wilson@...> wrote:

Per Scott's site, that is up to WSJT-X to support, not Scott. That is why I posted here.
It is good that you asked, and I appreciate the additional perspective that G4WJS provided. We have two sides with very busy developers who have constraints on their time. They both make valid points and are really saying pretty much the same thing. Which is OK. There are always workarounds.

Personally, I don't like bridge programs. But others do and that is a good alternative for them. I have always run WSJT-X under Linux. It happily talks to SpotCollector running on a Win7 box. The W3DJS Python script runs quietly in the background on the Linux machine and just does its job. I have tested it both talking to ACL on the Win7 box and ACL under WinXP running in a VM on the Linux machine. There are many ways to handle this.

73

-Jim
NU0C


locked Re: WSJT-X to N3FJP AC Log Interface

Joe Subich, W4TV
 

Scott has the typical "not invented here" syndrome.

The WSJT-X developers have chosen to develop/support a generic
UDP broadcast format that is supported by *several* logging
programs. If Scott chooses not to support that interface
already used by multiple applications, that is between him
and his users. There is/should be no expectation that the
WSJTX developers will write a unique interface to support
Scott's proprietary API.

If you need something that supports Scott's API, use JT-Alert.

If you want avoid JT-Alert, tell Scott to get with the program.

73,

... Joe, W4TV

On 2020-05-10 1:24 PM, Steve Wilson via groups.io wrote:
Per Scott's site, that is up to WSJT-X to support, not Scott. That is why I posted here.


locked Re: FT8 Logging Problem!

 

I wondered why people didn't use the "proper sequence". I like to plot my contacts on a map - I use an API available from DxAtlas, and the centre of a prefix area is not good enough. I also download contact details from eQSL and LotW which a lot of times updates gridsquares to the 6 character version.

73 Phil GM3ZZA

On 10 May 2020 16:46, Reino Talarmo <reino.talarmo@...> wrote:

Hi Steve,

Sending message 2 as the first message does not indicate a contest mode at all. Those users just want to save one timeslot.

Reino OH3mA

 

From: WSJTX@groups.io [mailto:WSJTX@groups.io] On Behalf Of Steve Kavanagh via groups.io
Sent: 10. toukokuuta 2020 17:35
To: WSJTX@groups.io
Subject: Re: [WSJTX] FT8 Logging Problem!

 

I had one case where a station (not in contest mode) called me using message 2, so he never sent his grid.  As I understand it, WSJT-X is supposed to switch the non-contest-mode station into contest mode when a contest-mode exchange is received, but this combination of events didn't produce a valid contest QSO.  Not sure if there is a software fix.

I think those of us who are interested in VHF contests need to put on a big educational push so that those VHFers who are not particularly interested in contests learn about contest modes and how and when to use them....they only give up a signal report.  I think the same is true of HF digital contesting, but I have spent less time at that and don't have as much of a feel for how many contest-mode compatibility problems exist there.

73,
Steve VE3SMA



--
73 Phil GM3ZZA