Date   

locked Re: JTALERT Logging

HamApps Support (VK3AMA)
 

On 5/03/2020 10:02 am, Bill via Groups.Io wrote:
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 
NO, you don't need to remove the dashes. You enter the key exactly as shown on QRZ.com

de Laurie VK3AMA


locked Re: Wanted VE Province Alert

HamApps Support (VK3AMA)
 

On 7/03/2020 3:02 am, WB8ASI Herb wrote:
Hi Laurie,   I'm using 2.15.11 Beta Build 0010.  It appears that the new VE Province Alert is not using the LOTW confirmation filter.  It is showing worked, but not yet confirmed, as no longer Wanted.  Thanks. 73, Herb WB8ASI
Herb,

I'm confused by what your describing. The Alerts LoTW Filter only affects what Callsigns are displayed, it has no influence over Worked/Confirmed statuses. Please rephrase. What is not working?

I have retested and the Scan Log is correctly picking up LoTW confirmed Provinces, the Callsign QSO history is correctly showing the worked/confirmed status as is the Confirmed
Bands display which is showing confirmed correctly.

de Laurie VK3AMA



locked Re: array variable error

HamApps Support (VK3AMA)
 

On 7/03/2020 8:56 am, Joseph Hurd wrote:
Today, I downloaded and installed the latest US English and call sign databases. When a new [wanted] stae is detected, JTA shuts down and this message appears:

"Line 11247 error - array variable has incorrect number of sub scripts or sub script dimension range exceeded".

Anyone else with this problem?
See https://hamapps.groups.io/g/Support/message/28014 for the temporary fix until the next release.

de Laurie VK3AMA


locked array variable error

Joseph Hurd
 

Today, I downloaded and installed the latest US English and call sign databases. When a new [wanted] stae is detected, JTA shuts down and this message appears:

"Line 11247 error - array variable has incorrect number of sub scripts or sub script dimension range exceeded".

Anyone else with this problem?


locked Re: JTAlert 2.15.9, 2.15.10, 2.15.11 Callsign Setup Window Not Accessible on Initial Execution after Install on Win10 Laptop

Bill Franzen
 

Mike - I did try all of the off screen fixes and could not get to it at all. 

Laurie - I used the regedit approach, successfully.

Thanks for the quick response.

Bill

73 de N0NYH


On Fri, Mar 6, 2020 at 12:07 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 7/03/2020 4:58 am, HamApps Support (VK3AMA) via Groups.Io wrote:
Bill,

You have a couple of options, a command line parameter or a Registry entry.
  • Add this parameter to the command-line used to start JTAlert, /callsign=N0NYH

  • Add a Registry string (REG_SZ) under "HKEY_CURRENT_USER\Software\HamApps", with a name of "callsign" and a value of "N0NYH"

