Date   

Re: FSK problems with K3 and Microkeyer MK2

Joe Subich, W4TV
 

Are you using Router's FSK port as a COM# entry in N1MM+ or
are you using EXTFSK?

Are you using the most recent version of Router (9.3.1)?

Have you selected "C: Limiting Speed" for the USB Port in the
Misc -> TX Port dialog *FOR THE COPY OF MMTTY USED BY N1MM+*

Various solutions:

1) Add a two spaces following your callsign
2) *check* "Strict BPS" in Router's FSK Port
(neither should be necessary if N1MM+/MMTTY are configured
correctly).

*ALWAYS* use the most recent version of microHAM USB Device
Router.

73,

... Joe, W4TV

On 2020-09-30 8:00 AM, Ronald PA3EWP wrote:
Hello,
During the RTTY contest last weekend we noticed a problem that our
transmitted text was abrupted.
A lot of times our call was transmitted as PI4C or PI4CO instead of PI4COM.
We used the latest version of N1MM+, MMTTY, Microkeyer MK2 and a Elecraft
K3.
N1MM was configured as SO2V.
If I looked at the digital interface window the text was transmitted, at the
end the software disabled the PTT of the radio.
But the radio was still busy transmitting the text, the FSK led was still
flashing, but the software disabled the PTT.
I try to find what was happening or was changed, but I couldn't find any
solution for it.
So we changed it to AFSK and all worked fine again.
If I started MMTTY without N1MM it worked fine.
I hope someone has a solution for it, I am sure it must be something simple,
but I can't find it.
Ronald
PA3EWP
Contestgroup Oude Maas
30th anniversary callsign: PI30COM
http://www.pi4com.nl <http://www.pi4com.nl/>


FSK problems with K3 and Microkeyer MK2

Ronald PA3EWP
 

Hello,

 

During the RTTY contest last weekend we noticed a problem that our transmitted text was abrupted.

A lot of times our call was transmitted as PI4C or PI4CO instead of PI4COM.

 

We used the latest version of N1MM+, MMTTY, Microkeyer MK2 and a Elecraft K3.

N1MM was configured as SO2V.

 

If I looked at the digital interface window the text was transmitted, at the end the software disabled the PTT of the radio.

But the radio was still busy transmitting the text, the FSK led was still flashing, but the software disabled the PTT.

I try to find what was happening or was changed, but I couldn’t find any solution for it.

 

So we changed it to AFSK and all worked fine again.

If I started MMTTY without N1MM it worked fine.

 

I hope someone has a solution for it, I am sure it must be something simple, but I can’t find it.

 

 

Ronald

PA3EWP

 

Contestgroup Oude Maas

30th anniversary callsign: PI30COM

http://www.pi4com.nl

 

 

 

 

 


Re: Working Dupes without ESM

John Bednar
 

Thanks Rich.

I tracked down the cause and tested the fix.

 

John, K3CT

 

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of ve3ki
Sent: Tuesday, September 29, 2020 8:44 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] Working Dupes without ESM

 

John,

I just tested this with all 8 possible combinations of CW vs RTTY, ESM vs non-ESM and "Work dupes" checked vs unchecked.

In RTTY with ESM turned off, the ; and Insert keys did not send the exchange, as Lee has reported. With ESM turned on, the exchange was sent. The "Work dupes" setting did not make any difference. 

In CW, regardless of whether ESM was on or off and regardless of the "Work dupes" setting, the ; and Insert keys always sent the exchange.

So, the issue is specific to digital modes with ESM off. With that one particular combination of choices, the ; and Insert keys do not send the exchange to a dupe.

73,
Rich VE3KI


On Tue, Sep 29, 2020 at 07:43 AM, John Bednar wrote:

Lee,

 

I just tested this using SO1V mode with the CQWW CW and PA QSO Party contests, ESM off, RUN mode, logging CW contacts.

 

The ; and ‘ keys allow me to work a dupe station.

 

John, K3CT

 

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of KY7M Lee
Sent: Monday, September 28, 2020 11:23 PM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] Working Dupes without ESM

 

