For some time ago, you gave the answer on this question, but i failed to save your comment (sorry), So again:

When I start the program DXKeeper, the height of the layout is not what I had adjusted it before (e.q. 75% of the screen height).
It Is again the maximum (100%) of my screen height, so I have to adjust it again and again.
Using the Logdisplayfile In "Config" to save my adjustments (..\DXLAB\DXKeeper\Configurations\log Logdisplayfile2.txt), does not give me the wanted result.
What do I WRONG?

How do I solve this problem?
Please help me once more and I promise I will save your answer for sure!

+ My previous response is here:

https://groups.io/g/DXLab/message/204089

73,

Dave, AA6YQ

 73 de Wim, PA0WJG

Hi Dave,

Ok, I can understand part of this now including the screenshot I just sent you (so please disregard it !). The filter that’s showing up in the “Audio Alarm trigger” window now IS an expanded version of my SC filter as you explain here.

However, I can’t understand where the original error came from this morning because the alert function wasn’t enabled then and the SQL that showed up then isn’t the one that’s showing up now. I’m sure because I copied it at the time and still have it. That SQL had errors in it, which i fixed !

But a lot has happened now and I guess I can’t say for sure what exactly was going on when that filter showed up anymore. Right now everything seems to be working as expected so let me just leave it at this for now. If something seemingly weird starts showing up that my new understanding can’t explain, I’ll shoot you another post.

Thanks as always Dave !
Russ KR6W

+ AA6YQ comments below

@ In the "Audio Alarm trigger" panel, check the "Match SDB filter" box. With this panel still visible, type my callsign into the textbox in the Main window's Filter panel, and then click the Filter panel's Call button. The SQL expression shown in the "Audio Alarm" tab's "Audio Alarm trigger" panel should be updated to match your new Spot Database filter; the SQL expression should begin with

((Callsign LIKE 'aa6yq') AND �

-rr2: Done. Yes, that is exactly what happened. It�s a pretty big filter but it starts as you show above. What the heck ?????????

+ The Call filter is not simply

Callsign LIKE 'aa6yq')

+ It includes the Band filter, the Mode filter, the Continent filter, the Origin filter, the Age filter (if enabled) and the AutoHide filter (if enabled). You're seeing the SQL that implements all of that.

73,

Dave, AA6YQ

OK, my responses now following “—rr2: "

On Jan 6, 2022, at 8:55 PM, Dave AA6YQ <aa6yq@...> wrote:

@ more AA6YQ comments below

+ Evidently, the current Spot Database Display filter is incorrect. Your action copied this incorrect filter to the "Audio Alarm" tab's big SQL expression box.

�rr: The thing here is, the current spot database display filter is one I�ve used almost every day for months, it produces the expected results and never throws an error. But more to the point, it is completely different than the filter that shows up in the SQL window described. As I mentioned, I can�t find that filter anywhere.

@ It is the last filter you applied to the Spot Database.

—rr2: yeah, sorry, should have specifically stated this. Yes, it is the last filter applied and the one current while running these tests.

@ In the "Audio Alarm trigger" panel, check the "Match SDB filter" box. With this panel still visible, type my callsign into the textbox in the Main window's Filter panel, and then click the Filter panel's Call button. The SQL expression shown in the "Audio Alarm" tab's "Audio Alarm trigger" panel should be updated to match your new Spot Database filter; the SQL expression should begin with

