Date   

Re: Spotcollector versus Capture&Commander

eddy on5jk
 

Bingo!!

I did set set my "doubleclick speed" a little bit lower, and for the time being it seems to cure the failure.

I tested about 40 doubleclicks, all work fine.

However, don't see why it happened, because i did not change settings anywhere.

Is it possible that an update of Win10 changed a setting?

Future will show if i can be happy again.

Thanks Dave!

Eddy ON5JK

Op 15/06/2021 om 19:29 schreef Dave AA6YQ:

+ AA6YQ comments below
When i doubleclick a spot entry, most of the time it works normal, setting DXV, Capture, DXK and Commander the normal way. Once and then, it is not: when i doubleclick on an entry, the blinking cursor(I) remains on the place i clicked, middle of the Callsign. It does not return into an arrow, no other App is following.

When i repeat my action, doubleclicking on the same spot entry, often all Apps do follow as they should.

+ Perhaps your action with your mouse is not being interpreted as a "double-click". If SpotCollector's Main window is not activated, left-click in its title bar before you attempt to double-click on a Spot Database Entry; does that make the double-click operation reliable?

 + Also, check your mouse configuration options in Windows, and set the "double-click interval" to one that reliably results in a double-click.

         73,

               Dave, AA6YQ

 


Re: Spotcollector versus Capture&Commander

Dave AA6YQ
 

+ AA6YQ comments below
When i doubleclick a spot entry, most of the time it works normal, setting DXV, Capture, DXK and Commander the normal way. Once and then, it is not: when i doubleclick on an entry, the blinking cursor(I) remains on the place i clicked, middle of the Callsign. It does not return into an arrow, no other App is following.

When i repeat my action, doubleclicking on the same spot entry, often all Apps do follow as they should.

+ Perhaps your action with your mouse is not being interpreted as a "double-click". If SpotCollector's Main window is not activated, left-click in its title bar before you attempt to double-click on a Spot Database Entry; does that make the double-click operation reliable?

 + Also, check your mouse configuration options in Windows, and set the "double-click interval" to one that reliably results in a double-click.

         73,

               Dave, AA6YQ

 


Re: Spotcollector versus Capture&Commander

eddy on5jk
 

Dave i'm sorry, but i feel a little bit leaved behind and/or guilty.

For so many years all Apps of XLab where working fine. That's why i promoted the DXLabsuite to several local OM's.

I did not change any setting. Digital mode application is not used or connected. WW is not started.

When i doubleclick a spot entry, most of the time it works normal, setting DXV, Capture, DXK and Commander the normal way. Once and then, it is not: when i doubleclick on an entry, the blinking cursor(I) remains on the place i clicked, middle of the Callsign. It does not return into an arrow, no other App is following.

When i repeat my action, doubleclicking on the same spot entry, often all Apps do follow as they should.

Sometimes (rare) i have to click for a third time.

Doubleclicking in the first column will always work, but disabels the Autoscrolling.

Is it me? Is it my computer? Is it something else? Remember i am to old for being an ITer.

Can an ErrorLog help me? Of coarse the ErrorLog will show several normal actions, and a missing one sometimes.

If it happens to be my Computer, can somebody help me please? Thanks a lot.

Eddy ON5JK


.9/06/2021 om 11:27 schreef Dave AA6YQ:

+ AA6YQ comments below

Starting 06/06/2021 i noticed a strange fenomena.

I used to D-click on a spotted Callsign, near the middel of the Callsign. Normally the arrow of the mouse changes into a cursor, blinking most left of the spotted Callsign,second Column. Then Capture is populated with all info, and Commander is following as it should do.
Then the cursor stops blinking, and the black arrow in the most left column moves to the latest spot received.

It happens sometime, that after D-clicking on the spotted Callsign, the blinking cursor is not placed left of the Callsign, but stays in the middel of the Callsign, exactly on the place i D-clicked. Capture and Commander are not following. The black arrow in the left most column then stays near the clicked callsign for a very long time.

Strange, but sometimes after minutes, or after selecting another spotted Callsign, and then D-clicking again on the earlier spot, all things went to normal.

+ Whether or not the Capture window is populated from the information in a double-clicked Spot Database Entry depends on the Entry's Mode, whether or not a digital mode application is "connected", and the settings in the "Actions with Digital Mode Application connected" panel on the Configuration window's General tab, as described in

