Date   

locked Re: Suggestion: For Field Day, main screen toggle

Brad
 

I agree

On Jun 27, 2021, at 2:47 PM, Ken B <kb7who@...> wrote:

I would like to see a toggle on the main screen (my suggestion is to turn the Field Day alert on the main screen into a button).

There were several contacts that I could have made that were not participating in field day if I could have exited the field day mode a little quicker before they went QSB.

Thanks (and I appreciate WSJT!)

Ken


locked Suggestion: For Field Day, main screen toggle

Ken B
 

I would like to see a toggle on the main screen (my suggestion is to turn the Field Day alert on the main screen into a button).

There were several contacts that I could have made that were not participating in field day if I could have exited the field day mode a little quicker before they went QSB.

Thanks (and I appreciate WSJT!)

Ken


locked Re: JTAlet stops responding

Brad
 

Well I think I got it working for now.
What I did not have was WSJT-X selected to go through my added it to the exception list and JTAlert seam to be working fine now.

As for the double logging I uncheck the Secondary UDP Server (Deprecated) box) under the reporting tab of WSJT-X
next I unchecked the UDP Transmission of last QSO in the JTAlert logging last QSO API

All is working again


locked JTAlet stops responding

Brad
 

WSJT-X Version         : 2.5.0-rc1

WSJT-X Revision        : 68a3d4

WSJT-X Spec Op Mode    : ARRL Field Day

WSJT-X UDP ID          : WSJT-X

WSJT-X UDP Port        : 2237

WSJT-X UDP Server      : 224.0.0.1

WSJT-X UDP MCast on LB : True

WSJT-X UDP Max Schema  : 3

 

My JTAlert stops responding as soon as I click on a call. And when it does work it wants to double log to HRD logbook.

I ‘m running JTAlert 2.5.0.2, WSJT-X 2.5.0-rc1, and HRD, and Windows 10

I’m hoping it is just a setting I have wrong

 

Let me know if you need anything. Someone can also log into my system if needed.

Please help


locked Re: Signal report - Assumptions are important

K8TS
 

GM Laurie;
Thank you for all you fine, and diligent work. Although I have not been active in the FTx modes of late, I know you are still there producing a great product for the ham community, with awesome support.
Dale K8TS


locked Re: Unable to log to DXKeeper

Dave AA6YQ
 

# more AA6YQ comments below

+ Not correct; DXKeeper first logs the QSO, and then performs the uploads.

Thanks for the clarification Dave.

Is there some pre-logging event that may account for the excessive delay in writing the QSO to the log file? Perhaps an XML lookup?

# When DXKeeper receives a TCP message bearing a "Log" directive, it places that directive in a first-in first-out queue. Assuming
nothing precedes that directive in the queue, it will be processed 250 ms later. An empty new QSO is created in the log database,
and populated with information from the ADIF record contained in the "Log" directive; there are no callbook or database updates;
that's the responsibility of the application that assembled the ADIF record.

# The most typical reason for slow performance is interference from an incompetent or incorrectly configured anti-malware
application, but other applications are known to interfere, as described in

https://www.dxlabsuite.com/dxlabwiki/ApplicationInteference

# Just last week, a DXLab user was bitten by interference from nVidia's GEFORCE EXPERIENCE application with its IN-GAME OVERLAY
option enabled

# In Mark's case, the problem with not uploading to LoTW was caused by DXKeeper being prevented from registering the Microsoft
component it uses to send and receive information via the internet (MSWINSCK.OCX). The cause of that remains to be determined.

# Database performance is sensitive to many parameters, including the amount of free RAM, the time since Windows was last rebooted,
the computational load on the system, and the system's virtual memory configuration. There are many books and online articles on
this topic.

73,

Dave, AA6YQ


locked Re: Unable to log to DXKeeper

Dave AA6YQ
 

The "log debugging information" box is not checked and restarted DXKeeper just to make sure. I still have the see "DXKeeper Errorlog.txt" message in the title bar.

+ I sent you specific instructions in response to the email message you sent me. Did you follow those instructions?

73,

Dave, AA6YQ


locked Re: Unable to rebuild alert database. Just get brief blink of window

HamApps Support (VK3AMA)
 

On 26/06/2021 9:07 pm, Gareth, M5KVK wrote:
I'm running 2.50.2 with WSJT-X v2.3.1 on Windows 10
I've not been on for a while, but when I tried to rebuild the alert database and clicked on "Rebuild All (enabled" all I see is a window blinking once and then disappearing; the main wind freezes for a second or two, and then goes back to normal, and the (updates) tag is still there on the main window header.
I've enabled debug logging but I don't know where the log file is located.

Gareth - M5KVK