I think I have figured out the issue.  I have the box checked in Configurer for Function Keys “Work dupes when running”.  I use the semicolon hot key to send the exchange when running and it normally send F5+F2.  The semicolon key does NOT work for me when working a  dupe while running.  If I press the F5 and F2 keys directly it DOES send for a dupe while running.  Something missing in the program??? 

 

The source of my confusion was that when you hover over that “Work dupes” check box you see the message “If this box is checked, ESM mode will let you work duplicate contacts when running” – thus my conclusion that it was only intended for ESM users.

 

Please excuse my confusion, but there is an issue using the semicolon hotkey when running and trying to work a dupe.

 

 

 

 


Re: how to add 3rd hardware #n1mm

Jay Uy
 

thank you for your reply and instruction
I will try this out next week when im free from work.
ill let you know how it goes.
best 73
jay du7jay


Re: Can't Open Com5 for Radio Commands

chuck.gooden
 

More settings from the FTdx3000 page in the NN1MM help documents  My Settings are in BOLD

FTDX-3000

  • The radio menu settings:
    • CAT TOT should be set to 1000 or higher.     Set to 1000
    • CAT SELECT must be set to USB if you wish to use the internal USB port for CAT control.  Set to USB
    • PC KEYING must be set to DTR to send CW with a COM port or with the USB port on the radio.  CW is working and not related to CAT
    • CAT RATE must match the program COM port baud rate. The suggested baud rate is 38400 (38400, N, 8, 2).  Using 38400, N, 8, 2
      • When using a COM port cable that contains signaling wires (RTS & DTR), verify that the radio menu CAT RTS = ENABLE (default) and the program radio COM port RTS to Handshake.
        CAT RTS set to ENABLE and Com5 RTS set to Handshake
      • When using a COM port cable with only three wires (TX, RX and ground) set CAT RTS = DISABLE on the radio menu and set the program radio COM port RTS to Always OFF
      Using the comport on the USB port of the radio.  It is the enhanced com port so the above statement does not apply
73's
Chuck K9LC


On 9/29/2020 9:42 PM, chuck.gooden wrote:

The frequency in the title bar of the N1MM program does change when I move the tuning knob on the radio.  The indicator in the band map also moves too.

Menu #40 Cat RTS is set to Enable.  The RTS pull down in Config --> Harware  .... Com5 is set to Handhake.

Chuck K9LC



On 9/29/2020 9:05 PM, ve3ki wrote:
You can send commands to the radio, but can the radio send information to the program? If you change frequency using the radio's tuning knob, does the frequency displayed in the program change?

Depending on the menu settings in the radio, the radio may need a handshaking signal on RTS on COM5 in order to respond to queries from the program. See <https://n1mmwp.hamdocs.com/manual-supported/supported-radios/#ftdx-3000>.

73,
Rich VE3KI


On Tue, Sep 29, 2020 at 08:46 PM, chuck.gooden wrote:
I am getting an error message when ever I change bands using the band
selector buttons in the main window.  When I click on a band to change
to a new ham band, an error window appears and says "Can't Open Com5 for
Radio Commands".  However even though the error message is display, my
FTDX3000 does in fact change bands and displays the last frequency that
I used on that band. This occurs before I click the OK button to dismiss
the error window.

The RTTY engine window also appears to freeze until I click the OK
button.  The MTTY is using Com3 to send FSK data to the radio. The other
com port being used is Com4 which is used to Key the rig for CW.

I can click on call signs in the band map window and the frequency
changes with out an error message so the com5 appears to be working and
controlling the radio correctly.

I would like to get this fixed as it is an annoyance, although minor. 
Any ideas why this is occurring and how do I fix it?

The issue is also in the new version of N1MM that I upgraded to today. 
It was also seen a while back too but I lived with it and did not report it.

Chuck K9LC


Re: Can't Open Com5 for Radio Commands

chuck.gooden
 

The frequency in the title bar of the N1MM program does change when I move the tuning knob on the radio.  The indicator in the band map also moves too.

