My apologies to all for my reply coming with some extra snark. Seriously, I do think Ham Radio software does need to adopt some modern architecture principles. In this context the WSJT-X team should be focused on weak-signal communication protocol processing. Issues such as logging should be left to others to focus on, and there should be a well defined complete API for applications to interface to them.
Absent the Ham Radio logging community coming up with such an API, some application should emerge to bridge the gap, with a well defined API. JTAlert comes very, very, close to this. Issues such as TCP vs UDP should nearly disappear at this level. I think there is a legitimate discussion to be had about if logging a QSO is something that needs to be reliable or fast. I would advocate for reliable, and my answer is thus TCP. Standards have emerged, such as REST, for doing TCP APIs in a uniform manner and libraries exist in nearly every programming language in use today. Hopefully this is with less snark. Thanks. Robert. AD6I. On Mon, Jun 29, 2020, at 6:07 PM, Robert A. Klahn (AD6I) wrote: > IMHO, this sort of thing is often better implemented as a program emulating > the client's supported protocol. That program can then communicate with > whatever downstream service is needed, in its preferred protocol. > > Even better is to apply some well defined modern application solution > instead, like REST. But this is Ham Radio, we cant do that. > > Regardless, this should not be a particular logging software problem, a > WSJT-X problem, or even operating system specific problem. > > Thanks. Robert. AD6I. > > On Mon, Jun 29, 2020, at 5:53 PM, Terry Estes wrote: >> Many other amateur radio stations use the N3FJP Logging Software, primarily >> for logging ARRL Field Day and Winter Field Day contests. >> The addition of Field Day exchange capabilities to WSJT-X has made the use >> during FD of FT-8 a major improvement and has increased its use for FD. >> Many stations now utilize Raspberry Pi computers running WSJT-X under >> various forms of Linux. (Mine is Raspbian Stretch) >> N3FJP unfortunately only runs on Windows based computers. >> Herein lies the problem - A way to export the WSJT-X log entries (packets) >> to the N3FJP software. >> WSJT-X appears to utilize UDP communications with N1MM Logging Software. >> N3FJP utilizes TCP communications to import the logging packets from other >> communications packages such as FLDigi. N3FJP acts as a TCP Server on a >> Windows machine and FLDigi as a TCP Client on a Linux machine, >> interconnected either by Ethernet cable or by WiFi. >> >> Proposal: It would make things appear seamless if WSJT-X could also act as a >> TCP Client, running on the Linux machine, sending the appropriate logging >> packets to the N3FJP Server on the Windows machine. >> The FLDigi implementation sends the callsign to N3FJP as it is first >> collected by FLDigi, allowing N3FJP to check for duplication (DUPEs). >> As long as WSJT-X is checking for dupes, it may not be necessary to send the >> call across prior to completion of the FD exchanges. >> WSJT-X can send the complete contact log information across, in proper >> order, to N3FJP at the completion of the contact. >> Any and all information about the N3FJP software is provided by its >> creator/owner to help further the interconnection capability and utilization >> of his software. >> >> Thanks for your consideration, >> >> Terry Estes, W4ZQ >> w...@arrl.net >> >> _______________________________________________ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
