Date   

locked Re: F5 Text message operation

HamApps Support (VK3AMA)
 

On 30/04/2021 10:10 am, WB5JJJ - George wrote:
I've been caught by this a couple of times.  

I start typing a response to an F5 message while calling CQ.  When a NEW station calls me back, their call replaces the call in the DX Call (WSJTx) and also in the F5 message window.  So, when I click send, it goes to the NEW call and not the one I was actually responding to.  So far they have gone to non-users, but I have to retype the message and make sure it goes to the right person.  

Two things as suggestions.  1)  Be able to copy and paste in the F5 window and 2) keep the original call as the recipient until after send is clicked.  

In the mean time, I just have to NOT be calling CQ or hopefully nobody will just call me out of the blue, from their history and make double sure I'm sending to the right person before I hit send.  

Still adjust to the new Callsign window, but getting there.  
--
73's
George - WB5JJJ

Copy and Paste is already supported by the message edit field. You can even call up previously saved messages via the selector below that edit field.

From the release notes of the next release, 2.50.1, due in a few days...
    - Messaging window: WSJT-X DX Call changes now no longer auto populate the
       Callsign field if a message is already being composed. That is if the
       message field contains text, the DX Call change is ignored.

de Laurie VK3AMA



locked F5 Text message operation

WB5JJJ - George
 

I've been caught by this a couple of times.  

I start typing a response to an F5 message while calling CQ.  When a NEW station calls me back, their call replaces the call in the DX Call (WSJTx) and also in the F5 message window.  So, when I click send, it goes to the NEW call and not the one I was actually responding to.  So far they have gone to non-users, but I have to retype the message and make sure it goes to the right person.  

Two things as suggestions.  1)  Be able to copy and paste in the F5 window and 2) keep the original call as the recipient until after send is clicked.  

In the mean time, I just have to NOT be calling CQ or hopefully nobody will just call me out of the blue, from their history and make double sure I'm sending to the right person before I hit send.  

Still adjust to the new Callsign window, but getting there.  
--
73's
George - WB5JJJ
Hamshack Holine #4969


locked Re: Issues Relating to Recently-Installed v2.50.0

HamApps Support (VK3AMA)
 

My answers inline...

On 30/04/2021 2:18 am, Paul wrote:

I recently installed JTAlert 2.50.0 and I love the new, flexible callsigns display.  That is a great enhancement.  Thank you for a fabulous upgrade.

However, I am running into some issues, namely:

  • When logging a completed contact, the instant the ‘logging successful’ confirmation window pops up, the Callsigns window goes blank, and I have not found any way to prevent this.  In the past, I was able to select the next station to be contacted while the logging was occurring.  Now I have to wait a full cycle and relocate the station of interest within all the callsigns displayed.
Turn off the "Clear Callsigns display after logging" option in the main JTAlert Settings window, "Logging" section. Look under the "Logging Options". You will need to scroll the list of settings down to reveal the required checkbox.


  • For some reason I am also getting a large Decodes window opening whenever I launch the app, and I have tried but failed to get that to stop. I have to manually close the window every time. (my computer screen is not large, and I cannot accommodate any ‘extra’ windows)
Turn off the "Restore window when JTAlert is started" option in the main JTAlert Setting window. "Window -> Decodes" section.


  • FYI, I have seen your recommendation to use UDP Server address 239.255.0.0 in WSJT-X and, of course, the downloaded newest WSJT-X release installed with those settings but, unless I changed that back to 127.0.0.1, my JTAlert Callsigns window always remained blank – nothing was being displayed.
Very likely you didn't perform the required change in JTAlert when switching WSJT-X to use multicast. Make sure the "Settings -> WSJT-X UDP Multicast on Loopback" menu of the main JTAlert window is ticked. The Help file (not the 2.50 features help) has instructions for the correct setup. See the "WSJT-X UDP Setup" topic (its at the root level) in that help.


  • I had thought that callsign clicking actions are dictated by WSJT-X.  Is that correct?  I ask because I am finding the double-click on a callsign for some reason behaves differently when done within the WSJT-X Band Activity window or within the JTAlert Callsigns window.  Double-clicking a decoded callsign in WSJT-X moves the RX frequency focus and enables TX.  Double-clicking a displayed callsign within the JTAlert moves the RX frequency focus but does not enable TX.  Is that correct/as-designed?
