Topics

Problem with DI in WAE

Dimitri F4DSK
 

Hi,

Spent few hours in the WAE RTTY Contest and had 500+ QTC (around half sent and half received). It was working just find !
N1MM 1.0.7907, SO2R, DI with 3 RX windows for each radios (2xMMTTY + 2Tone), ESM and "Right click = Return NOT menu" active.
Windows 8.1 with a simple laptop (6 years old so not the faster CPU...) + additional screen.

If you use RBN, don't allow "save spots", it will slow down your computer due to high volume of spots.

73 de Dimitri F4DSK /TM3Z 

n7wy
 

My experience was similar to what Tim/N3QE experienced a few times, not prevalent.  I am not sure how clicking in the MMTTY decoder window to populate the QTC dialog box is coordinated, but it seems that under some rare condition the process causes the decoder to freeze up.  Clicking in anger trying to get it to release did not seem to fix anything.  In one case, I was about to CTRL-K to tell the sender that the QTCs had failed when the decoder suddenly painted what it had copied and I furiously clicked to fill the dialog and then luckily was able to confirm all were received OK.  Is there a thread locking process that may be getting confused within MMTTY?  I have to think more deeply about how I would coordinate the MVCs between the two windows.

Rick Ellison
 

The point of clicking on the qtc is a simple process. Mouse Down event pauses the RX window input. Mouse Up event selects the line under the mouse and sends the selected line over to the QTC Window where the qtc line is broken into individual items and placed in the qtc boxes. When that is done the RX window becomes un-paused. You can watch the pause strip on the left of the window turn yellow and then goes back to green. On some systems that un-pause seems to not be happening. Each time I copied QTC directly from another station or while others were sending qtc I opened the QTC window and clicked on each qtc to populate the window and it worked each time.

I just need to figure out why the un-pause did not work for them.

Also at any time you can click the yellow stripe on the left side of the window and that will un-pause the rx window.

 

The WAE contest uses the most resources than any other contest that N1MM supports I have noticed some lag when the database has a higher number of contacts but the database has been indexed to not slow down the background work.

 

73 Rick N2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of n7wy via Groups.Io
Sent: Monday, November 11, 2019 7:06 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] Problem with DI in WAE

 

My experience was similar to what Tim/N3QE experienced a few times, not prevalent.  I am not sure how clicking in the MMTTY decoder window to populate the QTC dialog box is coordinated, but it seems that under some rare condition the process causes the decoder to freeze up.  Clicking in anger trying to get it to release did not seem to fix anything.  In one case, I was about to CTRL-K to tell the sender that the QTCs had failed when the decoder suddenly painted what it had copied and I furiously clicked to fill the dialog and then luckily was able to confirm all were received OK.  Is there a thread locking process that may be getting confused within MMTTY?  I have to think more deeply about how I would coordinate the MVCs between the two windows.

Rick I2BRT
 

>>Mouse Down event pauses the RX window input. Mouse Up event selects the line under the mouse and sends the selected line over to the QTC Window where the qtc line is broken into individual items and placed in the qtc boxes. When that is done the RX window becomes un-paused.

This most of the time works as described.
Odd but seems that sometimes  Mouse Up events doesn't trigger the un-pause.
When eventually it's un-paused I had to run as fast as I can (mean : no way hi) to try to catch all the received QTCs during the long pause.

For future release I wish to ask the developer team to consider another improvement (if possible somehow).
In the case a received QTC is scrambled it would be better and more faster to have a sort of shortcut to instruct the program to skip it.
Something like contol+click (shift+click, or a press on the keyboard or some other way) because moving the mouse from the received text box to the QTC text boxes (and back) will lower the focus on the incoming QTCs and is not always so easy .

However : was a lot of adrenalin hi !
TU and 73 de RICK I2BRT.

Ron
 

If we hit Clear RX as soon as they sent "Are you QRV" we did not seem to have the problem... If we did not it often was a mess. Ron, WV4P


On Mon, Nov 11, 2019, 8:15 AM Rick Ellison <rellison@...> wrote:

The point of clicking on the qtc is a simple process. Mouse Down event pauses the RX window input. Mouse Up event selects the line under the mouse and sends the selected line over to the QTC Window where the qtc line is broken into individual items and placed in the qtc boxes. When that is done the RX window becomes un-paused. You can watch the pause strip on the left of the window turn yellow and then goes back to green. On some systems that un-pause seems to not be happening. Each time I copied QTC directly from another station or while others were sending qtc I opened the QTC window and clicked on each qtc to populate the window and it worked each time.

I just need to figure out why the un-pause did not work for them.

Also at any time you can click the yellow stripe on the left side of the window and that will un-pause the rx window.

 

The WAE contest uses the most resources than any other contest that N1MM supports I have noticed some lag when the database has a higher number of contacts but the database has been indexed to not slow down the background work.

 

