Date   

McAfee deleted DXKeeper

Ed Ireland
 

McAfee deleted DXKeeper saying it was a virus.  When I try to instruct Commander to install DXKeeper, the only option is "Upgrade" but it then says "dxkeeper.exe does not exist:.  How do I reinstall KXKeeper?  I have removed McAfee from my computer.

Thanks,

Ed


Re: RadioInfo UDP Packet - Proposal - <app> element to identify source

Dave AA6YQ
 

+ AA6YQ comments below

We are planning on adding the <app> tag to all our XML messages. This will allow a consuming app to know what app they are talking to, thus if an app is only supposed to control a rotor for N1MM+, it can do that.

+ That's fine.

The whole purpose of XML is standardization, but also to allow extension. If another application is in need of a data element not in the standard, and one we are not willing to add, then it can be ignored by consumers who don't need it.

+ Are you willing to include data elements not supported by N1MM+ in the documentation, assuming you are appropriately informed?

Regarding frequency down to the Hz level, I have not yet heard a requirement for that. When/if it needs to be added, I am inclined to add it as a new element as an integer number of Hz as opposed to integer number of tens of Hz. SDRs controlled by extio use integer Hz to set frequency. It would be a new element to prevent all consumers from needing to handle both the current and the new format. They consumer could chose what to support without the need to coordinate with the sender.

+ Sounds good.

73,

Dave, AA6YQ


Re: RadioInfo UDP Packet - Proposal - <app> element to identify source

Dave AA6YQ
 

+ AA6YQ comments below

I would like to propose a small change to the RadioInfo XML Document UDP packet that broadcasts the status of the radios being controlled by logging software.

Add an element to the RadioInfo packet:
<app>N1MM</app>
<app>DXLAB</app>
<app>Logger32</app>
Etc…

The W1TR HFAUTO software that controls the Palstar HF-AUTO ATU uses these broadcasts to preset the L/C tuning solution in the ATU (long story, some other time).
I’m guessing that there many other APPs out there that use this information for various purposes.

The complete syntax and semantics of the information in the RadioInfo packet varies depending on its source.
It would be unreasonable to require standardization of this XML Document…

+ Exactly why would it be unreasonable to maintain a standard format used by all applications? I'm happy to make any changes in DXLab applications required to do that..


But… inclusion of the <app> element would make it easier for 3rd party software using this to properly decode it and identify its source.

+ If you make it easy to introduce gratuitous differences, guess what will happen.


Logger32 has a clever solution for providing the 1 HZ digit… <Freq>1416350.3</Freq> Use a decimal point and additional digit to get 14.163.503 as a frequency.
Too bad that N1MM chose 10 Hz as the frequency resolution, but that ship has sailed.

+ Two decimal points in a number is "clever"? Why not add 3 or 4 more and be "brilliant"? Or switch to hex, that will be even less readily understandable.

+ When I'm telling war stories about the ridiculous "variances" encountered when importing ADIF files from various applications, "frequencies that contain two decimal points" always gets a big laugh. Let's not standardize this nonsense.


At least applications broadcast RadioInfo UDP packets:
1) N1MM / N1MM+
2) DXLAB
3) Logger32

I also broadcast UDP packets from FLDIGI_UDP and W1TR Rig Control, but use a different XML Document Name.
With the use of the <app> element, I could change those to RadioInfo as well.

+ As far as I'm concerned, the N1MM team should continue owning and maintaining the XML specifications; I'm happy to keep following their lead. If there's a need for more precise frequency resolution, ask them to consider providing it.

73,

Dave, AA6YQ


Re: Minor nit - LotW inconsistency report

Dave AA6YQ
 

+ AA6YQ comments below

When request a report for inconsistencies in an LotW sync it would be nice if the same inconsistency was reported in a similar format.

2020-01-04 21:08:41 xxxx 40M RTTY N9LJX log vs LotW mismatch: logged CQZ = 5, LotW CQZ = 04
2020-01-04 21:08:41 xxxx 40M RTTY N9LJX WAZ candidate specifies a CQ zone 04 that doesn't match the logged QSO's CQ zone 5

In this case the LotW and Logged zones are reported in different order. Same information, just listed in opposite order.

