Topics

WW and JT modes

Gilbert Baron W0MN
 

Any chance that JT modes get added to WW? Psk is nearly dead. I realize there may be licensing problems.

 

 

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

 

Robie
 

Gilbert,

JTAlertX allows direct logging of contacts into DXKeeper. This feature is the one I’d most want from the integration.  It’s available now.

Robie - AJ4F 

On Dec 17, 2017, at 12:33, 'Gilbert Baron' w0mn00@... [dxlab] <dxlab@...> wrote:

 

Any chance that JT modes get added to WW? Psk is nearly dead. I realize there may be licensing problems.

 

 

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

 

Gilbert Baron W0MN
 

I know that exists but it is much more convenient and easier to use one set of applications for everything. OTOH I realize it may not be a good use of resources for something that is available another way.

I am spoiled by DXLabs since configuration is vastly easier than WSJT and N1MM and all of the rest.

 

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

 

From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, December 17, 2017 13:29
To: dxlab@...
Subject: Re: [dxlab] WW and JT modes

 

 

Gilbert,

 

JTAlertX allows direct logging of contacts into DXKeeper. This feature is the one I’d most want from the integration.  It’s available now.

Robie - AJ4F 


On Dec 17, 2017, at 12:33, 'Gilbert Baron' w0mn00@... [dxlab] <dxlab@...> wrote:

 

Any chance that JT modes get added to WW? Psk is nearly dead. I realize there may be licensing problems.

 

 

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

 

Robie
 

Ok - good luck!

Robie

On Dec 17, 2017, at 13:37, 'Gilbert Baron' w0mn00@... [dxlab] <dxlab@...> wrote:

 

I know that exists but it is much more convenient and easier to use one set of applications for everything. OTOH I realize it may not be a good use of resources for something that is available another way.

I am spoiled by DXLabs since configuration is vastly easier than WSJT and N1MM and all of the rest.

 

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

 

From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, December 17, 2017 13:29
To: dxlab@...
Subject: Re: [dxlab] WW and JT modes

 

 

Gilbert,

 

JTAlertX allows direct logging of contacts into DXKeeper. This feature is the one I’d most want from the integration.  It’s available now.

Robie - AJ4F 


On Dec 17, 2017, at 12:33, 'Gilbert Baron' w0mn00@... [dxlab] <dxlab@...> wrote:

 

Any chance that JT modes get added to WW? Psk is nearly dead. I realize there may be licensing problems.

 

 

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

 

g4wjs
 

Hi Gilbert,

