Date   

locked Alert Sound and Pathfinder Problems

Mark Robinson
 

Hi Laurie,

Since I upgraded to version 2.16.10 from 2.14.2 my Sound Alerts have stopped working. The Test Sound card button produces no sound.

I am running win 7 Pro and can see no problems with my soundcard setup. I don't know what else to look at. Can you advise.


I also notice that when I work a new station in WSJTX,  the callsign is not being passed to DXLab Suite   Path Finder.  Using the earlier version 2.14.2, Path Finder would display the new callsign details as soon as I started a   QSO.  Now Pathfinder only displays the new callsign after I log a station and I suspect the DXKeeper is causing Pathfinder to show the latestlog entry.

Any help would be appreciated

73 Mark N1UK


locked Re: Lost my Bearings

WB8ASI Herb
 

Thanks Laurie.  You nailed it.  Not sure how my Gridsquare file got wiped out.  Maybe I never got it reset correctly when moving locations, but think JTA alerts me that there is a mismatch of my gridsquare from my WSJT-X config and my Station Callsign info in JTA.   Had some updates lately too, that might have reset it.  Anyways All is well again, and now I know where to look if it ever happens again.  Keep up the good work.  73, Herb WB8ASI


locked Re: Wanted and Ignored callsign on JTAlert

HamApps Support (VK3AMA)
 

On 14/08/2020 7:37 am, asobel@... wrote:
Laurie

The problem with your solution is that if I put "Don't play Alert if
callsign is a B4" it will work for all wanted callsigns and all bands.

Amos 4X4MF

That's not correct, it would be applied to individual Callsigns only. If a Wanted Callsign (one out of the many possible for the Alert) is a B4 it would simply not be Alerted. It would NOT be applied to the Alert globally.

de Laurie VK3AMA


locked Re: Wanted and Ignored callsign on JTAlert

asobel@...
 

Laurie

The problem with your solution is that if I put "Don't play Alert if
callsign is a B4" it will work for all wanted callsigns and all bands.

Amos 4X4MF

-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of
Laurie, VK3AMA
Sent: Friday, August 14, 2020 12:26 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Wanted and Ignored callsign on JTAlert



On 12/08/2020 12:53 am, asobel@netvision.net.il wrote:
Please make the Wanted and Ignored callsign of JTAlert become band
dependent such as Wanted DXCC. The current situation creates problems.
Examples: I  did  work VK1ABC on 20m and I want to work it on all all
bands but I get infinite alerts from it on 20m. VK2PQR  is not wanted
on 20m but wanted on 6m.

Amos 4X4MF
Extending the "Wanted Callsigns Alert" to use individual Band/Mode tracking
is not practical. Developing a suitable settings interface would be
difficult.

The better solution is if I add a "Don't play Alert if callsign is a B4"
option to the "Wanted Callsign Alert". This simple change would allow a
Callsign to be alerted whenever decoded except for when it has been
previously worked on the current Band/Mode. I'll add this feature to the
todo list.

de Laurie VK3AMA


locked Re: Wanted and Ignored callsign on JTAlert

Laurie, VK3AMA
 

On 12/08/2020 12:53 am, asobel@netvision.net.il wrote:
Please make the Wanted and Ignored callsign of JTAlert become band dependent such as Wanted DXCC. The current situation creates problems. Examples: I  did  work VK1ABC on 20m and I want to work it on all all bands but I get infinite alerts from it on 20m. VK2PQR  is not wanted on 20m but wanted on 6m.

Amos 4X4MF
Extending the "Wanted Callsigns Alert" to use individual Band/Mode tracking is not practical. Developing a suitable settings interface would be difficult.

The better solution is if I add a "Don't play Alert if callsign is a B4" option to the "Wanted Callsign Alert". This simple change would allow a Callsign to be alerted whenever decoded except for when it has been previously worked on the current Band/Mode. I'll add this feature to the todo list.

de Laurie VK3AMA


locked Re: Lost my Bearings

HamApps Support (VK3AMA)
 

On 14/08/2020 1:49 am, WB8ASI Herb wrote:
There are NO bearings showing up in my Decodes Window even tho the Grids do appear.  I'm not seeing the Bearings or Grids either when I hover over the Callsign on the Main Window, which I think used to appear there.  Not exactly sure when this started.  I'm not at my homebase station, and have no antenna to turn at my current location.  Just noticed this yesterday after updating to 2.16.11, but it may have been missing earlier.  Restarting and rebooting did not change things.  Thanks, 73, Herb WB8ASI

