Date   
Re: VP6D Bearing and Distance

Danny Douglas
 

I have no idea. Ive done it by hand a couple of times, but didnt have more than a very few contacts with the particular station, and I dont use or know dxwatch.

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 October 26, 2018 at 6:44 AM Mark Robinson <markrob@...> wrote:


If I add an override in DXWatch with the correct grid information will
that fix all my prior QSO's with VP6D or will I need to fix the old
qso's by hand?


73 Mark N1UK

On 25-Oct-18 8:44 PM, Danny Douglas wrote:
You are going to find a lot of these errors, especially on DXpeditions, because when those guys get a callsign for the exped, they do it thru the home address, and that is what shows up on QRZ. I see it every month or so, and you need to keep your Overrides up to date showing expeditions locations, and calls. When I miss seeing one of these upcoming expeds, I sometimes just draw a blank when trying to figure out where a station is located on SpotCollector. If we wanna be a DXPedition hunter, we gotta prepare. Dont know how that works in WSJT, because I log with DXKeeper, and that takes care of that problem. The zones,grids, etc pop up correctly when you do the overrides.

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 October 25, 2018 at 8:11 PM Dave AA6YQ <@AA6YQ> wrote:


+ AA6YQ comments below

Basically all my first QSO's from 20 Oct 11:39 GMT to 22 Oct 9:39 have Grid 1 blank. These are cw and ssb

22 Oct 9:50 to 24 Oct 02:30 GMT show Grid 1 as DM42mk. These are FT8, ssb , cw and rtty

+ If the first of these QSOs was logged via JT-Alert, and if you have JT-Alert configured to use QRZ as a callbook, then DXKeeper's "Ignore geocoded grid squares" setting would have been irrelevant, and the QSO would have been logged with a grid of DM42MK in Arizona. Subsequent QSOs logged via DXKeeper would harvest the DM42MK grid square from the logged FT8 QSO.

After and including 24 Oct 03:04 GMT all QSO's show Grid 1 as CG75.
These are FT8, ssb, cw

I did e-mail QRZ about this on the 24 October

+ QRZ.com still shows a US State of Arizona, but the beam heading shows that the location has been changed to CG75.

+ The bottom line is that if you rely on a callbook for location information but that callbook contains erroneous location information, your logged QSOs will contain erroneous location information. DXKeeper assumes that when you log a QSO, the logged information is accurate; it thus uses this information to populate subsequent QSOs with the same station.

73,

Dave, AA6YQ






Re: VP6D Bearing and Distance

Mark Robinson
 

If I add an override in DXWatch with the correct grid information will that fix all my prior QSO's with VP6D or will I need to fix the old qso's by hand?


73 Mark N1UK

On 25-Oct-18 8:44 PM, Danny Douglas wrote:
You are going to find a lot of these errors, especially on DXpeditions, because when those guys get a callsign for the exped, they do it thru the home address, and that is what shows up on QRZ. I see it every month or so, and you need to keep your Overrides up to date showing expeditions locations, and calls. When I miss seeing one of these upcoming expeds, I sometimes just draw a blank when trying to figure out where a station is located on SpotCollector. If we wanna be a DXPedition hunter, we gotta prepare. Dont know how that works in WSJT, because I log with DXKeeper, and that takes care of that problem. The zones,grids, etc pop up correctly when you do the overrides.

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 October 25, 2018 at 8:11 PM Dave AA6YQ <@AA6YQ> wrote:


+ AA6YQ comments below

Basically all my first QSO's from 20 Oct 11:39 GMT to 22 Oct 9:39 have Grid 1 blank. These are cw and ssb

22 Oct 9:50 to 24 Oct 02:30 GMT show Grid 1 as DM42mk. These are FT8, ssb , cw and rtty

+ If the first of these QSOs was logged via JT-Alert, and if you have JT-Alert configured to use QRZ as a callbook, then DXKeeper's "Ignore geocoded grid squares" setting would have been irrelevant, and the QSO would have been logged with a grid of DM42MK in Arizona. Subsequent QSOs logged via DXKeeper would harvest the DM42MK grid square from the logged FT8 QSO.