there are no licensing issues, the JT mode protocols are in the public domain and there is no barrier, other than competence and time, to developers writing their own applications that encode and decode these modes. It is an unfortunate fact that the current alternative implementations are knock offs using the source code of WSJT and WSJT-X, usually without even asking the permission of the original authors. They can do this within the terms of the GPL license that those programs are developed under so long as they themselves also release strictly under the same license but nothing stops a closed source developer writing encoders and decoders so long as they do not refer to the existing implementations in any way when implementing their alternative (https://en.wikipedia.org/wiki/Clean_room_design).

73
Bill
G4WJS..

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, December 17, 2017 1:33 PM
To: dxlab@...
Subject: [dxlab] WW and JT modes

Any chance that JT modes get added to WW? Psk is nearly dead.

JTAlert and WSJT-X interoperate well with the DXLab Suite. It would be nice of JTAlert were extended to directly reference the
award progress tables in the current log, but I certainly understand that Laurie VK3AMA has a lot on his plate, and that an
enhancement specific to one logging application may not rise to the necessary priority level.

73,

Dave, AA6YQ

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, December 17, 2017 3:09 PM
To: dxlab@...
Subject: [dxlab] Re: WW and JT modes

there are no licensing issues, the JT mode protocols are in the public domain and there is no barrier, other than competence and time, to developers writing their own applications that encode and decode these modes. It is an unfortunate fact that the current alternative implementations are knock offs using the source code of WSJT and WSJT-X, usually without even asking the permission of the original authors. They can do this within the terms of the GPL license that those programs are developed under so long as they themselves also release strictly under the same license but nothing stops a closed source developer writing encoders and decoders so long as they do not refer to the existing implementations in any way when implementing their alternative (https://en.wikipedia.org/wiki/Clean_room_design).

If I were to take a "next step", it would likely be to extend WinWarbler to directly interoperate with WSJT-X so that a "Broadband Decode" window showing all active JT-mode stations could be presented, color-coded by need and LoTW/eQSL participation. Doing this would in no way violate GPL, but out of courtesy I would still seek approval from the K1JT team before proceeding.
73,

Dave, AA6YQ

ghassan chammas
 

That would be driving the dxlab suite to a luxury version. However i feel that in its current version ww is super
Ghassan



Sent from Samsung tablet.

-------- Original message --------
From: "'Dave AA6YQ' aa6yq@... [dxlab]" <dxlab@...>
Date: 17/12/2017 23:03 (GMT+02:00)
To: dxlab@...
Subject: RE: [dxlab] Re: WW and JT modes

 

>>>AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, December 17, 2017 3:09 PM
To: dxlab@...
Subject: [dxlab] Re: WW and JT modes

there are no licensing issues, the JT mode protocols are in the public domain and there is no barrier, other than competence and time, to developers writing their own applications that encode and decode these modes. It is an unfortunate fact that the current alternative implementations are knock offs using the source code of WSJT and WSJT-X, usually without even asking the permission of the original authors. They can do this within the terms of the GPL license that those programs are developed under so long as they themselves also release strictly under the same license but nothing stops a closed source developer writing encoders and decoders so long as they do not refer to the existing implementations in any way when implementing their alternative (https://en.wikipedia.org/wiki/Clean_room_design).

>>>If I were to take a "next step", it would likely be to extend WinWarbler to directly interoperate with WSJT-X so that a "Broadband Decode" window showing all active JT-mode stations could be presented, color-coded by need and LoTW/eQSL participation. Doing this would in no way violate GPL, but out of courtesy I would still seek approval from the K1JT team before proceeding.

73,

Dave, AA6YQ

d_ziolkowski
 

You can also continue to use Commander for CAT control by selecting Commander as the radio inn WSJTX.

l found setting up WSJTX -JTAlert to work with DXLAbs to be quite painless, and operation has been flawless.

Dan  KC2STA

 

On Sun, Dec 17, 2017 at 2:28 PM, Robie Elms ruler55@... [dxlab] <dxlab@...> wrote:
 

Gilbert,


JTAlertX allows direct logging of contacts into DXKeeper. This feature is the one I’d most want from the integration.  It’s available now.

Robie - AJ4F 

On Dec 17, 2017, at 12:33, 'Gilbert Baron' w0mn00@... [dxlab] <dxlab@...> wrote:

 

Any chance that JT modes get added to WW? Psk is nearly dead. I realize there may be licensing problems.

 

 

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop

 




--
Dan Ziolkowski KC2STA
SKCC #4290T
Ubuntu LINUX

Joe Subich, W4TV
 

If I were to take a "next step", it would likely be to extend WinWarbler to directly interoperate with WSJT-X so that a "Broadband Decode" window showing all active JT-mode stations could be presented, color-coded by need and LoTW/eQSL participation.
Which is exactly what JTAlert does already.

73,

... Joe, W4TV


On 12/17/2017 4:03 PM, 'Dave AA6YQ' @AA6YQ [dxlab] wrote:
AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, December 17, 2017 3:09 PM
To: dxlab@...
Subject: [dxlab] Re: WW and JT modes
there are no licensing issues, the JT mode protocols are in the public domain and there is no barrier, other than competence and time, to developers writing their own applications that encode and decode these modes. It is an unfortunate fact that the current alternative implementations are knock offs using the source code of WSJT and WSJT-X, usually without even asking the permission of the original authors. They can do this within the terms of the GPL license that those programs are developed under so long as they themselves also release strictly under the same license but nothing stops a closed source developer writing encoders and decoders so long as they do not refer to the existing implementations in any way when implementing their alternative (https://en.wikipedia.org/wiki/Clean_room_design).

If I were to take a "next step", it would likely be to extend WinWarbler to directly interoperate with WSJT-X so that a "Broadband Decode" window showing all active JT-mode stations could be presented, color-coded by need and LoTW/eQSL participation. Doing this would in no way violate GPL, but out of courtesy I would still seek approval from the K1JT team before proceeding.
73,
Dave, AA6YQ
------------------------------------
Posted by: "Dave AA6YQ" <@AA6YQ>
------------------------------------
------------------------------------
Yahoo Groups Links

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, December 17, 2017 8:00 PM
To: dxlab@...
Subject: Re: [dxlab] Re: WW and JT modes


If I were to take a "next step", it would likely be to extend
WinWarbler to directly interoperate with WSJT-X so that a "Broadband
Decode" window showing all active JT-mode stations could be presented,
color-coded by need and LoTW/eQSL participation.
Which is exactly what JTAlert does already.

Does JTAlert now color-code for DXCC, IOTA, Marathon, VUCC, WAS, WAZ, and WPX need based on progress information maintained in DXKeeper's log file (and thus not requiring the user to manually update filters after logging a QSO)?
If not, I'd love to see it be extended to do so. In the mean time, my plate is quite full with other enhancements.
73,

Dave, AA6YQ

iain macdonnell - N6ML
 

On Sun, Dec 17, 2017 at 5:40 PM, 'Dave AA6YQ' @AA6YQ
[dxlab] <dxlab@...> wrote:



AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, December 17, 2017 8:00 PM
To: dxlab@...
Subject: Re: [dxlab] Re: WW and JT modes

If I were to take a "next step", it would likely be to extend
WinWarbler to directly interoperate with WSJT-X so that a "Broadband
Decode" window showing all active JT-mode stations could be presented,
color-coded by need and LoTW/eQSL participation.
Which is exactly what JTAlert does already.

Does JTAlert now color-code for DXCC, IOTA, Marathon, VUCC, WAS, WAZ, and WPX need based on progress information maintained in DXKeeper's log file (and thus not requiring the user to manually update filters after logging a QSO)?
I don't think it can do that (yet?)... but it can post local spots to
SpotCollector, and SpotCollector can determine (and display / alert
on) "neededness". It would be nice to be able to double-click on a
"needed" callsign to initiate a QSO, though...

73,

~iain / N6ML

Joe Subich, W4TV
 

73,

... Joe, W4TV

Does JTAlert now color-code for DXCC, IOTA, Marathon, VUCC, WAS,
WAZ, and WPX need based on progress information maintained in
DXKeeper's log file (and thus not requiring the user to manually
update filters after logging a QSO)?
No. However, JTAlert does alert (for those awards supported) based on
its own (internal) "needs" tables. The internal tables are updated
manually (as needed) by instructing JTAlert to scan the DXKeeper log
and update the tables. The time to update tables is comparable to
DXKeeper's "Recompute" and need be done only every few days (typically,
from my experience, only when cards/LotW confirmations have been
processed).

JTAlert currently supports DXCC, WAS, WAC, WAZ, VUCC (6m & 2M only),
WPX, and Marathon. It can also be used for the ARRL Grid Chase (it
will tack grids on a per band basis). The only award you list that
is not currently supported is IOTA.

73,

... Joe, W4TV


On 12/17/2017 8:40 PM, 'Dave AA6YQ' @AA6YQ [dxlab] wrote:
AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Sunday, December 17, 2017 8:00 PM
To: dxlab@...
Subject: Re: [dxlab] Re: WW and JT modes

If I were to take a "next step", it would likely be to extend
WinWarbler to directly interoperate with WSJT-X so that a "Broadband
Decode" window showing all active JT-mode stations could be presented,
color-coded by need and LoTW/eQSL participation.
Which is exactly what JTAlert does already.

Does JTAlert now color-code for DXCC, IOTA, Marathon, VUCC, WAS, WAZ, and WPX need based on progress information maintained in DXKeeper's log file (and thus not requiring the user to manually update filters after logging a QSO)?
If not, I'd love to see it be extended to do so. In the mean time, my plate is quite full with other enhancements.
73,
Dave, AA6YQ
------------------------------------
Posted by: "Dave AA6YQ" <@AA6YQ>
------------------------------------
------------------------------------
Yahoo Groups Links

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Monday, December 18, 2017 4:15 PM
To: dxlab@...
Subject: Re: [dxlab] Re: WW and JT modes

Does JTAlert now color-code for DXCC, IOTA, Marathon, VUCC, WAS, WAZ,
and WPX need based on progress information maintained in DXKeeper's
log file (and thus not requiring the user to manually update filters
after logging a QSO)?
No. However, JTAlert does alert (for those awards supported) based on its own (internal) "needs" tables. The internal tables are updated manually (as needed) by instructing JTAlert to scan the DXKeeper log
and update the tables. The time to update tables is comparable to
DXKeeper's "Recompute" and need be done only every few days (typically, from my experience, only when cards/LotW confirmations have been processed).

No Recompute operation is required in DXKeeper or SpotCollector when a new QSO is logged; all of the progress tables are updated instantaneously, so SpotCollector and Commander immediately update their presentations of "needed active DX".
A Recompute is only required when you delete or modify a logged QSO, and even then DXKeeper performs a selective Recompute based on the awards you're pursuing. For example, if you're only pursuing DXCC, then deleting a logged QSO with P5 will only recompute DXCC award progress for P5, limiting the logged QSOs to be scanned. A "Recompute everything" operation is only required after changing your award objectives, or when recovering from an error or defect.
My hope is that Laurie VK3AMA will find the time to update JTAlert to utilize the progress tables that DXKeeper maintains.
73,

Dave, AA6YQ

Joe Subich, W4TV
 

No Recompute operation is required in DXKeeper or SpotCollector when a new QSO is logged; all of the progress tables are updated instantaneously, so SpotCollector and Commander immediately update their presentations of "needed active DX".
I'm aware that DXKeeper generally updates its "needed" tables in real
time. However, JTAlert does not use DXKeeper's "needed" tables *nor*
*would I expect it to support DXKeeper's 'needed' tables*.

JTAlert supports five different logging options. Scanning the log and
building JTAlert's own internal "needs" list is a generalized support
for all of the logging options. Since the internal needs list does
not need to be updated until a needed "counter" is confirmed, the need
for manual scanning and rebuilding the internal needs list is minimal.

There is little to be gained with automatically updating the "needs"
list in rel time since JTAlert can be configured to alert on unworked
or unconfirmed but does not provide "dual level" alerts.

73,

... Joe, W4TV


On 12/18/2017 5:25 PM, 'Dave AA6YQ' @AA6YQ [dxlab] wrote:
AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Monday, December 18, 2017 4:15 PM
To: dxlab@...
Subject: Re: [dxlab] Re: WW and JT modes

Does JTAlert now color-code for DXCC, IOTA, Marathon, VUCC, WAS, WAZ,
and WPX need based on progress information maintained in DXKeeper's
log file (and thus not requiring the user to manually update filters
after logging a QSO)?
No. However, JTAlert does alert (for those awards supported) based on its own (internal) "needs" tables. The internal tables are updated manually (as needed) by instructing JTAlert to scan the DXKeeper log
and update the tables. The time to update tables is comparable to
DXKeeper's "Recompute" and need be done only every few days (typically, from my experience, only when cards/LotW confirmations have been processed).

No Recompute operation is required in DXKeeper or SpotCollector when a new QSO is logged; all of the progress tables are updated instantaneously, so SpotCollector and Commander immediately update their presentations of "needed active DX".
A Recompute is only required when you delete or modify a logged QSO, and even then DXKeeper performs a selective Recompute based on the awards you're pursuing. For example, if you're only pursuing DXCC, then deleting a logged QSO with P5 will only recompute DXCC award progress for P5, limiting the logged QSOs to be scanned. A "Recompute everything" operation is only required after changing your award objectives, or when recovering from an error or defect.
My hope is that Laurie VK3AMA will find the time to update JTAlert to utilize the progress tables that DXKeeper maintains.
73,
Dave, AA6YQ
------------------------------------
Posted by: "Dave AA6YQ" <@AA6YQ>
------------------------------------
------------------------------------
Yahoo Groups Links

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Monday, December 18, 2017 9:35 PM
To: dxlab@...
Subject: Re: [dxlab] Re: WW and JT modes


No Recompute operation is required in DXKeeper or SpotCollector when a
new QSO is logged; all of the progress tables are updated
instantaneously, so SpotCollector and Commander immediately update
their presentations of "needed active DX".
I'm aware that DXKeeper generally updates its "needed" tables in real time. However, JTAlert does not use DXKeeper's "needed" tables *nor* *would I expect it to support DXKeeper's 'needed' tables*.

JTAlert supports five different logging options. Scanning the log and building JTAlert's own internal "needs" list is a generalized support for all of the logging options. Since the internal needs list does not need to be updated until a needed "counter" is confirmed, the need for manual scanning and rebuilding the internal needs list is minimal.

There is little to be gained with automatically updating the "needs"
list in rel time since JTAlert can be configured to alert on unworked or unconfirmed but does not provide "dual level" alerts.

I strongly disagree. Having SpotCollector immediately update its display of what's needed when I log a QSO with a previously-needed station is enormously beneficial, particularly in a target-rich environment. That includes making the distinction between a station I have already worked (and thus need not work again) and an unworked station associated with a worked-but-unconfirmed counter (which I should attempt to work).
73,

Dave, AA6YQ

Joe Subich, W4TV
 

I strongly disagree. Having SpotCollector immediately update its display of what's needed when I log a QSO with a previously-needed station is enormously beneficial, particularly in a target-rich environment. That includes making the distinction between a station
I have already worked (and thus need not work again) and an unworked station associated with a worked-but-unconfirmed counter (which I should attempt to work).
With WSJT-X/JTAert logging to DXKeeper, SpotCollector *does* immediately
update *its* needed display. It is only JTAlert that doesn't update its
need list and alerts immediately.

Typically, FT8/JT9/JT65 is not a target-rich environment and but since
FT8/JT9/JT65 users are some of the most active users of LotW one has
most often confirmed or not worked a given "counter".

73,

... Joe, W4TV


On 12/18/2017 9:45 PM, 'Dave AA6YQ' @AA6YQ [dxlab] wrote:
AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Monday, December 18, 2017 9:35 PM
To: dxlab@...
Subject: Re: [dxlab] Re: WW and JT modes

No Recompute operation is required in DXKeeper or SpotCollector when a
new QSO is logged; all of the progress tables are updated
instantaneously, so SpotCollector and Commander immediately update
their presentations of "needed active DX".
I'm aware that DXKeeper generally updates its "needed" tables in real time. However, JTAlert does not use DXKeeper's "needed" tables *nor* *would I expect it to support DXKeeper's 'needed' tables*.
JTAlert supports five different logging options. Scanning the log and building JTAlert's own internal "needs" list is a generalized support for all of the logging options. Since the internal needs list does not need to be updated until a needed "counter" is confirmed, the need for manual scanning and rebuilding the internal needs list is minimal.
There is little to be gained with automatically updating the "needs"
list in rel time since JTAlert can be configured to alert on unworked or unconfirmed but does not provide "dual level" alerts.

I strongly disagree. Having SpotCollector immediately update its display of what's needed when I log a QSO with a previously-needed station is enormously beneficial, particularly in a target-rich environment. That includes making the distinction between a station I have already worked (and thus need not work again) and an unworked station associated with a worked-but-unconfirmed counter (which I should attempt to work).
73,
Dave, AA6YQ
------------------------------------
Posted by: "Dave AA6YQ" <@AA6YQ>
------------------------------------
------------------------------------
Yahoo Groups Links

Dave AA6YQ
 

AA6YQ comments below
-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Monday, December 18, 2017 10:24 PM
To: dxlab@...
Subject: Re: [dxlab] Re: WW and JT modes


I strongly disagree. Having SpotCollector immediately update its
display of what's needed when I log a QSO with a previously-needed
station is enormously beneficial, particularly in a target-rich
environment. That includes making the distinction between a station I
have already worked (and thus need not work again) and an unworked
station associated with a worked-but-unconfirmed counter (which I
should attempt to work).
With WSJT-X/JTAert logging to DXKeeper, SpotCollector *does* immediately update *its* needed display. It is only JTAlert that doesn't update its need list and alerts immediately.

Typically, FT8/JT9/JT65 is not a target-rich environment and but since
FT8/JT9/JT65 users are some of the most active users of LotW one has most often confirmed or not worked a given "counter".

Had FT8 been available at the beginning of the year when I began my pursuit of CQ DX Marathon on 160m, it would have provided an extremely target-rich environment. New DXers would encounter a similar inundation, as would long-time DXers who have just begun pursuing a new band, mode, or award family.
Having SpotCollector immediately update its need display is certainly helpful, but it'd be better if JTAlert also did this. As stated previously, I understand that Laurie VK3AMA has a full plate, and may not be able to justify spending time on improvements that benefit only a fraction of his user community.
73,

Dave, AA6YQ

Björn Ekelund, SM7IUN
 

Based on input from some of us users Laurie has recently made substantial improvements to JTAlerts award tracking mechanics, 
but they are still very basic compared to those of DXLab. For instance, the "worked before" status no longer overrides other tracking. 

When on JT modes I often find myself "testing" calls in DXLab and would personally love if JTAlert was able to use DXKeeper's "needed" status information directly.

But it is easy to wish for someone else to do a lot of work. I am very grateful JTAlert exist at all. 

73,

Björn SM7IUN








2017-12-19 4:37 GMT+01:00 'Dave AA6YQ' aa6yq@... [dxlab] <dxlab@...>:

 

>>>AA6YQ comments below

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Monday, December 18, 2017 10:24 PM
To: dxlab@...
Subject: Re: [dxlab] Re: WW and JT modes

> I strongly disagree. Having SpotCollector immediately update its
> display of what's needed when I log a QSO with a previously-needed
> station is enormously beneficial, particularly in a target-rich
> environment. That includes making the distinction between a station I
> have already worked (and thus need not work again) and an unworked
> station associated with a worked-but-unconfirmed counter (which I
> should attempt to work).
With WSJT-X/JTAert logging to DXKeeper, SpotCollector *does* immediately update *its* needed display. It is only JTAlert that doesn't update its need list and alerts immediately.

Typically, FT8/JT9/JT65 is not a target-rich environment and but since
FT8/JT9/JT65 users are some of the most active users of LotW one has most often confirmed or not worked a given "counter".

>>>Had FT8 been available at the beginning of the year when I began my pursuit of CQ DX Marathon on 160m, it would have provided an extremely target-rich environment. New DXers would encounter a similar inundation, as would long-time DXers who have just begun pursuing a new band, mode, or award family.

>>>Having SpotCollector immediately update its need display is certainly helpful, but it'd be better if JTAlert also did this. As stated previously, I understand that Laurie VK3AMA has a full plate, and may not be able to justify spending time on improvements that benefit only a fraction of his user community.

73,

Dave, AA6YQ


llibsch
 

Dave,

    I would strongly support your extending WinWarbler to directly interoperate with WSJT-X so that a "Broadband Decode" window showing all active JT-mode stations could be presented, color-coded by need and LoTW/eQSL participation. DX and DXpedition operation on FT-8 is already significant and growing rapidly. Integration of WSJT-X into WinWarbler would be a great addition to your outstanding DXLab Suite.
                                      
                                                                                 Larry, K4KGG