Date   

locked 2021-08 .NET 5.0.9 Security Update for x64 Client (KB5005419),,Download size: 52.3 MB

Bob Frostholm
 

Google wants to install NET 5.0.9 Security Update for x64 on my win 7 PC

I recall there were many issues with an earlier version a couple of months ago. Before I do something stupid, I want to know if anyone else has installed this and if so, is it problem free?

--
73

Bob

Ko6Lu



--
Bob
KO6LU


locked Re: 2 meter wanted grid bug?

HamApps Support (VK3AMA)
 

On 13/08/2021 4:21 am, John P wrote:
Just rebuilt the alerts database after confirming a few new VHF grids today. I use DxKeeper for logging. When I look at confirmed 2 meter grids, ones that I've worked via the satellites are being included. In DxKeeper, the "Mode" for satellite contacts is "SAT" and these should not be included in the 2 meter count. There actually should be a separate "Wanted Grid" page for satellite contacts.
--
John P.
WA2FZW

"SAT" is not a QSO Mode, it is, based on the ADIF specs, a "Propagation Mode" or the mechanism by which the QSO was made, similar to "EME", it is not the Mode used for the QSO.

What Mode was used for these Satellite assisted QSOs? That is what will influence was JTAlert does with the Log Scanning and how the QSOs will be treated.

The Mode recorded, not the SAT_MODE, is the important bit.

de Laurie VK3AMA


locked #Announcement #NewRelease : JTAlert 2.50.5 is available #Announcement #NewRelease

HamApps Support (VK3AMA)
 

The latest JTAlert version 2.50.5 is now available at https://hamapps.com/JTAlert/

The new installers have been examined by Microsoft and flagged as Virus/Trojan free. The MS Defender definitions files have been updated to exclude JTAlert 2.50.5 as a threat.

*** IMPORTANT *** If you use the Ignore Date setting for Worked B4 alerting the existing setting may have been reset or changed. You will need to go into the JTAlert Settings window, "Alerts -> Worked B4" section and ensure the Date is set per your requirements.

Full release notes are available at the end of this message. I strongly encourage all users read these before installing this new JTAlert release.

de Laurie VK3AMA

Release Notes:

2.50.5 (2021-Aug-11)

  *** Includes Callsign database file version 2021-08-?? (2021-Aug-11)

  New:

    - Worked B4 Alert: Ignoreing the B4 status based on the age of QSOs in the Log.
       Selectable in Monthly increments, 1, 2, 3, 6, 9, 12, 24 and 36 Months. The age
       is determinined by the utc Date when the current JTAlert session is started.
       See the Alerts -> Worked B4 section of the main JTAlert window Settings.

    - User Defined Alert: New %JTAlert_IsFFMAGrid% environment variable has been
       added for use within the Alert script/batch file. This environment variable will
       indicated "Yes" or "No" if the Grid of the Alerted decode is an FFMA grid.

    - Activity Window: WSJTX/JTDX active Band and Mode now displayed in status bar.
       Note: This is for the first JTAlert instance only (#1).

    - Activity Window: The Band matching the WSJTX/JTDX active Band now has a user-
       settable colored indicator to the left of the Band title. The tx and rx count
       numbers of the active Band are displayed with an increased font weight.
       Note: This is for the first JTAlert instance only (#1).


  Changes:

    - WSJTX/JTDX UDP Resend: If the UDP resend is enabled and the port is set to
       match the WSJTX/JTDX UDP Server port, the port is reset to the default 2334
       and the resend option is disabled. This is to prevent resent data being sent
       back to the port that JTAlert is listening too for UDP messages from WSJTX/JTDX
       and creating a feedback loop causing endless duplicated decodes and logging

    - Sample User Alert script: The script has been updated to use the CMail freeware
       command-line SMTP mailer. CMail supports SSL/TLS connections to SMTP accounts
       something that was not possible with the previously used Blat mailer.


  Fixes:

    - Callsigns Window: Band and Mode shown in status bar not visible after
       closing and reopening the window.

    - Logging: "QSO_DATE_OFF" not being sent in logging instruction sent to all
       supported logs when there was not a date change during the length of a QSO.
       The lastqso.adi file was also not getting this data. Note: the QSO End Date
       is not sent to ACLog as it has no support for this data in its logging API.

    - Activity Window: Last display line, Band or Total depending on display
       options not visible when window is first shown after startup requiring
       a manual window resizing to bring the missing line back into view.


locked Re: Callsigns window

Joe Subich, W4TV
 

Left click on the window (to make it active) then press F2 to
open the Window Options dialog.

*Uncheck* both Size Locked and Position Locked. Now you can
grab the edges of the windows and resize it as well as grab
the top bar and move the window.

73,

... Joe, W4TV

On 2021-08-12 1:57 PM, Arthur Smith wrote:
My callsign window has shrunk down to very small and I can't resize it or move it.


locked 2 meter wanted grid bug?

John P
 

Just rebuilt the alerts database after confirming a few new VHF grids today. I use DxKeeper for logging. When I look at confirmed 2 meter grids, ones that I've worked via the satellites are being included. In DxKeeper, the "Mode" for satellite contacts is "SAT" and these should not be included in the 2 meter count. There actually should be a separate "Wanted Grid" page for satellite contacts.
--
John P.
WA2FZW


locked Callsigns window

Arthur Smith
 

My callsign window has shrunk down to very small and I can't resize it or move it. 


locked Re: Feature Request - Log4OM V2

Joe Subich, W4TV
 

1) WSJTX, Omni-Rig and Log4OM *MUST ALL* be operating with
standard permissions *NOT* "Run a Administrator"

2) WSJTX should use Omni-RIG as the "Rig" selection

