Date   
Re: PTT hanging

Rag LB-Three-RE Stein-Roar
 

Hi
Its kenwood ts950sdx

Running 100% slow, 50 % and normal

I never lost frequency
I tried also ts850 with 0 watt out. Same symthomps

Best Regards,
Stein-Roar Brobakken


Den 25. sep. 2017 kl. 11.55 skrev 'John Bednar' k3ct@... [N1MMLoggerplus] <N1MMLoggerplus@...>:

 

 

What radio?

 

It is unusual that the hardware PTT from the Microham is not used and you are relying on radio command PTT. Why?

 

The CPU usage for Logger+ and radio command PTT not working seems to indicate that you are getting RF into the radio control cable. Do you lose radio control at the same time?

 

John, K3CT

 

From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: Monday, September 25, 2017 3:56 AM
To: N1MMLoggerplus@...
Subject: Re: [N1MMLoggerplus] Re: PTT hanging

 

 

Hi

 

Microham:

Only ptt on fsk port

No soundcard ptt enabled

 

Mmtty:

No ptt in mmtty

 

N1mm:

No ptt port

Only active software ptt on last check on rig control/cat 

 

No telnet or skimmer connected.

 

 

 


Den 25. sep. 2017 kl. 09.39 skrev ve3iay@... [N1MMLoggerplus] <N1MMLoggerplus@...& gt;:

 

How are you doing PTT? Do you have more than one method of PTT control configured? For example, do you have PTT configured in both N1MM+ and MMTTY? Also, do you have Sound card PTT enabled in the microHam Router? IIRC, that can cause problems, and it's not necessary when you are using software that can control PTT directly.

 

CPU usage going up sounds like some other activity may be interfering. Are you using telnet? Raw skimmer spots or filtered?

 

73,

Rich VE3KI



---In N1MMLoggerplus@..., wrote :

Hi

I ran CQ WW RTTY this weekend, and PTT hangs on end of TX from time to time. At any macro...
I use mmtty for tx, but cpu usage go up for n1mm suddenly. Cpu usage for mmtty stay normal.

Then need to ESC to make it stop, then its engage suddenly again 2-3 times...
After this a long stream of macros start to finish the stream...

This happens even no RF output to Microham MKII keyer.

A bug in n1mm?
Writelog works fine with mmtty.

73s
Stein-Roar Brobakken
LB3RE K3RAG
www.lb3re.com
post@...

Re: 'Next...' function still not working the way it used to..................

Rick Ellison
 

“....I only tried the single click once, and if I recall, it replaced the first call I grabbed with the second one I clicked, and worked them in reverse order....doesn't the digital call stacking selection still work ( FIFO , lifo, mult first ?)”

 

Depending on what setting you have chosen in the call stacking menu the call that is currently in the Entry Window will be replaced. If you have selected Last in First out the call will be replaced and the call that was there will move to the stack. If you have chosen First in First out then the call will stay in the Entry Window and the new call that is clicked will be put on the stack. If Digital call stacking is turned on and you are in Run mode a single click is all that is required to place calls on the stack. As Rich mentioned I also would not recommend using LOGTHENGRAB if you are using the TU/Next sequence. You will more than likely get garbage into your stack. So only use LOGTHENPOP if you want correct working of this feature.

 

When the call frame logic was changed this stopped allowing call stack calls from being placed there. It’s not broken it was a meant change. The stacking and unstacking should be all automatic if setup and configured correctly.

 

73 Rick N2AMG

 

From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: Monday, September 25, 2017 6:11 AM
To: N1MMLoggerplus@...
Subject: Re: [N1MMLoggerplus] Re: 'Next...' function still not working the way it used to..................

 

 

I don't know when it "broke" but I'm pretty sure it worked in last years CQWW and I think it even worked in January for ARRL.....I know it didn't break, but was changed for some unknown reason....many, many diehard rtty contesters have requested it go back to the call frame, have yet to see a valid reason why it can't work the way it did in K8UT video....Rich , you mentioned you never look at the band map or entry window when running.....I agree with the band map, but the entry window? How are you certain what you grabbed? In a multi transmitter event, I don't even want the band map open on the run transmitter, but am forced to now to see my stack ( off topic, but related....the other ops freq is nice to see in the band map, don't remember seeing that last year, is there a way to move that to the Info window instead)

 

