Date   

locked Re: JTAlert is not displaying call signs decode in WSJTX

Charlie Rubenstein
 

In the "About" window, JAlert doesn't show an UDP port being used for decodes.....is that the problem?


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

HamApps Support (VK3AMA)
 

On 4/07/2020 9:14 pm, g4wjs wrote:

all understood Dave, this may have been a different issue from that descripton of Carl's issue. Here 81 QSOs in a row failed to log. No issues prior to that and none afterwards, once DX Keeper was restarted. I have asked Steve, M5BFL, who was operating with his laptop, to send a support request including debug files to Laurie in case there is anything useful in those.


--
73
Bill
G4WJS.
Bill & Dave,

From previous reports and debug files, QSOs that are not making it to DXKeeper are being sent by JTAlert without error. The error checks performed by JTAlert are simple. It checks if it was first able to open a TCP connection to DXKeeper and if an error is thrown when executing the TCPSend command.

JTAlert doesn't maintain an open TCPIP socket connection to DXKeeper, it opens a connection when needed and closes after sending the data or if a TCPSend failure occurs.

I wonder if the volume of logging requests (ie socket create/close events) over a period of time is at the root of the problem.

I'll throw together a test to repeatedly log dummy QSOs to DXKeeper and see what transpires.

de Laurie VK3AMA



locked Re: JTAlert is not displaying call signs decode in WSJTX

Charlie Rubenstein
 

Well, I restarted twice, but same problem. Get the UDP warning.


locked Re: JTAlert is not displaying call signs decode in WSJTX

HamApps Support (VK3AMA)
 

On 5/07/2020 7:30 am, Charlie Rubenstein wrote:
Having the same problem here. I have checked the settings (see below) but don't see a problem. It is giving the warning box about UDP settings. The only thing

You're problem is NOT the same as the original poster, he had some Callsigns missing, your reporting all Callsigns missing. The UDP error message is the clue, if UDP comms between JTAlert and WSJT-X is not working then there will be nothing received by JTAlert and nothing to display.

If Callsigns display worked previously than something has changed. Likely a recent Windows update. A PC restart tends to fix most problems these days with Win10 updates. Try that first.

de Laurie VK3AMA


locked Re: JTAlert is not displaying call signs decode in WSJTX

HamApps Support (VK3AMA)
 

On 5/07/2020 6:37 am, Greg Foster wrote:
This morning I noticed some call sign that were decoded in WSJTX were not being displayed in JTA.

Greg
VE3PJ
Missing Callsigns (not all) is a sign that you have one or more Alert Filters engaged. The missing Callsigns are not passing the Filters like LoTW only, hide non-Alerting, hide B4, etc.


de Laurie VK3AMA


locked Re: JTAlert is not displaying call signs decode in WSJTX

Charlie Rubenstein
 

Here are the settings I have:




locked Re: JTAlert is not displaying call signs decode in WSJTX

Charlie Rubenstein
 
Edited

Having the same problem here. I have checked the settings (see below) but don't see a problem. It is giving the warning box about UDP settings. The only thing that has changed overnight is two new Windows 10 Defender updates were installed. I tried turning off Windows Defender but it didn't fix it, so doubt that is it.

FRUSTRATED !!





JAlert does recognize the mode, the call, and band but no decodes are displayed.

Charlie


locked JTAlert is not displaying call signs decode in WSJTX

Greg Foster
 

This morning I noticed some call sign that were decoded in WSJTX were not being displayed in JTA. I had recently upgraded to JTA Ver 2.16.8 so I downgraded to 2.16.6 and found the same problem. The affected call signs can be either worked B4,a required call sign or a call sign from a QSO in progress as defined in WSJTX. 

I reworked a call sign shown as worked before but once the QSO was completed he still did not display in JTA

I scanned 7 or 8 pages on messages and could not find any similar concerns

I am running

Windows 7
WSJTX 2.1.2
JTA 2.16.8


Greg
VE3PJ


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

KD7YZ Bob
 