After and including 24 Oct 03:04 GMT all QSO's show Grid 1 as CG75.
These are FT8, ssb, cw

I did e-mail QRZ about this on the 24 October

+ QRZ.com still shows a US State of Arizona, but the beam heading shows that the location has been changed to CG75.

+ The bottom line is that if you rely on a callbook for location information but that callbook contains erroneous location information, your logged QSOs will contain erroneous location information. DXKeeper assumes that when you log a QSO, the logged information is accurate; it thus uses this information to populate subsequent QSOs with the same station.

73,

Dave, AA6YQ



Re: Error (?) in spotting from DXK 14.6.2

Wolf, DK1FW
 

Thanks for the corrected DXK version, Dave.
Lightning-speed as usual.

The right-click contextual menu now correctly shows the my RX freuency with the split added in brackets.

What puzzles me is the menu-choice to QSY to my TX frequency.
When I am spotting from my log in DXK my QSO has already taken place, so why should I want to do that QSY.

73 de Wolf, DK1FW


Am 25.10.2018 um 23:17 schrieb Dave AA6YQ:

+ AA6YQ comments below

just realized that right-clicking a qso in DXK opens a menue choice to spot the station with or w/o notes.
However, if it is split-frequency qso the spot frequency is my TX frequency.
I would expect that it should be my RX frequeny.

Or have I missed a setting?

+ It should if you have the "Spot Split Frequency" option enabled, but there's a defect. This defect is available in DXKeeper 14.6.9, which has not yet been publicly released.

To obtain DXKeeper 14.6.9,

1. Download the zip archive from

<http://www.dxlabsuite.com/dxkeeper/DXKeeper1469.zip>

2. Extract the file DXKeeper1469.exe from this archive into your DXKeeper folder

3. update your anti-malware applications to consider DXKeeper1469.exe safe

4. use Windows Explorer to navigate to your DXKeeper folder, and run DXKeeper1469.exe


+ If you want the Launcher to start DXKeeper 14.6.9, then in your DXKeeper folder

a. delete the file named DXKeeper.exe

b. make a copy of the file DXKeeper1469.exe and then rename this copy DXKeeper.exe


Please let me know how it goes; thanks!

73,

Dave, AA6YQ





Re: Change proposal to SpotCollector

Salvatore Besso
 

Dave,

I know that there is a QSY function, I'm using it all the way. I'd like to simply QSY and stop. It shouldn't be too hard to add.

73 de
Salvatore (I4FYV)

Re: Change proposal to SpotCollector

Dave AA6YQ
 

+ AA6YQ comments below

I'd also find very useful, when right clicking on a spot to QSY the radio to:

1. NOT looking in DXKeeper

2. NOT populating WinWarbler

3. NOT activate split

In other words, a method to simply QSY the radio and nothing else, just to hear at the DX without preparing for QSO. Possible
solutions:

a. add a key (Ctrl, Shift or so) to the right click

b. add another item to the contextual menu

+ There's already a QSY function in the Spot Database Entry's right-click menu, but updates DXView and WinWarbler. I don't see the
need for another variant of this function.

73,

Dave, AA6YQ

Re: VP6D Bearing and Distance

HamApps Support (VK3AMA)
 

On 26/10/2018 2:17 PM, HamApps Support (VK3AMA) wrote:
On 26/10/2018 1:52 PM, Mark Robinson wrote:
My first QSO was 40m cw and that grid square is blank.  All the QSo's after that had a blank grid square until my first FT8 QSO when the DM42mk grid square was first populated.. So it looks like JTAlert populated DM42mk.

After several days a 30m FT8 QSO populated CG75.


73 Mark N1UK
That is to be expected, if your log contained VP6D QSOs without a Grid, and no grid was received from WSJT-X, JTAlert would have used the only source for the grid, the XML lookup.

There was no need to wait several days for an FT8 QSO with the correct grid, all you needed to do was correct the most recent (preferably all) QSO in your log with the correct Grid and JTAlert would have picked it up and used it even if there was no WSJT-X supplied grid.

de Laurie VK3AMA