Menu #40 Cat RTS is set to Enable.  The RTS pull down in Config --> Harware  .... Com5 is set to Handhake.

Chuck K9LC



On 9/29/2020 9:05 PM, ve3ki wrote:
You can send commands to the radio, but can the radio send information to the program? If you change frequency using the radio's tuning knob, does the frequency displayed in the program change?

Depending on the menu settings in the radio, the radio may need a handshaking signal on RTS on COM5 in order to respond to queries from the program. See <https://n1mmwp.hamdocs.com/manual-supported/supported-radios/#ftdx-3000>.

73,
Rich VE3KI


On Tue, Sep 29, 2020 at 08:46 PM, chuck.gooden wrote:
I am getting an error message when ever I change bands using the band
selector buttons in the main window.  When I click on a band to change
to a new ham band, an error window appears and says "Can't Open Com5 for
Radio Commands".  However even though the error message is display, my
FTDX3000 does in fact change bands and displays the last frequency that
I used on that band. This occurs before I click the OK button to dismiss
the error window.

The RTTY engine window also appears to freeze until I click the OK
button.  The MTTY is using Com3 to send FSK data to the radio. The other
com port being used is Com4 which is used to Key the rig for CW.

I can click on call signs in the band map window and the frequency
changes with out an error message so the com5 appears to be working and
controlling the radio correctly.

I would like to get this fixed as it is an annoyance, although minor. 
Any ideas why this is occurring and how do I fix it?

The issue is also in the new version of N1MM that I upgraded to today. 
It was also seen a while back too but I lived with it and did not report it.

Chuck K9LC


Re: Can't Open Com5 for Radio Commands

ve3ki
 

You can send commands to the radio, but can the radio send information to the program? If you change frequency using the radio's tuning knob, does the frequency displayed in the program change?

Depending on the menu settings in the radio, the radio may need a handshaking signal on RTS on COM5 in order to respond to queries from the program. See <https://n1mmwp.hamdocs.com/manual-supported/supported-radios/#ftdx-3000>.

73,
Rich VE3KI


On Tue, Sep 29, 2020 at 08:46 PM, chuck.gooden wrote:
I am getting an error message when ever I change bands using the band
selector buttons in the main window.  When I click on a band to change
to a new ham band, an error window appears and says "Can't Open Com5 for
Radio Commands".  However even though the error message is display, my
FTDX3000 does in fact change bands and displays the last frequency that
I used on that band. This occurs before I click the OK button to dismiss
the error window.

The RTTY engine window also appears to freeze until I click the OK
button.  The MTTY is using Com3 to send FSK data to the radio. The other
com port being used is Com4 which is used to Key the rig for CW.

I can click on call signs in the band map window and the frequency
changes with out an error message so the com5 appears to be working and
controlling the radio correctly.

I would like to get this fixed as it is an annoyance, although minor. 
Any ideas why this is occurring and how do I fix it?

The issue is also in the new version of N1MM that I upgraded to today. 
It was also seen a while back too but I lived with it and did not report it.

Chuck K9LC


Re: Is N1MM open source?

AB2ZY
 

It is not open source.

Al
AB2ZY

-----Original Message-----
From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of chuck.gooden
Sent: Tuesday, September 29, 2020 8:50 PM
To: N1MMLoggerPlus@groups.io
Subject: [N1MM+] Is N1MM open source?


If N1MM is an open source software can you please let me know where the
Git, CVS, or other repository is located.

Thanks,

Chuck K9LC


Is N1MM open source?

chuck.gooden
 

If N1MM is an open source software can you please let me know where the Git, CVS, or other repository is located.

Thanks,

Chuck K9LC


Can't Open Com5 for Radio Commands

chuck.gooden
 

I am getting an error message when ever I change bands using the band selector buttons in the main window.  When I click on a band to change to a new ham band, an error window appears and says "Can't Open Com5 for Radio Commands".  However even though the error message is display, my FTDX3000 does in fact change bands and displays the last frequency that I used on that band. This occurs before I click the OK button to dismiss the error window.