Rich , you also mentioned you just click on the call to stack them, and they are worked in the order you clicked them, and you don't need to alt click.....that didn't work for me, using a very recent version....I still needed to alt click....I only tried the single click once, and if I recall, it replaced the first call I grabbed with the second one I clicked, and worked them in reverse order....doesn't the digital call stacking selection still work ( FIFO , lifo, mult first ?)


On Sep 25, 2017, at 3:14 AM, ve3iay@... [N1MMLoggerplus] <N1MMLoggerplus@...> wrote:

 

Based on your description, where you mention both clicking on more than one call sign and the Grab window, busted calls, dupes, etc., I believe you may be mixing up two different ways of implementing the 'next' function: LOGTHENPOP and LOGTHENGRAB. They are two different things and they work in different ways. It is easiest to pick one and stick with it, not try to combine them.

 

The one I like is LOGTHENPOP. To use this with ESM, you designate a 'Next' key in the Configurer, Function Keys tab. I use F9, but any unused function key will do. The message you program into the designated 'Next' key must contain the LOGTHENPOP macro, as described in the manual. Do NOT, repeat do NOT, put a LOGTHENGRAB macro in that function key message. You will regret it if you do. The final configuration step to get this method working is to enable Digital Call Stacking in the Setup menu in the DI window.



To use this method, when two people call you with valid call signs that appear in the clear and are not grey (dupes), click on the two (or more) call signs one after the other, and then press Enter or right-click to start the first QSO. At the end of that QSO, ESM will automatically use the 'Next' function key instead of the normal 'TU' function key to end that QSO and start the next one. The Grab window is not involved (unless you go out of your way to use it with a GRAB macro or Alt+G) - in fact, I have my Grab window disabled, because I don't use it. Busted calls, wrong calls, old calls, previously worked calls etc. will only get involved if you click on them. The answer to that is simple: don't click on them.

 

Once you choose which call signs to click on, the rest of the process is automatic. Yes, at one time the call signs from the stack appeared in the frame, but frankly I never even noticed when that stopped working, because I never look at either the frame or the Bandmap window when I am running; the LOGTHENPOP process just works. The only time it goes wrong is if I click on something I shouldn't have clicked on, and then I have only myself to blame - the Esc key comes in handy in those circumstances.

 

I don't understand why this is such a hot-button item for some people; obviously I am missing something. Maybe some folks are using the LOGTHENPOP macro manually without designating a 'Next' function key, or without using ESM(??). I can visualize where not seeing the next call sign might be a problem in that scenario. Anyway, I believe that what changed when the call sign frame logic was changed was that simply clicking on a second call sign now does what Alt+clicking used to do. In effect, the call signs are now worked in the order you clicked on them instead of the reverse order, but I don't recall seeing anyone comment on that.

 

On to the second method... This is LOGTHENGRAB. This one is not as automated. You do not assign a 'Next' function key in the Configurer for this method. You do program a function key message with a LOGTHENGRAB macro in it, but do NOT, repeat do NOT, designate a function key containing the LOGTHENGRAB macro as the 'Next' function key. You will not like the results if you do.

 

To use this one, you do not click on two call signs or put call signs in the bandmap stack. The LOGTHENGRAB macro does not look there, and the call sign frame is not involved. LOGTHENGRAB gets its call signs directly from the Grab window. If the call sign highlighted in the Grab window at the end of the first QSO happens to be a good call sign that you want to work next, then and only then you can click on the function key with the LOGTHENGRAB macro in it instead of using the TU key or Enter or a right-click to end the QSO. The LOGTHENGRAB macro that you called up by clicking on that function key will log the first QSO and pull the next call sign out of the Grab window and try to work it.

 

The Grab window is not very smart - it often gets filled up with busted calls, wrong calls, and so on. That is why the LOGTHENGRAB process is not automated - you have to supply the smarts by looking at the Grab window and deciding whether you want to use a call sign from it or not. There is a DELSEL macro that pops garbage off the top of the Grab window which you can use to help with this.

 

In both methods you have to supply some discretion to weed out bad call signs, etc. In the automated method, you supply that discretion by not clicking on bad call signs before starting the first QSO. In the Grab method, you supply the discretion by not using the LOGTHENGRAB function key if the call sign highlighted in the Grab window is bad, or is not the one you want to work next.

 

