Date   

Re: Commander and DXKeeper sequencing

Ed W2LCQ <w2lcq@...>
 

This discussion is beyond my level of understanding. However I frequently initialize DXK before Commander.  WSJT-X is brought up automatically by my launcher. When I close WSJT-X and bring up Commander, Commander passes frequency to DXK and communicates with DXK without any problems. 

73, de Ed Jones W2LCQ

Frankford Radio Club
BUG CWops SKCC FISTS LICWC QCWA


On Jul 16, 2021, at 4:30 PM, Dave AA6YQ <aa6yq@...> wrote:



+ AA6YQ comments below


On Fri, Jul 16, 2021 at 12:22 PM, Bob - W6OPO wrote:

 I surmise that Commander not running in Administrator mode prevented some communication with DXKeeper at least in one direction. 

+ This was the reason that DXKeeper and Commander weren't interoperating when DXKeeper was started first: Windows would not convey the "I exist" message from Commander to DXKeeper because Commander was running at a lower level of administrative privilege.

+ Most DXLab users let the Launcher install itself and the rest of the DXLab applications in the default folder C:\DXLab which doesn't require giving Administrative privileges to any of the applications. Only if you install DXLab applications in what Windows considers to be a "protected folder", like

c:\program files\x86

+ are administrative privileges required. See

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

        73,

             Dave, AA6YQ


Re: Commander and DXKeeper sequencing

Dave AA6YQ
 

+ AA6YQ comments below


On Fri, Jul 16, 2021 at 12:22 PM, Bob - W6OPO wrote:

 I surmise that Commander not running in Administrator mode prevented some communication with DXKeeper at least in one direction. 

+ This was the reason that DXKeeper and Commander weren't interoperating when DXKeeper was started first: Windows would not convey the "I exist" message from Commander to DXKeeper because Commander was running at a lower level of administrative privilege.

+ Most DXLab users let the Launcher install itself and the rest of the DXLab applications in the default folder C:\DXLab which doesn't require giving Administrative privileges to any of the applications. Only if you install DXLab applications in what Windows considers to be a "protected folder", like

c:\program files\x86

+ are administrative privileges required. See

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

        73,

             Dave, AA6YQ


Re: Commander and DXKeeper sequencing

Bob - W6OPO
 

I sent this to Dave earlier.  Check his comment at the bottom of this message regarding risk.  Important to know.

My message begins:
Fixed- Lets see if I can explain this.  

 

I have this need to have the application programs (execution modules) in one of the two Programs directories in Windows.  As I recall – been a few years since I installed DXLab on this computer – DXLab was to be installed in the root directory.  That went against my training of old so I didn’t.

 

I installed all the DXLab applications in the Programs directory.  But that caused a problem with Windows.  Being in the Program directory all the DXLab applications had to be run as Administrator.  All were but not Commander.  I had been noticing but ignoring when starting Commander I wasn’t getting the Windows interruption asking me if I wanted to proceed.

 

So a few minutes ago I looked at the Compatibility tab in Properties and see I had not checked the box Run as Administrator.  Saving all I then rebooted.  Now it works as it should.  Even if I start DXKeeper first then Commander the CC now shows up in DXKeeper's title bar and the Commander information is passed on to DXKeeper.

 

I surmise that Commander not running in Administrator mode prevented some communication with DXKeeper at least in one direction.  Now it works in either sequence.

 

Although I have been running DXLab this way for years all DXLab application have performed as expected – they all were set to run as Administrator – even Launcher.  BTW - when running Launcher I have to click to proceed responding to Windows challenge.  But I only have to do that once for Launcher.  All programs it starts do so without a Windows challenge.  (All this because I want the programs to reside in the Windows Programs directory - a personal desire)

 

Any comments on this issue of having the programs in the Windows Program directory.  Anything I’m missing?

 

Dave added this in response to my question regarding running apps in Administrator Mode - a high level of authorization.  In Administrator Mode the system allows a program to write to another program - an inherent exposure there.  Just be sure you know what you are doing in regards to risk.  

"+ No, it's perfectly fine to install all of the DXLab apps in what Windows considers a "protected folder" so long as they're all running at the same level of Admin privilege. Any other apps that interoperate with DXLab apps via DDE must obey the same constraint.

 

 

+ From a system security perspective, it's best to minimize the number of apps that have Admin privileges, but unless you manage your finances on the same machine that hosts DXLab, that's likely not a significant issue."

73,
Bob - W6OPO


Re: Telnet Access to IOTA Spots

Dave AA6YQ
 

+ AA6YQ comments below

Is there a telnet address for IOTA spots so I can add them to SpotCollector like I do SOTA?

+ Are you asking if there is a DXCluster that is dedicated to IOTA spots?

+ SpotCollector identifies and extracts IOTA tags in the spot notes of all spot sources; these appear in the Spot Database's IOTA field. Today, for example, EA6/EI6DX is active from EU-004. SOTA and POTA tags are similarly identified and extracted.

73,

Dave, AA6YQ


Telnet Access to IOTA Spots

 

