Date   

Simulator

Chris Gay
 

I remember hearing that for some types of CW contests, you can turn N1MM+ into a contest simulator for practice. But I've forgotten how to do it and can't find the information. Could someone point me to the chunk of documentation that covers this?

KU4A


Re: WAE RTTY. Why am I off frequency?

WA5LXS
 

Thanks Julian. I may have used the band map or more likely I clicked on the N1MM spectrum display. I have not used RBN, so I will investigate that approach. Will RBN show my mark/space frequency or just show my frequency shifted by the mark or space? Good idea, thanks!


Re: Rx QTC issue in WAE RTTY

Rick Ellison
 

Victor..
When the RX QTC window opens you need to click on the QTC in the rx window to place it in the QTCWindow.
I would suggest you watch this video here that explains it all..
https://n1mmwp.hamdocs.com/mmfiles/waerttyqtc2018-mp4/

73 Rick N2AMG

-----Original Message-----
From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of Victor Culver via groups.io
Sent: Monday, November 16, 2020 3:15 PM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] Rx QTC issue in WAE RTTY

Gentlemen, my problem with QTC was on the RQTC end of things. Perhaps cockpit error, but the RQTC window came up on CTRL-Z but didn't populate. Data was saved in the D1 window but I didn't have the presence of mind to make a copy of it. I did try to type it in the QTC box manually but #10 wouldn't take the data. In futzing around I managed to mess up the #9 data boxes also. I don't have anything now to 'fix'.

I do NOT use fldigi, which some have accused of being the problem. I run latest version of N1MM+ stand alone.

I truly missed a lot of score because I neither received nor sent QTCs in this event. Gotta get a fix before next time!

--
73, Vic W4VIC

“Anyone who has made the effort to get a license and get on the air is already something of a hero.
They are doing something to improve their lives, expanding their horizons, learning new things, and making new friends. Adventure waits them and they are eager to experience it. They are enlarging their lives. Good for them – and they are us.” -- W9KNI








--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


Re: Rx QTC issue in WAE RTTY

Victor Culver
 

Gentlemen, my problem with QTC was on the RQTC end of things. Perhaps cockpit error, but the RQTC window came up on CTRL-Z but didn't populate. Data was saved in the D1 window but I didn't have the presence of mind to make a copy of it. I did try to type it in the QTC box manually but #10 wouldn't take the data. In futzing around I managed to mess up the #9 data boxes also. I don't have anything now to 'fix'.

I do NOT use fldigi, which some have accused of being the problem. I run latest version of N1MM+ stand alone.

I truly missed a lot of score because I neither received nor sent QTCs in this event. Gotta get a fix before next time!

--
73, Vic W4VIC

“Anyone who has made the effort to get a license
and get on the air is already something of a hero.
They are doing something to improve their lives,
expanding their horizons, learning new things,
and making new friends. Adventure waits them
and they are eager to experience it. They are
enlarging their lives. Good for them – and
they are us.” -- W9KNI


Re: QTC's issue

Rick Ellison
 

Peter clicking on the yellow bar should turn it off while it is yellow.

I have not used Gritty in a long time. I'm not sure why it would only happen when a N1MM user sends the time it is all being sent as string asci so Gritty should not have an issue copying it.

73 Rick N2AMG

-----Original Message-----
From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of Peter Krüger
Sent: Monday, November 16, 2020 2:42 PM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

I had the same problem sometimes - DI (MMTTY) paused and it was hard to activate it again (and I could not take any QTC into the QTC window if it is "paused" - which should be possible or?).

Second "fault/bug" was that GRITTY (DI2) could not decode the time of a qtc (I feel, this only happens if the QTC sender uses N1MM+ - there seems to be a small challenge about CR/LF or so)


--
---
N1mm+Toolbox -> see at https://df1lx.darc.de
---






--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


Re: QTC's issue

Rick Ellison
 

All of the information in the qtc window can be entered manually by typing in the information. This is how CW ops enter the info when doing WAE CW. And the entry of the windows has been optimized for entering it by hand. Type the info and press the space bar to move between fields. When the space press lands on the cfm button hit enter or space again to send it.

 

73 Rick N2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of py2ny
Sent: Monday, November 16, 2020 2:37 PM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

 

Hi there

 

All I want is the chance to fill QTC header by

hand and have no problem to copy the following

