Date   
Re: Recovering N1MM Logger+ from dead computer (Redux)

ve3ki
 

Do not copy the C:\Program Files(x86)\N1MM Logger+ directory from the old hard drive. If N1MM+ is already installed on the backup PC, then everything in that directory was put there when you installed the program on that PC. Overwriting it won't make anything better and might screw things up by overwriting something with an out of date version. Besides, none of your logs and databases are in there anyway. Those are all in the Documents\N1MM Logger+ directory (unless you have put some of them somewhere else).

Installing N1MM+ on the backup PC should also have created the C:\Users\George\Documents\N1MM Logger+ (user files) directory and populated it with the basics, to which you have now added whatever files were created or used for the IARU contest. You do not want to overwrite those newer files with old ones from the old computer, because that will lose your IARU log and any other files you created for that contest. So, when copying files from the old user files area, don't overwrite newer files already on the hard drive with older ones from the old hard drive. When copying a file with the same name as an existing file in the destination location, Windows 7 gives you the option of which file to keep. Always keep the file with the newer date.

In particular, don't copy the n1mm logger.ini file from the old hard drive to the new one. Unless the two computers were identical and Windows enumerated all of the serial ports and sound card devices in exactly the same order on both computers, the hardware configuration will be different, and the old n1mm logger.ini file will not work properly on the new PC.

If there was a ham.s3db database on the old hard drive that contains logs you want to keep, don't copy it over top of the new file. Instead, rename it to something like ham-old.s3db before copying it. You will be able to access those files by using the File > Open Database... menu item to select the old database and open your old logs.

C:\N1MM Logger+ is not part of a standard install. I have no idea what you had in there, but if such a folder does not yet exist on the backup computer, you won't overwrite anything by copying it from the old hard drive, so that should be safe to do.

73,
Rich VE3KI



On Wed, Jul 17, 2019 at 09:32 PM, George W1EBI wrote:
I installed N1MM+ into a backup Windows 7 desktop and successfully operated in IARU last weekend.  A colleague at work has a disk recovery device, so I removed the hard drive from the dead desktop PC and EUREKA!!--the drive is intact and accessible!  My colleague is copying critical files and folders onto USB drives so I can put the backup PC into service with a complete historic version of my N1MM+ logs and databases.  I am planning to copy the following files:

C:\N1MM Logger+
C:\Program Files (x86)\N1MM Logger+
C:\Users\George\My Documents\N1MM Logger+

All my databases will be included here.  I have exactly one log in the database HAM.s3db in the backup PC, but I want to basically copy the recovered files and folders from the USB drives into the backup PC--without screwing anything up.  Could I please have some advice from the development team on the correct way to do this?

George W1EBI

7300 not going in TX

Jamie WW3S
 

First time using 7300 in RTTY contest, setting up for NAQP, using 2tone as AFSK to key the rig. The rig is not going into transmit when the function keys are pressed. How should PTT be set in config? 

Re: Grid square multiplier map

andy@...
 

My thanks go to Rich and John.

I now have a working Grid square map.

John you may be interested to know that I installed version 1.0.7809, which is I believe the version before 1.0.7825, but this didnt cure the issue, installing version 1.0.7790 did solve the problem though.

Thanks again
Andy GD0AMD

Re: Tab / Space behaviour on VHF contests

Les Elliott
 

Pat
I have just tested B4 and the Locator fills on pressing Tab,
perhaps it is down to how you have formatted your CH file.

Les, G4OGB

-----Original Message-----
From: Patrick Herborn
Sent: Wednesday, July 17, 2019 3:33 PM
To: N1MMLoggerPlus@groups.io
Subject: [N1MM+] Tab / Space behaviour on VHF contests

Good afternoon all!

This question / feature request pertains to the action of Tab and Space
when in a VHF contest. Space is most useful insofar as it will pre-fill
the locator information if pressed in the Callsign field (if using
history lookup), BUT in doing so it jumps directly to the received
serial box, pre-filling the sent and received reports with 59.

