Date   

Re: Problem with Gateway

Bill Pence
 

And your image does not get sent to the list...


On Wed, Sep 9, 2020, 6:29 PM Richard Lawn <rjlawn@...> wrote:
I confess to not being a real contester but in retirement I'm now beginning to devote more time to contesting. I'm also trying to settle in on 1 logger for everything and am liking DXLabs Suite and Keeper. But I want to use N1MM+ for contesting. I've tried to set up the Gateway app so that anything logged in N1MM+ goes into DXKeeper. I think that WSJT-X couple be the culprit but it's not working and I've received the attached error message. I could use some help configuring this as I don't want to use more applications than are necessary. For radios I use either a Flex 6400 or IC-7610.

Rick, W2JAZ

--
Rick, W2JAZ 


Re: Problem with Gateway

Bill Pence
 

Email me direct. I use n1mm wsjt and dxkeeper gateway....


On Wed, Sep 9, 2020, 6:29 PM Richard Lawn <rjlawn@...> wrote:
I confess to not being a real contester but in retirement I'm now beginning to devote more time to contesting. I'm also trying to settle in on 1 logger for everything and am liking DXLabs Suite and Keeper. But I want to use N1MM+ for contesting. I've tried to set up the Gateway app so that anything logged in N1MM+ goes into DXKeeper. I think that WSJT-X couple be the culprit but it's not working and I've received the attached error message. I could use some help configuring this as I don't want to use more applications than are necessary. For radios I use either a Flex 6400 or IC-7610.

Rick, W2JAZ

--
Rick, W2JAZ 


Problem with Gateway

Richard Lawn <rjlawn@...>
 

I confess to not being a real contester but in retirement I'm now beginning to devote more time to contesting. I'm also trying to settle in on 1 logger for everything and am liking DXLabs Suite and Keeper. But I want to use N1MM+ for contesting. I've tried to set up the Gateway app so that anything logged in N1MM+ goes into DXKeeper. I think that WSJT-X couple be the culprit but it's not working and I've received the attached error message. I could use some help configuring this as I don't want to use more applications than are necessary. For radios I use either a Flex 6400 or IC-7610.

Rick, W2JAZ

--
Rick, W2JAZ 


Re: Spot Collector : BandModeWorked problem

iain macdonnell - N6ML
 

On Wed, Sep 9, 2020 at 11:46 AM Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ AA6YQ comments below

Tnx for quick reply.

Well, I understand that it will be too expensive (in term of perormance).

I love DxLabs software. Dave you are making a great job.
But, this function for all call-signs should be great.

I am on the air every day and I try to make as much interesting QSO as I can.
For me, an interesting QSO is not located in EU, and if it is a DX call-sign, it's better.

Very often I see a Dx-call-sign on spotcollector. Then I click on it, and I have wait that DxKeeper tells me I have already worked him on this bandmode.
I have 90000 QSO in log, about 2700 slots, so many DX seen on spotcollector had already been worked. But here are some DX I did not work yet.

I just saw the Dave's answer. (tnx DAve)

+ states that they are not populated in all cases. SpotCollector only refers to a Spot Database Entry's Bandworked field, for example, if the Entry's BandProgress field is set to 'W' (meaning "worked"). For all other values of BandProgress, there is no need to take the time to query your log to determine a value for Bandworked.

There is a big difference for me :
If I have already worked and confirmed ZL4TT on 80m CW, spotcollector will not show ZL4TT as needed.
So I have ZL worked and confirmed. But from EU, a QSO with ZL is always a pleasure because it's very far from EU.

So, if SpotCollector shows ZL2AGY on 80m CW, it should be great to work him if it's an unworked.
There is no value for award, but there is a good value for a good QSO.

This is my point of view. May be I am alone ... or not.

+ There is a DXing objective known as the "Quixote Quest" which is to confirm every DXCC entity on every combination of band and mode. There is a SpotCollector add-in called SpotSpy that supports this objective. See

<http://www.dl9ho.de/SpotSpy/SpotSpy.htm>

+ As for the objective of confirming a QSO with every callsign on every combination of band and mode, I'm sure that you aren't the only ham pursuing this objective, but your numbers are small. I prioritize DXLab development work by considered the magnitude of the effort, the magnitude of the benefit to a user, and the number of users likely to enjoy that benefit.