73,

Rich VE3KI

 


---In N1MMLoggerplus@..., <ron@...> wrote :

The "next" function has become unusable.  I totally embarrassed myself this weekend in the CQWW DX RTTY contest after trying to decipher the incomprehensible instructions in hamdocs, then screwing up royally when the contest got going. 

 

The way it used to work is that you would click on a callsign that you wanted to be 'next' and it went into the 'call frame'.  The original instructions still say that, but the call frame now only displays the words "CQ-Frequency" and nothing else.  You can't really choose between the busted calls, wrong calls, old calls, previous worked calls, etc. that show up in the 'grab' box and/or the band map.

 

The call frame apparently stopped working about a year and a half ago, and despite reporting this earlier this year, it's still a problem.  Is the only work-around for this to use and old version of Logger+?  I really hate to do that.

 

Ron

N6IE

 

Re: Com ports in use by other ?

Joe Subich, W4TV
 

What version of Windows?

Did you explicitly do a *RESTART* or did you simply power down
the computer (sleep, hibernate, hybrid sleep) and power it back
up (wake)?

In Windows 7 and later, most ways of closing Windows results in
saving an image of RAM (including hardware drivers) to disk and
reloading that image when restarting. In Windows 8 and 10 that
is the default behavior ("hybrid sleep").

This behavior precludes proper initialization of hardware devices
and does not allow for clearing improperly closed applications
from memory.

73,

... Joe, W4TV

On 9/25/2017 3:37 AM, @F1VEV [N1MMLoggerplus] wrote:


HI Rich,


Thanks but maybe I should have said that this was done at least the restart of windows and that did not solve the issue anyway will look into it when I get home tonight 73s

Re: Com ports in use by other ?

Vytenis LY5T
 

Hello Jacques,
This small utility may help you:
https://rigexpert.com/which-program-is-using-a-serial-port/

Vytenis
LY5T

Mysterious K3 FSK mode change

Gary Johnson
 

I’m posting the to both the N1MM and Elecraft reflectors. The problem station at N6RO is a K3 running AFSK, controlled by N1MM with MMTTY. OS is Win10. This station was working ok on RTTY some months ago. This problem cropped up at the start of the CQWW contest: The rig would spontaneously change sub-modes from AFSK-A to FSK-D when you turn the VFO dial. Not just cluster-clicking, but simply turning the knob! Then you have to press the Data MD button to fix it, every time you QSY. Never occurs while running.

What I’m looking for is 1) confirmation that the K3 has no obscure feature that could do this, and 2) is there some setting I should look for in the software.

This setup will be converted to hardware FSK very soon, which hopefully will resolve the problem, but maybe not, so that’s why I’m asking.

Gary NA6O

Re: Mysterious K3 FSK mode change

David G3YYD <g3yyd@...>
 

Gary

 

Check Configurer, Mode control tab and set RTTY to the AFSK drop down.

 

In a RTTY contest I also set Mode always with RTTY drop down (left hand side)

 

73 David G3YYD

 

From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: 25 September 2017 14:26
To: elecraft_k3@...; n1mmloggerplus@...
Subject: [N1MMLoggerplus] Mysterious K3 FSK mode change

 

 

I’m posting the to both the N1MM and Elecraft reflectors. The problem station at N6RO is a K3 running AFSK, controlled by N1MM with MMTTY. OS is Win10. This station was working ok on RTTY some months ago. This problem cropped up at the start of the CQWW contest: The rig would spontaneously change sub-modes from AFSK-A to FSK-D when you turn the VFO dial. Not just cluster-clicking, but simply turning the knob! Then you have to press the Data MD button to fix it, every time you QSY. Never occurs while running.

What I’m looking for is 1) confirmation that the K3 has no obscure feature that could do this, and 2) is there some setting I should look for in the software.

This setup will be converted to hardware FSK very soon, which hopefully will resolve the problem, but maybe not, so that’s why I’m asking.

Gary NA6O

Re: Com ports in use by other ?

Howard Rensin
 

I did not find that this program worked. It reported that my computer had no serial ports; none, nada, not even Com 1 which all computers have.