Check that you have your Gridsquare set with JTAlert. Check the Station Callsign section of the Settings window. If you change or add a new grid you will need to restart JTAlert.

de Laurie VK3AMA


locked Re: Version 2.16.11 Multicast and Multiple Instances

g4wjs
 

On 13/08/2020 22:13, HamApps Support (VK3AMA) wrote:
On 14/08/2020 1:20 am, g4wjs wrote:
prior to the latest release JTAlert was not able to interoperate with multiple WSJT-X clients, instead one had to start a JTAlert instance for each WSJT-X client. I am not sure that the latest inclusion of multicast UDP support in JTAlert has changed that position. We will have to wait for confirmation from Laurie, but I suspect you may have to start groups of applications each using a different multicast group address. So for example two WSJT-X instances would look like this:

WSJT-X - instance 1 ----------> 239.255.0.0 -------------> JTAlert instance 1
                                       |
                                       +-----------------> Gridtracker instance 1

WSJT-X - instance 2 ----------> 239.255.0.1 -------------> JTAlert instance 2
                                       |
                                       +-----------------> Gridtracker instance 2

rather than the more straightforward:

WSJT-X instance 1 -------------+ +-----------> JTAlert
                               |                    |
                               +---> 239.255.0.0 ---+
                               |                    |
WSJT-X instance 2 -------------+ +-----------> Gridtracker

I do not know if Gridtracker is capable of running two or more instances on the same machine, so the first configuration may not be possible.

73
Bill
G4WJS.

Bill,

Neither is exactly correct. The current JTAlert implementation will transparently support each WSJT-X instance using a unique multicast address (per your first diagram) as well as instances running either common multicast or unicast (with unique port) address.

Your second diagram is closest to the mark, but it shows a single JTAlert instance which will work, but restrict JTAlert to a single WSJT-X instance. There should be an equal number of JTAlert / WSJT-X combinations.

eg.
WSJT-X instance #1 -------------+ +-----------> JTAlert instance #1
                                |                    |
WSJT-X instance #2 -------------+---> 239.255.0.0 ---+-----------> JTAlert instance #2
                                |                    |
WSJT-X instance #3 -------------+ +-----------> JTAlert instance #3

I can't speak for the GridTracker multi-instance requirements

The simplest method is that all WSJT-X instances use a single address/port,  JTAlert can handle that configuration now.

FYI, Under-the-hood, JTAlert.exe (the main window) is still stuck in the unicast IP + unique WSJT-X port realm (due to AutoIT limits) but instead of forcing those restrictions on the WSJT-X UDP Server setup, that is applied to the JTAlertV2.Manager.exe process (.NET code) which translates the WSJT-X multicast traffic to the still required unicast traffic. JTAlert talks exclusively to the Manger process with the Manager process handling all the UDP traffic to and from the WSJT-X instances.

de Laurie VK3AMA

Hi Laurie,

thanks for that info. Shame you have to jump through so many hoops to get it all working but what you have at least looks like the way the WSJT-X UDP Message Protocol was intended to work, from the outside. Well done for getting it up and running.

73
Bill
G4WJS.


--
73
Bill
G4WJS.


locked Re: Version 2.16.11 Multicast and Multiple Instances

HamApps Support (VK3AMA)
 

On 14/08/2020 1:20 am, g4wjs wrote:
prior to the latest release JTAlert was not able to interoperate with multiple WSJT-X clients, instead one had to start a JTAlert instance for each WSJT-X client. I am not sure that the latest inclusion of multicast UDP support in JTAlert has changed that position. We will have to wait for confirmation from Laurie, but I suspect you may have to start groups of applications each using a different multicast group address. So for example two WSJT-X instances would look like this:

WSJT-X - instance 1 ----------> 239.255.0.0 -------------> JTAlert instance 1
                                       |
                                       +-----------------> Gridtracker instance 1

WSJT-X - instance 2 ----------> 239.255.0.1 -------------> JTAlert instance 2
                                       |
                                       +-----------------> Gridtracker instance 2

rather than the more straightforward:

WSJT-X instance 1 -------------+ +-----------> JTAlert
                               |                    |
                               +---> 239.255.0.0 ---+
                               |                    |