https://www.dxlabsuite.com/spotcollector/Help/ConfigurationGeneral.htm#Phone%20Modes%20Panel

73,

Dave, AA6YQ





Re: Solarhistory.txt how does it work?

g4wjs
 

On 15/06/2021 12:11, Komkit Listisard via groups.io wrote:
Thanks Bill,  I will try that when I get a chance.

Assuming I would put the command in the CMD field in the spot sources Telnet DXCluster settings.

73, Kit
Hi Kit,

yes but it needs some escaped control characters as well to enter it. It is all in the following article:

http://www.dxlabsuite.com/dxlabwiki/CollectingSpots



--
73

Bill

G4WJS.


Re: Solarhistory.txt how does it work?

Komkit Listisard
 

Thanks Bill,  I will try that when I get a chance.

Assuming I would put the command in the CMD field in the spot sources Telnet DXCluster settings.

73, Kit


Re: Solarhistory.txt how does it work?

g4wjs
 

On 15/06/2021 11:29, Komkit Listisard via groups.io wrote:
Looks like I only see 1 line in the file, there were no history to speak off.  Seem like there was a new line every time I run SC but there was no history.

Does SC depends on another application in order to have a history? Or some option in the SC that I need to enable it?

73, Kit

Hi Kit,

I believe is is summary data extracted from WWV reports broadcast by the DX Cluster nodes you have SpotCollector connected to. Personally I have a user defined command that is sent to each DX Cluster I connect to which sends:

sh/wwv/200

This populates the Solar data in case I have not run SpotCollector for a while. New WWV reprots are added automatically as they are posted (every three hours I think).

The startup commands and suggestions are documented in the SpotCollector manual.


--
73

Bill

G4WJS.


Solarhistory.txt how does it work?

Komkit Listisard
 

Looks like I only see 1 line in the file, there were no history to speak off.  Seem like there was a new line every time I run SC but there was no history.

Does SC depends on another application in order to have a history? Or some option in the SC that I need to enable it?

73, Kit


Re: LoTW Status changes

Dave AA6YQ
 

+ AA6YQ comments below
BINGO to #3!   I exported Qs using the "ADIF for LoTW" in order to import into WG7J's GridMapper program.  Won't do that again!  Should've known....

+ That behavior is documented here:

https://www.dxlabsuite.com/dxkeeper/Help/Export.htm#Exporting%20to%20LotW

       73,

              Dave, AA6YQ


Re: wsjt-x+jtalert+DXLab - an incomplete story ..

Joe Subich, W4TV
 

@ At minimum, automatically directly WSJT-X to change configurations
when a new transceiver is selected in Commander would be controlled
by a checkbox for each primary transceiver. Disabling all 4 of those
checkboxes would yield the behavior we have today.
I suppose I could rename my "HF-6M" configuration with the rig name
and have it selected when changing rigs. Would simply need to select
one of the alternate configurations after selecting the rig, if needed
(for example to chase a F/H station).

73,

... Joe, W4TV


On 2021-06-14 8:26 PM, Dave AA6YQ wrote:
@ more AA6YQ comments below

The rule would be "name each radio configuration in WSJT-X to match
> the radio name you specified in Commander".
That is problematic. For example, I have multiple configurations in WSJTX ... in particular, I already have a general HF/6M configuration,
a "hound" configuration, a meteor scatter (MSK144), configuration, a Q65 configuration (6m), an FST4 configuration for 160, and a VHF contest
configuration.
At the least, it would require some kind of blended configuration to support both transceiver selection and "operating/mode" selection.
@ At minimum, automatically directly WSJT-X to change configurations when a new transceiver is selected in Commander would be controlled by a checkbox for each primary transceiver. Disabling all 4 of those checkboxes would yield the behavior we have today. I don't know how to do better than that when there's not a one-to-one relationship between primary transceivers and WSJT-X Configurations.
73,
Dave, AA6YQ


Re: LoTW Status changes

Steve - N3SL
 

Thanks, Dave.

BINGO to #3!   I exported Qs using the "ADIF for LoTW" in order to import into WG7J's GridMapper program.  Won't do that again!  Should've known....