The decision to go into transmit in response to a callsign click event is controlled by WSJT-X. JTAlert cannot control that behavior. There is no mechanism in the command sent to WSJT-X to tell it to go into transmit. JTAlert simply tells WSJT-X this Callsign of a specific decode was clicked. This is how the WSJT-X API is designed, there is no support within the API to instruct WSJT-X to go into transmit in response to a callsign click.


Related to that last item, I would very much like to have actions for both single- and double-click, whereby a single-click on a station of interest focusses the RX frequency accordingly, and a double-click both focusses the RX frequency and enables TX.  There are many times when I merely wish to observe a station for a brief period before calling – usually to wait until his current contact is finishing before calling.  If, as I had thought, clicking actions are controlled solely by WSJT-X, then I will make my suggestion/request with that group.

See my previous comment about API limitations in WSJT-X.

73, and thanks again for all your efforts…  Paul (VE3PS)


73
de Laurie VK3AMA


locked Re: JT Alert will not run - V 2.50.0 & 2.16.17

HamApps Support (VK3AMA)
 

On 29/04/2021 2:22 pm, W Ramsey wrote:

I’m on latest updated version of Windows 10 64x Home (20H2).  PC has 32GB memory, Intel i9-10850K CPU and 2TB SSD.  WSJT-X 2.3.1 functions properly.   HamAppSound 2.5.3 and HamAppsDatabases 2021.04.20 were successfully installed.

 

I’ve tried both JT Alert versions 2.50.0 and 2.16.17.  Both install successfully with no errors.   However each fail to run after the “Reading Settings Data – Standby” pop-up message appears then disappears.  Version 2.16.17 usually shows a Line 41603 error.  Net 5 is installed for version 2.50.0 and is correct version based on confirmation in the CMD window. 

 

I’ve uninstalled and reinstalled both WSJT-X and JT-Alert versions 2.50.0 and 2.16.17 five (5) times.  I restarted computer after each uninstall and reinstall and the same issue is present – JT-Alert fails to run.

 

I tried deleting the config.sqlite file and JT Alert still fails to launch.  The only JT Alert process that loads temporarily during program start is the “Audio & Visual Alerts for WSJT-X. (32 bit)” process.  This process starts and then terminates within one second.  

 

I use N3FJP’s Amateur Contact Log so having JT-Alert functioning really speeds up QSO logging – when JT-Alert is functioning.

 

Not sure what the issue is but I have successfully used prior versions of WSJT-X and JT-Alert for years without issues.

 

Ideas appreciated.

 

Thanks –

 

William


William,

If repeated installs and different version installs result in an error condition it suggests something common on your PC, that doesn't change with the different installs is likely the cause. One candidate is the JTAlert config file as it doesn't get touched during multiple installs. Since you still received the error after removing the config file, that rules out a corrupt config as the cause.

My best guess is that your PC protection software (what do you use?) has now taken a dislike to JTAlert. Check that it is not now blocking JTAlert. You may have to flag JTAlert as safe to get past its interference.

Worth checking is your Windows Event log, there may be something in there that can provide a clue.

If I was a betting person, I would put my money of Protection software being the issue.

de Laurie VK3AMA



locked Re: Issues Relating to Recently-Installed v2.50.0

Paul
 

Laurie,

I apologize for emailing you, but I have been unable to figure out how to post a reply within any thread I read.  There is no Reply ‘button’ as there is with other groups I belong to.

I recently installed JTAlert 2.50.0 and I love the new, flexible callsigns display.  That is a great enhancement.  Thank you for a fabulous upgrade.

However, I am running into some issues, namely:

  • When logging a completed contact, the instant the ‘logging successful’ confirmation window pops up, the Callsigns window goes blank, and I have not found any way to prevent this.  In the past, I was able to select the next station to be contacted while the logging was occurring.  Now I have to wait a full cycle and relocate the station of interest within all the callsigns displayed.
  • For some reason I am also getting a large Decodes window opening whenever I launch the app, and I have tried but failed to get that to stop. I have to manually close the window every time. (my computer screen is not large, and I cannot accommodate any ‘extra’ windows)
  • FYI, I have seen your recommendation to use UDP Server address 239.255.0.0 in WSJT-X and, of course, the downloaded newest WSJT-X release installed with those settings but, unless I changed that back to 127.0.0.1, my JTAlert Callsigns window always remained blank – nothing was being displayed.
  • I had thought that callsign clicking actions are dictated by WSJT-X.  Is that correct?  I ask because I am finding the double-click on a callsign for some reason behaves differently when done within the WSJT-X Band Activity window or within the JTAlert Callsigns window.  Double-clicking a decoded callsign in WSJT-X moves the RX frequency focus and enables TX.  Double-clicking a displayed callsign within the JTAlert moves the RX frequency focus but does not enable TX.  Is that correct/as-designed?