WSJT-X instance 2 -------------+ +-----------> Gridtracker

I do not know if Gridtracker is capable of running two or more instances on the same machine, so the first configuration may not be possible.

73
Bill
G4WJS.
Bill,

Neither is exactly correct. The current JTAlert implementation will transparently support each WSJT-X instance using a unique multicast address (per your first diagram) as well as instances running either common multicast or unicast (with unique port) address.

Your second diagram is closest to the mark, but it shows a single JTAlert instance which will work, but restrict JTAlert to a single WSJT-X instance. There should be an equal number of JTAlert / WSJT-X combinations.

eg.
WSJT-X instance #1 -------------+ +-----------> JTAlert instance #1
                                |                    |
WSJT-X instance #2 -------------+---> 239.255.0.0 ---+-----------> JTAlert instance #2
                                |                    |
WSJT-X instance #3 -------------+ +-----------> JTAlert instance #3

I can't speak for the GridTracker multi-instance requirements

The simplest method is that all WSJT-X instances use a single address/port,  JTAlert can handle that configuration now.

FYI, Under-the-hood, JTAlert.exe (the main window) is still stuck in the unicast IP + unique WSJT-X port realm (due to AutoIT limits) but instead of forcing those restrictions on the WSJT-X UDP Server setup, that is applied to the JTAlertV2.Manager.exe process (.NET code) which translates the WSJT-X multicast traffic to the still required unicast traffic. JTAlert talks exclusively to the Manger process with the Manager process handling all the UDP traffic to and from the WSJT-X instances.

de Laurie VK3AMA


locked JTAlert 2.16.12 is available - UDP Resend Fix - #Announcement #NewRelease

HamApps Support (VK3AMA)
 

The latest JTAlert version 2.16.12 is now available @ https://hamapps.com/JTAlert/

de Laurie VK3AMA

Release Notes.

2.16.12 (14-Aug-2020)

  Fixes:

    - UDP Resend: WSJT-X/JTDX UDP packet resend not working (2.16.11 defect).



locked Re: Version 2.16.11 Multicast and Multiple Instances

Santiago Mejia
 


I got it working -almost-. I have Wsjtx broadcasting to the same multicast ip and port in the 3 instances and JTAlert is listening fine. On the GT tracker side, callable roster is getting information fine but Lookup Window only works with first instance not the other two. While everything is going fine to Log4OM too, so no problem there.

I guess this is a GT issue, so I will take it to their group and see what I can find.

Santiago
______________
73 de Santiago
HI8SMX
web: www.hi8smx.online 
YouTube: HI8SMX 
Twitter: @hi8smx
Instagram: hi8smx


locked Re: Problem with new version 2.16.11 - DEFECT Confirmed

Charlie Hoffman
 

Can you make this "recompiled version" available to all users?

I also was using port 2334 and had to revert to version 2.16.9 to make it work correctly.


locked Lost my Bearings

WB8ASI Herb
 

There are NO bearings showing up in my Decodes Window even tho the Grids do appear.  I'm not seeing the Bearings or Grids either when I hover over the Callsign on the Main Window, which I think used to appear there.  Not exactly sure when this started.  I'm not at my homebase station, and have no antenna to turn at my current location.  Just noticed this yesterday after updating to 2.16.11, but it may have been missing earlier.  Restarting and rebooting did not change things.  Thanks, 73, Herb WB8ASI


locked Re: Version 2.16.11 Multicast and Multiple Instances

g4wjs
 

On 13/08/2020 16:07, Santiago Mejia via groups.io wrote:
Good morning all. I have a question regarding the new JT Alert version with multicast and running multiple instances of Wsjtx+JTAlert and Grid Tracker. Prior to the newest version, I had 3 separate instances of Wsjtx and JtAlert running fine, along with Grid Tracker and Log4OM as well. All were working fine and communicating smoothly.

However, after upgrading to version 2.16.11 of JtAlert, I don´t seem to be able to get the 3 instances of WSJTX talk with JTAlert, Grid Tracker and Log4OM. I´ve configured the Wsjtx instances to use a muilticast ip and udp port and configured GT and Log4Om to listen to that port but no info is coming thru from 2 of the 3 instances.

Can anyone help?, thanks.
______________
73 de Santiago
HI8SMX
Hi Santiago,

