B4 Behavior


Craig
 

I continue to struggle with getting B4 to behave accurately.  For example, I called VK6EI this evening on 30M FT8 based on JTAlert showing a not worked status. When the QSO was completed and logged with DXKeeper, my log showed that I have worked this station 5 times in 2021 on 30M FT8.  My JTAlert B4 settings are ALL unchecked.  Looking for guidance on this regularly occurring issue.  I am using V2.50.5  Thanks. 
--
Craig
NZ4CW


HamApps Support (VK3AMA)
 

On 15/09/2021 5:05 am, Craig wrote:
I continue to struggle with getting B4 to behave accurately.  For example, I called VK6EI this evening on 30M FT8 based on JTAlert showing a not worked status. When the QSO was completed and logged with DXKeeper, my log showed that I have worked this station 5 times in 2021 on 30M FT8.  My JTAlert B4 settings are ALL unchecked.  Looking for guidance on this regularly occurring issue.  I am using V2.50.5  Thanks. 
--
Craig
NZ4CW

Check the "Alerts -> Worked B4" section of the Settings window. What date is shown for the highlighted setting shown in this image?

 

If it is todays date or a relatively recent date, enable the "Ignore QSOs based on log entry date" checkbox temporarily, than adjust the date to some far off date in the past, say 1900-01-01, then uncheck that checkbox. Close the Settings window than restart JTAlert. Let me know if that corrects the problem.

de Laurie VK3AMA


Craig
 

Hello Laurie - the date that is showing is 2018-01-01... as this date is not today's date or anything recent, I made no changes.  Will wait to hear from you.  Thanks.  C

--
Craig
NZ4CW


Craig
 

Laurie - I decided to go ahead and adjust the date per your recommendation and process.  Will assess and let you know what I find.
--
Craig
NZ4CW


Craig
 

Laurie - on 30M FT8.  After change of date and re-start, VK6EI is still showing as not worked which is not the case per my original email.
--
Craig
NZ4CW


neil_zampella
 

Have you posted this here before, as I recall seeing this exact same post somewhere.  Perhaps over on the WSJT-X group?

In any case, 2.50.6 has been released, try that to see if that has changed anything. 

 

Neil, KN3ILZ


HamApps Support (VK3AMA)
 

On 15/09/2021 10:55 am, Craig wrote:
Laurie - on 30M FT8.  After change of date and re-start, VK6EI is still showing as not worked which is not the case per my original email.
--
Craig
NZ4CW

Craig,

It sounds like the DXKeeper log file that JTAlert is reading when doing the B4 checks may not be the correct file.

When you log a QSO via JTAlert, does it get written correctly to DXKeeper and is JTAlert reporting a success or failure message after logging? Does the DXKeeper log file path shown by JTAlert in the Settings window, "Logging -> DXLab DXKeeper" section match the file name and path in DXKeeper?

Check your inbox, I have sent an email direct requesting some additional information and files.

de Laurie VK3AMA


Craig
 

Hello Laurie - I wanted to confirm with you that you received the DXKeeper logfile and also the JTAlert files.  Please let me know if you need anything additional.  Thanks again for your assistance.
--
Craig
NZ4CW


n7eal@...
 


I've also seen a bunch of stations that I have worked, on the same band not show as B4 a few days after the contact, date is set way back in the past.

n7eal


WB5JJJ - George
 

I have seen this also in recent days/weeks.  I also noticed that WSJTx does NOT honor a B4 status on some stations, thus triggering the wanted status on to JTAlert.  Nothing special about the call or any other information at all.  

To test, I disconnected my log (HRD) from JTAlert and logged a fake QSO in WSJTx for the actual B4 station that I'm currently seeing, and then forced WSJTx to rescan its adif log.  That seemed to fix the problem.  In comparing the previous adif log entry for that non-B4 station and the new fake one, they appear to be identical in Notepad++.  The next time this happens, I'm going to copy the fake QSO in place of the original one, delete the fake one and then force WSJTx to do a rescan.   Will be interesting to see what happens.  

So I'm at a loss as to why WSJTx is sending it on as a wanted contact.  (Reported to the developers group)  JTAlert is apparently behaving as it should, based on the bad information it gets from WSJTx, even though I think JTAlert should have recognized the entry as a B4 itself.  

--
73's
George - WB5JJJ
Hamshack Holine #4969


Dave Garber
 

how do you rescan a log in wsjtx

Dave Garber
VE3WEJ / VE3IE


On Fri, Sep 17, 2021 at 9:42 AM WB5JJJ - George <wb5jjj@...> wrote:
I have seen this also in recent days/weeks.  I also noticed that WSJTx does NOT honor a B4 status on some stations, thus triggering the wanted status on to JTAlert.  Nothing special about the call or any other information at all.  

To test, I disconnected my log (HRD) from JTAlert and logged a fake QSO in WSJTx for the actual B4 station that I'm currently seeing, and then forced WSJTx to rescan its adif log.  That seemed to fix the problem.  In comparing the previous adif log entry for that non-B4 station and the new fake one, they appear to be identical in Notepad++.  The next time this happens, I'm going to copy the fake QSO in place of the original one, delete the fake one and then force WSJTx to do a rescan.   Will be interesting to see what happens.  

