Topics

N1MM-DXKeeper Gateway version 1.1.6


Dave AA6YQ
 

This version

- correctly handles the multiple QSOs created by N1MM when a county line QSO is logged during a State QSO Party contest

- provides an option to direct DXKeeper to query its currently configured callbook and augment the information in the logged QSO
with the results of that query

- provides options to direct DXKeeper to automatically upload each logged QSO to eQSL.cc, LoTW, and Club Log

- maintains a visible log of completed operations

- provides an option to force the creation and maintenance of a diagnostic errorlog, and a button to display the errorlog

- updates the documentation file <http://www.dxlabsuite.com/N1MM-DXKeeper/index.htm>;


To obtain version 1.1.6 of the N1MM-DXKeeper Gateway, download its zip archive from

<https://www.dxlabsuite.com/N1MM-DXKeeper/N1MM_DXK_GW.zip>;

and extract the application it contains into the folder of your choice.


I am not a contester, but I did test this version by logging multiple QSOs from N1MM+ version 1.0.8701

Many thanks to all who contributed to the understanding of N1MM's handling of county line QSOs in State QSO Parties!

73,

Dave, AA6YQ


Dave AA6YQ
 

68 of 70 engines available via VirusTotal found no malware in N1MM_DXK_GW.exe

0 of 15 engines available via Jotti found no malware in N1MM_DXK_GW.exe

N1MM_DXK_GW.exe has been submitted to Microsoft Security Intelligence; it generally takes them 12 hours to scan a submitted file.

73,

Dave, AA6YQ

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: Friday, October 23, 2020 12:10 AM
To: DXLab@groups.io
Subject: [DXLab] N1MM-DXKeeper Gateway version 1.1.6

This version

- correctly handles the multiple QSOs created by N1MM when a county line QSO is logged during a State QSO Party contest

- provides an option to direct DXKeeper to query its currently configured callbook and augment the information in the logged QSO
with the results of that query

- provides options to direct DXKeeper to automatically upload each logged QSO to eQSL.cc, LoTW, and Club Log

- maintains a visible log of completed operations

- provides an option to force the creation and maintenance of a diagnostic errorlog, and a button to display the errorlog

- updates the documentation file <http://www.dxlabsuite.com/N1MM-DXKeeper/index.htm>;


To obtain version 1.1.6 of the N1MM-DXKeeper Gateway, download its zip archive from

<https://www.dxlabsuite.com/N1MM-DXKeeper/N1MM_DXK_GW.zip>;

and extract the application it contains into the folder of your choice.


I am not a contester, but I did test this version by logging multiple QSOs from N1MM+ version 1.0.8701

Many thanks to all who contributed to the understanding of N1MM's handling of county line QSOs in State QSO Parties!

73,

Dave, AA6YQ









--
This email has been checked for viruses by AVG.
https://www.avg.com


Phil Deaver
 

Dave-
Thank you for your quick response for the update to N1MM to DxKeeper Gateway. I'm trying it out now and really like the new log feature.
One issue though. I get a popup from DXkeeper "there is no log page display sort specified, sorting the log page display by QSO date". This popup puts a halt to the contacts transferring to DXkeeper and LOTW. If I press OK, I get one more contact transferred and then the message again. It doesn't appear to lose any, it just holds them. I had to press it twenty times this morning to clear the logjam.  I've looked at the menus and don't see one to indicate a default sort to prevent the popup from appearing. I've been seeing the issue lately and I think I've seen it before this latest revision. 
Thanks again for the quick revision to N1MM to Dxkeeper Gateway.
Phil WR7T


Dave AA6YQ
 

+ AA6YQ comments below
Thank you for your quick response for the update to N1MM to DxKeeper Gateway. I'm trying it out now and really like the new log feature.
One issue though. I get a popup from DXkeeper "there is no log page display sort specified, sorting the log page display by QSO date". 
+ In the Sort panel in the lower-left corner of the "Log QSOs" tab on DXKeeper's Main window, select "UTC".

     73,

           Dave, AA6YQ


Kent N6WT
 

Dave

While using the gateway, if I enter a callsign in N1MM and hit enter the info is populated in N1MM but then the focus goes to the gateway application. I have to click on the N1MM log window so I can hit enter to log the qso. Is there a way to keep the gateway from taking the focus? 