3) Omni-Rig provides rig sharing between WSJTX and Log4OM.

*READ AND STUDY* the appropriate help files until you understand
the rig set-up.

73,

... Joe, W4TV

On 2021-08-11 3:06 PM, Dana Smith wrote:
Thanks. Been waiting to here from them. But I now have the Log4OM seeing the radio, but WSJT-X says it can’t see the com port leading me to more confusion Hi Hi
WSJTX is decoding, but the program won’t see the radio so it’s receiving signals but won’t set the frequency for transmit, etc. I am very confused now!!!!


locked Re: Feature Request - Log4OM V2

Dana Smith
 

Thanks. Been waiting to here from them. But I now have the Log4OM seeing the radio, but WSJT-X says it can’t see the com port leading me to more confusion Hi Hi
WSJTX is decoding, but the program won’t see the radio so it’s receiving signals but won’t set the frequency for transmit, etc. I am very confused now!!!!

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH


locked Re: Feature Request - Log4OM V2

Jim N6VH
 

On 8/11/2021 11:22 AM, Dana Smith wrote:
Jim,
I understand that. Log4OM V2 is what doesn’t recognize the radio. Lof4OM Verson 1 worked just fine.
So I don’t know what setup for the interface is different, etc.
Thanks,
Dana
Dana,

Understood.  Then the question might be better asked on the Log4OM forum, on their web page. There are several people there who could help.

73,

Jim N6VH


locked Re: Feature Request - Log4OM V2

Dana Smith
 

Jim,
I understand that. Log4OM V2 is what doesn’t recognize the radio. Lof4OM Verson 1 worked just fine.
So I don’t know what setup for the interface is different, etc.
Thanks,
Dana

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH


locked Re: Feature Request - Log4OM V2

Jim N6VH
 

On 8/11/2021 7:21 AM, Dana Smith wrote:
Does anyone have any idea why V2 won't recognize the transceiver although V1 worked well?
Icom 7410, Windows 10.
K7QH

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH
JTAlert doesn't interact with any transceiver. Is it possible the problem is with WSJT-X?

73,

Jim N6VH


locked Re: CQ Marathon anomalies

Phil Cooper
 

Many thanks for that Laurie,

I will keep an eye out, but I think this may have solved the problem.
As yet, i haven't seen anything that might give an alert.

Very best 73

Phil GU0SUP

-----Original Message-----
From: "HamApps Support (VK3AMA)" <vk3ama.ham.apps@gmail.com>
Sent: Wednesday, 11 August, 2021 10:03
To: Support@HamApps.groups.io
Subject: Re: [HamApps] CQ Marathon anomalies

On 11/08/2021 6:42 pm, Phil Cooper via groups.io wrote:

I do indeed have a QSL requirement set in the rebuild.... It is set to
LoTW, so I guess that is where the anomaly is coming from?
However, as QSL's are NOT needed, I have turned that off.

I will give that a go and see what happens...

73 de Phil GU0SUP
That will be the reason previously worked and auto-marked as no longer
needed Marathon entities are re-alerting at a later time as the rebuild
is resetting the need status because it is looking for LoTW
confirmations in your log.

