Date   

locked New : Sound files (2.5.3) have been updated with improved announcement sounds for non-English languages.

HamApps Support (VK3AMA)
 

The Sound files have been updated to version 2.5.3

All the non-English language files have been recreated with improved pronunciation of the alert words.
Announcements are now correct for the language. Words are spoken in the correct language rather than English words spoken with a language accent as used in 2.5.2.

For the users of US male voiced files, I was unable to get an acceptable announcement for "DX" so have used the old "DX" file from version 2.5.1.

de Laurie VK3AMA


locked Re: new callsign failure

HamApps Support (VK3AMA)
 

On 6/03/2020 6:29 pm, androman@... wrote:
Hello, I am setting up PC's for our new club vanity callsign. I installed the wsjt-x software and Jtalert.
But when I went to put in our callsign with the change callsign program it Would Not accept it.
What did I do wrong?
This happened on two different PC's.

OM,

There is no need to run the Change Callsign program when your installing JTAlert for the first time.

When you run JTAlert for the first time after a new installation, it will automatically prompt you for your Callsign.

de Laurie VK3AMA


locked new callsign failure

androman@...
 

Hello, I am setting up PC's for our new club vanity callsign. I installed the wsjt-x software and Jtalert.
But when I went to put in our callsign with the change callsign program it Would Not accept it.
What did I do wrong?
This happened on two different PC's.


locked Re: Using JTA with DXLabs and WSJT-X

Laurie, VK3AMA
 


On 6/03/2020 10:54 am, Hasan Schiers N0AN wrote:
I use 2334 and it works fine. I think the rebroadcast port may default to 2334, but in any case, the programmer that helped me get it all working told me to use 2334. I'll have to ask him if there was any special reason.

It certainly works, and I'm a very happy camper having JTAlert working full time again and being able to use the incredible power of SpotCollector in DXLab Suites.

73, N0AN
Hasan

The port number is not critical except it has to be a free port not used by another application. Whatever port is set in JTAlert, that is the port that needs to be used in the application that is listening for these UDP packets.


de Laurie VK3AMA


locked Re: Using JTA with DXLabs and WSJT-X

Laurie, VK3AMA
 

That's how I would do it.

de Laurie VK3AMA


locked Re: Using JTA with DXLabs and WSJT-X

Hasan Schiers N0AN
 

I use 2334 and it works fine. I think the rebroadcast port may default to 2334, but in any case, the programmer that helped me get it all working told me to use 2334. I'll have to ask him if there was any special reason.

It certainly works, and I'm a very happy camper having JTAlert working full time again and being able to use the incredible power of SpotCollector in DXLab Suites.

73, N0AN
Hasan


On Thu, Mar 5, 2020 at 5:45 PM Dave Garber <ve3wej@...> wrote:
i thought the re-broadcast was to be 2234 ( or I use 2239).  unless you had a typo, the port 2334 may be used sometimes by something else
I use 2239 to get to gridtracker, running on a Raspberry pi

Dave Garber
VE3WEJ / VE3IE


On Thu, Mar 5, 2020 at 6:04 AM Hasan Schiers N0AN <hbasri.schiers6@...> wrote:
I have been using DXLab Suites of late and one of the things that I really missed was being able to use JTAlert at the same time I was using DXLab SpotCollector, because JTAlert wants exclusive control or use of the UDP info coming out of WSJT-X.

There are things that JTA does much better than SpotCollector. It is more immediate in its alerts. It tabulates information in a very intuitive way, so that a quick glance or listen gives information efficiently.

There are other things that SpotCollector does, too many to mention, that JTA does not do and will never do. They complement each other, but running them together is not easily or obviously done. (at least to me)

I stumbled on a way that works:

1. Leave WSJT-X in its standard UDP reporting configuration:
127.0.0.1 and Port 2237

2. Use the recommended settings for WSJT-X to log to DXKeeper.

3. Set JTAlert to log to its own ADIF log. (do not use DxKeeper as your JTA logger) or you will get double entries in your DXKeeper log.