Classic GIGO. Garbage In, Garbage Out

From https://www.techopedia.com/definition/3801/garbage-in-garbage-out-gigo

Garbage in, garbage out (GIGO), in the context of information technology, is a slang expression that means regardless of how accurate a program's logic is, the results will be incorrect if the input is invalid.


The root cause of this is the grossly inaccurate Grid recorded in the QRZ.com xml data.I note that the HamQTH data is correct.

At the end of the day, provided VP6D have the correct grid recorded in their LoTW certificate, DXKeeper will offer to correct the grid when it syncs with LoTW when their QSOs have been uploaded.

de Laurie VK3AMA

Re: VP6D Bearing and Distance

HamApps Support (VK3AMA)
 

On 26/10/2018 1:52 PM, Mark Robinson wrote:
My first QSO was 40m cw and that grid square is blank.  All the QSo's after that had a blank grid square until my first FT8 QSO when the DM42mk grid square was first populated.. So it looks like JTAlert populated DM42mk.

After several days a 30m FT8 QSO populated CG75.


73 Mark N1UK
That is to be expected, if your log contained VP6D QSOs without a Grid, and no grid was received from WSJT-X, JTAlert would have used the only source for the grid, the XML lookup.

There was no need to wait several days for an FT8 QSO with the correct grid, all you needed to do was correct the most recent (preferably all) QSO in your log with the correct Grid and JTAlert would have picked it up and used it even if there was no WSJT-X supplied grid.

de Laurie VK3AMA

Re: VP6D Bearing and Distance

Mark Robinson
 

My first QSO was 40m cw and that grid square is blank.  All the QSo's after that had a blank grid square until my first FT8 QSO when the DM42mk grid square was first populated.. So it looks like JTAlert populated DM42mk.

After several days a 30m FT8 QSO populated CG75.


73 Mark N1UK

On 25-Oct-18 10:32 PM, Dave AA6YQ wrote:
* more AA6YQ comments below


+ If the first of these QSOs was logged via JT-Alert, and if you have JT-Alert configured to use QRZ as a callbook, then
DXKeeper's "Ignore geocoded grid squares" setting would have been irrelevant, and the QSO would have been logged with a grid of
DM42MK in Arizona. Subsequent QSOs logged via DXKeeper would harvest the DM42MK grid square from the logged FT8 QSO.

FYI,

JTAlert has its own xml grid override mechanism. If the on-air 4 character grid received from WSJT-X doesn't match the the first 4
characters of an XML returned grid, the xml result is ignored and the on-air grid is logged. If the first 4 characters match then
the XML returned grid is used as it is deemed to be more accurate.

With VP6D using CG75 on-air and QRZ XML returning DM42mk, then JTAlert will log CG75, the DM42 is ignored.

+ Duh. I forgot that FT8 conveys the grid square over-the-air. Thanks, Laurie!

73,

Dave, AA6YQ



Re: VP6D Bearing and Distance

Dave AA6YQ
 

* more AA6YQ comments below


+ If the first of these QSOs was logged via JT-Alert, and if you have JT-Alert configured to use QRZ as a callbook, then
DXKeeper's "Ignore geocoded grid squares" setting would have been irrelevant, and the QSO would have been logged with a grid of
DM42MK in Arizona. Subsequent QSOs logged via DXKeeper would harvest the DM42MK grid square from the logged FT8 QSO.

FYI,

JTAlert has its own xml grid override mechanism. If the on-air 4 character grid received from WSJT-X doesn't match the the first 4
characters of an XML returned grid, the xml result is ignored and the on-air grid is logged. If the first 4 characters match then
the XML returned grid is used as it is deemed to be more accurate.

With VP6D using CG75 on-air and QRZ XML returning DM42mk, then JTAlert will log CG75, the DM42 is ignored.

+ Duh. I forgot that FT8 conveys the grid square over-the-air. Thanks, Laurie!

73,

Dave, AA6YQ

Re: VP6D Bearing and Distance

Mark Robinson
 

Thank you for the information Laurie,

