Re: Commander - Disable interrogation doesnt ¡°stick¡±
+ AA6YQ comments below
Have a need to disable Commander¡¯s interrogation of a 7610 (mostly because of documented/captured CIV bus collisions that the flex amp/tuner cannot handle, thats another story). ? If i dont, the flex (not so genius) amp and tuner randomly change frequencies if slaving to the civ when collisions occur (long story, for another tread).
But when i goto commander¡¯s config, and uncheck the interrogation box, it doesnt seem to save that configuration artifact when i close the appl and i have to again disable it every time.
anyone else notice this? ? I¡¯d like to have it save it and restore that setting like all (or most) the other settings.
+ Commander's Interrogation option is intentionally enabled at startup because control of most radios requires it. For example, Commander can't track the state of your IC-7610's receive filtering with Interrogation disabled; it also can't track S-meter and transmit meter readings. The ability to temporarily disable Interrogation is provided for diagnostic purposes.
+ Any device that connects to an Icom CI-V bus must be able to properly handle collisions, as specified in the CI-V bus specification. The CI-V bus uses the same technique as does the Ethernet physical layer protocol; collisions should not cause errors!
+ The designers of Icom's PW-1 amplifier assumed that the amplifier would be directly connected to the transceiver's CI-V port with no other CI-V devices present to cause collisions, and so omitted the (trivial) collision detection logic. When ops began using connecting their PCs to the CI-V bus to enable the use of transceiver control applications (like Commander), the resulting collisions let the smoke out of many a PW-1. Larry K8UT carefully studied this phenomenon, and documented his findings in a paper entitled? "Riding the CI-V Bus", which is available here:
+ Commander's Secondary CAT port can be configure to provide a collision free CI-V bus for the PW-1 amplifier. I don't know that this will satisfy your Flex amplifier and tuner, but you might give it a try. See
+ From a source code review (but not a hand-on test), the technique that Joe W4TV suggested -- configure Commander to use MultiRadio support and disable Interrogation on the Configuration window's MultiRadio tab -- should work. However, running with Interrogation disabled will result in a loss of functionality, as noted above. Using Commander's Secondary CAT port would be the best solution, if it keeps your amplifier and tuner happy.
? ? ? ?73,
? ? ? ? ? ? ?Dave, AA6YQ
?
?
|
Re: DXKeeper logging a WSJT-X rover's home grid, and not his actual grid
Dave, I just worked WR7X/P in DN05, home grid DN14cs, and DXKeeper logged it properly as DN05!
I will watch for more rovers and see if the /P or /R makes it work.
I'll keep you posted.
-Chris
|
Print the instructions and check them off as perform the actions.
?
73,
Dave, w6de
?
toggle quoted message
Show quoted text
From: [email protected]
<[email protected]> On Behalf Of Rod W7ZRC via groups.io
Sent: 15 June, 2024 22:41
To: [email protected]
Subject: Re: [DXLab] Moving ...
?
Have you reviewed:?? ???
GL and 73, Rod w7zrc
?
On Saturday, June 15, 2024, 4:33 PM, k3sui@... wrote:
Question for all the exerts. I am moving to a new PC and would like to have DX Labs keep all of the attributes that I have built within it for the last 16 years. I have tried several
of my own "home grown" methods without success. Can someone tell me how to clone my new PC so that DX labs will look and act the same as my old PC without taking years to sort things out. Thank You in advance for the help,.?
73
Barry
K3SUI
|
Re: Commander - Disable interrogation doesnt ¡°stick¡±
Do you have more than one radio defined or a radio
defined on the MultiRadio tab? If so, uncheck interrogation
there.
Do you have a workspace defined and loaded on start-up? If
so, uncheck interrogation on both the General and MultiRadio
tabs, close all applications except Launcher and update your
workspace.
73,
... Joe, W4TV
toggle quoted message
Show quoted text
On 6/16/2024 11:41 AM, bob-w9zv wrote: Have a need to disable Commander¡¯s interrogation of a 7610 (mostly because of documented/captured CIV bus collisions that the flex amp/tuner cannot handle, thats another story). ? If i dont, the flex (not so genius) amp and tuner randomly change frequencies if slaving to the civ when collisions occur (long story, for another tread).
But when i goto commander¡¯s config, and uncheck the interrogation box, it doesnt seem to save that configuration artifact when i close the appl and i have to again disable it every time.
anyone else notice this? ? I¡¯d like to have it save it and restore that setting like all (or most) the other settings.
|
Commander - Disable interrogation doesnt ¡°stick¡±
Have a need to disable Commander¡¯s interrogation of a 7610 (mostly because of documented/captured CIV bus collisions that the flex amp/tuner cannot handle, thats another story). ? If i dont, the flex (not so genius) amp and tuner randomly change frequencies if slaving to the civ when collisions occur (long story, for another tread).
But when i goto commander¡¯s config, and uncheck the interrogation box, it doesnt seem to save that configuration artifact when i close the appl and i have to again disable it every time.
anyone else notice this? ? I¡¯d like to have it save it and restore that setting like all (or most) the other settings.
|
Re: DXKeeper logging a WSJT-X rover's home grid, and not his actual grid
|
With me the TQSL.exef dosent work, I wrote a script where PF is started first, and than all other programs, thats working fine for me
73 Alex, OE3JTB
|
I should have mentioned I am controlling an Elecraft K4 by using remote desktop (in my case, RustDesk or AnyDesk) and "tuning" by mouse-wheeling in the VFO A panel of Commander.??
In theory, any knob that can imitate a mouse wheel should work. On Sun, Jun 16, 2024 at 5:07?AM Gordon LaPoint N1MGO via <gordon.lapoint= [email protected]> wrote:
Chuck,
??? What kind on radio are you
controlling remotely and how?
Gordon - N1MGO
On 6/15/2024 6:44 PM, Chuck, WS1L via
wrote:
I'm not loving the experience of "tuning" my radio
remotely via mousewheel.? Has anyone used a USB variable knob of
some sort for this?? I see several different ones for sale, some
of which look as though they could be made to work.
But I'm not looking to (ahem...) re-invent the, well, you
know.
|
Dave,
I have seen this same situation between DXKeeper and Spot Collector. Ever since I changed the TQSL file to exef as you recommended previously, the issue has not reappeared.
Bruce - K5WBM
toggle quoted message
Show quoted text
On Jun 15, 2024, at 8:40?PM, Dave AA6YQ via groups.io <aa6yq@...> wrote:
?# More AA6YQ comments below
clearing the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab eliminate the "on startup, DXKeeper isn't connected to Pathfinder" misbehavior?
+ DXKeeper does not use DDE to interoperate with TQSL - it directs Windows to start TQSL with a particular set of command line arguments, and then waits for TQSL to create a file containing the requested results ("news" about a new version or approaching Callsign Certificate expirations). With LoTW not available, TQSL never creates that file; DXKeeper eventually gives up.
+ It's possible that DXKeeper waiting for that file to be created is responsible for the "on startup, DXKeeper isn't connected to Pathfinder" misbehavior on some systems. What happened after you cleared the "TQSL.exe pathname"?
Thanks for such a quick response, Dave.
My DXLab Suite and PF is currently without any hiccup, but I'm going to attempt to recreate the PF hiccup thusly:
1) I reinserted what I had removed weeks ago, the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab and then proceeded to terminate DXLab Launcher and all enabled programs.
2) Restarted the PC.
3) DXLauncher opens all enabled programs.
4) DXKeeper opens and displays only a [CC] in it's titlebar and not what I would expect to see, [CC,PF].
5) A popup window, "DXKeeper: Updates from LoTW" reports, "TQSL is unable to connect LoTW". I acknowledge with an "OK" click and the popup closes.
6) I click on a previously logged entry in the DXKeeper log and focusing on the PF window I see no response there. What I expect to see is the selected callsign's QRZ page.
7) The hiccup has returned. PF will not respond to queries.
7) I close PF, relaunch PF, and now [CC,PF] is displayed on the DXKeeper titlebar.
8) PF works as it should for this session of DXLab Suite. With a reboot, the PF hiccup returns.
--------- Now, to return my system to not having the PF hiccup I follow these steps:
1) I remove the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab and proceed to terminate DXLab Launcher and all enabled programs.
2) Restart the PC.
3) DXLauncher opens all enable programs.
4) DXKeeper opens and displays a [CC,PF] in the titlebar as it should for me.
5) There is no popup window warning of LoTW being offline or TQSL difficulties nor of any other potential problem
6) PF responds as it should and has for several weeks now, but only after eliminating the TQSL.exe pathname as cited above. My reasoning for erasing the TQSL.exe pathname? Why launch an executable that cannot work until the LoTW server is restored.
All I know is that this detail has worked for me and once LoTW is restored I'll reinsert the TQSL.exe pathname.
# Many thanks, Joe! Your methodical approach demonstrates that when DXKeeper is not "connected" to Pathfinder at startup, the root cause is likely DXKeeper waiting for TQSL to respond to its "report the LoTW news" query.
# Rather than temporarily clear the TQSL pathname as you report above, I suggest instead making this change in the pathname:
TQSL.exe => TQSL.exef
# This will prevent DXKeeper from directing TQSL to "report the LotW news", but make it easy to restore the correct TQSL pathname after LoTW is again accessible.
Dave, I have not seen the "on startup, DXKeeper isn't connected to Pathfinder" popup. I've been spared that one <whew!>
# There is no such popup; that's just my concise description of the misbehavior.
Oh, and thanks for the clarification about DDE calls and such. You're the program guru. I most certainly am not.
# Nor should you need to be.
73,
Dave, AA6YQ
|
Chuck,
??? What kind on radio are you
controlling remotely and how?
Gordon - N1MGO
On 6/15/2024 6:44 PM, Chuck, WS1L via
groups.io wrote:
toggle quoted message
Show quoted text
I'm not loving the experience of "tuning" my radio
remotely via mousewheel.? Has anyone used a USB variable knob of
some sort for this?? I see several different ones for sale, some
of which look as though they could be made to work.
But I'm not looking to (ahem...) re-invent the, well, you
know.
|
Re: LOTW - unable to contact server
+ AA6YQ comments bleow
Being a QRP operator all my QSOs for the past 20 years have been with
5W. I set this manually on QSO entries but it would be nice in the
configuration to be able to set this en masse rather than separately for
each band and mode.
+ If you set the "Transmit Power" to 5 on the Configuration window's Defaults tab, then all new QSOs will be logged with TX_Power items set to 5, independent of band and mode.
+ For QSOs you've already logged, you can set the TX_Power item to 5 in every logged QSO using the "Modify QSOs" panel in the "Advanced Sorts, Filters, and Modifiers" window. Step-by-step instructions are here:
+ Step 1 is critical: by backing up your log, you can easily "undo" an operation that didn't turn out as you expected.
?
And being a dinosaur I still use paper logs outside
contests and all my day to day QSOs are input post event. DXKeeper seems
to do this fairly efficiently, something I have found lacking in other
loggers.
+ DXKeeper can be optimized for logging already-completed QSOs from a paper log. See
http://www.dxlabsuite.com/dxkeeper/Help/LogCompletedMain.htm
?
The concept of 'propagation mode' is new to me. If I just leave it
disabled are there any issues, I tend not to use repeaters or satellite,
just HF and the occasional FM chat (which may not even reach my logbook..).
+ Unless you're studying propagation or using satellites or planning to enter the CQ DX Marathon, there's no compelling reason to accurately record each QSO's propagation mode. My advice is to set the "Propagation Mode" to F2 on the Configuration window's Defaults tab.
+ If you haven't yet reviewed this article, you may find it useful:
https://www.dxlabsuite.com/dxlabwiki/SwitchingToDXKeeper
? ? ? 73,
? ? ? ? ? ? ?Dave, AA6YQ
|
Re: LOTW - unable to contact server
Many thanks Dave and Tony, changing the TQSL address as suggested has
stopped the irritating start up message. None of us of course expected
the prolonged LOTW outage and ARRL, perhaps understandably, are being
pretty reserved about when it will resume. At least I have plenty of
local backup copies of my log.
A couple of other questions...
Being a QRP operator all my QSOs for the past 20 years have been with
5W. I set this manually on QSO entries but it would be nice in the
configuration to be able to set this en masse rather than separately for
each band and mode. And being a dinosaur I still use paper logs outside
contests and all my day to day QSOs are input post event. DXKeeper seems
to do this fairly efficiently, something I have found lacking in other
loggers.
The concept of 'propagation mode' is new to me. If I just leave it
disabled are there any issues, I tend not to use repeaters or satellite,
just HF and the occasional FM chat (which may not even reach my logbook..).
Thanks for the great program.
73 Dave G3YNC
toggle quoted message
Show quoted text
On 16/06/2024 02:10, Dave AA6YQ wrote: + AA6YQ comments below
Dave G3YMC posted:
New user of DXKeeper, trying it out as a potential move from XMLog which I have used for years. My 87k QSOs imported, eQSL confirmations set up, reading the help files and getting there.
+ Welcome to DXLab, Dave!
Because LOTW is down I am getting a 'cannot contact LOTW server' message at start up. Is there any way to disable that while it remains off? I imagine it is starting up TQSL at start which is pretty pointless at the moment.
+ At startup, DXKeeper directs TQSL to report "LoTW News", which could be the availability of a new version, or the impending expiration of one of your Callsign Certificates.
Tony ON6TM posted:
As Dave wrote in post no. Jun 1 #222683 </g/DXLab/message/222683> :
In the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab, temporarily change the suffix of the TQSL pathname from .exe to .exef
+ I did not anticipate lengthy LoTW outages, and so did not provide an option to disable the automatic "get LoTW News on startup" operation. Changing the TQSL pathname's suffix is a kludge, but it's effective at preventing the 'cannot contact LOTW server' message. Hopefully, LoTW outages won't be come sufficiently frequent to justify adding a new option that controls the "get LoTW News on startup" operation.
73,
Dave, AA6YQ
|
Re: DXKeeper logging a WSJT-X rover's home grid, and not his actual grid
+ AA6YQ comments below
Hi Dave, no I had never worked WB5N before.
And I worked a rare grid this afternoon, same problem.
Editing the grid after is not a big deal as I upload to LOTW weekly (or monthly now!), it's just that I'm worried that I might forget.
I hope to work another rare rover grid tomorrow, maybe I should disable my call book first?
+ Please don't. Leave your settings exactly as they are.
Dave
|
Re: DXKeeper logging a WSJT-X rover's home grid, and not his actual grid
Hi Dave, no I had never worked WB5N before.
And I worked a rare grid this afternoon, same problem.
Editing the grid after is not a big deal as I upload to LOTW weekly (or monthly now!), it's just that I'm worried that I might forget.
I hope to work another rare rover grid tomorrow, maybe I should disable my call book first?
Anyhow, thank you for looking into this. I'm sure it's something I've done wrong, but just can't figure it out.
-Chris VA3ECO
|
QSRE: [DXLab] DXKeeper logging a WSJT-X rover's home grid, and not his actual grid
# More AA6YQ comments below
That EM02 grid does not seem to be getting from WSJT-X to DXKeeper, though the times, mode and call sign do.
+ Do you have a previously-logged QSO with WB5N?
# I just checked: the grid square specified in a previously logged QSO with a station does not replace the grid square specified in a new QSO with that station logged from WSJT-x.
# So that I can see what's going on, please do the following:
1. On the General tab of DXKeeper's Configuration window, check the "Log debugging info" box
2. Terminate DXKeeper
3. Start DXKeeper
4. After you log a QSO via WSJT-X and find that the logged grid square is not what was decoded WSJT-X,
4a. On the General tab of DXKeeper's Configuration window, uncheck the "Log debugging info" box
4b. Attach the errorlog.txt file from your DXKeeper folder to an email message that specifies the Callsign, correct grid, and incorrect grid; then send the message to me via
aa6yq (at) ambersoft.com
# Thanks!
73,
Dave, AA6YQ
|
# More AA6YQ comments below
clearing the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab eliminate the "on startup, DXKeeper isn't connected to Pathfinder" misbehavior?
+ DXKeeper does not use DDE to interoperate with TQSL - it directs Windows to start TQSL with a particular set of command line arguments, and then waits for TQSL to create a file containing the requested results ("news" about a new version or approaching Callsign Certificate expirations). With LoTW not available, TQSL never creates that file; DXKeeper eventually gives up.
+ It's possible that DXKeeper waiting for that file to be created is responsible for the "on startup, DXKeeper isn't connected to Pathfinder" misbehavior on some systems. What happened after you cleared the "TQSL.exe pathname"?
Thanks for such a quick response, Dave.
My DXLab Suite and PF is currently without any hiccup, but I'm going to attempt to recreate the PF hiccup thusly:
1) I reinserted what I had removed weeks ago, the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab and then proceeded to terminate DXLab Launcher and all enabled programs.
2) Restarted the PC.
3) DXLauncher opens all enabled programs.
4) DXKeeper opens and displays only a [CC] in it's titlebar and not what I would expect to see, [CC,PF].
5) A popup window, "DXKeeper: Updates from LoTW" reports, "TQSL is unable to connect LoTW". I acknowledge with an "OK" click and the popup closes.
6) I click on a previously logged entry in the DXKeeper log and focusing on the PF window I see no response there. What I expect to see is the selected callsign's QRZ page.
7) The hiccup has returned. PF will not respond to queries.
7) I close PF, relaunch PF, and now [CC,PF] is displayed on the DXKeeper titlebar.
8) PF works as it should for this session of DXLab Suite. With a reboot, the PF hiccup returns.
--------- Now, to return my system to not having the PF hiccup I follow these steps:
1) I remove the "TQSL.exe pathname" in the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab and proceed to terminate DXLab Launcher and all enabled programs.
2) Restart the PC.
3) DXLauncher opens all enable programs.
4) DXKeeper opens and displays a [CC,PF] in the titlebar as it should for me.
5) There is no popup window warning of LoTW being offline or TQSL difficulties nor of any other potential problem
6) PF responds as it should and has for several weeks now, but only after eliminating the TQSL.exe pathname as cited above. My reasoning for erasing the TQSL.exe pathname? Why launch an executable that cannot work until the LoTW server is restored.
All I know is that this detail has worked for me and once LoTW is restored I'll reinsert the TQSL.exe pathname.
# Many thanks, Joe! Your methodical approach demonstrates that when DXKeeper is not "connected" to Pathfinder at startup, the root cause is likely DXKeeper waiting for TQSL to respond to its "report the LoTW news" query.
# Rather than temporarily clear the TQSL pathname as you report above, I suggest instead making this change in the pathname:
TQSL.exe => TQSL.exef
# This will prevent DXKeeper from directing TQSL to "report the LotW news", but make it easy to restore the correct TQSL pathname after LoTW is again accessible.
Dave, I have not seen the "on startup, DXKeeper isn't connected to Pathfinder" popup. I've been spared that one <whew!>
# There is no such popup; that's just my concise description of the misbehavior.
Oh, and thanks for the clarification about DDE calls and such. You're the program guru. I most certainly am not.
# Nor should you need to be.
73,
Dave, AA6YQ
|
Re: DX Marathon "0 Worked" display
+ AA6YQ comments below
"Include QSOs with no prop"
That was it!! I dont even understand what that means, I will read on.
+ In the "Frequencies and Disallowed Entries " section of
+ you will find this sentence:
"Contacts through repeaters or satellites are not allowed nor are contacts with maritime or aeronautical mobile stations."
+ To exclude QSOs made through repeaters or satellites, DXLab's support for the CQ DX Marathon award considers each logged QSO's "Propagation Mode" item, which is accessible in the "Propagation" panel on the Main window's "Log QSOs" tab.
+ The "Propagation Mode" of a QSO made through a repeater is RPT.
+ The "Propagation Mode" of a QSO made via a satellite is SAT.
+ Only QSOs whose "Propagation Mode" items are set to one of these values are valid for CQ DX Marathon:
AUR - Aurora
AUE - Aurora-E
BS - Back scatter
ES - Sporadic E
FAI - Field Aligned Irregularities
F2 - F2 Reflection
GWAVE - Ground wave
ION - Ionoscatter
LOS - Line of sight
MS - Meteor scatter
RS - Rain scatter
TEP - Trans-equatorial
TR - Tropospheric ducting
+ You can define a default "Propagation Mode" on the Defaults tab of DXKeeper's Configuration window. Most HF operators set this to F2 unless they are temporarily exploiting a different propagation mode like Sporadic E (ES) or Trans-equatorial (TEP); satellite operator would of course set the default propagation mode to SAT during a pass.
+ By checking the "Include QSOs with no prop" box in the "Marathon Bands & Modes" panel, you are asserting that none of your logged QSOs that don't specify a Propagation Mode item were made with a propagation modes that is invalid for CQ DX Marathon.
73,
Dave, AA6YQ
|
Re: LOTW - unable to contact server
+ AA6YQ comments below Dave G3YMC posted: New user of DXKeeper, trying it out as a potential move from XMLog which I have used for years. My 87k QSOs imported, eQSL confirmations set up, reading the help files and getting there. + Welcome to DXLab, Dave! Because LOTW is down I am getting a 'cannot contact LOTW server' message at start up. Is there any way to disable that while it remains off? I imagine it is starting up TQSL at start which is pretty pointless at the moment. + At startup, DXKeeper directs TQSL to report "LoTW News", which could be the availability of a new version, or the impending expiration of one of your Callsign Certificates. Tony ON6TM posted: As Dave wrote in post no. Jun 1 #222683 < /g/DXLab/message/222683> : In the TQSL panel at the bottom of the "QSL Configuration" window's LoTW tab, temporarily change the suffix of the TQSL pathname from .exe to .exef + I did not anticipate lengthy LoTW outages, and so did not provide an option to disable the automatic "get LoTW News on startup" operation. Changing the TQSL pathname's suffix is a kludge, but it's effective at preventing the 'cannot contact LOTW server' message. Hopefully, LoTW outages won't be come sufficiently frequent to justify adding a new option that controls the "get LoTW News on startup" operation. 73, Dave, AA6YQ
|
The online Help files
www.dxlabsuite.com/dxkeeper/Help/SQL.htm (4th paragraph)
and
www.dxlabsuite.com/dxkeeper/Help/Scripts.htm (2nd paragraph)
have been updated with hyperlinks to
www.dxlabsuite.com/dxkeeper/Help/Items.htm
To update your local copies of these two files, direct your web browser to save each one to DXKeeper's Help folder, replacing the existing file with the same name.
Both of these updated files will be included with the next version of DXKeeper.
Thanks Joe!
73,
Dave, AA6YQ
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] [mailto: [email protected]] On Behalf Of Joe Subich, W4TV Sent: Saturday, June 15, 2024 10:20 AM To: [email protected]Subject: Re: [DXLab] List of SQL labels? If you mean fields on which to search, I use the list in Advanced Filters -> Modify QSOs -> Item Name. The complete list appears to be in the Log Items help file (DXKeeper/Help/Items.htm). Unfortunately, there is no reference or link to that file from "Filtering the Log Page Display with SQL" (DXKeeper/Help/SQL.htm) or "Filtering, Modifying, and Reporting with Scripts (DXKeeper/Help/Scripts.htm). 73, ... Joe, W4TV On 6/15/2024 9:57 AM, John P wrote: Dave (or anyone) is there a list somewhere in the DxKeeper documentation that has a list of all the SQL query keywords. Couldn't find one!
Specifically looking for the right expression to add to one of my custom filters to show only QSOs confirmed or verified via LoTW.
--
John P.
WA2FZW
|
Re: DX Marathon "0 Worked" display
Thank you very much for your help.
paul
|
Chuck, WS1L
Dave Sergeant G3YMC