+ The messages are clear, I think. I'll spare you the Ralph Waldo Emerson quote.

73,

Dave, AA6YQ


Commander Mute "Command Sequence" for TS-890S

Jim McPhee
 

Have used Commander to mute the audio of my TS-890S, sometimes I'd like to be able to un-mute it from the radio as opposed to doing it from the computer. This is because the computer and the radio are a few feet away from one another. Does anyone know if there is a way to do this?
--
Jim McPhee
Placitas, NM
W5ABA


RadioInfo UDP Packet - Proposal - <app> element to identify source

Terry Glagowski / W1TR / AFA1DI
 

I would like to propose a small change to the RadioInfo XML Document UDP packet that broadcasts the status of the radios being controlled by logging software.

 

Add an element to the RadioInfo packet:

<app>N1MM</app>

<app>DXLAB</app>

<app>Logger32</app>

Etc

 

The W1TR HFAUTO software that controls the Palstar HF-AUTO ATU uses these broadcasts to preset the L/C tuning solution in the ATU (long story, some other time).

I’m guessing that there many other APPs out there that use this information for various purposes.

 

The complete syntax and semantics of the information in the RadioInfo packet varies depending on its source.

It would be unreasonable to require standardization of this XML Document…

But… inclusion of the <app> element would make it easier for 3rd party software using this to properly decode it and identify its source.

 

Logger32 has a clever solution for providing the 1 HZ digit…

<Freq>1416350.3</Freq>

Use a decimal point and additional digit to get 14.163.503 as a frequency.

Too bad that N1MM chose 10 Hz as the frequency resolution, but that ship has sailed.

 

At least applications broadcast RadioInfo UDP packets:

1)      N1MM / N1MM+

2)      DXLAB

3)      Logger32

 

I also broadcast UDP packets from FLDIGI_UDP and W1TR Rig Control, but use a different XML Document Name.

With the use of the <app> element, I could change those to RadioInfo as well.

 

Terry G. Glagowski / W1TR
HAM: W1TR / USAF MARS: AFA1DI / GRID: FN31vw / ELEV: 950 MSL / 41.924750 N, 72.190320 W.


25 Hnath Road, Ashford, CT 06278 .
(860) 429-9444 (Landline) .
(860) 617-1969 (Cell) .

(EMail) W1TR@... .
(Web)  http://www.Glagowski.org/Radio .


Re: Multiple radios and "myQTH ID's"

Gordon LaPoint
 

Dave,
     I set up DXKeeper like you suggested.  All seems to be working fine!  I just worked a contact on the K3 (Home) and it logged with the correct myQTH and it uploaded with the correct LOTW station location (checked the LotWCommand.bat file, I have each contact upload).  I also worked one station with the Home:Virt 590 and it used the correct myQTH and also uploaded with the correct LOTW station location (Westminster).
    So every thing is working correctly, and switching auto-magically!
Now to correct some of the previous contacts to match the new myQTH names!
Thanks,
Gordon - N1MGO

On 1/10/2020 14:28 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

I am setup with multiple radios (on two computers at home) and a remote radio at a town nearby, controlled using RCForb server/client.

Is there a way to have DXKeeper set the default myQTH ID from which radio is chosen in commander. (Not just append a radio name, but actually change the myQTH ID)

+ No.

Examples of default myQTH ID's used:

Home:K3

Home:K2

Westminster: Virt 590

+ If you replace the myQTH whose ID is

Westminster: Virt 590

+ with a myQTH whose ID is

Home: Virt 590

+ Then you can use the existing mechanism to automatically change the "Default myQTH ID" when you select a radio in Commander:

<https://www.dxlabsuite.com/dxlabwiki/LogTransceiverInfo>

+ Note that the "Home: Virt 590" myQTH would still specify Westminister as the location; only the "myQTH ID" would be changed.


I would also like the LOTW station location to change with commander radio changes

Examples:

myQTH ID station location

Home:K3 HOME

Westminster:Virt 590 Westminster

W4AAW Round Hill, VA

