Date   

Re: 13Colonies how to make SQL Spot Collector filter

Dave AA6YQ
 

+ AA6YQ comments below

how can i create a filter on the SCollector that does 

Band and Mode and Callsign LIKE 'K2?'  and Unworked

when selected, i only want to see the 'K2?' stations that on cw or ssb are unworked ??? 

putzed a bit, reading help file... seems to work until i add "unworked"... also would like only spots from the last 30min only...  also how to work in GB13COL WM3PEN TM13COL stations in addition to K2?

+ Reviewing

http://www.13colonies.us/

+ the objective is to work 15 specific callsigns, on any band in any mode. If that's correct, then

 

1. add each of those 15 callsigns to SpotCollector's Special Callsigns list with the tag 13colonies

https://www.dxlabsuite.com/dxlabwiki/IdentifyLogClubMembers


2. define a filter to find the stations you haven't worked on bands and modes on which you are QRV,:

(TAGS LIKE ('*13colonies*')) and (Bands in (list of bands I can work)) and (Modes in (list of modes I can work))

for example

(TAGS LIKE ('*13colonies*')) and (BAND in ('80m','40m','30m','20m','15m','10m','6m')) and (MODE in ('CW','SSB'))

3. When you work one of these 15 stations, remove it from SpotCollector's Special Callsign List

+ Good hunting!

      73,

              Dave, AA6YQ

 

 


13Colonies how to make SQL Spot Collector filter

bob-w9zv
 

how can i create a filter on the SCollector that does 

Band and Mode and Callsign LIKE 'K2?'  and Unworked

when selected, i only want to see the 'K2?' stations that on cw or ssb are unworked ??? 

putzed a bit, reading help file... seems to work until i add "unworked"... also would like only spots from the last 30min only...  also how to work in GB13COL WM3PEN TM13COL stations in addition to K2?


Re: Undocumented updates

Peter Laws / N5UWY
 

n Fri, Jul 1, 2022 at 3:49 PM Dave AA6YQ <aa6yq@...> wrote:

+ AA6YQ comments below

I am an Icom fanboy and I will be the first to say that the company
does not document CI-V well.

+ Icom is better at documenting its CAT commands than most.
Well, that's discouraging!!

Thank you for putting in the work to let us use all these command sets.



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


Re: QSL "R"

Dave AA6YQ
 

On Fri, Jul 1, 2022 at 05:36 PM, Joe Subich, W4TV wrote:
+ An easier way to accomplish that is to set the "QSL Via" panel to cards or labels, and then click the "Add Needed" button;
I was thinking of the opposite action ... *clearing* QSL_SENT for QSOs
that were not needed.

+ On the "QSL Configuration" window's General tab,  the "Preset QSL Requested checkbox" and "Initialize QSL Sent to 'R' for each imported QSO" option should only be enabled if your intent is to send a QSL card to every QSO partner with whom you log a QSO.

+ These days, most ops only send a QSL card if asked by their QSO partner -- in which case you should check the Capture window's "QSL Requested" box.

+ When its time to print cards or labels, click the "Add Needed" button to generate outgoing QSL cards/labels for which a confirmation would advance your award progress, and then click the "Add Requested" button to generate outgoing QSL cards/labels for the QSO partners who requested one.

        73,

               Dave, AA6YQ 

 

 

 


Re: QRZ.COM lookup delay in importing logs

Dave AA6YQ
 

+ AA6YQ comments below

Living in a rural area, my internet service is pretty slow (~10 Mb/s).  When importing an ADI contest log and DXKeeper configured to look up calls on QRZ, the first few calls imported sometimes result in a “Callbook error for XXXXXX: Name not resolved.”

 

Could a buffering delay be added to compensate for the lookup delay?

+ You could try increasing the "QRZ.com timeout" setting on the Configuration window's Callbook tab, but if Windows reports "Name not resolved", there is nothing I can do about it.

        73,

              Dave, AA6YQ


Re: QSL "R"

Joe Subich, W4TV
 

+ An easier way to accomplish that is to set the "QSL Via" panel to cards or labels, and then click the "Add Needed" button;
I was thinking of the opposite action ... *clearing* QSL_SENT for QSOs
that were not needed.

73,

... Joe, W4TV

On 2022-07-01 7:27 PM, Dave AA6YQ wrote:
+ AA6YQ comments below


One *could* use the "Need" filter (see Help file) and filter the log for
QSOs that are not needed, then use the "Modify" feature on the Advanced
filters screen to clear QSL_SENT, if one did not want to "waste" a card
for unneeded QSOs. It might be possible to automate the operation by
writing a script (I have not tested the possibility) if it is done on a
regular basis.
+ An easier way to accomplish that is to set the "QSL Via" panel to cards or labels, and then click the "Add Needed" button; unconfirmed QSOs whose confirmations will advance the awards you configured DXKeeper to pursue will be added to the QSL card.
73,
Dave, AA6YQ