Normally, even when errors are encountered, the Rebuild window should stay visible waiting for your action to save the changes. There is only one place in the code that could produce that result you're seeing. That is when JTAlert is unable to create/open the text file used to record the results of the rebuild, this happens very early in the code and would produce a quick show/close of the window event. It would appear that JTAlert is being prevented from creating the file within the session directory
that JTAlert has full access to. Sounds very much like Protection software interference. All JTAlert session files are created under the users %localappdata%\HamApps directory.

The debugging data is automatically sent as part of a Support Request. Use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis. Don't forget to turn off Debug recording as it may have a detrimental effect on JTAlert performance if left enabled.

de Laurie VK3AMA



locked Re: Unable to log to DXKeeper

HamApps Support (VK3AMA)
 

On 26/06/2021 2:53 pm, Dave AA6YQ wrote:
+ Not correct; DXKeeper first logs the QSO, and then performs the uploads.

Thanks for the clarification Dave.

Is there some pre-logging event that may account for the excessive delay in writing the QSO to the log file? Perhaps an XML lookup?

de Laurie VK3AMA


locked Re: jtalert stopped talking to wsjt-x

Frode Igland
 

Chris, 
In the event you have not gotten everything to work: Your our error message states that you use IP address 224.0.0.0. That is not a valid IP address for multicasting. The 224 series starts at 224.0.0.1. The JTAlert Help file contains the two valid series.
Make the change and I guess it will work.

73 Frode LA6VQ


locked Re: Unable to log to DXKeeper

Mark Basel <mb02731@...>
 

The "log debugging information" box is not checked and restarted DXKeeper just to make sure. I still have the see "DXKeeper Errorlog.txt" message in the title bar.

On Jun 25, 2021, at 11:53 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ AA6YQ comments below

yes the QSO makes it to the DX keeper log but does not automatically upload to Lotw which is why Im running this two
programs to begin with. I have increased the delay to 20 seconds time to log the QSO, still no luck. Guess I can do them manually
but thats a PITA and defeats the reason to use DXKeeper in the first place...


If 20 seconds is insufficient time for DXKeeper to write the QSO to its log file that suggests to me that DXKeeper is hanging while
it tries to upload the QSO to LoTW. My understanding is that DXKeeper doesn't write the QSO to the physical log gile until after it
has completed any online uploads .

+ Not correct; DXKeeper first logs the QSO, and then performs the uploads.

See this response <https://hamapps.groups.io/g/Support/message/35796> from Dave AA6YQ the DXLab author to help isolate the cause of
LoTW upload failing.

+ Mark sent me the errorlog.txt file I created, which revealed that the component DXKeeper employs to upload and download files via
the internet is not properly registered with Windows. This was signified by the presence of the words "See DXKeeper Errorlog.txt" in
the title bar of DXKeeper's Main window.

+ If DXKeeper was unable to register the component because of interference from Windows' access control mechanism, the instructions
I sent Mark should overcome that problem. We'll see...

+ DXKeeper users: if the words "See DXKeeper Errorlog.txt" appear in the title bar of DXKeeper's Main window, then examine the
Configuration window's General tab to see if the "log debugging information" box has been checked; if so, uncheck it, and restart
DXKeeper. If not, then please attach the errorlog.txt file from your DXKeeper folder to an email message, and send the message to me
via

aa6yq (at) ambersoft.com

+ No "pre-approval" from me is required.

73,

Dave, AA6YQ






locked Re: Signal report - Assumptions are important

Mark Basel <mb02731@...>
 

Lived the acronyms world of a 2G logistics planner in the AF, It was nuts. Ive seen SIPRnet message traffic that was almost nothing but🤪 glad I XB3'd most of them🥸

On Jun 26, 2021, at 1:45 AM, Laurie, VK3AMA <hamapps.support@vkdxer.com> wrote:



On 26/06/2021 3:40 pm, Jim Cooper wrote:
would you mind defining 'ARO'?

use of acronyms without first defining them
can put many readers at a disadvantage for
understanding your post.

w2jc

[I'm GUESSING it means Amateur Radio Operator]
AROs to me suggests it is coming from some Government department bureaucratic licensing document.

At my local club we are all HAMs, not AROs, which coincidentally has the same number of characters ;-)

While I am proud to call myself a HAM, I do use the phrase "Amateur Radio Operator" when communicating with non-Hams, especially when trying to explain the meaning of my Car registration plates, "VKDXER". I have to explain about Ham (Amateur) Radio, what the "VK" stands for in relation to the thousands of like-minded individuals around the world, and what is "DX" and why I call myself a "DXer". I never have to explain the meaning to another Ham, except for the occasional newly-minted Ham.

de Laurie VK3AMA






