Date   

Re: Disappearing QSOs

Dave AA6YQ
 

+ AA6YQ comments below

All of my DXlab apps are up to date according to Launcher. In particular DXKeeper is 16.1.9.

This afternoon I working some FT8 on several bands and decided to check to see how many new QSOs I had to upload to LoTW. I went to the QSL tab and instructed it to Add Requested. 33 QSOs were added to the queue. I then clicked on the LOG QSOs tab and noticed the QSOs were no longer in the log display. I then went back to the QSL tab and uploaded the QSOs to LoTW. They were all uploaded but when I did a synch qsos after they showed up on LoTW the report showed that none of the QSOs were in the log. They are OK on LoTW but not in my DXK log.

So I have two questions. First I want to figure out what happened to the QSOs so I can avoid having it happen again. Secondly, I need to find out how down load the affected QSOs from LoTW and import them in to DXK. The DXK error log contains no recent entries.

+ The QSOs in question all remain present in Paul's log; evidently, the Log Page Display was filtered in a way that hid them.

73,

Dave, AA6YQ


an updated USAP database is available...

Dave AA6YQ
 

...via the Databases tab of DXView's Configuration window. If you have DXKeeper or SpotCollector running, terminate them; then
direct DXView to upgrade its USAP database.

The USAP database specifies a US State and Grid Square for 836,680 stations licensed by the US Federal Communications Commission
(FCC).

Many thanks to Tom KQ5S for preparing this update!

73,

Dave, AA6YQ


Re: Disappearing QSOs

Dave AA6YQ
 

+ AA6YQ comment below
Sorry, I forgot to mention that I had done that. I always do a ctrl click when I go back to the Log Qsos tab.
+ OK. Please place your log file (suffix .mdb) in a zip archive, attach the zip archive to an email message that describes the date/time-range or QSOs that are missing, and send the message to me via

aa6yq (at) ambersoft.com

      73,

            Dave, AA6YQ


Re: Disappearing QSOs

Paul W5PF
 

Sorry, I forgot to mention that I had done that. I always do a ctrl click when I go back to the Log Qsos tab.

Paul W5PF


On 7/16/2021 6:34 PM, Dave AA6YQ wrote:

+ AA6YQ comments below
All of my DXlab apps are up to date according to Launcher. In particular DXKeeper is 16.1.9.

This afternoon I working some FT8 on several bands and decided to check to see how many new QSOs I had to upload to LoTW. I went to the QSL tab and instructed it to Add Requested. 33 QSOs were added to the queue. I then clicked on the LOG QSOs tab and noticed the QSOs were no longer in the log display. I then went back to the QSL tab and uploaded the QSOs to LoTW. They were all uploaded but when I did a synch qsos after they showed up on LoTW the report showed that none of the QSOs were in the log. They are OK on LoTW but not in my DXK log.

So I have two questions. First I want to figure out what happened to the QSOs so I can avoid having it happen again. Secondly, I need to find out how down load the affected QSOs from LoTW and import them in to DXK. The DXK error log contains no recent entries.
+ As a first step, please click the X button in the Filter panel at the bottom of the Main window's "Log QSOs" tab. Did your missing QSOs re-appear?

        73,

             Dave, AA6YQ


Re: Disappearing QSOs

Dave AA6YQ
 

+ AA6YQ comments below
All of my DXlab apps are up to date according to Launcher. In particular DXKeeper is 16.1.9.

This afternoon I working some FT8 on several bands and decided to check to see how many new QSOs I had to upload to LoTW. I went to the QSL tab and instructed it to Add Requested. 33 QSOs were added to the queue. I then clicked on the LOG QSOs tab and noticed the QSOs were no longer in the log display. I then went back to the QSL tab and uploaded the QSOs to LoTW. They were all uploaded but when I did a synch qsos after they showed up on LoTW the report showed that none of the QSOs were in the log. They are OK on LoTW but not in my DXK log.

So I have two questions. First I want to figure out what happened to the QSOs so I can avoid having it happen again. Secondly, I need to find out how down load the affected QSOs from LoTW and import them in to DXK. The DXK error log contains no recent entries.
+ As a first step, please click the X button in the Filter panel at the bottom of the Main window's "Log QSOs" tab. Did your missing QSOs re-appear?

        73,

             Dave, AA6YQ


Disappearing QSOs

Paul W5PF
 

All of my DXlab apps are up to date according to Launcher. In particular DXKeeper is 16.1.9.

This afternoon I working some FT8 on several bands and decided to check to see how many new QSOs I had to upload to LoTW. I went to the QSL tab and instructed it to Add Requested. 33 QSOs were added to the queue. I then clicked on the LOG QSOs tab and noticed the QSOs were no longer in the log display. I then went back to the QSL tab and uploaded the QSOs to LoTW. They were all uploaded but when I did a synch qsos after they showed up on LoTW the report showed that none of the QSOs were in the log. They are OK on LoTW but not in my DXK log.

So I have two questions. First I want to figure out what happened to the QSOs so I can avoid having it happen again. Secondly, I need to find out how down load the affected QSOs from LoTW and import them in to DXK. The DXK error log contains no recent entries.


