Date   

Re: IRC spot source: "Nickname is already in use."

Joe Subich, W4TV
 

John,

To further locate the issue ....

In W1JA@..., the 73-126-63-193 will
be the public IP (73.126.63.193) assigned to the connection by your
ISP (typical addressing for most of the big cable providers).

73,

... Joe, W4TV

On 2020-12-11 12:54 PM, John W1JA wrote:
Iain,
You asked "Do you have multiple instances of SpotCollector attempting to use WorldIRC at the same time?"
I do not. However, you have given me a hint, that I may be able to fix my problem by changing mu username to W1JA-1. I will try this when I get home.
But wait, then you may have revealed the real cause of the problem. You said
"Currently WorldIRC shows this connection using W1JA: * [W1JA] (W1JA@... <mailto:W1JA@...>): John..."
When I read the "ct.comcast.net" part, it made me think of the state of Connecticut (ct). I now recall that a few weeks ago I helped a friend in Connecticut set up his new PC with DXLab. To speed things up, I copied my SC Workspace file over to his PC, and used it. If so, he is logged in as me. (He leaves his PC on 24/7, which may explain why CQDX has never worked for me.)
I will learn more later, when I get home. I will report back. Thanks for what is almost certain to be the solution.
73, John W1JA


Re: IRC spot source: "Nickname is already in use."

John W1JA
 
Edited

Iain,

You asked "Do you have multiple instances of SpotCollector attempting to use WorldIRC at the same time?"

I do not. However, you have given me a hint, that I may be able to fix my problem by changing my username to W1JA-1. I will try this when I get home.

But wait, then you may have revealed the real cause of the problem. You said
"Currently WorldIRC shows this connection using W1JA: * [W1JA] (W1JA@...): John..."

When I read the "ct.comcast.net" part, it made me think of the state of Connecticut (ct). I now recall that a few weeks ago I helped a friend in Connecticut set up his new PC with DXLab. To speed things up, I copied my SC Workspace file over to his PC, and used it. If so, he is logged in as me. (He leaves his PC on 24/7, which may explain why CQDX has never worked for me.)

I will learn more later, when I get home. I will report back. Thanks for what is almost certain to be the solution.

73, John W1JA

 


Re: IRC spot source: "Nickname is already in use."

Kent N6WT
 

Dave, Iain, and John

I would like to add to this that In the "Connecting to Spot Sources" in "SpotCollector Online Help Contents" under "Connecting DX Summit via the CQDX IRC channel" it says "to capture DX spots and WWV announcements from the excellent DX Summit DXCluster, which is not accessible via the Telnet protocol". The link in that statement for http://oh2aq.kolumbus.com/dxs/ is dead. Is OH2AQ the author of the DX Summit? If so he may no longer support it? Just a thought.

Thanks
73
Kent
N6WT


On Fri, Dec 11, 2020 at 8:11 AM iain macdonnell - N6ML <ar@...> wrote:
On Fri, Dec 11, 2020 at 5:23 AM John W1JA <john@...> wrote:
>
> Dave,
> In my case, I've had this problem for several weeks. I like CQDX (using it adds DX Summit as a spot source) and I miss it now that it's gone. I'm not quite ready to give up yet...
>
> Iain,
> Do you know how I can "register"? I can't use any commands from the N or X command list. The reply is always "Register first." Actually, I don't know how anyone can use CQDX via the DXLab interface, as it doesn't require "registration."

Hi John,

Do you have multiple instances of SpotCollector attempting to use
WorldIRC at the same time? If you do, you will need to use a different
username (nickname) on each - e.g. W1JA-1, W1JA-2, etc. Actually that
should work as a workaround even if you don't.

Currently WorldIRC shows this connection using W1JA:

* [W1JA] (W1JA@...): John

and it is in the #CQDX channel. It is almost certainly an instance of
SpotCollector.

73,

    ~iain / N6ML






Re: IRC spot source: "Nickname is already in use."

iain macdonnell - N6ML
 

On Fri, Dec 11, 2020 at 8:11 AM iain macdonnell - N6ML via groups.io
<ar@...> wrote:

On Fri, Dec 11, 2020 at 5:23 AM John W1JA <john@...> wrote:

Dave,
In my case, I've had this problem for several weeks. I like CQDX (using it adds DX Summit as a spot source) and I miss it now that it's gone. I'm not quite ready to give up yet...

Iain,
Do you know how I can "register"? I can't use any commands from the N or X command list. The reply is always "Register first." Actually, I don't know how anyone can use CQDX via the DXLab interface, as it doesn't require "registration."
Hi John,

Do you have multiple instances of SpotCollector attempting to use
WorldIRC at the same time? If you do, you will need to use a different
username (nickname) on each - e.g. W1JA-1, W1JA-2, etc. Actually that
should work as a workaround even if you don't.

Currently WorldIRC shows this connection using W1JA:

* [W1JA] (W1JA@...): John

and it is in the #CQDX channel. It is almost certainly an instance of
SpotCollector.
P.S. I forgot to address your question about registration. I was able
to create an account at:

http://cservice.worldirc.org/live/

and I could use it to login to 'X', but when I try to interact with
'N' I get "No such nick" - I assume that 'N' is offline, and no one
has noticed yet.

73,

~iain / N6ML


Re: IRC spot source: "Nickname is already in use."

iain macdonnell - N6ML
 

On Fri, Dec 11, 2020 at 5:23 AM John W1JA <john@...> wrote:

Dave,
In my case, I've had this problem for several weeks. I like CQDX (using it adds DX Summit as a spot source) and I miss it now that it's gone. I'm not quite ready to give up yet...

Iain,
Do you know how I can "register"? I can't use any commands from the N or X command list. The reply is always "Register first." Actually, I don't know how anyone can use CQDX via the DXLab interface, as it doesn't require "registration."
Hi John,

Do you have multiple instances of SpotCollector attempting to use
WorldIRC at the same time? If you do, you will need to use a different
username (nickname) on each - e.g. W1JA-1, W1JA-2, etc. Actually that
should work as a workaround even if you don't.

Currently WorldIRC shows this connection using W1JA:

* [W1JA] (W1JA@...): John

and it is in the #CQDX channel. It is almost certainly an instance of
SpotCollector.

73,

~iain / N6ML


Re: IRC spot source: "Nickname is already in use."

John W1JA
 

Dave,
In my case, I've had this problem for several weeks. I like CQDX (using it adds DX Summit as a spot source) and I miss it now that it's gone. I'm not quite ready to give up yet...

Iain,
Do you know how I can "register"? I can't use any commands from the N or X command list. The reply is always "Register first." Actually, I don't know how anyone can use CQDX via the DXLab interface, as it doesn't require "registration."

73, John W1JA


Re: LotW vs. DXKeeper

Gilbert Baron W0MN
 

The correct way Joe but can be a lot of work. 😊

 

Outlook Laptop Gil W0MN

Hierro candente, batir de repente

44.08226N 92.51265W EN34rb

 

-----Original Message-----
From: DXLab@groups.io <DXLab@groups.io> On Behalf Of Joe Subich, W4TV
Sent: Thursday, December 10, 2020 18:16
To: DXLab@groups.io
Subject: Re: [DXLab] LotW vs. DXKeeper

 

 

On 2020-12-10 6:17 PM, neil_zampella wrote:

> I let it overwrite as that's what my QSO partner has set for his

> station location in LoTW which may be better data than what I have

> logged for the station previously, or that QRZ has.

I *DO NOT* allow the LotW data to overwrite my log data.  I have seen far too many instances of W1/W2/W3/W8/W9/W0 callsigns that have been in my log for 20+ years and confirmed suddenly appearing as "new"

confirmations from Florida, NC, SC and W7 calls that have been previously confirmed from MT, ND, SD, ID, WA, OR suddenly showing up as "new" confirmations from AZ & NM.

 

I review the "discrepancy report" once the "Sync QSLs" process has finished and edit the log data as appropriate when the LotW station location needs to be updated (Grid sub-square, secondary administrative subdivision, etc.).  I carefully research the license history (FCC license database) and check prior addresses/dates before I accept a new state/county (in most cases I end up not updating because there is an old license for the state/county I have logged and previously confirmed).

 

73,

 

    ... Joe, W4TV

 

 

On 2020-12-10 6:17 PM, neil_zampella wrote:

> FWIW ... I let it overwrite as that's what my QSO partner has set for

