Date   

Re: "Leading! " Filter

iain macdonnell - N6ML
 

On Thu, Mar 26, 2020 at 10:06 AM Pete Smith <n4zr@...> wrote:

I recently uploaded my entire 164K QSO DXKeeper log to Clublog. They responded with 19 exceptions, some of which I have deleted or corrected in DXKeeper, and now I would like to upload just those corrected entries in an ADIF file.
If you've configured DXKeeper for upload to Club Log [1], you'd just
need to make sure that "Club" is set to 'M' (in the Auxiliary panel)
for those QSOs, then click on "Upload" in the Club Log panel on the
Check Progress tab. Alternatively, you could right-click on each QSO
individually and select "Upload to Club Log".

73.

~iain / N6ML

[1] http://www.dxlabsuite.com/dxlabwiki/ClubLogUpload


"Leading! " Filter

Pete Smith
 

I recently uploaded my entire 164K QSO DXKeeper log to Clublog.  They responded with 19 exceptions, some of which I have deleted or corrected in DXKeeper, and now I would like to upload just those corrected entries in an ADIF file.  I saw the box for "leading !" in the Export QSOs tab and thought, "Oh goody, this must be the way to select just a few QSOs to export."  I tested this with one QSO from my log, and it didn't work, although DXKeeper did store the leading "!"

I've searched the Help, in vain, so here I am.  Help much appreciated!

-- 
73, Pete N4ZR
Check out the Reverse Beacon Network 
at <http://reversebeacon.net>, now 
spotting RTTY activity worldwide. 
For spots, please use your favorite 
"retail" DX cluster.


Recurring issue: awards recompute slows down to a crawl

Jan AE7U
 

Hi Everyone:

My DXKeeper awards recompute function used to be "instantaneous", but now it is very slow.  Here is one data point: QSO ends 13:37:00; recompute finishes 13:40:00.  While the recompute is going on, the log is inaccessible.  I had this problem before and it seemed to have self-rectified after installing the latest version of all software, but now the problem is back.  All the software is up to date and Windows 10 has the latest updates installed.  

I don't know if this problem is related to the fact that my JTAlert automatic logging to DXKeeper stopped working after I upgraded to Windows 10 a month or so ago?  

I suspect though, that Windows 10 is the culprit here, but I would not know where to start to fix these problems?


Re: LoTW Callsign Certificate

neil_zampella
 

I believe the only place it needs to be updated in is TQSL.

Neil, KN3ILZ

On 3/25/2020 5:46 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

I have a new updated callsign certificate but I don't see where to update it in DXLAB. Also, they offered the alternative to have
no password and I chose that option.

+ Unless you changed the callsign you're using over the air, no update in DXLab is required.

73,

Dave, AA6YQ



--
This email has been checked for viruses by AVG.
https://www.avg.com


Re: Windows 10 Automatic Update Created Issue with Serial Ports

neil_zampella
 

FWIW ... also check the privacy settings for your Microphone, as it appears that M$ is trying to 'help' you by turning off stuff you turned on.   Check to make sure that WSJT-X still has access to the mic.

Neil, KN3ILZ

On 3/25/2020 2:58 PM, Dave AA6YQ wrote:

+ AA6YQ comments below

On Wed, Mar 25, 2020 at X1:41 AM, Peter Laws wrote:

On Wed, Mar 25, 2020 at 1:38 PM Peter Laws via Groups.Io
<plaws0@...> wrote:


Dave has (somewhere) instructions on disabling automagic updates.
I'll dig for those and see if I can beat AA6YQ to it. :-) It is a
little dependent on which level of W10 you have, IIRC.
https://www.dxlabsuite.com/dxlabwiki/PreventUSBPortPowerDown

Other stuff at https://www.dxlabsuite.com/dxlabwiki/WindowsTricks
including how to better control updates.

+ At this point, the best a Windows 10 user can do is

1. document your serial port assignments

2. configure Windows 10 to only apply updates when you direct it to do so

3. after Windows 10 completes an update, immediately check the serial port assignments, and correct any that have changed.

+ Perhaps someone with Windows device driver programming experience will create a tool that can take a named snapshot of serial port assignments, and restore serial port assignments to those specified in a named snapshot. 

          73,

                Dave, AA6YQ

 

 


Virus-free. www.avg.com


Re: Windows 10 Automatic Update Created Issue with Serial Ports

Dave AA6YQ
 

