Date   

locked Re: Not logging some QSOs to DXKeeper. #DXLAB

HamApps Support (VK3AMA)
 

On 7/07/2020 11:05 am, g4wjs wrote:
Maybe if a logging event takes an extended time, due to Internet actions on my very poor shack WiFi connection, the next QSO logged could cause JTAlert to start a new connection while DXKeeper was still finishing its end of the last connection.

Bill,

With the current code, it is not possible to initiate a second logging event when the first hasn't completed or timed-out.

The code is synchronous, with no async callbacks. Once JTAlert has entered the logging/confirmation code (a single method), everything blocks until that method is left. There are two possible exit paths from the logging method (success or failure) and both perform a
TCPCloseSocket operation.

de Laurie VK3AMA


locked Re: Phantom Wanted Call Audio

HamApps Support (VK3AMA)
 

On 7/07/2020 11:48 am, Paul AC9O wrote:
I am having a Wanted Call audio alert without the corresponding color highlight in either JTAlert or WSTX.

I added the 13 Colonies calls and the 3 bonus calls. I worked the 13 and only the 3 remain.

The phantom Wanted Call audio started after working 11 or 12.

I can't figure out what call is triggering the alert. The 3 listed are not in the decodes.

Has anyone else had this happen?

Becomes a mute issus after tomorrow so no big deal.

The Wanted Call is likely generating one or more other Alerts. While all Alerts triggered will generate each of their associated sound files, only one Alert will dictate the coloring of the Callsign and that will be the Alert with the highest priority.

By default the Wanted Callsign Alert is below the priorities of all the other Wanted Alerts.
Move the Wanted Callsigns Alert up the priority list.

   

de Laurie VK3AMA


locked Phantom Wanted Call Audio

Paul AC9O
 

I am having a Wanted Call audio alert without the corresponding color highlight in either JTAlert or WSTX.

I added the 13 Colonies calls and the 3 bonus calls. I worked the 13 and only the 3 remain.

The phantom Wanted Call audio started after working 11 or 12.

I can't figure out what call is triggering the alert. The 3 listed are not in the decodes.

Has anyone else had this happen?

Becomes a mute issus after tomorrow so no big deal.



Thanks and 73
Paul, AC9O


locked Re: s in green dot

HamApps Support (VK3AMA)
 

On 7/07/2020 11:10 am, richard clare wrote:
What does the s in the green dot/no dot signify? Richard wb6ewm

WSJT-X has your rig in Split Mode perhaps. I see the "S" visibility toggle when I toggle the split mode of my rig.

de Laurie VK3AMA


locked Re: Wanted Call needs to ignore Filters

HamApps Support (VK3AMA)
 

On 4/07/2020 9:20 am, WB5JJJ - George wrote:
If you have a Wanted Call and Filters>>QSL Membership Options>>LoTW member selected, the wanted call will NOT alert.  

Perhaps the Filter section should be ignored for any wanted calls, mostly since many of those rare (wanted) calls may not have Internet access or use LoTW.  If No QSL Filters is selected, the grid is filled with everybody, including what you are looking for, which makes it hard to find what call alerted you.  

A current example is the 13 Colonies Special Event.  They do not use LoTW, but if you have that for a requirement, then none of them you have listed as a Wanted Call will be announced.  If you deselect it (set to No), then the grid is overrun with calls.  
--
73's
George - WB5JJJ
George,

Excluding the Wanted Call Alert from obeying any of the Alert Filters set is on the TODO list, but I don't know when that will be implemented, sorry.

All is not lost, since the Wanted Call Alert has its own (user-settable) coloring, it should not be an onerous task to find the Callsign in among the many Callsigns displayed at the end of a period when Filters are not active. It should stand-out, then a single click on the Callsign will setup the WSJT-X DXCall and generate the necessary messages, you just need to "Enable TX". Looking for the alerted Callsign in the WSJT-X window is not the right way to go about it when JTAlert is full of Callsigns, IMO.

