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
 


Join main@WSJTX.groups.io to automatically receive all group messages.