lines with 10 (almost always) QTC's.

I can't remember exactly why I had some RX QTC

operations this year with that problem. I could have

the first line (QTC 1) or header with problem, filling

that by hand, and trying to fill QTC 2 to QTC 10 with

mouse clicking being impossible.

 

Maybe 5 times, that's all, but was boring in those 5

times stop my running and copy 10 QTC's typing

one by one. 

Sorry about my English... I am in rush because the

'home office' here  😎 

.

..

...

--------------------------------

PY2NY / SP9NY / V26NY  - Vitor Luis Aidar dos Santos

 

 

 

Em seg., 16 de nov. de 2020 às 16:30, Rick Ellison <rellison@...> escreveu:

Phil and All..

The means of clicking has not changed in the program in more than 10 years. So nothing has changed from one year to another. When you click in the window and the program is in RQTC mode it selects the entire line that the mouse is over when the mouse up event happens it then passes that line that it selected over to the QTC Window to be processed. SO I'm not understanding a difference in mouse clicks unless Microsoft has changed something in the back end.

The new thing is why the pause if not turning off When the mouse is down it pauses the window from receiving any data so the line does not move. On the Mouse up event the pause is turned off. (At least that’s the way it work when working correctly.

What window type are you using Scrolling or Non-Scrolling???

I have just uploaded changes that stops the clearing of the rx window when sending qtc. It was a test point I had set to make sure a point in the send routine was being hit. I failed to remove it..

I also just uploaded changes for the Fldigi users that on my system corrects the problem with the QTC's being sent on one line. Fldigi does not send a CR in its text output. So I had to add some code to change over from the expected CR's to use just LineFeeds when Fldigi is loaded...

73 Rick N2AMG

-----Original Message-----
From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of Phil Cooper via groups.io
Sent: Monday, November 16, 2020 10:48 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

Rick and the gang,

I use MMTTY in D1 and a secondary decode screen of 2Tone.

I noticed that on a few occasions, the D1 window would freeze (yellow sidebar) as soon as I had received the header, but it wasn't consistent.
When I had received QTC's, I did notice that I had to click on the very first letter of QTC 26/10, rather than on the number.

On a couple of occasions when receiving QTC, I wanted to freeze the window, and in the D1 MMTTY window, this worked, but I was unable to freeze the secondary window. Clicking on the sidebar turned it yellow, but as soon as new text arrived, it unfroze automatically.

Witjh the QTC QSO data, I am sure I was previously able to click anywhere on the line to get it to populate the QTC window, but using this latest version, I had to click at the very start of the line, or it would not populate.

When you look at the code, is there a way to stop it clearing the RX window when sending QTC's? It was OK on receive, but when I sent some, it was a pain to see the RX window go blank. For me, this was because there was someone else calling me just before, and I wanted to see the call again, to make sure I had entered it right.

73 de Phil GU0SUP

-----Original Message-----
From: "Rick Ellison" <rellison@...>
Sent: Monday, 16 November, 2020 15:28
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

Those of you that had pausing issues what window type are you using Scrolling or Non-Scrolling??



I’m trying to find why the pause if not returning to false . Every time a mouse down event happens in the rx windows the pause is turned on and when the mouse up event happens the pause is turned off. I need to find why it’s not turning off like it should…

73 Rick N2AMG



From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of py2ny
Sent: Monday, November 16, 2020 10:01 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue



Thanks Peter & GU0SUP

About DI window paused, this is new for me and hope to

be corrected in the future, because isn't rare that we need

to work with RX QTC after finishing the operation.

But yeap, I had the problem only 4 or 5 times during those

700 received QTC's, when the TX station was under QSB

or other problems.

Thank you so much everybody, and congratulations to all

the guys involved with N1MM+ development. I will be

N1MM+ user forever.



Bye bye   [PY2NY]

.

..

...

--------------------------------

PY2NY / SP9NY / V26NY  - Vitor Luis Aidar dos Santos

http://military-jeep-brasil.blogspot.com.br/







Em dom., 15 de nov. de 2020 às 19:59, Peter Krüger <pkfalkensee@... <mailto:pkfalkensee@...> > escreveu:

The DI-window is "paused" - you see a yellow part in the left - then you are not able to click on the lines and fill the QTCs lines.
The logging window must be scrolling - and not paused - I had this one time but after activating the scrolling everything worked as expected.

My challenge was, that GRITTY could not decode the time when a N1MM user send QTCs - only MMTTY could do it - that was challenging :)
--
---
N1mm+Toolbox -> see at  https://df1lx.darc.de
---