QRZ.COM lookup delay in importing logs

Jim N7US
 

Living in a rural area, my internet service is pretty slow (~10 Mb/s).  When importing an ADI contest log and DXKeeper configured to look up calls on QRZ, the first few calls imported sometimes result in a “Callbook error for XXXXXX: Name not resolved.”

 

Could a buffering delay be added to compensate for the lookup delay?

 

73,  Jim N7US

 


Re: QSL "R"

Dave AA6YQ
 

+ AA6YQ comments below
One *could* use the "Need" filter (see Help file) and filter the log for
QSOs that are not needed, then use the "Modify" feature on the Advanced
filters screen to clear QSL_SENT, if one did not want to "waste" a card
for unneeded QSOs. It might be possible to automate the operation by
writing a script (I have not tested the possibility) if it is done on a
regular basis.

+ An easier way to accomplish that is to set the "QSL Via" panel to cards or labels, and then click the "Add Needed" button; unconfirmed QSOs whose confirmations will advance the awards you configured DXKeeper to pursue will be added to the QSL card. 

     73,

            Dave, AA6YQ


Re: QSL "R"

Joe Subich, W4TV
 

On 2022-07-01 1:33 PM, Earl Needham wrote:
I have a habit of setting ALL QSL's to "R when I work somebody -- IOW
I request QSL via LoTW, card, and eQSL.
You can direct DXKeeper to *automatically* set QSL_Sent, LotW_QSL_Sent
and eQSL_QSL_Sent to 'R' by checking the appropriate boxes in the
General, LotW and eQSL tabs of the QSL Config respectively.

Typically, one would upload to LotW daily/weekly - that will also
automatically set LotW_QSL_RCVD = 'R'.

And second -- is there an automatic way to set the other two to, say,
a blank when I receive a QSL via any method?
No, confirming a QSO by one method will not clear QSL_Sent for the other
two. As Dave pointed out, in general, since eQSL confirmations do not
count for ARRL awards one would not want receipt of an eQSL
"confirmation" to clear requests for cards/LotW.

One *could* use the "Need" filter (see Help file) and filter the log for
QSOs that are not needed, then use the "Modify" feature on the Advanced
filters screen to clear QSL_SENT, if one did not want to "waste" a card
for unneeded QSOs. It might be possible to automate the operation by
writing a script (I have not tested the possibility) if it is done on a
regular basis.


73,

... Joe, W4TV

On 2022-07-01 1:33 PM, Earl Needham wrote:
I have a habit of setting ALL QSL's to "R when I work somebody -- IOW I
request QSL via LoTW, card, and eQSL.
Two questions -- first, is this ridiculous?
And second -- is there an automatic way to set the other two to, say, a
blank when I receive a QSL via any method?
Tnx,
Earl
KD5XB


Re: Undocumented updates

Dave AA6YQ
 

+ AA6YQ comments below
I am an Icom fanboy and I will be the first to say that the company
does not document CI-V well.

+ Icom is better at documenting its CAT commands than most. Recall that I had to write the initial documentation for the Flex Signature's ethernet API by asking questions of Flex engineers.

+ Until recently, I would have said that Yaesu is the worst at it - but then  I encountered Thetis, which is unbelievable poor.

+ Recall the FT-817/857/897 disaster, in which an undocumented command that writes to non-volatile memory addresses was used to modify radio parameters not accessible via the documented CAT command set. One logging application took advantage of this, ignoring the point that non-volatile memories have a finite "write budget". Exceed that budget, and the memory stops working, which bricks the radio. Evidently, Yaesu no longer has access to replacement parts, so those radios are not reparable.

de AA6YQ


Re: Undocumented updates

Peter Laws / N5UWY
 

On Fri, Jul 1, 2022 at 3:02 PM k6xt <k6xt@...> wrote:

Referring to our recent IC7300 XFC discussion how can I help you implement the discussed undocumented feature, should you decide to add it to your todo list? If you need one I'll send you my IC7300.

Incidentally my statement that the capability is undocumented referred to the user manual. Not a programmer, I don't know what assets are made available by Icom.
I am an Icom fanboy and I will be the first to say that the company
does not document CI-V well.

On my IC-910H, the CI-V command table is poorly rendered in the docs
and makes it appear that you can't turn on the transmitter via CI-V
... but you can ... and now Commander knows about this feature under
the name "IC-910HA". A fake ID because it's not clear which of the
versions of that radio supports it (910A, 910D, 910H, 911, etc) so
doing it like that is probably the best way to handle it.



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