Thanks
73
Kent
N6WT


On Sat, Oct 24, 2020 at 11:56 AM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below
Thank you for your quick response for the update to N1MM to DxKeeper Gateway. I'm trying it out now and really like the new log feature.
One issue though. I get a popup from DXkeeper "there is no log page display sort specified, sorting the log page display by QSO date". 
+ In the Sort panel in the lower-left corner of the "Log QSOs" tab on DXKeeper's Main window, select "UTC".

     73,

           Dave, AA6YQ


Dave AA6YQ
 

+ AA6YQ comments below
While using the gateway, if I enter a callsign in N1MM and hit enter the info is populated in N1MM but then the focus goes to the gateway application. I have to click on the N1MM log window so I can hit enter to log the qso. Is there a way to keep the gateway from taking the focus?
+ The new "Operation log" added in  Gateway1.1.6 may be responsible for that; I will investigate...

        73,

             Dave, AA6YQ


Ignacio Martinez
 

Dave,
 
I have the same problem as Kent, if you use the space to change fields, the same thing happens, works fine (in my case Pathfinder to perform "lookup" operations) but you lose the focus.
 
Thanks
73 de Ignacio, EA4OR.


Dave AA6YQ
 

+ AA6YQ comments below

I have the same problem as Kent, if you use the space to change fields, the same thing happens, works fine (in my case Pathfinder to perform "lookup" operations) but you lose the focus.

+ I've sent Kent N6WT and Phil WR7T a new version of the Gateway that should prevent "focus theft". I just sent the new version to you as well; please let me know how it goes.

73,

Dave, AA6YQ


bob-w9zv
 

I had the same problem, Focus Stealing... which rendered the N1MM-DXK-GW unusable.
I hope this fix works.

to get around this for this weekend's CQWW I had to revert to v1.1.4 which did NOT steal focus.    Of course, one can just export/import post contest i guess.

however, i still had the  "</contactinfo>: Foreign application won't perform DDE method or operation"  fault/error message which results in the QSO NOT getting logged in DXK  four times over the contest period.   I thought v1.1.6 would fix it, but apparently not. 

maybe get rid of the entire DDE mechanism and use a diff IPC mechanism like TCP/IP instead??   


Dave AA6YQ
 

+ AA6YQ comments below

Subject: Re: [DXLab] N1MM-DXKeeper Gateway version 1.1.6

I had the same problem, Focus Stealing... which rendered the N1MM-DXK-GW unusable.
I hope this fix works.

+ The three ops to whom I have sent version 1.1.6 of the Gateway report that the focus stealing has been eliminated with one exception: Pathfinder steals focus on the first lookup, but not on subsequent lookups. I am investigating.

to get around this for this weekend's CQWW I had to revert to v1.1.4 which did NOT steal focus. Of course, one can just export/import post contest i guess.

however, i still had the "</contactinfo>: Foreign application won't perform DDE method or operation" fault/error message which results in the QSO NOT getting logged in DXK four times over the contest period.

+ As I pointed out to you in my response to your report of this behavior in November 2019, the above error message means that the Gateway directed Windows to convey message containing a QSO to DXKeeper, but Windows could not do so. I also pointed out that Windows has a long track record for failing to deliver such messages when it's "in trouble" -- e.g. does not have sufficient memory available.

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

+ If you've done nothing to correct the conditions responsible for this message (insufficient resources), then it would be surprising if it stopped happening.


I thought v1.1.6 would fix it, but apparently not.

+ Are you reporting that you experienced the above error message while running version 1.1.6 of the Gateway?


maybe get rid of the entire DDE mechanism and use a diff IPC mechanism like TCP/IP instead??

+ As I posted here last week, version 1.1.6 of the N1MM-DXKeeper Gateway uses TCP (instead of DDE) to convey QSOs to DXKeeper.

<https://groups.io/g/DXLab/message/196903>;



73,

Dave, AA6YQ


Kent N6WT
 

Dave

During the CQ-WW-SSB contest, I was a really being casual. I was only looking for DX that I need to fill bands that I needed for the year. For the contest I only logged 117 Q's. I did have 2 instances of a TCP error that showed up in the gateway where a qso was not transferred into DXK, one right after the other, but after that no other problems. 

I then used the gateway in the K1USN Slow Speed CW Contest. I logged 32 contacts over about 3/4 of an hour. The gateway performed perfectly!.