--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus













--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus






Virus-free. www.avast.com


Re: Rx QTC issue in WAE RTTY

Rick Ellison
 

“but I didn't know FLdigi is a program developed in Linux.”

Yes Fldigi is written and developed on a linux based OS it is then cross compiled for Windows and MacOS.

 

73 Rick N2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of Julian
Sent: Monday, November 16, 2020 11:48 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] Rx QTC issue in WAE RTTY

 

Hi Jim, as the program developer stated earlier in that thread, it looks like the problem is with FLdigi processing CRs. It also needs an LF. It looks like a the problem is both ways, when TXing and RXing. I also suspected a Linux Windows mishap, but I didn't know FLdigi is a program developed in Linux. I am not a programmer, but I did come across this CR LF conundrum occasionally in Notepad++ for ex when editing simple scripts etc, basic stuff. 
73 de J, MØIPU YOЗFCA


Virus-free. www.avast.com


Re: Rx QTC issue in WAE RTTY

Rick Ellison
 

More than likely they had ENTERLF set for their QTC spacing. But there was an issue with Fldigi that was not dropping the line as it was looking for a CR and Fldigi was not outputting the CR.. Its fixed for tomorrows build..

 

73 Rick N2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of Jim Bruce
Sent: Monday, November 16, 2020 11:14 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] Rx QTC issue in WAE RTTY

 

Thanks J, that helps ease my mind a bit. I did see others sending QTCs that had CR/LF after each QTC. Not sure what software they were running to send without them.

Jim/W3FA

 

On 11/16/2020 10:47 AM, Julian wrote:

That is wrong. There is a fix on the way. See "WAE QTC - no CR and/or LF at the end of QTC lines on RX" thread. 

Regards, J, MØIPU


Virus-free. www.avast.com


Re: QTC's issue

Rick Ellison
 

Re #1 a CR/LF is already sent at the beginning of a resend.

Re #2 It easy enough to change but I’m not sure all operators would want it sent twice. Have to think about this one..

 

73 Rick n2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of John GM0OPS via groups.io
Sent: Monday, November 16, 2020 11:14 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

 

On Mon, Nov 16, 2020 at 10:55 AM, Ken - K4XL wrote:

A second problem but on SQTCs.  I'm not exaggerating when I say that over 90% of the time I had requests to resend a Q.  Number 10 was always on the list and very frequently it was the only requested repeat.  After reading the comments in this series of emails,  I opened the QTC Window and looked at the RTTY Setup tab.

I would also ask that the system, when an operator resends a specific QTC Number i.e QTC 7   it resends it but automatically sends it twice. This would have saved me some time and it was great when stations did it as sometimes the first one for some reason came up on MMTTY, not on a clear line, so even 

1. A CR/LF is sent at the start of that particular QTC line
2. QTC specific lines are sent twice

But it is all great software and very smart

Regards
John
GM0OPS/MM9I


Virus-free. www.avast.com


Re: QTC's issue

Peter Krüger
 

I had the same problem sometimes - DI (MMTTY) paused and it was hard to activate it again (and I could not take any QTC into the QTC window if it is "paused" - which should be possible or?).

Second "fault/bug" was that GRITTY (DI2) could not decode the time of a qtc (I feel, this only happens if the QTC sender uses N1MM+ - there seems to be a small challenge about CR/LF or so)


--
---
N1mm+Toolbox -> see at  https://df1lx.darc.de
---


Re: QTC's issue

Rick Ellison
 

When you Yellow pause bar did not turn off all you needed to do was click on it to turn it off then continue on with the rest of the QTC’s

So far I have not found any changes for why the pause bar did not turn off. It is turned on and off with every mouse click in the rx window. Most of the time the click is done in milliseconds and your eye does not notice the color change of the pause bar.

 

When you send ENTERLF you are adding an extra linefeed to each line. There is nothing wrong with that and is what I send most of the time it adds an extra space in between QTC but if you are using a short window then the qtc will scroll off the screen much faster..

 

73 Rick n2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of Ken - K4XL
Sent: Monday, November 16, 2020 10:55 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

 

Rick,