prior to the latest release JTAlert was not able to interoperate with multiple WSJT-X clients, instead one had to start a JTAlert instance for each WSJT-X client. I am not sure that the latest inclusion of multicast UDP support in JTAlert has changed that position. We will have to wait for confirmation from Laurie, but I suspect you may have to start groups of applications each using a different multicast group address. So for example two WSJT-X instances would look like this:

WSJT-X - instance 1 ----------> 239.255.0.0 -------------> JTAlert instance 1
                                    |
                                     +-----------------> Gridtracker instance 1

WSJT-X - instance 2 ----------> 239.255.0.1 -------------> JTAlert instance 2
                                       |
                                       +-----------------> Gridtracker instance 2

rather than the more straightforward:

WSJT-X instance 1 -------------+                    +-----------> JTAlert
                               |                    |
                               +---> 239.255.0.0 ---+
                               |                    |
WSJT-X instance 2 -------------+                    +-----------> Gridtracker

I do not know if Gridtracker is capable of running two or more instances on the same machine, so the first configuration may not be possible.

73
Bill
G4WJS.



--
73
Bill
G4WJS.


locked Version 2.16.11 Multicast and Multiple Instances

Santiago Mejia
 

Good morning all. I have a question regarding the new JT Alert version with multicast and running multiple instances of Wsjtx+JTAlert and Grid Tracker. Prior to the newest version, I had 3 separate instances of Wsjtx and JtAlert running fine, along with Grid Tracker and Log4OM as well. All were working fine and communicating smoothly.

However, after upgrading to version 2.16.11 of JtAlert, I don´t seem to be able to get the 3 instances of WSJTX talk with JTAlert, Grid Tracker and Log4OM. I´ve configured the Wsjtx instances to use a muilticast ip and udp port and configured GT and Log4Om to listen to that port but no info is coming thru from 2 of the 3 instances.

Can anyone help?, thanks.
______________
73 de Santiago
HI8SMX
web: www.hi8smx.online 
YouTube: HI8SMX 
Twitter: @hi8smx
Instagram: hi8smx


locked Re: JTAlert with UDP Multicast support available for testing #Beta

TomK
 

Ah, Laurie!  Must be Aussie Hacker humor to point out settings and info based on code released just hours before, ha!

Thought I was bad when running the code distributions for Fido and Opus, et al. <loving elbow>.

Seriously, thanks for hinting about a just released fix but, more importantly …

… for the 1st and only cogent explanation of the addressing scheme for the 3 popular apps, WSJT, JTA, and GT!

All is working. Great job on the JTA code.

 

Any hints on when there might be County alerting?

TomK / KT1TK / 73

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Thursday, August 13, 2020 2:15 AM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert with UDP Multicast support available for testing #Beta

 

On 13/08/2020 3:56 pm, TomK wrote:

Glad you noted the multicast test-build issue, Laurie.

I, too, lost my GridTracker input feed when I upgraded it at the same time I upgraded JT.

Thought it was GT. Now looks like it may be due to the build error you noted.

I circumvented the problem setting GT to use the (now deprecated) WSJT secondary port forwarding.

Would prefer to us either base program’s main port again (WSJT or JT as B4) without funky deprecated WSJT forwarding

TomK / KT1TK / 73


Why bother with the UDP forwarding?

That is no longer needed now that JTAlert supports UDP mulitcasting. You just need to set both WSJT-X and Grid Tracker to use the same multicast IP address (in the 239.0.0.0 to 239.255.255.255 range) with nothing to set in JTAlert. The whole point of multitasking is that multiple concurrently running applications can work directly with WSJT-X, something that can't be done when using UDP forwarding. The application (eg Grid Tracker) cannot send commands to WSJT-X, it can only receive. With multicasting that is no longer the case.

de Laurie VK3AMA


locked Re: JTAlert with UDP Multicast support available for testing #Beta

HamApps Support (VK3AMA)
 

On 13/08/2020 3:56 pm, TomK wrote:

Glad you noted the multicast test-build issue, Laurie.

I, too, lost my GridTracker input feed when I upgraded it at the same time I upgraded JT.

Thought it was GT. Now looks like it may be due to the build error you noted.

I circumvented the problem setting GT to use the (now deprecated) WSJT secondary port forwarding.

Would prefer to us either base program’s main port again (WSJT or JT as B4) without funky deprecated WSJT forwarding

TomK / KT1TK / 73


Why bother with the UDP forwarding?