Thanks
73
Kent
N6WT


On Mon, Oct 26, 2020 at 12:24 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

Subject: Re: [DXLab] N1MM-DXKeeper Gateway version 1.1.6

I had the same problem, Focus Stealing... which rendered the N1MM-DXK-GW unusable.
I hope this fix works.

+ The three ops to whom I have sent version 1.1.6 of the Gateway report that the focus stealing has been eliminated with one exception: Pathfinder steals focus on the first lookup, but not on subsequent lookups. I am investigating.

to get around this for this weekend's CQWW I had to revert to v1.1.4 which did NOT steal focus.    Of course, one can just export/import post contest i guess.

however, i still had the  "</contactinfo>: Foreign application won't perform DDE method or operation"  fault/error message which results in the QSO NOT getting logged in DXK  four times over the contest period.

+ As I pointed out to you in my response to your report of this behavior in November 2019, the above error message means that the Gateway directed Windows to convey message containing a QSO to DXKeeper, but Windows could not do so. I also pointed out that Windows has a long track record for failing to deliver such messages when it's "in trouble" -- e.g. does not have sufficient memory available.

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

+ If you've done nothing to correct the conditions responsible for this message (insufficient resources), then it would be surprising if it stopped happening.


I thought v1.1.6 would fix it, but apparently not.

+ Are you reporting that you experienced the above error message while running version 1.1.6 of the Gateway?


maybe get rid of the entire DDE mechanism and use a diff IPC mechanism like TCP/IP instead??   

+ As I posted here last week, version 1.1.6 of the N1MM-DXKeeper Gateway uses TCP (instead of DDE) to convey QSOs to DXKeeper.

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



            73,

                   Dave, AA6YQ








bob-w9zv
 

+ Are you reporting that you experienced the above error message while running version 1.1.6 of the Gateway?
i was responding in concurrence with the "stealing focus" issue, which (because it made it unusable) forced me to back down to v114.

i will look thru the error log (which has 116 and 114 entries in it) for the DDE error to be sure it only occurred when 114 was in place.    If 116 replaced DDE with TCP, obviously it cannot be happening.   

i wrote a couple apps to work with DDE years ago, and it had similar issues where it would not work in maybe 1 of 1000 times.  i dont recall the details, its far too long ago.  in my case I had to write a DDE server for a customer's DDE reporting client for some stat updates, and it missed one once and a while.   In our case, it didnt make much diff as the next update would re-write the stale entry anyways and it wasnt a deal killer problem.   missing a single update just wasn't critical.   we moved on later with an entirely different mechanism as well, never getting the the bottom of the DDE issue. 

my windows box here (not a vm) has far more resources available than is required so hard to imagine it was "in trouble".   the thing is dedicated to the ham radio chores alone, and is coasting in cpu cycles, awash in memory & disk (storage, I/O).  There wasn't much running on it other than n1mm/dxlab.   

exploring options a little bit, I did go to LA0FA's web site http://www.la0fa.com/content/home/default4.asp?Content_ID=14  (which is also v116) and downloaded the GW zip he has there thinking maybe I'd fiddle with it a bit.  but i no longer have a vb6 environment to play in and saw this topic so i abandoned any ideas for diddling with it since its fixed.   getting rid of DDE was/is the answer... 

if 116 replaced DDE IPC mechanism with TCP, I would think thats the end of it... RIP DDE... glad the conversion was made. 

+ As I posted here last week, version 1.1.6 of the N1MM-DXKeeper Gateway uses TCP (instead of DDE) to convey QSOs to DXKeeper. https://groups.io/g/DXLab/message/196903>

agreed - if you depend on delivery with UDP the appl itself must be responsible for implementing reliability, where TCP its guaranteed. while UDP on the same box should be very reliable, still no way to guarantee delivery... 

-bob


Dave AA6YQ
 

+ AA6YQ comments below

During the CQ-WW-SSB contest, I was a really being casual. I was only looking for DX that I need to fill bands that I needed for the year. For the contest I only logged 117 Q's. I did have 2 instances of a TCP error that showed up in the gateway where a qso was not transferred into DXK, one right after the other, but after that no other problems.

+ What was the text of the error message?

+ Is there an errorlog.txt file in your Gateway folder? If so, please attach it to an email message and send that message to me via