I neglected to add to the above (it has just gone 5:00am here and I'm still on my first coffee)...

The command-line parameter is a temporary fix with the parameter needed with all future shortcuts used to start JTAlert until the permanent fix is applied by creating the Registry entry.

   

de Laurie VK3AMA


locked Re: Sound files and callsign data base

WB8ASI Herb
 

Comcast/Xfinity has added new security on their routers.  You need to disable for download, then re-enable.  Here's a path to get you there.  Took me awhile to figure it out.  https://internet.xfinity.com/more/my-services/my-services-disabling  73, Herb WB8ASI

On March 6, 2020 at 1:38 PM Dave Tucker Nu4N <dwtucker19@...> wrote:

For some reason I cant dowload either of these programs. I get a response of secure connection failed.
Any help would be appreciated.
Thanks in advance. 73
--
DAVE NU4N

 


locked Sound files and callsign data base

 

For some reason I cant dowload either of these programs. I get a response of secure connection failed.
Any help would be appreciated.
Thanks in advance. 73
--
DAVE NU4N


locked Re: JTAlert 2.15.9, 2.15.10, 2.15.11 Callsign Setup Window Not Accessible on Initial Execution after Install on Win10 Laptop

HamApps Support (VK3AMA)
 

On 7/03/2020 4:58 am, HamApps Support (VK3AMA) via Groups.Io wrote:
Bill,

You have a couple of options, a command line parameter or a Registry entry.
  • Add this parameter to the command-line used to start JTAlert, /callsign=N0NYH

  • Add a Registry string (REG_SZ) under "HKEY_CURRENT_USER\Software\HamApps", with a name of "callsign" and a value of "N0NYH"

I neglected to add to the above (it has just gone 5:00am here and I'm still on my first coffee)...

The command-line parameter is a temporary fix with the parameter needed with all future shortcuts used to start JTAlert until the permanent fix is applied by creating the Registry entry.

   

de Laurie VK3AMA


locked Re: JTAlert 2.15.9, 2.15.10, 2.15.11 Callsign Setup Window Not Accessible on Initial Execution after Install on Win10 Laptop

HamApps Support (VK3AMA)
 

On 6/03/2020 11:03 pm, Bill Franzen wrote:

Good Morning. 

 

I’ve had a copy of JTAlert 2.15.9, database 2020.02.06, Sounds 2.5.1 successfully running on my Windows 10 “Shack” machine, with WSJT-X and Amateur Contact Log (ACL).

 

I am in the process of installing same stack on my laptop.  I’ve successfully installed WSJT-X, and have installed JTAlert 2.15.11.  I launch JTAlert (doesn’t matter which I start with menu bar or not), the process shows the “Reading Settings Data Standby” window.  The “Setup Callsign” window is present but not accessible either via the Windows ALT-TAB or via Task Manager’s selection on the item to move it to the foreground.  ka

I de-installed release 2.15.11, and installed 2.15.10.  Same story.  I de-installed release 2.15.10 and tried 2.15.9, same story. 

 

Then I went back to my notes and followed them exactly.  I installed JTAlert 2.15.9, then Sounds, then Database, and then launched.

 

In all cases, I can’t see the “Setup Callsign” window.  I know it’s there because I can see it from task manager (see attached png).  I just can’t get to it. 

 

I’ve done a quick search and I realize this appears to the be first time this has happened. 

 

BTW I also tried copying the HamApp AppData from the Shack machine (where things work) to the Laptop for only 2.15.9.  Still no joy.

 

I’m all out of ideas, unless there is a command line parameter invocation which accepts a call sign or there is some point of corruption in a registry entry or directory I don’t know about. 

 

At this point, I’ve de-installed JTAlert, Sounds and Database.  I have not (but will at some point) clean out the AppData HamApp directory. 

 

Any thoughts?  (I also realize this is likely a “Bill” problem; if you have any suggestions I’m happy to chase them down and report back)….

 

73

Bill

N0NYH

Bill,

You have a couple of options, a command line parameter or a Registry entry.
  • Add this parameter to the command-line used to start JTAlert, /callsign=N0NYH

  • Add a Registry string (REG_SZ) under "HKEY_CURRENT_USER\Software\HamApps", with a name of "callsign" and a value of "N0NYH"

de Laurie VK3AMA



locked Wanted VE Province Alert

WB8ASI Herb
 

Hi Laurie,   I'm using 2.15.11 Beta Build 0010.  It appears that the new VE Province Alert is not using the LOTW confirmation filter.  It is showing worked, but not yet confirmed, as no longer Wanted.  Thanks. 73, Herb WB8ASI


locked Re: Can't download JTAlert 2.15.11

Tom Gregor
 

GM de Laurie VK3AMA:

tnx for turning my attention to my AVAST installation. Yes, you were correct and I have now successfully updated to the latest version. Interestingly, I don't recall a previous issue where AVAST prevented/interfered with my ability to download a file. Live and learn...   

My thanks for all you do in providing top-notch software. Well done.

tnx es 73 de K3SSB

Tom G, Sr.


locked Re: Users with missing B4s, some questions to help isolate the cause.

Bobby Chandler
 

The B4 problem appears to have started in the 2.25.9 version. The 2.15.8 looks OK.

Bobby/N4AU


locked Re: JTAlert 2.15.9, 2.15.10, 2.15.11 Callsign Setup Window Not Accessible on Initial Execution after Install on Win10 Laptop

Michael Black
 

On Friday, March 6, 2020, 06:03:38 AM CST, Bill Franzen <wgfranzen@...> wrote:


Good Morning. 

 

I’ve had a copy of JTAlert 2.15.9, database 2020.02.06, Sounds 2.5.1 successfully running on my Windows 10 “Shack” machine, with WSJT-X and Amateur Contact Log (ACL).

 

I am in the process of installing same stack on my laptop.  I’ve successfully installed WSJT-X, and have installed JTAlert 2.15.11.  I launch JTAlert (doesn’t matter which I start with menu bar or not), the process shows the “Reading Settings Data Standby” window.  The “Setup Callsign” window is present but not accessible either via the Windows ALT-TAB or via Task Manager’s selection on the item to move it to the foreground.  ka

I de-installed release 2.15.11, and installed 2.15.10.  Same story.  I de-installed release 2.15.10 and tried 2.15.9, same story. 

 

Then I went back to my notes and followed them exactly.  I installed JTAlert 2.15.9, then Sounds, then Database, and then launched.

 

In all cases, I can’t see the “Setup Callsign” window.  I know it’s there because I can see it from task manager (see attached png).  I just can’t get to it. 

 

I’ve done a quick search and I realize this appears to the be first time this has happened. 

 

BTW I also tried copying the HamApp AppData from the Shack machine (where things work) to the Laptop for only 2.15.9.  Still no joy.

 

I’m all out of ideas, unless there is a command line parameter invocation which accepts a call sign or there is some point of corruption in a registry entry or directory I don’t know about. 

 

At this point, I’ve de-installed JTAlert, Sounds and Database.  I have not (but will at some point) clean out the AppData HamApp directory. 

 

Any thoughts?  (I also realize this is likely a “Bill” problem; if you have any suggestions I’m happy to chase them down and report back)….

 

73

Bill

N0NYH

 

 

 

 

 


locked JTAlert 2.15.9, 2.15.10, 2.15.11 Callsign Setup Window Not Accessible on Initial Execution after Install on Win10 Laptop

Bill Franzen
 

Good Morning. 

 

I’ve had a copy of JTAlert 2.15.9, database 2020.02.06, Sounds 2.5.1 successfully running on my Windows 10 “Shack” machine, with WSJT-X and Amateur Contact Log (ACL).

 

I am in the process of installing same stack on my laptop.  I’ve successfully installed WSJT-X, and have installed JTAlert 2.15.11.  I launch JTAlert (doesn’t matter which I start with menu bar or not), the process shows the “Reading Settings Data Standby” window.  The “Setup Callsign” window is present but not accessible either via the Windows ALT-TAB or via Task Manager’s selection on the item to move it to the foreground.  ka

I de-installed release 2.15.11, and installed 2.15.10.  Same story.  I de-installed release 2.15.10 and tried 2.15.9, same story. 

 

Then I went back to my notes and followed them exactly.  I installed JTAlert 2.15.9, then Sounds, then Database, and then launched.

 

In all cases, I can’t see the “Setup Callsign” window.  I know it’s there because I can see it from task manager (see attached png).  I just can’t get to it. 

 

I’ve done a quick search and I realize this appears to the be first time this has happened. 

 

BTW I also tried copying the HamApp AppData from the Shack machine (where things work) to the Laptop for only 2.15.9.  Still no joy.

 

I’m all out of ideas, unless there is a command line parameter invocation which accepts a call sign or there is some point of corruption in a registry entry or directory I don’t know about. 

 

At this point, I’ve de-installed JTAlert, Sounds and Database.  I have not (but will at some point) clean out the AppData HamApp directory. 

 

Any thoughts?  (I also realize this is likely a “Bill” problem; if you have any suggestions I’m happy to chase them down and report back)….

 

73

Bill

N0NYH

 

 

 

 

 


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

8861 - 8880 of 36983