73’s

Howard M. Rensin,

Call Sign: KC3D

Life Member: ARRL, QCWA & a bunch of others.

Palm Beach Gardens, FL 33418

EL96wv

kc3d@...

 

 

Re: 'Next...' function still not working the way it used to..................

Jamie WW3S
 

We used logthenpop.....i swear the single click did not work, but it could have been operator error, we were set for work mults first i believe....the issue isnt so much hiw it works, but where...when running i would prefer not to open the bandmap, instead focusing on the digi window and the entry window...it worked so well previously, why the change?

----- Original Message -----
From: 'Rick Ellison' rellison@... [N1MMLoggerplus] <N1MMLoggerplus@...>
To: N1MMLoggerplus@...
Sent: Mon, 25 Sep 2017 07:50:49 -0400 (EDT)
Subject: RE: [N1MMLoggerplus] Re: 'Next...' function still not working the way it used to..................

“....I only tried the single click once, and if I recall, it replaced the first call I grabbed with the second one I clicked, and worked them in reverse order....doesn't the digital call stacking selection still work ( FIFO , lifo, mult first ?)”



Depending on what setting you have chosen in the call stacking menu the call that is currently in the Entry Window will be replaced. If you have selected Last in First out the call will be replaced and the call that was there will move to the stack. If you have chosen First in First out then the call will stay in the Entry Window and the new call that is clicked will be put on the stack. If Digital call stacking is turned on and you are in Run mode a single click is all that is required to place calls on the stack. As Rich mentioned I also would not recommend using LOGTHENGRAB if you are using the TU/Next sequence. You will more than likely get garbage into your stack. So only use LOGTHENPOP if you want correct working of this feature.



When the call frame logic was changed this stopped allowing call stack calls from being placed there. It’s not broken it was a meant change. The stacking and unstacking should be all automatic if setup and configured correctly.



73 Rick N2AMG



From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: Monday, September 25, 2017 6:11 AM
To: N1MMLoggerplus@...
Subject: Re: [N1MMLoggerplus] Re: 'Next...' function still not working the way it used to..................





I don't know when it "broke" but I'm pretty sure it worked in last years CQWW and I think it even worked in January for ARRL.....I know it didn't break, but was changed for some unknown reason....many, many diehard rtty contesters have requested it go back to the call frame, have yet to see a valid reason why it can't work the way it did in K8UT video....Rich , you mentioned you never look at the band map or entry window when running.....I agree with the band map, but the entry window? How are you certain what you grabbed? In a multi transmitter event, I don't even want the band map open on the run transmitter, but am forced to now to see my stack ( off topic, but related....the other ops freq is nice to see in the band map, don't remember seeing that last year, is there a way to move that to the Info window instead)



Rich , you also mentioned you just click on the call to stack them, and they are worked in the order you clicked them, and you don't need to alt click.....that didn't work for me, using a very recent version....I still needed to alt click....I only tried the single click once, and if I recall, it replaced the first call I grabbed with the second one I clicked, and worked them in reverse order....doesn't the digital call stacking selection still work ( FIFO , lifo, mult first ?)
On Sep 25, 2017, at 3:14 AM, ve3iay@... <mailto:ve3iay@...> [N1MMLoggerplus] <N1MMLoggerplus@... <mailto:N1MMLoggerplus@...> > wrote:



Based on your description, where you mention both clicking on more than one call sign and the Grab window, busted calls, dupes, etc., I believe you may be mixing up two different ways of implementing the 'next' function: LOGTHENPOP and LOGTHENGRAB. They are two different things and they work in different ways. It is easiest to pick one and stick with it, not try to combine them.



The one I like is LOGTHENPOP. To use this with ESM, you designate a 'Next' key in the Configurer, Function Keys tab. I use F9, but any unused function key will do. The message you program into the designated 'Next' key must contain the LOGTHENPOP macro, as described in the manual. Do NOT, repeat do NOT, put a LOGTHENGRAB macro in that function key message. You will regret it if you do. The final configuration step to get this method working is to enable Digital Call Stacking in the Setup menu in the DI window.