aa6yq (at) ambersoft.com

73,

Dave, AA6YQ


Kent N6WT
 

Dave

I think it said something about a TCP error and that the call sign had not been logged. I did not take much note of since I did not notice as it happened but a few call signs later. 

There was no error log. 

Thanks
73
Kent
N6WT


On Mon, Oct 26, 2020 at 3:19 PM Dave AA6YQ <aa6yq@...> wrote:
+ AA6YQ comments below

During the CQ-WW-SSB contest, I was a really being casual. I was only looking for DX that I need to fill bands that I needed for the year. For the contest I only logged 117 Q's. I did have 2 instances of a TCP error that showed up in the gateway where a qso was not transferred into DXK, one right after the other, but after that no other problems.

+ What was the text of the error message?

+ Is there an errorlog.txt file in your Gateway folder? If so, please attach it to an email message and send that message to me via

aa6yq (at) ambersoft.com

        73,

                Dave, AA6YQ







Dave AA6YQ
 

# more AA6YQ comments below

+ Are you reporting that you experienced the above error message while running version 1.1.6 of the Gateway?
i was responding in concurrence with the "stealing focus" issue, which (because it made it unusable) forced me to back down to v114.

i will look thru the error log (which has 116 and 114 entries in it) for the DDE error to be sure it only occurred when 114 was in place. If 116 replaced DDE with TCP, obviously it cannot be happening.

# DDE is still used to detect whether DXKeeper is running, but DDE errors should not occur when a QSO is being conveyed from N1MM to DXKeeper. Note that this change from DDE to TCP was made because of the interference between UDP and DDE, not because anyone other than you ever reported DDE errors.


i wrote a couple apps to work with DDE years ago, and it had similar issues where it would not work in maybe 1 of 1000 times. i dont recall the details, its far too long ago. in my case I had to write a DDE server for a customer's DDE reporting client for some stat updates, and it missed one once and a while. In our case, it didnt make much diff as the next update would re-write the stale entry anyways and it wasnt a deal killer problem. missing a single update just wasn't critical. we moved on later with an entirely different mechanism as well, never getting the the bottom of the DDE issue.


# DXLab applications have relied heavily on DDE for interoperation since their introduction in 2001. Other than in cases where Windows is under duress, DDE has been reliable. Because DDE typically involves collaboration among more than one asynchronous process, concurrency defects in applications -- e.g. race conditions, starvation, unanticipated code paths -- often produce intermittent errors that are erroneously blamed on DDE.


my windows box here (not a vm) has far more resources available than is required so hard to imagine it was "in trouble".

the thing is dedicated to the ham radio chores alone, and is coasting in cpu cycles, awash in memory & disk (storage, I/O). There wasn't much running on it other than n1mm/dxlab.

# Windows employs many data structures that are limited in size or capacity. If one or more of these data structures run low or become exhausted, trouble ensues. Absent a course in Windows Internals and constant monitoring with appropriate tools, users should reboot Windows at a frequency that maintains reliable operation. I reboot weekly.


exploring options a little bit, I did go to LA0FA's web site http://www.la0fa.com/content/home/default4.asp?Content_ID=14 (which is also v116) and downloaded the GW zip he has there thinking maybe I'd fiddle with it a bit. but i no longer have a vb6 environment to play in and saw this topic so i abandoned any ideas for diddling with it since its fixed. getting rid of DDE was/is the answer...

# That code base is several years out of date.


if 116 replaced DDE IPC mechanism with TCP, I would think thats the end of it... RIP DDE... glad the conversion was made.

+ As I posted here last week, version 1.1.6 of the N1MM-DXKeeper Gateway
+ uses TCP (instead of DDE) to convey QSOs to DXKeeper.
+ https://groups.io/g/DXLab/message/196903>;

agreed - if you depend on delivery with UDP the appl itself must be responsible for implementing reliability, where TCP its guaranteed. while UDP on the same box should be very reliable, still no way to guarantee delivery...

# The observed behavior was that if the Gateway version 1.1.5 process was in DDE rendezvous delivering a QSO to DXKeeper when a new UDP message arrived from N1MM, Windows discarded the UDP message -- which is perfectly legal. This only became problematic when N1MM began emitting 4 UDP messages for a logged QSO that specifies 4 counties.

73,

Dave, AA6YQ