+ If you specify the appropriate "LoTW Station Location" in the LoTW selector of each "my QTH", DXKeeper will use the appropriate "Callsign Certificate" and "Station Location" as a function of the logged QSO's "Station Callsign" and "myQTH ID" items, respectively. see
<https://www.dxlabsuite.com/dxlabwiki/LotWMultipleCallsignsLocations>

I have all of the LOTW station locations setup, and the different default myQTH ID's , but have to remember to change them when I change radios in commander.

+ Implementing the above recommendations would provide the desired automation: select the radio in Commander, and start logging QSOs.

+ Note that all QSOs being submitted to LoTW in one batch must have the same "Station Callsign" and the same "myQTH ID". This is a non-issue if each QSOs is being submitted as it is logged. If you're using "Add Requested" to populate the QSL Queue with a batch of QSOs to be submitted to LoTW, doing so at the completion of each operating session and just before changing radios would assure compliance.

73,

Dave, AA6YQ


Minor nit - LotW inconsistency report

Scott Stembaugh
 

When request a report for inconsistencies in an LotW sync it would be nice if the same inconsistency was reported in a similar format. 

  2020-01-04  21:08:41           xxxx     40M      RTTY              N9LJX    log vs LotW mismatch: logged CQZ = 5, LotW CQZ = 04
  2020-01-04  21:08:41           xxxx     40M      RTTY              N9LJX    WAZ candidate specifies a CQ zone 04 that doesn't match the logged QSO's CQ zone 5

In this case the LotW and Logged zones are reported in different order.  Same information, just listed in opposite order.

--scott


Re: Manual updates Question

W8UV Phil
 

Tnx Dave,

Just what I was looking for.

Phil  W8UV

On 1/10/2020 10:26 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

When a Manual , lets use the Commander, goes from v13.9.0 to v14.4.0 is there a website That tells what has been updated/added.

+ Yes. When I make a new release public, I post its "release note" here on the DXLab Discussion Group. Here's the release note for Commander 14.4.0 posted on the day it was announced:

<https://groups.io/g/DXLab/message/173728>

Release notes for every public release are available via the "Release Notes" column of the table in

<https://www.dxlabsuite.com/download.htm#Availability%20announcements>

+ For example, all Commander Release Notes are available from

<https://www.dxlabsuite.com/commander/ReleaseNotes/>

+ The release note for Commander 14.4.0 is available from

<https://www.dxlabsuite.com/commander/ReleaseNotes/1440.txt>


73,

Dave, AA6YQ




Re: Manual updates Question

Dave AA6YQ
 

+ AA6YQ comments below

When a Manual , lets use the Commander, goes from v13.9.0 to v14.4.0 is there a website That tells what has been updated/added.

+ Yes. When I make a new release public, I post its "release note" here on the DXLab Discussion Group. Here's the release note for Commander 14.4.0 posted on the day it was announced:

<https://groups.io/g/DXLab/message/173728>

Release notes for every public release are available via the "Release Notes" column of the table in

<https://www.dxlabsuite.com/download.htm#Availability%20announcements>

+ For example, all Commander Release Notes are available from

<https://www.dxlabsuite.com/commander/ReleaseNotes/>

+ The release note for Commander 14.4.0 is available from

<https://www.dxlabsuite.com/commander/ReleaseNotes/1440.txt>


73,

Dave, AA6YQ


Manual updates Question

W8UV Phil
 

When a Manual , lets use the Commander,  goes from v13.9.0 to v14.4.0 is there a website
That tells what has been updated/added.
Phil  W8UV


Re: DX Keeper Filte

Dave AA6YQ
 

+ AA6YQ comments below

In DXKeeper-->Log Qso's--.Adv tab...When I go down to Mode Filter and hover mouse over FT4 it pops up and says "check to show qso's in FT8" and if I hover over FT8 it says "check to show qso's in FT4" All other filter boxes see to be ok. Which is correct???

+ The FT4 and FT8 checkboxes are correctly labeled; it's the explanatory popups ("tooltips", in Microsoft parlance) that are incorrect. This defect is corrected in the next version of DXKeeper.

+ Thanks!

73,

Dave, AA6YQ


DX Keeper Filte

Jim-N7ESU
 

