Date   

Re: ADIF import for Rovers

Joe Subich, W4TV
 

I can't see that one ADIF log would have QSOs from more than one state QSO party. Could you not select the QSO party you're importing from a drop down list? AD1C's program does it that way.
There are multiple examples of overlapping state QSO parties. One
can not count on the Contest ID to define the state. I know of one
weekend that has a regional QSO party (7QP) plus two other states -
Maryland and Indiana, IIRC.

73,

... Joe, W4TV


On 2021-03-17 5:31 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
I can't comment on the grid square import since I've never operated as a VHF contest rover. I have operated mobile in a number of state QSO parties.
I think not all logging programs export a CONTEST-ID tag.
+ N1MM does; I'm happy to start there, and then persuade others to follow.
I can't see that one ADIF log would have QSOs from more than one state QSO party. Could you not select the QSO party you're importing from a drop down list? AD1C's program does it that way.
+ DXKeeper could be extended to recognize state QSO parties in the imported CONTEST-ID tag, and infer "my state" that way.
Personally I would prefer to have more control on naming the myQTHID. The possible example above is longer than I would want to use. For example for the logs I imported for the Texas QSO Party myQTHIDs were TQP-Midland, TQP-Andrews, etc.
+ Understood.
Looking in the Documents/N1MM+/MultChaser directory on my computer I noticed there are XML files for each QSO party with the county abbreviation and full county name. Perhaps AB2ZY could expand those files so they could be used to provide a correct MY_CNTY tag on export of a QSO party log. A spot check shows the full county names in those files would have to be checked to insure they were the same as the LOTW county names. Some are not.
While this would be a nice feature I wonder how many DXLab users operate mobile in state QSO parties?
+ Nothing being contemplated would take more than 30 minutes to implement, document, and test -- but the addition of a new "Create Mobile myQTHID" option on the Main window's "Import QSOs" tab would increase user-perceived complexity.
+ Ideally, there will be a way for the N1MM user to ensure that the ADIF exported for each logged QSO includes a MY_GRIDSQUARE field that DXKeeper can then use to fabricate a myQTHID, if both enabled and necessary. That ensures that QSOs valid for VUCC will be correctly submitted to LoTW, no matter what the contest.
+ If that's not the case, then using MY_GRIDSQUARE when present, and a combination of the state inferred from the state QSO party specified in CONTEST-ID and the county code from the new APP_N1MM_ROVERCNTY field would be the fallback. This would yield fabricated myQTHIDs like
mobile_FN42
+ and
mobile_VA_LAN
+ and
mobile_PA_LAN
+ In the case where MY_GRIDSQUARE is not present, the rover who logs VHF or UHF QSOs from multiple grid squares within a county would have some manual work to do to ensure correct uploads to LoTW.
+ In case anyone is wondering what we're doing here, it's called "Requirements Elicitation by Stumbling Around".
73,
Dave, AA6YQ


Re: DXK: QSO could not be logged

Dave AA6YQ
 

+ AA6YQ comments below

Received an error today after completing an FT8 QSO, the results was indeed a QSO not being logged in DXKeeper. There is an entry in the errorlog,txt file. DXK also displayed a pop-up window with Received ADIF Record details. I cannot spot anything wrong with the ADIF record. I saw this error a few days back for the first time, I closed WSJT, JTAlert, and restarted them, and the problem went away.

+ Please attach the errorlog.txt file to an email message, and send the message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


DXK: QSO could not be logged

Bernd - KB7AK
 

Received an error today after completing an FT8 QSO, the results was indeed a QSO not being logged in DXKeeper. There is an entry in the errorlog,txt file. DXK also displayed a pop-up window with Received ADIF Record details. I cannot spot anything wrong with the ADIF record. I saw this error a few days back for the first time, I closed WSJT, JTAlert, and restarted them, and the problem went away.

73,
Bernd - KB7AK


Re: ADIF import for Rovers

Dave AA6YQ
 

+ AA6YQ comments below

I can't comment on the grid square import since I've never operated as a VHF contest rover. I have operated mobile in a number of state QSO parties.

I think not all logging programs export a CONTEST-ID tag.

+ N1MM does; I'm happy to start there, and then persuade others to follow.