+ As was writing this response, it occurred to me that the effort to extend SpotCollector to support your "every callsign on every combination of band and mode" object is simply that of providing a "consider all callsigns to have a <leaderboard> tag" option. So while the number of users likely to enjoy the benefit is small, so is the magnitude of the effort. I've added this to SpotCollector's enhancement list.
That may solve Phil's problem, but that's just one case where having
those fields populated for all spot database entries could be useful.

My current personal pursuit (only semi-serious) is pseudo-awards using
only FT8 and only LoTW. I've finished WAS on 6-160m (incl 60m). The
next milestone is DXCC Challenge (1073 worked, 942 confirmed). DXCC on
individual bands next, probably - pretty close to finishing 15 thru
80m. The rest are waiting for prop. SpotCollector is not very helpful
in this pursuit, even with FT8 as my user-specified digital mode
family) since it only identifies cases where the entity has not been
worked on any band as "needed". JTAlert helps quite a bit, but only on
the band I'm monitoring at the time.

Not complaining ... just sharing another perspective....

73,

~iain / N6ML


Re: Port 7300 conflict?

Dave AA6YQ
 

+ AA6YQ comments below

I have been using Spot Collector without incident until today. When I booted up my PC (Win 10) and started the program, I received an error message that I could not log into the N6WS cluster.

+ Please make a screen shot showing the error message, attach the screen shot to an email message, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Re: Spot Collector : BandModeWorked problem

F5PHW Phil BERGER
 

Dave

Tnx for quick answer as usual.

And also for this sentence :

"I've added this to SpotCollector's enhancement list."

If another operator need this function, please, send an email to Dave !!!

Tnx to all

Best 73

F5PHW Phil

Web page on http://f5phw.free.fr
F5PHW on FACEBOOK : https://www.facebook.com/phil.berger.75
WX in Nostang :
http://www.nostang.meteoamikuze.com/index.html
https://www.wunderground.com/personal-weather-station/dashboard?ID=IBRETAGN147

----- Mail original -----
De: "aa6yq" <aa6yq@ambersoft.com>
À: "DXLab" <DXLab@groups.io>
Envoyé: Mercredi 9 Septembre 2020 20:46:46
Objet: Re: [DXLab] Spot Collector : BandModeWorked problem

+ AA6YQ comments below

Tnx for quick reply.

Well, I understand that it will be too expensive (in term of perormance).

I love DxLabs software. Dave you are making a great job.
But, this function for all call-signs should be great.

I am on the air every day and I try to make as much interesting QSO as I can.
For me, an interesting QSO is not located in EU, and if it is a DX call-sign, it's better.

Very often I see a Dx-call-sign on spotcollector. Then I click on it, and I have wait that DxKeeper tells me I have already worked him on this bandmode.
I have 90000 QSO in log, about 2700 slots, so many DX seen on spotcollector had already been worked. But here are some DX I did not work yet.

I just saw the Dave's answer. (tnx DAve)

+ states that they are not populated in all cases. SpotCollector only refers to a Spot Database Entry's Bandworked field, for example, if the Entry's BandProgress field is set to 'W' (meaning "worked"). For all other values of BandProgress, there is no need to take the time to query your log to determine a value for Bandworked.

There is a big difference for me :
If I have already worked and confirmed ZL4TT on 80m CW, spotcollector will not show ZL4TT as needed.
So I have ZL worked and confirmed. But from EU, a QSO with ZL is always a pleasure because it's very far from EU.

So, if SpotCollector shows ZL2AGY on 80m CW, it should be great to work him if it's an unworked.
There is no value for award, but there is a good value for a good QSO.

This is my point of view. May be I am alone ... or not.

+ There is a DXing objective known as the "Quixote Quest" which is to confirm every DXCC entity on every combination of band and mode. There is a SpotCollector add-in called SpotSpy that supports this objective. See

<http://www.dl9ho.de/SpotSpy/SpotSpy.htm>

+ As for the objective of confirming a QSO with every callsign on every combination of band and mode, I'm sure that you aren't the only ham pursuing this objective, but your numbers are small. I prioritize DXLab development work by considered the magnitude of the effort, the magnitude of the benefit to a user, and the number of users likely to enjoy that benefit.