de Laurie VK3AMA


locked s in green dot

richard clare
 

What does the s in the green dot/no dot signify? Richard wb6ewm


locked Re: transmitter keying

richard clare
 

Figured it out. thanks for steering me in that direction. Default sound card setting!


locked Re: Not logging some QSOs to DXKeeper. #DXLAB

g4wjs
 

On 05/07/2020 23:36, HamApps Support (VK3AMA) wrote:
On 5/07/2020 9:25 am, g4wjs wrote:

Hi Laurie,

a socket close call is not the same as doing a socket shutdown call first. Is this code AutoIT or .Net?


--
73
Bill
G4WJS.

AutoIT. The TCP logging component in JTAlert is not part of the new .NET based JTAlertV2.Manager code. What AutoIT does under the hood is unknown, it only offers a TCPCloseSocket command, but that is likely their friendly description of the function executing the low-level TCP instructions.

I just stopped the auto logging to DXKeeper, 20 hours continuous, logging every 30 seconds. Not a single QSO was lost, 2410 records sent and logged.

Before I shutdown the Test, I went into DXKeeper and deliberately changed the Base Port of the Network Service (from 52000 to 62000) which as expected stopped DXK from receiving the logging instructions. JTAlert correctly identified an inability to connect (recorded a standard 10060 error) after 10 retries. Resetting the DXK port back to 52000 and logging resumed.

Perhaps a Network Service restart is all that is needed, rather than a DXKeeper restart if the failed logging occurs again.

At this time, I don't know where else to look.

de Laurie VK3AMA

Hi Laurie,

RR on all, I did look for the sources of the AutoIT TCP Socket code but that part seems to be closed source. I do note that by default a socket close() operation on on Windows makes a reasonable attempt to do a graceful shutdown, so I doubt that closing the socket after each logging event is the source of this issue.

Did you look at the support request from Steve M5BFL, it was his PC running at my shack where the problem occurred, I wonder if there was anything helpful in the debug files?

Another possibility is that DXKeeper has an issue with handling multiple TCP/IP client connections concurrently. Maybe if a logging event takes an extended time, due to Internet actions on my very poor shack WiFi connection, the next QSO logged could cause JTAlert to start a new connection while DXKeeper was still finishing its end of the last connection. Steve was very busy running a frequency using FT4 at  the time so QSOs were being logged at a fast rate.


--
73
Bill
G4WJS.


locked Re: JTAlertV2.Manager will not start

HamApps Support (VK3AMA)
 

On 6/07/2020 3:19 am, Jan Eliasson wrote:
I am using JTAlert 2.16.8 on a Windows 7 Professional 64 bits computer.

JTAlertV2.Manager will not start. I can see atempts in processes in the taskmanager. i have tried to disable the firewall (Windows) and Avast Anti virus,

I can not exactly say when it stopped working, but my last uploaded QSO in Clublog was from the beginning of april. So it started with version 2.16.3 or 2.16.4. 

73 de SM7NDX, Jan

Jan,

Please do the following...
  • Uninstall JTAlert using Windows Control Panel.
  • Using Windows File Explorer, navigate to the folder where you had JTAlert installed.
  • Delete any remaining files and folders in your old JTAlert install directory.
  • Install JTAlert.

After having done this cleanup and reinstall start JTAlert and leave running for 3 minutes then send another support request.

Thanks

de Laurie VK3AMA


locked Re: JTAlertV2.Manager will not start

HamApps Support (VK3AMA)
 

On 6/07/2020 7:06 am, John wrote:
If you find a solution please let me know. I'm having the same problem. Messages to and from Laurie haven't come up with a solution. I asked if there was a way to force it to start. Laurie said it's hard wired in the program.
After many attempts I occasionally get it started, then after using it I minimize it rather than closing it, that works great until a computer restart is needed.
73, John

John,

Please use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