My pause problem occured like this.

1)  I agree to RX QTC

2) DX starts sending.  Header and first Q has been sent and scrolling is on.

3) I click on the header...maybe twice in order to get it to populate the RQTC window.

4) With my mouse pointer hovering over the header line, I wait for the 1st Q to scroll up.  When it does, I click on it but do not move the mouse otherwise. 

5) I click on each subsequent Q, but suddenly, the yellow pause bar lights up.  I figure I've done something wrong, but can't figure it out!  Hope you can!!

 

A second problem but on SQTCs.  I'm not exaggerating when I say that over 90% of the time I had requests to resend a Q.  Number 10 was always on the list and very frequently it was the only requested repeat.  After reading the comments in this series of emails,  I opened the QTC Window and looked at the RTTY Setup tab.  Under SQTC Messages, the Send All Ending:  Originally it was {ENTER}QSL?? BK DE {MyCall} K  I've changed it to start {ENTERLF} thinking that the LF time might give the receiving station a clear read of #10.  Will this work, or is there something else that needs doing?

 

Thanks,

Ken - K4XL

 

On Mon, Nov 16, 2020 at 10:28 AM Rick Ellison <rellison@...> wrote:

Those of you that had pausing issues what window type are you using Scrolling or Non-Scrolling??

 

I’m trying to find why the pause if not returning to false . Every time a mouse down event happens in the rx windows the pause is turned on and when the mouse up event happens the pause is turned off. I need to find why it’s not turning off like it should…

73 Rick N2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of py2ny
Sent: Monday, November 16, 2020 10:01 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

 

Thanks Peter & GU0SUP

About DI window paused, this is new for me and hope to

be corrected in the future, because isn't rare that we need

to work with RX QTC after finishing the operation.

But yeap, I had the problem only 4 or 5 times during those

700 received QTC's, when the TX station was under QSB 

or other problems.

Thank you so much everybody, and congratulations to all

the guys involved with N1MM+ development. I will be

N1MM+ user forever.

 

Bye bye   [PY2NY]

.

..

...

--------------------------------

PY2NY / SP9NY / V26NY  - Vitor Luis Aidar dos Santos

 

 

 

Em dom., 15 de nov. de 2020 às 19:59, Peter Krüger <pkfalkensee@...> escreveu:

The DI-window is "paused" - you see a yellow part in the left - then you are not able to click on the lines and fill the QTCs lines.
The logging window must be scrolling - and not paused - I had this one time but after activating the scrolling everything worked as expected.

My challenge was, that GRITTY could not decode the time when a N1MM user send QTCs - only MMTTY could do it - that was challenging :)
--
---
N1mm+Toolbox -> see at  https://df1lx.darc.de
---



 

Virus-free. www.avast.com



--

Ken - K4XL
BoatAnchor Manual Archive
BAMA - http://bama.edebris.com


Re: QTC's issue

py2ny
 

Hi there

All I want is the chance to fill QTC header by
hand and have no problem to copy the following
lines with 10 (almost always) QTC's.

I can't remember exactly why I had some RX QTC
operations this year with that problem. I could have
the first line (QTC 1) or header with problem, filling
that by hand, and trying to fill QTC 2 to QTC 10 with
mouse clicking being impossible.

Maybe 5 times, that's all, but was boring in those 5
times stop my running and copy 10 QTC's typing
one by one. 

Sorry about my English... I am in rush because the
'home office' here  😎 
.
..
...
--------------------------------
PY2NY / SP9NY / V26NY  - Vitor Luis Aidar dos Santos



Em seg., 16 de nov. de 2020 às 16:30, Rick Ellison <rellison@...> escreveu:

Phil and All..

The means of clicking has not changed in the program in more than 10 years. So nothing has changed from one year to another. When you click in the window and the program is in RQTC mode it selects the entire line that the mouse is over when the mouse up event happens it then passes that line that it selected over to the QTC Window to be processed. SO I'm not understanding a difference in mouse clicks unless Microsoft has changed something in the back end.