This behaviour is fine on HF contests, but we tend to send real signal
reports, which means one then has to go back to correct the pre-filled
signal reports. Occasionally one might have to correct the locator
for a /P but that's just life.

One way of avoiding this is to use the Tab key - this steps through
the fields and permits entry of RS(T) and serial, but then it doesn't
pre-fill the locator. Kind of damned if you do, damned if you don't.
It would be useful to have an option for Space (or some other key)
to pre-fill the locator only, and jump to the relevant next
field (as discussed below).

An additional improvement might be to change the Tab order of the
fields - again this is related to the use of real signal reports.
The default behaviour is to go from the callsign to the sent
signal report - this is fine in Run mode where you just have
to give the best report you can based on receiving just a callsign,
but in S&P you get your report from the Run station, which
allows a better determination of an accurate signal report, ergo
the sent report tends to get filled in last. It would be helpful
to have an option to change the tab (or space or other key) order to
Callsign->RxRST->RxSn->Loc->SntRST - perhaps tracking Run/S&P state.

These things may of course already be possible - I just haven't found a
way of doing it - in which case I should be grateful for any hints /
tips / instructions.

Best regards,

Pat (M0MGO).

--
Patrick Herborn <pat@...>

Re: Clicking on Zone Mults - SO2R

Stewart G3RXQ
 

Might there be a way of assigning individual bands in the Zone multiplier map to specific Radio Com  ports ?

Maybe tied in with the Entry window band selection.

73 Stewart G3RXQ - G3Q

Recovering N1MM Logger+ from dead computer (Redux)

George W1EBI
 

I installed N1MM+ into a backup Windows 7 desktop and successfully operated in IARU last weekend.  A colleague at work has a disk recovery device, so I removed the hard drive from the dead desktop PC and EUREKA!!--the drive is intact and accessible!  My colleague is copying critical files and folders onto USB drives so I can put the backup PC into service with a complete historic version of my N1MM+ logs and databases.  I am planning to copy the following files:

C:\N1MM Logger+
C:\Program Files (x86)\N1MM Logger+
C:\Users\George\My Documents\N1MM Logger+

All my databases will be included here.  I have exactly one log in the database HAM.s3db in the backup PC, but I want to basically copy the recovered files and folders from the USB drives into the backup PC--without screwing anything up.  Could I please have some advice from the development team on the correct way to do this?

George W1EBI

Re: Tab / Space behaviour on VHF contests

Patrick Herborn
 

On Wed, 17 Jul 2019 14:24:54 -0700
andy@... wrote:

Things do appear to be very different across the pond, in the UK and Europe
genuine signal reports are routinely given in V/UHF contests, and at least
in the RSGB contests you WILL be penalised if you log any part of the exchange
incorrectly.

After all the purpose of a contest is to pass information as quickly and
*accurately* as possible, not to make up the contact details for the log..
And indeed we can show UBNs for mismatched RS(T)s...

You may have noticed that Pat's callsign places him as English, so he is
also subject to these rules. and hence he has raised a perfectly valid query.
Very valid for us, yes :)

Perhaps we can now let someone answer Pats question.
Are you using the B4RTTY UDC for VHF or are you using MINOS ? If the
former, have you seen the behaiour that John describes, where even
a Tab completes the Locator ? Perhaps I have configure it wrong
somehow...

As an aside, did I hear that right when I heard a glimmer of GM0AMD/MM
in IO66 square the other night ? :)

Andy GD0AMD
Cheers,

Pat. (M0MGO)

--
Patrick Herborn <pat@...>

Re: Tab / Space behaviour on VHF contests

Patrick Herborn
 

On Thu, 18 Jul 2019 10:36:17 +1200
"Ken McVie" <kenmc@...> wrote:

Hey Pat,
Hiya Ken!

you don't really believe your S meter [guess meter] do you??
Oooohhh... now THAT could be an entire forum's worth of
discussion in its own right ;)