After sending your support request, please do the following...
  • Uninstall JTAlert using Windows Control Panel.
  • Using Windows File Explorer, navigate to the folder where you had JTAlert installed.
  • Delete any remaining files and folders in your old JTAlert install directory.
  • Install JTAlert.

After having done this cleanup and reinstall start JTAlert and leave running for 3 minutes thensend another support request.


Thanks

de Laurie VK3AMA


locked Re: Click on JTAlert and get PathFinder to see "Call sign" ?

HamApps Support (VK3AMA)
 

On 7/07/2020 5:30 am, KD7YZ Bob wrote:
Following some 'search' through the archives, I also tried a previous version that DID have the TEST function for the DXLabSuite connections.
I see FAIL ... but dunno how that would be fixed.

When I hit LOG after a contact ... as JTAlert puts it up, once it's logged, seen in DXKeeper, THEN Pathfinder shows the callsign.
A "Connect Fail" message indicates that JTAlert was unable to establish a DDE connection. All DXLab lookups utilize a DDE connection and instruction.

The Pathfinder Callsign getting populated after logging is not done by JTAlert, it is done by DXKeeper.

The most likely cause of a DDE connection failure is Windows preventing the connection due to a permissions level mismatch. Very likely you have all the DXLab suite of programs set to run as Administrator or DXLab Launcher is set to run elevated which will automatically cause all the programs it launches to be elevated. Windows will prevent any normal privileged program (JTAlert) from communicating via DDE with elevated programs.

There is NEVER a need to run the DXLab suite of programs elevated provided you have DXLab installed outside the Windows protected "Program Files..." directory tree.

de Laurie VK3AMA


locked Re: transmitter keying

HamApps Support (VK3AMA)
 

On 7/07/2020 5:01 am, richard clare wrote:
When JT Alerts logs qso to DX Labs, my Yaesu mk V transmits at low power for about 3 seconds, The first time it has ever done this. Does anybody have a clue for me?

This is due to the standard Windows sound emitted after logging and you having the Windows default sound device set to be used by WSJT-X.

You should not be running WSJT-X set to use the default Windows audio device, unless your PC has a single sound card, in which case you should disable all Windows sounds and set JTAlert to have Sounds OFF.

FWIW, The next JTAlert release has replaced the remaining Sound Play events that utilize the standard Windows notification sounds, as used by the Logging success/failure popup and some other critical startup errors, with a user settable sound file (like all the Wanted Alerts) that is played on the JTAlert selected sound device.

de Laurie VK3AMA


locked Re: How are JTAlert messages sent?

Larry W5EIT
 

Thanks for the explanation, Bill.  I was using this method to chat with my dad, W5JE.  He thought the data were sent via FT8, but the amount and accuracy of the data didn't fit with how FT8 works.

And I totally agree, if the signal reports aren't sent/received totally over the air, they're not valid.

Thanks again.

- Larry - W5EIT


locked Re: Click on JTAlert and get PathFinder to see "Call sign" ?

KD7YZ Bob
 

Following some 'search' through the archives, I also tried a previous version that DID have the TEST function for the DXLabSuite connections.
I see FAIL ... but dunno how that would be fixed.

When I hit LOG after a contact ... as JTAlert puts it up, once it's logged, seen in DXKeeper, THEN Pathfinder shows the callsign.


locked Re: How are JTAlert messages sent?

g4wjs
 

On 06/07/2020 19:05, Larry Floyd wrote:
This is not a question of how to use the messaging feature, it's a question about how the actual information in each text message is sent?  There's a misconception that the information is sent via FT8, but I suspect it's sent via the Internet from JTAlert app to JTAlert app.  Correct?

Thanks.

- Larry - W5EIT
Larry,

they are sent via the Internet using the HamSpots server for routing. I have noticed a couple of JA stations recently sending test messsages that they have sent RR73, if you have not received a confirmation of your sent report over the air then the QSO is *not* valid. If someone attempts to complete a QSO like this using JTAlert text messages then you should ignore the message and continue sending an R+report message and only log the QSO once you have received RRR or RR73 over the air, otherwise it is a busted QSO.