+ As was writing this response, it occurred to me that the effort to extend SpotCollector to support your "every callsign on every combination of band and mode" object is simply that of providing a "consider all callsigns to have a <leaderboard> tag" option. So while the number of users likely to enjoy the benefit is small, so is the magnitude of the effort. I've added this to SpotCollector's enhancement list.

73,

Dave, AA6YQ


Re: DXLab error update and SpotCollector question/feature request.

Dave AA6YQ
 

+ AA6YQ comments below
This is what I do, when I want the WWV data updated in SpotCollector. The telnet cluster is used just so I can issue the SH/WWV command at the start of a session

+ You can configure SpotCollector to issue the SH/WWV command immediately after connecting to the telnet cluster.

, or let it auto update if the session extends long enough.

Granted that I'm not familiar with the 'behind the scenes' activities and perhaps the cost involved, my preference is not to use DX Cluster resources just for WWV data. It does not seem fair and/or an efficient use of the resource.

+ There's no cause for concern. DX Clusters are designed to handle large numbers of connections, and your usage is "in bounds". If you wanted, you could configure DXKeeper with 3 "WWV only" spot sources but only enable one, rotating among them from time to time.

       73,

             Dave, AA6YQ

 


Port 7300 conflict?

Lou Laderman W0FK
 

I have been using Spot Collector without incident until today. When I booted up my PC (Win 10) and started the program, I received an error message that I could not log into the N6WS cluster.



I didn't change anything in the configuration settings, and logged into the other clusters (one of which also specifies port 7300. I am puzzled why I am getting this error message and what to do about it. There are my config settings under spot sources:



I am also running Commander, DXKeeper and DXView. Radio selected is a Flex 6600 (radio was not active when I ran into this issue).

I'd appreciate some guidance.

73, Lou W0FK


Re: Spot Collector : BandModeWorked problem

Dave AA6YQ
 

+ AA6YQ comments below

Tnx for quick reply.

Well, I understand that it will be too expensive (in term of perormance).

I love DxLabs software. Dave you are making a great job.
But, this function for all call-signs should be great.

I am on the air every day and I try to make as much interesting QSO as I can.
For me, an interesting QSO is not located in EU, and if it is a DX call-sign, it's better.

Very often I see a Dx-call-sign on spotcollector. Then I click on it, and I have wait that DxKeeper tells me I have already worked him on this bandmode.
I have 90000 QSO in log, about 2700 slots, so many DX seen on spotcollector had already been worked. But here are some DX I did not work yet.

I just saw the Dave's answer. (tnx DAve)

+ states that they are not populated in all cases. SpotCollector only refers to a Spot Database Entry's Bandworked field, for example, if the Entry's BandProgress field is set to 'W' (meaning "worked"). For all other values of BandProgress, there is no need to take the time to query your log to determine a value for Bandworked.

There is a big difference for me :
If I have already worked and confirmed ZL4TT on 80m CW, spotcollector will not show ZL4TT as needed.
So I have ZL worked and confirmed. But from EU, a QSO with ZL is always a pleasure because it's very far from EU.

So, if SpotCollector shows ZL2AGY on 80m CW, it should be great to work him if it's an unworked.
There is no value for award, but there is a good value for a good QSO.

This is my point of view. May be I am alone ... or not.

+ There is a DXing objective known as the "Quixote Quest" which is to confirm every DXCC entity on every combination of band and mode. There is a SpotCollector add-in called SpotSpy that supports this objective. See

<http://www.dl9ho.de/SpotSpy/SpotSpy.htm>

+ As for the objective of confirming a QSO with every callsign on every combination of band and mode, I'm sure that you aren't the only ham pursuing this objective, but your numbers are small. I prioritize DXLab development work by considered the magnitude of the effort, the magnitude of the benefit to a user, and the number of users likely to enjoy that benefit.

+ As was writing this response, it occurred to me that the effort to extend SpotCollector to support your "every callsign on every combination of band and mode" object is simply that of providing a "consider all callsigns to have a <leaderboard> tag" option. So while the number of users likely to enjoy the benefit is small, so is the magnitude of the effort. I've added this to SpotCollector's enhancement list.

73,

Dave, AA6YQ


Re: Spot Collector : BandModeWorked problem

