Date   

locked Version 2.16.12 Working Well

Mark Robinson
 

I just updated to version 2.16.12 and now my sound alerts are working perfectly and DXLab Suite Pathfinder is being updated as I start to work each new station


Great job   Many thanks

Mark N1UK


locked Re: Version 2.16.11 Multicast and Multiple Instances

Santiago Mejia
 


This issue was solved. Everything is working fine with Wsjtx, JTAlert and Gridtracker. The issue of Lookup Window only working with 1st instance is a GT issue and Tag will be looking at it in future releases. 

Today's fixed of UDP Rebroadcast has allowed me to also incorporate FRLogger (A logger for Flex Radios) into the mix. No I can have Wsjtx (3 instances), JTAlert (3 instancies), GridTracker, Log4Om and FRLogger running at the same time.

Thanks Laurie.

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


locked Re: Version Numbers

 

Marlo,

Me too.  Didn’t actually check the version number till I saw you post.  I just re-downloaded and reinstalled and it now reads 2.16.12.

 

__________

Dan – K4SHQ

CFI/II

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Marlo Montanaro - KA2IRQ
Sent: Friday, August 14, 2020 1:54 PM
To: Support@HamApps.groups.io
Subject: [HamApps] Version Numbers

 

I just installed 2.16.12 but my Decodes window still says 2.16.11.  Win10.  Everything seems to be working fine.

73,

Marlo- KA2IRQ


--
Dan - K4SHQ


locked Version Numbers

Marlo Montanaro - KA2IRQ
 

I just installed 2.16.12 but my Decodes window still says 2.16.11.  Win10.  Everything seems to be working fine.

73,

Marlo- KA2IRQ


locked Re: Alert Sound and Pathfinder Problems

Jesus
 

Mark, tienes que traducir, lo siento.
Estuve mucho tiempo con la versión 2.14.2, que bien funcionaba.....
Hoy estoy con la versión 2.16.10, funcionada correctamente.... compre una tarjeta de sonido exterior para JTAlert exclusiva, y todo funciona...
Por si te sirve de ayuda....

Cordialmente, 
Jesus, EA1YR

El vie., 14 ago. 2020 a las 1:59, Mark Robinson (<markrob@...>) escribió:
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 Entity Naming Conventions

Barry Murrell ZS2EZ
 

Hi Laurie

 

Having loaded the latest version of JTAlert I am now seeing the change to the name of South Africa – now Republic of South Africa.

 

Must say, I haven’t heard my home country referred to as “Republic of South Africa” in ages!!  J

 

This has however raised a conundrum : In JTAlert this just shows as “Rep. Of”…. Not distinguishable from the other 4 Republic Ofs (Korea, Kosovo, South Sudan and Congo). Kind of got used to F.R. meaning Germany, but at a glance both Kosovo and South Sudan start with a Z, which makes matters worse!!

 

As JTAlert only has a VERY small field to display the name (and to the best of my understanding does not actually transfer the name, but rather the DXCC entity number when logging), surely either a shorter (and more readable) option would make more sense…. Or alternatively a way to enlarge the blocks to enable the whole name to be read??

 

Sure, I know that we are supposed to know our prefixes… but some of us are getting a bit slower nowadays!!  J

 

73 de BARRY MURRELL ZS2EZ

KF26ta - Port Elizabeth, South Africa

EPC#0558 DMC#1690  30MDG#4081

DXCC HONOR ROLL (332/340)

DXCC(mixed)#41,146  DXCC(RTTY)#1,916

DXCC(phone)#34,990  DXCC(CW)#11,714

DXCC 80m,40m,30m,20m,17m,15m,12m,10m   5BDXCC#8,916

WAS Triple Play #492  WAS(RTTY)#538  WAS(Digital)#163-Endorsements JT65,FT8

WAZ(RTTY)#185  WAE-I(mixed)#72  WAZS(mixed)#214  AAA#1569

AS ZR6DXB: VUCC(50MHZ)#1,334  UKSMG WAE(Silver)#75  UKSMG AFRICA#22  WAC (Satellite)

website : www.zs2ez.co.za

 


locked Re: Wanted and Ignored callsign on JTAlert

asobel@...
 

Laurie

 

You are correct if the B4 disable  is made individual to each wanted call. Still, I want to work it for each band and not be harassed by repeated alerts from the wanted call on  already worked bands.

 

Amos 4X4MF

 

 

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

 

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 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.

4321 - 4340 of 35458