4. In JTA:
Manage Settings > Applications >  WSJT-X/JTDX:
Check Rebroadcast WSJT-X  UDP Packets (rx'd only)
Port 2334
IP: 127.0.0.1

5. In SpotCollector:
Config > Spot Sources > WSJT-X:
Check CQ Color, MyCall color, Port 2334
Check Lookup, Callbook LoTW (as needed)
Finally, check ENABLE WSJT-X

The Resulting Operations:

JTAlert gets decoded UDP Packets directly from WSJT-x on Port 2237

JTAlert Rebroadcasts those UDP packets to SpotCollector which is listening on 2334.

If things are working correctly, the Spot Source Status light at the top of SpotCollector window (row of red/green lights) will show green at the far right, indicating it is getting spots from WSJT-X (which in reality it is not, it is getting them from the rebroadcast of JTAlert

If this doesn't happen, you might have to try it more than once (enable/disable WSJT-X in SpotCollector config), or stop/restart either or both JTA or SpotCollector or WSJT-x. Once it "takes" and the green light is lit, it will stay working just fine.

If needed, export your DXKeeper log in adif format and place it in JTAlert's logging location for ADIF log. This will make sure your two logs are in sync and give proper Worked B4, STATE and DX summaries. As each new qso comes in, it is logged to DXKeeper in its file and and to JTAlert's ADIF log file. No dupes! You should only have to import / replace the JTA adif file one time, when setting this up the first time. (All this assumes that DXKeeper is your master log and has more qsos than you might have in your ADIF log in JTAlert.

I found placing the ADIF log file in a more accessible directory worked better as you can import it more easily than inside the AppData subdirectories. I put mine in the Download directory and made sure to rename it properly  so it would be easy to see which file to import. (Choose select when in the ADIF log setup in JTA)

Now:
JTAlert is fully functional  and stays current
DxLab SpotCollector is nearly fully functional and stays current.

No conflicts, no dupes. 

CAVEAT:
You can call stations in JTA by double clicking as normal and WSJT-X will follow.

You cannot double click in SpotCollector and have WSJT-X  move to the spot.

SpotCollector does not remember Port 2334 in it's configuration for WSJT-X as a spot source. Every time you stop/restart SpotCollector you will need to go in and set the Port to 2334 if you want it to work with JTAlert as described above.
Seems like the best of both worlds.

If there's a better way to do this, I'm sure someone will point it out and I'll learn from it. If there's something wrong on dangerous with doing things the way I have outlined, please speak up.

You can return to "normal" Spot Collector operation by closing JTAlert and :

SpotCollector > Config > Spot Sources > Change Port back to 2237 from 2334.

73, N0AN

Hasan


locked Re: Using JTA with DXLabs and WSJT-X

Dave Garber
 

i thought the re-broadcast was to be 2234 ( or I use 2239).  unless you had a typo, the port 2334 may be used sometimes by something else
I use 2239 to get to gridtracker, running on a Raspberry pi

Dave Garber
VE3WEJ / VE3IE


On Thu, Mar 5, 2020 at 6:04 AM Hasan Schiers N0AN <hbasri.schiers6@...> wrote:
I have been using DXLab Suites of late and one of the things that I really missed was being able to use JTAlert at the same time I was using DXLab SpotCollector, because JTAlert wants exclusive control or use of the UDP info coming out of WSJT-X.

There are things that JTA does much better than SpotCollector. It is more immediate in its alerts. It tabulates information in a very intuitive way, so that a quick glance or listen gives information efficiently.

There are other things that SpotCollector does, too many to mention, that JTA does not do and will never do. They complement each other, but running them together is not easily or obviously done. (at least to me)

I stumbled on a way that works:

1. Leave WSJT-X in its standard UDP reporting configuration:
127.0.0.1 and Port 2237

2. Use the recommended settings for WSJT-X to log to DXKeeper.

3. Set JTAlert to log to its own ADIF log. (do not use DxKeeper as your JTA logger) or you will get double entries in your DXKeeper log.

4. In JTA:
Manage Settings > Applications >  WSJT-X/JTDX:
Check Rebroadcast WSJT-X  UDP Packets (rx'd only)
Port 2334
IP: 127.0.0.1

5. In SpotCollector:
Config > Spot Sources > WSJT-X:
Check CQ Color, MyCall color, Port 2334
Check Lookup, Callbook LoTW (as needed)
Finally, check ENABLE WSJT-X

The Resulting Operations:

JTAlert gets decoded UDP Packets directly from WSJT-x on Port 2237

JTAlert Rebroadcasts those UDP packets to SpotCollector which is listening on 2334.

If things are working correctly, the Spot Source Status light at the top of SpotCollector window (row of red/green lights) will show green at the far right, indicating it is getting spots from WSJT-X (which in reality it is not, it is getting them from the rebroadcast of JTAlert

If this doesn't happen, you might have to try it more than once (enable/disable WSJT-X in SpotCollector config), or stop/restart either or both JTA or SpotCollector or WSJT-x. Once it "takes" and the green light is lit, it will stay working just fine.

If needed, export your DXKeeper log in adif format and place it in JTAlert's logging location for ADIF log. This will make sure your two logs are in sync and give proper Worked B4, STATE and DX summaries. As each new qso comes in, it is logged to DXKeeper in its file and and to JTAlert's ADIF log file. No dupes! You should only have to import / replace the JTA adif file one time, when setting this up the first time. (All this assumes that DXKeeper is your master log and has more qsos than you might have in your ADIF log in JTAlert.

I found placing the ADIF log file in a more accessible directory worked better as you can import it more easily than inside the AppData subdirectories. I put mine in the Download directory and made sure to rename it properly  so it would be easy to see which file to import. (Choose select when in the ADIF log setup in JTA)

Now:
JTAlert is fully functional  and stays current
DxLab SpotCollector is nearly fully functional and stays current.

No conflicts, no dupes. 

CAVEAT:
You can call stations in JTA by double clicking as normal and WSJT-X will follow.

You cannot double click in SpotCollector and have WSJT-X  move to the spot.

SpotCollector does not remember Port 2334 in it's configuration for WSJT-X as a spot source. Every time you stop/restart SpotCollector you will need to go in and set the Port to 2334 if you want it to work with JTAlert as described above.
Seems like the best of both worlds.

If there's a better way to do this, I'm sure someone will point it out and I'll learn from it. If there's something wrong on dangerous with doing things the way I have outlined, please speak up.

You can return to "normal" Spot Collector operation by closing JTAlert and :

SpotCollector > Config > Spot Sources > Change Port back to 2237 from 2334.

73, N0AN

Hasan


locked Re: history page just showing DIG on ACL

ne1y@...
 

tnx for you quick reply ... this was at our club station where someone exported the adi file to a new computer and opted to check box in ACL's ADIF export Mapping that exports "All to CW, PH or DIG" ... it is a jungle out here in club land.   

NE1Y


locked Re: history page just showing DIG on ACL

HamApps Support (VK3AMA)
 

On 6/03/2020 6:58 am, ne1y@... wrote:
The history page [worked B4} is just showing DIG

is there an easy fix for this in JTAlert or is it a ACL problem

This is an ACL issue. JTAlert never sends a generic "DIG" mode QSO to ACL, it always sends the true mode.

de Laurie VK3AMA
 


locked history page just showing DIG on ACL

ne1y@...
 

so OK ... 
WSJT 2.1.2
ACL 6.6
JTAlert 2.15.11
Win 10 up to date. 

Everything is working where I need it to work.  BUT

on ACL the standard log is showing FT4 and FT8 under mode worked. 

The history page [worked B4} is just showing DIG

is there an easy fix for this in JTAlert or is it a ACL problem

Vic NE1Y


locked Re: Can't download JTAlert 2.15.11

HamApps Support (VK3AMA)
 

On 6/03/2020 5:55 am, Tom Gregor wrote:
Hopefully, this proves to be a temporary situation. And the author now has a "heads-up".
Tom,

The only problem is that your installation of AVAST is interfering with your access to https://HamApps.com

The site is up and accessible, there is nothing for me to fix.

de Laurie VK3AMA


locked Re: QRZ API Key Dashes

HamApps Support (VK3AMA)
 

On 6/03/2020 12:30 am, Bill via Groups.Io wrote:
Do the QRZ API Key dashes have to be removed before using it in JTAlert, i.e. no spaces?
73,
Bill KO4NR 

The API key needs to be entered exactly as it is shown for your QRZ logbook.
The dashes need to be used. There are no spaces in any of the keys I have tested, but if yours has spaces than they have to be included as well.

de Laurie VK3AMA


locked Can't download JTAlert 2.15.11

Tom Gregor
 

Good Afternoon Group:

I can't download the latest version of the software JTAlert 2.15.11. 

The attempted download results in the following error message: "This site can't be reached" The connection was reset. Along with an AVAST alert.

Hopefully, this proves to be a temporary situation. And the author now has a "heads-up".

tnx es 73 de K3SSB

Tom G, Sr.


locked Re: JTAlert is closing (crashing) after logging or settings change

Rich McCabe
 

Ok, looks like I am out.

Will try again when I get an email a new release is out.

73,

Rich


locked QRZ API Key Dashes

Bill <ko4nrbs@...>
 

Do the QRZ API Key dashes have to be removed before using it in JTAlert, i.e. no spaces?
73,
Bill KO4NR 


locked Using JTA with DXLabs and WSJT-X

Hasan Schiers N0AN
 

I have been using DXLab Suites of late and one of the things that I really missed was being able to use JTAlert at the same time I was using DXLab SpotCollector, because JTAlert wants exclusive control or use of the UDP info coming out of WSJT-X.

There are things that JTA does much better than SpotCollector. It is more immediate in its alerts. It tabulates information in a very intuitive way, so that a quick glance or listen gives information efficiently.

There are other things that SpotCollector does, too many to mention, that JTA does not do and will never do. They complement each other, but running them together is not easily or obviously done. (at least to me)

I stumbled on a way that works:

1. Leave WSJT-X in its standard UDP reporting configuration:
127.0.0.1 and Port 2237

2. Use the recommended settings for WSJT-X to log to DXKeeper.

3. Set JTAlert to log to its own ADIF log. (do not use DxKeeper as your JTA logger) or you will get double entries in your DXKeeper log.

4. In JTA:
Manage Settings > Applications >  WSJT-X/JTDX:
Check Rebroadcast WSJT-X  UDP Packets (rx'd only)
Port 2334
IP: 127.0.0.1

5. In SpotCollector:
Config > Spot Sources > WSJT-X:
Check CQ Color, MyCall color, Port 2334
Check Lookup, Callbook LoTW (as needed)
Finally, check ENABLE WSJT-X

The Resulting Operations:

JTAlert gets decoded UDP Packets directly from WSJT-x on Port 2237

JTAlert Rebroadcasts those UDP packets to SpotCollector which is listening on 2334.

If things are working correctly, the Spot Source Status light at the top of SpotCollector window (row of red/green lights) will show green at the far right, indicating it is getting spots from WSJT-X (which in reality it is not, it is getting them from the rebroadcast of JTAlert

If this doesn't happen, you might have to try it more than once (enable/disable WSJT-X in SpotCollector config), or stop/restart either or both JTA or SpotCollector or WSJT-x. Once it "takes" and the green light is lit, it will stay working just fine.

If needed, export your DXKeeper log in adif format and place it in JTAlert's logging location for ADIF log. This will make sure your two logs are in sync and give proper Worked B4, STATE and DX summaries. As each new qso comes in, it is logged to DXKeeper in its file and and to JTAlert's ADIF log file. No dupes! You should only have to import / replace the JTA adif file one time, when setting this up the first time. (All this assumes that DXKeeper is your master log and has more qsos than you might have in your ADIF log in JTAlert.

I found placing the ADIF log file in a more accessible directory worked better as you can import it more easily than inside the AppData subdirectories. I put mine in the Download directory and made sure to rename it properly  so it would be easy to see which file to import. (Choose select when in the ADIF log setup in JTA)

Now:
JTAlert is fully functional  and stays current
DxLab SpotCollector is nearly fully functional and stays current.

No conflicts, no dupes. 

CAVEAT:
You can call stations in JTA by double clicking as normal and WSJT-X will follow.

You cannot double click in SpotCollector and have WSJT-X  move to the spot.

SpotCollector does not remember Port 2334 in it's configuration for WSJT-X as a spot source. Every time you stop/restart SpotCollector you will need to go in and set the Port to 2334 if you want it to work with JTAlert as described above.
Seems like the best of both worlds.

If there's a better way to do this, I'm sure someone will point it out and I'll learn from it. If there's something wrong on dangerous with doing things the way I have outlined, please speak up.

You can return to "normal" Spot Collector operation by closing JTAlert and :

SpotCollector > Config > Spot Sources > Change Port back to 2237 from 2334.

73, N0AN

Hasan


locked Re: JTALERT Logging

Bill <ko4nrbs@...>
 

Do you have to remove the dashes in the QRZ.com API Key?

My buddy is a QRZ subscriber so that isn’t the issue.

73,
Bill KO4NR 



On Mar 4, 2020, at 4:17 PM, Bill via Groups.Io <ko4nrbs@...> wrote:

Thank you.

We found the set up for QRZ.com and HRDLog.net in JTALERT Manage Settings as you described.  Used HRDLog.net log in code and QRZ API code as instructed.  

It uploads to DXKEEPER perfectly but will not upload to QRZ or HRDLog.net.  No idea what is wrong.

73,
Bill KO4NR 


On Mar 4, 2020, at 2:26 PM, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:

On 5/03/2020 5:40 am, Bill via Groups.Io wrote:
When I select DXKEEPER and then select HRDLog.net it unselects Dxkeeper.  Also can’t find where to tell it to also log into QRZ.com.
 Bill KO4NR 

DXKeeper and HRDLog.net logging can be run concurrently. I suspect your confusing HRD V5/V6 logging with HRDLog.net. If you enable any of the loggers under the Logging section of the Settings, any previously enabled logger type under that section will be disabled. Only one primary Logger can be enabled for use with JTAlert, it is used for Worked B4 checks and determining what Alerts are generated for each decode, as well as logging your QSOs.

HRDLog.net is an online log and can be enabled independent of the primary Logger like DXKeeper. It is under the "Web Services -> Online Logbooks" section of the Settings. All online logbooks under that section can be enabled simultaneously.

de Laurie VK3AMA


locked Needed AK & HI states not flagged

Bill - AA4M
 

I've searched but did not see any posts discussing this problem.

I have HI and AK marked as needed on 15M FT8 but I've seen these states on the band and they are not being flagged.  So I tested against a couple of other states and they were correctly flagged, just Hi & AK are having the problem.

This was with 2.5.11.  So I reinstalled 2.5.10, same problem.

73, Bill - AA4M


locked Re: New : JTAlert voiced Alert sound files available in several languages and accents.#Announcement

HamApps Support (VK3AMA)
 

On 5/03/2020 8:29 am, Ron W3RJW via Groups.Io wrote:
New links downloaded and installed sound files FB (also correct Icon now showing) ....  Individual alerts use new sound file (US English). .... 'Testing your sound Card" is old voice for what it's worth .
--
73
Ron, W3RJW
Tnx Ron,

The old voiced "Testing your soundcard" is coming from a file embedded in the JTAlert executable. This was done to allow users to get a voiced test announcement when they didn't have the sounds package installed. The next version of JTAlert now tries to use the Sounds package file and if not found than uses the inbuilt file, which has been updated to the newer "Testing 123".

de Laurie VK3AMA


locked Re: #FIX : Sound file download links now fixed. #FIX

Dwaine Pipe
 

Thanks Laurie

 

Download AU (and UK just for fun) and both working 😊

 

Cheers

David

VK7YUM

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Thursday, 5 March 2020 8:14 AM
To: Support@HamApps.groups.io
Subject: [HamApps] #FIX : Sound file download links now fixed.

 

The links for the Sound File downloads have now been fixed.

Prior to the fix, the download file was corrupted and would not run.

Sorry for the inconvenience.

de Laurie VK3AMA