That is no longer needed now that JTAlert supports UDP mulitcasting. You just need to set both WSJT-X and Grid Tracker to use the same multicast IP address (in the 239.0.0.0 to 239.255.255.255 range) with nothing to set in JTAlert. The whole point of multitasking is that multiple concurrently running applications can work directly with WSJT-X, something that can't be done when using UDP forwarding. The application (eg Grid Tracker) cannot send commands to WSJT-X, it can only receive. With multicasting that is no longer the case.

de Laurie VK3AMA


locked Re: JTAlert with UDP Multicast support available for testing #Beta

TomK
 

Glad you noted the multicast test-build issue, Laurie.

I, too, lost my GridTracker input feed when I upgraded it at the same time I upgraded JT.

Thought it was GT. Now looks like it may be due to the build error you noted.

I circumvented the problem setting GT to use the (now deprecated) WSJT secondary port forwarding.

Would prefer to us either base program’s main port again (WSJT or JT as B4) without funky deprecated WSJT forwarding

TomK / KT1TK / 73

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Wednesday, August 12, 2020 10:22 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] JTAlert with UDP Multicast support available for testing #Beta

 

On 13/08/2020 12:11 pm, B. Smith via groups.io wrote:

It was a cursory observation. I didn't see the pink B4s and maybe some other colors initially  and not sure if JTA was displaying all of the callsigns either. So there appeared to be some effect between JTA and WSJT-X as everything looked great right after I unchecked that box.

73, Bill n3xl 


Bill,

I just checked the code, that option was being ignored in the latest build (left over testing code that should have been removed) so it would not have made a difference.

de Laurie VK3AMA


locked Re: JTAlert with UDP Multicast support available for testing #Beta

HamApps Support (VK3AMA)
 

On 13/08/2020 12:11 pm, B. Smith via groups.io wrote:
It was a cursory observation. I didn't see the pink B4s and maybe some other colors initially  and not sure if JTA was displaying all of the callsigns either. So there appeared to be some effect between JTA and WSJT-X as everything looked great right after I unchecked that box.
73, Bill n3xl 

Bill,

I just checked the code, that option was being ignored in the latest build (left over testing code that should have been removed) so it would not have made a difference.

de Laurie VK3AMA


locked Re: Problem with new version 2.16.11 - DEFECT Confirmed

HamApps Support (VK3AMA)
 

On 13/08/2020 11:56 am, Chris VK2BYI wrote:

Hi Laurie

I updated JTAlert to v2.16.11, and made no changes to the configuration settings whatsoever for WSJT-X and JTAlert.

I notice that the Resend WSJT-X UDP packets (received only) setting is still available, so I expected that it would work as before but found that not to be the case.

I have a mapping application that plots decodes being resent by JTAlert, but at present it doesn't support multicasting.  I have reverted JTAlert to v2.16.10 in the meantime and all is working once again.

Is it the intention that the Resend WSJT-X UDP packets (received only) feature will still work as long as a non-multicast group address is configured in WSJT-X?

73 Chris
VK2BYI


Hi Chris,

Tnx for the report. This is a defect.''

I had accidentally left in-place some multicast testing code that bypasses the "Resend WSJT-X UDP packets" function. I am recompiling a new build as I type this. Look for a download link in your inbox in ~15minutes.

de Laurie VK3AMA


locked Re: JTAlert with UDP Multicast support available for testing #Beta

B. Smith <bill.n3xl@...>
 

Laurie,
It was a cursory observation. I didn't see the pink B4s and maybe some other colors initially  and not sure if JTA was displaying all of the callsigns either. So there appeared to be some effect between JTA and WSJT-X as everything looked great right after I unchecked that box.
73, Bill n3xl 

On Aug 12, 2020 21:13, "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...> wrote:
On 13/08/2020 10:50 am, B. Smith via groups.io wrote:
JTA settings - Applications - WSJT-x/JTDX you should uncheck "Resend WSJT-X UDP packets..." Nice upgrade.

73, Bill N3XL  

Bill,

Failing to uncheck that resend option should have no ill effects. Did you see otherwise?

That resend option was being used by GridTracker prior to multicast, but with changing GT to using a multicast address the packets sent on that port would not be seen by GT.

The only down-side to keeping that option enabled would be a minimal performance impact (unnoticed by the user) on JTAlert operation as it will be executing instructions for no purpose.

de Laurie VK3AMA


5861 - 5880 of 36991