The RTTY engine window also appears to freeze until I click the OK button.  The MTTY is using Com3 to send FSK data to the radio. The other com port being used is Com4 which is used to Key the rig for CW.

I can click on call signs in the band map window and the frequency changes with out an error message so the com5 appears to be working and controlling the radio correctly.

I would like to get this fixed as it is an annoyance, although minor.  Any ideas why this is occurring and how do I fix it?

The issue is also in the new version of N1MM that I upgraded to today.  It was also seen a while back too but I lived with it and did not report it.

Chuck K9LC


Re: Setting up Maine qso party

Tom Osborne
 

What was excellent?  73
Tom W7WHY



On Tue, Sep 29, 2020 at 5:16 PM Fred Tollin <lizzyfan4986@...> wrote:
Excellent!!!


Re: Setting up Maine qso party

Fred Tollin
 

Excellent!!!


Re: Minor annoyance on switching bands while doing RTTY

ve3ki
 

Pierre,

In the Digital Interface window, open the Settings window and over at the right side of the Settings window, select MMTTY as you Default RTTY Interface.

73,
Rich VE3KI


On Tue, Sep 29, 2020 at 04:40 PM, Pierre Fogal wrote:
Hi folks,

For some time now, I have been experiencing a minor annoyance while doing RTTY contests.  I usually operate with an MMTTY window and a GRITTY window. When I change bands by clicking on the band list in the Entry window, the MMTTY window closes and the MMVARI window opens.  I then close the MMVARI and re-open the MMTTY.  It happens both with GRITTY running and without. It does not happen if type a frequency into the entry window, nor if I change the band on the radio.

I run AFSK through an external usb sound-card. The radio is a Kenwood TS-570D and a Rigblaster Pro interface is in use.  The computer is an i5 Thinkpad running Windows 10.

Is there by chance a setting that indicates which RTTY interface is the default?

73,
Pierre VE3KTB (VA3LML this past weekend)


Minor annoyance on switching bands while doing RTTY

Pierre Fogal
 

Hi folks,

For some time now, I have been experiencing a minor annoyance while doing RTTY contests.  I usually operate with an MMTTY window and a GRITTY window. When I change bands by clicking on the band list in the Entry window, the MMTTY window closes and the MMVARI window opens.  I then close the MMVARI and re-open the MMTTY.  It happens both with GRITTY running and without. It does not happen if type a frequency into the entry window, nor if I change the band on the radio.

I run AFSK through an external usb sound-card. The radio is a Kenwood TS-570D and a Rigblaster Pro interface is in use.  The computer is an i5 Thinkpad running Windows 10.

Is there by chance a setting that indicates which RTTY interface is the default?

73,
Pierre VE3KTB (VA3LML this past weekend)


Re: Setting up Maine qso party

KE8G
 

Yes, it is fixed

On Tue, Sep 29, 2020 at 3:25 PM Fred Tollin <lizzyfan4986@...> wrote:
Any updates?


Re: Setting up Maine qso party

Fred Tollin
 

Any updates?


Re: CQ WW RTTY Contest ADIF Logs

Ed Muns, W0YK
 

Yep, we discovered that case a today and are arranging a fix.  Thanks for the sleuthing and feedback! 

73,
Ed W0YK


-------- Original message --------
From: "Phil Cooper via groups.io" <pcooper@...>
Date: 9/29/20 10:01 (GMT-08:00)
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] CQ WW RTTY Contest ADIF Logs

Hi Ed,

 

After running through the process, and getting to the bit where it produces the Cabrillo file, I noted that DX (ie non-US/VE stations) were correctly identified as DX, but it also put DX against all my US/VE contacts too.

 

From what I could see, it asks for a sample of the CQ Zone, and a sample of the "Received Location", but the choices available don't seem to cater for what N1MM produces in the ADIF file, which is (for example) <STATE:2>MA.

 