Is there a telnet address for IOTA spots so I can add them to SpotCollector like I do SOTA?  

Bob AF9W


Re: Commander question/request

Dave AA6YQ
 

+ AA6YQ comments below
Please point me at the documentation of the hamlib API that controls the notch filter bandwidth of every transceiver with a CAT-controllable notch filter.


From Hamlib 4.2 API reference

rig_set_mode()

int rig_set_mode ( RIG *  rig,
    vfo_t  vfo,
    rmode_t  mode,
    pbwidth_t  width 
  )    

set the mode of the target VFO

Parameters
rig The rig handle
vfo The target VFO
mode The mode to set to
width The passband width to set to

+ That API control's the radio RX bandwidth. I asked for documentation of the API that controls the notch filter bandwidth.

       73,

             Dave, AA6YQ


Re: Commander question/request

Johnny IZ8EWD
 
Edited

Please point me at the documentation of the hamlib API that controls the notch filter bandwidth of every transceiver with a CAT-controllable notch filter.


From Hamlib 4.2 API reference

rig_set_mode()

int rig_set_mode ( RIG *  rig,
    vfo_t  vfo,
    rmode_t  mode,
    pbwidth_t  width 
  )    

set the mode of the target VFO

Parameters
rig The rig handle
vfo The target VFO
mode The mode to set to
width The passband width to set to


I hope this can help.
Best 73


Re: Memory: Kenwood R-5000

Dave AA6YQ
 

+ AA6YQ comments below
I now feel that I have been squarely Put in My Place
+ No, your suggestion has been put in its place. .

      73,

             Dave, AA6YQ


Re: Memory: Kenwood R-5000

Dave AA6YQ
 

+ AA6YQ comments below

Thanks, I now feel that I have been squarely Put in My Place. Perhaps it is not a "very desirable" feature iff 1) you measure desirability by popularity

+ I measure it by value to DXLab's target users

and 2) if you are only considering 'working DX' from a base-station that has plenty of workspace

+ That's what most DXers do.

and 3) your trusty tower-of-power computer is right there, plugged into the wall outlet

+ That's what most DXers do.

.But, that is not the case for someone operating emergency-service comms from a remote location with NO mains power; possibly also a shortfall of fuel to run an AC generator 24/7.

+ That's not what most DXers do, or what the DXLab Suite aims to support.

Why not have the capability of writing to the on-board memory of the transceiver or receiver?

+ Because the time spent implementing it would be time not spent implementing far more valuable new capabilities; in product management, this concept is referred to as "opportunity cost".

That write-to functionality is inherent in the R-5000 and (without recourse to the specifications of other receivers / transceivers...), I suspect it's true of many other radios.

+ It's true of some but certainly not all radios.  Worse, Elecraft, FlexRadio, Icom, Kenwood, TenTec, and Yaesu all implement memories differently, and thus unique code is required for each approach (and testing, and documentation). Commander provides memories for all transceivers, whether they provide "hardware support" or not. And those memories remain accessible when the user switches from one primary transceiver to another.

+ You are proposing that a large amount of time be spent building, testing, and documenting something that is inferior to what's already provided to support a usage scenario (no computer, emergency service) that is far outside DXLab's target: Dxers primary, and general operators secondarily.

+ DXLab explicitly does not target contesting. It also does not target emergency communications.

+ If you're seeking transceiver control for emergency communications, DXLab is the wrong choice.

         73,

                 Dave, AA6YQ


Re: Commander and DXKeeper sequencing

Bob - W6OPO
 

Dave -
Done - error log file sent separately.
73,
Bob - W6OPO


Re: Memory: Kenwood R-5000

lynx@...
 

Thanks, I now feel that I have been squarely Put in My Place. Perhaps it is not a "very desirable" feature iff 1) you measure desirability by popularity, and 2) if you are only considering 'working DX' from a base-station that has plenty of workspace and 3) your trusty tower-of-power computer is right there, plugged into the wall outlet.

But, that is not the case for someone operating emergency-service comms from a remote location with NO mains power; possibly also a shortfall of fuel to run an AC generator 24/7.

Why not have the capability of writing to the on-board memory of the transceiver or receiver? That write-to functionality is inherent in the R-5000 and (without recourse to the specifications of other receivers / transceivers...), I suspect it's true of many other radios.



Re: Memory: Kenwood R-5000

Dave AA6YQ
 

+ AA6YQ comments below

When looking into Commander's capabilities, it said that it had 100 memories in 10 banks (10x10). This coincides with the memory on-board the R-5000 and, it seemed sensible and intuitive that Commander could be used to easily upload up to 100 memory location's worth of settings from a Text or CSV-type of file, to the memory of my Kenwood R-5000 with just a few key strokes. That task having been done, one would not always need the connection to a computer and to use Commander ---- one could simply make use of the on-board memories.

This was desirable, particularly during mobile and emergency operations when carrying and putting additional reliance on a PC isn't sensible.

Perhaps I am missing something, but this very desirable function seems to be lacking. I can change the frequency and VFO (A vs B) and mode (FM, AM...etc). Perhaps someone can explain what, if anything, I am missing here.