It is certainly true that many rigs' S meters are not calibrated.
I seem to recall much consternation that Icom didn't properly
calibrate the S meter on the 7610 for example (something you might
HOPE they would have done on a rig in that price bracket)... but
then on the flipside, I believe that SDRPlay DID take the time
and expend the effort to ensure that the S Meter readings
from RSPs are true (ironic, given how many of those you
could buy for the price of a single 7610!).

In the present context though, we are REQUIRED to correctly
log received signal reports and we are penalised if we get
them wrong - so even if the meters are telling us lies,
we still need logs to match.

73
Ken ZL4NR
Best regards,

Pat (M0MGO)

On 18/07/2019 2:33 AM, Patrick Herborn wrote:
Good afternoon all!

This question / feature request pertains to the action of Tab and Space
when in a VHF contest. Space is most useful insofar as it will pre-fill
the locator information if pressed in the Callsign field (if using
history lookup), BUT in doing so it jumps directly to the received
serial box, pre-filling the sent and received reports with 59.

This behaviour is fine on HF contests, but we tend to send real signal
reports, which means one then has to go back to correct the pre-filled
signal reports. Occasionally one might have to correct the locator
for a /P but that's just life.

One way of avoiding this is to use the Tab key - this steps through
the fields and permits entry of RS(T) and serial, but then it doesn't
pre-fill the locator. Kind of damned if you do, damned if you don't.
It would be useful to have an option for Space (or some other key)
to pre-fill the locator only, and jump to the relevant next
field (as discussed below).

An additional improvement might be to change the Tab order of the
fields - again this is related to the use of real signal reports.
The default behaviour is to go from the callsign to the sent
signal report - this is fine in Run mode where you just have
to give the best report you can based on receiving just a callsign,
but in S&P you get your report from the Run station, which
allows a better determination of an accurate signal report, ergo
the sent report tends to get filled in last. It would be helpful
to have an option to change the tab (or space or other key) order to
Callsign->RxRST->RxSn->Loc->SntRST - perhaps tracking Run/S&P state.

These things may of course already be possible - I just haven't found a
way of doing it - in which case I should be grateful for any hints /
tips / instructions.

Best regards,

Pat (M0MGO).


--
Patrick Herborn <pat@...>

Re: Tab / Space behaviour on VHF contests

Patrick Herborn
 

On Wed, 17 Jul 2019 18:00:58 -0400
"John Bednar via Groups.Io" <k3ct=verizon.net@groups.io> wrote:

Pat,
Hiya John!

I just tested using the ARRL June VHF contest. As I expected, entering a
callsign and pressing the Tab key DOES populate the exchange box from call
history and place the cursor in the RST field.
Oh, now that is very interesting! It doesn't do that on my installation -
if I tab from the Callsign box then it goes to Sent RST but doesn't fill
in the locator from the history - it only does it with space for me.

I wonder if this has something to do with the use of a UDC here ?

The code also places the cursor in the RST box at the location to update
the RST.
Yes, it does advance to the Sent RST for me also - if memory serves it is
placed after a 5 when using the tab (would need to check).

As Andy GD0AMD points out, we send real signal reports AND we are
penalised if we get them wrong - so they have to match. Real
signal reports means that the 5 is NOT a given - think we have
given out a 31 before now.... and someone even once sent out
something like a 40 which caused some controversy, since 0
suggests NO signal - when that operator probably MEANT the
signal wasn't moving the S meter at all. I digress. Correcting
a 5 is easy with the delete key when you're already past it,
but having to shift-tab (or mouse) all the way back (and then
also have to replace the default 59) is more of a pain.

I was careful to request this as an OPTION - that way it
means that it doesn't affect the normal operation for
those whose signal reports aren't important, but for those
of us penalised for getting them wrong, there is a more
fluid path available than what space bar offers right now.

Pressing tab again advances the cursor to the RST box highlighting the
correct character again.
Well, it looks like there is light at the end of this tunnel. That's
pretty much the way I would want it in Run mode, and worst case in
S&P one could tab twice past the locator to be back in the sent
signal report :) Just need to figure out how to make my copy do
that now :)