73 Rick N2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of n7wy via Groups.Io
Sent: Monday, November 11, 2019 7:06 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] Problem with DI in WAE

 

My experience was similar to what Tim/N3QE experienced a few times, not prevalent.  I am not sure how clicking in the MMTTY decoder window to populate the QTC dialog box is coordinated, but it seems that under some rare condition the process causes the decoder to freeze up.  Clicking in anger trying to get it to release did not seem to fix anything.  In one case, I was about to CTRL-K to tell the sender that the QTCs had failed when the decoder suddenly painted what it had copied and I furiously clicked to fill the dialog and then luckily was able to confirm all were received OK.  Is there a thread locking process that may be getting confused within MMTTY?  I have to think more deeply about how I would coordinate the MVCs between the two windows.

Tim Shoppa
 

Clear RX at the top of the QTC list is a really good idea, Ron! Even when manually typing in all the QTC it would help me keep the multiple panes somewhat synchronized.

For the past several years I have logged more QTC's in WAE RTTY than any other competitor. I will see if I can write up a set of recommendations on how to improve the N1MM side. Below are some of my tips:

I rarely used the "stock messages" for request QTC and thanks QTC and almost always control-K keyed them in. By hand keying I try to indicate that I own the frequency by sending my call at the end, and not sending my call if I do not own the frequency. I know the stock messages can be edited from the SETUP menu inside the QTC window but I don't like the possibilities there because no matter what I put there, they will give almost no clue to a listener whether the guy sending QTC is running or the other way around. I'm thinking some good convention (like used in NA Sprints) might offer a clue to the most proficient listeners as to which side owns the frequency and if we set this convention up as default that folks will get the hang of it.

My most blatant recommendation: currently the "Agn" buttons in the receive pane clear all the info for that QTC line out. The info I am carefully and painstakingly trying to get a fill on from the other side over multiple repeats. It would be great to turn off the auto-clearing.

Also as I typed/spaced/tabbed info in every so often I would miskey something and then my rig would go into transmit right in the middle of the 10 QTC's I was trying to copy. (I think I may have triggered an "Agn" message but not really sure.) I don't understand the intended behavior but going into transmit during a batch of 10 QTC's (as usually done in RTTY) is very very bad. I suspect this behavior makes more sense in CW or SSB where most often we wait for an audible acknowledge (dit or R or "roger") after each QTC before doing the next.

Tim N3QE

On Mon, Nov 11, 2019 at 10:12 AM Ron <wv4ptn@...> wrote:
If we hit Clear RX as soon as they sent "Are you QRV" we did not seem to have the problem... If we did not it often was a mess. Ron, WV4P

On Mon, Nov 11, 2019, 8:15 AM Rick Ellison <rellison@...> wrote:

The point of clicking on the qtc is a simple process. Mouse Down event pauses the RX window input. Mouse Up event selects the line under the mouse and sends the selected line over to the QTC Window where the qtc line is broken into individual items and placed in the qtc boxes. When that is done the RX window becomes un-paused. You can watch the pause strip on the left of the window turn yellow and then goes back to green. On some systems that un-pause seems to not be happening. Each time I copied QTC directly from another station or while others were sending qtc I opened the QTC window and clicked on each qtc to populate the window and it worked each time.

I just need to figure out why the un-pause did not work for them.

Also at any time you can click the yellow stripe on the left side of the window and that will un-pause the rx window.

 

The WAE contest uses the most resources than any other contest that N1MM supports I have noticed some lag when the database has a higher number of contacts but the database has been indexed to not slow down the background work.

 

73 Rick N2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of n7wy via Groups.Io
Sent: Monday, November 11, 2019 7:06 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] Problem with DI in WAE

 

My experience was similar to what Tim/N3QE experienced a few times, not prevalent.  I am not sure how clicking in the MMTTY decoder window to populate the QTC dialog box is coordinated, but it seems that under some rare condition the process causes the decoder to freeze up.  Clicking in anger trying to get it to release did not seem to fix anything.  In one case, I was about to CTRL-K to tell the sender that the QTCs had failed when the decoder suddenly painted what it had copied and I furiously clicked to fill the dialog and then luckily was able to confirm all were received OK.  Is there a thread locking process that may be getting confused within MMTTY?  I have to think more deeply about how I would coordinate the MVCs between the two windows.

Eric Wagner
 

I had 2 issues while copying QTCs this weekend.

In one instance I was cleanly copying the QTCs and clicking each as they arrived in the DI window.  The first 8 entered smoothly.  When I clicked on the 9th it would not populate into the 9th row of the QTC window.   So, I tried to type it in manually and the last 2 rows would not take any entries.  My next step was to cancel the QTC window, freeze the DI window and scroll back to re-enter after reopening the QTC window.  As I was doing the re-entry, the DI buffer apparently filled and the DI window cleared.  I lost all 10 of the copied QTCs.  I need to check if I set the DI or MMTTY windows to record all received data to a file.  