F5PHW Phil BERGER
 

Iain and Dave

Tnx for quick reply.

Well, I understand that it will be too expensive (in term of perormance).

I love DxLabs software. Dave you are making a great job.
But, this function for all call-signs should be great.

I am on the air every day and I try to make as much interesting QSO as I can.
For me, an interesting QSO is not located in EU, and if it is a DX call-sign, it's better.

Very often I see a Dx-call-sign on spotcollector. Then I click on it, and I have wait that DxKeeper tells me I have already worked him on this bandmode.
I have 90000 QSO in log, about 2700 slots, so many DX seen on spotcollector had already been worked. But here are some DX I did not work yet.

I just saw the Dave's answer. (tnx DAve)

+ states that they are not populated in all cases. SpotCollector only refers to a Spot Database Entry's Bandworked field, for example, if the Entry's BandProgress field is set to 'W' (meaning "worked"). For all other values of BandProgress, there is no need to take the time to query your log to determine a value for Bandworked.

There is a big difference for me :
If I have already worked and confirmed ZL4TT on 80m CW, spotcollector will not show ZL4TT as needed.
So I have ZL worked and confirmed. But from EU, a QSO with ZL is always a pleasure because it's very far from EU.

So, if SpotCollector shows ZL2AGY on 80m CW, it should be great to work him if it's an unworked.
There is no value for award, but there is a good value for a good QSO.

This is my point of view. May be I am alone ... or not.

Many tnx for all great efforts you are making for us.

Best 73

F5PHW Phil

Web page on http://f5phw.free.fr
F5PHW on FACEBOOK : https://www.facebook.com/phil.berger.75
WX in Nostang :
http://www.nostang.meteoamikuze.com/index.html
https://www.wunderground.com/personal-weather-station/dashboard?ID=IBRETAGN147

----- Mail original -----
De: "iain macdonnell - N6ML" <ar@dseven.org>
À: "DXLab" <DXLab@groups.io>
Envoyé: Mercredi 9 Septembre 2020 17:46:47
Objet: Re: [DXLab] Spot Collector : BandModeWorked problem

On Wed, Sep 9, 2020 at 7:38 AM F5PHW Phil BERGER <f5phw@free.fr> wrote:
I have a problem in SpotCollector with the Spot Database Fields : BandModeWorked

I have selected this field and I see the column on the SpotCollector screen.

But this column stays empty. There is no "Y" or "N".
It is the same problem for : BandWorked and ModeWorked.
You cannot rely on those fields always being populated (as noted in
https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm). They
were added to support the "Leaderboard" feature (to signify that a
DXpedition slot has already been worked). The fields are only
populated in cases where the log database is queried to determine if
the callsign has already been worked. That query is only performed if
the callsign is tagged for "Leaderboard" or if the spotted band/mode
is "needed" for some other award objective. It's considered that a log
database lookup for every new spot database entry would be too
"expensive" (in terms of performance),

73,

~iain / N6ML


Re: DXLab error update and SpotCollector question/feature request.

Dave AA6YQ
 

+ AA6YQ comments below
An update: I was having some database errors a couple of months ago. It did not seem to impact any functionality, but the error warnings were kind of irritating.

We exchanged a couple of messages back then, and the conclusion was that something was corrupted in my Win 10 installation. I tried your suggestions, found some others on the web, but nothing worked. I gave up, and let it be.

Fast forward to the last big Windows update from August, I think. All error warnings disappeared after updating Windows.
+ Great! That would tend to confirm our earlier conclusion.
Now for the SpotCollector question/feature request: As far as I can see, looks like SpotColletor derives its WWV data from the telnet DX Clusters and/or the IRC. Is it possible to offer an option where the data can be retrieved directly from the NIST site?

Reason for the request: I don't normally use telnet DX Clusters, except during the 3 or 4 contests I participate in a typical year, not even that lately, due to poor propagation. I use DXHeat for quick checks of activity and WWV numbers.

My off contest operation is mostly FT8 these days, so SpotCollector is configured for the RBN. It looks like the RBN does not relay WWV data, at least when configured for FT8.

I checked the SpotCollector feature request list and did not see this ever being requested. Maybe it's not a simple thing to do.
+ Is there a reason that you don't simply connect to one cluster that conveys WWV spots?

        73,

              Dave, AA6YQ