+ AA6YQ comments below

On Wed, Mar 25, 2020 at 04:38 PM, w6de wrote:

Have Windows-10 stop updating device drivers automatically.

https://www.windowscentral.com/how-disable-automatic-driver-updates-windows-10

Choose the “How to stop updates for drivers with Windows Update using Group Policy” this is a little saver than editing the registry.

Follow the directions given.

I know this works for Windows-10-Pro.  If Windows-10 for Home won’t allow you to perform this group policy change, you’ll have to use the Registry Edit procedure.

 

Make sure your USB to serial adapter is a FTDI chip based adapter.  Also down load the FTDI driver.  And, perform the Group Policy change to keep automatic updates from overloading your FTDI driver with the Microsoft generic USB driver.

 

Even if you aren’t using the USB to Serial adapters, stop the automatic driver updates

+ Thanks, Dave! That article is now accessible via


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

       73,

               Dave, AA6YQ


Re: Windows 10 Automatic Update Created Issue with Serial Ports

w6de
 

Have Windows-10 stop updating device drivers automatically.

https://www.windowscentral.com/how-disable-automatic-driver-updates-windows-10

Choose the “How to stop updates for drivers with Windows Update using Group Policy” this is a little saver than editing the registry.

Follow the directions given.

I know this works for Windows-10-Pro.  If Windows-10 for Home won’t allow you to perform this group policy change, you’ll have to use the Registry Edit procedure.

 

Make sure your USB to serial adapter is a FTDI chip based adapter.  Also down load the FTDI driver.  And, perform the Group Policy change to keep automatic updates from overloading your FTDI driver with the Microsoft generic USB driver.

 

Even if you aren’t using the USB to Serial adapters, stop the automatic driver updates.

 

Now, having said that, with my Windows-10 update to version 1909, the V-1909 update among other things un-did that Policy Change, threw away my FTDI driver, changed all the port assignments AND screwed up my default sound card assignments.

 

73,

Dave, w6de

 

 

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of fjk5146
Sent: 25 March, 2020 21:32
To: DXLab@groups.io
Subject: Re: [DXLab] Windows 10 Automatic Update Created Issue with Serial Ports

 

Thanks to everyone for the helpful information.  I will see if I can do a better job of documenting the serial port information.  I may try to if I can get details at the hardware level that I can use to identify what hardware addresses are connected to each COMM port before and after an update.  Maybe that can be used to ease the remapping.


Also, thanks for the confidence in USB to RS232  adapters.  The device I had the problem with was the USB port on the Green Heron RT11 Rotor controller.  I even installed large chunks of ferrite on the cable without success. I may try using an actual USB to RS232 adapter on the Green Heron serial port to see if that works OK within some RF.  

Thanks again for all the good advice,
--
Fred, KC9QQ


Re: LoTW Callsign Certificate

Dave AA6YQ
 

+ AA6YQ comments below

I have a new updated callsign certificate but I don't see where to update it in DXLAB. Also, they offered the alternative to have
no password and I chose that option.

+ Unless you changed the callsign you're using over the air, no update in DXLab is required.

73,

Dave, AA6YQ


Re: LoTW Callsign Certificate

Bill Pence
 

Pretty certain this gets updated in the eqsl app....


On Wed, Mar 25, 2020, 5:40 PM Michael Daly <n5sj@...> wrote:

Dave,

I have a new updated callsign certificate but I don’t see where to update it in DXLAB.  Also, they offered the alternative to have no password and I chose that option.

 

Cordially,

Mike

 

Michael Daly, N5SJ

1408 Linda Drive

Gallup, NM 87301-5616

DM55pm

505 870 3430

N5sj@...

 


Re: Reduced QSL picture quality

Dave AA6YQ
 

+ AA6YQ comments below

After successfully printing almost a thousand QSLs using the DXKeeper's 'Print QSL cards' feature I'm now running into a problem of quality and its not a printer issue. When I view the background image BMP file with a photo viewing app, both large and small font text and the small logo lettering looks fine. But when I click on the "Print QSL Cards" button with the "Print preview (QSL cards)" box checked, the quality of the preview is much poorer and matches the poorer printed QSL card. I tried an older version of DXK and get the same results, poor quality preview and prints that match what the preview shows. At the top right of the preview the background image dimensions (pixels) reads 538 X 357, if that might be a clue to the poor quality preview. The background image BMP file is the same one that I've been using for over a year.

