Date   

Re: Spotcollector versus Capture&Commander

eddy on5jk
 

Thanks Dave, i will certainly send you the wanted ErrorLog.

Today i observed that my "cry for victory" was to early. Indeed, it happened again, doubleclick not working as expected.

Eddy ON5JK

Op 16/06/2021 om 17:46 schreef Dave AA6YQ:

+ AA6YQ comments below

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?

+ I don’t know, Eddy. It's possible that the load on your computer has increased to the point where more "double-click" time is necessary.

+ So that I can see what's going on, please do the following:

0. Configure SpotCollector to be connected to your usual spot sources, if that's not already the case

1. On the Configuration window's General tab, check the "log debugging info" box

2. Terminate SpotCollector

3. Start SpotCollector, and wait until it is fully initialized.

4. Repeat this two-step procedure 10 times:

4a. double-click on a Spot Database Entry

4b. wait 10 seconds

5. On the Configuration window's General tab, uncheck the "log debugging info" box

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

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ





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

Dave AA6YQ
 

+ AA6YQ comments below
Is that done through using multicast UDP or unicast with unique ports for each WSJT-X instance?

+ SpotCollector (actually, the SC_WSJX.exe "helper app") listens on 2237 using the Microsoft Winsock control, which does not support multicast. Each incoming message conveys the (ephemeral) address and port of the source WSJT-X instance, which uniquely identifies the client and enables UDP messages (like "set callsign color") to be sent to it. The user is not aware of the ephemeral ports; he or she configures each WSJT-X instance to communicate with port 2237 on the IP address of the machine that hosts SpotCollector. I found it necessary for the Winsock data arrival task to immediately parse and enqueue each message as it arrives, with a separate task dequeuing and processing messages.

       73,

             Dave, AA6YQ

 

 


Re: Removing Duplicate QSOs

peril2k <peril2k@...>
 

Will do.  TNX Davve


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

HamApps Support (VK3AMA)
 

On 17/06/2021 1:48 pm, Dave AA6YQ wrote:
Yes, SpotCollector can interoperate with up to 16 instances of WSJT-X.

Is that done through using multicast UDP or unicast with unique ports for each WSJT-X instance?

de Laurie VK3AMA


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

Dave AA6YQ
 

+ AA6YQ comments below

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.

+ Since there can be only one instance of Commander running on a computer, if you want multiple instances of WJST-X that each use Commander for transceiver control, then those instances of WSJT-X and Commander must each be hosted on a separate network-connected computers.

+ Alternatively, you can host multiple instanced of WXJT-X on a single computer, one that employs Commander for transceiver control, and the rest using WSJT-X's native transceiver control.

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.

+ Yes, SpotCollector can interoperate with up to 16 instances of WSJT-X.

There should be no problem with having one rig controlled by Commander one or more others each directly controlled by separate WSJT-X instances.

+ There is indeed no problem with that configuration.

73,

Dave, AA6YQ


Re: Removing Duplicate QSOs

Dave AA6YQ
 

+ AA6YQ comments below

I imported a contest log from N1MM (June VHF) twice by accident. I've read through the instructions at http://www.dxlabsuite.com/dxlabwiki/RemovingDuplicates but have already received about half of the contact QSLs via LOTW.

If I go through the process to delete duplicates, will it delete those which haven't been uploaded yet rather than the Q's which have already been uploaded? I would rather go through 250 dupes by hand than inadvertently delete some of the new confirmed grids I worked.

+ If you have 250 QSOs whose CONTEST_ID items specify

ARRL-VHF-JUN

that have been submitted to LoTW, and 250 duplicates of those QSO that have not been submitted to LoTW, then

1. Backup your log (Configuration window, Log tab, Backup button

2. select the "right" duplicates by filtering the Log Page Display with

(CONTEST_ID = 'ARRL-VHF-JUN') and (YEAR(QSO_BEGIN)=2021) and (APP_DXKEEPER_LOTW_QSL_SENT not in ('U','Y'))

3. delete these "not submitted to LoTW" duplicates en masse by depressing the CTRL key while clicking the Delete button above the Log Page Display

73,

Dave, AA6YQ


Removing Duplicate QSOs

peril2k <peril2k@...>
 

I imported a contest log from N1MM (June VHF) twice by accident.  I've read through the instructions at http://www.dxlabsuite.com/dxlabwiki/RemovingDuplicates but have already received about half of the contact QSLs via LOTW.

If I go through the process to delete duplicates, will it delete those which haven't been uploaded yet rather than the Q's which have already been uploaded?  I would rather go through 250 dupes by hand than inadvertently delete some of the new confirmed grids I worked.

TNX, Paul / W7IV


Re: Spotcollector versus Capture&Commander

Dave AA6YQ
 

+ AA6YQ comments below

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?

+ I don’t know, Eddy. It's possible that the load on your computer has increased to the point where more "double-click" time is necessary.

+ So that I can see what's going on, please do the following:

0. Configure SpotCollector to be connected to your usual spot sources, if that's not already the case

1. On the Configuration window's General tab, check the "log debugging info" box

2. Terminate SpotCollector

3. Start SpotCollector, and wait until it is fully initialized.

4. Repeat this two-step procedure 10 times:

4a. double-click on a Spot Database Entry

4b. wait 10 seconds

5. On the Configuration window's General tab, uncheck the "log debugging info" box

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

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


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

2661 - 2680 of 204622