I can't see that one ADIF log would have QSOs from more than one state QSO party. Could you not select the QSO party you're importing from a drop down list? AD1C's program does it that way.

+ DXKeeper could be extended to recognize state QSO parties in the imported CONTEST-ID tag, and infer "my state" that way.

Personally I would prefer to have more control on naming the myQTHID. The possible example above is longer than I would want to use. For example for the logs I imported for the Texas QSO Party myQTHIDs were TQP-Midland, TQP-Andrews, etc.

+ Understood.


Looking in the Documents/N1MM+/MultChaser directory on my computer I noticed there are XML files for each QSO party with the county abbreviation and full county name. Perhaps AB2ZY could expand those files so they could be used to provide a correct MY_CNTY tag on export of a QSO party log. A spot check shows the full county names in those files would have to be checked to insure they were the same as the LOTW county names. Some are not.

While this would be a nice feature I wonder how many DXLab users operate mobile in state QSO parties?

+ Nothing being contemplated would take more than 30 minutes to implement, document, and test -- but the addition of a new "Create Mobile myQTHID" option on the Main window's "Import QSOs" tab would increase user-perceived complexity.

+ Ideally, there will be a way for the N1MM user to ensure that the ADIF exported for each logged QSO includes a MY_GRIDSQUARE field that DXKeeper can then use to fabricate a myQTHID, if both enabled and necessary. That ensures that QSOs valid for VUCC will be correctly submitted to LoTW, no matter what the contest.

+ If that's not the case, then using MY_GRIDSQUARE when present, and a combination of the state inferred from the state QSO party specified in CONTEST-ID and the county code from the new APP_N1MM_ROVERCNTY field would be the fallback. This would yield fabricated myQTHIDs like

mobile_FN42

+ and

mobile_VA_LAN

+ and

mobile_PA_LAN

+ In the case where MY_GRIDSQUARE is not present, the rover who logs VHF or UHF QSOs from multiple grid squares within a county would have some manual work to do to ensure correct uploads to LoTW.

+ In case anyone is wondering what we're doing here, it's called "Requirements Elicitation by Stumbling Around".

73,

Dave, AA6YQ


Re: N1MM, DXKeeper, Gateway.

Dave AA6YQ
 

+ AA6YQ comments below

Dave, thanks for your help.

+ Are things now working to your satisfaction?

73,

Dave, AA6YQ


Re: Intermitent Rig Control Errors to my ICOM 7610

Dave AA6YQ
 

+ AA6YQ comments below
OK, I like that direction better!  I'll give it a try and see if that helps.

+ Also, be sure that your firewall and anti-malware are configure to consider WSJT-X, Commander, and your other DXLab applications to be "safe".

       73,

            Dave, AA6YQ


Re: Intermitent Rig Control Errors to my ICOM 7610

Mike Wasserburger - WF0M
 

OK, I like that direction better!  I'll give it a try and see if that helps.

thanks!

Mike / WF0M

On Wed, Mar 17, 2021 at 10:59 AM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below
Every once in a while, WSJT software reports a rig control error.  The message is this:

DX Lab Suite Commander rig did not respond to PTT: ON

I have the command interval set to 100ms.  I had it set to 50ms, but when I started seeing this error, I backed it off to 100ms.  That doesn't seem to be helping.
+ Try changing the Command Interval to 25 ms.

      73,

             Dave, AA6YQ


Re: Intermitent Rig Control Errors to my ICOM 7610

Dave AA6YQ
 

+ AA6YQ comments below
Every once in a while, WSJT software reports a rig control error.  The message is this:

DX Lab Suite Commander rig did not respond to PTT: ON

I have the command interval set to 100ms.  I had it set to 50ms, but when I started seeing this error, I backed it off to 100ms.  That doesn't seem to be helping.
+ Try changing the Command Interval to 25 ms.

      73,

             Dave, AA6YQ


Intermitent Rig Control Errors to my ICOM 7610

Mike Wasserburger - WF0M
 

Every once in a while, WSJT software reports a rig control error.  The message is this:

DX Lab Suite Commander rig did not respond to PTT: ON

I have the command interval set to 100ms.  I had it set to 50ms, but when I started seeing this error, I backed it off to 100ms.  That doesn't seem to be helping.

Any suggestions?

thanks,

Mike / WF0M


Re: ADIF import for Rovers