I am using JTAlert and automatic logging to DXKeeper but my first few FT8 contacts with VP6D show the grid as DM42mk.  Is there a setting that I have wrong?

73 Mark N1UK



On 25-Oct-18 10:20 PM, HamApps Support (VK3AMA) wrote:
On 26/10/2018 11:11 AM, Dave AA6YQ wrote:
+ If the first of these QSOs was logged via JT-Alert, and if you have JT-Alert configured to use QRZ as a callbook, then DXKeeper's "Ignore geocoded grid squares" setting would have been irrelevant, and the QSO would have been logged with a grid of DM42MK in Arizona. Subsequent QSOs logged via DXKeeper would harvest the DM42MK grid square from the logged FT8 QSO.
FYI,

JTAlert has its own xml grid override mechanism. If the on-air 4 character grid received from WSJT-X doesn't match the the first 4 characters of an XML returned grid, the xml result is ignored and the on-air grid is logged. If the first 4 characters match then the XML returned grid is used as it is deemed to be more accurate.

With VP6D using CG75 on-air and QRZ XML returning DM42mk, then JTAlert will log CG75, the DM42 is ignored.

However, if a user is manually entering VP6D in WSJT-X without a grid reference then the Logged QSO packet from WSJT-X will not contain a grid and the results from the XML lookup is used, which would be the DM42 grid. The user has to take some responsibility with what is logged if they are manually entering the data in WSJT-X and not using what is being received in the live decodes.

de Laurie VK3AMA


Re: VP6D Bearing and Distance

HamApps Support (VK3AMA)
 

On 26/10/2018 11:11 AM, Dave AA6YQ wrote:
+ If the first of these QSOs was logged via JT-Alert, and if you have JT-Alert configured to use QRZ as a callbook, then DXKeeper's "Ignore geocoded grid squares" setting would have been irrelevant, and the QSO would have been logged with a grid of DM42MK in Arizona. Subsequent QSOs logged via DXKeeper would harvest the DM42MK grid square from the logged FT8 QSO.
FYI,

JTAlert has its own xml grid override mechanism. If the on-air 4 character grid received from WSJT-X doesn't match the the first 4 characters of an XML returned grid, the xml result is ignored and the on-air grid is logged. If the first 4 characters match then the XML returned grid is used as it is deemed to be more accurate.

With VP6D using CG75 on-air and QRZ XML returning DM42mk, then JTAlert will log CG75, the DM42 is ignored.

However, if a user is manually entering VP6D in WSJT-X without a grid reference then the Logged QSO packet from WSJT-X will not contain a grid and the results from the XML lookup is used, which would be the DM42 grid. The user has to take some responsibility with what is logged if they are manually entering the data in WSJT-X and not using what is being received in the live decodes.

de Laurie VK3AMA

Re: VP6D Bearing and Distance

Dave AA6YQ
 

+ AA6YQ comments below

Thanks Danny,

This is all new stuff to me. Do I do the overrides in DXView ?

+ Yes; see

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

+ Soon, the limit of 16 overrides will be eliminated.

73,

Dave, AA6YQ

Re: VP6D Bearing and Distance

Mark Robinson
 

Thanks Danny,

This is all new stuff to me. Do I do the overrides in DXView ?

73 Mark N1UK

On 25-Oct-18 8:44 PM, Danny Douglas wrote:
You are going to find a lot of these errors, especially on DXpeditions, because when those guys get a callsign for the exped, they do it thru the home address, and that is what shows up on QRZ. I see it every month or so, and you need to keep your Overrides up to date showing expeditions locations, and calls. When I miss seeing one of these upcoming expeds, I sometimes just draw a blank when trying to figure out where a station is located on SpotCollector. If we wanna be a DXPedition hunter, we gotta prepare. Dont know how that works in WSJT, because I log with DXKeeper, and that takes care of that problem. The zones,grids, etc pop up correctly when you do the overrides.

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 October 25, 2018 at 8:11 PM Dave AA6YQ <@AA6YQ> wrote:


+ AA6YQ comments below

Basically all my first QSO's from 20 Oct 11:39 GMT to 22 Oct 9:39 have Grid 1 blank. These are cw and ssb