> his station location in LoTW which may be better data than what I have

> logged for the station previously, or that QRZ has.

>

> Neil, KN3ILZ

>

> On 12/10/2020 5:12 PM, David Reed wrote:

>> I note that when I do an update from LotW, I get a lot of mismatched

>> Grids, and other stuff like county; my tendency is to not let the

>> update overwrite with LotW data; as the operation may have been

>> portable, and logged correctly.

>> 

>> I am looking for other opinions in case I am misunderstanding

>> something here...

>> 

>> Thanks & 73 de Dave, W5SV

>> 

>> 

>> 

>> 

>> 

>> 

>

>

>

>

>

 

 

 

 


--

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop


Re: Incorrect format in frequency display

g4wjs
 

On 11/12/2020 10:58, Scott Anderson wrote:
Hi Dave,
This is an Icom IC-775DSP.

I was just getting WinWabbler setup for the first time, so if I recall, most of my change were there. I could not get Commander or WinWabbler to transmit, so I made a change on the radio too.
Changed CI-V Transceive to Off
Changed CI-V 731 (operating frequency data length) from 5 bits to 4 bits - I did this per an old post to to get DXlab to transmit through the cv-i cable

I changed my CI-V 731 back and that seems to have fixed my display problem. Now to get WinWabbler to transmit.

And of course I didn't make a backup, lol! First lesson of computers. I'll make a backup before I change anything else.
Hi Scott,

CI-V IC-731 mode is archaic and was only needed when the old IC-731 was used on the same CI-V bus as a more modern Icom. The IC-31 used a different frequency format in CAT commands with a different resolution. These days almost all CI-V CAT control is done over a one-to-one CI-V connection so the IC-731 mode is never needed.



--
73

Bill

G4WJS.


Re: Incorrect format in frequency display

Scott Anderson
 

Hi Dave,
This is an Icom IC-775DSP.

I was just getting WinWabbler setup for the first time, so if I recall, most of my change were there. I could not get Commander or WinWabbler to transmit, so I made a change on the radio too.
Changed CI-V Transceive to Off
Changed CI-V 731 (operating frequency data length) from 5 bits to 4 bits - I did this per an old post to to get DXlab to transmit through the cv-i cable

I changed my CI-V 731 back and that seems to have fixed my display problem. Now to get WinWabbler to transmit.

And of course I didn't make a backup, lol! First lesson of computers. I'll make a backup before I change anything else.


Re: No sound from Spotcollector

Dave AA6YQ
 

+ AA6YQ comments below

I got back the sound, by just enabling the sound alarm setting! Of course I should have checked this before writing a post here. But I don't understand why the sound was disabled. I have not touched it, some something changed this automatically. I do think this is not the first time this happen.

+ SpotCollector does not have the ability to autonomously enable or disable the Enable option in the upper-left corner of the Configuration window's "Audio Alarm" tab. Note that for convenience, you can also change this setting by checking or unchecking the Audio box in the Filter panel at the bottom of SpotCollector's Main window.

+ If you didn't alter this setting, then either it was altered when you loaded the Windows Registry from a Workspace, or the contents of the Windows Registry was altered -- in which case either Windows or your computer are broken.

Maybe the setting is changed when SC is updated?