To use this method, when two people call you with valid call signs that appear in the clear and are not grey (dupes), click on the two (or more) call signs one after the other, and then press Enter or right-click to start the first QSO. At the end of that QSO, ESM will automatically use the 'Next' function key instead of the normal 'TU' function key to end that QSO and start the next one. The Grab window is not involved (unless you go out of your way to use it with a GRAB macro or Alt+G) - in fact, I have my Grab window disabled, because I don't use it. Busted calls, wrong calls, old calls, previously worked calls etc. will only get involved if you click on them. The answer to that is simple: don't click on them.



Once you choose which call signs to click on, the rest of the process is automatic. Yes, at one time the call signs from the stack appeared in the frame, but frankly I never even noticed when that stopped working, because I never look at either the frame or the Bandmap window when I am running; the LOGTHENPOP process just works. The only time it goes wrong is if I click on something I shouldn't have clicked on, and then I have only myself to blame - the Esc key comes in handy in those circumstances.



I don't understand why this is such a hot-button item for some people; obviously I am missing something. Maybe some folks are using the LOGTHENPOP macro manually without designating a 'Next' function key, or without using ESM(??). I can visualize where not seeing the next call sign might be a problem in that scenario. Anyway, I believe that what changed when the call sign frame logic was changed was that simply clicking on a second call sign now does what Alt+clicking used to do. In effect, the call signs are now worked in the order you clicked on them instead of the reverse order, but I don't recall seeing anyone comment on that.



On to the second method... This is LOGTHENGRAB. This one is not as automated. You do not assign a 'Next' function key in the Configurer for this method. You do program a function key message with a LOGTHENGRAB macro in it, but do NOT, repeat do NOT, designate a function key containing the LOGTHENGRAB macro as the 'Next' function key. You will not like the results if you do.



To use this one, you do not click on two call signs or put call signs in the bandmap stack. The LOGTHENGRAB macro does not look there, and the call sign frame is not involved. LOGTHENGRAB gets its call signs directly from the Grab window. If the call sign highlighted in the Grab window at the end of the first QSO happens to be a good call sign that you want to work next, then and only then you can click on the function key with the LOGTHENGRAB macro in it instead of using the TU key or Enter or a right-click to end the QSO. The LOGTHENGRAB macro that you called up by clicking on that function key will log the first QSO and pull the next call sign out of the Grab window and try to work it.



The Grab window is not very smart - it often gets filled up with busted calls, wrong calls, and so on. That is why the LOGTHENGRAB process is not automated - you have to supply the smarts by looking at the Grab window and deciding whether you want to use a call sign from it or not. There is a DELSEL macro that pops garbage off the top of the Grab window which you can use to help with this.



In both methods you have to supply some discretion to weed out bad call signs, etc. In the automated method, you supply that discretion by not clicking on bad call signs before starting the first QSO. In the Grab method, you supply the discretion by not using the LOGTHENGRAB function key if the call sign highlighted in the Grab window is bad, or is not the one you want to work next.



73,

Rich VE3KI




---In N1MMLoggerplus@... <mailto:N1MMLoggerplus@...> , <ron@... <mailto:ron@...> > wrote :

The "next" function has become unusable. I totally embarrassed myself this weekend in the CQWW DX RTTY contest after trying to decipher the incomprehensible instructions in hamdocs, then screwing up royally when the contest got going.



The way it used to work is that you would click on a callsign that you wanted to be 'next' and it went into the 'call frame'. The original instructions still say that, but the call frame now only displays the words "CQ-Frequency" and nothing else. You can't really choose between the busted calls, wrong calls, old calls, previous worked calls, etc. that show up in the 'grab' box and/or the band map.



The call frame apparently stopped working about a year and a half ago, and despite reporting this earlier this year, it's still a problem. Is the only work-around for this to use and old version of Logger+? I really hate to do that.



Ron

N6IE

Re: Mysterious K3 FSK mode change

Rick Tavan
 

Probably not your problem, but be aware that K3 frequency memories save DATA mode info. If you invoke a memory that was originally set with a data mode other than the one you're using now, it switches. This drove me nuts until I figured it out because I use memories as band switches. 

/Rick N6XI


Rick Tavan
Truckee, CA

On Mon, Sep 25, 2017 at 7:26 AM, Gary Johnson gwj@... [N1MMLoggerplus] <N1MMLoggerplus@...> wrote:
 