In DXKeeper-->Log Qso's--.Adv tab...When I go down to Mode Filter and hover mouse over FT4 it pops up and says "check to show qso's in FT8" and if I hover over FT8 it says "check to show qso's in FT4" All other filter boxes see to be ok. Which is correct??? 
Jim
n7esu


Re: N1MM DXKeeper Gateway Problem

Dave AA6YQ
 

+ AA6YQ comments below

I am running Windows 10, SmartSDR 2.6.1 with N1MM+ 1.0.8063.0 and am trying to start N1MM_DXK_GW.exe. When I start the Gateway, I
get the following message "Error: Address in use". What do I need to do to eliminate this problem????

+ The N1MM-DXKeeper gateway connects to N1MM via port 12060. If another application is already using that port, the "Error: Address
in use" message will appear.

+ Run the Windows Task Manager to check for an existing instance of the N1MM-DXKeeper gateway; if you find one, direct the Task
Manager to terminate it.

+ Occasionally, Windows gets confused about port usage; you can clear this by rebooting Windows.

73,

Dave, AA6YQ


Re: DXview remains in memory

Dave AA6YQ
 

+ AA6YQ comments below

Just noticed that sometimes when I start DXlab suite using Launcher it snags saying DXview is already running. It's not showing on the task bar but using task manager it shows up not as an app but a background process. I can kill it but then have to re-start the whole suite. This is not a big problem.
I have discovered a way to make this happen. Start Launcher from the task bar. Start DXview from Launcher. Hover over the DXview icon on the task bar. When the popup comes up kill (close) it from there. Then close Launcher. Checking with Task Manager will show DXview still running as a back ground process. This is reproducible. OK so the work round is "Don't close DXview that way." But occasionally I have closed things quickly using the popups and not noticed snags with other things. As far as I'm aware it doesn't happen with other parts of the DXsuite.
Dave, Just thought you might want to know. Thanks for a great set of programs.

+ Thanks, Tony, but I cannot replicate that behavior here.

+ Please do the following:

1. start the Launcher

2. start DXKeeper

3. start the Windows Task Manager, and select is Applications tab so you can see the list of running applications, which should include both DXView and the DXLab Launcher

4. terminate DXView from the Windows Task Bar as you describe above

+ How long does it take for DXView's entry to disappear from the Windows Task Manager's Applications tab?

73,

Dave, AA6YQ


Re: Contest logging

Dave AA6YQ
 

+ AA6YQ comments below

It's now working OK, the problem was in an "unofficial" version of N1MM-DXK GW which had a higher version number. I'm now using the
oficial v.1.1.4 which works as I would like.

+ The N1MM-DXKeeper Gateway was originally developed by Matthias LA0FA, who decided to halt development and sent me the source code
for version 1.0.8. I continued development, beginning with version 1.0.9. and continuing through the current 1.1.4.

+ Unfortunately, I only later discovered that Matthias had released versions 1.1.4, 1.1.5, and 1.1.6 -- which has caused some
confusion. To mitigate this confuscion, I have updated the Gateway's documentation with a screenshot:

<https://www.dxlabsuite.com/N1MM-DXKeeper/index.htm>


A slight error in the documentation, pressing enter in N1MM+ only logs to DXKeeper if it will also log in N1MM+, ie all the fields
are acceptable to
N1MM+.

+ Thanks! I updated the "Operation" section of the Gateway's documentation to state

"In N1MM or N1MM+, if typing a callsign and striking the Enter key logs the QSO to N1MM or N1MM+ respectively, the Gateway will also
log the QSO to DXKeeper."

73,

Dave, AA6YQ


Re: Multiple radios and "myQTH ID's"

Dave AA6YQ
 

+ AA6YQ comments below

I am setup with multiple radios (on two computers at home) and a remote radio at a town nearby, controlled using RCForb server/client.

Is there a way to have DXKeeper set the default myQTH ID from which radio is chosen in commander. (Not just append a radio name, but actually change the myQTH ID)

+ No.

Examples of default myQTH ID's used:

Home:K3

Home:K2

Westminster: Virt 590

+ If you replace the myQTH whose ID is

Westminster: Virt 590

+ with a myQTH whose ID is

Home: Virt 590

+ Then you can use the existing mechanism to automatically change the "Default myQTH ID" when you select a radio in Commander:

<https://www.dxlabsuite.com/dxlabwiki/LogTransceiverInfo>

+ Note that the "Home: Virt 590" myQTH would still specify Westminister as the location; only the "myQTH ID" would be changed.


I would also like the LOTW station location to change with commander radio changes

Examples:

myQTH ID station location

Home:K3 HOME

Westminster:Virt 590 Westminster

W4AAW Round Hill, VA

+ If you specify the appropriate "LoTW Station Location" in the LoTW selector of each "my QTH", DXKeeper will use the appropriate "Callsign Certificate" and "Station Location" as a function of the logged QSO's "Station Callsign" and "myQTH ID" items, respectively. see
<https://www.dxlabsuite.com/dxlabwiki/LotWMultipleCallsignsLocations>


I have all of the LOTW station locations setup, and the different default myQTH ID's , but have to remember to change them when I change radios in commander.

+ Implementing the above recommendations would provide the desired automation: select the radio in Commander, and start logging QSOs.

+ Note that all QSOs being submitted to LoTW in one batch must have the same "Station Callsign" and the same "myQTH ID". This is a non-issue if each QSOs is being submitted as it is logged. If you're using "Add Requested" to populate the QSL Queue with a batch of QSOs to be submitted to LoTW, doing so at the completion of each operating session and just before changing radios would assure compliance.

73,

Dave, AA6YQ


N1MM DXKeeper Gateway Problem

Stewart Lewis
 

I am running Windows 10, SmartSDR 2.6.1 with N1MM+ 1.0.8063.0 and am trying to start N1MM_DXK_GW.exe.  When I start the Gateway, I get the following message Error: Address in use.  What do I need to do to eliminate this problem????

73

Stewart W0SHL





DXview remains in memory

Tony Dixon G4CJC
 

Just noticed that sometimes when I start DXlab suite using Launcher it snags saying DXview is already running. It's not showing on the task bar but using task manager it shows up not as an app but a background process. I can kill it but then have to re-start the whole suite. This is not a big problem.
I have discovered a way to make this happen. Start Launcher from the task bar. Start DXview from Launcher. Hover over the DXview icon on the task bar. When the popup comes up kill (close) it from there. Then close Launcher. Checking with Task Manager will show DXview still running as a back ground process. This is reproducible. OK so the work round is "Don't close DXview that way." But occasionally I have closed things quickly using the popups and not noticed snags with other things. As far as I'm aware it doesn't happen with other parts of the DXsuite.
Dave, Just thought you might want to know. Thanks for a great set of programs.
73
Tony G4CJC


Re: Contest logging

Brian D
 

Thanks Dave and Rich,

It's now working OK, the problem was in an "unofficial" version of N1MM-DXK
GW which had a higher version number. I'm now using the oficial v.1.1.4
which works as I would like.

A slight error in the documentation, pressing enter in N1MM+ only logs to
DXKeeper if it will also log in N1MM+, ie all the fields are acceptable to
N1MM+.

73

Brian G3VGZ G8AOE G3T


"ve3ki" <ve3iay@...> wrote:

...and if you have made the mistake of using the same N1MM+ database for
contacts made using two different call signs, the "my call" would be wrong
for one of them. If you use more than one call sign, you need to use a
separate N1MM+ database file for each call sign you use.

73, Rich VE3KI

On Wed, Jan 8, 2020 at 09:12 PM, Dave AA6YQ wrote:


+ AA6YQ comments below

Until recently for most contests I export an ADIF file from N1MM and
load this into DxKeeper afterwards.

This works, and inserts the correct callsign into "station callsign" in
DXKeeper.

Recently I have been using N1MM-DXK GW v1.1.6 to transfer live into
DXKeeper.

+ The current version of the N1MM-to-DXKeeper gateway is 1.1.4. It is
available via

< https://www.dxlabsuite.com/N1MM-DXKeeper/index.htm >

+ The gateway accepts "Contact" messages broadcast by N1MM:

https://n1mmwp.hamdocs.com/appendices/external-udp-broadcasts/#contact

+ The "Contact" message's "my call" item is recorded by DXKeeper as the
QSO's "Station Callsign".

73,

Dave, AA6YQ



--
Brian D
G3VGZ