Related to that last item, I would very much like to have actions for both single- and double-click, whereby a single-click on a station of interest focusses the RX frequency accordingly, and a double-click both focusses the RX frequency and enables TX.  There are many times when I merely wish to observe a station for a brief period before calling – usually to wait until his current contact is finishing before calling.  If, as I had thought, clicking actions are controlled solely by WSJT-X, then I will make my suggestion/request with that group.

73, and thanks again for all your efforts…  Paul (VE3PS)


locked CHat support without WSJTx

Franco
 
Edited

HI All

Of JTalert I also gladly use his CHAT that with F5 makes me reach the correspondent to pass him some info.

SUPER!
 
But I can use the JTalert CHAT only if I have activated WSJTx first, then I start JTalert and finally close the WSJTx for to run use another FT8 app which is not wsjtx

Would it be possible to start the JTalert (CHAT) without WSJTx or do I always have to first start WSJTx, then JTalert and then close Wsjtx for to open the other FT soft ??
 
I don't always use WSJTx and I often use another one for FT8/4 which unfortunately does not want to make udp compatible with the excellent JTalert. :-(

Thanks for info
Franco


locked Re: JTAlert X - HRD log scan careened past 1085 records and hit a brick wall in memory crashed and burned

Ron W3RJW
 
Edited

Let me add a few things:

I have a Microsoft Access log with 23,000 contacts and it works just fine. Many people have much bigger logs.

The biggest problem is that many of us have/had really old Access drivers. The act of creating a new log and importing old QSO's, as Laurie describes, forces the system to update those drivers.  This fixes a lot of problems, but maybe will not fix yours.

A comprehensive discussion on the HRD web site describes the details, including how to check your drivers:
https://www.hamradiodeluxe.com/blog/The-Problem-With-Microsoft-Access.html


If you really feel the need to change to MySQLdatabase, there is an instruction link on the page above.

Just let me say that updating HRD will not fix driver problems.It's a separate issue.

--
73
Ron, W3RJW

FTdx-5000, Timewave Navigator, WSJT-x 2.4.0 rc4, JTAlert 2.50.0, HRD Deluxe v6.7.0.323
FTdx-3000, SignaLink USB


locked JT Alert will not run - V 2.50.0 & 2.16.17

W Ramsey <km4jok@...>
 

I’m on latest updated version of Windows 10 64x Home (20H2).  PC has 32GB memory, Intel i9-10850K CPU and 2TB SSD.  WSJT-X 2.3.1 functions properly.   HamAppSound 2.5.3 and HamAppsDatabases 2021.04.20 were successfully installed.

 

I’ve tried both JT Alert versions 2.50.0 and 2.16.17.  Both install successfully with no errors.   However each fail to run after the “Reading Settings Data – Standby” pop-up message appears then disappears.  Version 2.16.17 usually shows a Line 41603 error.  Net 5 is installed for version 2.50.0 and is correct version based on confirmation in the CMD window. 

 

I’ve uninstalled and reinstalled both WSJT-X and JT-Alert versions 2.50.0 and 2.16.17 five (5) times.  I restarted computer after each uninstall and reinstall and the same issue is present – JT-Alert fails to run.

 

I tried deleting the config.sqlite file and JT Alert still fails to launch.  The only JT Alert process that loads temporarily during program start is the “Audio & Visual Alerts for WSJT-X. (32 bit)” process.  This process starts and then terminates within one second.  

 

I use N3FJP’s Amateur Contact Log so having JT-Alert functioning really speeds up QSO logging – when JT-Alert is functioning.

 

Not sure what the issue is but I have successfully used prior versions of WSJT-X and JT-Alert for years without issues.

 

Ideas appreciated.

 

Thanks –

 

William

 

 


locked Re: JTAlert X - HRD log scan careened past 1085 records and hit a brick wall in memory crashed and burned

Stephanie WX3K
 

