Date   
locked Re: New Version

Tom - N1MM
 

Version 1.0.7342(November 13, 2018)
  1. Unhandled Exception: Fix for unhandled exception in ContestInstance (N9ECY) (Coded by KU7T)
  2. ARRL SS: Better processing of exchange. Any number, without a precedence or section following the number will be treated as the QSO Number. (Coded by N2IC)

Re: ICOM 7300 using DVK Messages

John Bednar
 

 

Rich,

 

When the concatenate box is checked, the code checks for:

  • Wav file read permission.
  • PCM encoding.
  • Sample rate, bit depth, and channels.
  • Missing letter & number files. These files are required:  "0", "1", "2", "3", "4", "5",

"6", "7", "8", "9", "A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K",

"L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",

"STROKE", "STROKEP", "QUERY"

 

The Lettters Path and Wav\Operator directories are both checked.

 

If file snips of partial callsigns exist (“PY”) or full callsigns exist, they are used for playback when voicing the callsign.

 

If the complete expanded number set exists (“TWENTY”, “FORTY”, etc), those files are used to voice the number (One-Thousand-Three) instead of (One-Zero-Zero-Three).

 

John, K3CT

 

 

From: N1MMLoggerPlus@groups.io <N1MMLoggerPlus@groups.io> On Behalf Of ve3ki
Sent: Monday, November 12, 2018 8:25 PM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MMLoggerPlus] ICOM 7300 using DVK Messages

 

If he is using wav files from N1MM+ rather than DVK memories in the radio, then a simple #,restofexchange.wav should do it, shouldn't it (as long as everything is recorded at the same sample rate, etc.)?

73,
Rich VE3KI


On Mon, Nov 12, 2018 at 08:17 PM, John Bednar wrote:

 

Rich,

 

The IC-7300 contains a radio codec. I assumed Scott is using the sound card in the radio.

 

John, K3CT

 

From: N1MMLoggerPlus@groups.io <N1MMLoggerPlus@groups.io> On Behalf Of ve3ki
Sent: Monday, November 12, 2018 7:58 PM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MMLoggerPlus] ICOM 7300 using DVK Messages

 

Scott, how are you sending the DVK messages from the 7300? Is it using a CAT1HEX-type macro? If so, you could try a message like ! # {END}{CAT1HEX ...} where the DVK message contains precedence, call, check and section. John can correct me if I am wrong, but I suspect you might need the {END} macro to prevent the {CAT1HEX} from being executed before the ! and # are sent.

73,
Rich VE3KI


On Mon, Nov 12, 2018 at 06:53 PM, Scott wrote:

Most likely the answer will be no, but I'm going to ask anyway. Since I started using the DVK messages from my 7300, I am totally sold on using them in contests as I find it very easy to record messages and send from N1MM+. Is there a way to mix these with my .wav files that I used to use? For example, this weekend is ARRL November SS phone, and I had a macro in the past where I would use a mix of the .wav files to send all the information that is sent, including the callsigns using the numbers and letters that I had recorded a few years ago. It sounded robotic, but it also worked. Is it possible to somehow program a macro for the exchange so I can send the callsign and the sequential number from a .wav and the rest from a DVK message? If not, then it's no big deal, just wondering if it is possible. I was experimenting a bit with it and doesn't seem to work. I could just revert back to the .wav files for one contest if I really wanted to.

Scott
KN3A

 

Re: ICOM 7300 using DVK Messages

Barry Bettman
 

Are you referring to:

#1  playing ic7300 dvk memories that are pre-recorded on the rig 
or 
#2 playing N1MM+ messages that were previously recorded 


On Mon, Nov 12, 2018 at 4:29 PM John Bednar <k3ct@...> wrote:

 

Scott,

 

Logger+ Audio player has an option to concatenate wav files.

All files need to have the same sample rate. The files are checked when the option is enabled.

 

John, K3CT

 

 