Re: Undocumented updates

Dave AA6YQ
 

+ AA6YQ comments below
Reading the update notes for Commander 15.4.4 I see an undocumented feature on a Yaesu rig that wasn't ignored..

Referring to our recent IC7300 XFC discussion how can I help you implement the discussed undocumented feature, should you decide to add it to your todo list? If you need one I'll send you my IC7300.

Incidentally my statement that the capability is undocumented referred to the user manual. Not a programmer, I don't know what assets are made available by Icom.

+ "Supports the undocumented FT-757GXII meter reading CAT command" in Commander 15.4.4 was low risk: that radio's functionality cannot be changed via a firmware update, and the change supports a capability that isn't already present. If it were to fail due to a future action by Yaesu, users would be in no worse shape than they were before Commander 15.4.4.

+ Icom radios provide a Split mechanism that works well for working DX stations operating split. Exploiting undocumented commands in an Icom radio that is under active development with firmware updates to replicate functionality that already exists would be risky, and would not be a good use of my development time compared to alternative uses of that time.

          73,

               Dvae, AA6YQ

 


Undocumented updates

k6xt
 

Hi Dave

Reading the update notes for Commander 15.4.4 I see an undocumented feature on a Yaesu rig that wasn't ignored..

Referring to our recent IC7300 XFC discussion how can I help you implement the discussed undocumented feature, should you decide to add it to your todo list? If you need one I'll send you my IC7300.

Incidentally my statement that the capability is undocumented referred to the user manual. Not a programmer, I don't know what assets are made available by Icom.

73 Art K6XT/W7NTA


Re: DXKeeper 16.6.6 is available

Dave AA6YQ
 

+ AA6YQ comments below

Thanks for the MyQTH report button! Would it be possible to add a box letting you know the report is being created with an abort
button and progress bar? I have 99000 QSOs and 311 MyQTHs and it takes about 63 seconds to prepare the report. The first time I
ran it I didn't think it was working and pressed the report button a couple of times which produced a box saying the report couldn't
be created. Finally the report came up.

A box letting me know the report is being created would be really helpful.

73, Alan N5NA

+ That's a defect. In the next version of DXKeeper, the mouse cursor changes to a spinning wheel to indicate that the Report is
being generated, and you won't be able to re-invoke the Report while it's running. Thanks!

73,

Dave, AA6YQ


Re: QSL "R"

Earl Needham
 

Oops, one got away from me!  That blank message was a wild one, I tell ya'!

On Fri, Jul 1, 2022 at 12:16 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below
I have a habit of setting ALL QSL's to "R when I work somebody -- IOW I request QSL via LoTW, card, and eQSL.
 
Two questions -- first, is this ridiculous?

+ There is no log item named "ALL QSLs".

Yes, I've been doing this manually. 

+ DXKeeper's QSL automation is triggered by setting one or more of the "QSL Sent", "LoTW QSL Sent", and/or "eQSL QSL Sent" items to 'R', meaning "Requested". There are options on the appropriate tabs of the "QSL Configuration" window to automate this. 

<snip>

+ I suggest that you review

https://www.dxlabsuite.com/dxkeeper/Help/QSL.htm

+ and

https://www.dxlabsuite.com/dxlabwiki/QSLing


Headed there now, thanks.

Earl



Re: QSL "R"

Earl Needham
 

On Fri, Jul 1, 2022 at 12:16 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below
I have a habit of setting ALL QSL's to "R when I work somebody -- IOW I request QSL via LoTW, card, and eQSL.
 
Two questions -- first, is this ridiculous?

+ There is no log item named "ALL QSLs".


 

+ DXKeeper's QSL automation is triggered by setting one or more of the "QSL Sent", "LoTW QSL Sent", and/or "eQSL QSL Sent" items to 'R', meaning "Requested". There are options on the appropriate tabs of the "QSL Configuration" window to automate this. 

+ The "Add Requested" function on the Main window's QSL tab employs these items to populate the QSL Queue, as a function of that tab's "QSL Via" panel setting. After an outgoing QSL card or label is printed from the QSL Queue, the "Update Log" function changes that QSO's "QSL Sent" item from 'R' to 'Y'. After submitting a QSO to LoTW, when the "Sync LoTW QSOs" function reports that QSO to have been accepted by LoTW, its "LoTW QSL Sent" item is set to 'Y' and and its "LoTW QSL Rcvd" item is set to 'R'. Submitting a QSO to eQSL sets its "eQSL QSL Sent" item to 'Y' and its "eQSL QSL Rcvd" item to 'R'.