When I select a CQ callsign in JTAlert 2.16.8 how do I make that pass-through the callsign to DXLab's Pathfinder ?

Despite all the check-boxes in 'Settings' of JTAlert,, the only time I see a callsign pass over to Patfinder is AFTER I have had JTAlert initiate Logging to DXLab's wonderful DXKeeper.

Thanks .....


locked Re: v2.16.7 No Sound - Realtec - Windows 10 - WSJT-X v2.2.1

John
 

Hi Joe,

Tried that and still no alert sounds and no JTAlertV2.manager in the sounder screen
73

John

On 6/17/2020 11:41 AM, Joe Subich, W4TV wrote:

> I thought it would say JTAlertV2.manager

It should.

> It will happen after I make a QSO and log it (in Log4OM.V!)

If you're seeing JTAlert instead of JTAlertV2.manager, the sound is
probably an error sound (Windows Error).  Acts like you do not have
JTAlert configured correctly for the proper sound card.  Go to Settings
-> Manage Settings -> Sound Card.  Select any sound card *except* your
Realtek [Speakers (Realtek High Definition Audio)] then go back and
select Speakers (Realtek High Definition Audio).  Set the Volume in
"Test Sound Card" at around 50% and click "Test Play".

73,

   ... Joe, W4TV


On 2020-06-17 11:17 AM, John wrote:

Bill, I have found a way to get the JTAlert to show up on the volume mixer. But
I thought it would say JTAlertV2.manager




It will happen after I make a QSO and log it (in Log4OM.V!)

BUT, I still don't hear any alerts or the test sound

John








  

Virus-free. www.avg.com


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

g4wjs
 

On 04/07/2020 04:14, Dave AA6YQ wrote:
# more AA6YQ comments below


today I suffered this issue. JTAlert was giving the message about being unable to confirm logging to DXKeeper, as usual I ignored it since my PC is often very busy and slowing down DXKeeper, but this time it turns out the QSO were not being logged to DXKeeper. I don't have much to help diagnosing but the following observations may help.

*	The WSJT-X/JTAlert/DXKeeper combination had been running for quite a while with QSOs being correctly logged.
*	At some point QSOs stopped arriving in the DXKeeper log, no error messages from DXKeeper.
*	Once they stopped logging there was no recovery.
*	The WSJT-X ADIF log was complete, later used to add the missing QSOs via import without generating duplicates.
*	Restarting WSJT-X did not fix the issue.
*	Restarting JTAlert did not fix the issue.
*	Restarting DXKeeper*did*  fix the issue.

+ Thanks, Bill. The question is, "was DXKeeper receiving logging directives from JT-Alert via TCP?".

+ The next time this happens, please

1.  enable "log debugging info" on the General tab of DXKeeper's 
Configuration window

2. log a QSO from JT-Alert

3. disable "log debugging info" on the General tab of DXKeeper's 
Configuration window

4. attach the errorlog.txt file from your DXKeeper folder to an email 
message that specifies the callsign you directed JT-Alert to log in 
step 2, and send the message my way

           73,

                 Dave, AA6YQ
Hi Dave,

understood. Unfortunately today's issue happened during a pileup and the only priority was to get the log up to date and functioning.

I believe the fact that restarting JTAlert did not fix the issue, but restarting DX Keeper did, is pretty strong evidence that the problem lies at the DX Keeper end of the TCP/IP connection. But that is still only conjecture.

# We already have an errorlog from Carl WC4H showing that DXKeeper did not receive a "log QSO" directive from JT-Alert for a particular QSO, but did receive a "log QSO"  directive for a QSO logged before the unlogged QSO, and for a QSO logged after the unlogged QSO. Likely, there's at least one problem involving transport via TCP. An errorlog generated from the scenario you report above would reveal whether or not DXKeeper stopped listening for incoming directives via TCP, as you're guessing.

# An errorlog from JT-Alert would likely also be helpful, but I'll defer to Laurie VK3AMA on that.

       73,

             Dave, AA6YQ

Hi Dave,