The second issue I ran into was another QTC receive, where the DI window scrolled on me and I clicked on the 3rd QTC rather the 2nd.  I didn’t notice immediately and decided to just keep clicking to fill out the rest and correct the order after receiving all of them.  Then one QTC got garbled and wouldn’t populate in the QTC row.  So, I typed in the partial and moved on.  I ended up with 9 rows filled and asked for a repeat manually of the one garbled with ctrl-k and acknowledged.  Then went back to correct the QTC entries in the QTC window.  During the process of trying to shift the entries down one row, the last 3 rows populated with hyphens and I saw a status flash that said something like buffer full or something similar.  After some further attempts to correct I eventually saved the partially filled QTC window after writing down the QTCs to correct it later.  These ended up partially out of order in the log due to the editing I attempted.

I avoided receiving QTCs for a while until I was sure to have an error free copy of QTCs. Sending QTCs always worked like a charm.  

Eric - NR4O


On Nov 11, 2019, at 10:27 AM, Tim Shoppa <tshoppa@...> wrote:


Clear RX at the top of the QTC list is a really good idea, Ron! Even when manually typing in all the QTC it would help me keep the multiple panes somewhat synchronized.

For the past several years I have logged more QTC's in WAE RTTY than any other competitor. I will see if I can write up a set of recommendations on how to improve the N1MM side. Below are some of my tips:

I rarely used the "stock messages" for request QTC and thanks QTC and almost always control-K keyed them in. By hand keying I try to indicate that I own the frequency by sending my call at the end, and not sending my call if I do not own the frequency. I know the stock messages can be edited from the SETUP menu inside the QTC window but I don't like the possibilities there because no matter what I put there, they will give almost no clue to a listener whether the guy sending QTC is running or the other way around. I'm thinking some good convention (like used in NA Sprints) might offer a clue to the most proficient listeners as to which side owns the frequency and if we set this convention up as default that folks will get the hang of it.

My most blatant recommendation: currently the "Agn" buttons in the receive pane clear all the info for that QTC line out. The info I am carefully and painstakingly trying to get a fill on from the other side over multiple repeats. It would be great to turn off the auto-clearing.

Also as I typed/spaced/tabbed info in every so often I would miskey something and then my rig would go into transmit right in the middle of the 10 QTC's I was trying to copy. (I think I may have triggered an "Agn" message but not really sure.) I don't understand the intended behavior but going into transmit during a batch of 10 QTC's (as usually done in RTTY) is very very bad. I suspect this behavior makes more sense in CW or SSB where most often we wait for an audible acknowledge (dit or R or "roger") after each QTC before doing the next.

Tim N3QE

On Mon, Nov 11, 2019 at 10:12 AM Ron <wv4ptn@...> wrote:
If we hit Clear RX as soon as they sent "Are you QRV" we did not seem to have the problem... If we did not it often was a mess. Ron, WV4P

On Mon, Nov 11, 2019, 8:15 AM Rick Ellison <rellison@...> wrote:

The point of clicking on the qtc is a simple process. Mouse Down event pauses the RX window input. Mouse Up event selects the line under the mouse and sends the selected line over to the QTC Window where the qtc line is broken into individual items and placed in the qtc boxes. When that is done the RX window becomes un-paused. You can watch the pause strip on the left of the window turn yellow and then goes back to green. On some systems that un-pause seems to not be happening. Each time I copied QTC directly from another station or while others were sending qtc I opened the QTC window and clicked on each qtc to populate the window and it worked each time.

I just need to figure out why the un-pause did not work for them.

Also at any time you can click the yellow stripe on the left side of the window and that will un-pause the rx window.

 

The WAE contest uses the most resources than any other contest that N1MM supports I have noticed some lag when the database has a higher number of contacts but the database has been indexed to not slow down the background work.

 

73 Rick N2AMG

 

From: N1MMLoggerPlus@groups.io [mailto:N1MMLoggerPlus@groups.io] On Behalf Of n7wy via Groups.Io
Sent: Monday, November 11, 2019 7:06 AM
To: N1MMLoggerPlus@groups.io
Subject: Re: [N1MM+] Problem with DI in WAE

 

My experience was similar to what Tim/N3QE experienced a few times, not prevalent.  I am not sure how clicking in the MMTTY decoder window to populate the QTC dialog box is coordinated, but it seems that under some rare condition the process causes the decoder to freeze up.  Clicking in anger trying to get it to release did not seem to fix anything.  In one case, I was about to CTRL-K to tell the sender that the QTCs had failed when the decoder suddenly painted what it had copied and I furiously clicked to fill the dialog and then luckily was able to confirm all were received OK.  Is there a thread locking process that may be getting confused within MMTTY?  I have to think more deeply about how I would coordinate the MVCs between the two windows.