ve3ki
 

The Documents/N1MM+/MultChaser directory you mentioned was not created by N1MM+. In all likelihood it, along with all of the files it contains, came from a third-party program.

73,
Rich VE3KI


On Tue, Mar 16, 2021 at 11:07 PM, Alan Sewell wrote:
On Tue, Mar 16, 2021 at 07:21 PM, Dave AA6YQ wrote:
+ The question is what to do if there's no MY_GRIDSQUARE field in the
+ record. If a MY_CNTY were reliably present (is it?), that could be
+ used -- but the problem is that these are ambiguous. QSOs made in the
+ PA and VA State QSO Parties could specify <MY_CNTY:3>LAN. The only way
+ I can see to reliably disambiguate this would be to also include the
+ contents of the CONTEST-ID field. Were I to do that, a fabricated
+ myQTHID could look like


mobile_PA-QSO-PARTY_LAN

+ Comments? Better ideas?
I can't comment on the grid square import since I've never operated as a VHF contest rover.  I have operated mobile in a number of state QSO parties.

I think not all logging programs export a CONTEST-ID tag.  I can't see that one ADIF log would have QSOs from more than one state QSO party.  Could you not select the QSO party you're importing from a drop down list?  AD1C's program does it that way.

Personally I would prefer to have more control on naming the myQTHID.  The possible example above is longer than I would want to use.  For example for the logs I imported for the Texas QSO Party myQTHIDs were TQP-Midland, TQP-Andrews, etc.  

Looking in the Documents/N1MM+/MultChaser directory on my computer I noticed there are XML files for each QSO party with the county abbreviation and full county name. Perhaps AB2ZY could expand those files so they could be used to provide a correct MY_CNTY tag on export of a QSO party log.  A spot check shows the full county names in those files would have to be checked to insure they were the same as the LOTW county names.  Some are not.

While this would be a nice feature I wonder how many DXLab users operate mobile in state QSO parties?


N1MM, DXKeeper, Gateway.

Yuriy Veselov
 

Dave, thanks for your help.
73. Yuri R2ZX


Re: ADIF import for Rovers

Alan N5NA
 

On Tue, Mar 16, 2021 at 07:21 PM, Dave AA6YQ wrote:
+ The question is what to do if there's no MY_GRIDSQUARE field in the
+ record. If a MY_CNTY were reliably present (is it?), that could be
+ used -- but the problem is that these are ambiguous. QSOs made in the
+ PA and VA State QSO Parties could specify <MY_CNTY:3>LAN. The only way
+ I can see to reliably disambiguate this would be to also include the
+ contents of the CONTEST-ID field. Were I to do that, a fabricated
+ myQTHID could look like


mobile_PA-QSO-PARTY_LAN

+ Comments? Better ideas?
I can't comment on the grid square import since I've never operated as a VHF contest rover.  I have operated mobile in a number of state QSO parties.

I think not all logging programs export a CONTEST-ID tag.  I can't see that one ADIF log would have QSOs from more than one state QSO party.  Could you not select the QSO party you're importing from a drop down list?  AD1C's program does it that way.

Personally I would prefer to have more control on naming the myQTHID.  The possible example above is longer than I would want to use.  For example for the logs I imported for the Texas QSO Party myQTHIDs were TQP-Midland, TQP-Andrews, etc.  

Looking in the Documents/N1MM+/MultChaser directory on my computer I noticed there are XML files for each QSO party with the county abbreviation and full county name. Perhaps AB2ZY could expand those files so they could be used to provide a correct MY_CNTY tag on export of a QSO party log.  A spot check shows the full county names in those files would have to be checked to insure they were the same as the LOTW county names.  Some are not.

While this would be a nice feature I wonder how many DXLab users operate mobile in state QSO parties?


Re: ADIF import for Rovers

Dave AA6YQ
 

To be clear, there are two independent challenges when importing contest logs:

1. Importing a contest log created by a roving station that contains QSOs made from several -- possibly many -- different locations. This prevents the user from importing the log by specifying a single myQTHID to be applied to each imported QSO. Ideally, DXKeeper would independently fabricate an appropriate myQTHID for each imported QSO, eliminating the need for the roving user to do that with filtering and mass modification operations.