So I'm at a loss as to why WSJTx is sending it on as a wanted contact.  (Reported to the developers group)  JTAlert is apparently behaving as it should, based on the bad information it gets from WSJTx, even though I think JTAlert should have recognized the entry as a B4 itself.  

--
73's
George - WB5JJJ
Hamshack Holine #4969


Joe Subich, W4TV
 

On 2021-09-17 7:10 PM, Dave Garber wrote:
how do you rescan a log in wsjtx
WSJTX rereads the log every time it starts.

On Fri, Sep 17, 2021 at 9:42 AM WB5JJJ - George <wb5jjj@gmail.com
<mailto:wb5jjj@gmail.com>> wrote:
So I'm at a loss as to why WSJTx is sending it on as a wanted
contact.
JTAlert does not use the B4 information from WSJTX. When you use an
external log, JTAlert compares the "received" data to previously
logged data - Callsign, Grid, Band and mode (and date - if you have
have selected "Ignore QSOs B4"). JTAlert reads the log and caches a
copy in memory every time it starts.

If you are not closing JTAlert and your logging program after every
operating session, you risk damage to the cached image of your log
data through sleep/hibernate/shutdown that could cause inaccurate
QSO B4 behavior.

73,

... Joe, W4TV


On 2021-09-17 7:10 PM, Dave Garber wrote:
how do you rescan a log in wsjtx
Dave Garber
VE3WEJ / VE3IE
On Fri, Sep 17, 2021 at 9:42 AM WB5JJJ - George <wb5jjj@gmail.com <mailto:wb5jjj@gmail.com>> wrote:
I have seen this also in recent days/weeks.  I also noticed that
WSJTx does NOT honor a B4 status on some stations, thus triggering
the wanted status on to JTAlert.  Nothing special about the call or
any other information at all.
To test, I disconnected my log (HRD) from JTAlert and logged a fake
QSO in WSJTx for the actual B4 station that I'm currently seeing,
and then forced WSJTx to rescan its adif log.  That seemed to fix
the problem.  In comparing the previous adif log entry for that
non-B4 station and the new fake one, they appear to be identical in
Notepad++.  The next time this happens, I'm going to copy the fake
QSO in place of the original one, delete the fake one and then force
WSJTx to do a rescan.   Will be interesting to see what happens.
So I'm at a loss as to why WSJTx is sending it on as a wanted
contact.  (Reported to the developers group)  JTAlert is apparently
behaving as it should, based on the bad information it gets from
WSJTx, even though I think JTAlert should have recognized the entry
as a B4 itself.
--
73's
George - WB5JJJ
Hamshack Holine #4969


WB5JJJ - George
 

To rescan the adif, goto Files >> Settings >> Colors and on the right about 2/3 down is a button to do this.
--
73's
George - WB5JJJ
Hamshack Holine #4969


Dave Garber
 

found it , thanks

Dave Garber
VE3WEJ / VE3IE


On Fri, Sep 17, 2021 at 8:57 PM WB5JJJ - George <wb5jjj@...> wrote:
To rescan the adif, goto Files >> Settings >> Colors and on the right about 2/3 down is a button to do this.
--
73's
George - WB5JJJ
Hamshack Holine #4969


Laurie, VK3AMA
 

On 18/09/2021 10:57 am, WB5JJJ - George wrote:
To rescan the adif, goto Files >> Settings >> Colors and on the right about 2/3 down is a button to do this.
--
73's
George - WB5JJJ
In addition to Joe's (W4TV) excellent reply here https://HamApps.groups.io/g/Support/message/37188
I will point out that the re-scanning of the WSJTX ADIF will have zero affect on the JTAlert B4. JTAlert does not interrogate the WSJTX adif file, it never has.

de Laurie VK3AMA


Laurie, VK3AMA
 

On 17/09/2021 11:41 pm, WB5JJJ - George wrote:
JTAlert is apparently behaving as it should, based on the bad information it gets from WSJTx, even though I think JTAlert should have recognized the entry as a B4 itself.
To be clear, WSJTX does not send bad or good information to JTAlert, it simply sends what was decoded. The extra information about a decoded callsign, like B4 and Wanted status, is determined by WSJTX or JTAlert after examining the decoded callsigns.

You cannot rely on the differences in what JTAlert and WSJTX are reporting as an indication of a problem. The reported status of a Callsign by JTAlert and WSJTX is coming from 2 different log files. WSJTX uses its internal adif file and JTAlert uses the log file of the LOgger you have enabled in JTAlert. Unless you keep both logs in sync, there will be instances of different reporting.

de Laurie VK3AMA


KD7YZ Bob
 

Laurie, I was just having this problem. Am using 2.50.6.
Tried setting the "Ignore" to 1900 as you suggested. Saved ..then unchecked "Ignore" then Saved.
Then I restarted JTAlert and all is OK.
B4 stations now do not appear in "Callsigns#1" as they did before.
thanks tip


HamApps Support (VK3AMA)
 

On 19/09/2021 10:58 pm, KD7YZ Bob wrote:
Laurie, I was just having this problem. Am using 2.50.6.
Tried setting the "Ignore" to 1900 as you suggested. Saved ..then unchecked "Ignore" then Saved.
 Then I restarted JTAlert and all is OK.
B4 stations now do not appear in "Callsigns#1" as they did before.
thanks tip

Tnx Bob.
Do you recall what the Date was set to before you made the change?

de Laurie VK3AMA