From: N1MMLoggerPlus@groups.io <N1MMLoggerPlus@groups.io> On Behalf Of Scott
Sent: Monday, November 12, 2018 6:54 PM
To: N1MMLoggerPlus@groups.io
Subject: [N1MMLoggerPlus] ICOM 7300 using DVK Messages

 

Most likely the answer will be no, but I'm going to ask anyway. Since I started using the DVK messages from my 7300, I am totally sold on using them in contests as I find it very easy to record messages and send from N1MM+. Is there a way to mix these with my .wav files that I used to use? For example, this weekend is ARRL November SS phone, and I had a macro in the past where I would use a mix of the .wav files to send all the information that is sent, including the callsigns using the numbers and letters that I had recorded a few years ago. It sounded robotic, but it also worked. Is it possible to somehow program a macro for the exchange so I can send the callsign and the sequential number from a .wav and the rest from a DVK message? If not, then it's no big deal, just wondering if it is possible. I was experimenting a bit with it and doesn't seem to work. I could just revert back to the .wav files for one contest if I really wanted to.

Scott
KN3A

Re: ICOM 7300 using DVK Messages

ve3ki
 

If he is using wav files from N1MM+ rather than DVK memories in the radio, then a simple #,restofexchange.wav should do it, shouldn't it (as long as everything is recorded at the same sample rate, etc.)?

73,
Rich VE3KI


On Mon, Nov 12, 2018 at 08:17 PM, John Bednar wrote:

 

Rich,

 

The IC-7300 contains a radio codec. I assumed Scott is using the sound card in the radio.

 

John, K3CT

 

From: N1MMLoggerPlus@groups.io <N1MMLoggerPlus@groups.io> On Behalf Of ve3ki
Sent: Monday, November 12, 2018 7:58 PM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MMLoggerPlus] ICOM 7300 using DVK Messages

 

Scott, how are you sending the DVK messages from the 7300? Is it using a CAT1HEX-type macro? If so, you could try a message like ! # {END}{CAT1HEX ...} where the DVK message contains precedence, call, check and section. John can correct me if I am wrong, but I suspect you might need the {END} macro to prevent the {CAT1HEX} from being executed before the ! and # are sent.

73,
Rich VE3KI


On Mon, Nov 12, 2018 at 06:53 PM, Scott wrote:

Most likely the answer will be no, but I'm going to ask anyway. Since I started using the DVK messages from my 7300, I am totally sold on using them in contests as I find it very easy to record messages and send from N1MM+. Is there a way to mix these with my .wav files that I used to use? For example, this weekend is ARRL November SS phone, and I had a macro in the past where I would use a mix of the .wav files to send all the information that is sent, including the callsigns using the numbers and letters that I had recorded a few years ago. It sounded robotic, but it also worked. Is it possible to somehow program a macro for the exchange so I can send the callsign and the sequential number from a .wav and the rest from a DVK message? If not, then it's no big deal, just wondering if it is possible. I was experimenting a bit with it and doesn't seem to work. I could just revert back to the .wav files for one contest if I really wanted to.

Scott
KN3A

 

Re: ICOM 7300 using DVK Messages

John Bednar
 

 

Rich,

 

The IC-7300 contains a radio codec. I assumed Scott is using the sound card in the radio.

 

John, K3CT

 

From: N1MMLoggerPlus@groups.io <N1MMLoggerPlus@groups.io> On Behalf Of ve3ki
Sent: Monday, November 12, 2018 7:58 PM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MMLoggerPlus] ICOM 7300 using DVK Messages

 

Scott, how are you sending the DVK messages from the 7300? Is it using a CAT1HEX-type macro? If so, you could try a message like ! # {END}{CAT1HEX ...} where the DVK message contains precedence, call, check and section. John can correct me if I am wrong, but I suspect you might need the {END} macro to prevent the {CAT1HEX} from being executed before the ! and # are sent.

73,
Rich VE3KI


On Mon, Nov 12, 2018 at 06:53 PM, Scott wrote:

Most likely the answer will be no, but I'm going to ask anyway. Since I started using the DVK messages from my 7300, I am totally sold on using them in contests as I find it very easy to record messages and send from N1MM+. Is there a way to mix these with my .wav files that I used to use? For example, this weekend is ARRL November SS phone, and I had a macro in the past where I would use a mix of the .wav files to send all the information that is sent, including the callsigns using the numbers and letters that I had recorded a few years ago. It sounded robotic, but it also worked. Is it possible to somehow program a macro for the exchange so I can send the callsign and the sequential number from a .wav and the rest from a DVK message? If not, then it's no big deal, just wondering if it is possible. I was experimenting a bit with it and doesn't seem to work. I could just revert back to the .wav files for one contest if I really wanted to.

Scott
KN3A

Re: ICOM 7300 using DVK Messages

ve3ki
 

Scott, how are you sending the DVK messages from the 7300? Is it using a CAT1HEX-type macro? If so, you could try a message like ! # {END}{CAT1HEX ...} where the DVK message contains precedence, call, check and section. John can correct me if I am wrong, but I suspect you might need the {END} macro to prevent the {CAT1HEX} from being executed before the ! and # are sent.

73,
Rich VE3KI


On Mon, Nov 12, 2018 at 06:53 PM, Scott wrote:
Most likely the answer will be no, but I'm going to ask anyway. Since I started using the DVK messages from my 7300, I am totally sold on using them in contests as I find it very easy to record messages and send from N1MM+. Is there a way to mix these with my .wav files that I used to use? For example, this weekend is ARRL November SS phone, and I had a macro in the past where I would use a mix of the .wav files to send all the information that is sent, including the callsigns using the numbers and letters that I had recorded a few years ago. It sounded robotic, but it also worked. Is it possible to somehow program a macro for the exchange so I can send the callsign and the sequential number from a .wav and the rest from a DVK message? If not, then it's no big deal, just wondering if it is possible. I was experimenting a bit with it and doesn't seem to work. I could just revert back to the .wav files for one contest if I really wanted to.

Scott
KN3A

Re: ICOM 7300 using DVK Messages

John Bednar
 

 

Scott,

 

Logger+ Audio player has an option to concatenate wav files.

All files need to have the same sample rate. The files are checked when the option is enabled.

 

John, K3CT

 

 

From: N1MMLoggerPlus@groups.io <N1MMLoggerPlus@groups.io> On Behalf Of Scott
Sent: Monday, November 12, 2018 6:54 PM
To: N1MMLoggerPlus@groups.io
Subject: [N1MMLoggerPlus] ICOM 7300 using DVK Messages

 

Most likely the answer will be no, but I'm going to ask anyway. Since I started using the DVK messages from my 7300, I am totally sold on using them in contests as I find it very easy to record messages and send from N1MM+. Is there a way to mix these with my .wav files that I used to use? For example, this weekend is ARRL November SS phone, and I had a macro in the past where I would use a mix of the .wav files to send all the information that is sent, including the callsigns using the numbers and letters that I had recorded a few years ago. It sounded robotic, but it also worked. Is it possible to somehow program a macro for the exchange so I can send the callsign and the sequential number from a .wav and the rest from a DVK message? If not, then it's no big deal, just wondering if it is possible. I was experimenting a bit with it and doesn't seem to work. I could just revert back to the .wav files for one contest if I really wanted to.

Scott
KN3A

ICOM 7300 using DVK Messages

Scott
 

Most likely the answer will be no, but I'm going to ask anyway. Since I started using the DVK messages from my 7300, I am totally sold on using them in contests as I find it very easy to record messages and send from N1MM+. Is there a way to mix these with my .wav files that I used to use? For example, this weekend is ARRL November SS phone, and I had a macro in the past where I would use a mix of the .wav files to send all the information that is sent, including the callsigns using the numbers and letters that I had recorded a few years ago. It sounded robotic, but it also worked. Is it possible to somehow program a macro for the exchange so I can send the callsign and the sequential number from a .wav and the rest from a DVK message? If not, then it's no big deal, just wondering if it is possible. I was experimenting a bit with it and doesn't seem to work. I could just revert back to the .wav files for one contest if I really wanted to.