2. Dealing with the non-standard county abbreviations used in State QSO Party contests so that ops pursuing USACA ("Worked all US Counties") and WAS ("Worked all US States") would have logged QSOs that accurately specify a US state and county. As has been pointed out, Jim AD1C maintains an application that translates non-standard County abbreviations in an ADIF file to standard County abbreviations in an ADIF file; ideally, the need to pre-process and ADIF file before importing it into DXKeeper could be eliminated. I am in discussion with Jim.

73,

Dave, AA6YQ



+ AA6YQ comments below

Alan N5NA wrote:

When I switched to DXLab earlier this year I imported thousands of state QSO party QSOs from hundreds of different counties creating a myQTH ID for each county. I used a bulk search and replace program where I searched for the MY_CNTY tag that had the county abbreviation and replaced it with a string of ADIF tags.

+ The next version of DXKeeper provides a new "Create mobile myQTHID"
+ option on the Main window's "Import QSOs" tab. If you haven't
+ specified a myQTHID on this tab's "Substitution options" panel, and
+ you've enabled the new "Create mobile myQTHID" option, and DXKeeper
+ encounters an ADIF record that doesn't specify an
+ App_DXKeeper_My_QTHID, then if the forthcoming new version of N1MM has
+ included a MY_GRIDSQUARE field that specifies CM87, then DXKeeper
+ will import the record with a myQTHID of

mobile_FN42

+ The question is what to do if there's no MY_GRIDSQUARE field in the
+ record. If a MY_CNTY were reliably present (is it?), that could be
+ used -- but the problem is that these are ambiguous. QSOs made in the
+ PA and VA State QSO Parties could specify <MY_CNTY:3>LAN. The only way
+ I can see to reliably disambiguate this would be to also include the
+ contents of the CONTEST-ID field. Were I to do that, a fabricated
+ myQTHID could look like

mobile_PA-QSO-PARTY_LAN

+ Comments? Better ideas?

73,

Dave, AA6YQ


Re: ADIF import for Rovers

Dave AA6YQ
 

+ AA6YQ comments below

Alan N5NA wrote:

When I switched to DXLab earlier this year I imported thousands of state QSO party QSOs from hundreds of different counties creating a myQTH ID for each county.  I used a bulk search and replace program where I searched for the MY_CNTY tag that had the county abbreviation and replaced it with a string of ADIF tags.

+ The next version of DXKeeper provides a new "Create mobile myQTHID" option on the Main window's "Import QSOs" tab. If you haven't specified a myQTHID on this tab's "Substitution options" panel, and you've enabled the new "Create mobile myQTHID" option, and DXKeeper encounters an ADIF record that doesn't specify an App_DXKeeper_My_QTHID, then if the forthcoming new version of N1MM has included a MY_GRIDSQUARE field that specifies CM87,  then DXKeeper will import the record with a myQTHID of

mobile_FN42

+ The question is what to do if there's no MY_GRIDSQUARE field in the record. If a MY_CNTY were reliably present (is it?), that could be used -- but the problem is that these are ambiguous. QSOs made in the PA and VA State QSO Parties could specify <MY_CNTY:3>LAN. The only way I can see to reliably disambiguate this would be to also include the contents of the CONTEST-ID field. Were I to do that, a fabricated myQTHID could look like

mobile_PA-QSO-PARTY_LAN

+ Comments? Better ideas?

      73,

            Dave, AA6YQ


Re: Spots do not display in SpotCollector main window

Dave AA6YQ
 

+ AA6YQ comments below

I have just installed SpotCollector, version 8.8.3 from the DXLabLauncher program. I am running Windows 10 Pro on a laptop. My problem is that I do not see any spots at all in the main window. All I see is a grey screen and a set of grey rectangles on the left side of the screen running from top to bottom. My Spot Source is enabled in the Telnet DXClusters window, and the spot source is operating correctly as the LED for it is green and I can see spots in its window. Also when I hover my mouse over the grey rectangles I see messages such as “Click to convey A25RU to other apps….”. As well the SpotCollector Statistics window has entries in various bands. The Filter: None is set at the bottom of the main window, and the radio button to the right of “Mrthn” is on.