Yes, using MS Access type logbook at the moment. Im a little behind on HRD upgrades and perhaps it may be time to revisit that in light of this recent issue. I seem to remember the MariaDB coming up somewhere else too. Oh ! I converted over to Maria DB from MySQL in CQRlog so I am familiar with at least the Linux version of it. :-)

Appreciate the feedback Laurie ! Hope I can get JT Alert up and running this weekend. Really looking for the notification features in it.

73
Stephanie WX3K


locked Re: JTAlert X - HRD log scan careened past 1085 records and hit a brick wall in memory crashed and burned

Laurie, VK3AMA
 

On 29/04/2021 9:01 am, Stephanie WX3K wrote:
Such self destructive behavior for an app :-)

Installation ran well for version 2.50.0. Installed .NET 5 will no issues for 64 bit OS. JTalert acknowledged a valid .NET 5 installation existed during installation.

Windows 10 Pro(64 bit) on a Dell Inspiron 3670 12 GB ram

Did the program miss a turn somewhere ? LOL
I note that the failure is occurring while scanning a HRDLogbook log. Is it an MSAccess type log? There have been a number of problems in recent months involving MSAccess Logs. In most cases exporting the log, creating a new log and importing the old QSOs than setting JTAlert to use the new log has been sufficient to restore normal operation. In a very small number of cases creating a new MSAccess log didn't seem to  provide a 100% fix. Switching to using a MariaDB log type worked 100%.

HRD recommend abandoning MSAccess and switching to MariaDB. They have a video somewhere outlining the steps needed, it is not overly difficult and in the end your HRDLogbook experience with be faster and more reliable.

de Laurie VK3AMA


locked JTAlert X - HRD log scan careened past 1085 records and hit a brick wall in memory crashed and burned

Stephanie WX3K
 
Edited

Such self destructive behavior for an app :-)

Installation ran well for version 2.50.0. Installed .NET 5 will no issues for 64 bit OS. JTalert acknowledged a valid .NET 5 installation existed during installation.

Windows 10 Pro(64 bit) on a Dell Inspiron 3670 12 GB ram

Did the program miss a turn somewhere ? LOL




locked Re: Callsigns window appeared too small to be usable and readjusted

HamApps Support (VK3AMA)
 

On 29/04/2021 6:37 am, Gary Yarbrough via groups.io wrote:
I do shutdown all programs and the radio upon completion of a normal day with the radio on a little over 12 hours.  This morning on restarting radio and all programs normally run I got the small callsign window with no other abnormal events.

73, Gary
KE5TD

Tnx Gary.

Until I release a confirmed fix, you're best to leave the Callsigns window "size locked" checkbox unticked so that you can quickly drag the window to the correct size when it happens again. It is unlikely that a fix will be in the 2.50.1 release, due within a week.

de Laurie VK3AMA


locked Re: unable to launch program

HamApps Support (VK3AMA)
 

On 28/04/2021 8:43 pm, dpaschal@... wrote:
What version of Windows, 7.1, 8.1 or 10? 10 - latest update.
What bit type 32bit (x86) or 64bit (x64)? x64

Check TaskManager, is JTAlertV2,Manager.exe running?  None of these are running.  I rebooted too.

If JTAlertV 2.Manager.exe is not running, that will cause errors within the main JTAlert program. While being a separate process, it is critical to JTAlert operation. Both JTAlert.exe and JTAlertV2.Manager.exe need to be running.

Perhaps your PC protection software is interfering with the launching of the Manager process.

Another possibility is that you don't have the correct .NET 5 Desktop Runtime installed. What does "dotnet --info" produce when you type it into a Windows command-prompt window? Post an image of the result. eg. this is mine...


You could also try starting JTAlert without a config file. There may be something in the config that is tripping up JTAlert. See the JTAlert Help file (not the 2.50.0 features help), "Troubleshooting -> Setting Changes Not Remembered" topic. It explains where to find the config file. It may be worth trying to restore an old backup of the config.sqlite file, explained in that help topic, before proceeding to starting JTAlert without a config file. All Help files are available in the "HamApps JTAlert" Windows start-menu group if you're unable to access from within JTAlert.

de Laurie VK3AMA



locked Re: Callsigns window appeared too small to be usable and readjusted

Gary Yarbrough, KE5TD
 

Laurie,

Nothing unusual in the  shutdown. I normally run two instances of WSJTx and JTAlert both are started manually and shutdown manually in reverse order.  The radio is Flex 6500 and operating system Win 10 Pro updated daily. 