The new thing is why the pause if not turning off When the mouse is down it pauses the window from receiving any data so the line does not move. On the Mouse up event the pause is turned off. (At least that’s the way it work when working correctly.

What window type are you using Scrolling or Non-Scrolling???

I have just uploaded changes that stops the clearing of the rx window when sending qtc. It was a test point I had set to make sure a point in the send routine was being hit. I failed to remove it..

I also just uploaded changes for the Fldigi users that on my system corrects the problem with the QTC's being sent on one line. Fldigi does not send a CR in its text output. So I had to add some code to change over from the expected CR's to use just LineFeeds when Fldigi is loaded...

73 Rick N2AMG

-----Original Message-----
From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of Phil Cooper via groups.io
Sent: Monday, November 16, 2020 10:48 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

Rick and the gang,

I use MMTTY in D1 and a secondary decode screen of 2Tone.

I noticed that on a few occasions, the D1 window would freeze (yellow sidebar) as soon as I had received the header, but it wasn't consistent.
When I had received QTC's, I did notice that I had to click on the very first letter of QTC 26/10, rather than on the number.

On a couple of occasions when receiving QTC, I wanted to freeze the window, and in the D1 MMTTY window, this worked, but I was unable to freeze the secondary window. Clicking on the sidebar turned it yellow, but as soon as new text arrived, it unfroze automatically.

Witjh the QTC QSO data, I am sure I was previously able to click anywhere on the line to get it to populate the QTC window, but using this latest version, I had to click at the very start of the line, or it would not populate.

When you look at the code, is there a way to stop it clearing the RX window when sending QTC's? It was OK on receive, but when I sent some, it was a pain to see the RX window go blank. For me, this was because there was someone else calling me just before, and I wanted to see the call again, to make sure I had entered it right.

73 de Phil GU0SUP

-----Original Message-----
From: "Rick Ellison" <rellison@...>
Sent: Monday, 16 November, 2020 15:28
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

Those of you that had pausing issues what window type are you using Scrolling or Non-Scrolling??



I’m trying to find why the pause if not returning to false . Every time a mouse down event happens in the rx windows the pause is turned on and when the mouse up event happens the pause is turned off. I need to find why it’s not turning off like it should…

73 Rick N2AMG



From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of py2ny
Sent: Monday, November 16, 2020 10:01 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue



Thanks Peter & GU0SUP

About DI window paused, this is new for me and hope to

be corrected in the future, because isn't rare that we need

to work with RX QTC after finishing the operation.

But yeap, I had the problem only 4 or 5 times during those

700 received QTC's, when the TX station was under QSB

or other problems.

Thank you so much everybody, and congratulations to all

the guys involved with N1MM+ development. I will be

N1MM+ user forever.



Bye bye   [PY2NY]

.

..

...

--------------------------------

PY2NY / SP9NY / V26NY  - Vitor Luis Aidar dos Santos

http://military-jeep-brasil.blogspot.com.br/







Em dom., 15 de nov. de 2020 às 19:59, Peter Krüger <pkfalkensee@... <mailto:pkfalkensee@...> > escreveu:

The DI-window is "paused" - you see a yellow part in the left - then you are not able to click on the lines and fill the QTCs lines.
The logging window must be scrolling - and not paused - I had this one time but after activating the scrolling everything worked as expected.

My challenge was, that GRITTY could not decode the time when a N1MM user send QTCs - only MMTTY could do it - that was challenging :)
--
---
N1mm+Toolbox -> see at  https://df1lx.darc.de
---










--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus













--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus







Re: QTC's issue

Rick Ellison
 

What I mean by window type is are you using the Scrolling or Non-Scrolling selection for the RX window type..

When selecting QTC you should not need to click on multiple sections of the QTC just one click anyplace on the line of QTC should send it over to the QTC Window.

 

73 Rick N2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of John GM0OPS via groups.io
Sent: Monday, November 16, 2020 10:51 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

 

On Mon, Nov 16, 2020 at 10:28 AM, Rick Ellison wrote:

m trying to find why the pause if not returning to

Hi Rick
Not sure what you mean window type but I did find that if I tried to click on the callsign or even close to the left hand side bar then the screen would pause, even worse when clicking on the QTC number, so I tried a few things and this is it

1. Click on the far right of the QTC number
2. After each call click on the far right, usually the stations serial number

Doing both of the above kept my mouse from being anywhere near the left hand panel and that made it easier. Now I know why people just like to send QTC, oh so much easier.

Regards
John
GM0OPS/MM9I


Virus-free. www.avast.com


Re: QTC's issue

Rick Ellison
 

Phil and All..