I love the idea of printing my own cards with QSO data as part of each personalized QSL, but the resolution of the smaller print and small logos on the cards printed by DXK is so poor that I can't use them.

Is there a parameter in the setup that I may be overlooking that may have been changed to cause this problem?

+ If you're saying that the quality of images printed on DXKeeper-generated QSL cards has degraded from what it was in the past, there has been no change to that functionality in DXKeeper for many years. If you specify a date on which you last generated images of acceptable quality, I can send you the then-public version of DXKeeper to test; that will reveal whether the degradation is a result of a subsequent change to DXKeeper or a change in your system.

+ Here's a QSL card that I generated from DXKeeper back in August 2011:

<http://www.dxlabsuite.com/dxkeeper/BackgroundQSL.jpg>

+ It's resolution is 504 x 313 - around 100 pixels per inch. If this is not sufficient for your purposes, your options are to

1. configure DXKeeper to generate an ADIF file from the QSL Queue, and use that to drive a more flexible QSL-generating application:

<https://www.dxlabsuite.com/dxkeeper/Help/QSL.htm#QSLing%20via%20ADIF>

2. Purchase pre-printed QSL cards bearing your images, and have DXKeeper generate QSL labels that you can affix to them:

<https://www.dxlabsuite.com/dxkeeper/Help/QSL.htm#QSLing%20with%20Paper.

73,

Dave, AA6yQ


LoTW Callsign Certificate

Michael Daly
 

Dave,

I have a new updated callsign certificate but I don’t see where to update it in DXLAB.  Also, they offered the alternative to have no password and I chose that option.

 

Cordially,

Mike

 

Michael Daly, N5SJ

1408 Linda Drive

Gallup, NM 87301-5616

DM55pm

505 870 3430

N5sj@...

 


Re: Windows 10 Automatic Update Created Issue with Serial Ports

fjk5146
 

Thanks to everyone for the helpful information.  I will see if I can do a better job of documenting the serial port information.  I may try to if I can get details at the hardware level that I can use to identify what hardware addresses are connected to each COMM port before and after an update.  Maybe that can be used to ease the remapping.


Also, thanks for the confidence in USB to RS232  adapters.  The device I had the problem with was the USB port on the Green Heron RT11 Rotor controller.  I even installed large chunks of ferrite on the cable without success. I may try using an actual USB to RS232 adapter on the Green Heron serial port to see if that works OK within some RF.  

Thanks again for all the good advice,
--
Fred, KC9QQ


Reduced QSL picture quality

Rich - K1HTV
 

After successfully printing almost a thousand QSLs using the DXKeeper's 'Print QSL cards' feature I'm now running into a problem of quality and its not a printer issue. When I view the background image BMP file with a photo viewing app, both large and small font text and the small logo lettering looks fine. But when I click on the "Print QSL Cards" button with the "Print preview (QSL cards)" box checked, the quality of the preview is much poorer and matches the poorer printed QSL card. I tried an older version of DXK and get the same results, poor quality preview and prints that match what the preview shows. At the top right of the preview the background image dimensions (pixels) reads 538 X 357, if that might be a clue to the poor quality preview. The background image BMP file is the same one that I've been using for over a year.

I love the idea of printing my own cards with QSO data as part of each personalized QSL, but the resolution of the smaller print and small logos on the cards printed by DXK is so poor that I can't use them.

Is there a parameter in the setup that I may be overlooking that may have been changed to cause this problem?

73,
Rich - K1HTV


Re: Windows 10 Automatic Update Created Issue with Serial Ports

Dave AA6YQ
 

+ AA6YQ comments below

On Wed, Mar 25, 2020 at X1:41 AM, Peter Laws wrote:

On Wed, Mar 25, 2020 at 1:38 PM Peter Laws via Groups.Io
<plaws0@...> wrote:


Dave has (somewhere) instructions on disabling automagic updates.
I'll dig for those and see if I can beat AA6YQ to it. :-) It is a
little dependent on which level of W10 you have, IIRC.
https://www.dxlabsuite.com/dxlabwiki/PreventUSBPortPowerDown

Other stuff at https://www.dxlabsuite.com/dxlabwiki/WindowsTricks
including how to better control updates.

+ At this point, the best a Windows 10 user can do is

1. document your serial port assignments

2. configure Windows 10 to only apply updates when you direct it to do so