Scott
KN3A

Re: Muting mike audio during message playback not working in Logger+ Audio? #n1mm

Peter Barron
 

Hi All

I have the same "feature" with my Soundcard as well , it works fine with Config Audio,  in the Windows  Speakers Properties screen I also have a Mic Level window and when I use Configure Audio it shows the Mic as muted  during playback with N1MM Logger+.

But when Logger+ Audio is used , it shows on the Speaker Properties Mic at normal level and on the Record Properties the level rolls back to -186dB. so the through path is still live.

However  if I use the on board  Realtek AC883 HDAUDIO that works the other way??? That is
with Logger+ Audio  the onboard HDAUDIO work fine and mutes, Providing I set "listen  to this device" to ON.

If I use Configure Audio I can't select the MIC to mute on the HDAUDIO chip!!

I have detailed screen snips etc if anyone needs them

Soundcard is Creative Audigy RX 7.1.

Cheers

Peter

VE3PN

Re: Sending QTCs in the WAE RTTY contest when using SO2R

Rick Ellison
 

Hi Sam..

This is on my list to look at. I had 2 other reports of this..

 

73 Rick N2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of w4pk@...
Sent: Monday, November 12, 2018 4:14 PM
To: N1MMLoggerPlus@groups.io
Subject: [N1MMLoggerPlus] Sending QTCs in the WAE RTTY contest when using SO2R

 

Hello all

I use SO2R, and I encountered a problem when sending QTCs.  If I had recently logged a contact (non NA) on the opposite radio AND then received a request for (or asked for) QTCs on the current radio then it would send them on the opposite radio. The current radio had focus, but when I did the CTRL-Z thing it would come up with the last call I had logged on the opposite radio and of course it would transmit QTCs on that radio.   In a couple of cases I forced the QTCs to be sent on the current radio by manually selecting that radio (via> hardware) but this meant that the wrong call was logged with the QTCs being sent. 

I had no problem with receiving QTCs or in sending them if the last logged station  on the opposite radio was from the NA region.

Has anyone else experienced this, or yet again am I the only one?

73, Sam W4PK

Re: Radio sent invalid CAT DATA

Pete N4KW
 

Hi Joe,  Well I believe it is now working properly.  I want to thank you
for taking the time to help with this problem.
Without your descriptions on how you thought it worked sure helped me
start to understand how this all worked together.
I did not know about the system not being able to have two parallel TDX
lines etc.  So here is what I did.

I turned OFF SW#1 placing the SPE in a listen mode.  Doing this I lost
the SPE in that it was not following my xcvr (band and freq).
Not knowing what to do next I decided to remove the USB cable to the PC
and that did not change a thing.  So I decided to normalize things
pluged in the USB cable and saw that now the SPE was now on the same
band as the xcvr and SW#1 was still OFF.  I sat and watched N1MM+
for about 20 minutes and no indication of invalid data.  It has been
working fine for the past 3 days.  Everything is working and both
switches on the RS-232 connector plugged into the SPE are OFF, the USB
cable is plugged into the SPE to my PC, SPE and N1MM+ both follow my
xcvr etc.  No invalid data indicated. Looks like the listen mode is just
that and I only have one TXD line in use.

Not sure why it started to work when I plugged the USB cable back in,
could have been coincidence.

Thanks again Joe,  73,m Pete, N4KW

On 11/6/2018 7:57 PM, Joe Subich, W4TV wrote:


On 2018-11-06 7:35 PM, N4KW Pete wrote:
Joe can you explain what SW#1 is actually doing
Not without a schematic to actually see what the switch does.

or what is the meaning of "On, for normal RS-232, and Off, for serial
Port Sharing".
A guess is that "on" connects the serial out line from the amplifier
to the serial in line of the transceiver (e.g. pin 9 on the SPE
to pin 3 of the transceiver) when "on" (figure 12.4, 12.5, & 12.6
in the SPE Manual) and disconnects the serial out line when OFF
(figure 14.2 in the SPE Manual).  Note: the SPE Manual contradicts
itself in the labeling of Figure 12.4, 12.5, & 12.6 making it even
more difficult to know hat is really going on!