+ Updates to DXLab applications deposit a new executable file to the folder of the application being updated, and maybe an auxiliary file or two (like some additional sound files; they do not modify the settings of the application being updated.

+ The most recent update to SpotCollector (8.7.5) was released back on September 8. If installing this update modified your Audio Enable setting, wouldn't you have noticed long before now?

Beside this, I often have problem with Windows sound setting. Suddenly these are changed. Main sound and WSJX/DXlab sounds are changed. I now have a written note besides my PC, which make resetting fast. But it's annoying. I suppose this is a problem with the OS, and not DxLab.

+ Correct. You should report this behavior to Microsoft Support.

73,

Dave, AA6YQ


Re: No sound from Spotcollector

Markku SM5FLM
 

I got back the sound, by just enabling the sound alarm setting! Of course I should have checked this before writing a post here. But I don't understand why the sound was disabled. I have not touched it, some something changed this automatically. I do think this is not the first time this happen. Maybe the setting is changed when SC is updated?

Beside this, I often have problem with Windows sound setting. Suddenly these are changed. Main sound and WSJX/DXlab sounds are changed. I now have a written note besides my PC, which make resetting fast. But it's annoying. I suppose this is a problem with the OS, and not DxLab.


Re: No sound from Spotcollector

Dave AA6YQ
 

+ AA6YQ comments below

Alarmsound from SC has disappeared.
I have Windows 10 with latest update Version 20H2 installed 1 November.
I have an Icom IC-7300 with builtin sound driver USB.

Sounds from System, Firefox (Youtube) and to/from WSJT-X are ok.

In the OS System/Sound setup, details per application, the Spotcollector application is not shown (which it should).
Restart of PC or SC doesn't help.

+ Unless someone here knows why your system is ignoring SpotCollector's audio output, I suggest contacting Microsoft Support. Tell them that you're running the same SpotCollector application today as you were when SpotCollector was last able to play sounds.

+ Note that you can use the Test button in the "Announce callsign phonetically" panel to confirm correct operation, rather than wait for a needed callsign to be spotted.

73,

Dave, AA6YQ


Re: Incorrect format in frequency display

Dave AA6YQ
 

+ AA6YQ comments below

I'm not sure what I did, but now Commander, DXKeeper, and WinWabbler all show a funky format for the frequency.

So now:
3.925.00
Becomes:
392,500.00

It was working fine, then I was playing with some settings and can't figure out what I did to change this since this was an unintended change.

1. What make and model transceiver are you using?

2. With what settings were you playing?

3. Did you save a Workspace containing your settings before you began playing with your settings?

73,

Dave, AA6YQ


Re: IRC spot source: "Nickname is already in use."

iain macdonnell - N6ML
 

On Thu, Dec 10, 2020 at 9:59 AM John W1JA <john@...> wrote:

I changed First Name from W1JA to John; same error. (And I recently changed it from John to W1JA to try to solve this problem on my own. I had found an old thread in it was suggested that a user set Username and First Name to his callsign. So, the problem starsted when my First Name was John, as it had been for these several years I used SC IRC without issue.)

So I surfed to us.worldirc.org. At this URL http://www.worldirc.org/?page=services&service=N I found some commands that seemed like they could be useful.

First, in the command list, each command is preceded by "/". To use the commands in the SC CQDX window, one must omit the "/". Then, I had this interesting exchange:
<W1JA> msg N RECOVER
:Register first.
<W1JA> msg N REGISTER
:Register first.
<W1JA> msg N WHOAMI
:Register first.
<W1JA> msg N RELEASE
:Register first.

A puzzle. Apparently I must register to be able to use any command, including the command to register. Also it knows I am <W1JA>.

I've never used IRC for anything except as an SC spot source. Googling "i have to register first before using the IRC register command" gives results as puzzling as the exchange I list above.
I don't know anything about the WorldIRC service, but from a quick
look around, it gives me the impression of something that's dying a
slow death. Their services seem to be somewhat broken - at least they
don't work as documented. There are three people in the #help channel.
Only one of them appears to be an operator (maybe), and he's not
responded to me after an hour and a half.

Fortunately you don't actually need those services to use it as a spot
source. The nick-protection could be useful if someone else was
trying to use W1JA as their nickname, but I highly doubt that that's
what's happened to you.

73,

~iain / N6ML


Incorrect format in frequency display

Scott Anderson
 

Hi All,

I'm not sure what I did, but now Commander, DXKeeper, and WinWabbler all show a funky format for the frequency.

So now:
3.925.00
Becomes:
392,500.00

It was working fine, then I was playing with some settings and can't figure out what I did to change this since this was an unintended change.

Any ideas?
Thanks,
Scott
N0XJO


Re: How to fix bad MYQTHID and re-upload to LOTW?

Dave AA6YQ
 

+ AA6YQ comments below

I have two locations defined in TQSL: My home QTH and one in another state where I sometimes operate portable for Field Day. Historically in my DXKeeper log these locations correspond respectively to MYQTHID values 1 and 2. I reviewed many of my log entries and the settings in DXKeeper's "my QTH" tab and the LotW tab of the QSL Configuration panel and discovered a few things that may explain what happened.

1. After Field Day 2020 I returned home, manually changed the default MYQTHID in the Log tab of DXKeeper Configuration from 1 to 2 [probably not the best way to do this], entered the Field Day QSOs into DXDeeper, and forgot to change the default back to 1. This explains why since Field Day, and until very recently, all manually entered QSOs had a MYQTHID value of 2 instead of 1. (However, the vast majority of recent QSOs had the correct MYQTHID value of 1, but only because these were imported from N1MM-generated ADIF files, and during the import DXKeeper supplied the missing MYQTHID as "1", which I specified in the "Substitution options" on the "Import QSOs" tab.)

2. In DXKeeper's "my QTHs" tab the MYQTHID value specified in the "ID" field is associated with the TQSL station locations using the drop-down list in the "LotW" field. Is it possible that at some point after prior years' Field Days and before this year, the associated LotW location for ID "2" was changed to be the same location that is associated with ID "1"?

+ No. The LoTW selector on the myQTH tab specifies an LoTW "Station Location" by name. This will only change if you change it.

This could explain why online in LotW all of this year's QSOs show my station location as my home QTH, regardless of what their myQTHID was set to in DXKeeper. It also would explain why my attempt to upload QSOs with updated locations failed yesterday, since they already had the correct LotW location due to the incorrect association described above.

3. In the QSL Configuration panel's "TQSL 2.5.7" section, the "station location" field is set to my home station's location. Does this explain why all QSOs, regardless of their MYQTHID, are uploaded to LotW using my home location?

+Yes, except that DXKeeper will not submit a QSO whose "myQTH" specifies a LoTW Station Location that doesn't match the "Station Location" specified in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab.

Should this be left blank so that it will prompt me to specify which location to use for each upload?

+ No.

+ All QSOs in a batch being submitted to LoTW must have been made using the same "Station Callsign" and must specify the same "Station Location". If you have been making QSOs with multiple Station Callsigns and/or from multiple Station Locations, you must filter the Log Page Display to contain only QSOs with the same "Station Callsign" and "Station Location" before invoking the "Add Requested" function to populate the QSL Queue. Set the "Station Location" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab to that "Station Location". If you don't filter correctly and the "Upload to LoTW" function encounters a QSOs whose "my QTH" specifies a "Station Location" doesn't match the Station Location" specified in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab, the QSO won't be submitted to LoTW.

+ All of the above is explained in

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


Now that the myQTHID-to-LotW Location association has been corrected, instead of correcting the locations that I tried to upload yesterday, I need to correct the locations of my 2020 Field Day QSOs and upload those to LotW. I tried to do this following the same procedure you gave me, and this time the result was different. It recognized that I was changing QTH details, but it still failed:

TQSL Version 2.5.7 [v2.5.7]
Signing using Callsign N5EP, DXCC Entity UNITED STATES OF AMERICA

Already Uploaded QSO suppressed on line 5
CALL: AA3S
TIME_ON: 003300
QSO_DATE: 20200628
MODE: CW
BAND: 20M
FREQ: 14.058
BAND_RX: 20M
FREQ_RX: 14.058

Your QTH Details changed for this QSO.

Originally these were: CQZ: 4, GRIDSQUARE: EN51ws, ITUZ: 8, US_COUNTY: Du Page, US_STATE: IL Now they are:CQZ: 4, GRIDSQUARE: EN56fa, ITUZ: 8, US_COUNTY: Vilas, US_STATE: WI

Please verify that you intended to change this QSO!

Signing aborted
All QSOs are already uploaded; aborted
No records to upload
Final Status: No QSOs written(8)

Is there a DXKeeper setting that allows one to provide the verification of intention to change that TQSL is requesting? Or do I have to export these to an ADIF and upload them using TQSL?

+ As you can see in the LoTW documentation

< https://lotw.arrl.org/lotw-help/cmdline/>

+ TQSL provides a command line option that governs the handling of duplicate, out-of-date-range, or invalid QSOs, but does not provide a command line option to confirm intended changes. Thus DXKeeper cannot provide the setting you seek.

73,

Dave, AA6YQ


Re: LotW vs. DXKeeper

Joe Subich, W4TV
 

On 2020-12-10 6:17 PM, neil_zampella wrote:
I let it overwrite as that's what my QSO partner has set for his
station location in LoTW which may be better data than what I have logged for the station previously, or that QRZ has.
I *DO NOT* allow the LotW data to overwrite my log data. I have seen
far too many instances of W1/W2/W3/W8/W9/W0 callsigns that have been
in my log for 20+ years and confirmed suddenly appearing as "new"
confirmations from Florida, NC, SC and W7 calls that have been
previously confirmed from MT, ND, SD, ID, WA, OR suddenly showing up
as "new" confirmations from AZ & NM.

I review the "discrepancy report" once the "Sync QSLs" process has
finished and edit the log data as appropriate when the LotW station
location needs to be updated (Grid sub-square, secondary administrative
subdivision, etc.). I carefully research the license history (FCC
license database) and check prior addresses/dates before I accept a
new state/county (in most cases I end up not updating because there
is an old license for the state/county I have logged and previously
confirmed).

73,

... Joe, W4TV


On 2020-12-10 6:17 PM, neil_zampella wrote:
FWIW ... I let it overwrite as that's what my QSO partner has set for
his station location in LoTW which may be better data than what I have
logged for the station previously, or that QRZ has.
Neil, KN3ILZ
On 12/10/2020 5:12 PM, David Reed wrote:
I note that when I do an update from LotW, I get a lot of mismatched
Grids, and other stuff like county; my tendency is to not let the
update overwrite with LotW data; as the operation may have been
portable, and logged correctly.

I am looking for other opinions in case I am misunderstanding
something here...

Thanks & 73 de Dave, W5SV






Re: LotW vs. DXKeeper

Gilbert Baron W0MN
 

OR NOT !!!

 

Outlook Laptop Gil W0MN

Hierro candente, batir de repente

44.08226N 92.51265W EN34rb

 

From: DXLab@groups.io <DXLab@groups.io> On Behalf Of David Bunte
Sent: Thursday, December 10, 2020 17:20
To: DXLab@groups.io
Subject: Re: [DXLab] LotW vs. DXKeeper

 

Dave -

 

I also permit LoTW to override my log, for the reasons cited by Neil in his response.

 

Dave - K9FN

 

On Thu, Dec 10, 2020 at 6:17 PM neil_zampella <neilz@...> wrote:

FWIW ... I let it overwrite as that's what my QSO partner has set for
his station location in LoTW which may be better data than what I have
logged for the station previously, or that QRZ has.

Neil, KN3ILZ

On 12/10/2020 5:12 PM, David Reed wrote:
> I note that when I do an update from LotW, I get a lot of mismatched
> Grids, and other stuff like county; my tendency is to not let the
> update overwrite with LotW data; as the operation may have been
> portable, and logged correctly.
>
> I am looking for other opinions in case I am misunderstanding
> something here...
>
> Thanks & 73 de Dave, W5SV
>
>
>
>
>
>





--

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop


Re: LotW vs. DXKeeper

Dave AA6YQ
 

+ AA6YQ comments below

On Thu, Dec 10, 2020 at 03:20 PM, David Bunte wrote:

I also permit LoTW to override my log, for the reasons cited by Neil in his response.

+ Historically, there have been complaints about the accuracy of information submitted by QSO partners, incorrect grid squares, and swapped CQ and ITU zones being the most frequent culprits. That's why DXKeeper lets each user decide how to handle descripancies.

+ I have DXKeeper configured to let me resolve each discrepancy.

          73,

                Dave. AA6YQ

 


Re: LotW vs. DXKeeper

David Bunte
 

Dave -

I also permit LoTW to override my log, for the reasons cited by Neil in his response.

Dave - K9FN

On Thu, Dec 10, 2020 at 6:17 PM neil_zampella <neilz@...> wrote:
FWIW ... I let it overwrite as that's what my QSO partner has set for
his station location in LoTW which may be better data than what I have
logged for the station previously, or that QRZ has.

Neil, KN3ILZ

On 12/10/2020 5:12 PM, David Reed wrote:
> I note that when I do an update from LotW, I get a lot of mismatched
> Grids, and other stuff like county; my tendency is to not let the
> update overwrite with LotW data; as the operation may have been
> portable, and logged correctly.
>
> I am looking for other opinions in case I am misunderstanding
> something here...
>
> Thanks & 73 de Dave, W5SV
>
>
>
>
>
>





10661 - 10680 of 208692