73,
Steve

On Mon, Jun 14, 2021 at 7:57 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

This is NOT a problem, just an "interesting" happening - twice now....

Saved my log last evening, as usual.  This morning, went to "sync LoTW QSOs" (and as we know, LoTW was refusing requests for a while this monring).  Later in the day noticed my latest QSOs still showing "U" (not unexpected), but then noticed further up my log other entries also were showing "U" - even if already confirmed by LoTW.  Ran a query on LoTW_QSL-Sent = "U" and got 1563 QSOs listed, all the way back the beginning of my log.  Easy enough to modify, but this is the second time this has happened.  No idea HOW I managed to do it, or exactly what gremlin did it.  Just an observation, and curious as to why/how....

+ The only ways DXKeeper can set a QSO's "LoTW QSL Sent" item to 'U' are

1. initially logging that QSO when DXKeeper is configured to automatically upload each newly-logged QSO to LoTW

2. directing DXKeeper to upload that already-logged QSO to LotW

3. directing DXKeeper to export that already-logged QSO to an ADIF file when the "Export ADIF for LoTW" option is enabled on the Main window's "Export QSOs" tab

4. using the Main window's "Log QSOs" tab to directly change the QSO's "LoTW QSL Sent" item to 'U'

5. using the "Advanced Sorts, Filters, and Modifiers" window's "Modify QSOs" panel to change that QSO's "LoTW QSL Sent" item to 'U'

      73,

            Dave, AA6YQ








Re: LoTW Status changes

Dave AA6YQ
 

+ AA6YQ comments below

This is NOT a problem, just an "interesting" happening - twice now....

Saved my log last evening, as usual. This morning, went to "sync LoTW QSOs" (and as we know, LoTW was refusing requests for a while this monring). Later in the day noticed my latest QSOs still showing "U" (not unexpected), but then noticed further up my log other entries also were showing "U" - even if already confirmed by LoTW. Ran a query on LoTW_QSL-Sent = "U" and got 1563 QSOs listed, all the way back the beginning of my log. Easy enough to modify, but this is the second time this has happened. No idea HOW I managed to do it, or exactly what gremlin did it. Just an observation, and curious as to why/how....

+ The only ways DXKeeper can set a QSO's "LoTW QSL Sent" item to 'U' are

1. initially logging that QSO when DXKeeper is configured to automatically upload each newly-logged QSO to LoTW

2. directing DXKeeper to upload that already-logged QSO to LotW

3. directing DXKeeper to export that already-logged QSO to an ADIF file when the "Export ADIF for LoTW" option is enabled on the Main window's "Export QSOs" tab

4. using the Main window's "Log QSOs" tab to directly change the QSO's "LoTW QSL Sent" item to 'U'

5. using the "Advanced Sorts, Filters, and Modifiers" window's "Modify QSOs" panel to change that QSO's "LoTW QSL Sent" item to 'U'

73,

Dave, AA6YQ


LoTW Status changes

Steve - N3SL
 

This is NOT a problem, just an "interesting" happening - twice now....

Saved my log last evening, as usual.  This morning, went to "sync LoTW QSOs" (and as we know, LoTW was refusing requests for a while this monring).  Later in the day noticed my latest QSOs still showing "U" (not unexpected), but then noticed further up my log other entries also were showing "U" - even if already confirmed by LoTW.  Ran a query on LoTW_QSL-Sent = "U" and got 1563 QSOs listed, all the way back the beginning of my log.  Easy enough to modify, but this is the second time this has happened.  No idea HOW I managed to do it, or exactly what gremlin did it.  Just an observation, and curious as to why/how....

Steve, N3SL


Re: wsjt-x+jtalert+DXLab - an incomplete story ..

Dave AA6YQ
 

@ more AA6YQ comments below

The rule would be "name each radio configuration in WSJT-X to match
> the radio name you specified in Commander".

That is problematic. For example, I have multiple configurations in WSJTX ... in particular, I already have a general HF/6M configuration,
a "hound" configuration, a meteor scatter (MSK144), configuration, a Q65 configuration (6m), an FST4 configuration for 160, and a VHF contest
configuration.


At the least, it would require some kind of blended configuration to support both transceiver selection and "operating/mode" selection.