I’m posting the to both the N1MM and Elecraft reflectors. The problem station at N6RO is a K3 running AFSK, controlled by N1MM with MMTTY. OS is Win10. This station was working ok on RTTY some months ago. This problem cropped up at the start of the CQWW contest: The rig would spontaneously change sub-modes from AFSK-A to FSK-D when you turn the VFO dial. Not just cluster-clicking, but simply turning the knob! Then you have to press the Data MD button to fix it, every time you QSY. Never occurs while running.

What I’m looking for is 1) confirmation that the K3 has no obscure feature that could do this, and 2) is there some setting I should look for in the software.

This setup will be converted to hardware FSK very soon, which hopefully will resolve the problem, but maybe not, so that’s why I’m asking.

Gary NA6O


SCQ and Running issues

John Holmes W9ILY
 

During the CQWW-RTTY this past weekend I ran across two items when running that I wanted to mention.

The first is a question about {SCQ}. I use CQ Repeat and ESM. At the end of my F3 macro I have {SCQ} so that CQing resumes again after the QSO. If I hear a caller I press the <ESC> key to stop the CQ. A couple of times during the weekend something odd happened. I pressed the <ESC> to stop the auto CQing and all was OK. The caller was very slow in responding and, strangely, my CQ began again just as he was starting to send his call. I pressed the <ESC> again to stop it and usually had to ask for a repeat.It almost seems that the auto CQ began again after the 3.2 seconds that I have configured for the CQ delay. I may have been imagining this but thought it might be worth mentioning.

A second item is a comment about the entry window when running. After logging a contact and going back to CQ, the top area that was the "on deck" area of course shows "CQ-Frequency" but the lower left area where the DX caller's info is populated shows "CT: EU/Portugal, Zn 14" as if it is reading the CQ as a callsign. Just a mention for a future tweak.

Thanks for all the hard work, guys!

73,

John W9ILY

Happy User

Tom Martin
 

Just finished the CQWWRTTY test and N1MMLogger+ was flawless! Not one glitch. Not one freeze. I'm still using an old XP desktop for contests. Most happy with the result.

Thanks to all who make this the best contest program out there.

73,

Tom W8JWN

new user

Ken Reid
 

Hi group,

I am using a Kenwwod 590sg and N1MM+.

When using the RTTY mode, and the MMTTY engineI, I have the radio set to LSB and Data. Which is the only way I could get it to send and decode.

This works fine for S&P, but when I click on a station in the multiplier window it shifts the radio to FSK.

I could use some advise.

73 to all

Ken

KG4USN

Re: 'Next...' function still not working the way it used to..................

Tom Osborne
 

I couldn't use that here this weekend as the box with the calls in it was full of junk.  If I clicked on W1AW, WDF%%GHW!AW would be in the box.  Some calls were right, but a lot of them were just junk.

I unchecked 'find calls in garbage', set the squelch way high, and every other thing I could think of to no avail, it still put all sorts of garbage text in the box.  It never used to to do that before

Other than that, it worked perfectly for the whole contest.  73
Tom W7WHY


On Sun, Sep 24, 2017 at 8:53 PM, ron@... [N1MMLoggerplus] <N1MMLoggerplus@...> wrote:
 

The "next" function has become unusable.  I totally embarrassed myself this weekend in the CQWW DX RTTY contest after trying to decipher the incomprehensible instructions in hamdocs, then screwing up royally when the contest got going. 


The way it used to work is that you would click on a callsign that you wanted to be 'next' and it went into the 'call frame'.  The original instructions still say that, but the call frame now only displays the words "CQ-Frequency" and nothing else.  You can't really choose between the busted calls, wrong calls, old calls, previous worked calls, etc. that show up in the 'grab' box and/or the band map.


The call frame apparently stopped working about a year and a half ago, and despite reporting this earlier this year, it's still a problem.  Is the only work-around for this to use and old version of Logger+?  I really hate to do that.


Ron

N6IE


.

Re: new user

ve3ki
 

In the Configurer, under the Mode Control tab, right side of the window, set the Mode Sent to Radio for RTTY to LSB. You must have it set to RTTY now, and this is what is causing the program to switch the rig into FSK (RTTY) mode.

73,
Rich VE3KI



---In N1MMLoggerplus@..., <ken@...> wrote :