all understood Dave, this may have been a different issue from that descripton of Carl's issue. Here 81 QSOs in a row failed to log. No issues prior to that and none afterwards, once DX Keeper was restarted. I have asked Steve, M5BFL, who was operating with his laptop, to send a support request including debug files to Laurie in case there is anything useful in those.


--
73
Bill
G4WJS.


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

Dave AA6YQ
 

# more AA6YQ comments below


today I suffered this issue. JTAlert was giving the message about being unable to confirm logging to DXKeeper, as usual I ignored it since my PC is often very busy and slowing down DXKeeper, but this time it turns out the QSO were not being logged to DXKeeper. I don't have much to help diagnosing but the following observations may help.

* The WSJT-X/JTAlert/DXKeeper combination had been running for quite a while with QSOs being correctly logged.
* At some point QSOs stopped arriving in the DXKeeper log, no error messages from DXKeeper.
* Once they stopped logging there was no recovery.
* The WSJT-X ADIF log was complete, later used to add the missing QSOs via import without generating duplicates.
* Restarting WSJT-X did not fix the issue.
* Restarting JTAlert did not fix the issue.
* Restarting DXKeeper*did* fix the issue.

+ Thanks, Bill. The question is, "was DXKeeper receiving logging directives from JT-Alert via TCP?".

+ The next time this happens, please

1. enable "log debugging info" on the General tab of DXKeeper's
Configuration window

2. log a QSO from JT-Alert

3. disable "log debugging info" on the General tab of DXKeeper's
Configuration window

4. attach the errorlog.txt file from your DXKeeper folder to an email
message that specifies the callsign you directed JT-Alert to log in
step 2, and send the message my way

73,

Dave, AA6YQ
Hi Dave,

understood. Unfortunately today's issue happened during a pileup and the only priority was to get the log up to date and functioning.

I believe the fact that restarting JTAlert did not fix the issue, but restarting DX Keeper did, is pretty strong evidence that the problem lies at the DX Keeper end of the TCP/IP connection. But that is still only conjecture.

# We already have an errorlog from Carl WC4H showing that DXKeeper did not receive a "log QSO" directive from JT-Alert for a particular QSO, but did receive a "log QSO" directive for a QSO logged before the unlogged QSO, and for a QSO logged after the unlogged QSO. Likely, there's at least one problem involving transport via TCP. An errorlog generated from the scenario you report above would reveal whether or not DXKeeper stopped listening for incoming directives via TCP, as you're guessing.

# An errorlog from JT-Alert would likely also be helpful, but I'll defer to Laurie VK3AMA on that.

73,

Dave, AA6YQ


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

g4wjs
 

On 04/07/2020 03:26, Dave AA6YQ wrote:
+ AA6YQ comments below

today I suffered this issue. JTAlert was giving the message about being unable to confirm logging to DXKeeper, as usual I ignored it since my PC is often very busy and slowing down DXKeeper, but this time it turns out the QSO were not being logged to DXKeeper. I don't have much to help diagnosing but the following observations may help.

* The WSJT-X/JTAlert/DXKeeper combination had been running for quite a while with QSOs being correctly logged.
* At some point QSOs stopped arriving in the DXKeeper log, no error messages from DXKeeper.
* Once they stopped logging there was no recovery.
* The WSJT-X ADIF log was complete, later used to add the missing QSOs via import without generating duplicates.
* Restarting WSJT-X did not fix the issue.
* Restarting JTAlert did not fix the issue.
* Restarting DXKeeper*did* fix the issue.

+ Thanks, Bill. The question is, "was DXKeeper receiving logging directives from JT-Alert via TCP?".

+ The next time this happens, please

1. enable "log debugging info" on the General tab of DXKeeper's Configuration window

2. log a QSO from JT-Alert

3. disable "log debugging info" on the General tab of DXKeeper's Configuration window

4. attach the errorlog.txt file from your DXKeeper folder to an email message that specifies the callsign you directed JT-Alert to log in step 2, and send the message my way

73,

Dave, AA6YQ
Hi Dave,