Re: Spot Collector : BandModeWorked problem

Dave AA6YQ
 

+ AA6YQ comments below
You cannot rely on those fields always being populated (as noted in
https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm). They
were added to support the "Leaderboard" feature (to signify that a
DXpedition slot has already been worked). The fields are only
populated in cases where the log database is queried to determine if
the callsign has already been worked. That query is only performed if
the callsign is tagged for "Leaderboard" or if the spotted band/mode
is "needed" for some other award objective. It's considered that a log
database lookup for every new spot database entry would be too
"expensive" (in terms of performance),

+ The BandWorked and ModeWorked fields determine whether or not a Spot Database Entry for an already worked (but not confirmed) entity-band or entity-mode is shown as "needed". If the Entry's callsign has been previously worked on the entry's entity-band or entity-mode respectively, then another QSO with the callsign won't improve the user's prospects for confirming that entity-band or entity-mode (so the Entry is not "needed"). If the Entry's callsign has not been previously worked on its entity-band or entity-mode respectively, then working the callsign would provide a new way to obtain a confirmation, so the Entry is shown as "needed".

+ The BandModeWorked field is only populated for a Leaderboard station, as the DXCC award family does not track entity-band-modes.

+ Every database query or update costs CPU cycles and time required to access the mass storage device; to minimize its impact on system performance, SpotCollector avoids log database queries wherever possible.

          73,

                Dave, AA6YQ

 


Re: IP Address in Spot Sources / WSJT-X Panel in Spot Collector.

Dave AA6YQ
 

+ AA6YQ comments below
it's not that simple. The technology used to implement DX Lab Suite does not support multicast IP, nor is it possible to patch it up by calling the necessary lower level Windows functionality at the necessary point.
+ If supporting multicast IP were a priority, I would develop a standalone "router" using a technology that supports it (like .net) and have DXLab  applications interact with that router via TCP -- just as SpotCollector now interacts with its SC_WSJTX "helper app" via TCP.

      73,

              Dave, AA6YQ


Re: Spot Collector : BandModeWorked problem

Dave AA6YQ
 

+ AA6YQ comments below
I have a problem in SpotCollector with the Spot Database Fields : BandModeWorked
 
I have selected this field and I see the column on the SpotCollector screen.
 
But this column stays empty. There is no "Y" or "N".
It is the same problem for : BandWorked and ModeWorked.

+ That's correct. The description of these fields in 

<https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm#Spot%20Database%20Field%20Table>

+ states that they are not populated in all cases. SpotCollector only refers to a Spot Database Entry's Bandworked field, for example, if the Entry's BandProgress field is set to 'W' (meaning "worked"). For all other values of BandProgress, there is no need to take the time to query your log to determine a value for Bandworked.

+ An Entry's BandModeWorked field is only populated if the Entry's Callsign has a Leaderboard tag in the Special Callsign List.

      73,

            Dave, AA6YQ

 

 


Re: Spot Collector : BandModeWorked problem

iain macdonnell - N6ML
 

On Wed, Sep 9, 2020 at 7:38 AM F5PHW Phil BERGER <f5phw@free.fr> wrote:
I have a problem in SpotCollector with the Spot Database Fields : BandModeWorked

I have selected this field and I see the column on the SpotCollector screen.