You can keep the Lotw requirement set for the other Alerts and turn off
all QSL requirements for the Marathon Alert only. The individual Alerts
have independent QSL requirements set under their respective sections of
the Rebuild settings.

de Laurie VK3AMA


locked Re: Feature Request - Log4OM V2

Joel
 

Dana

For my 7300 I had to get a USB to CV-I cable and follow this setup to get it to work with WSJTX and FLDigi. Try selecting your radio in omnirig for the setup:

Icom IC7300 CAT control for multiple DATA programs.
The IC7300 and similar radios that have two CAT connections that can be separated provide an easy and unique method of connecting multiple software data packages.
1. Having installed the Icom USB port drivers to the PC
2. Connect a USB cable to the rear connection on the IC7300 and to a USB port on the PC
3. Connect a USB CI-V cable to the ‘REMOTE’ socket on the back of the IC-7300 and another USB port on the PC.
4. Make a note of the port numbers for these two connections as shown in the PC device manager
Setting up the IC7300
In Menu/Set/Connectors/CI-V set the following
CI-V Baud rate = 19200
CI-V Tranceive = OFF
CI-V USB Port = Unlink from (Remote) CI-V USB Baud Rate = 19200
All other settings as default
Setting up Log4OM
Download and install Omnirig.
In Settings/Program Configuration/CAT Interface
CAT Engine = Omnirig
Check the box = Auto start CAT
Check the box = Invert SSB side (CW)
Check the box = Switch to digital mode when required Default = Select FT8 from list
Click ‘SAVE AND APPLY’
   24

