Date   

Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

+ AA6YQ comments below

There are 58 (+/-) QSO parties with county abbreviations supported by N1MM+. Those abbreviations range between 3 and 6 characters in length - four characters was for the particular QSO party Phil logged the contacts in (I'm guessing it was the Illinois QSO Party). There is a file distributed with the N1MM Logger+ program (actually with each program update) that contains lists of the abbreviations used in all of those contests, but that list does not indicate what the actual county name is, only which abbreviations are considered valid in each contest. The correspondence between the abbreviations and the full county names would presumably be found on the applicable contest sponsor web sites. The list could change from time to time depending on whether the sponsors for one of the contests choose to change their abbreviation list or format for some reason. For these reasons, I don't think this list would be useful for your suggested purpose.

+ if Jim AD1C can maintain an application that performs the county name "translations" in batch, then it should be possible to perform them interactively. I'll ask him about it.

If Phil could report the exact times logged in DXKeeper for the two QSOs, that would help pin down what is happening. If they are identical to the second, N1MM+ must be issuing <contactinfo> messages with identical times, which would be surprising given that it logs them with different times, but not impossible. If they differ by two seconds (or four or six seconds), the issue is likely with the UDP message transmission / buffering / decoding process.

In any case, my own recommendation would be for people wanting to transfer contacts from these contests to use the ADIF export / AD1C county code conversion / ADIF import procedure. Not only is it less likely to have problems, the visibility of the ADIF files makes it much easier to diagnose and debug any problems that might arise,

+ I'll add a "Log debugging info" option to the next version of the N1MM-DXKeeper Gateway so that we can better track down problems like this one.

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

* More AA6YQ comments below


+ There's clearly a defect lurking here; thanks for reporting the
behavior so that it can be tracked down and corrected.
It is likely in the data N1MM+ emits in the UDP broadcast. Any way to check the *TIME* in the four QSOs N1MM has logged? I don't believe DXKeeper considers the "Exchange1"/"SRX_STRING" data in its duplicate checking routine (only date/time/call/band/frequency/mode) thus the four N1MM+ "QSO" records would each need to have unique times. If any two QSOs were recorded with the same time to the second, the second QSO record would probably be ignored as a duplicate by DXKeeper.

* Only if duplicate checking were enabled on the Main window's "Import QSOs" tab, which is not recommended given the performance penalty.

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

+ AA6YQ comments below

have you allowed for the unfortunate behaviour of the VB6 UDP client that concatenates UDP datagrams into one response buffer?

+ Thanks for the reminder, Bill. It looks like the original developer of the N1MM-DXKeeper gateway handled that correctly.

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

ve3ki
 

Dave,

There are 58 (+/-) QSO parties with county abbreviations supported by N1MM+. Those abbreviations range between 3 and 6 characters in length - four characters was for the particular QSO party Phil logged the contacts in (I'm guessing it was the Illinois QSO Party). There is a file distributed with the N1MM Logger+ program (actually with each program update) that contains lists of the abbreviations used in all of those contests, but that list does not indicate what the actual county name is, only which abbreviations are considered valid in each contest. The correspondence between the abbreviations and the full county names would presumably be found on the applicable contest sponsor web sites. The list could change from time to time depending on whether the sponsors for one of the contests choose to change their abbreviation list or format for some reason. For these reasons, I don't think this list would be useful for your suggested purpose.

If Phil  could report the exact times logged in DXKeeper for the two QSOs, that would help pin down what is happening. If they are identical to the second, N1MM+ must be issuing <contactinfo> messages with identical times, which would be surprising given that it logs them with different times, but not impossible. If they differ by two seconds (or four or six seconds), the issue is likely with the UDP message transmission / buffering / decoding process.

In any case, my own recommendation would be for people wanting to transfer contacts from these contests to use the ADIF export / AD1C county code conversion / ADIF import procedure. Not only is it less likely to have problems, the visibility of the ADIF files makes it much easier to diagnose and debug any problems that might arise,

73,
Rich VE3KI


On Sun, Oct 18, 2020 at 08:26 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
I can't tell you for sure whether N1MM+ emits one <contactinfo> message or four, but from the N1MM+ manual:
"Separate QSOs will appear in your log, one for each county."
If four separate QSOs are logged, it might seem reasonable to expect four <contactinfo> messages in rapid succession, but without setting up a test I cannot be sure about that.

+ The 3 possibilities are

1. N1MM+ only sent 2 <contactinfo> messages (defect in N1MM+)

2. N1MM+ sent 4 <contactinfo> messages, but only 2 of those messages were actually delivered the N1MM_DXKeeper gateway because the UDP protocol that N1MM+ employs to deliver <contactinfo> messages is a "best efforts" protocol, with no guarantee of delivery.

3. N1MM+ sent 4 <contactinfo> messages, and all 4 of those messages were actually delivered to the the N1MM_DXKeeper gateway, but a defect in gateway or DXKeeper resulted only two QSOs being logged.

+ I would be helpful if someone familiar with N1MM+, the N1MM-DXKeeper Gateway, and state QSO parties could attempt to replicate this scenario so that we can determine what's going on, and correct whatever defects we find.


In any case, the "county" data exported by N1MM+ is not exported as county data. It is exported as "Exchange1" data, which I believe the Gateway translates into the SRX_STRING field. If there were four <contactinfo> messages, there should be four QSOs imported into DXKeeper, each with a different four-letter exchange abbreviation stored in the SRX_STRING field. There would be nothing stored in the County field, because N1MM+ does not export ADIF county data, it exports received contest exchange abbreviations, which are not valid county data in accordance with the ADIF specification that DXKeeper uses.

There is a program written by AD1C that can read an ADIF file exported by N1MM+ (or other contest logging programs) and convert the contest exchange abbreviation data recorded by the logging program into a valid ADIF County field -- see <http://software.ad1c.us/ADIF_County/index.html>. The way to use this to get the county data into DXKeeper would be by turning off the Gateway during the contest, exporting an ADIF file from N1MM+ after the contest, running it through the conversion program, and then importing the converted ADIF file into DXKeeper.

+ Alternatively, I could add that capability to the N1MM-DXKeeper Gateway. Where would I find the list of state QSO parties for which N1MM records 4-letter county abbreviations in SRX_STRING field? Where would I find a list of the 4-letter county abbreviations and their full county names?

My understanding of how county-line QSOs are logged in N1MM+ (see <https://n1mmwp.hamdocs.com/manual-supported/contests-setup/setup-qsop-contests/#rover-mobile-and-county-line-support>)
is that there would be four separate QSOs logged in N1MM+ at two-second intervals, resulting in four separate QSOs in the ADIF file and therefore in DXKeeper. When uploaded to LotW, these would be recorded as four otherwise identical QSOs at two-second intervals. Note that information about the other station's location (state/county/country/zone/IOTA reference) from your log is not uploaded to LotW - that kind of information comes only from the other station's upload. To have the county data recorded correctly in LotW, the other station would have to upload each of the four separately-logged QSOs signed with a separate station location, one for each county. Also, while the times of those four QSOs would also be separated by two-second intervals, it is unlikely that the exact time logged would be identical to the second at both ends of the QSO, meaning matching up the QSO records between the two stations might be a bit trickier than usual.

+ LoTW only requires QSO start times to match within 30 minutes, so the "log one QSO every 2 seconds" approach will not prevent LoTW confirmations, so long as your QSO partner submits 4 QSOs to LoTW, each using a Station Location that specifies the correct US Country. At present, however, LoTW confirmations do not count towards CQ's USA-CA award (worked all US Counties).

+ Many thanks for the helpful response, Rich!

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

Joe Subich, W4TV
 

+ There's clearly a defect lurking here; thanks for reporting the
behavior so that it can be tracked down and corrected.
It is likely in the data N1MM+ emits in the UDP broadcast. Any way
to check the *TIME* in the four QSOs N1MM has logged? I don't believe
DXKeeper considers the "Exchange1"/"SRX_STRING" data in its duplicate
checking routine (only date/time/call/band/frequency/mode) thus the
four N1MM+ "QSO" records would each need to have unique times. If
any two QSOs were recorded with the same time to the second, the
second QSO record would probably be ignored as a duplicate by DXKeeper.

N1MM should probably assign a unique start time to each "QSO" as a
matter of course otherwise LotW will also have heartburn with any
records that share start times.

73,

... Joe, W4TV


On 2020-10-18 8:11 PM, Dave AA6YQ wrote:
+ AA6YQ comments below
N1MM logged four QSOs without my interaction.
The county data was in the exchange I received from the IL station. The QSO's that made it into dxkeeper show the exchange in the RX info section of the contest panel, but only the first two of the four qso's show up.
+ Thanks, Phil! That clarifies the situation.
======I was impressed that N1MM parsed it =======+ To what does the word "it" refer?
I was impressed that N1MM took the exchange from one QSO and logged it as four separate QSO's with different counties, and giving me credit for working those 4 counties in the QSO party.
It's not a problem for me. I thought I would just report my findings in case anyone was interested.
+ There's clearly a defect lurking here; thanks for reporting the behavior so that it can be tracked down and corrected.
73,
Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

g4wjs
 

On 19/10/2020 01:26, Dave AA6YQ wrote:
+ AA6YQ comments below
I can't tell you for sure whether N1MM+ emits one <contactinfo> message or four, but from the N1MM+ manual:
"Separate QSOs will appear in your log, one for each county."
If four separate QSOs are logged, it might seem reasonable to expect four <contactinfo> messages in rapid succession, but without setting up a test I cannot be sure about that.

+ The 3 possibilities are

1. N1MM+ only sent 2 <contactinfo> messages (defect in N1MM+)

2. N1MM+ sent 4 <contactinfo> messages, but only 2 of those messages were actually delivered the N1MM_DXKeeper gateway because the UDP protocol that N1MM+ employs to deliver <contactinfo> messages is a "best efforts" protocol, with no guarantee of delivery.

3. N1MM+ sent 4 <contactinfo> messages, and all 4 of those messages were actually delivered to the the N1MM_DXKeeper gateway, but a defect in gateway or DXKeeper resulted only two QSOs being logged.

+ I would be helpful if someone familiar with N1MM+, the N1MM-DXKeeper Gateway, and state QSO parties could attempt to replicate this scenario so that we can determine what's going on, and correct whatever defects we find.


In any case, the "county" data exported by N1MM+ is not exported as county data. It is exported as "Exchange1" data, which I believe the Gateway translates into the SRX_STRING field. If there were four <contactinfo> messages, there should be four QSOs imported into DXKeeper, each with a different four-letter exchange abbreviation stored in the SRX_STRING field. There would be nothing stored in the County field, because N1MM+ does not export ADIF county data, it exports received contest exchange abbreviations, which are not valid county data in accordance with the ADIF specification that DXKeeper uses.

There is a program written by AD1C that can read an ADIF file exported by N1MM+ (or other contest logging programs) and convert the contest exchange abbreviation data recorded by the logging program into a valid ADIF County field -- see<http://software.ad1c.us/ADIF_County/index.html>. The way to use this to get the county data into DXKeeper would be by turning off the Gateway during the contest, exporting an ADIF file from N1MM+ after the contest, running it through the conversion program, and then importing the converted ADIF file into DXKeeper.

+ Alternatively, I could add that capability to the N1MM-DXKeeper Gateway. Where would I find the list of state QSO parties for which N1MM records 4-letter county abbreviations in SRX_STRING field? Where would I find a list of the 4-letter county abbreviations and their full county names?

My understanding of how county-line QSOs are logged in N1MM+ (see<https://n1mmwp.hamdocs.com/manual-supported/contests-setup/setup-qsop-contests/#rover-mobile-and-county-line-support>)
is that there would be four separate QSOs logged in N1MM+ at two-second intervals, resulting in four separate QSOs in the ADIF file and therefore in DXKeeper. When uploaded to LotW, these would be recorded as four otherwise identical QSOs at two-second intervals. Note that information about the other station's location (state/county/country/zone/IOTA reference) from your log is not uploaded to LotW - that kind of information comes only from the other station's upload. To have the county data recorded correctly in LotW, the other station would have to upload each of the four separately-logged QSOs signed with a separate station location, one for each county. Also, while the times of those four QSOs would also be separated by two-second intervals, it is unlikely that the exact time logged would be identical to the second at both ends of the QSO, meaning matching up the QSO records between the two stations might be a bit trickier than usual.

+ LoTW only requires QSO start times to match within 30 minutes, so the "log one QSO every 2 seconds" approach will not prevent LoTW confirmations, so long as your QSO partner submits 4 QSOs to LoTW, each using a Station Location that specifies the correct US Country. At present, however, LoTW confirmations do not count towards CQ's USA-CA award (worked all US Counties).

+ Many thanks for the helpful response, Rich!

73,

Dave, AA6YQ
Hi Dave,

have you allowed for the unfortunate behaviour of the VB6 UDP client that concatenates UDP datagrams into one response buffer?



--
73

Bill

G4WJS.


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

+ AA6YQ comments below
I can't tell you for sure whether N1MM+ emits one <contactinfo> message or four, but from the N1MM+ manual:
"Separate QSOs will appear in your log, one for each county."
If four separate QSOs are logged, it might seem reasonable to expect four <contactinfo> messages in rapid succession, but without setting up a test I cannot be sure about that.

+ The 3 possibilities are

1. N1MM+ only sent 2 <contactinfo> messages (defect in N1MM+)

2. N1MM+ sent 4 <contactinfo> messages, but only 2 of those messages were actually delivered the N1MM_DXKeeper gateway because the UDP protocol that N1MM+ employs to deliver <contactinfo> messages is a "best efforts" protocol, with no guarantee of delivery.

3. N1MM+ sent 4 <contactinfo> messages, and all 4 of those messages were actually delivered to the the N1MM_DXKeeper gateway, but a defect in gateway or DXKeeper resulted only two QSOs being logged.

+ I would be helpful if someone familiar with N1MM+, the N1MM-DXKeeper Gateway, and state QSO parties could attempt to replicate this scenario so that we can determine what's going on, and correct whatever defects we find.


In any case, the "county" data exported by N1MM+ is not exported as county data. It is exported as "Exchange1" data, which I believe the Gateway translates into the SRX_STRING field. If there were four <contactinfo> messages, there should be four QSOs imported into DXKeeper, each with a different four-letter exchange abbreviation stored in the SRX_STRING field. There would be nothing stored in the County field, because N1MM+ does not export ADIF county data, it exports received contest exchange abbreviations, which are not valid county data in accordance with the ADIF specification that DXKeeper uses.

There is a program written by AD1C that can read an ADIF file exported by N1MM+ (or other contest logging programs) and convert the contest exchange abbreviation data recorded by the logging program into a valid ADIF County field -- see <http://software.ad1c.us/ADIF_County/index.html>. The way to use this to get the county data into DXKeeper would be by turning off the Gateway during the contest, exporting an ADIF file from N1MM+ after the contest, running it through the conversion program, and then importing the converted ADIF file into DXKeeper.

+ Alternatively, I could add that capability to the N1MM-DXKeeper Gateway. Where would I find the list of state QSO parties for which N1MM records 4-letter county abbreviations in SRX_STRING field? Where would I find a list of the 4-letter county abbreviations and their full county names?

My understanding of how county-line QSOs are logged in N1MM+ (see <https://n1mmwp.hamdocs.com/manual-supported/contests-setup/setup-qsop-contests/#rover-mobile-and-county-line-support>)
is that there would be four separate QSOs logged in N1MM+ at two-second intervals, resulting in four separate QSOs in the ADIF file and therefore in DXKeeper. When uploaded to LotW, these would be recorded as four otherwise identical QSOs at two-second intervals. Note that information about the other station's location (state/county/country/zone/IOTA reference) from your log is not uploaded to LotW - that kind of information comes only from the other station's upload. To have the county data recorded correctly in LotW, the other station would have to upload each of the four separately-logged QSOs signed with a separate station location, one for each county. Also, while the times of those four QSOs would also be separated by two-second intervals, it is unlikely that the exact time logged would be identical to the second at both ends of the QSO, meaning matching up the QSO records between the two stations might be a bit trickier than usual.

+ LoTW only requires QSO start times to match within 30 minutes, so the "log one QSO every 2 seconds" approach will not prevent LoTW confirmations, so long as your QSO partner submits 4 QSOs to LoTW, each using a Station Location that specifies the correct US Country. At present, however, LoTW confirmations do not count towards CQ's USA-CA award (worked all US Counties).

+ Many thanks for the helpful response, Rich!

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

+ AA6YQ comments below

N1MM logged four QSOs without my interaction.

The county data was in the exchange I received from the IL station. The QSO's that made it into dxkeeper show the exchange in the RX info section of the contest panel, but only the first two of the four qso's show up.

+ Thanks, Phil! That clarifies the situation.

======I was impressed that N1MM parsed it =======+ To what does the word "it" refer?
I was impressed that N1MM took the exchange from one QSO and logged it as four separate QSO's with different counties, and giving me credit for working those 4 counties in the QSO party.

It's not a problem for me. I thought I would just report my findings in case anyone was interested.

+ There's clearly a defect lurking here; thanks for reporting the behavior so that it can be tracked down and corrected.

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

ve3ki
 

I can't tell you for sure whether N1MM+ emits one <contactinfo> message or four, but from the N1MM+ manual:
"Separate QSOs will appear in your log, one for each county."
If four separate QSOs are logged, it might seem reasonable to expect four <contactinfo> messages in rapid succession, but without setting up a test I cannot be sure about that.

In any case, the "county" data exported by N1MM+ is not exported as county data. It is exported as "Exchange1" data, which I believe the Gateway translates into the SRX_STRING field. If there were four <contactinfo> messages, there should be four QSOs imported into DXKeeper, each with a different four-letter exchange abbreviation stored in the SRX_STRING field. There would be nothing stored in the County field, because N1MM+ does not export ADIF county data, it exports received contest exchange abbreviations, which are not valid county data in accordance with the ADIF specification that DXKeeper uses.

There is a program written by AD1C that can read an ADIF file exported by N1MM+ (or other contest logging programs) and convert the contest exchange abbreviation data recorded by the logging program into a valid ADIF County field -- see <http://software.ad1c.us/ADIF_County/index.html>. The way to use this to get the county data into DXKeeper would be by turning off the Gateway during the contest, exporting an ADIF file from N1MM+ after the contest, running it through the conversion program, and then importing the converted ADIF file into DXKeeper.

My understanding of how county-line QSOs are logged in N1MM+
(see <https://n1mmwp.hamdocs.com/manual-supported/contests-setup/setup-qsop-contests/#rover-mobile-and-county-line-support>)
is that there would be four separate QSOs logged in N1MM+ at two-second intervals, resulting in four separate QSOs in the ADIF file and therefore in DXKeeper. When uploaded to LotW, these would be recorded as four otherwise identical QSOs at two-second intervals. Note that information about the other station's location (state/county/country/zone/IOTA reference) from your log is not uploaded to LotW - that kind of information comes only from the other station's upload. To have the county data recorded correctly in LotW, the other station would have to upload each of the four separately-logged QSOs signed with a separate station location, one for each county. Also, while the times of those four QSOs would also be separated by two-second intervals, it is unlikely that the exact time logged would be identical to the second at both ends of the QSO, meaning matching up the QSO records between the two stations might be a bit trickier than usual.

73,
Rich VE3KI


On Sun, Oct 18, 2020 at 05:28 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

I'm running DXKeeper Gateway version 1.1.5 and 1.0.8701.0 N1MM and up-to-date versions of Dxkeeper and Dxview. I was working a state QSO party this weekend and one station sent me four counties in Illinois. All four counties showed up as separate QSOs in N1MM 

+ Did you direct N1MM to log one QSO, or four QSOs?

+ Does anyone from the N1MM development team know whether N1MM emits one or four <contactinfo> UDP messages in a scenario like this?


but only the first two counties got transferred to DXKeeper and LOTW.

+ Where were the first two counties recorded in DXKeeper?


I was impressed that N1MM parsed it

+ To what does the word "it" refer?

h
and that at least two counties made it into dxkeeper and LOTW but if I were a county hunter, I'd miss the other two counties.

+ The N1MM-DXKeeper Gateway does not convey US counties from N1MM to DXKeeper; see the list of information conveyed in the Operation section of

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


Is there a limit of two counties or a string length issue? They all were four characters. (GALL/HAML/SALI/WHIT).

+ DXKeeper does not interpret 4-character sequences appended to callsigns as US County names. DXKeeper can record callsigns of up to 13 characters in length.


+ The N1MM-DXKeeper Gateway logs one QSO in DXKeeper in response to each <contactinfo> UDP message it receives from N1MM.

<https://n1mmwp.hamdocs.com/appendices/external-udp-broadcasts/#contact-info-udp-packet>

+ The <contactinfo> UDP message does not provide a means of conveying the name of a US country, or of any other secondary administrative subdivision.

73,

Dave, AA6YQ


Re: N1MM to DXKeeper Gateway multiple county issue

Phil Deaver
 

N1MM logged four QSOs without my interaction. 

The county data was in the exchange I received from the IL station. The QSO's that made it into dxkeeper show the exchange in the RX info section of the contest panel, but only the first two of the four qso's show up. 
 
======I was impressed that N1MM parsed it
=======+ To what does the word "it" refer?
I was impressed that N1MM took the exchange from one QSO and logged it as four separate QSO's with different counties, and giving me credit for working those 4 counties in the QSO party.

It's not a problem for me. I thought I would just report my findings in case anyone was interested.
Phil WR7T


Re: N1MM to DXKeeper Gateway multiple county issue

Dave AA6YQ
 

+ AA6YQ comments below

I'm running DXKeeper Gateway version 1.1.5 and 1.0.8701.0 N1MM and up-to-date versions of Dxkeeper and Dxview. I was working a state QSO party this weekend and one station sent me four counties in Illinois. All four counties showed up as separate QSOs in N1MM

+ Did you direct N1MM to log one QSO, or four QSOs?

+ Does anyone from the N1MM development team know whether N1MM emits one or four <contactinfo> UDP messages in a scenario like this?


but only the first two counties got transferred to DXKeeper and LOTW.

+ Where were the first two counties recorded in DXKeeper?


I was impressed that N1MM parsed it

+ To what does the word "it" refer?


and that at least two counties made it into dxkeeper and LOTW but if I were a county hunter, I'd miss the other two counties.

+ The N1MM-DXKeeper Gateway does not convey US counties from N1MM to DXKeeper; see the list of information conveyed in the Operation section of

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


Is there a limit of two counties or a string length issue? They all were four characters. (GALL/HAML/SALI/WHIT).

+ DXKeeper does not interpret 4-character sequences appended to callsigns as US County names. DXKeeper can record callsigns of up to 13 characters in length.


+ The N1MM-DXKeeper Gateway logs one QSO in DXKeeper in response to each <contactinfo> UDP message it receives from N1MM.

<https://n1mmwp.hamdocs.com/appendices/external-udp-broadcasts/#contact-info-udp-packet>

+ The <contactinfo> UDP message does not provide a means of conveying the name of a US country, or of any other secondary administrative subdivision.

73,

Dave, AA6YQ


Re: Using secondary port of Commander for CW SKIMMER ?

Andrew OBrien
 

Bingo ! Got it now , thanks Dave . Knowing that I should stick to the K3 settings was the part that helped .

For anyone following this thread . The 705 can be used for Skimmer functions by setting the 705’s “USB AF/IF Output” to IF. I’m seeing skims for about a 24 khz range . Having a little CW Skimmer action works very well with Spotcollector and DXKeeeper.

Andy K3UK.

On Oct 18, 2020, at 5:02 PM, Dave AA6YQ <aa6yq@ambersoft.com> wrote:

+ AA6YQ comments below

I had to resort to reading the instructions about using CW Skimmer with Commander's secondary port.

+ Are you referring to these instructions?

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

I see I'm even quoted in that section ! Now , however , I am trying to configure the an Icom.

+ The primary transceiver's make and model have no impact on the Secondary CAT Port confioguratioon.

Back in the day I think I was using Kenwood products . The instructions reference an Elecraft

+ Step 2.a and 3.c.iii of the instructions recommend configuring the Secondary CAT Port and CW Skimmer to communicate via the Elecraft K3 protocol. I'm don't know of any reason to change this recommendation.

I have Commander connected to port 3 that is installed by Icom drivers . That is working fine . I have virtual ports 5 and 6 created and paired . I have the Commander secondary port configured for port 5 with 'enabled' checked . I have Omnirig configured for port 6, however CWSkimmer and Commander's secondary port do not see each other (I do have 'follow and lead' checked ) . In Commander's secondary port config area should I choose Icom as the radio (with A4 as C-IV address ) or is this a case where I should be using a generic Kenwood as the radio setting ? I tried making sure the baud rate in Commander equalled that of Omnirig and tried various combinations for DTR and RTS . So far , no success . I did succeed in getting the frequency display in CW Skimmer to light up, but frequency equalled 0.0

+ I suggest using the settings shown in steps 2 and 3 of

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

+ What's critical is configuring Commander's Secondary CAT Port and OmniRig to use the same protocol and baud rate. The two connected virtual ports must also be working..

73,

Dave, AA6YQ






Re: Using secondary port of Commander for CW SKIMMER ?

Dave AA6YQ
 

+ AA6YQ comments below

I had to resort to reading the instructions about using CW Skimmer with Commander's secondary port.

+ Are you referring to these instructions?

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

I see I'm even quoted in that section ! Now , however , I am trying to configure the an Icom.

+ The primary transceiver's make and model have no impact on the Secondary CAT Port confioguratioon.

Back in the day I think I was using Kenwood products . The instructions reference an Elecraft

+ Step 2.a and 3.c.iii of the instructions recommend configuring the Secondary CAT Port and CW Skimmer to communicate via the Elecraft K3 protocol. I'm don't know of any reason to change this recommendation.

I have Commander connected to port 3 that is installed by Icom drivers . That is working fine . I have virtual ports 5 and 6 created and paired . I have the Commander secondary port configured for port 5 with 'enabled' checked . I have Omnirig configured for port 6, however CWSkimmer and Commander's secondary port do not see each other (I do have 'follow and lead' checked ) . In Commander's secondary port config area should I choose Icom as the radio (with A4 as C-IV address ) or is this a case where I should be using a generic Kenwood as the radio setting ? I tried making sure the baud rate in Commander equalled that of Omnirig and tried various combinations for DTR and RTS . So far , no success . I did succeed in getting the frequency display in CW Skimmer to light up, but frequency equalled 0.0

+ I suggest using the settings shown in steps 2 and 3 of

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

+ What's critical is configuring Commander's Secondary CAT Port and OmniRig to use the same protocol and baud rate. The two connected virtual ports must also be working..

73,

Dave, AA6YQ


N1MM to DXKeeper Gateway multiple county issue

Phil Deaver
 

I'm running DXKeeper Gateway version 1.1.5 and 1.0.8701.0 N1MM and up-to-date versions of Dxkeeper and Dxview. I was working a state QSO party this weekend and one station sent me four counties in Illinois. All four counties showed up as separate QSOs in N1MM but only the first two counties got transferred to DXKeeper and LOTW. I was impressed that N1MM parsed it and that at least two counties made it into dxkeeper and LOTW but if I were a county hunter, I'd miss the other two counties. Is there a limit of two counties or a string length issue? They all were four characters. (GALL/HAML/SALI/WHIT).
Phil


Using secondary port of Commander for CW SKIMMER ?

Andrew OBrien
 

I had to resort to reading the instructions about using CW Skimmer with Commander’s secondary port . I see I’m even quoted in that section ! Now , however , I am trying to configure the an Icom . Back in the day I think I was using Kenwood products . The instructions reference an Elecraft , I am not sure of each step for the Icom 705 . I have Commander connected to port 3 that is installed by Icom drivers . That is working fine . I have virtual ports 5 and 6 created and paired . I have the Commander secondary port configured for port 5 with “enabled” checked . I have Omnirig configured for port 6, however CWSkimmer and Commander’s secondary port do not see each other (I do have “follow and lead” checked ) . In Commander’s secondary port config area should I choose Icom as the radio (with A4 as C-IV address ) or is this a case where I should be using a generic Kenwood as the radio setting ? I tried making sure the baud rate in Commander equalled that of Omnirig and tried various combinations for DTR and RTS . So far , no success . I did succeed in getting the frequency display in CW Skimmer to light up, but frequency equalled 0.0

Any help appreciated . Skimmer is working fine when not used with Commander . Obviously , for logging purposes I would like Commander and CWS to be in tandem .

Andy K3UK


updated eQSL AG and LoTW databases are available...

Dave AA6YQ
 

...via the Databases tab of DXView's Configuration window

73,

Dave, AA6YQ


Re: Export "EMAIL" field in a tab delimited export

K2JVS Joe
 

Thank you very much Dave, I really appreciate your fast response and great help.
Best regards,
Joe K2JVS


Re: Default Mode in Capture Window

Fred Kemmerer
 

Hello Dave,

Well, as usual, DXLab already had everything needed to address the items in this thread. The DXKeeper setting to initialize the signal reports and to set their default values works great in my EME use case. I already have a separate Workspace setup for EME so setting the RO/O or O/O defaults for my EME operations still enables a different set of defaults to be used in other cases. I use JT65b exclusively for the EME workspace so that takes care of the default reports to mode association.

Thank you!
--
Best and 73,

Fred, AB1OC
https://stationproject.blog
https://www.n1fd.org


Re: VE7CC - Spot Source

Henk Remijn PA5KT
 

It also has a nice gui which works better then spotcollector, at least for me.

During contests I dont run spotcollector.

73 Henk PA5KT

Op 17-10-2020 om 03:34 schreef Dave AA6YQ:

$ AA6YQ comments below

On Fri, Oct 16, 2020 at 6:15 PM Dave AA6YQ <aa6yq@ambersoft.com> wrote:
+ AA6YQ comments below

Contesters make extensive use of the CC User model (inserted infront of their context logging software) - or at least they did when I was involved a while back. If anyone's more sensitive to spot latency than DXers, it'd be contesters.

+ Have they measured the added latency and decided it was acceptable, or do they just employ CC User because they have no alternative?
I'm fairly sure that N1MM Logger[+] has/had its own spot filtering capabilities too... but I haven't been in that world for a while.

I see no reason to suspect that CC User would add more than a fraction of a second of latency. Do you have reason to believe that it would?

$ 50 years of professional hardware and software engineering have taught me that "guilty until proven innocent" is the appropriate outlook.

$ My concern with the unnecessary use of CC User is not latency, but rather unnecessary CPU and memory consumption, and "one more thing to break".

73,

Dave, AA6YQ





Re: Export "EMAIL" field in a tab delimited export

Dave AA6YQ
 

+ AA6YQ comments below

The EMAIL field is part of the export when ADIF is used, but I need to export it as a field in a tab delimited export and this does not seem to be standard when using tab delimited export. I see there are user defined fields. Is there any way to make one of the user defined fields the EMAIL field so that I can export/import this using tab delimited?

+ I have extended the next version of DXKeeper to include each QSO's email item in an exported tab-delimited file, and emailed it to you.

+ Please let me know how it goes..

73,

Dave, AA6YQ

3181 - 3200 of 200001