The means of clicking has not changed in the program in more than 10 years. So nothing has changed from one year to another. When you click in the window and the program is in RQTC mode it selects the entire line that the mouse is over when the mouse up event happens it then passes that line that it selected over to the QTC Window to be processed. SO I'm not understanding a difference in mouse clicks unless Microsoft has changed something in the back end.

The new thing is why the pause if not turning off When the mouse is down it pauses the window from receiving any data so the line does not move. On the Mouse up event the pause is turned off. (At least that’s the way it work when working correctly.

What window type are you using Scrolling or Non-Scrolling???

I have just uploaded changes that stops the clearing of the rx window when sending qtc. It was a test point I had set to make sure a point in the send routine was being hit. I failed to remove it..

I also just uploaded changes for the Fldigi users that on my system corrects the problem with the QTC's being sent on one line. Fldigi does not send a CR in its text output. So I had to add some code to change over from the expected CR's to use just LineFeeds when Fldigi is loaded...

73 Rick N2AMG

-----Original Message-----
From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of Phil Cooper via groups.io
Sent: Monday, November 16, 2020 10:48 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

Rick and the gang,

I use MMTTY in D1 and a secondary decode screen of 2Tone.

I noticed that on a few occasions, the D1 window would freeze (yellow sidebar) as soon as I had received the header, but it wasn't consistent.
When I had received QTC's, I did notice that I had to click on the very first letter of QTC 26/10, rather than on the number.

On a couple of occasions when receiving QTC, I wanted to freeze the window, and in the D1 MMTTY window, this worked, but I was unable to freeze the secondary window. Clicking on the sidebar turned it yellow, but as soon as new text arrived, it unfroze automatically.

Witjh the QTC QSO data, I am sure I was previously able to click anywhere on the line to get it to populate the QTC window, but using this latest version, I had to click at the very start of the line, or it would not populate.

When you look at the code, is there a way to stop it clearing the RX window when sending QTC's? It was OK on receive, but when I sent some, it was a pain to see the RX window go blank. For me, this was because there was someone else calling me just before, and I wanted to see the call again, to make sure I had entered it right.

73 de Phil GU0SUP

-----Original Message-----
From: "Rick Ellison" <rellison@twcny.rr.com>
Sent: Monday, 16 November, 2020 15:28
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue

Those of you that had pausing issues what window type are you using Scrolling or Non-Scrolling??



I’m trying to find why the pause if not returning to false . Every time a mouse down event happens in the rx windows the pause is turned on and when the mouse up event happens the pause is turned off. I need to find why it’s not turning off like it should…

73 Rick N2AMG



From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of py2ny
Sent: Monday, November 16, 2020 10:01 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] QTC's issue



Thanks Peter & GU0SUP

About DI window paused, this is new for me and hope to

be corrected in the future, because isn't rare that we need

to work with RX QTC after finishing the operation.

But yeap, I had the problem only 4 or 5 times during those

700 received QTC's, when the TX station was under QSB

or other problems.

Thank you so much everybody, and congratulations to all

the guys involved with N1MM+ development. I will be

N1MM+ user forever.



Bye bye [PY2NY]

.

..

...

--------------------------------

PY2NY / SP9NY / V26NY - Vitor Luis Aidar dos Santos

http://military-jeep-brasil.blogspot.com.br/







Em dom., 15 de nov. de 2020 às 19:59, Peter Krüger <pkfalkensee@gmail.com <mailto:pkfalkensee@gmail.com> > escreveu:

The DI-window is "paused" - you see a yellow part in the left - then you are not able to click on the lines and fill the QTCs lines.
The logging window must be scrolling - and not paused - I had this one time but after activating the scrolling everything worked as expected.

My challenge was, that GRITTY could not decode the time when a N1MM user send QTCs - only MMTTY could do it - that was challenging :)
--
---
N1mm+Toolbox -> see at https://df1lx.darc.de
---










--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus













--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


Re: ODP: [N1MM+] WAE RTTY QTC Receiving Problem In DI Windows

Jim W7RY
 

In my opinion... the pause routine in the di window needs work.  Been kinda flakey for around a year.



Thanks and 73 W7RY
Sent from my wireless communicator