In the Omnirig menu
1. Select the radio from the drop-down list (IC7300 DATA)
2. Select the com port number for the USB – USB connection to the radio and set the Baud rate to 19200
3. Click OK (Frequency and mode changes on the radio will be reflected in Log4OM
Setting up WSJT CAT control
In WSJT File/Settings/Radio
Select OMNIRIG Rig?? In the Rig menu
Set PTT method to CAT
Set Mode to DATA/PKT
Set Split Operation to FAKE IT Click OK
Setting up FLDIGI CAT control
In FLDigi Configure/Configure Dialog/Rig Control/Hamlib
Select Icom IC7300 (Stable) from the Rig menu Check the box ‘USE HAMLIB’
Select the USB CI-V – Remote com port number in the ‘DEVICE’ menu Set ‘BAUD RATE’ to 19200
Click on ‘INITIALISE’
Click ‘SAVE’
Click ‘Close’
In the Configure menu click on Save Config

Good luck & 73
Joel
AC8WS

On Aug 11, 2021, at 10:21 AM, Dana Smith <ah6rim9@...> wrote:


Does anyone have any idea why V2 won't recognize the transceiver although V1 worked well?
Icom 7410, Windows 10.
K7QH

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH


locked Re: Feature Request - Log4OM V2

Dana Smith
 

Does anyone have any idea why V2 won't recognize the transceiver although V1 worked well?
Icom 7410, Windows 10.
K7QH

--
Any chance there is a version of Alert that works on a Mac or to be developed?
K7QH


locked Re: Feature Request - DXCC Most Wanted rank

Pete Ritter K5CPR
 

I hadn't envisioned it as a real-time lookup. I'd think that an infrequent update of the MWL of, say, every six months, would be fine since the ranks don't change much.  And I agree with you that it is eye candy and therefore not urgent or very important. Thanks for considering the change. 


locked Re: CQ Marathon anomalies

HamApps Support (VK3AMA)
 

On 11/08/2021 6:42 pm, Phil Cooper via groups.io wrote:

I do indeed have a QSL requirement set in the rebuild.... It is set to LoTW, so I guess that is where the anomaly is coming from?
However, as QSL's are NOT needed, I have turned that off.

I will give that a go and see what happens...

73 de Phil GU0SUP

That will be the reason previously worked and auto-marked as no longer needed Marathon entities are re-alerting at a later time as the rebuild is resetting the need status because it is looking for LoTW confirmations in your log.

You can keep the Lotw requirement set for the other Alerts and turn off all QSL requirements for the Marathon Alert only. The individual Alerts have independent QSL requirements set under their respective sections of the Rebuild settings.

de Laurie VK3AMA


locked Re: CQ Marathon anomalies

Phil Cooper
 

Hi Laurie,

I do indeed have a QSL requirement set in the rebuild.... It is set to LoTW, so I guess that is where the anomaly is coming from?
However, as QSL's are NOT needed, I have turned that off.

I will give that a go and see what happens...

73 de Phil GU0SUP


locked Re: Feature Request - DXCC Most Wanted rank

HamApps Support (VK3AMA)
 

On 11/08/2021 7:02 am, HamApps Support (VK3AMA) via groups.io wrote:
On 10/08/2021 3:32 am, Pete Ritter K5CPR via groups.io wrote:
I doubt that I'm the first to suggest this, but a quick search revealed no other such suggestions, so here goes ...

How about adding the rank on ClubLog's "DXCC Most Wanted List" to the info on the hover-over pop-up?

This is the first request for this.

Performing an online lookup to determine where a decoded station appears in the "Most Wanted" rankings is not suitable for the real-time alerting of JTAlert. It would be more suitable as part of the current online lookups when the DXCall changes. That is limited to the the data gathering & display for the current QSO partner.

JTAlert could mitigate the overhead of an online lookup by caching the lookup results as it currently does for other CPU expensive tasks like log B4 checks & XML lookups.

Having JTAlert from multiple users hitting the ClubLog server, even with local lookup caching, would likely not be appreciated by ClubLog.

JTAlert could eliminate the online-lookups by have the Rankings stored locally in the Callsigns database, my preferred method BTW, but that will require extending the Callsign database schema producing a database that is incompatible with all current JTAlert versions. Extending the Callsign database is currently a work-in-progress project as I have other data I want to include as part of some Alerting enhancements that are planned.

Knowing a station's position in the "Most Wanted" rankings, is in my mind, an "eye-candy" feature, like showing the location of decoded Callsigns on a world map. Both achieve little in working/logging stations, nice to look at, but not adding any real utility to the real-time alerting, IMO.

This is something I will add to the "nice-to-have-but-not-urgent" todo list. It may get elevated from that list when the current Callsign Database redesign project progresses.

de Laurie VK3AMA


Adding to my previous message...

At the time of my initial response I hadn't done any investigation into the lookup mechanism on Clublog. I assumed the lookup would be done in real-time (like xml lookups), thus my comments on overhead. Turns out the "Most Wanted" rankings are updated on a Monthly basis. That sort of frequency is a better fit for inclusion of the data into the existing database. It will be trivial to add to the database, but will be a breaking change so will not be rolled out anytime soon. It will have to wait until I finish the database extension project.

The inclusion & display of a ranking number (that is all it is) is not a high priority at this time.

de Laurie VK3AMA


locked Re: Feature Request - DXCC Most Wanted rank

HamApps Support (VK3AMA)
 

On 10/08/2021 3:32 am, Pete Ritter K5CPR via groups.io wrote:
I doubt that I'm the first to suggest this, but a quick search revealed no other such suggestions, so here goes ...

How about adding the rank on ClubLog's "DXCC Most Wanted List" to the info on the hover-over pop-up?

This is the first request for this.

Performing an online lookup to determine where a decoded station appears in the "Most Wanted" rankings is not suitable for the real-time alerting of JTAlert. It would be more suitable as part of the current online lookups when the DXCall changes. That is limited to the the data gathering & display for the current QSO partner.

JTAlert could mitigate the overhead of an online lookup by caching the lookup results as it currently does for other CPU expensive tasks like log B4 checks & XML lookups.

Having JTAlert from multiple users hitting the ClubLog server, even with local lookup caching, would likely not be appreciated by ClubLog.

JTAlert could eliminate the online-lookups by have the Rankings stored locally in the Callsigns database, my preferred method BTW, but that will require extending the Callsign database schema producing a database that is incompatible with all current JTAlert versions. Extending the Callsign database is currently a work-in-progress project as I have other data I want to include as part of some Alerting enhancements that are planned.

Knowing a station's position in the "Most Wanted" rankings, is in my mind, an "eye-candy" feature, like showing the location of decoded Callsigns on a world map. Both achieve little in working/logging stations, nice to look at, but not adding any real utility to the real-time alerting, IMO.

This is something I will add to the "nice-to-have-but-not-urgent" todo list. It may get elevated from that list when the current Callsign Database redesign project progresses.

de Laurie VK3AMA


locked Re: Feature Request - DXCC Most Wanted rank

HamApps Support (VK3AMA)
 

On 10/08/2021 11:16 pm, Pete Ritter K5CPR via groups.io wrote:
It’s to me more valuable than the DXCC entity number that is displayed already.

The DXCC number is displayed because there is no overhead in doing so, it is already available internally due to checking the DXCC Alert status.

de Laurie VK3AMA

2021 - 2040 of 38542