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 in WSJT-X and, of course, the downloaded newest WSJT-X release installed with those settings but, unless I changed that back to, 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)

de Laurie VK3AMA

Join Support@HamApps.groups.io to automatically receive all group messages.