+ The "Sync eQSL QSLs" and "Sync LoTW QSLs" functions automate the updating of a QSO's "eQSL QSL Rcvd" and "LoTW QSL Rcvd" items respectively. You must manually set a QSO's "QSL Rcvd" item to 'R' when you receive a QSL card for that QSO.

And second -- is there an automatic way to set the other two to, say, a blank when I receive a QSL via any method?

+ No. You wouldn't want the receipt of an eQSL confirmation to prevent you from seeking an LoTW confirmation, for example, as eQSL confirmations are not valid for ARRL awards.

+ I suggest that you review

https://www.dxlabsuite.com/dxkeeper/Help/QSL.htm

+ and

https://www.dxlabsuite.com/dxlabwiki/QSLing

     73,

           Dave, AA6YQ

 

 


Re: QSL "R"

Dave AA6YQ
 

+ AA6YQ comments below
I have a habit of setting ALL QSL's to "R when I work somebody -- IOW I request QSL via LoTW, card, and eQSL.
 
Two questions -- first, is this ridiculous?

+ There is no log item named "ALL QSLs".

+ DXKeeper's QSL automation is triggered by setting one or more of the "QSL Sent", "LoTW QSL Sent", and/or "eQSL QSL Sent" items to 'R', meaning "Requested". There are options on the appropriate tabs of the "QSL Configuration" window to automate this. 

+ The "Add Requested" function on the Main window's QSL tab employs these items to populate the QSL Queue, as a function of that tab's "QSL Via" panel setting. After an outgoing QSL card or label is printed from the QSL Queue, the "Update Log" function changes that QSO's "QSL Sent" item from 'R' to 'Y'. After submitting a QSO to LoTW, when the "Sync LoTW QSOs" function reports that QSO to have been accepted by LoTW, its "LoTW QSL Sent" item is set to 'Y' and and its "LoTW QSL Rcvd" item is set to 'R'. Submitting a QSO to eQSL sets its "eQSL QSL Sent" item to 'Y' and its "eQSL QSL Rcvd" item to 'R'.

+ The "Sync eQSL QSLs" and "Sync LoTW QSLs" functions automate the updating of a QSO's "eQSL QSL Rcvd" and "LoTW QSL Rcvd" items respectively. You must manually set a QSO's "QSL Rcvd" item to 'R' when you receive a QSL card for that QSO.

And second -- is there an automatic way to set the other two to, say, a blank when I receive a QSL via any method?

+ No. You wouldn't want the receipt of an eQSL confirmation to prevent you from seeking an LoTW confirmation, for example, as eQSL confirmations are not valid for ARRL awards.

+ I suggest that you review

https://www.dxlabsuite.com/dxkeeper/Help/QSL.htm

+ and

https://www.dxlabsuite.com/dxlabwiki/QSLing

     73,

           Dave, AA6YQ

 

 


Re: DXKeeper 16.6.6 is available

Alan N5NA
 


- provides a Report button on the Main window's "My QTHs" tab that generates a myQTH report that shows the number and percentage of
total QSOs made from each myQTH (requester lost in the mists of time)
Thanks for the MyQTH report button!  Would it be possible to add a box letting you know the report is being created with an abort button and progress bar?  I have 99000 QSOs and 311 MyQTHs and it takes about 63 seconds to prepare the report.  The first time I ran it I didn't think it was working and pressed the report button a couple of times which produced a box saying the report couldn't be created.  Finally the report came up.

A box letting me know the report is being created would be really helpful.

73, Alan N5NA


QSL "R"

Earl Needham
 

I have a habit of setting ALL QSL's to "R when I work somebody -- IOW I request QSL via LoTW, card, and eQSL.

Two questions -- first, is this ridiculous?

And second -- is there an automatic way to set the other two to, say, a blank when I receive a QSL via any method?

Tnx,
Earl
KD5XB


Re: DXKeeper 16.6.6 is available

Peter Laws / N5UWY
 

On Fri, Jul 1, 2022 at 11:02 AM Dave AA6YQ <aa6yq@...> wrote:

- what is specified in DXKeeper's "Program Path"?
I have a LOT of windows on my screens. At some point, while
DXKeeper's config dialog was on the screen, it had focus and what I
typed when there, scrambling the path.

All fixed now. When fellow League life member and IRCA member Wayne
said he'd had no issues, I knew I needed to angle the blame mirror a
little differently. :-)

Thanks for requesting methodical data collection as that lead me right
to the (my) error!

Now, off to run up my 50-MHz grid totals ... 250 is within sight.




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

1461 - 1480 of 210307