--
73
Bill
G4WJS.


locked Re: transmitter keying

g4wjs
 

On 06/07/2020 20:01, richard clare wrote:
When JT Alerts logs qso to DX Labs, my Yaesu mk V transmits at low power for about 3 seconds, The first time it has ever done this. Does anybody have a clue for me?
Hi Richard,

some sort of VOX keying being used combined with the sound card connected to you rig being the system default sound card.



--
73
Bill
G4WJS.


locked How are JTAlert messages sent?

Larry W5EIT
 

This is not a question of how to use the messaging feature, it's a question about how the actual information in each text message is sent?  There's a misconception that the information is sent via FT8, but I suspect it's sent via the Internet from JTAlert app to JTAlert app.  Correct?

Thanks.

- Larry - W5EIT


locked transmitter keying

richard clare
 

When JT Alerts logs qso to DX Labs, my Yaesu mk V transmits at low power for about 3 seconds, The first time it has ever done this. Does anybody have a clue for me?


locked Re: Not logging some QSOs to DXKeeper. #DXLAB

HamApps Support (VK3AMA)
 

On 5/07/2020 9:25 am, g4wjs wrote:

Hi Laurie,

a socket close call is not the same as doing a socket shutdown call first. Is this code AutoIT or .Net?


--
73
Bill
G4WJS.

AutoIT. The TCP logging component in JTAlert is not part of the new .NET based JTAlertV2.Manager code. What AutoIT does under the hood is unknown, it only offers a TCPCloseSocket command, but that is likely their friendly description of the function executing the low-level TCP instructions.

I just stopped the auto logging to DXKeeper, 20 hours continuous, logging every 30 seconds. Not a single QSO was lost, 2410 records sent and logged.

Before I shutdown the Test, I went into DXKeeper and deliberately changed the Base Port of the Network Service (from 52000 to 62000) which as expected stopped DXK from receiving the logging instructions. JTAlert correctly identified an inability to connect (recorded a standard 10060 error) after 10 retries. Resetting the DXK port back to 52000 and logging resumed.

Perhaps a Network Service restart is all that is needed, rather than a DXKeeper restart if the failed logging occurs again.

At this time, I don't know where else to look.

de Laurie VK3AMA


locked Re: JTalert integration with EQSL - Help

HamApps Support (VK3AMA)
 

On 5/07/2020 3:29 pm, Barry Bettman wrote:
Tonight I spend a couple of hours trying to configure the latest JTalert for eqsl integration but not successful yet.

I enabled the EQSL option and got a message when trying to log from WSJT-X 2.2.2 that the udp 2337 was not talking to wsjt-x.  Then I changed the udp in jtalert to 2337 and when I logged a contact in WSJT-x this time did not get an error; however the call logged into wsjt-x never showed up in eqsl.

I have also searched online for help and istructions on integration jtalert with eqsl, but to no avail.

Can anyone help, please

73,

Barry K6ST

Eqsl integration is easy. set the enable checkbox and make sure you have the "Callsign, Password & QTH Nickname" fields filled in.

   

Uploading to Eqsl (and the other online services) depends on JTAlert being set to log QSOs, so you need to enable your logger in JTAlert. If JTAlert shows "NO Log" in the titlebar than you don't have a logger enabled and there will be no online log uploads.

Uploading to Eqsl is then automatic each time JTAlert receives a QSO logged message from WSJT-X.

You cannot change the UDP port that JTAlert is listening to for WSJT-X messages. That is automatic and is determined by reading the WSJT-X config file.

If your getting UDP error messages from JTAlert, than UDP traffic from WSJT-X will not be received and no QSOs logged (or uploaded) or decoded callsigns shown.

Make sure you have the WSJT-X UDP Server settings correct. eg.

   

If you make any UDP changes, restart both WSJT-X and JTAlert.

If you still have problems, Please use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

de Laurie VK3AMA

7121 - 7140 of 37779