But in general, "ON" would be the setting for using the amplifier
with a rig only and "OFF" would be the "Listen Only" mode (listen
to data from rig to computer/logging program).  This is only a
guess based on the operation of "listen only" devices.

73,

   ... Joe, W4TV


On 2018-11-06 7:35 PM, N4KW Pete wrote:
Joe can you explain what SW#1 is actually doing or what is the meaning
of "On, for normal RS-232, and Off, for serial Port Sharing".  I
understand RS-232.

73, Pete, N4KW


On 11/6/2018 2:36 PM, Joe Subich, W4TV wrote:

I don't have an SPE.  My comments are based on studying the SPE
manuals and dealing with similar "paralleled device" problems
(e.g. SteppIR, certain auto-tuners, etc.).

RS-232 can not possibly work with two "transmitters" connected to
one "receiver" and most rigs will respond with garbage if two
devices "talk" to the rig at the same time.

Finally, unless the logging program is written to ignore invalid
input (or unexpected input) - like DXLab Suite CIV Commander -
they will often complain or even lock up entirely when receiving
invalid/corrupted/unexpected responses from the radio.

73,

   ... Joe, W4TV


On 2018-11-06 2:25 PM, N4KW Pete wrote:
Interesting Joe, the card that came with my cables says #1 Default ON,
#2 Default OFF.  With your switches in those position are you able to
see your SPE front panel on your monitor and control the linear with
your mouse?  I believe that if SW#2 is ON then your linear will
turn on
and off with your xcvr.  It that the way yours works.
I could try your settings and see what effect it would have. Don't
think it would hurt anything.

73, Pete, N4KW


On 11/6/2018 9:10 AM, Joe Subich, W4TV wrote:

Hope you understand and that I have not confused you. I was told
that
the Default position of the switches is SW1 OFF and SW2 ON and that
is the way I presently have it.
You have thoroughly confused me with a cable with switches in it.

The principle is that the rig can not have two devices (e.g. computer
and amplifier) connected to the "receive" data line at the same time.
I leave it to you to figure out whether your configuration meets that
requirement.

73,

   ... Joe, W4TV


On 2018-11-05 11:47 PM, N4KW Pete wrote:
Hey Joe,  I really appreciate all the research you must have done
to get
down to the connectors pins etc.  I do not quite understand
everything.
put have a pretty good idea.  My cables were ordered and made
before I
ordered the linear.  My xcvr is a FTDX-5000 and my cables were
made by
KC5PCB.  The RS-232 connector that plugs into the SPE 1.3K-FA
linear has
two small switches, switch No. 1 switch is TXD and it is off, No.2
switch is
Remote and is On.  With the documentation I received it says to
turn OFF
SWitch 1 for serial port sharing. and switch 2 Off to disable
remote.

I use the remote function as it allows the SPE front panel's
identical
image to appear on my monitor and I can control the linear with the
mouse.
As I understand it, if I reversed the switch settings to SW#1 to off
(for serial port sharing) and SW#2 to off the spe would turn on and
off
by my xcvr .
Wonder if I turn off SW#1 (allowing serial port sharing) and keep
SW#2
on I would still be able to use the remote feature. Hope you
understand
and that
I have not confused you.  I was told that the Default position of
the
switches is SW1 OFF and SW2 ON and that is the way I presently have
it.

73, Pete, N4KW
ps block diagram of the cables says sw1 should be OFF for just
listening. Does not listening mean that it does not poll?

On 11/5/2018 3:34 PM, Joe Subich, W4TV wrote:

The typical configuration for a "Y" is to connect all three wires
(2, 3, 5) between the rig and computer and connect *only* data
from the rig to the "third" device (pins 2, 5 on the rig to the
amplifier).

Per the SPE manual(s), that would be connections to only pin 9
(data) and 4 (ground) as shown in figure 14.2 (pg 48) of the
1.3K-FA manual, fig 14.2 (pg 45) of the 2K-FA manual or Fig 14.2
(pg 39) of the 1K-FA manual.