@ At minimum, automatically directly WSJT-X to change configurations when a new transceiver is selected in Commander would be controlled by a checkbox for each primary transceiver. Disabling all 4 of those checkboxes would yield the behavior we have today. I don't know how to do better than that when there's not a one-to-one relationship between primary transceivers and WSJT-X Configurations.

73,

Dave, AA6YQ


Re: wsjt-x+jtalert+DXLab - an incomplete story ..

Joe Subich, W4TV
 

On 2021-06-14 6:45 PM, Dave AA6YQ wrote:
The rule would be "name each radio configuration in WSJT-X to match the radio name you specified in Commander".
Dave,

That is problematic. For example, I have multiple configurations in
WSJTX ... in particular, I already have a general HF/6M configuration,
a "hound" configuration, a meteor scatter (MSK144), configuration, a
Q65 configuration (6m), an FST4 configuration for 160, and a VHF contest
configuration.

At the least, it would require some kind of blended configuration to
support both transceiver selection and "operating/mode" selection.

73,

... Joe, W4TV


On 2021-06-14 6:45 PM, Dave AA6YQ wrote:
+ AA6YQ comments below


that is certainly possible, UDP message SwitchConfiguration(14) will
switch a specified WSJT-X client to the named configuration if it exists.
It would need a rather loosely coupled setup where the user would be
responsible for creating the configurations that
Commander/SpotCollector/SC_WSJTX might switch to
+ Thanks Bill! I'll look for the SwitchConfiguration(14) documentation . The rule would be "name each radio configuration in WSJT-X to match the radio name you specified in Commander".
73,
Dave, AA6YQ


Re: wsjt-x+jtalert+DXLab - an incomplete story ..

g4wjs
 

On 14/06/2021 23:45, Dave AA6YQ wrote:
+ AA6YQ comments below
that is certainly possible, UDP message SwitchConfiguration(14) will switch a specified WSJT-X client to the named configuration if it exists. It would need a rather loosely coupled setup where the user would be responsible for creating the configurations that Commander/SpotCollector/SC_WSJTX might switch to

+ Thanks Bill! I'll look for the SwitchConfiguration(14) documentation . The rule would be "name each radio configuration in WSJT-X to match the radio name you specified in Commander".

         73,

                Dave, AA6YQ

Hi Dave,

the documentation is here: https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/Network/NetworkMessage.hpp#l470 .

I should point out that the WSJT-X way of supporting multiple radios is to use multiple instances of WSJT-X, of course that gets complicated if using Commander for proxy rig control is required since only one instance of WSJT-X can expect to use Commander to control the DX Lab Suite primary rig.

I don't know if SC_WSJTX and SpotCollector work with multiple instances of WSJT-X, I suspect they do as you have used plural terminology with respect to that. There should be no problem with having one rig controlled by Commander one or more others each directly controlled by separate WSJT-X instances. I know JTAlert supports such configurations and is able to route logged QSOs through to DXKeeper.

There are many possible ways to achieve multiple rig setups, users need to work out which has the least limitations for their desired modus operandi.


--
73

Bill

G4WJS.


Re: wsjt-x+jtalert+DXLab - an incomplete story ..

Dave AA6YQ
 

+ AA6YQ comments below
that is certainly possible, UDP message SwitchConfiguration(14) will switch a specified WSJT-X client to the named configuration if it exists. It would need a rather loosely coupled setup where the user would be responsible for creating the configurations that Commander/SpotCollector/SC_WSJTX might switch to

+ Thanks Bill! I'll look for the SwitchConfiguration(14) documentation . The rule would be "name each radio configuration in WSJT-X to match the radio name you specified in Commander".

         73,

                Dave, AA6YQ


Re: wsjt-x+jtalert+DXLab - an incomplete story ..

Joe Subich, W4TV
 

Bill,

what are you hoping to gain over and above the existing Commander
multi-radio support that allows you to switch between a pre-configured
set of radios?
There are times that the sound device must be changed in concert with
changing the primary radio. At present, it is not possible to change
audio endpoints in WSJTX in concert with changing the primary radio
in Commander.