understood. Unfortunately today's issue happened during a pileup and the only priority was to get the log up to date and functioning.

I believe the fact that restarting JTAlert did not fix the issue, but restarting DX Keeper did, is pretty strong evidence that the problem lies at the DX Keeper end of the TCP/IP connection. But that is still only conjecture.



--
73
Bill
G4WJS.


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

Dave AA6YQ
 

+ AA6YQ comments below

today I suffered this issue. JTAlert was giving the message about being unable to confirm logging to DXKeeper, as usual I ignored it since my PC is often very busy and slowing down DXKeeper, but this time it turns out the QSO were not being logged to DXKeeper. I don't have much to help diagnosing but the following observations may help.

* The WSJT-X/JTAlert/DXKeeper combination had been running for quite a while with QSOs being correctly logged.
* At some point QSOs stopped arriving in the DXKeeper log, no error messages from DXKeeper.
* Once they stopped logging there was no recovery.
* The WSJT-X ADIF log was complete, later used to add the missing QSOs via import without generating duplicates.
* Restarting WSJT-X did not fix the issue.
* Restarting JTAlert did not fix the issue.
* Restarting DXKeeper *did* fix the issue.

+ Thanks, Bill. The question is, "was DXKeeper receiving logging directives from JT-Alert via TCP?".

+ The next time this happens, please

1. enable "log debugging info" on the General tab of DXKeeper's Configuration window

2. log a QSO from JT-Alert

3. disable "log debugging info" on the General tab of DXKeeper's Configuration window

4. attach the errorlog.txt file from your DXKeeper folder to an email message that specifies the callsign you directed JT-Alert to log in step 2, and send the message my way

73,

Dave, AA6YQ


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

g4wjs
 

On 26/06/2020 02:10, Dave AA6YQ wrote:
+ AA6YQ comments below

I have noticed that sometimes the QSO is not displayed in the window of the Log QSOs tab.  I have been able to make it reappear by terminating and then restarting DXKeeper.  My theory is that the pointer used for the display of the incore database records gets corrupted.  When the file is closed and reopened the pointers are resynched.  Only a guess at what may be happening, but try it next time you see the error.

+ There is no evidence supporting that guess. The next time it happens, Dave, remove any Log Page Display filtering by clicking the X button in the Filter panel at the bottom of DXKeeper's Main window's "Log QSOs" tab.

+ The errorlog that Carl WC4H sent me showed that for the missing QSO, DXKeeper never received a "Log QSO" directive from JT-Alert.

           73,

                 Dave, AA6YQ

Hi Dave and Laurie,

today I suffered this issue. JTAlert was giving the message about being unable to confirm logging to DXKeeper, as usual I ignored it since my PC is often very busy and slowing down DXKeeper, but this time it turns out the QSO were not being logged to DXKeeper. I don't have much to help diagnosing but the following observations may help.

  • The WSJT-X/JTAlert/DXKeeper combination had been running for quite a while with QSOs being correctly logged.
  • At some point QSOs stopped arriving in the DXKeeper log, no error messages from DXKeeper.
  • Once they stopped logging there was no recovery.
  • The WSJT-X ADIF log was complete, later used to add the missing QSOs via import without generating duplicates.
  • Restarting WSJT-X did not fix the issue.
  • Restarting JTAlert did not fix the issue.
  • Restarting DXKeeper *did* fix the issue.
73
Bill
G4WJS.

--
73
Bill
G4WJS.


locked Wanted Call needs to ignore Filters

WB5JJJ - George
 

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


locked Re: 13 Colonies

Alfred Reeves
 

Great job Jon..This is why these forums work..

73
Al
W1JHU

On 7/3/2020 4:57 PM, Jon KM8V wrote:
I got this working, and it is alerting by band/mode just fine.

I added the callsigns to the wanted callsigns alerts, and on Worked B4 I set it to ignore B4 status before 2020-07-01.

Ignore Band and Ignore Mode are unchecked, beyond that it is not obvious to me how it is working for multiple bands / modes, but it is.


