Date   

Autoupdate of reference files?

Jim Wysocki
 

I've been perusing the documentation about the reference files that are used by the various DXLab applications.  It appears that at least some of them are automatically updated with each module's new release.  Is that true in all cases?  I'm referring to files like BandModes.txt and the like.

I'd also like to compare the contents of these files on my computer with their latest versions in the documentation standards.  I know where to find them on my computer, but can you give me the location of the file repository?  I'm not readily finding it in the documentation.

Thanks and 73,  Jim  W9FI


Re: Sync LotW QSOs issues

Dave AA6YQ
 

+ AA6YQ comments below
It is very frustrating to see that in LOTW there are 2 qsos with the same call, mode, freq etc. BUT the time is sometimes 30 to 45 seconds difference.
For example, I send 09:24:31, and the other station sends 09:24:00 and that already has a difference. However, LOTW says they take a 15-minute difference into account.
This will give you the message "no matching QSO in log".

+ That's not what the message ""no matching QSO in log" means, Patrick.

+ It means that you submitted the QSO to LoTW with one time specified, but the QSO in your log specifies a different time (or a different band or a different mode, or ...).

+ For example, if you submit a QSO logged in DXKeeper with a start time of 9:24:31 to LoTW, then change the logged QSO's time to 09:24:00, and then invoke DXKeeper's "Sync LoTW QSOs" operation, the result will be "no matching QSO in log"  -- because there is no QSO in your log with a start time of 09:24:31.

+ The actions of your QSO partner cannot cause this error message; it can only be caused by your actions, or by an error in LoTW.

       73,

               Dave, AA6YQ

 

 

 

 


Re: Sync LotW QSOs issues

Patrick ON6AT
 

Hi Dave,
It is very frustrating to see that in LOTW there are 2 qsos with the same call, mode, freq etc. BUT the time is sometimes 30 to 45 seconds difference.
For example, I send 09:24:31, and the other station sends 09:24:00 and that already has a difference. However, LOTW says they take a 15-minute difference into account.
This will give you the message "no matching QSO in log".

That's how I see it Dave.
See my example:


73 Patrick ON6AT


Re: Intermitent Rig Control Errors to my ICOM 7610

Dave AA6YQ
 

Thanks for the detailed report below, Jerry.

Some comments

1. You should not be running MMD.exe when you are running WSJT-X.

2. The error message "DX Lab Suite Commander rig did not respond to PTT: ON" comes from WSJT-X, which expects that within a certain period of time, Commander will report that it has switched from RX to TX in response to sending Commander a "switch from RX to TX" directive.

3. I have seen access to a network connected printer cause sporadic long processing delays.


Thus my advice is

A. terminate MMD when running WSJT-X

B. On the WSJT-X Advanced Tab, set the TX delay to 0.2 seconds (the setting I use with my IC-7800, which is slower than your iC-7610)

C. For the next several days, temporarily disable the Canon applications and disable your machine's access to the Wifi-accessible printer

D. Update Windows 10 to the latest virus definitions in

https://www.microsoft.com/en-us/wdsi/definitions

E. Reboot Windows

Let's see if this changes the incidence of failure.

If you go 4 days without a failure, then try re-enabling your Wifi printer and its Canon utilizies.

73,

Dave, AA6YQ

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Gerald Wilson
Sent: Wednesday, April 07, 2021 7:44 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Intermitent Rig Control Errors to my ICOM 7610

Dave AA6YQ,

I have been slow to respond because I've had some business to attend to, and I wanted to observe the error again to give you a fresh report. I usually suspect that any problems here are most often caused by the limitations of the operator whose hand is on the mouse or the radio knob. While I have not been on FT-8 or FT-4 much since I last wrote, I did encounter another "Rig Control Error" today on 20m FT-8. I had completed an FT-4 QSO and a 2 FT-8 QSO's. The following error popped up with the following details:


"DX Lab Suite Commander rig did not respond to PTT: ON
Timestamp: 2021-04-07T22:32:32.705Z"

I checked Commander's Error Log, and there was no entry for this date.