((Callsign LIKE 'aa6yq') AND …

-rr2: Done. Yes, that is exactly what happened. It’s a pretty big filter but it starts as you show above. What the heck ?????????

73,

Dave, AA6YQ

@ more AA6YQ comments below

+ Evidently, the current Spot Database Display filter is incorrect. Your action copied this incorrect filter to the "Audio Alarm" tab's big SQL expression box.

�rr: The thing here is, the current spot database display filter is one I�ve used almost every day for months, it produces the expected results and never throws an error. But more to the point, it is completely different than the filter that shows up in the SQL window described. As I mentioned, I can�t find that filter anywhere.

@ It is the last filter you applied to the Spot Database.

@ In the "Audio Alarm trigger" panel, check the "Match SDB filter" box. With this panel still visible, type my callsign into the textbox in the Main window's Filter panel, and then click the Filter panel's Call button. The SQL expression shown in the "Audio Alarm" tab's "Audio Alarm trigger" panel should be updated to match your new Spot Database filter; the SQL expression should begin with

((Callsign LIKE 'aa6yq') AND ...

73,

Dave, AA6YQ

Hi Dave,

Thanks for the response. My responses next to “—rr: ” below:

On Jan 6, 2022, at 8:19 PM, Dave AA6YQ <aa6yq@...> wrote:

+ AA6YQ comments below

After having settled on various SQL filters I've been running SC without issues or unexpected behavior for many months. Today I noticed a generic "something is wrong with an SQL filter" error message which listed the offending filter.

After hunting it down, I found it in SC>Conf>Audio Alarm>Audio Alarm trigger. It's a long filter so I broke it out in Notepad and successfully discovered three grouping errors. I fixed the errors and replaced the filter. I did not receive an error and the "SQL Expression" label did not turn red so the correction seemed to be OK at least w/r to syntax.

+ Clicking he "Audio Alarm trigger" panel's Test button (upper-right corner) is the recommended way to test the SQL expression you've specified.

"SQL expression" and "Match SDB filter" boxes were both checked. It seems odd an error only just occurred since no SQL expressions have been changed for many months. But it gets weirder ...


+ If the "Audio Alarm" tab's Enable box is not checked, the SQL expression would never be invoked, and thus the syntax error never reported.

I wanted to try checking only the "Match SDB filter" box to make sure I understand correctly that is uses the filter I have selected for SC itself (top SC window, bottom panel at "Filter" :). I checked "Needed" in the "Audio Alarm trigger" panel then clicked back to "Match SDB filter" and to my surprise:

1) BOTH the "Match SDB filter" and the "SQL expression" buttons became checked (not just the "Match SDB filter" button I'd clicked)

+ That's correct. Checking "Match SDB filter" populates the "Audio Alarm" tab's big SQL expression box with the current Spot Database Display filter and sets the "Audio Alarm trigger" to "SQL expression"

2) the corrected filter I'd just placed in the SQL window was replaced by the incorrect one I'd just fixed

—rr: Good, thanks. I understand everything above this line.

+ Evidently, the current Spot Database Display filter is incorrect. Your action copied this incorrect filter to the "Audio Alarm" tab's big SQL expression box.

—rr: The thing here is, the current spot database display filter is one I’ve used almost every day for months, it produces the expected results and never throws an error. But more to the point, it is completely different than the filter that shows up in the SQL window described. As I mentioned, I can’t find that filter anywhere.

3) no error was generated and the "SQL expression" label did not turn red despite the fact that the filter now had the three grouping errors that started this all off in the first place

+ The error would have been reported had you clicked the "Audio Alarm trigger" panel's Test button.

—rr: Right, got it. That explains that part - thanks !

4) the filter isn't even close to the one I have selected for SC, isn't any of the filters I've created for any of the SC user buttons, and I can't find it anywhere else !

Obviously, I'm completely missing something. Where would that filter come from

+ It's the most recent filter you invoked via the Main window's Filter panel.

—rr: Again, weirdly it really isn’t as I mentioned above ! I can’t figure out WHAT filter it is ! It’s clearly one I crafted because it has, for example, my callsign embedded in it.

why doesn't it ALWAYS produce an error and how to I replace it with the corrected one ?

+ Before you check the "Match SDB filter" box, make sure that the Spot Database filter is valid.

—rr: Done as mentioned above, and just done again to be thorough - it IS valid.

Also, despite all of this, is the "Match SDB filter" option using the selected SC filter ?

+ Not if the current Spot Database filter is not a valid SQL expression.

—rr: Understand, but this one is. Something else seems to be going on ??

73,

Dave, AA6YQ

+ AA6YQ comments below

After having settled on various SQL filters I've been running SC without issues or unexpected behavior for many months. Today I noticed a generic "something is wrong with an SQL filter" error message which listed the offending filter.

After hunting it down, I found it in SC>Conf>Audio Alarm>Audio Alarm trigger. It's a long filter so I broke it out in Notepad and successfully discovered three grouping errors. I fixed the errors and replaced the filter. I did not receive an error and the "SQL Expression" label did not turn red so the correction seemed to be OK at least w/r to syntax.

+ Clicking he "Audio Alarm trigger" panel's Test button (upper-right corner) is the recommended way to test the SQL expression you've specified.

"SQL expression" and "Match SDB filter" boxes were both checked. It seems odd an error only just occurred since no SQL expressions have been changed for many months. But it gets weirder ...