locked Re: Unable to rebuild alert database. Just get brief blink of window

chas cartmel
 

The updates tag refers to data downloads and not the alerts database.
Check the website for latest data downloads

73 Charlie

G4EST

www.g4est.me.uk

Stay safe out there

 

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Gareth, M5KVK
Sent: 26 June 2021 12:08
To: Support@HamApps.groups.io
Subject: [HamApps] Unable to rebuild alert database. Just get brief blink of window

 

I'm running 2.50.2 with WSJT-X v2.3.1 on Windows 10
I've not been on for a while, but when I tried to rebuild the alert database and clicked on "Rebuild All (enabled" all I see is a window blinking once and then disappearing; the main wind freezes for a second or two, and then goes back to normal, and the (updates) tag is still there on the main window header.
I've enabled debug logging but I don't know where the log file is located.

Gareth - M5KVK


This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com


locked Re: Unable to rebuild alert database. Just get brief blink of window

Michael Black
 

Sounds like your anti-virus is causing problems create an exception in your antivirus program for The JTAlert program folder and reinstall.


On Jun 26, 2021, at 7:54 AM, Gareth, M5KVK <Gareth.m5kvk@...> wrote:

I'm running 2.50.2 with WSJT-X v2.3.1 on Windows 10
I've not been on for a while, but when I tried to rebuild the alert database and clicked on "Rebuild All (enabled" all I see is a window blinking once and then disappearing; the main wind freezes for a second or two, and then goes back to normal, and the (updates) tag is still there on the main window header.
I've enabled debug logging but I don't know where the log file is located.

Gareth - M5KVK


locked Unable to rebuild alert database. Just get brief blink of window

Gareth, M5KVK
 

I'm running 2.50.2 with WSJT-X v2.3.1 on Windows 10
I've not been on for a while, but when I tried to rebuild the alert database and clicked on "Rebuild All (enabled" all I see is a window blinking once and then disappearing; the main wind freezes for a second or two, and then goes back to normal, and the (updates) tag is still there on the main window header.
I've enabled debug logging but I don't know where the log file is located.

Gareth - M5KVK


locked Re: Signal report - Assumptions are important

Laurie, VK3AMA
 

On 26/06/2021 3:40 pm, Jim Cooper wrote:
would you mind defining 'ARO'?

use of acronyms without first defining them
can put many readers at a disadvantage for
understanding your post.

w2jc

[I'm GUESSING it means Amateur Radio Operator]
AROs to me suggests it is coming from some Government department bureaucratic licensing document.

At my local club we are all HAMs, not AROs, which coincidentally has the same number of characters ;-)

While I am proud to call myself a HAM, I do use the phrase "Amateur Radio Operator" when communicating with non-Hams, especially when trying to explain the meaning of my Car registration plates, "VKDXER". I have to explain about Ham (Amateur) Radio, what the "VK" stands for in relation to the thousands of like-minded individuals around the world, and what is "DX" and why I call myself a "DXer". I never have to explain the meaning to another Ham, except for the occasional newly-minted Ham.

de Laurie VK3AMA


locked Re: Signal report - Assumptions are important

TomK
 

Apologies. I'm not immune to occasionally using acronyms w/o thoroughly weighing their recognizability in a given venue.

 

                ARO … Amateur Radio Operator.

 

It's an older, literal variant, TLA that avoids the demeaning, less intuitive, but more recognizable moniker of "HAM".

By less intuitive, I don’t mean less recognizable.  To wit, “ARO” at least makes literal sense whereas “HAM” does not.

 

<laugh> In case you are asking, "TLA" is the old well-known recursive acronym meaning "Three Letter Acronym".

It is mostly used in jocular wry interchanges making fun of the use of acronyms. Hence the recursive attribution.

 

Hope that answers your question.

TomK 73

 

-----Original Message-----
From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Jim Cooper
Sent: Saturday, June 26, 2021 1:41 AM
To: TomK <QSO@...>
Cc: Support@HamApps.groups.io
Subject: Re: [HamApps] Signal report - Assumptions are important

 

On 26 Jun 2021 at 1:14, TomK wrote:

 

> Active AROs

 

would you mind defining 'ARO'?

 

use of acronyms without first defining them can put many readers at a disadvantage for understanding your post.

 

w2jc

 