On Mon, Nov 16, 2020, 8:16 AM ve3ki <ve3iay@...> wrote:
There is a green or yellow bar at the left of the DI window. When it is green, the DI window is displaying received text as it comes in and scrolling upwards or wrapping around depending on the scrolling setting. When it is yellow, the DI window is frozen - the purpose is to give you a chance to prevent text from scrolling off the window before you can click on it. You can change it from green to yellow, or vice versa, by clicking on the bar. If it is yellow, when you click on it the bar will change to green, the received text that was being buffered while it was yellow will be displayed, and the text will resume scrolling normally from there.

The exact location of the mouse pointer when you click on the mouse is important. If you click near the left edge of the DI window, the mouse position may be detected as being in the green/yellow bar instead of in the text, and in that case it is interpreted as a freeze/unfreeze command, not as clicking on text. Therefore you should avoid clicking close to the left edge of the window. Also, you must click within the text; clicking nearby but not actually in the text might not work. If your eyesight is not quite as good as it used to be, you may have a bit of trouble knowing exactly when the mouse pointer is inside the text. Enlarging the font might help. Incidentally, this is why it is a good idea to send leading zeros in serial numbers in RTTY. It is a lot easier to click somewhere in 001 than it is in just 1 with no leading zeros.

Whether the other station's call sign appears in the QTC header or not is not important on its own. The header number for each QTC is stored in the log without the call sign, since the call sign is already in another field in the log. The Cabrillo file is created based on what is in the log, not on what was displayed in the DI window or QTC window.

73,
Rich VE3KI


On Mon, Nov 16, 2020 at 08:22 AM, Andy VA3PL wrote:
Hi There
I experiance exactly the same problem. RX window freezes and my remedy for this was to click on yellow wertical bar number of times.
Also clicking on QTC number will not transfer heather to QTX RX window. On occasion multiple clisk will transwer QTC heather to QTC RX window.
Andy SP9KR
 
 

Od: N1MMLoggerPlus@groups.io <N1MMLoggerPlus@groups.io> w imieniu użytkownika David AD4TJ via groups.io <ad4tj=yahoo.com@groups.io>
Wysłane: poniedziałek, 16 listopada 2020 14:12
Do: N1MM+ <n1mmloggerplus@groups.io>
Temat: [N1MM+] WAE RTTY QTC Receiving Problem In DI Windows
 
  Using N1MM, MMTTY, and 2Tone. When receiving QTCs, sometimes the DI windows would freeze immediately after receiving the header, and not unfreeze until the QSO was over, so it was impossible to click on each QTC as it was received. I would have to scramble and try to go back to the beginning of their transmission and manually populate the QTC form to get credit for them( I assume I did get credit!?! ).
 
  And at other times, clicking on the header WOULD NOT transfer to the QTC box. Manually entering the info was necessary. And on that note, sometimes( all the time? ) the header would be " QTC 22/10 " or whatever the totals were; sometimes the other stations call would be included, and sometimes not. Is this by design? The call is included ONLY when I am sending QTCs, correct?
 
  This was only my 2nd WAE RTTY. Pretty good conditions on 20, only had 14 Qs on 15, nada heard on 10.
 
  TS-2000X, KPA-500, 50-350 watts, TA-33 at 20 feet fixed at 30 degrees, 35' tall Inverted L.
 
  380 Qs, 455 QTCs, 270 Ms, 225,450 claimed score. 16 hours 37 minutes
 
David AD4TJ


Re: Rx QTC issue in WAE RTTY

ve3ki
 

The issue is partly on the transmitting end and partly on the receiving end.

The receiving problem is with fldigi - when it receives a CR character, it is apparently ignoring it entirely. If it replaced the CR with a single space, the received QTCs would not have been jumbled together. but that's apparently not how it behaves.

On the transmitting end, if every line had been started and ended with an extra space character, the consecutive QTCs would have been separated and could have been clicked on even though they were not on separate lines.

This is also true of the normal messages sent in RTTY - if you don't want the beginning or end of an RTTY message to be contaminated with noise characters, add an extra space to separate the message from the noise. For example, if your TU message when running is something like TU QRZ {MYCALL}, make sure there is a space after the (MYCALL} and before the terminating {RX}; otherwise, there is a good chance that noise characters will be tacked onto your call sign making it difficult or impossible for receiving stations to click on it. That in turn will slow you down while you are waiting for the other station to type in the call sign instead of being able to simply click on it. This is especially important for people with short call sign suffixes, as the noise tacked on to a short call sign can make it look like a longer call sign, making it impossible to know for sure where the call sign ends and the noise begins.