What this connection does is prevent the amplifier from polling
the rig.  If you intend to operate without a logging program that
polls the rig, use the rig's menu to turn on "auto information"
(rig sends data automatically whenever frequency/band changes)
so the amplifier can follow frequency changes.  The exact menu
item will depend on make/model of transceiver.

73,

   ... Joe, W4TV


On 2018-11-05 3:10 PM, N4KW Pete wrote:
Hi Joe, thanks for replying to my note.  I have a "Y" cable and
would
guess that both would be polling but not sure if its at the same
time,
and if so then
there could be bumping heads and N1MM cannot decipher that. Is
there a
way I can fix what is happening.  Never gave any thought to both
polling
at the
same time.
73, Pete, N4KW


On 11/5/2018 1:59 PM, Joe Subich, W4TV wrote:

I have been testing this situation and found today that this
seems to
happens only when my SPE linear is being used. Any one familiar
with
this Red Dot and Note. Could it be a false positive.
How is your SPE amplifier connected?  Is it simply connected to
*listen* to the data from the transceiver or are you using some
kind of port splitter to allow both N1MM+ and the SPE to poll
your rig at the same time?

73,

   ... Joe, W4TV


On 2018-11-05 11:32 AM, N4KW Pete wrote:
When using N1MM+ I keep seeing a Red Dot in the lower left
corner
of the
main screen with the note "Radio sent invalid CAT DATA."
The note and the red dot will disappear and come back after a
short
while.  I looked to see if N1MM had some kind of "ERROR" file
that
would
be generated
when encountering any kind of error but unable to find any
mention of
such a file.  I spent a lot of time on this yesterday and felt
that
if I
continued the error could impact on my Cabrilo file so removed
myself
from the SS.

I use DXLab as my logging software and it has error logs for the
various
apps.  The commander app that interfaces with my xcvr and CAT
does not
show any errors.  I have been testing this situation and found
today
that this seems to happens only when my SPE linear is being
used.
Any one familiar with this Red Dot and Note. Could it be a false
positive.

73, Pete, N4KW
























Sending QTCs in the WAE RTTY contest when using SO2R

w4pk@w4pk.com
 

Hello all

I use SO2R, and I encountered a problem when sending QTCs.  If I had recently logged a contact (non NA) on the opposite radio AND then received a request for (or asked for) QTCs on the current radio then it would send them on the opposite radio. The current radio had focus, but when I did the CTRL-Z thing it would come up with the last call I had logged on the opposite radio and of course it would transmit QTCs on that radio.   In a couple of cases I forced the QTCs to be sent on the current radio by manually selecting that radio (via> hardware) but this meant that the wrong call was logged with the QTCs being sent. 

I had no problem with receiving QTCs or in sending them if the last logged station  on the opposite radio was from the NA region.

Has anyone else experienced this, or yet again am I the only one?

73, Sam W4PK

Re: DI Window pause

ShelbyK4WW
 

I was in an abnormally disadvantaged situation, having no usable antenna for high bands. I understand the concept of passing QTC's. What I don't understand is a station asking for, or wanting to pass, QTC's after requiring several repeats for the contest exchange? I only worked 4 stations that I felt comfortable passing QTC's, and even then repeats were required. 

On Mon, Nov 12, 2018 at 2:30 PM ve3ki <ve3iay@...> wrote:
On Mon, Nov 12, 2018 at 11:46 AM, Bill KO7SS wrote:
As Rich VE3KI said, QTC editing seemed best done in the log window by double clicking, but this was time
consuming. 
Actually, that is not quite what I said. What I said was that even after the QTC window has been closed, it is still possible to edit QTCs in the Log window. In other words, just because the QTC window has closed, if you can see errors in the logged data, do not despair, it is still possible to fix them then and there (or later) in the Log window. That does not necessarily mean that I was recommending doing that as a routine procedure.