Hi group,

I am using a Kenwwod 590sg and N1MM+.

When using the RTTY mode, and the MMTTY engineI, I have the radio set to LSB and Data. Which is the only way I could get it to send and decode.

This works fine for S&P, but when I click on a station in the multiplier window it shifts the radio to FSK.

I could use some advise.

73 to all

Ken

KG4USN

Available Multipliers & Q's Window not working?

Robert Bereit
 

Worked the CQ WW RTTY contest this weekend. The window for Available Multipliers & Q's didn't seem to be working. My Telnet connection was up, spots were coming through and being posted on the bandmap, but nothing appeared in the Available Mults window.


Any one else having this problem?

Re: Available Multipliers & Q's Window not working?

ve3ki
 

Click on the Bands & Modes button in the Available Mults & Qs window. Check to make sure the bands and modes you want are being passed. Note that this filter, although it looks very similar to the one in the Telnet window, is not the same one. This one only affects the Available window, not the Bandmap or Telnet windows.

73,
Rich VE3KI



---In N1MMLoggerplus@..., <rmbereit@...> wrote :

Worked the CQ WW RTTY contest this weekend. The window for Available Multipliers & Q's didn't seem to be working. My Telnet connection was up, spots were coming through and being posted on the bandmap, but nothing appeared in the Available Mults window.


Any one else having this problem?

Re: 'Next...' function still not working the way it used to..................

Phil Cooper
 

Hi all,

 

I have tried in the past to get the LOGTHENPOP function to work, and – try as I might – I just can’t get it to work smoothly. Each time I have tried it, I either get the wrong call next, or it fails to load the “next” call on the bandmap.

Actually getting calls on to the bandmap in the first place has been an issue.

The instructions say to enter a call,, press the F key (can’t recall which one now) and then enter the next call, which is the one you will work first.

 

For the life of me, I cannot see how this is practical.

 

In the last few contests, I have made use of the {LASTCALL} function. I have one F=key called NEXT, and the message is something like {TX} TU {LASTCALL} 73 {ENTER}NOW {F2} {F5} {RX}

and that seems to work for me. I can see the calls come up, I click on one, work him, press enter to log the call, then click on the next one I choose.

I find that far easier, and I can control who I work next, especially if there are multiple callers.

 

Is this not a better solution? Or am I mis-using the macro?

 

73 de Phil GU0SUP

 

 


Virus-free. www.avast.com

Program hangs

John Eigenbrode
 

During CQWWRTTY everything worked smoothly till I tried to email the Cabrillo file, then n1mm locked up with a “This operation cannot be completed warning”. Could not type in the email window, or access any windows in N1MM+.
Running Windows 10 with latestest updates. Rig is Yeasu FTdx-3000 using USB interface. I had to use task manager to shut down the email window, N1MM+ and MMTTY.
I then started the logger again with the same results.
Shutdown overnight and tried again this AM with same results.

Re: Com ports in use by other ?

Michael <wa7skg@...>
 

@F1VEV [N1MMLoggerplus] wrote on 09/25/2017 12:37 AM:
HI Rich,
Thanks but  maybe I should have said that this was done at least the restart of windows and that did not solve the issue  anyway will look into it when I get home tonight 73s
Windows does not always fully close everything when restarting. Do a complete power down, unplug the computer, press power button to deplete the power supply. This kills all memory functions. Then plug it in and restart. Sometimes it takes that drastic of a shutdown to get Windows to actually close everything.

Michael
WA7SKG


.

Re: PTT hanging

Michael <wa7skg@...>
 

'John Bednar' k3ct@... [N1MMLoggerplus] wrote on 09/25/2017 02:55 AM:
What radio?
It is unusual that the hardware PTT from the Microham is not used and you are relying on radio command PTT. Why?
The CPU usage for Logger+ and radio command PTT not working seems to indicate that you are getting RF into the radio control cable. Do you lose radio control at the same time?
John, K3CT
I have this occasionally with IC-7300. Happens with several different digital programs. I hit send, the radio keys, the message is sent, the software indicates unkey but the radio continues to transmit. I must hit the transmit button on the radio to unkey. No explanation, cannot force it to happen. It just periodically happens.

Gremlins.

Michael
WA7SKG


.