3. after Windows 10 completes an update, immediately check the serial port assignments, and correct any that have changed.

+ Perhaps someone with Windows device driver programming experience will create a tool that can take a named snapshot of serial port assignments, and restore serial port assignments to those specified in a named snapshot. 

          73,

                Dave, AA6YQ

 

 


Re: Windows 10 Automatic Update Created Issue with Serial Ports

Danny Douglas <n7dc@...>
 

USB -> RS-232 is stable in my experience if you follow (again!) Dave's
advice about configuring the ports, the important thing being don't
let them take a nap.


That is a real problem here. I turn off all computers when I get up and walk away for the night, or even in the daytime, when weather has any indications of rain. I have lost three computers. a rig, an antenna tuner, and numerous other electronics in the past 20 or so years here. Its down right aggravating that MS continues to ignore there software doing such things as changing ports and other such actions - even when we have told their software NO.

N7DC@...
Ex WN5QMX,WA5UKR,ET2US,ET3USA,SV0WPP,VS6DD,N7DC/YV5/G5CTB
QSL Bureau, DIRECT, LOTW Preferred, eQSL used but upload at a courtesy only, as do not use the system for awards.

On March 25, 2020 at 2:38 PM Peter Laws <plaws0@...> wrote:
Danny
N7DC


Re: Windows 10 Automatic Update Created Issue with Serial Ports

Peter Laws / N5UWY
 

On Wed, Mar 25, 2020 at 1:38 PM Peter Laws via Groups.Io
<plaws0=gmail.com@groups.io> wrote:


Dave has (somewhere) instructions on disabling automagic updates.
I'll dig for those and see if I can beat AA6YQ to it. :-) It is a
little dependent on which level of W10 you have, IIRC.
https://www.dxlabsuite.com/dxlabwiki/PreventUSBPortPowerDown

Other stuff at https://www.dxlabsuite.com/dxlabwiki/WindowsTricks
including how to better control updates.


--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!


Re: Windows 10 Automatic Update Created Issue with Serial Ports

Peter Laws / N5UWY
 

On Wed, Mar 25, 2020 at 1:22 PM fjk5146 <fredjkeller@...> wrote:

I don't know if any of you have experienced the issue that I ran into yesterday. The Windows 10 desktop used for my ham shack was automatically updated to Version 1909 on March 4th. I tried to operate my station for the first time since the update yesterday. I quickly discovered that Commander was not communicating with my radio. I also found the DXView could not communicate with my Green Heron RT-11 Rotator.
Dave has (somewhere) instructions on disabling automagic updates.
I'll dig for those and see if I can beat AA6YQ to it. :-) It is a
little dependent on which level of W10 you have, IIRC. Tools like USB
Device Tree Viewer (https://www.uwe-sieber.de/usbtreeview_e.html) and
screen shots are helpful for reconfiguring regardless.

USB -> RS-232 is stable in my experience if you follow (again!) Dave's
advice about configuring the ports, the important thing being don't
let them take a nap.

My PC (an Intel NUC) has no legacy ports and no slots for
old-fashioned cards, so all my serial ports are connected via USB,
whether it's the 4-port Siig adapter, the Arduino Nanos in my Morttys
or the CI-V adapters I have for some of my Icoms.


--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!


Re: Odd QRG for TT8SN

Phil Cooper
 

Hi Dave,

Thanks for the explanation! I don't recall seeing anything like JK72<>IM76 in the spot notes, but I can't be sure. I will see if I can check this later.
But, the explanation helps me to understand how it happened.

73 de Phil GU0SUP

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: 25 March 2020 17:33
To: DXLab@groups.io
Subject: Re: [DXLab] Odd QRG for TT8SN

+ AA6YQ comments below

As we are currently on day one of a 14 day lockdown here in Guernsey, I am spending some time in the shack, and watching the cluster.

I am seeing spots for TT8SN in SC, and some are showing an azimuth of 153 (which I believe to be correct), and some are showing a heading of 190.

DXView shows the heading to be 153 as well, so I am puzzled as to why some spots are showing 190.

The call being spotted is TT8SN, and it is the same call each time, not a typo of those with the wrong QRG.

If I spot the call, it shows 153, yet when EA5DIC spotted it, it showed 190.

Does this imply that some spotters have their own locator incorrectly set?

+ DXLab's DXCC Database positions TT8SN at 12 6' 29" N, 15 6' 0" E, which is the location of Chad's capital and largest city of N'Djamena. That location corresponds to grid square JK72nc, and yields a short-path heading of 83 degrees from my QTH near Boston.

+ When I direct SpotCollector to list all entries for TT8SN, all but two show an azimuth of 83; the two exceptions show 74.

+ In the first case, an entry for FT8 on 12m, EA7FDR has posted these spot notes:

FT8 F/H JK72MC<>IM76HG

+ SpotCollector interprets the first grid square to be that the spotter, and the second to be that of the DX station. IM76HG is what's producing the erroneous heading of 74.

+ The second erroneous TT8SN entry is for FT8 on 10m. Again, the root cause is a "backwards" grid square report from EA7FDR.

+ Since there is no standard for conveying grid squares in spot notes, extracting location information from spot notes will sometimes yield an incorrect location. You can prevent this by disabling the "Capture location info from notes" option in the General panel on the Configuration window's General tab; SpotCollector will then ignore any grid squares or IOTA tags it finds in spot notes.

73,

Dave, AA6YQ


Windows 10 Automatic Update Created Issue with Serial Ports

fjk5146
 

I don't know if any of you have experienced the issue that I ran into yesterday.  The Windows 10 desktop used for my ham shack was automatically updated to Version 1909 on March 4th.  I tried to operate my station  for the first time since the update yesterday.  I quickly discovered that Commander was not communicating with my radio.  I also found the DXView could not communicate with my Green Heron RT-11 Rotator. 

When I assembled this computer for the shack I had installed two PCI Serial Cards which gave me 8 real serial ports.  I wanted real RS-232 ports because I had experienced some issues with some USB to RS-232 adapters disconnecting during contests (sometimes requiring a reboot).  The serial ports have worked fine for the past two years until this most recent Windows 10 update.  After a bit of sleuthing I figured out that the update had re-mapped all the physical RS-232 ports to different numbers.  Also, they were not re-numbered in any logical sequence.  I was able to use a piece of software that I use with my scanner to re-identify each of the ports.  This software searches each of the ports to determine which port the scanner is connected to.  I was able to move it to each of the connectors until I had identified the COMM number for each connector.    

I don't know if anyone else has experienced this issue.  if so, is there any way to keep Windows updates from changing COMM port numbers already to assigned to physical ports?   I know this can be done with USB to RS232 converters, but it doesn't seem to work for actual serial ports.  

After a couple of hours of frustration I managed to get all the ham gear communicating with the computer again.  

73,
Fred, KC9QQ
--
Fred, KC9QQ


Re: Odd QRG for TT8SN

Dave AA6YQ
 

+ AA6YQ comments below

As we are currently on day one of a 14 day lockdown here in Guernsey, I am spending some time in the shack, and watching the cluster.

I am seeing spots for TT8SN in SC, and some are showing an azimuth of 153 (which I believe to be correct), and some are showing a heading of 190.

DXView shows the heading to be 153 as well, so I am puzzled as to why some spots are showing 190.

The call being spotted is TT8SN, and it is the same call each time, not a typo of those with the wrong QRG.

If I spot the call, it shows 153, yet when EA5DIC spotted it, it showed 190.

Does this imply that some spotters have their own locator incorrectly set?

+ DXLab's DXCC Database positions TT8SN at 12 6' 29" N, 15 6' 0" E, which is the location of Chad's capital and largest city of N'Djamena. That location corresponds to grid square JK72nc, and yields a short-path heading of 83 degrees from my QTH near Boston.

+ When I direct SpotCollector to list all entries for TT8SN, all but two show an azimuth of 83; the two exceptions show 74.

+ In the first case, an entry for FT8 on 12m, EA7FDR has posted these spot notes:

FT8 F/H JK72MC<>IM76HG

+ SpotCollector interprets the first grid square to be that the spotter, and the second to be that of the DX station. IM76HG is what's producing the erroneous heading of 74.

+ The second erroneous TT8SN entry is for FT8 on 10m. Again, the root cause is a "backwards" grid square report from EA7FDR.

+ Since there is no standard for conveying grid squares in spot notes, extracting location information from spot notes will sometimes yield an incorrect location. You can prevent this by disabling the "Capture location info from notes" option in the General panel on the Configuration window's General tab; SpotCollector will then ignore any grid squares or IOTA tags it finds in spot notes.

73,

Dave, AA6YQ