I would never have guessed that your trick of waiting and not clicking on QTCs, responding RRR and closing while the window was still empty and then re-opening the QTC window to enter the QTCs again would work at all. Given that it works, I can see doing this as an S&P station, but I would not want to be doing this as a CQing station. For one thing, as soon as you send RRR, there is a greater or lesser likelihood that someone will be waiting in the wings (or relying on Skimmer spots) wanting to work you, and who would call as soon as the RRR sequence is over and not want to wait 8 seconds or however long it takes you to catch up.

The intent of the original design was that you would click on QTCs as they came in, using the S (for Skip) buttons for garbled QTCs so you could go back and ask for fills for them at the end of the original packet, and that sending the RRR sequence told everyone else listening as well as the station sending the QTCs that you had everything logged and were ready to move on to the next QSO.

73,
Rich VE3KI



--
73, Shelby - K4WW
As I don't have an iPad nor iPhone, sent from my PC

Re: DI Window pause

ve3ki
 

On Mon, Nov 12, 2018 at 11:46 AM, Bill KO7SS wrote:
As Rich VE3KI said, QTC editing seemed best done in the log window by double clicking, but this was time
consuming. 
Actually, that is not quite what I said. What I said was that even after the QTC window has been closed, it is still possible to edit QTCs in the Log window. In other words, just because the QTC window has closed, if you can see errors in the logged data, do not despair, it is still possible to fix them then and there (or later) in the Log window. That does not necessarily mean that I was recommending doing that as a routine procedure.

I would never have guessed that your trick of waiting and not clicking on QTCs, responding RRR and closing while the window was still empty and then re-opening the QTC window to enter the QTCs again would work at all. Given that it works, I can see doing this as an S&P station, but I would not want to be doing this as a CQing station. For one thing, as soon as you send RRR, there is a greater or lesser likelihood that someone will be waiting in the wings (or relying on Skimmer spots) wanting to work you, and who would call as soon as the RRR sequence is over and not want to wait 8 seconds or however long it takes you to catch up.

The intent of the original design was that you would click on QTCs as they came in, using the S (for Skip) buttons for garbled QTCs so you could go back and ask for fills for them at the end of the original packet, and that sending the RRR sequence told everyone else listening as well as the station sending the QTCs that you had everything logged and were ready to move on to the next QSO.

73,
Rich VE3KI

Re: DI Window pause

Bill KO7SS
 

When it was time to get QTC's, I would bring up the QTC RX window just to use the QRV button, then sit
and watch the QTC's roll on the screen, making sure I eventually had 10 clean clickable QTC's visible,
using the QTC RX window repeat buttons, and then freeze the screen.

Then I would hit save on the QTC RX window with no QTC's entered, this would send the R R R message
and the QTC screen would disappear. Then I would retype the QTC sending station call in the active field,
bring up another QTC RX window, and click,click,click enter everything, hit save and it was done in 8 seconds.

Again my problem was a tiny flickering cursor on a high res 2560 X 1440 screen as the QTC's were actively
rolling in.

As Rich VE3KI said, QTC editing seemed best done in the log window by double clicking, but this was time
consuming. 

None of the EU stations were above S7 here on 20 so it was a challenge with them. The above process
was very quick when begging QTC's from 20 over 9 JA's and PY/CE/LU

73, Bill KO7SS

Re: DI Window pause

ve3ki
 

Once QTCs have been logged and the QTC window has closed, you can edit QTCs in the Log window the same way you can edit QSOs. Be very careful doing this - it is easy to screw things up. It might be best to make a backup copy of the log before editing, either by making a copy of the entire database file, or by creating a new empty database file, switching back to the original database, using the "File > Copy this Contest to Another Database" menu item to copy the existing log into the new database, and then opening the new database where you can edit the copy of the log without affecting the original.

If you use the Edit window rather than double-clicking in the Log window, the field labels in the Edit window will be confusing, as QTC data are stored in fields that are normally used for other purposes for QSOs. You will need to inspect existing QTCs carefully to see where the data items are stored.

73,
Rich VE3KI