If I choose the default of AUTO:DX it places DX against all US/VE calls, rather than the State, as per the instructions. However, I note that it says " Select ADIF field that contains received State/Province", but I can't seem to navigate to anything other than the first contact in the ADIF file.

 

73 de Phil GU0SUP

 

 

 

-----Original Message-----
From: "Ed Muns, W0YK" <ed@...>
Sent: Tuesday, 29 September, 2020 13:10
To: N1MMLoggerPlus@groups.io
Subject: [N1MM+] CQ WW RTTY Contest ADIF Logs

We’ve added an ADIF Converter webpage to the CQ WW RTTY Contest website and would like to test it with some N1MM+ Logger ADIF logs.  Please export an ADIF of your log from last weekend and email it to me.  Or, if you’d like, try the converter yourself.

 

                https://www.cqwwrtty.com/adif/

 

One concern is whether the QTH exchange field is provided (US state, VE area or ‘DX’).

 

73,

Ed W0YK

 


Re: CQ WW RTTY Contest ADIF Logs

Phil Cooper
 

Hi Ed,

 

After running through the process, and getting to the bit where it produces the Cabrillo file, I noted that DX (ie non-US/VE stations) were correctly identified as DX, but it also put DX against all my US/VE contacts too.

 

From what I could see, it asks for a sample of the CQ Zone, and a sample of the "Received Location", but the choices available don't seem to cater for what N1MM produces in the ADIF file, which is (for example) <STATE:2>MA.

 

If I choose the default of AUTO:DX it places DX against all US/VE calls, rather than the State, as per the instructions. However, I note that it says " Select ADIF field that contains received State/Province", but I can't seem to navigate to anything other than the first contact in the ADIF file.

 

73 de Phil GU0SUP

 

 

 

-----Original Message-----
From: "Ed Muns, W0YK" <ed@...>
Sent: Tuesday, 29 September, 2020 13:10
To: N1MMLoggerPlus@groups.io
Subject: [N1MM+] CQ WW RTTY Contest ADIF Logs

We’ve added an ADIF Converter webpage to the CQ WW RTTY Contest website and would like to test it with some N1MM+ Logger ADIF logs.  Please export an ADIF of your log from last weekend and email it to me.  Or, if you’d like, try the converter yourself.

 

                https://www.cqwwrtty.com/adif/

 

One concern is whether the QTH exchange field is provided (US state, VE area or ‘DX’).

 

73,

Ed W0YK

 


Re: CQ WW RTTY Contest ADIF Logs

ve3ki
 

Tim,

If you use the "Export ADIF to file by date to from ALL contests" option to export an ADIF file, you can almost count on having problems with the contest exchange and CONTEST_ID fields. The "export from all contests" routine does not look at each QSO to determine which contest it was logged in and decide what ADIF tags are needed for contest-specific items in the database. If you want the contest-related data (such as the exchange) to be handled correctly, you should export each contest log individually. Perhaps this is an explanation for the defective ADIF files Ed reported, i.e. perhaps people were using the "export from all contests" option instead of the basic "export the current contest" option.

73,
Rich VE3KI


On Tue, Sep 29, 2020 at 11:48 AM, Tim Shoppa wrote:
Just to show how complicated it can be, I switched from my WW RTTY log to my General-purpose DX N1MM log, then did an ADIF export of all contests starting with 0000Z Friday night.  The CONTEST_ID comes out as CQ-WW-RTTY. The state comes out, but in ARRL_SECT, not in STATE.
 
Then I switched to a CWT log and did an ADIF export of all contests again starting with 0000Z Friday night. The CONTEST_ID comes out as CQ-WW-RTTY. The state doesn't appear anywhere at all in this ADIF.
 
I'm not saying any of the N1MM behavior is wrong, I'm just saying ADIF export depends on the context of the current contest (not the context of a past contest) even though CONTEST_ID is there and correct for the past contest being exported.
 
I use N1MM more than anyone else in the world (except AA3B) so I kind of understand it's internal model and why it does it does, but it might surprise other less regular contesters (which is everybody in the world except for AA3B and me) to see it work this way.
 