John, K3CT
Best regards,

Pat (M0MGO)


-----Original Message-----
From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf
Of Patrick Herborn
Sent: Wednesday, July 17, 2019 10:34 AM
To: N1MMLoggerPlus@groups.io
Subject: [N1MM+] Tab / Space behaviour on VHF contests



Good afternoon all!



This question / feature request pertains to the action of Tab and Space

when in a VHF contest. Space is most useful insofar as it will pre-fill

the locator information if pressed in the Callsign field (if using

history lookup), BUT in doing so it jumps directly to the received

serial box, pre-filling the sent and received reports with 59.



This behaviour is fine on HF contests, but we tend to send real signal

reports, which means one then has to go back to correct the pre-filled

signal reports. Occasionally one might have to correct the locator

for a /P but that's just life.



One way of avoiding this is to use the Tab key - this steps through

the fields and permits entry of RS(T) and serial, but then it doesn't

pre-fill the locator. Kind of damned if you do, damned if you don't.

It would be useful to have an option for Space (or some other key)

to pre-fill the locator only, and jump to the relevant next

field (as discussed below).



An additional improvement might be to change the Tab order of the

fields - again this is related to the use of real signal reports.

The default behaviour is to go from the callsign to the sent

signal report - this is fine in Run mode where you just have

to give the best report you can based on receiving just a callsign,

but in S&P you get your report from the Run station, which

allows a better determination of an accurate signal report, ergo

the sent report tends to get filled in last. It would be helpful

to have an option to change the tab (or space or other key) order to

Callsign->RxRST->RxSn->Loc->SntRST - perhaps tracking Run/S&P state.



These things may of course already be possible - I just haven't found a

way of doing it - in which case I should be grateful for any hints /

tips / instructions.



Best regards,



Pat (M0MGO).



--

Patrick Herborn <pat@...>








--
Patrick Herborn <pat@...>

Re: Grid square multiplier map

John Bednar
 

Andy,

 

This will be fixed in the next release. It was introduced in version 1.0.7825 with the Grid Field addition.

 

John, K3CT

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of andy@...
Sent: Wednesday, July 17, 2019 4:36 PM
To: N1MMLoggerPlus@groups.io
Subject: [N1MM+] Grid square multiplier map

 

We have been using N1MM and N1MM+ logger for many years, but just recently we have been having a problem.with the Grid square map,
As we are mainly interested in VHF / UHF contesting we have been using the grid square map, particulerally in contests using the first contact with each locator squares to give bonus points. This feature has therefore been extreamly useful

Unfortunately around early July this stopped working, and when a locator is logged this is not reflected on the map,
If the Grid squares window is used, this does indicate locators which have been worked.

This appears to be an issue with or without a radio connected and on all bands, additionally I have used a number of VHF contests' templates and on two computers, both Windows 10..

As an additional test I fired up a computer which hasn't been used for some time and ran a few mock QSOs on an old version of N1MM+ this worked fine, I changed the contest template a few times these all worked correctly. I then allowed N1MM+ to update, this broke the Grid square map.

Could there be a bug in the latest updates? is there any way I could go back a couple of updates to further test this issue.

Thanks in advance

Andy GD0AMD

Re: Tab / Space behaviour on VHF contests

Ken McVie <kenmc@...>
 

Hey Pat, you don't really believe your S meter [guess meter] do you??

73
Ken ZL4NR

On 18/07/2019 2:33 AM, Patrick Herborn wrote:
Good afternoon all!

This question / feature request pertains to the action of Tab and Space
when in a VHF contest. Space is most useful insofar as it will pre-fill
the locator information if pressed in the Callsign field (if using
history lookup), BUT in doing so it jumps directly to the received
serial box, pre-filling the sent and received reports with 59.

This behaviour is fine on HF contests, but we tend to send real signal
reports, which means one then has to go back to correct the pre-filled
signal reports. Occasionally one might have to correct the locator
for a /P but that's just life.