73,
Rich VE3KI


On Mon, Nov 16, 2020 at 11:14 AM, Jim Bruce wrote:

Thanks J, that helps ease my mind a bit. I did see others sending QTCs that had CR/LF after each QTC. Not sure what software they were running to send without them.

Jim/W3FA

 

On 11/16/2020 10:47 AM, Julian wrote:
That is wrong. There is a fix on the way. See "WAE QTC - no CR and/or LF at the end of QTC lines on RX" thread. 
Regards, J, MØIPU


Re: Cluster Filtering

danzee
 

I always set filters in the cc cluster client, and they "stick.". I never tried changing them through N1MM. Maybe that's the difference.



Sent from my Verizon, Samsung Galaxy smartphone


-------- Original message --------
From: KE8G <ke8g.jim@...>
Date: 11/16/20 12:09 PM (GMT-05:00)
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] Cluster Filtering

Hi Rich,
Thanks for the follow-up... I will shoot off an email and see what he has to say.

73 de Jim - KE8G

PS:  hope to hear you in the CWTs!

On Mon, Nov 16, 2020 at 10:28 AM ve3ki <ve3iay@...> wrote:
Those are commands to the cluster node, not to N1MM+. You'd have to ask the cluster sysop why they are not remembered between sessions.

You can program some of the Telnet window buttons with commands like these and invoke them at the beginning of each session, or any time the connection to the cluster node is lost and you have to reconnect. I don't believe you can make this happen automatically every time you log in to the cluster.

73,
Rich VE3KI


On Mon, Nov 16, 2020 at 10:17 AM, KE8G wrote:
Hi All,
I must be doing something wrong, but can't find any information on the subject.
 
I use the VE7CC cluster with N1MM+ and have some filtering in place.  Recently, it appears there have been some commands added to prevent FT4, FT8, and RTTY spots from appearing; set/noFT4, set/noFT8 & set/noRTTY.  
 
I invoke them when starting N1MM+ and they work well throughout the day.  When I shut things down for the evening, I have to re-enter the commands the next morning.
 
Is there a way to keep them permanently in place?
 
Thanks in advance.
73 de Jim - KE8G


Re: Cluster Filtering

KE8G
 

Hi Rich,
Thanks for the follow-up... I will shoot off an email and see what he has to say.

73 de Jim - KE8G

PS:  hope to hear you in the CWTs!

On Mon, Nov 16, 2020 at 10:28 AM ve3ki <ve3iay@...> wrote:
Those are commands to the cluster node, not to N1MM+. You'd have to ask the cluster sysop why they are not remembered between sessions.

You can program some of the Telnet window buttons with commands like these and invoke them at the beginning of each session, or any time the connection to the cluster node is lost and you have to reconnect. I don't believe you can make this happen automatically every time you log in to the cluster.

73,
Rich VE3KI


On Mon, Nov 16, 2020 at 10:17 AM, KE8G wrote:
Hi All,
I must be doing something wrong, but can't find any information on the subject.
 
I use the VE7CC cluster with N1MM+ and have some filtering in place.  Recently, it appears there have been some commands added to prevent FT4, FT8, and RTTY spots from appearing; set/noFT4, set/noFT8 & set/noRTTY.  
 
I invoke them when starting N1MM+ and they work well throughout the day.  When I shut things down for the evening, I have to re-enter the commands the next morning.
 
Is there a way to keep them permanently in place?
 
Thanks in advance.
73 de Jim - KE8G


Re: Rx QTC issue in WAE RTTY

Julian
 

Hi Jim, as the program developer stated earlier in that thread, it looks like the problem is with FLdigi processing CRs. It also needs an LF. It looks like a the problem is both ways, when TXing and RXing. I also suspected a Linux Windows mishap, but I didn't know FLdigi is a program developed in Linux. I am not a programmer, but I did come across this CR LF conundrum occasionally in Notepad++ for ex when editing simple scripts etc, basic stuff. 
73 de J, MØIPU YOЗFCA


Re: WAE Color Codes

Andy (KU7T)
 

Did anyone try the experimental version? If so, I am interested to know how it went wrt. the multiplier coloring issue. 

Thanks and 73,
Andy
KU7T

3481 - 3500 of 59174