Question: What applications were running? (I'll include them all to be thorough if not additionally helpful.)
Answer: The MS Task Manager listed the following apps running on the date of my first e-mail.


1. Two apps running in the background related to my WiFi connected Canon printer.
Canon Quick Menu and
Canon Quick Menu Image Display


2. DXLabLauncher.exe Ver. 2.1.4

3. MMD.exe Ver. 6

4. CI-V Commander.exe Ver. 15.0.1
5. DXKeeper.exe Ver. 15.9.9

6. DXView.exe Ver. 4.7.9
including World Map display

7. Pathfinder.exe Ver. 5.2.6

8. SC_WSJTS.exe Ver. 1.0.7

9. SpotCollector.exe Ver. 8.8.3


10. WSJT-X: Digital Modes Ver. 2.3.0 Oc42df (64-bit)
Console Window Host
jt9 - WSJT-X slow mode decoder (?? I haven't used JT-9)
WSJT-X Digital Modes


11. For time sychronization, I am using Dimension 4, Ver. 5.31.331.0.


12. Additionally on the day of the earlier error, I probably had the Chrome browser open to monitor lightning conditions in our region. During today's Rig Control Error, the Chrome browser was not running.


13. Today, I did have my e-mail client (Thunderbird) open.


Regarding Spotcollector, I have been using 3 spot sources: VE7CC, a local DX cluster, and WSJT-X itself. The local DX cluster appears to avoid FT-8 and FT-4 spots unless they are posted locally. VE7CC sends out copious digital spot postings and sometimes seems to slow my system down so I turn it off occasionally. I do not recall if I was monitoring VE7CC when the earlier error occurred. Today, I was connected to the VE7CC cluster.


Regarding software settings, I have WSJT-X under the Radio-tab to use "DX Lab Suite Commander" and the Poll Interval set to 1 second. On the WSJT-X Advanced Tab, I have the TX delay set to 0.3 seconds.


My PC setup is as follows:

* Processor AMD Ryzen 5 @ 3.6 GHZ w/ 32 GB of RAM
* 232 GB Solid State Drive with 50 GB free
* MS-Windows 10 Pro with the current updates.

* Security is MS Defender.

Today as all this software is running, the Task Manager shows the CPU running at 5-15% capacity with peaks on 20m FT-8 decode of 25-35%.


The XCVR as mentioned before is an ICOM IC-7610 with firmware V. 1.20.

I hope this gives an adequate picture of my operating conditions so as to provide you with adequate information. If I can provide additional details, please let me know.

Thank you for your assistance in the past and for your guidance now.

73, Jerry K7VIT



________________________________

On 3/22/2021 23:04, Dave AA6YQ wrote:


+ AA6YQ comments below


I made the change and operated some FT-8 with only 1 error occurring over 3 days.

+ A failure every 3 days is not consistent with the expect level of reliability. Clearly reducing the "Command Interval" has helped, but something else is going on. What other applications are running besides DXLab applications.

73,

Dave, AA6YQ


<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>


Re: Intermitent Rig Control Errors to my ICOM 7610

Gerald Wilson
 

Dave  AA6YQ,

I have been slow to respond because I've had some business to attend to, and I wanted to observe the error again to give you a fresh report.  I usually suspect that any problems here are most often caused by the limitations of the operator whose hand is on the mouse or the radio knob.   While I have not been on FT-8 or FT-4 much since I last wrote, I did encounter another "Rig Control Error" today on 20m FT-8.  I had completed an FT-4 QSO and a 2 FT-8 QSO's.  The following error popped up with the following details:

"DX Lab Suite Commander rig did not respond to PTT: ON
Timestamp: 2021-04-07T22:32:32.705Z"

I checked Commander's Error Log, and there was no entry for this date.

Question:   What applications were running?  (I'll include them all to be thorough if not additionally helpful.)
Answer:    The MS  Task Manager listed the following apps running on the date of my first e-mail.

  1. Two apps running in the background related to my WiFi connected Canon printer.
    Canon Quick Menu   and
    Canon Quick Menu Image Display

  2. DXLabLauncher.exe     Ver. 2.1.4
  3. MMD.exe               Ver. 6    
  4. CI-V Commander.exe    Ver. 15.0.1
  5. DXKeeper.exe          Ver. 15.9.9
  6. DXView.exe            Ver. 4.7.9
    including World Map display
  7. Pathfinder.exe        Ver. 5.2.6
  8. SC_WSJTS.exe          Ver. 1.0.7
  9. SpotCollector.exe     Ver. 8.8.3

  10. WSJT-X: Digital Modes Ver. 2.3.0 Oc42df (64-bit)
    Console Window Host
    jt9 - WSJT-X slow mode decoder (?? I haven't used JT-9)
    WSJT-X Digital Modes

  11. For time sychronization, I am using Dimension 4, Ver. 5.31.331.0.

  12. Additionally on the day of the earlier error, I probably had the Chrome browser open to monitor lightning conditions in our region. During today's Rig Control Error, the Chrome browser was not running.

  13. Today, I did have my e-mail client (Thunderbird) open.

Regarding Spotcollector, I have been using 3 spot sources:  VE7CC, a local DX cluster, and WSJT-X itself.  The local DX cluster appears to avoid FT-8 and FT-4 spots unless they are posted locally.  VE7CC sends out copious digital spot postings and sometimes seems to slow my system down so I turn it off occasionally.  I do not recall if I was monitoring VE7CC when the earlier error occurred.  Today, I was connected to the VE7CC cluster.

Regarding software settings, I have WSJT-X under the Radio-tab to use "DX Lab Suite Commander" and the Poll Interval set to 1 second. On the WSJT-X Advanced Tab, I have the TX delay set to 0.3 seconds.

My PC setup is as follows:

  • Processor AMD Ryzen 5 @ 3.6 GHZ w/ 32 GB of RAM
  • 232 GB Solid State Drive with 50 GB free
  • MS-Windows 10 Pro with the current updates. 
  • Security is MS Defender.

Today as all this software is running, the Task Manager shows the CPU running at 5-15% capacity with peaks on 20m FT-8 decode of 25-35%. 

The XCVR as mentioned before is an ICOM IC-7610 with firmware V. 1.20.

I hope this gives an adequate picture of my operating conditions so as to provide you with adequate information.  If I can provide additional details, please let me know.

Thank you for your assistance in the past and for your guidance now.

73,    Jerry    K7VIT


On 3/22/2021 23:04, Dave AA6YQ wrote:
+ AA6YQ comments below
 I made the change and operated some FT-8 with only 1 error occurring over 3 days. 
+ A failure every 3 days is not consistent with the expect level of reliability. Clearly reducing the "Command Interval" has helped, but something else is going on. What other applications are running besides DXLab applications.

     73,

           Dave, AA6YQ


Re: Error Log - K3

Dave AA6YQ
 

Thanks for the errorlog, Mike.

It begins at 2021-04-06 17:43:14 and ends 63 seconds later at 17:44:17.

At 17:43:30, Commander reported your K3's frequency as 14024.82

46 seconds later at 17:55:16, Commander reported your K3's frequency as 14050.91

The errorlog you sent me shows correct operation throughout.

I do see many entries like these in your errorlog:

CIVComm.OnComm: comEvCTS
CIVComm.OnComm: comEvDSR
CIVComm.OnComm: comEvCD

These entries mean that Commander is receiving indications that the serial port's CTS, DSR, and CD signals are changing state. I've seen this happen when there are long, unterminated wires connected to these serial port signals. While they cause no functional harm, handling these events does consume additional CPU cycles, so it would be best to stop them from occurring.

73,

Dave, AA6YQ


Re: Deleting duplicates #file

Dave AA6YQ
 

+ AA6YQ comments below
How can I delete duplicates ??

+ You asked that question yesterday, and I answered it:

https://groups.io/g/DXLab/message/200790

     73,

           Dave, AA6YQ


Re: Deleting duplicates #file

iain macdonnell - N6ML
 

On Tue, Apr 6, 2021 at 11:34 AM Dave Tucker Nu4N <dwtucker19@comcast.net> wrote:

How can I delete duplicates ??
The top result of a Google search for "dxlab delete duplicates" is:

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

73,

~iain / N6ML


Deleting duplicates #file

Dave Tucker Nu4N <dwtucker19@...>
 

How can I delete duplicates ??
thanks

--
73's de NU4N Dave


Re: Commander won't track K3 for more than 10 seconds

Dave AA6YQ
 

+ AA6YQ comments below
I tried the suggestions in Joe's article with no real success.  
 
I should mention that this has been happening for the past several months, I've been busy with other things and never got to asking about it until now.
 
I should also mention that N1MM controls my K3 just fine and follows the frequency without any issues.
 
Any other suggestions?

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

1. on the General tab of Commander's Configuration window, check the "log debugging info" box
2. terminate Commander
3. set your K3 to 14005 in CW
4. start Commander, and wait for it to fully initialize
5. using its front panel, slowly QSY your K3 to 14050 over the course of 30 seconds
6. on the General tab of Commander's Configuration window, uncheck the "log debugging info" box
7. attach the errorlog.txt file from your Commander folder to an email message, and send the message to me via

aa6yq (at) ambersoft.com

        73,

               Dave, AA6YQ


Re: Commander won't track K3 for more than 10 seconds

Michael Murphy
 

Dave,

I tried the suggestions in Joe's article with no real success.  

I should mention that this has been happening for the past several months, I've been busy with other things and never got to asking about it until now.

I should also mention that N1MM controls my K3 just fine and follows the frequency without any issues.

Any other suggestions?

Thanks!

- Mike - KI8R

On Mon, Apr 5, 2021 at 2:22 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

I have a problem with Commander tracking my K3. It will track for about 10 seconds and then drop. I have tried multiple cables without any change.

If I hit the reset button under the general tab in the configuration tab it will come back but again for only about 10 seconds.

It works fine with my 7300 and KX3.

Thoughts?

+ Is this new behavior, or has this always been the case?

+ Make sure that Windows is not configured to power down the port you are using with your K3.

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

     73,

                 Dave, AA6YQ









--
---------------------------------------------
Michael Murphy - KI8R

mike@...

www.ki8r.com

614-371-8265 

---------------------------------------------

--
Mike Murphy - KI8R


Re: Print daily logbook #file

Joe Subich, W4TV
 

Really?? Date() is not supposed to take any argument. It returns the
*current system date*.
Correct, fingers got ahead of the brain. I actually tend to use
QSO_Begin >= DATE()-1 to get the *previous* UTC day's QSOs after
0000Z.

73,

... Joe, W4TV


On 2021-04-05 11:36 AM, iain macdonnell - N6ML wrote:
On Mon, Apr 5, 2021 at 6:01 AM Joe Subich, W4TV <lists@subich.com> wrote:


Don't know what to tell you ... I use
QSO_Begin >= Date(2021-04-04) or
QSO_Begin >= #2021-04-04 or
2021-04-04 and click the "Since" button
daily to export QSOs made on my "radio" computer and move
them to my laptop.

All three formats work equally well/identically.
Really?? Date() is not supposed to take any argument. It returns the
*current system date*.
Dave's original proposal was:
QSO_Begin >= Date()
*exactly as written* - nothing added, nothing removed.
73,
~iain / N6ML

On 2021-04-05 5:29 AM, Dave Tucker Nu4N wrote:
On Sun, Apr 4, 2021 at 04:18 PM, Joe Subich, W4TV wrote:


*QSO_Begin* >= Date(4/3/2021)
Joe I typed in *QSO_Begin* >= Date(4/3/2021)
And still get the same report. The whole log. I must be missing something somewhere
Thanks Joe

--
73's de NU4N Dave





Re: SC autoscroll

Joe Subich, W4TV
 

On 2021-04-05 2:44 PM, Joe K2UF wrote:
Maybe the "autoscroll" box could be put to the left of the arrows and
increase the font to 18 or 24 pitch.
Please, no! That would force a wider minimum screen width for SC -
which is already nearly too wide for operators with limited screen real
estate (single monitors, older, less than "FULL HD" resolution monitors,
etc.).

73,

... Joe, W4TV


On 2021-04-05 2:44 PM, Joe K2UF wrote:
This would probably be put in the 'nit picking' catagory.
When I have to scroll back through past SC post SC will freeze and the autoscroll warning begin to flash.  Usually the back scrolling happens when I am trying to get some additional info on a spot that I am trying to work.  after I work the station (or give up!) I continue going about life.  Most of the time I forget to resume SC scrolling because the small autoscroll flashing warning is very small and my eyes are very old.  eventually I happen to notice it and resume SC scrolling.
Maybe the "autoscroll" box  could be put to the left of the arrows and increase the font to 18 or 24 pitch.  That way it would be more of a shock to see some thing that big flashing on the screen.
I know this would be a low priority change and I don't expect it to be changed this afternoon but maybe by morning   ;o{)))>
73  Joe K2UF


Re: SC autoscroll

Dave AA6YQ
 

+ AA6YQ comments below

This would probably be put in the 'nit picking' catagory.

When I have to scroll back through past SC post SC will freeze and the autoscroll warning begin to flash. Usually the back
scrolling happens when I am trying to get some additional info on a spot that I am trying to work. after I work the station (or
give up!) I continue going about life. Most of the time I forget to resume SC scrolling because the small autoscroll flashing
warning is very small and my eyes are very old. eventually I happen to notice it and resume SC scrolling.

Maybe the "autoscroll" box could be put to the left of the arrows and increase the font to 18 or 24 pitch. That way it would be
more of a shock to see some thing that big flashing on the screen.

+ You can make the "autoscroll" box - and everything else in SpotCollector - bigger by following Dave W6DE's recommendations:

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

73,

Dave, AA6YQ


Re: Print daily logbook #file

Dave AA6YQ
 

+ AA6YQ comments below

Yes I finally figured it out. Thanks to everyone for the help.

I do have one question how do I delete duplicates.

+ See

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

Then I will be ready to go.

+ I disagree. Before you go any further, I suggest that you scan

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

+ By "scan", I mean review the material to understand what capabilities are available, but without attempting to remember the details required to use those capabilities (which you can go back and obtain when needed).

73,

Dave, AA6YQ


SC autoscroll

Joe K2UF
 

This would probably be put in the 'nit picking' catagory.
 
When I have to scroll back through past SC post SC will freeze and the autoscroll warning begin to flash.  Usually the back scrolling happens when I am trying to get some additional info on a spot that I am trying to work.  after I work the station (or give up!) I continue going about life.  Most of the time I forget to resume SC scrolling because the small autoscroll flashing warning is very small and my eyes are very old.  eventually I happen to notice it and resume SC scrolling.
 
Maybe the "autoscroll" box  could be put to the left of the arrows and increase the font to 18 or 24 pitch.  That way it would be more of a shock to see some thing that big flashing on the screen.
 
I know this would be a low priority change and I don't expect it to be changed this afternoon but maybe by morning   ;o{)))>
 
 
73  Joe K2UF


Re: Print daily logbook #file

Dave Tucker Nu4N <dwtucker19@...>
 

Yes I finally figured it out. Thanks to everyone for the help.

I do have one question how do I delete duplicates. Then I will be ready to go.

On 4/5/2021 1:29 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

That seems to work but I dont see any lOTW confirmations Nor EQSL confirmations.

+ Do you have the Log Page Display configured to include columns for LoTW confirmations and eQSL confirmations?

73,

Dave, AA6YQ




--
73's de NU4N Dave


Re: Print daily logbook #file

Dave AA6YQ
 

+ AA6YQ comments below

That seems to work but I dont see any lOTW confirmations Nor EQSL confirmations.

+ Do you have the Log Page Display configured to include columns for LoTW confirmations and eQSL confirmations?

73,

Dave, AA6YQ


Re: Help with SQL Expression for DXKeeper wanted

Dave AA6YQ
 

+ AA6YQ comments below

Joe, thanks for your help too. This made things even easier for me.
There was a file named "DXKeeper Filters" available back in 2013, which was assembled by K9UW. Is this still being updated or available?

+ Yes:

https://groups.io/g/DXLab/files/DXKeeper%20SQL%20Filters/DXKeeper%20SQL%20Filters.pdf

I think there is still a lot to learn with the powerful SQL expressions.

+ See

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

+ The nice thing about SQL filters is that they are non-destructive, so you can experiment without fear of damaging your data.

73,

Dave, AA6YQ


Re: Commander won't track K3 for more than 10 seconds

Dave AA6YQ
 

+ AA6YQ comments below

I have a problem with Commander tracking my K3. It will track for about 10 seconds and then drop. I have tried multiple cables without any change.

If I hit the reset button under the general tab in the configuration tab it will come back but again for only about 10 seconds.

It works fine with my 7300 and KX3.

Thoughts?

+ Is this new behavior, or has this always been the case?

+ Make sure that Windows is not configured to power down the port you are using with your K3.

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

73,

Dave, AA6YQ

3201 - 3220 of 203945