One way of avoiding this is to use the Tab key - this steps through
the fields and permits entry of RS(T) and serial, but then it doesn't
pre-fill the locator. Kind of damned if you do, damned if you don't.
It would be useful to have an option for Space (or some other key)
to pre-fill the locator only, and jump to the relevant next
field (as discussed below).

An additional improvement might be to change the Tab order of the
fields - again this is related to the use of real signal reports.
The default behaviour is to go from the callsign to the sent
signal report - this is fine in Run mode where you just have
to give the best report you can based on receiving just a callsign,
but in S&P you get your report from the Run station, which
allows a better determination of an accurate signal report, ergo
the sent report tends to get filled in last. It would be helpful
to have an option to change the tab (or space or other key) order to
Callsign->RxRST->RxSn->Loc->SntRST - perhaps tracking Run/S&P state.

These things may of course already be possible - I just haven't found a
way of doing it - in which case I should be grateful for any hints /
tips / instructions.

Best regards,

Pat (M0MGO).

Re: Tab / Space behaviour on VHF contests

John Bednar
 

Pat,

 

I just tested using the ARRL June VHF contest. As I expected, entering a callsign and pressing the Tab key DOES populate the exchange box from call history and place the cursor in the RST field.

 

The code also places the cursor in the RST box at the location to update the RST.

 

Pressing tab again advances the cursor to the RST box highlighting the correct character again.

 

John, K3CT

 

 

 

-----Original Message-----
From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of Patrick Herborn
Sent: Wednesday, July 17, 2019 10:34 AM
To: N1MMLoggerPlus@groups.io
Subject: [N1MM+] Tab / Space behaviour on VHF contests

 

Good afternoon all!

 

This question / feature request pertains to the action of Tab and Space

when in a VHF contest. Space is most useful insofar as it will pre-fill

the locator information if pressed in the Callsign field (if using

history lookup), BUT in doing so it jumps directly to the received

serial box, pre-filling the sent and received reports with 59.

 

This behaviour is fine on HF contests, but we tend to send real signal

reports, which means one then has to go back to correct the pre-filled

signal reports. Occasionally one might have to correct the locator

for a /P but that's just life.

 

One way of avoiding this is to use the Tab key - this steps through

the fields and permits entry of RS(T) and serial, but then it doesn't

pre-fill the locator. Kind of damned if you do, damned if you don't.

It would be useful to have an option for Space (or some other key)

to pre-fill the locator only, and jump to the relevant next

field (as discussed below).

 

An additional improvement might be to change the Tab order of the

fields - again this is related to the use of real signal reports.

The default behaviour is to go from the callsign to the sent

signal report - this is fine in Run mode where you just have

to give the best report you can based on receiving just a callsign,

but in S&P you get your report from the Run station, which

allows a better determination of an accurate signal report, ergo

the sent report tends to get filled in last. It would be helpful

to have an option to change the tab (or space or other key) order to

Callsign->RxRST->RxSn->Loc->SntRST - perhaps tracking Run/S&P state.

 

These things may of course already be possible - I just haven't found a

way of doing it - in which case I should be grateful for any hints /

tips / instructions.

 

Best regards,

 

Pat (M0MGO).

 

--

Patrick Herborn <pat@...>

 

Re: RSGB IOTA - Exchange

Dany VE2EBK
 

Hi Bob

Do not waste time with that, just enter 1 as serial receive. This station will not send its log anyway.

To have participated in the contest for 11 years in a row, I have not seen all kinds of exchanges received. The most common is NA001 or 002.
A W6 in the Bahamas (NA-001) ? ? ?  When you ask the operator to explain, he answers that he is NA and that it is his first or second QSO.

This year we take a break.

Have fun

73  Dany VE2EBK

CF2I, CG2I, CG200I, CK2I, VX2I, XM2I, XL2I
https://qsl.net/na128cg/

Re: Grid square multiplier map

ve3ki
 