On Mon, Nov 12, 2018 at 10:18 AM, Eric Wagner wrote:
Bill, 
 
How did you bring up the QTC window after logging to correct errors in the QTC list?  Looking for an easy way to fix my QTC operating errors.  
 
I resorted to writing down the received QTCs when I jumbled up the receive window on the first couple QTCs I received. 
 
I too saw the pause a couple times.  Just clicking on the yellow bar got it back to normal for me.  It was handy having the freeze feature when I as copying down the messed up QTCs entries.  
 
The QTC window worked great for sending and I was careful to only accept QTC from very strong stations that assured clean decoding.
 
Thanks,
Eric - NR4O  

 

On Nov 12, 2018, at 1:12 AM, Bill KO7SS via Groups.Io <ko7ss@...> wrote:

The N1MM WAE RTTY QTC window is amazing software. Thank you to the developers! My main issue was a quivering/flickering cursor in the
RX window as the QTC's were being sent. Eventually my procedure was to acknowledge the QTC's as rcvd and freeze the screen. Then bring
up the RX QTC window again and fill it out with clicks and typing. Since the contesting pace on Sunday was more "casual" and I was begging
for QTC's it was all good. 

73, Bill KO7SS

Re: BANDMAP and TELNET, NO SPOTS

Bill KO7SS
 

I assume that you have signed on successfully to one of the clusters? Very few of the ones that are on the
N1MM list actually work. NC7J or VE7CC seem most reliable. On the filters tab check all the bands and CW
as the mode.

73, Bill KO7SS

BANDMAP and TELNET, NO SPOTS

KEN
 

Using Win10, N1MM v1.0.77300.0 update, computer hardwire to router, Yaesu FT-450D, RT Systems cable 9 pin to USB.  
I cannot get any spots from any of the Telnet sources on the Cluster list.
The RT systems cable is communicating.  I can see that the freq. changes  in both the logging window and with the Bandmap. I have viewed all the tabs in the Telnet window. In the Filters tab I tried various settings, reviewed the suggestions in  the window associated with the   Help - Why don't I see spots?.
Help
Needed.     ham.wn8y@...

Re: DI Window pause

Eric Wagner
 

Bill, 

How did you bring up the QTC window after logging to correct errors in the QTC list?  Looking for an easy way to fix my QTC operating errors.  

I resorted to writing down the received QTCs when I jumbled up the receive window on the first couple QTCs I received. 

I too saw the pause a couple times.  Just clicking on the yellow bar got it back to normal for me.  It was handy having the freeze feature when I as copying down the messed up QTCs entries.  

The QTC window worked great for sending and I was careful to only accept QTC from very strong stations that assured clean decoding.

Thanks,
Eric - NR4O  


On Nov 12, 2018, at 1:12 AM, Bill KO7SS via Groups.Io <ko7ss@...> wrote:

The N1MM WAE RTTY QTC window is amazing software. Thank you to the developers! My main issue was a quivering/flickering cursor in the
RX window as the QTC's were being sent. Eventually my procedure was to acknowledge the QTC's as rcvd and freeze the screen. Then bring
up the RX QTC window again and fill it out with clicks and typing. Since the contesting pace on Sunday was more "casual" and I was begging
for QTC's it was all good. 

73, Bill KO7SS

Re: Flickering Call entry window SOLVED

Stephen Tompsett
 

Windows looks for mouse input on ports with serial enumeration' enabled, and can often mistake non-mouse data as mouse motion or clicks. I regularly encounter problems with GPS receivers causing problems after MS Windows updates if device drivers get updated. 
The option isn't available for all devices, it depends on the device driver.

Stephen Tompsett


On Mon, 12 Nov 2018, 15:04 GIWagner@... <giwagner@... wrote:
Stephan, I looked at my hardware and virtual com ports, and I only see a check box for "Serial enumeration" for the virtual com ports.  No reference to "Serial enumeration" on the hardware com ports.  I am not familiar with "Serial enumeration", so please tell me what it is, and why this might matter.

Tnx, George K5KG