+ If the "Audio Alarm" tab's Enable box is not checked, the SQL expression would never be invoked, and thus the syntax error never reported.

I wanted to try checking only the "Match SDB filter" box to make sure I understand correctly that is uses the filter I have selected for SC itself (top SC window, bottom panel at "Filter" :). I checked "Needed" in the "Audio Alarm trigger" panel then clicked back to "Match SDB filter" and to my surprise:

1) BOTH the "Match SDB filter" and the "SQL expression" buttons became checked (not just the "Match SDB filter" button I'd clicked)

+ That's correct. Checking "Match SDB filter" populates the "Audio Alarm" tab's big SQL expression box with the current Spot Database Display filter and sets the "Audio Alarm trigger" to "SQL expression"

2) the corrected filter I'd just placed in the SQL window was replaced by the incorrect one I'd just fixed

+ Evidently, the current Spot Database Display filter is incorrect. Your action copied this incorrect filter to the "Audio Alarm" tab's big SQL expression box.

3) no error was generated and the "SQL expression" label did not turn red despite the fact that the filter now had the three grouping errors that started this all off in the first place

+ The error would have been reported had you clicked the "Audio Alarm trigger" panel's Test button.


4) the filter isn't even close to the one I have selected for SC, isn't any of the filters I've created for any of the SC user buttons, and I can't find it anywhere else !

Obviously, I'm completely missing something. Where would that filter come from

+ It's the most recent filter you invoked via the Main window's Filter panel.


why doesn't it ALWAYS produce an error and how to I replace it with the corrected one ?

+ Before you check the "Match SDB filter" box, make sure that the Spot Database filter is valid.


Also, despite all of this, is the "Match SDB filter" option using the selected SC filter ?

+ Not if the current Spot Database filter is not a valid SQL expression.

73,

Dave, AA6YQ

+ AA6YQ comments below.

Thank you Dave for the reply. I checked my TQSL program and there are no mappings in the custom ADIF mode mappings window. When I look a the QSO on LOTW it shows the mode as PSK31 when his call is shown as the worked station. When I click the date and I become the worked station it shows the mode as DATA(DATA).

+ That indicates that TQSL submitted your QSO's mode to LoTW as DATA. With this QSO selected in the Log Page Display on the Main window's "Log QSOs" tab, what does DXKeeper show as the "date sent" in the LoTW sub-panel in the "Online QSLs" panel on that tab?

73,

Dave, AA6YQ

Thank you Dave for the reply. I checked my TQSL program and there are no mappings in the custom ADIF mode mappings window.  When I look a the QSO on LOTW it shows the mode as PSK31 when his call is shown as the worked station. When I click the date and I become the worked station it shows the mode as DATA(DATA). Does this mean he logged it as DATA? I surely have it in my log as PSK31.

Thanks <<John N4QWF

+ AA6YQ comments below

Been running nicely ever since you sent it out.

+ Note: SpotCollector 9.0.2 has not been publicly released; it's being tested by a dozen users who reported defects and/or suggested enhancements.

Like the new features.

+ Most of the new features are extensions to SpotCollector's Pre-filter window:

- augments the Pre-filter window with a "Discard incoming spots of stations in selected continents" panel

- augments the Pre-filter window with a "Discard incoming spots of NXCDF beacons" checkbox

- augments the Pre-filter window with a "Discard incoming spots of stations in selected DXCC entities" panel that provides 6 DXCC entity selectors

+ This version also lets you specify a different "Initial cluster command" for each cluster so that you can, for example, configure one of those cluster commands to enable RBN spots

+ I will make a public release when I'm confident that the reported defects have been repaired and no new defects have been inserted.

+ Thanks for the testing and report, Jose!

73,

Dave, AA6YQ

+ AA6YQ comments below

Today I worked K1KEN on 20m PSK31. This evening I updated my log from LOTW and DXKeeper reported the QSO mode was logged as DATA. I logged into LOTW and Ken had uploaded it as PSK31 but the upload from DXKeeper was reported as DATA(DATA). My log says PSK31 for the mode. I recall when FT8 was introduced LOTW had issues handling the mode correctly. I have uploaded many PSK31 QSO's in the past without issues. I tried to upload it again but TQSL sees it as a dupe and reports it was uploaded as MODE: PSK and SUBMODE: PSK31. Anyone have any idea what went wrong and how to fix it?