I you want to try different versions in order to pin down just when the changed behaviour started, that is quite easy to do. Go to the N1MM+ web site at <https://n1mmwp.hamdocs.com/>. From the menu bar on the web page, select Downloads > Program Files > Latest Update Info > Latest Update Files. This will give you a window with a list of updates going back about three months. By default, the list may start out with the oldest update at the top; you can click on the header of the Modified column once or twice to change the order so the most recent update is at the top. You can download any of the update files by right-clicking on the file name and selecting Download. The update installer will be downloaded to your Downloads folder.  Simply run it to install the version named in the file name, then you can run the program to check the behaviour of that version. To restore the program to the current version, just download the most recent update installer and run it.

There is a list of the various program changes at Downloads > Program Files > Latest Update Info > Latest Update History. This list may be a week or two out of date.

73,
Rich VE3KI


On Wed, Jul 17, 2019 at 04:42 PM, <andy@...> wrote:
We have been using N1MM and N1MM+ logger for many years, but just recently we have been having a problem.with the Grid square map,
As we are mainly interested in VHF / UHF contesting we have been using the grid square map, particulerally in contests using the first contact with each locator squares to give bonus points. This feature has therefore been extreamly useful.

Unfortunately around early July this stopped working, and when a locator is logged this is not reflected on the map,
If the Grid squares window is used, this does indicate locators which have been worked.

This appears to be an issue with or without a radio connected and on all bands, additionally I have used a number of VHF contests' templates and on two computers, both Windows 10..

As an additional test I fired up a computer which hasn't been used for some time and ran a few mock QSOs on an old version of N1MM+ this worked fine, I changed the contest template a few times these all worked correctly. I then allowed N1MM+ to update, this broke the Grid square map.

Could there be a bug in the latest updates? is there any way I could go back a couple of updates to further test this issue.

Thanks in advance

Andy GD0AMD

Re: Tab / Space behaviour on VHF contests

andy@...
 

Things do appear to be very different across the pond, in the UK and Europe genuine signal reports are routinely given in V/UHF contests, and at least in the RSGB contests you WILL be penalised if you log any part of the exchange incorrectly.

After all the purpose of a contest is to pass information as quickly and accurately as possible, not to make up the contact details for the log..

You may have noticed that Pat's callsign places him as English, so he is also subject to these rules. and hence he has raised a perfectly valid query.

Perhaps we can now let someone answer Pats question.

Andy GD0AMD

Re: Tab / Space behaviour on VHF contests

VE9AA - Mike
 

OK, but the 50's and paper were a lifetime ago.
We're talking about 2019 & computer logging.

BTW, I log all dupes as well !

;-)

My comments are not meant as confrontational....just trying to keep it realistic and on point.

73,
Mike VE9AA

On Wed, Jul 17, 2019 at 05:48 PM, Gilbert Baron W0MN wrote:

Very true but in the 50s I remember a lot of contests where people gave a real report. It seems crazy to even have it as part of the exchange. I do not know if checkers in the 50s bothered with that either. In the days of paper logs I bet it was much more allowed to have some errors as long as the calls and other really important thigs were exchanged. In big contests with many entrants I bet a lot of logs were not checked carefully at all. Those with no chance for any significant score.

 

Outlook Laptop Gil W0MN

Re: Tab / Space behaviour on VHF contests

Dana Shtun
 

North America vhf contests all use grid - either 4 digits or 6 not signal report - it’s not needed
Dana ve3ds 



On Jul 17, 2019, at 4:40 PM, Michael Walker <va3mw@...> wrote:

I agree.

In a contest I have always used 59 or 599 and to the best of my knowledge, I have never lost a QSO due to that.  

Serial number or some other info?  yes

Mike va3mw