22 Oct 9:50 to 24 Oct 02:30 GMT show Grid 1 as DM42mk. These are FT8, ssb , cw and rtty

+ If the first of these QSOs was logged via JT-Alert, and if you have JT-Alert configured to use QRZ as a callbook, then DXKeeper's "Ignore geocoded grid squares" setting would have been irrelevant, and the QSO would have been logged with a grid of DM42MK in Arizona. Subsequent QSOs logged via DXKeeper would harvest the DM42MK grid square from the logged FT8 QSO.

After and including 24 Oct 03:04 GMT all QSO's show Grid 1 as CG75.
These are FT8, ssb, cw

I did e-mail QRZ about this on the 24 October

+ QRZ.com still shows a US State of Arizona, but the beam heading shows that the location has been changed to CG75.

+ The bottom line is that if you rely on a callbook for location information but that callbook contains erroneous location information, your logged QSOs will contain erroneous location information. DXKeeper assumes that when you log a QSO, the logged information is accurate; it thus uses this information to populate subsequent QSOs with the same station.

73,

Dave, AA6YQ



Re: radio name in myqthID RED

Jamie WW3S
 

yes....

tried sending a screenshot but maybe not allowed thru groups?

-----Original Message-----
From: Dave AA6YQ
Sent: Thursday, October 25, 2018 7:55 PM
To: DXLab@groups.io
Subject: Re: [DXLab] radio name in myqthID RED

+ AA6YQ comments below

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Jamie WW3S
Sent: Thursday, October 25, 2018 7:36 PM
To: DXLab@groups.io
Subject: Re: [DXLab] radio name in myqthID RED

A new qth Id ? I have Meadville in the root, and Meadville:K3 and Meadville:Ic7610 defined as separate with ids , is there more to
it than that?

+ In the table on the lower half of the Main window's "My QTHs" tab, is there a row whose MYQTHID cell contains Meadville:Ic7610
?

73,

Dave, AA6YQ






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

Re: VP6D Bearing and Distance

Danny Douglas
 

You are going to find a lot of these errors, especially on DXpeditions, because when those guys get a callsign for the exped, they do it thru the home address, and that is what shows up on QRZ. I see it every month or so, and you need to keep your Overrides up to date showing expeditions locations, and calls. When I miss seeing one of these upcoming expeds, I sometimes just draw a blank when trying to figure out where a station is located on SpotCollector. If we wanna be a DXPedition hunter, we gotta prepare. Dont know how that works in WSJT, because I log with DXKeeper, and that takes care of that problem. The zones,grids, etc pop up correctly when you do the overrides.

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 October 25, 2018 at 8:11 PM Dave AA6YQ <@AA6YQ> wrote:


+ AA6YQ comments below

Basically all my first QSO's from 20 Oct 11:39 GMT to 22 Oct 9:39 have Grid 1 blank. These are cw and ssb

22 Oct 9:50 to 24 Oct 02:30 GMT show Grid 1 as DM42mk. These are FT8, ssb , cw and rtty

+ If the first of these QSOs was logged via JT-Alert, and if you have JT-Alert configured to use QRZ as a callbook, then DXKeeper's "Ignore geocoded grid squares" setting would have been irrelevant, and the QSO would have been logged with a grid of DM42MK in Arizona. Subsequent QSOs logged via DXKeeper would harvest the DM42MK grid square from the logged FT8 QSO.

After and including 24 Oct 03:04 GMT all QSO's show Grid 1 as CG75.
These are FT8, ssb, cw

I did e-mail QRZ about this on the 24 October

+ QRZ.com still shows a US State of Arizona, but the beam heading shows that the location has been changed to CG75.

+ The bottom line is that if you rely on a callbook for location information but that callbook contains erroneous location information, your logged QSOs will contain erroneous location information. DXKeeper assumes that when you log a QSO, the logged information is accurate; it thus uses this information to populate subsequent QSOs with the same station.

73,

Dave, AA6YQ



Re: CC User app not connecting properly with Spot Collector

Peter Dougherty
 