But this column stays empty. There is no "Y" or "N".
It is the same problem for : BandWorked and ModeWorked.
You cannot rely on those fields always being populated (as noted in
https://www.dxlabsuite.com/spotcollector/Help/SpotDatabase.htm). They
were added to support the "Leaderboard" feature (to signify that a
DXpedition slot has already been worked). The fields are only
populated in cases where the log database is queried to determine if
the callsign has already been worked. That query is only performed if
the callsign is tagged for "Leaderboard" or if the spotted band/mode
is "needed" for some other award objective. It's considered that a log
database lookup for every new spot database entry would be too
"expensive" (in terms of performance),

73,

~iain / N6ML


Spot Collector : BandModeWorked problem

F5PHW Phil BERGER
 

Hello everybody

I have a problem in SpotCollector with the Spot Database Fields : BandModeWorked

I have selected this field and I see the column on the SpotCollector screen.

But this column stays empty. There is no "Y" or "N".
It is the same problem for : BandWorked and ModeWorked.

BandProgress, ModeProgress and BandSought are working well.

In config windows, I have in size control
- Prune entries older than this age : 0.08
- Prune Spot Database on startup : yes
Prune Spot Database Hourly : no
Clear Spot Database on startup : no
 

Any idea ? May be I forgot to make an action ?

Tnx in advance.

All my DxLabs suite is updated with latests versions.

Best 73

F5PHW Phil

Web page on http://f5phw.free.fr
F5PHW on FACEBOOK : https://www.facebook.com/phil.berger.75
WX in Nostang :
http://www.nostang.meteoamikuze.com/index.html
https://www.wunderground.com/personal-weather-station/dashboard?ID=IBRETAGN147


Re: IP Address in Spot Sources / WSJT-X Panel in Spot Collector.

g4wjs
 

On 09/09/2020 15:17, Carl - WC4H via groups.io wrote:
Hi Dave.

I know that you removed the IP address from Spot Collectdor's Spot Sources Tab WSJT-X Panel because it was thought not to be needed.

WSJT-X uses multicast which I "listen" to with other programs.  To do this, the IP address for UDP broadcast is set to a 239.x.x.x IP.  That means that Spot Collector does not receive anything WSJT-X.

Is it possible to bring back the IP field there or am I missing some way of setting that up?

Many thanks.
Carl - WC4H
Hi Carl,

it's not that simple. The technology used to implement DX Lab Suite does not support multicast IP, nor is it possible to patch it up by calling the necessary lower level Windows functionality at the necessary point.

Note that WSJT-X does not "listen" for multicast traffic, that is the responsibility of applications wishing to interoperate with WSJT-X instances without blocking other such applications. For now SpotCollector requires exclusive access to the well known IP/port pair WSJT-X sends traffic as that must be a unicast IP address, WSJT-X works FB with that but other applications cannot join in.



--
73

Bill

G4WJS.


IP Address in Spot Sources / WSJT-X Panel in Spot Collector.

Carl - WC4H
 

Hi Dave.

I know that you removed the IP address from Spot Collectdor's  Spot Sources Tab WSJT-X Panel because it was thought not to be needed.

WSJT-X uses multicast which I "listen" to with other programs.  To do this, the IP address for UDP broadcast is set to a 239.x.x.x IP.  That means that Spot Collector does not receive anything WSJT-X.  

Is it possible to bring back the IP field there or am I missing some way of setting that up?

Many thanks.
Carl - WC4H

 


Re: eqsl login /m suffix errorr

Dave AA6YQ
 

+ AA6YQ comments below

Have had two eqsl logins, one for primary call (w9ii) and second for mobile call (w9ii/m)

Primary uploads and downloads correct.
Secondary w9ii/m hangs lately on downloads.
When downloading or uploading to secondary call I would manually change the info for user/password/qth nick for the secondary call.
Secondary call uploads correctly, but downloads for those eqsl result in error.
returned error: You have no eqsl log entries at present.

Was working for me in the past last few years without a problem

Any clues ?

+ There have been no changes to eQSL authentication in DXKeeper for at least a year. A DXKeeper errorlog would likely show no response from eQSL.cc; I suggest that you ask eQSL whether they've made any changes that would account for "Sync eQSL.cc QSLs" not working with your W9II/M callsigns.


P.S. A eqsl dropdown box for location / login info
like the lotw tab has would be a nice feature.

+ That would require eQSL to provide documentation for its "QTH nickname" mechanism (or for someone to point me at it, if it now exists).

73,

Dave, AA6YQ


eqsl login /m suffix errorr

Joel Christiansen
 

Hello,

 Have had two eqsl logins, one for primary call (w9ii)
and second for mobile call (w9ii/m)
 
Primary uploads and downloads correct.
Secondary w9ii/m hangs lately on downloads.
When downloading or uploading to secondary call
I would manually change the
info for user/password/qth nick for the secondary call.
Secondary call uploads correctly, but downloads
for those eqsl result in error.
returned error: You have no eqsl log entries at present.

Was working for me in the past last few years without a problem

Any clues ?
Joel w9ii


P.S. A eqsl dropdown box for location / login info
      like the lotw tab has would be a nice feature.

7801 - 7820 of 203941