Tim N3QE

On Tue, Sep 29, 2020 at 11:15 AM ve3ki <ve3iay@...> wrote:
Yes. You can check for this in the ADIF file by looking at the CONTEST_ID field.

73,
Rich VE3KI


On Tue, Sep 29, 2020 at 11:08 AM, Tim Shoppa wrote:
There is also a very good chance someone tried to use CQ WW CW logger or some zone-but-no-state RTTY logger to log the WW RTTY contest and that's why there's no states recorded anywhere in the ADIF.
 
I can tell you (as a club secretary) that a couple percent of hams start the contest with the wrong log and need help fixing everything up. Very common is for someone to start CQ WW SSB with CQ WPX SSB and they don't know until they are hundreds of QSO's in that they have been typing in zone numbers into the serial number box.
 
Tim N3QE

On Tue, Sep 29, 2020 at 10:11 AM ve3ki <ve3iay@...> wrote:
N1MM Logger has exported the state/province part of the CQ WW RTTY exchange to ADIF using the STATE tag since 2014 or before (I just tested it with N1MM Logger Classic version 14.9.0). In fact, it looks to me from the revision history as though this change to do this was made in 2003 (version 3.0.97). I doubt whether anyone is using a version that old, but you never know...

73,
Rich VE3KI

On Tue, Sep 29, 2020 at 09:53 AM, Tim Shoppa wrote:
Ed, I’m guessing an older version of N1MM? There have been several recent (last year or so) improvements in N1MM ADIF exports in an attempt to somehow encode all parts of the exchange (including location I recall)  in a more useful way for general purpose logger import.
 
Tim N3QE

On Sep 29, 2020, at 9:36 AM, Ed Muns, W0YK <ed@...> wrote:

Thanks much Tim.  We got some ADIF logs from N1MM Logger that didn't have the QTH field.  How could that happen?
 
73,
Ed W0YK
 
 
-------- Original message --------
From: Tim Shoppa <tshoppa@...>
Date: 9/29/20 05:54 (GMT-08:00)
Subject: Re: [N1MM+] CQ WW RTTY Contest ADIF Logs
 
Ed, I did a "diff" between N1MM's native Cabrillo export, and the N1MM's ADIF run through the Cabrillo converter.
 
The only differences in the QSO: lines were superficial, like whether there's a leading zero on the zone, or how frequencies are rounded off.
 
For example N1MM will round off frequencies to the nearest kHz, and the ADIF converter always rounds down ("floor"). e.g. 14.08573 shows up as "14086" in N1MM Cabrillo, and as "14085" in ADIF->Cabrillo conversion. I don't think the Cabrillo spec says which way we are supposed to round anyway.
 
The pulldowns, based on the users actual ADIF, to let the user decide which ADIF fields have state and zone, that actually seems pretty nifty and is an inspired solution to a hairy problem. They defaulted to the correct fields for my ADIF which started with a USA call. If the pulldown was based on the first US/VE QSO that might be marginally better than letting it use the very first ADIF QSO which might not be US/VE.
 
This converter seems like it'll be more broadly useful for WW Digi than for WW RTTY. But maybe there's more loggers out there today than a decade ago, that only do ADIF exports.
 
Tim N3QE

On Tue, Sep 29, 2020 at 8:10 AM Ed Muns, W0YK <ed@...> wrote:

We’ve added an ADIF Converter webpage to the CQ WW RTTY Contest website and would like to test it with some N1MM+ Logger ADIF logs.  Please export an ADIF of your log from last weekend and email it to me.  Or, if you’d like, try the converter yourself.

 

                https://www.cqwwrtty.com/adif/

 

One concern is whether the QTH exchange field is provided (US state, VE area or ‘DX’).

 

73,

Ed W0YK

 

 

 

 

 

 

 


(offlist) CQ contest names

Tim Shoppa
 

It doesn't help that all 10 of the CQ contest names formally start with "CQ World-Wide (whatever)."