OK, found the issue. For whatever reason the cluster is expecting me to use W2IRT-1 to log in, which was not the case with the old version of the software. Changing my call/Username to that value in Spot collector and everything's good.

Re: VP6D Bearing and Distance

Dave AA6YQ
 

+ AA6YQ comments below

Basically all my first QSO's from 20 Oct 11:39 GMT to 22 Oct 9:39 have Grid 1 blank. These are cw and ssb

22 Oct 9:50 to 24 Oct 02:30 GMT show Grid 1 as DM42mk. These are FT8, ssb , cw and rtty

+ If the first of these QSOs was logged via JT-Alert, and if you have JT-Alert configured to use QRZ as a callbook, then DXKeeper's "Ignore geocoded grid squares" setting would have been irrelevant, and the QSO would have been logged with a grid of DM42MK in Arizona. Subsequent QSOs logged via DXKeeper would harvest the DM42MK grid square from the logged FT8 QSO.

After and including 24 Oct 03:04 GMT all QSO's show Grid 1 as CG75.
These are FT8, ssb, cw

I did e-mail QRZ about this on the 24 October

+ QRZ.com still shows a US State of Arizona, but the beam heading shows that the location has been changed to CG75.

+ The bottom line is that if you rely on a callbook for location information but that callbook contains erroneous location information, your logged QSOs will contain erroneous location information. DXKeeper assumes that when you log a QSO, the logged information is accurate; it thus uses this information to populate subsequent QSOs with the same station.

73,

Dave, AA6YQ

Re: CC User app not connecting properly with Spot Collector

Dave AA6YQ
 

+ AA6YQ comments below

Beats me. My host address is 127.0.0.1 (since the CC User app is running on the same machine as SC). Port #7300 was selected. My callsign is the Username, Password and CMD are both empty, enable is selected, and SPOT is selected. Lee's cluster is not a DX Spider cluster so the second part of item 1 in the wiki is not applicable. In CC User I have Telnet enabled, set to port 7300, and like I said initially, spots are making it to the cluster's individual window; they're just not being passed to the main database window.

I can connect directly to Lee's telnet cluster (ve7cc.net:23) and that's fine, but I would prefer not to do it that way if possible.

+ You upgraded to a new version of "CC User", after which SpotCollector could no longer connect. Other users of the new version of "CC User" have told you that SpotCollector does connect. It is thus logical to assume that the problem lies in "CC User" -- most likely a misconfiguration. Since I don't have the source code for "CC User", I can't provide any help beyond this analysis.

73,

Dave, AA6YQ

Re: VP6D Bearing and Distance

Mark Robinson
 

Basically all my first QSO's from 20 Oct 11:39 GMT to 22 Oct 9:39 have Grid 1 blank.  These are cw and ssb

22 Oct 9:50 to 24 Oct 02:30 GMT show Grid 1 as DM42mk. These are FT8, ssb , cw and rtty

After and including 24 Oct  03:04 GMT all QSO's show Grid 1 as CG75. These are FT8, ssb, cw

I did e-mail QRZ about this on the 24 October

73 Mark N1UK

On 24-Oct-18 5:52 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

I checked the log and I already had "Ignore geocoded grid squares" checked.

My first VP6D QSO's have no grid square (the field is blank) , the next bunch have DM42mk and my last 30m FT8 qso has CG75 as the gridsquare.

I don't know how that happened. My log was populated using the capture screen or automatically with FT8.

+ Does the logged grid square correlate with the means by which the QSO was captured?

73,

Dave, AA6YQ



Re: radio name in myqthID RED

Dave AA6YQ
 

+ AA6YQ comments below

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Jamie WW3S
Sent: Thursday, October 25, 2018 7:36 PM
To: DXLab@groups.io
Subject: Re: [DXLab] radio name in myqthID RED

A new qth Id ? I have Meadville in the root, and Meadville:K3 and Meadville:Ic7610 defined as separate with ids , is there more to
it than that?

+ In the table on the lower half of the Main window's "My QTHs" tab, is there a row whose MYQTHID cell contains Meadville:Ic7610
?

73,

Dave, AA6YQ