There is a notification at the top of the main window saying “see error log”. In the error log there are numerous messages such as ” 2021-03-15 21:13:19.891 > program error -2147221164 in module SpotDatabaseModule.InitializeSpotdatabaseDisplayLayout, State = 10, I = 0, SpotDatabaseUI.SpotGrid.Columns.Count = 128: Class not registered”


+ "Class not registered" means that a software component that SpotCollector employs was not successfully registered when SpotCollector was installed. So that I can see what's going on, please attach the errorlog.txt file from your SpotCollector folder to an email message, and send the email message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Spots do not display in SpotCollector main window

Michael Brickell VE3TKI
 

I have just installed SpotCollector, version 8.8.3 from the DXLabLauncher program.  I am running Windows 10 Pro on a laptop.  My problem is that I do not see any spots at all in the main window. All I see is a grey screen and a set of grey rectangles on the left side of the screen running from top to bottom.  My Spot Source is enabled in the Telnet DXClusters window, and the spot source is operating correctly as the LED for it is green and I can see spots in its window.  Also when I hover my mouse over the grey rectangles I see messages such as “Click to convey A25RU to other apps….”. As well the SpotCollector Statistics window has entries in various bands. The Filter: None is set at the bottom of the main window, and the radio button to the right of “Mrthn” is on.

 

There is a notification at the top of the main window saying “see error log”.  In the error log there are numerous messages such as ” 2021-03-15 21:13:19.891 > program error -2147221164 in module SpotDatabaseModule.InitializeSpotdatabaseDisplayLayout, State = 10, I = 0, SpotDatabaseUI.SpotGrid.Columns.Count = 128: Class not registered”

 

Can someone explain what I am doing wrong?


Re: Install Issue Resolved

Dave AA6YQ
 

+ AA6YQ comments below
FYI: I was installing the program to a second computer that is located at a different console in the shack, which I primarily use for EME, as well as other VHF/UHF low signal work. I can now “share” the .mdb database file from my main computer with my VHF/UHF computer, so the log can be updated by either one when it’s in use. I also know to shut down DXLab on the one I’m not using so as not to corrupt the database. It all works!
+ If you're sharing a log file, DXKeeper is the only application you must terminate on computer A before starting it on computer B.

     73,

          Dave, AA6YQ


Install Issue Resolved

Henry Boze
 

Dave,

 

Thank you for your input on the file structure when installing the DXLab modules. What I did to get them installed was when the “defaulted” path to where the modules were to be installed came up in the DXLab Launcher Configuration; I changed them by manually creating separate sub-directories for each module inside the DXLab folder. Once that was done and the “Program Path” recognized the program folders, it installed correctly. I’m still unsure why Commander and DXKeeper modules installed without having to do that, but it all works correctly now.

 

FYI: I was installing the program to a second computer that is located at a different console in the shack, which I primarily use for EME, as well as other VHF/UHF low signal work. I can now “share” the .mdb database file from my main computer with my VHF/UHF computer, so the log can be updated by either one when it’s in use. I also know to shut down DXLab on the one I’m not using so as not to corrupt the database. It all works!

 

Thanks again for putting me on the right track in understanding the file structure! Your support is first rate and all of us that use DXLab appreciate what you do!

 

73,

Henry, N4HB 


Re: Using Commander with SatPC32

Dave AA6YQ
 

+ AA6YQ comments below

It seems my Yaesu FT450D is using the Silicon Labs ports 12/13

The Ic-910H is thru a single USB cable to port 3

Using Port three in SatPC32 allows SatPC32 to communicate with the IC-910H .

However, DxLabs Commander does not see Port 3 due to the conflict of Commander/SatPc32/Ic910H all trying to use Com3.

+ On Commander's Configuration window's Ports tab, clear the "Primary CAT Serial Port" panel's Port# selector by selecting the blank entry at the top of the list of entries. Commander does not communicate with your radio when interoperating with SatPC32.

73,

Dave, AA6YQ


Re: Using Commander with SatPC32

KD7YZ Bob
 

It seems my Yaesu FT450D is using the Silicon Labs ports 12/13

The Ic-910H is thru a single USB cable to port 3

Using Port three in SatPC32 allows SatPC32 to communicate with the IC-910H .

However, DxLabs Commander does not see Port 3 due to the conflict of
Commander/SatPc32/Ic910H all trying to use Com3.


--
73
Bob KD7YZ

4141 - 4160 of 204552