Date
1 - 20 of 24
Locked WSJT-X to N3FJP AC Log Interface
|
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 |
|
|
|
john ni0k
Works with HRD
toggle quoted message
Show quoted text
-de John NIØK Steve Wilson via groups.io wrote on 5/10/2020 9:56 AM: 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. :-) |
|
|
|
Joe Subich, W4TV
That's something Scott would need to do. WSJT-X already broadcasts
toggle quoted message
Show quoted text
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. :-) |
|
|
|
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 |
|
|
|
On 10/05/2020 15:56, 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. :-)Hi Steve, the WSJT-X development team is small and focused on weak signal communications modes, we have no wish to implement and support numerous different interfaces to the plethora of QSO logging applications. That would be an unnecessary drain on our resources, particularly where those applications do not run on all the platforms that WSJT-X is supported on. Instead we provide a documented protocol that other applications can interoperate with, that protocol provides more than just logged QSO details, it also provides near real-time information of decodes printed, and the status of the WSJT-X user interface. It also provides messages for external applications to initiate QSOs, highlight text in the WSJT-X Band Activity window, and change some user interface controls in WSJT-X. The protocol, when implemented properly, also allows multiple applications to interoperate with any number of WSJT-X instances, all running concurrently. Where the authors of logging, or other third party applications, do not have the inclination or resources to implement the WSJT-X UDP Message Protocol then there is space for other developers to implement bridging applications to fill that gap. An excellent example of that, although not the only one, is the JTAlert application by Laurie, VK3AMA. So that begs the question: what is wrong with the use of JTAlert to bridge between WSJT-X and AC Log, and have you asked Laurie if such deficiencies can be addressed within JTAlert? 73 Bill G4WJS. |
|
|
|
Dave Garber <ve3wej@...>
if you would rather not use jtalert, then gridtracker will listen on a udp port, and log to a few different logging programs, as selected. just another option for you Dave Garber VE3WEJ / VE3IE On Sun, May 10, 2020 at 10:56 AM Steve Wilson via groups.io <steve_wilson=yahoo.com@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. :-) |
|
|
|
Per Scott's site, that is up to WSJT-X to support, not Scott. That is why I posted here.
|
|
|
|
Joe Subich, W4TV
Scott has the typical "not invented here" syndrome.
toggle quoted message
Show quoted text
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. |
|
|
|
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 |
|
|
|
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 |
|
|
|
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
|
|
|
|
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. |
|
|
|
Jim Cooper
On 10 May 2020 at 13:05, Jim Shorney wrote:
We should walk in the shoes of (all) of theWe 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 ... |
|
|
|
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 |
|
|
|
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. 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. :-) |
|
|
|
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. 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: |
|
|
|
HamApps Support (VK3AMA) <vk3ama.ham.apps@...>
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