+ If the QSO's mode was originally logged as PSK31 in DXKeeper, then there are two possibilities:

1. you have TQSL configured to "map" PSK31 to DATA

2. your QSO partner K1KEN submitted your QSO with a mode of DATA

+ To check out #1 as a possibility, see

https://lotw.arrl.org/lotw-help/pref-adi/

73,

Dave, AA6YQ

+ AA6YQ comments below

Looking at the Aggregator Manual, page 18, figure 10.1 ... it looks
like you need to check the "Check here if users should be asked for
their call when connecting" box and configure SC to "Log in" to that
port.

To simplify, your local aggregator port must look like a cluster to
SC before it will register as "connected" and SC will add spots to
its database.

+ Don, did taking Joe W4TV's advice above enable SpotCollector to populate its Spot Database with information from your aggregator application?

      73,

             Dave, AA6YQ

Today I worked K1KEN on 20m PSK31. This evening I updated my log from LOTW and DXKeeper reported the QSO mode was logged as  DATA. I logged into LOTW and Ken had uploaded it as PSK31 but the upload from DXKeeper was reported as DATA(DATA). My log says PSK31 for the mode. I recall when FT8 was introduced LOTW had issues handling the mode correctly. I have uploaded many PSK31 QSO's in the past without issues. I tried to upload it again but TQSL sees it as a dupe and reports it was uploaded as MODE: PSK and SUBMODE: PSK31. Anyone have any idea what went wrong and how to fix it?

Thanks John N4QWF

+ AA6YQ comments below

After a day of operating, I am seeing no issues with the new version of DXKeeper

+ Thanks for the testing and the report, Don!

     73,

           Dave, AA6YQ

+ AA6YQ comments below

To expedite clearing a backlog of outgoing QSLs, I decided to use the DXKeeper label printing feature. It is a very flexible tool! But I was somewhat dismayed to see the QSL Date Format options only specified a 2-digit year (Local and English month options). I am a little picky on this point but I believe calendar years should always be four digits in length (have we learned nothing from Y2K!). I realize there is a potential line length limitation depending on the label dimension where two additional characters could be significant. Therefore I suggest adding a new QSL Date Format option for English Month featuring a 4-digit year. That way if there is a character length label constraint one could still select a 2-digit year option. Yes, I realize the ISO-8601 option is a 4-digit year but I prefer to have the month as alpha text rather than a numeric.

+ If you want a 4-digit year in the dates printed on QSL cards or QSL labels, your choices are to use the ISO-8601 format (YYYY-MM-DD) or to use DXKeeper to drive a more flexible QSL card/label generator, as described in

https://www.dxlabsuite.com/dxkeeper/Help/QSL.htm#QSLing%20via%20ADIF     

     73,

            Dave, AA6YQ

 

 

 

+ AA6YQ comments below

I last uploaded my log to LOTW a week ago with no problem.  Today I get the message "LOTW username/password incorrect."  I haven't changed the password.   I checked in the QSL Config window in the LOTW tab and the password I've been using for years is still there.  I then tried to log in to  LOTW on the ARRL.org website, which has always had a different password, I get the message that the username/password is incorrect.  I haven't changed any passwords so what am I missing?

+ If the LoTW username and password that you've specified in DXKeeper no longer allow you to log into your LoTW web account via your web browser, then I suggest that you contact the ARRL's Help Desk via

LoTW-help@...

+ If that's not the situation, please correct my misunderstanding.

    73,

         Dave, AA6YQ

 

On Thu, Jan 6, 2022 at 4:40 PM Wayne, W0ZW <greaves.wayne@...> wrote:

To expedite clearing a backlog of outgoing QSLs, I decided to use the DXKeeper label printing feature. It is a very flexible tool! But I was somewhat dismayed to see the QSL Date Format options only specified a 2-digit year (Local and English month options). I am a little picky on this point but I believe calendar years should always be four digits in length (have we learned nothing from Y2K!). I realize there is a potential line length limitation depending on the label dimension where two additional characters could be significant. Therefore I suggest adding a new QSL Date Format option for English Month featuring a 4-digit year. That way if there is a character length label constraint one could still select a 2-digit year option. Yes, I realize the ISO-8601 option is a 4-digit year but I prefer to have the month as alpha text rather than a numeric.

https://xkcd.com/2562/

Per the mouse-over, I am apparently a big-endian enthusiast ...


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