Date   

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


locked Re: Worked B4 not working

Jim Cooper
 

On 3 Jul 2020 at 6:00, Paul AC9O wrote:

It does NOT when I respond to a 73
or RR73. The grid is not in the log
yet
If WSJT has not detected that station's
grid from a previous CQ, how is it supposed
to know the grid?

When I do tail-end a 73 like that, I look back
to see if I can see where that station has
called CQ showing their grid; otherwise, I look
at the bottom of JTalert, where it has done the
QRZ xml lookup, and I put in the grid from there
(in the logging window).

Sometimes we have to do a little work ourselves !!

w2jc


locked Re: Worked B4 not working

Paul AC9O
 

Thank you for all the suggestions. Based on those, I think I figured out most of what's happening.

When I respond to a CQ, the Grid is in the DX Grid box and when the QSO is logged, the grid is passed to ACLog.

When I respond to a 73 that has alerted on Grid, the grid is NOT placed in the DX Grid box and is NOT passed to ACLog.

The Worked B4 works fine when I respond and complete a QSO starting with a CQ, it shows up as B4 and does not alert..

It does NOT when I respond to a 73 or RR73. The grid is not in the log yet (it will be once it's QSLed thru LoTW). It still alerts on Grid and is NOT marked as B4.

However, I would think the Worked B4 should suppress the Grid alert when the call/band is in the log regardless of whether the grid is in the log or not? I checked alert priorities and there isn't an entry for Worked B4.

Note that all the checkboxes you mentioned are NOT checked.

Thanks and 73!
Paul, AC9O


locked Re: 13 Colonies

Alfred Reeves
 

Paul:

Here's the link to the log sheet.  Download and use one for each band.

http://www.13colonies.us/2019_log

Al
W1JHU 

On 7/2/2020 8: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

Alfred Reeves
 

Paul:  They only way to do it on all bands is to keep a paper score sheet.  The 13 Colonies website has one you can download.

Good Lick
Al
W1JHU

On 7/2/2020 8: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

Paul N. Gayet AA1SU
 

Jim,
Yea, I know.  I should have put a smiley face with that.
Thanks.

73
Paul N. Gayet AA1SU
ARRL Vermont Section Manager
Fists #4028

On 7/2/2020 9:10 PM, Jim Cooper wrote:
On 2 Jul 2020 at 20:40, Paul N. Gayet AA1SU wrote:

I guess, I'll just have to keep the feature turned
on, and keep track of them on paper,
There's ONLY a dozen and a half to keep track of !!



4721 - 4740 of 35329