Date   

Automated spots not displaying when connected directly--fine using CC User

Peter Dougherty
 

Hi Dave/all,
I seem to be missing a great number of cluster spots. I think it's limited to skimmer-generated spots, but I'm not 100% sure. For the sake of simplicity and troubleshooting I have only one cluster connected at the moment (K3NC). Also for the sake of troubleshooting I connected to that same K3NC cluster using CC User software (ve7cc's cluster user program). Note that CC User is not feeding Spot collector; the two programs are connected to the same node independently.

Looking at the feed of spots on CC User I'm seeing the usual/expected flood of mostly skimmer-generated spots, but automated/skimmer spots are somehow not being passed on to Spot Collector.
Manually generated spots are displayed in SC, albeit about 20-30 seconds after they display in the CC User window.

The next step was to try connecting Spot Collector to CC User. I disconnected SC from its direct connection to the K3NC node, but instead was receiving K3NC node spots via CC User. Connected this way, the full feed is arriving in the Spot Collector window.

Is there a setting to reject automatically-sent CW, FT4/FT8 spots somewhere in SC? If there is I can't find it, but it's clear that when connected directly to a cluster (any cluster, not just K3NC), skimmer spots are being rejected by SC, but they come back if I get the cluster feed via CC User. Any thoughts?


Re: Adding old QSL cards to DXKeeper

Bill - AA4M
 

Wow, thanks for the comprehensive information Dave.  Unfortunately after studying the message and digging into the links you provided, I have not fully resolved my situation.  Here's where I stand:

- I saved a copy of the AA4M.mdb file in another folder.

- I've downloaded the DXCC credits and have more than 1,000 showing on the report.  BTW - this run took about 45 minutes, this is with a FAST connection and a FAST computer, hi.

- What I'd like to do now is delete all the records that don't include 4 items (Call, Date, Band, Mode) and upload the remainder to my database.  Then want to be able to see these new contacts in any award reports but do NOT want to upload them to LotW.

It seems this should be easy to do, but in reading all the information you've provided I'm more confused than ever!

Can you help?

73, Bill  AA4M


On 11/22/2020 18:51:34, Dave AA6YQ wrote:
+ AA6YQ comments below
I have about 1,000 old QSL cards, some dating back to the 1960's, that I'd like to add to DXKeeper, just so that the progress report somewhat matches what the ARRL has on their records.  A number of deleted countries are included in the 1,000.  Hopefully all I'll need to add are Call, Date (Year only hopefully?), Band and Mode.  None of the other information is needed (time, grid, etc.) for my purposes, at least I don't think it is.  My current DXKeeper database starts in 2018, so I may need to change the starting date from how I originally configured DXLab 2 years ago.

What do I need to do to simplify entry of all these cards?

+ DXKeeper can be configured to optimize for the entry of "already-completed" QSOs from paper logbooks or QSL cards. See

<https://www.dxlabsuite.com/dxkeeper/Help/LogCompletedMain.htm>

+ Getting familiar with DXKeeper's keyboard shortcuts will help speed QSO entry:

<https://www.dxlabsuite.com/dxkeeper/Help/KeyboardShortcuts.htm>

+ When you enter a callsign, DXKeeper will select the appropriate DXCC entity based on current callsign=>entity rules. That selection may be incorrect for older QSOs, particularly those with now-deleted entities. Perform the correction based on the information specified on each QSL card. There's a set DXKeeper scripts that will update logged QSOs with the appropriate DXCC entity based on the callsign and the QSO date, but your QSL cards are generally a more authoritative source; as with everything else in DXing, there are exceptions.

+ You must specify a valid date-and-time with each QSO. If you're going to take the time to enter these QSOs, I suggest that you accurately capture the year, month, and day; leaving the times at 0Z would be fine.

+ If you're not that concerned about accuracy, and alternative to adding manually logging completed QSOs to match your DXCC credits is to have DXKeeper download your DXCC credits from the ARRL, and fabricate "credit-only QSOs". This functionality is described here:

<https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#Managing%20DXCC%20Credits>

+ Before you can fabricate "credit-only QSO", you must first direct DXKeeper to link each of your DXCC credits to a logged QSO, if possible; typically, 25% of your DXCC credits from QSL cards you submitted to the ARRL DXCC desk will have to be manually linked to logged QSOs due to data entry errors or shortcuts taken by the DXCC desk. DXKeeper can then be directed to fabricate a QSO for each DXCC credit not linked to a logged QSO.

+ Step-by-step instructions are here:

<https://www.dxlabsuite.com/dxlabwiki/ManageDXCCCredits>

+ and here

<https://www.dxlabsuite.com/dxlabwiki/CreateCreditOnlyQSOs>

+ If you choose this approach, be sure to make a backup copy of your log before you start.

        73,

              Dave, AA6YQ

 

 

 

 



Re: Capture Window question

w3qt_mike
 

Hi Bill,

 

Thanks for the response.  It’s not a big deal.  In the past I hadn’t really paid much attention to some of the information in the Capture window.  I copy code in my head without many notes so it was easy just to relax and not pay much attention to the monitor except for entering the signal report.  I’ll remember to check the window and catch any discrepancies from now on.

 

73,

Mike, W3QT

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of g4wjs
Sent: Monday, November 23, 2020 09:54 AM
To: DXLab@groups.io
Subject: Re: [DXLab] Capture Window question

 

Hi Mike,

 

I think the intent of the documentation is to say that empty fields are initialized. Perhaps it should say prior QSO information is first carried forward before any empty fields are populated from an automatic callbook lookup.

 

73
Bill
G4WJS.

 

On 23/11/2020 14:45, w3qt_mike wrote:

Dave, thanks for the reply.  I guess some of my confusion/questions arose from some of the information presented in DXLabwiki.  Here’s where I was confused:

 

From “Determining a Station’s Location”:

 

“DXKeeper can be configured to query a local or online callbook to obtain the location information last posted there by whoever manages the entry for a callsign, typically, its owner.”

 

In this case the information on QRZ was updated with the new QTH information, so when I typed the callsign into the Capture window I had expected a new lookup. 

 

From “Using Callbooks”:

 

“Automatically use callbook data to initialize new QSOs: if you enable this option, DXKeeper will automatically perform a Callbook lookup when you type a callsign into the Capture window or the Main window's Log QSOs tab and strike the Enter or Tab keys; information from the Callbook will be used to fill in missing items, but will not replace items you've already specified.”

 

I expected a new lookup because this was a new QSO, even though it was with a previously worked station.  I’ll be more aware in the future and check before logging.  Thanks again.

 

73,

Mike, W3QT

 

 

 

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Sunday, November 22, 2020 07:58 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Capture Window question

 

+ AA6YQ comments below

Thanks for your thoughts.  If DXK via Capture Window queries QRZ (XML subscription) for information on each QSO, as it does to fill in the initial QSO information, wouldn’t DXK then automatically retrieve updated info for subsequent QSOs?  It sounds like you’re suggesting that DXK queries its existing log and if it finds the call previously logged it doesn’t query QRZ for the possibility of updated information.  That would assume a QTH is fixed and never changes or calls aren’t reassigned for whatever reason.  That’s where I’m seeking clarification.  Either I missed a setting or this is the way the system works.  I did make the manual changes and am wondering if that’s what’s needed under similar circumstances in the future – just want to keep things as accurate as possible

+ As described in this article, DXKeeper gives priority to location information from a previously logged QSO over location information from a callbook lookup:

<https://www.dxlabsuite.com/dxlabwiki/DetermineStationLocation>

          73,

               Dave, AA6YQ

 


--
73

Bill

G4WJS.


Re: Capture Window question

g4wjs
 

Hi Mike,

I think the intent of the documentation is to say that empty fields are initialized. Perhaps it should say prior QSO information is first carried forward before any empty fields are populated from an automatic callbook lookup.

73
Bill
G4WJS.

On 23/11/2020 14:45, w3qt_mike wrote:

Dave, thanks for the reply.  I guess some of my confusion/questions arose from some of the information presented in DXLabwiki.  Here’s where I was confused:

 

From “Determining a Station’s Location”:

 

“DXKeeper can be configured to query a local or online callbook to obtain the location information last posted there by whoever manages the entry for a callsign, typically, its owner.”

 

In this case the information on QRZ was updated with the new QTH information, so when I typed the callsign into the Capture window I had expected a new lookup. 

 

From “Using Callbooks”:

 

“Automatically use callbook data to initialize new QSOs: if you enable this option, DXKeeper will automatically perform a Callbook lookup when you type a callsign into the Capture window or the Main window's Log QSOs tab and strike the Enter or Tab keys; information from the Callbook will be used to fill in missing items, but will not replace items you've already specified.”

 

I expected a new lookup because this was a new QSO, even though it was with a previously worked station.  I’ll be more aware in the future and check before logging.  Thanks again.

 

73,

Mike, W3QT

 

 

 

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Sunday, November 22, 2020 07:58 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Capture Window question

 

+ AA6YQ comments below

Thanks for your thoughts.  If DXK via Capture Window queries QRZ (XML subscription) for information on each QSO, as it does to fill in the initial QSO information, wouldn’t DXK then automatically retrieve updated info for subsequent QSOs?  It sounds like you’re suggesting that DXK queries its existing log and if it finds the call previously logged it doesn’t query QRZ for the possibility of updated information.  That would assume a QTH is fixed and never changes or calls aren’t reassigned for whatever reason.  That’s where I’m seeking clarification.  Either I missed a setting or this is the way the system works.  I did make the manual changes and am wondering if that’s what’s needed under similar circumstances in the future – just want to keep things as accurate as possible

+ As described in this article, DXKeeper gives priority to location information from a previously logged QSO over location information from a callbook lookup:

<https://www.dxlabsuite.com/dxlabwiki/DetermineStationLocation>

          73,

               Dave, AA6YQ



--
73

Bill

G4WJS.


Re: Capture Window question

w3qt_mike
 

Dave, thanks for the reply.  I guess some of my confusion/questions arose from some of the information presented in DXLabwiki.  Here’s where I was confused:

 

From “Determining a Station’s Location”:

 

“DXKeeper can be configured to query a local or online callbook to obtain the location information last posted there by whoever manages the entry for a callsign, typically, its owner.”

 

In this case the information on QRZ was updated with the new QTH information, so when I typed the callsign into the Capture window I had expected a new lookup. 

 

From “Using Callbooks”:

 

“Automatically use callbook data to initialize new QSOs: if you enable this option, DXKeeper will automatically perform a Callbook lookup when you type a callsign into the Capture window or the Main window's Log QSOs tab and strike the Enter or Tab keys; information from the Callbook will be used to fill in missing items, but will not replace items you've already specified.”

 

I expected a new lookup because this was a new QSO, even though it was with a previously worked station.  I’ll be more aware in the future and check before logging.  Thanks again.

 

73,

Mike, W3QT

 

 

 

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Dave AA6YQ
Sent: Sunday, November 22, 2020 07:58 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Capture Window question

 

+ AA6YQ comments below

Thanks for your thoughts.  If DXK via Capture Window queries QRZ (XML subscription) for information on each QSO, as it does to fill in the initial QSO information, wouldn’t DXK then automatically retrieve updated info for subsequent QSOs?  It sounds like you’re suggesting that DXK queries its existing log and if it finds the call previously logged it doesn’t query QRZ for the possibility of updated information.  That would assume a QTH is fixed and never changes or calls aren’t reassigned for whatever reason.  That’s where I’m seeking clarification.  Either I missed a setting or this is the way the system works.  I did make the manual changes and am wondering if that’s what’s needed under similar circumstances in the future – just want to keep things as accurate as possible

+ As described in this article, DXKeeper gives priority to location information from a previously logged QSO over location information from a callbook lookup:

<https://www.dxlabsuite.com/dxlabwiki/DetermineStationLocation>

          73,

               Dave, AA6YQ

 

 


DX Keeper from JS8 Call

VK5OM@...
 

So I got my WTSJTX to directly log to DX Keeper with that simple extra program JT Alert. 

The next question is how do I get it to Auto log from JS8 Call?


Re: ISSUE LOADING WORKSPACE INCORRECTLY?

Steve / W1SMC
 

Thanks Dave .....

I finally had to use the default Workspace folder.  This works fine.  


Re: Importing an ADIF file

Dave AA6YQ
 

+ AA6YQ comments below
I have just down loaded and installed the latest DX Keeper, and it appears to be working. That is until I attempted  to upload some qso's to LoTW and they were rejected "FT8" mode invalid. I went through this with wxjt-x and HR Deluxe until the problem vanished. Now I need to find a solution for FT8 modes and DX Keeper.

+ Welcome to DXLab, Mike!

+ What version number appears in the title bar of DXKeeper's Main window?

+ What is the exact text of the error message informing you that FT8 is invalid?

+ On the LoTW tab of DXKeeper's Configuration window, there's a TQL panel at the bottom; please click the Run button in the panel's upper-right corner. When TQSL starts, open its Help menu, and select the "Check for Updates..." command. What version of "Configuration Data" does TQSL show as installed?

      73,

            Dave, AA6YQ

 


Re: Importing an ADIF file

 

I have just down loaded and installed the latest DX Keeper, and it appears to be working. That is until I attempted  to upload some qso's to LoTW and they were rejected "FT8" mode invalid. I went through this with wxjt-x and HR Deluxe until the problem vanished. Now I need to find a solution for FT8 modes and DX Keeper.
--
Mike
KE5WCT


Re: Adding old QSL cards to DXKeeper

Dave AA6YQ
 

+ AA6YQ comments below
I have about 1,000 old QSL cards, some dating back to the 1960's, that I'd like to add to DXKeeper, just so that the progress report somewhat matches what the ARRL has on their records.  A number of deleted countries are included in the 1,000.  Hopefully all I'll need to add are Call, Date (Year only hopefully?), Band and Mode.  None of the other information is needed (time, grid, etc.) for my purposes, at least I don't think it is.  My current DXKeeper database starts in 2018, so I may need to change the starting date from how I originally configured DXLab 2 years ago.

What do I need to do to simplify entry of all these cards?

+ DXKeeper can be configured to optimize for the entry of "already-completed" QSOs from paper logbooks or QSL cards. See

<https://www.dxlabsuite.com/dxkeeper/Help/LogCompletedMain.htm>

+ Getting familiar with DXKeeper's keyboard shortcuts will help speed QSO entry:

<https://www.dxlabsuite.com/dxkeeper/Help/KeyboardShortcuts.htm>

+ When you enter a callsign, DXKeeper will select the appropriate DXCC entity based on current callsign=>entity rules. That selection may be incorrect for older QSOs, particularly those with now-deleted entities. Perform the correction based on the information specified on each QSL card. There's a set DXKeeper scripts that will update logged QSOs with the appropriate DXCC entity based on the callsign and the QSO date, but your QSL cards are generally a more authoritative source; as with everything else in DXing, there are exceptions.

+ You must specify a valid date-and-time with each QSO. If you're going to take the time to enter these QSOs, I suggest that you accurately capture the year, month, and day; leaving the times at 0Z would be fine.

+ If you're not that concerned about accuracy, and alternative to adding manually logging completed QSOs to match your DXCC credits is to have DXKeeper download your DXCC credits from the ARRL, and fabricate "credit-only QSOs". This functionality is described here:

<https://www.dxlabsuite.com/dxkeeper/Help/Progress.htm#Managing%20DXCC%20Credits>

+ Before you can fabricate "credit-only QSO", you must first direct DXKeeper to link each of your DXCC credits to a logged QSO, if possible; typically, 25% of your DXCC credits from QSL cards you submitted to the ARRL DXCC desk will have to be manually linked to logged QSOs due to data entry errors or shortcuts taken by the DXCC desk. DXKeeper can then be directed to fabricate a QSO for each DXCC credit not linked to a logged QSO.

+ Step-by-step instructions are here:

<https://www.dxlabsuite.com/dxlabwiki/ManageDXCCCredits>

+ and here

<https://www.dxlabsuite.com/dxlabwiki/CreateCreditOnlyQSOs>

+ If you choose this approach, be sure to make a backup copy of your log before you start.

        73,

              Dave, AA6YQ

 

 

 

 


Re: Capture Window question

Dave AA6YQ
 

+ AA6YQ comments below
Thanks for your thoughts.  If DXK via Capture Window queries QRZ (XML subscription) for information on each QSO, as it does to fill in the initial QSO information, wouldn’t DXK then automatically retrieve updated info for subsequent QSOs?  It sounds like you’re suggesting that DXK queries its existing log and if it finds the call previously logged it doesn’t query QRZ for the possibility of updated information.  That would assume a QTH is fixed and never changes or calls aren’t reassigned for whatever reason.  That’s where I’m seeking clarification.  Either I missed a setting or this is the way the system works.  I did make the manual changes and am wondering if that’s what’s needed under similar circumstances in the future – just want to keep things as accurate as possible

+ As described in this article, DXKeeper gives priority to location information from a previously logged QSO over location information from a callbook lookup:

<https://www.dxlabsuite.com/dxlabwiki/DetermineStationLocation>

          73,

               Dave, AA6YQ

 

 


Re: Capture Window question

w3qt_mike
 

Dave,

 

Thanks for your thoughts.  If DXK via Capture Window queries QRZ (XML subscription) for information on each QSO, as it does to fill in the initial QSO information, wouldn’t DXK then automatically retrieve updated info for subsequent QSOs?  It sounds like you’re suggesting that DXK queries its existing log and if it finds the call previously logged it doesn’t query QRZ for the possibility of updated information.  That would assume a QTH is fixed and never changes or calls aren’t reassigned for whatever reason.  That’s where I’m seeking clarification.  Either I missed a setting or this is the way the system works.  I did make the manual changes and am wondering if that’s what’s needed under similar circumstances in the future – just want to keep things as accurate as possible.

 

73,

Mike, W3QT

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of David Bunte
Sent: Sunday, November 22, 2020 06:45 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Capture Window question

 

Mike -

 

If I am wrong, I am sure someone else will give a better answer, but I believe that in the case you described, you need to enter NC as his QTH for your most recent QSO... then it will come up the next time you work him. Otherwise DXK has no way to know that he changed QTHs.

 

73 de Dave - K9FN

 

On Sun, Nov 22, 2020 at 6:36 PM w3qt_mike <w3qt@...> wrote:

Hi Dave,

 

I worked a station today for the second time in three years.  Three years ago his QTH was in IL.  Today his QTH is in NC.  When I entered his call into the Capture Window his old logged QTH information filled in instead of his current location information from QRZ.  I wouldn’t have noticed the discrepancy except when he sent me his QTH I noticed that it didn’t match the Capture Window.  Am I missing a config setting to allow for the latest QTH information from QRZ to populate the Capture Window, or should I expect DXK to use the last logged QSO information under these circumstances?  Thanks.

 

73,

Mike, W3QT


Re: Which antivirus program works best with DXLab Suite

Jackson McNees
 

Steve,

 

My computer had a hardware failure, so took to shop.  Talked to them about their experience with systems brought in that had virus problems.  The recommended using Windows Defender that comes with Windows.  That is what I have been using, it is free, and have had no problem interaction with DXLab.

 

73,

Jack, K4IJQ

 

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of swpub via groups.io
Sent: Sunday, November 22, 2020 2:28 PM
To: DXLab@groups.io
Subject: [DXLab] Which antivirus program works best with DXLab Suite

 

Which (if any) antivirus/malware applications have been found to work the best with DXLab Suite, i.e., that both protect well and do not cause problems for DXLab Suite?

I finally got Norton Security Online to tolerate the DXLab Suite executables, but doing it required setting up scan exclusions for numerous exe, dll, and other files - several dozen in all - which was quite a pain.  At the end of the year my ISP will no longer provide Norton free to subscribers, so I'm thinking of switching to something else, and it would be nice to avoid repeating the hassle if that is even possible.

Thanks.

Steve, N5EP


Re: Capture Window question

David Bunte
 

Mike -

If I am wrong, I am sure someone else will give a better answer, but I believe that in the case you described, you need to enter NC as his QTH for your most recent QSO... then it will come up the next time you work him. Otherwise DXK has no way to know that he changed QTHs.

73 de Dave - K9FN

On Sun, Nov 22, 2020 at 6:36 PM w3qt_mike <w3qt@...> wrote:

Hi Dave,

 

I worked a station today for the second time in three years.  Three years ago his QTH was in IL.  Today his QTH is in NC.  When I entered his call into the Capture Window his old logged QTH information filled in instead of his current location information from QRZ.  I wouldn’t have noticed the discrepancy except when he sent me his QTH I noticed that it didn’t match the Capture Window.  Am I missing a config setting to allow for the latest QTH information from QRZ to populate the Capture Window, or should I expect DXK to use the last logged QSO information under these circumstances?  Thanks.

 

73,

Mike, W3QT


Capture Window question

w3qt_mike
 

Hi Dave,

 

I worked a station today for the second time in three years.  Three years ago his QTH was in IL.  Today his QTH is in NC.  When I entered his call into the Capture Window his old logged QTH information filled in instead of his current location information from QRZ.  I wouldn’t have noticed the discrepancy except when he sent me his QTH I noticed that it didn’t match the Capture Window.  Am I missing a config setting to allow for the latest QTH information from QRZ to populate the Capture Window, or should I expect DXK to use the last logged QSO information under these circumstances?  Thanks.

 

73,

Mike, W3QT


Adding old QSL cards to DXKeeper

Bill - AA4M
 

I have about 1,000 old QSL cards, some dating back to the 1960's, that I'd like to add to DXKeeper, just so that the progress report somewhat matches what the ARRL has on their records.  A number of deleted countries are included in the 1,000.  Hopefully all I'll need to add are Call, Date (Year only hopefully?), Band and Mode.  None of the other information is needed (time, grid, etc.) for my purposes, at least I don't think it is.  My current DXKeeper database starts in 2018, so I may need to change the starting date from how I originally configured DXLab 2 years ago.

What do I need to do to simplify entry of all these cards?

Thanks & 73,
Bill  AA4M


Re: Which antivirus program works best with DXLab Suite

BILL KENNAMER
 

I use Bitcefender. If it blocks something, it will tell you, and it can be switched on, at which point you won’t have a further problem. 

On Sunday, November 22, 2020, 1:27 PM, swpub via groups.io <swpub@...> wrote:

Which (if any) antivirus/malware applications have been found to work the best with DXLab Suite, i.e., that both protect well and do not cause problems for DXLab Suite?

I finally got Norton Security Online to tolerate the DXLab Suite executables, but doing it required setting up scan exclusions for numerous exe, dll, and other files - several dozen in all - which was quite a pain.  At the end of the year my ISP will no longer provide Norton free to subscribers, so I'm thinking of switching to something else, and it would be nice to avoid repeating the hassle if that is even possible.

Thanks.

Steve, N5EP


Re: Sync LotW QSOs issues

Dave AA6YQ
 

* More AA6YQ comments below

+ Why are you doing a CTRL-"Sync LoTW QSOs"?

Because the “DXKeeper Update from LotW” windows says: “the Log Page Display contains 29.934 QSOs, so depressing CTRL while clicking “Sync LoTW QSOs” will certainly be faster”

* Yes it will, but why are you trying to update the LoTW acceptance status of every QSO in your log?

* Why not limit the operation to only those QSOs that haven't been accepted by LoTW?

73,

Dave, AA6YQ


Re: Which antivirus program works best with DXLab Suite

neil_zampella
 

I've been using AVG for years, no problems.

Neil, KN3ILZ

On 11/22/2020 1:27 PM, swpub via groups.io wrote:
Which (if any) antivirus/malware applications have been found to work the best with DXLab Suite, i.e., that both protect well and do not cause problems for DXLab Suite?

I finally got Norton Security Online to tolerate the DXLab Suite executables, but doing it required setting up scan exclusions for numerous exe, dll, and other files - several dozen in all - which was quite a pain.  At the end of the year my ISP will no longer provide Norton free to subscribers, so I'm thinking of switching to something else, and it would be nice to avoid repeating the hassle if that is even possible.

Thanks.

Steve, N5EP


Re: Which antivirus program works best with DXLab Suite

Dave AA6YQ
 

+ AA6YQ comments below

Which (if any) antivirus/malware applications have been found to work the best with DXLab Suite, i.e., that both protect well and do not cause problems for DXLab Suite?

I finally got Norton Security Online to tolerate the DXLab Suite executables, but doing it required setting up scan exclusions for numerous exe, dll, and other files - several dozen in all - which was quite a pain. At the end of the year my ISP will no longer provide Norton free to subscribers, so I'm thinking of switching to something else, and it would be nice to avoid repeating the hassle if that is even possible.

+ I use the free version of AVG.

+ Occasionally, I direct MalwareBytes and SpytBot SD to scan my system; I do not leave MalwareBytes running in between scans.

73,

Dave, AA6YQ

3321 - 3340 of 200878