Date   

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

Mike 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@...> 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


Odd QRG for TT8SN

Phil Cooper
 

Hi all,

 

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?

 

Just curious!

 

73 de Phil GU0SUP

 


Re: Uploaded QSOs not in LOTW

Dave AA6YQ
 

+ AA6YQ comments below

There are a lot of Us scattered throughout my log that have dates sent to LOTW but these QSOs are not in LOTW. Most Us are recent but when I go back to the CQWW test last November there are a few QSOs with SENT U along with SENT Y for most QSOs. I also noted that all the ones with a Y last November have an associated LOTW QSL. That may be a coincidence. Of the two I uploaded today, one was a QSL and one was not.

Since Feb 21, 2020 Only one QSO near the end of the 160 contest was in LOTW. All of the others submitted at the same time never made it.
Today I took two QSOs and changed the Sent U to R, the RCVD R to blank and Cleared out the date sent box and checked the box to allow uploading to LOTW again. I then uploaded them again. Then I did the SYNC LOTW QSOs and the sent U magically changed to Y. I then went to the next QSO in the log and was never able to get it to work. It appeared to upload but never appeared in the LOTW database and the U never changed to Y. I have checked many QSOs in my log and always when I find a U in the sent field it is not in the LOTW database, which is as it should be. I just cant figure out why some of my QSOs that were uploaded at the same time as many others did not end up in the LOTW data base.
I have at least several hundred of over 52,000 QSOs I need to fix.

Would direct uploading of my recent contest logs be a possible fix for the past QSOs? If so, I still need to fix the problem for my next batch.

+ DXKeeper can resubmit your "unaccepted" QSOs to LoTW en masse, with a couple of mouse clicks, but before you do that, let's investigate the QSO you manually re-submitted but was not accepted.

+ Above, you say

"I then went to the next QSO in the log and was never able to get it to work."

+ Please place the callsign, date, time, frequency, and mode of this QSO in an email message.

+ Then place your log file in a zip archive, attach the zip archive to the email message you just created, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Uploaded QSOs not in LOTW

N4DJ
 

There are a lot of Us scattered throughout my log that have dates sent to LOTW but these QSOs are not in LOTW. Most Us are recent but when I go back to the CQWW test last November there are a few QSOs with SENT U along with SENT Y for most QSOs. I also noted that all the ones with a Y last November have an associated LOTW QSL. That may be a coincidence. Of the two I uploaded today, one was a QSL and one was not.
Since Feb 21, 2020 Only one QSO near the end of the 160 contest was in LOTW. All of the others submitted at the same time never made it.
Today I took two QSOs and changed the Sent U to R, the RCVD R to blank and Cleared out the date sent box and checked the box to allow uploading to LOTW again.  I then uploaded them again. Then I did the SYNC LOTW QSOs and the sent U magically changed to Y. I then went to the next QSO in the log and was never able to get it to work. It appeared to upload but never appeared in the LOTW database and the U never changed to Y. I have checked many QSOs in my log and always when I find a U in the sent field it is not in the LOTW database, which is as it should be. I just cant figure out why some of my QSOs that were uploaded at the same time as many others did not end up in the LOTW data base.
I have at least several hundred of over 52,000 QSOs I need to fix.

Would direct uploading of my recent contest logs be a possible fix for the past QSOs? If so, I still need to fix the problem for my next batch.

Thanks and 73,
Don
N4DJ


Re: Google Earth - DXView

Dave AA6YQ
 

+ AA6YQ comments below

I have a fresh install of DXLabs on my pc and now I'm try also Google Earth it works before but now goole earth will not oppen after start DXView

I get a message direct when Dxview is start Google earth This is the message LoadFly.KML save or open this file?
I try both but no luck Google Earth is closing every time when I try to start.
Have any one a idea how I can fix this?

+ What happens when you manually start Google Earth?

+ DXView relies on the fact that when Google Earth is correctly installed, Windows is configured to associate .KML files with Google Earth. So when directed to "open" a .KML file, Windows invokes Google Earth and direct it to display the contents of that file. Check your "Windows File Associations" to make sure this configured correctly:

<https://www.lifewire.com/how-to-change-file-associations-in-windows-2624477>

73,

Dave, AA6YQ

19081 - 19100 of 211213