+ Commander provides 10 banks of 10 memories for all supported transceivers; these memories remain accessible when Commander is switched from one primary transceiver to another. These capability rule out relying on the memories that some transceivers provide.

+ Most DXers do not use files that specify large numbers of frequencies, as shortwave listeners might do. They save frequencies on an ad hoc basis, e.g. for a sked or a net or to be able to monitor a frequency on which needed DX is may appear.

+ DXLab users all have computers, and most run Commander to control their transceivers and provide the other DXLab applications with access to the transceiver. Being able to use a transceiver without a computer is not useful.

+ In summary, what you characterize as a "very desirable function" isn't, at least for most DXLab users.

           73,

                   Dave, AA6YQ

 


Memory: Kenwood R-5000

lynx@...
 


-------- Original Message --------

Subject: Memory: Kenwood R-5000
Date: 2021-07-15 18:59
From: lynx@...
To: DXLab@groups.io



When looking into Commander's capabilities, it said that it had 100 memories in 10 banks (10x10). This coincides with the memory on-board the R-5000 and, it seemed sensible and intuitive that Commander could be used to easily upload up to 100 memory location's worth of settings from a Text or CSV-type of file, to the memory of my Kenwood R-5000 with just a few key strokes. That task having been done, one would not always need the connection to a computer and to use Commander ---- one could simply make use of the on-board memories.

This was desirable, particularly during mobile and emergency operations when carrying and putting additional reliance on a PC isn't sensible.

Perhaps I am missing something, but this very desirable function seems to be lacking. I can change the frequency and VFO (A vs B) and mode (FM, AM...etc). Perhaps someone can explain what, if anything, I am missing here.

Mike G



Re: Commander and DXKeeper sequencing

Dave AA6YQ
 

+ AA6YQ comments below

I know all DXLab applications know each other is there and "talk" to each other. But I have found when not using Launcher, starting selected applications manually that Commander has to start first before DXKeeper. If DXKeeper is started before Commander DXKeeper doesn't get the frequency information for Capture.

+ I just tested that scenario here, and the Capture window correctly displays my transceiver frequency when I enter a callsign and strike the Enter key.

+ 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. Terminate Commander

4. Start DXKeeper, and wait for it to fully initialize

5. Start Commander, and wait for it to fully initialize

6. Type my callsign in the Capture window's Call box, and strike the Enter key

7. Wait 15 seconds

8. On the General tab of DXKeeper's Configuration window, uncheck the "Log debugging info" box

9. Attach the errorlog.txt file from your DXKeeper folder to an email message, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Commander and DXKeeper sequencing

Bob - W6OPO
 

I know all DXLab applications know each other is there and "talk" to each other.  But I have found when not using Launcher, starting selected applications manually that Commander has to start first before DXKeeper.  If DXKeeper is started before Commander DXKeeper doesn't get the frequency information for Capture.

Anyone else notice that?

73,
Bob -W6OPO


Re: DX Keeper capture question

Dave AA6YQ
 

On Thu, Jul 15, 2021 at 03:29 PM, Ryan Trullinger (KC0QNB) wrote:
Can I change the caption on the button now named "other" in the progress reports>other reports to POTA in the Check Progress tab?
+ That button is not rename-able because it is used to access up to 8 progress reports.

      73,

           Dave, AA6YQ


Re: DX Keeper capture question

Ryan Trullinger (KC0QNB)
 

Thanks I got those things working, which generated a new question. Can I change the caption on the button now named "other" in the progress reports>other reports to POTA in the Check Progress tab?


Re: DX Keeper capture question

Dave AA6YQ
 

+ AA6YQ comments below

You can find more about DXLab support for POTA by doing a search on the DXLab wiki.

Go to the DXLab wiki: http://www.dxlabsuite.com/dxlabwiki/TitleIndex

In upper right corner Search Box, type in POTA and strike return key.

 

There is an article about POTA that may provide more help for you.

+ Mark AA3K contributed the article; it's here:

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

      73,

              Dave, AA6YQ

 


Re: DX Keeper capture question

w6de
 

You can find more about DXLab support for POTA by doing a search on the DXLab wiki.

Go to the DXLab wiki: http://www.dxlabsuite.com/dxlabwiki/TitleIndex

In upper right corner Search Box, type in POTA and strike return key.

 

There is an article about POTA that may provide more help for you.

 

73,

Dave, w6de

 

From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Ryan Trullinger (KC0QNB) via groups.io
Sent: Thursday, July 15, 2021 18:45
To: DXLab@groups.io
Subject: [DXLab] DX Keeper capture question

 

I decided to try using the QSL message/Comment box to make a note like "POTA K-3615", is this the best approach for this kind of thing? I see there is dedicated SOTA text box.


DX Keeper capture question

Ryan Trullinger (KC0QNB)
 

I decided to try using the QSL message/Comment box to make a note like "POTA K-3615", is this the best approach for this kind of thing? I see there is dedicated SOTA text box.

7821 - 7840 of 210242