[I'm GUESSING it means Amateur Radio Operator]

 

 

 

 

 

 


locked Re: Signal report - Assumptions are important

Jim Cooper
 

On 26 Jun 2021 at 1:14, TomK wrote:

Active AROs
would you mind defining 'ARO'?

use of acronyms without first defining them
can put many readers at a disadvantage for
understanding your post.

w2jc

[I'm GUESSING it means Amateur Radio Operator]


locked Re: Signal report - Assumptions are important

TomK
 

To bug reporter:  I think you’ve made a few incorrect assumptions.

If you see the QSO in question in YOUR OWN log, then JTA is uploading correctly.

 

I go to their page on QRZ.COM and check their log to see if was good contact and no it's not there."

Ok, so you’re saying you don’t see YOUR CALL in the log of ANOTHER QRZ user with whom you had a QSO?

I assume you mean in the “Logbook” widget of the other party’s QRZ profile lookup page?

 

To see your call in another QRZ user’s log, then (at least) the following conditions must be met:
Forgive me if some are painfully obvious. I just want to be logically complete.

  1. You & They (obviously) need to be QRZ members who are maintaining active logs.
  2. You & They must BOTH have uploaded the QSO sometime earlier (Nothing is immediate).
  3. The QSO needs to fit in the short time window of the “Logbook” widget (it’s only 15 entries).
    Active AROs log many calls in short periods so a QSO can fall outside the short widget in minutes.
    Adding to time (say) 15-60 mins to allow all DB updates, then your QSO may never show in that widget.
    To wit: If the other ARO is active and logs many QSOs, then by the time the system updates,
    you are already past the bottom of the time window.

 

Re advice that “QRZ not a reliable source”.

That was meant to say “AROs do not necessarily upload to QRZ in real-time.”

As a result, inspecting the other party’s log on QRZ is “is not a reliable source” to verify your QSO upload.

Why would you even want to do that? Your QSO upload is all that matters.

If you see your QSO uploaded,  then everything is working as intended.

What happens with the other party’s upload has nothing to do with JT-Alert or QRZ.

 

All-in-all, QRZ has an outstanding record for database availability when compared to other web logs.

LoTW and the others often have outages on a daily basis. QRZ’s DB has fared much better.

Many perceived JTA and/or QRZ issues are often related to other things like LoTW on the back end.

 

Hope that helps clarify the issue.

TomK / KT1TK / 73

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Friday, June 25, 2021 6:14 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Signal report

 

On 26/06/2021 7:53 am, Bob wrote:

I'm using wsjt-x windows 10 .Not using any contest mode. When I say gong to their page I mean I go to their page on QRZ.COM and check their log to see if was good contact and no it's not there. ALT + Q Will take you there. When I get pop-up to confirm QSO There isn't any signal report for me just the report I gave him/her and the time for Sent and received is the same it looks like not enough time. Is there a setting for increasing time for contact  to complete. Let me know your thoughts. Thank you kb1yxn 


Not everyone uploads their QSOs to QRZ, either manually or in real-time. QRZ is not a reliable source in this regard.
I personally never upload to QRZ.

As for missing signal report and QSO start/stop times, JTAlert will only log what it has received from WSJT-X when you log the QSO. You should check the "Log QSO" window fields before hitting the OK button and adjust any incorrect or missing data.

de Laurie VK3AMA


locked Re: Unable to log to DXKeeper

Dave AA6YQ
 

+ AA6YQ comments below

yes the QSO makes it to the DX keeper log but does not automatically upload to Lotw which is why Im running this two
programs to begin with. I have increased the delay to 20 seconds time to log the QSO, still no luck. Guess I can do them manually
but thats a PITA and defeats the reason to use DXKeeper in the first place...


If 20 seconds is insufficient time for DXKeeper to write the QSO to its log file that suggests to me that DXKeeper is hanging while
it tries to upload the QSO to LoTW. My understanding is that DXKeeper doesn't write the QSO to the physical log gile until after it
has completed any online uploads .

+ Not correct; DXKeeper first logs the QSO, and then performs the uploads.

See this response <https://hamapps.groups.io/g/Support/message/35796> from Dave AA6YQ the DXLab author to help isolate the cause of
LoTW upload failing.

+ Mark sent me the errorlog.txt file I created, which revealed that the component DXKeeper employs to upload and download files via
the internet is not properly registered with Windows. This was signified by the presence of the words "See DXKeeper Errorlog.txt" in
the title bar of DXKeeper's Main window.

+ If DXKeeper was unable to register the component because of interference from Windows' access control mechanism, the instructions
I sent Mark should overcome that problem. We'll see...

+ DXKeeper users: if the words "See DXKeeper Errorlog.txt" appear in the title bar of DXKeeper's Main window, then examine the
Configuration window's General tab to see if the "log debugging information" box has been checked; if so, uncheck it, and restart
DXKeeper. If not, then please attach the errorlog.txt file from your DXKeeper folder to an email message, and send the message to me
via

aa6yq (at) ambersoft.com

+ No "pre-approval" from me is required.

73,

Dave, AA6YQ

2121 - 2140 of 37686