Thanks,

Paul W5PF


Re: Commander and DXKeeper sequencing

Ed W2LCQ
 

Dave and Bob,

Thanks for taking the time and having the patience for those very complete explanations. I converted all my logs to DXL last year and haven’t looked back. DXL got me DXCC and WAS. I appreciate the ingenuity and creativity that made these interoperable programs a reality and enjoy using them every day. 

73, de Ed Jones W2LCQ

Frankford Radio Club
BUG CWops SKCC FISTS LICWC QCWA


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

 + AA6YQ comments below

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. 

+ The 8 DXLab applications are designed so that they can be started in any order, and will still succeed at identifying each other's presence and interoperating without operator intervention. I made this claim during a presentation to the Northern California DX Club last night. After the presentation, Bob W6OPO reported that on his system, DXKeeper and Commander only interoperated  if Commander was started first. I requested an errorlog.txt file, which showed that on his system, when DXKeeper was started first, it never received the "I'm alive" message from Commander. That's because Bob had 7 of his 8 DXLab applications configured to run with Administrator privileges -- required because he has them installed in a folder that Windows considers "protected", but did not have Commander configured to run with Administrator privileges. The security policy implemented on Windows means that a message sent by an application without Administrator privileges can't be delivered to an application with Administrator privileges; this is why Commander's "I'm alive" message was not delivered to DXKeeper. Starting Commander with Administrator privileges.

+ Installing the Launcher and its applications in a folder that Windows doesn't consider "protected" - like the default c:\DXLab - means that no DXLab applications need Administrator privileges in order to interoperate with their peers.

+ Note that the "you can start them in any order" property may not apply to non-DXLab applications that interoperate with DXLab applications.

      73,

             Dave, AA6YQ

 

 


Re: Group date change

Dave AA6YQ
 

+ AA6YQ comments below

Somehow, I screwed up on a CWT mini contest through N1MM this last Thursday, 7/14/2021. Somehow, all of the QSOs are dated 7/13 instead of 7/14 and I didn't notice it until I imported the .ADI file into DXkeeper. I need to do a group date change. I assume that has to be done using the Advanced Sorts, Filters, and Modifiers tab. I've looked at that and the wiki instructions but I am uncertain as to how to set up the change.

+ First, backup your log (Configuration window, Log tab, Backup button)

+ Next, filter the Log Page Display to contain only the QSOs whose dates are incorrect

+ Then user the "Modify QSOs" panel to correct the QSO_Begin and QSO_End fields by adding 24 hours to each. The 9th bullet in the "Using the Modify QSOs panel" section of

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

+ explains how to do this.

+ Note that articles in "Getting Started with DXLab" - aka "the Wiki" - provide step-by-step instructions for frequent usage scenarios, but do not provide a comprehensive description of all available functionality. For the latter, refer to the Reference documentation.

73,

Dave, AA6YQ


Group date change

Marv Stasak
 

Dave,
 Somehow, I screwed up on a CWT mini contest through N1MM this last Thursday, 7/14/2021. Somehow, all of the QSOs are dated 7/13 instead of 7/14 and I didn't notice it until I imported the .ADI file into DXkeeper.  I need to do a group date change.  I assume that has to be done using the Advanced Sorts, Filters, and Modifiers tab. I've looked at that  and the wiki instructions but I am uncertain as to how to set up the change.

73,

Marv, W5DT


Re: Commander and DXKeeper sequencing

Dave AA6YQ
 

 + AA6YQ comments below

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. 

+ The 8 DXLab applications are designed so that they can be started in any order, and will still succeed at identifying each other's presence and interoperating without operator intervention. I made this claim during a presentation to the Northern California DX Club last night. After the presentation, Bob W6OPO reported that on his system, DXKeeper and Commander only interoperated  if Commander was started first. I requested an errorlog.txt file, which showed that on his system, when DXKeeper was started first, it never received the "I'm alive" message from Commander. That's because Bob had 7 of his 8 DXLab applications configured to run with Administrator privileges -- required because he has them installed in a folder that Windows considers "protected", but did not have Commander configured to run with Administrator privileges. The security policy implemented on Windows means that a message sent by an application without Administrator privileges can't be delivered to an application with Administrator privileges; this is why Commander's "I'm alive" message was not delivered to DXKeeper. Starting Commander with Administrator privileges.

+ Installing the Launcher and its applications in a folder that Windows doesn't consider "protected" - like the default c:\DXLab - means that no DXLab applications need Administrator privileges in order to interoperate with their peers.

+ Note that the "you can start them in any order" property may not apply to non-DXLab applications that interoperate with DXLab applications.

      73,

             Dave, AA6YQ

 

 


Re: Commander and DXKeeper sequencing

Bob - W6OPO
 

Works Ed because you are not running DXLab's apps from a protected directory like Program Files or Program Files (x86).  Using DXLab's Launcher and installing the programs in the default directory avoids all this.

73,
Bob - W6OPO


Re: Commander and DXKeeper sequencing

Ed 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

8781 - 8800 of 211213