I do shutdown all programs and the radio upon completion of a normal day with the radio on a little over 12 hours.  This morning on restarting radio and all programs normally run I got the small callsign window with no other abnormal events.

73, Gary
KE5TD

On Wednesday, April 28, 2021, 03:03:26 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 29/04/2021 12:17 am, Gary Yarbrough via groups.io wrote:
Okay it happened again this morning and I am attaching the two files.

73, Gary
KE5TD

Tnx Gary!

The files indicate that the small size of the window is due to incorrect values being recorded in the config file and then being applied when next starting. Specifically, the size recorded was ...
    "Width": 160.0,
    "Height": 28.0,

These values are very wrong. There is likely a defect somewhere in the code causing this, but what and where is the question.

Is there anything unusual in your shutting down of JTAlert? How do you perform the JTAlert shutdown or do you leave it running and discover the incorrect size when you return to your PC?

de Laurie VK3AMA




locked Re: unable to launch program

HamApps Support (VK3AMA)
 

On 28/04/2021 8:43 pm, dpaschal@... wrote:
OM (name?, callsign?) - I am not certain what you mean here

I start all messages with "OM (name?, callsign?)" if the message to which I am replying was not signed with neither a Name or Callsign identifying the sender. You email address also does not contain any clue as to the sender. It's my way of asking to whom am I communicating?

It is common courteous to sign messages to a public forum. People should know to whom they are communicating.

de Laurie VK3AMA


locked Re: Q65 decodes not showing

HamApps Support (VK3AMA)
 

On 29/04/2021 5:16 am, K0GU wrote:
I don't see any Q65 calls in the JTAlert window either. But I thought that wasn't enabled yet from an earlier announcement. So I haven't been trying. I just worked someone on Q65 and nada in the window.
--
73,  Jay  K0GU

Non Q65 decodes display in 2.50.0 is a defect, despite the release notes claiming it was fixed.
It has been corrected and tested for the 2.50.1 release (likely within a week).

de Laurie VK3AMA


locked Re: Callsigns window appeared too small to be usable and readjusted

HamApps Support (VK3AMA)
 

On 29/04/2021 12:17 am, Gary Yarbrough via groups.io wrote:
Okay it happened again this morning and I am attaching the two files.

73, Gary
KE5TD

Tnx Gary!

The files indicate that the small size of the window is due to incorrect values being recorded in the config file and then being applied when next starting. Specifically, the size recorded was ...
    "Width": 160.0,
    "Height": 28.0,

These values are very wrong. There is likely a defect somewhere in the code causing this, but what and where is the question.

Is there anything unusual in your shutting down of JTAlert? How do you perform the JTAlert shutdown or do you leave it running and discover the incorrect size when you return to your PC?

de Laurie VK3AMA




locked Re: Q65 decodes not showing

K0GU
 

I don't see any Q65 calls in the JTAlert window either. But I thought that wasn't enabled yet from an earlier announcement. So I haven't been trying. I just worked someone on Q65 and nada in the window.
--
73,  Jay  K0GU


locked Re: Callsigns window appeared too small to be usable and readjusted

Gary Yarbrough, KE5TD
 



On Monday, April 26, 2021, 02:58:37 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 27/04/2021 5:08 am, Gary Yarbrough via groups.io wrote:

I also had the same experience two days, but I used the F3 key to resize and it has not repeated.

Gary
KE5TD

Gary,

If this occurs again, if your able, I would appreciate getting a copy of the Callsigns window config files before you resize the window. I need to see what sizes are recorded in the files when this occurs.

The files are "Callsigns_1.config" and "Callsigns_1.config.json" and are located at %localappdata%\HamApps\JTAlert\
KE5TD\Config\

The files are small, ~3KB.

Thanks
de Laurie VK3AMA

Laurie,

Okay it happened again this morning and I am attaching the two files.

73, Gary
KE5TD


locked Re: unable to launch program

dpaschal@...
 

OM (name?, callsign?) - I am not certain what you mean here.  Callsign is WB4IHY

What version of Windows, 7.1, 8.1 or 10? 10 - latest update.
What bit type 32bit (x86) or 64bit (x64)? x64

Check TaskManager, is JTAlertV2,Manager.exe running?  None of these are running.  I rebooted too.

1881 - 1900 of 36363