A lot of us say WPX not CQ WW WPX but we are being slackers and not saying the full contest name.

If the contest name was just "WPX" or "WW" it would help a little.


On Tue, Sep 29, 2020 at 11:50 AM Ed Muns, W0YK <ed@...> wrote:
Oh, yes, I'm well aware of these and many other anomalies.  I've cleaned up thousands of mangled logs over my contest admin tenure!

73,
Ed W0YK


-------- Original message --------
From: Tim Shoppa <tshoppa@...>
Date: 9/29/20 08:07 (GMT-08:00)
Subject: Re: [N1MM+] CQ WW RTTY Contest ADIF Logs

There is also a very good chance someone tried to use CQ WW CW logger or some zone-but-no-state RTTY logger to log the WW RTTY contest and that's why there's no states recorded anywhere in the ADIF.

I can tell you (as a club secretary) that a couple percent of hams start the contest with the wrong log and need help fixing everything up. Very common is for someone to start CQ WW SSB with CQ WPX SSB and they don't know until they are hundreds of QSO's in that they have been typing in zone numbers into the serial number box.

Tim N3QE

On Tue, Sep 29, 2020 at 10:11 AM ve3ki <ve3iay@...> wrote:
N1MM Logger has exported the state/province part of the CQ WW RTTY exchange to ADIF using the STATE tag since 2014 or before (I just tested it with N1MM Logger Classic version 14.9.0). In fact, it looks to me from the revision history as though this change to do this was made in 2003 (version 3.0.97). I doubt whether anyone is using a version that old, but you never know...

73,
Rich VE3KI

On Tue, Sep 29, 2020 at 09:53 AM, Tim Shoppa wrote:
Ed, I’m guessing an older version of N1MM? There have been several recent (last year or so) improvements in N1MM ADIF exports in an attempt to somehow encode all parts of the exchange (including location I recall)  in a more useful way for general purpose logger import.
 
Tim N3QE

On Sep 29, 2020, at 9:36 AM, Ed Muns, W0YK <ed@...> wrote:

Thanks much Tim.  We got some ADIF logs from N1MM Logger that didn't have the QTH field.  How could that happen?
 
73,
Ed W0YK
 
 
-------- Original message --------
From: Tim Shoppa <tshoppa@...>
Date: 9/29/20 05:54 (GMT-08:00)
Subject: Re: [N1MM+] CQ WW RTTY Contest ADIF Logs
 
Ed, I did a "diff" between N1MM's native Cabrillo export, and the N1MM's ADIF run through the Cabrillo converter.
 
The only differences in the QSO: lines were superficial, like whether there's a leading zero on the zone, or how frequencies are rounded off.
 
For example N1MM will round off frequencies to the nearest kHz, and the ADIF converter always rounds down ("floor"). e.g. 14.08573 shows up as "14086" in N1MM Cabrillo, and as "14085" in ADIF->Cabrillo conversion. I don't think the Cabrillo spec says which way we are supposed to round anyway.
 
The pulldowns, based on the users actual ADIF, to let the user decide which ADIF fields have state and zone, that actually seems pretty nifty and is an inspired solution to a hairy problem. They defaulted to the correct fields for my ADIF which started with a USA call. If the pulldown was based on the first US/VE QSO that might be marginally better than letting it use the very first ADIF QSO which might not be US/VE.
 
This converter seems like it'll be more broadly useful for WW Digi than for WW RTTY. But maybe there's more loggers out there today than a decade ago, that only do ADIF exports.
 
Tim N3QE

On Tue, Sep 29, 2020 at 8:10 AM Ed Muns, W0YK <ed@...> wrote:

We’ve added an ADIF Converter webpage to the CQ WW RTTY Contest website and would like to test it with some N1MM+ Logger ADIF logs.  Please export an ADIF of your log from last weekend and email it to me.  Or, if you’d like, try the converter yourself.

 

                https://www.cqwwrtty.com/adif/

 

One concern is whether the QTH exchange field is provided (US state, VE area or ‘DX’).

 

73,

Ed W0YK