One must, at a minimum, create separate "Configurations" in WSJTX
(for each transceiver) and select the appropriate configuration
(audio endpoints) in WSJTX at the same time as one changes primary
radios in Commander. AA6YQ has resolved this issue for RTTY/PSK31
operation with WinWarbler by providing "multi-radio" support in
WinWarbler that selects audio endpoints (along with Winkey and PTT
port selection) based on the Primary transceiver selected in
Commander.

73,

... Joe, W4TV


On 2021-06-14 6:22 PM, g4wjs wrote:
On 14/06/2021 22:52, Peter Laws / N5UWY wrote:
+ Conceptually, you could configure one instance of WSJT-X to use Commander to control one transceiver, and configure the second instance of WSJT-X to control your second transceiver directly.Whether any of the other plumbing can be made to work with this configuration, I can't say because you'd be outside the DXLab "one primary transceiver at a time" envelope.
I'm quite content to have different workspaces for the two radios and
was headed in that direction when W10 got me sidetracked.

What is the "easy" way to duplicate an existing workspace?  I'd like
to duplicate my "full" workspace that I use with my 746 to use with my
910.  I have another stripped down "lite" workspace that I use with
the 746 when I don't need (or want) PF, SC, WW, and CwGet, and MMTTY
and ... but just want Commander and DXKeeper and WSJT-X but for the
new workspace, I want to start with everything and then pare back.
Hi Peter,
what are you hoping to gain over and above the existing Commander multi-radio support that allows you to switch between a pre-configured set of radios? Just checking an radio name in a group of radio buttons seems far easier than switching workspaces.


Re: wsjt-x+jtalert+DXLab - an incomplete story ..

g4wjs
 

On 14/06/2021 23:31, Dave AA6YQ wrote:
+ AA6YQ comments below
what are you hoping to gain over and above the existing Commander multi-radio support that allows you to switch between a pre-configured set of radios? Just checking an radio name in a group of radio buttons seems far easier than switching workspaces.

+ It would be nice if selecting a primary transceiver in Commander caused WSJT-X to automatically choose the correct (pre-configured) configuration for that transceiver. That would require extending Commander to send a message to WSJT-X when the selected primary transceiver changes.

     73,

             Dave, AA6YQ

Hi Dave,

that is certainly possible, UDP message SwitchConfiguration(14) will switch a specified WSJT-X client to the named configuration if it exists. It would need a rather loosely coupled setup where the user would be responsible for creating the configurations that Commander/SpotCollector/SC_WSJTX might switch to.


--
73

Bill

G4WJS.


Re: wsjt-x+jtalert+DXLab - an incomplete story ..

Dave AA6YQ
 

+ AA6YQ comments below
what are you hoping to gain over and above the existing Commander multi-radio support that allows you to switch between a pre-configured set of radios? Just checking an radio name in a group of radio buttons seems far easier than switching workspaces.

+ It would be nice if selecting a primary transceiver in Commander caused WSJT-X to automatically choose the correct (pre-configured) configuration for that transceiver. That would require extending Commander to send a message to WSJT-X when the selected primary transceiver changes.

     73,

             Dave, AA6YQ


Re: wsjt-x+jtalert+DXLab - an incomplete story ..

g4wjs
 

On 14/06/2021 22:52, Peter Laws / N5UWY wrote:
+ Conceptually, you could configure one instance of WSJT-X to use Commander to control one transceiver, and configure the second instance of WSJT-X to control your second transceiver directly.Whether any of the other plumbing can be made to work with this configuration, I can't say because you'd be outside the DXLab "one primary transceiver at a time" envelope.
I'm quite content to have different workspaces for the two radios and
was headed in that direction when W10 got me sidetracked.

What is the "easy" way to duplicate an existing workspace?  I'd like
to duplicate my "full" workspace that I use with my 746 to use with my
910.  I have another stripped down "lite" workspace that I use with
the 746 when I don't need (or want) PF, SC, WW, and CwGet, and MMTTY
and ... but just want Commander and DXKeeper and WSJT-X but for the
new workspace, I want to start with everything and then pare back.

Hi Peter,

what are you hoping to gain over and above the existing Commander multi-radio support that allows you to switch between a pre-configured set of radios? Just checking an radio name in a group of radio buttons seems far easier than switching workspaces.


--
73

Bill

G4WJS.

2101 - 2120 of 204054