On Wed, Jul 17, 2019 at 4:37 PM VE9AA - Mike <ve9aa@...> wrote:
Honestly, nobody cares about a real signal report in any contest I've ever entered.  VHF incl)
If I ever rec'd one (I suppose I get 1 per contest), it still gets filled in as 59 or 599 and
nobody has ever lost a QSO. (the sponsors aren't checking your 579 against the received 559 reports, so far as I know)

IMO, you should reserve your real signal reports for on the air real weekday QSO's, not contest QSO's where the 59 or 599 is a mere place holder or a "get ready" (for the real exchange), which is normally a grid square in most VHF contests.

Maybe it's a lot different in EU or the UK, but . . . .

GL

Mike VE9AA...VHFer for decades

Re: Tab / Space behaviour on VHF contests

Gilbert Baron W0MN
 

Very true but in the 50s I remember a lot of contests where people gave a real report. It seems crazy to even have it as part of the exchange. I do not know if checkers in the 50s bothered with that either. In the days of paper logs I bet it was much more allowed to have some errors as long as the calls and other really important thigs were exchanged. In big contests with many entrants I bet a lot of logs were not checked carefully at all. Those with no chance for any significant score.

 

Outlook Laptop Gil W0MN

Hierro Candente Batir de Repente

44.08226N 92.51265 W en34rb

 

From: N1MMLoggerPlus@groups.io <N1MMLoggerPlus@groups.io> On Behalf Of Michael Walker
Sent: Wednesday, July 17, 2019 15:40
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] Tab / Space behaviour on VHF contests

 

I agree.

 

In a contest I have always used 59 or 599 and to the best of my knowledge, I have never lost a QSO due to that.  

 

Serial number or some other info?  yes

 

Mike va3mw

 

 

On Wed, Jul 17, 2019 at 4:37 PM VE9AA - Mike <ve9aa@...> wrote:

Honestly, nobody cares about a real signal report in any contest I've ever entered.  VHF incl)
If I ever rec'd one (I suppose I get 1 per contest), it still gets filled in as 59 or 599 and
nobody has ever lost a QSO. (the sponsors aren't checking your 579 against the received 559 reports, so far as I know)

IMO, you should reserve your real signal reports for on the air real weekday QSO's, not contest QSO's where the 59 or 599 is a mere place holder or a "get ready" (for the real exchange), which is normally a grid square in most VHF contests.

Maybe it's a lot different in EU or the UK, but . . . .

GL

Mike VE9AA...VHFer for decades

Grid square multiplier map

andy@...
 

We have been using N1MM and N1MM+ logger for many years, but just recently we have been having a problem.with the Grid square map,
As we are mainly interested in VHF / UHF contesting we have been using the grid square map, particulerally in contests using the first contact with each locator squares to give bonus points. This feature has therefore been extreamly useful.

Unfortunately around early July this stopped working, and when a locator is logged this is not reflected on the map,
If the Grid squares window is used, this does indicate locators which have been worked.

This appears to be an issue with or without a radio connected and on all bands, additionally I have used a number of VHF contests' templates and on two computers, both Windows 10..

As an additional test I fired up a computer which hasn't been used for some time and ran a few mock QSOs on an old version of N1MM+ this worked fine, I changed the contest template a few times these all worked correctly. I then allowed N1MM+ to update, this broke the Grid square map.

Could there be a bug in the latest updates? is there any way I could go back a couple of updates to further test this issue.

Thanks in advance

Andy GD0AMD

Re: Tab / Space behaviour on VHF contests

Michael Walker
 

I agree.

In a contest I have always used 59 or 599 and to the best of my knowledge, I have never lost a QSO due to that.  

Serial number or some other info?  yes

Mike va3mw


On Wed, Jul 17, 2019 at 4:37 PM VE9AA - Mike <ve9aa@...> wrote:
Honestly, nobody cares about a real signal report in any contest I've ever entered.  VHF incl)
If I ever rec'd one (I suppose I get 1 per contest), it still gets filled in as 59 or 599 and
nobody has ever lost a QSO. (the sponsors aren't checking your 579 against the received 559 reports, so far as I know)

IMO, you should reserve your real signal reports for on the air real weekday QSO's, not contest QSO's where the 59 or 599 is a mere place holder or a "get ready" (for the real exchange), which is normally a grid square in most VHF contests.

Maybe it's a lot different in EU or the UK, but . . . .

GL

Mike VE9AA...VHFer for decades