On Thu, Jul 2, 2020 at 08:40 PM, Paul N. Gayet AA1SU wrote:
Al,
This is okay if you want to work a station just once.
I'm working them on as many bands as possible this week.
I don't see a way to keep the call from popping up as a wanted call after working them.
I guess, I'll just have to keep the feature turned on, and keep track of them on paper, like Scott N2SAB.
73
Paul N. Gayet  AA1SU
ARRL Vermont Section Manager
Fists #4028
On 7/1/2020 11:47 PM, Alfred Reeves wrote:
This is the way I have the 13 Colonies alert.
1. Open "Settings" "Wanted Call Signs"
2. Check "Enable Wanted Callsign Alert"
3. Under "Options" check "Alert when decoded Callsign worked B4"
4. In the "Alert Callsigns" box enter the callsigns of the 15 "13 Colonies stations" ie K2A, K2B, etc.
5. Set the "Alert Color" to your preference.
6. Click the "Save" box at the lower right.
7. Close out.

As the 13 colonies stations are decoded they will show up colored to the preference you set even if you worked them B4 ie last year.  As you work the stations you can go and remove them from the "Alert Callsigns" box.

That's way I have been working them and it's very helpful.

Al
W1JHU 


locked Re: 13 Colonies

Jon KM8V
 

I got this working, and it is alerting by band/mode just fine.

I added the callsigns to the wanted callsigns alerts, and on Worked B4 I set it to ignore B4 status before 2020-07-01.

Ignore Band and Ignore Mode are unchecked, beyond that it is not obvious to me how it is working for multiple bands / modes, but it is.


On Thu, Jul 2, 2020 at 08:40 PM, Paul N. Gayet AA1SU wrote:
Al,
This is okay if you want to work a station just once.
I'm working them on as many bands as possible this week.
I don't see a way to keep the call from popping up as a wanted call after working them.
I guess, I'll just have to keep the feature turned on, and keep track of them on paper, like Scott N2SAB.
73
Paul N. Gayet  AA1SU
ARRL Vermont Section Manager
Fists #4028
On 7/1/2020 11:47 PM, Alfred Reeves wrote:
This is the way I have the 13 Colonies alert.
1. Open "Settings" "Wanted Call Signs"
2. Check "Enable Wanted Callsign Alert"
3. Under "Options" check "Alert when decoded Callsign worked B4"
4. In the "Alert Callsigns" box enter the callsigns of the 15 "13 Colonies stations" ie K2A, K2B, etc.
5. Set the "Alert Color" to your preference.
6. Click the "Save" box at the lower right.
7. Close out.

As the 13 colonies stations are decoded they will show up colored to the preference you set even if you worked them B4 ie last year.  As you work the stations you can go and remove them from the "Alert Callsigns" box.

That's way I have been working them and it's very helpful.

Al
W1JHU 


locked Re: Worked B4 not working

Jim Cooper
 

On 3 Jul 2020 at 10:42, Paul AC9O wrote:

I was not referring to WSJT, I was
referring to JTAlert which does know
the grid, that's why it highlighted
it.

The issue isn't really with the grid
alert or the Grid box in WSJT, it's
with the Worked B4 in JTAlert. If I
add the call to the ignored list, then
it suppresses the grid alert.

Hope that clarifies.
I don't think it does, because the B4 is
checked against the LOGGED info, and
JTalert does NOT do the logging, afaik ...
it sends the WSJT log info to the logger;
so if the grid is missing in the WSJT log
popup, it will be missing in the logger.

At least that's the way I understand it.


locked Re: Worked B4 not working

Paul AC9O
 

Hi Jim,

I was not referring to WSJT, I was referring to JTAlert which does know the grid, that's why it highlighted it.

The issue isn't really with the grid alert or the Grid box in WSJT, it's with the Worked B4 in JTAlert. If I add the call to the ignored list, then it suppresses the grid alert.

Hope that clarifies.

73
Paul, AC9O

4821 - 4840 of 35434