Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - w2huv

Pages: [1] 2
The subject issue was resolved by unchecking “PTT via Radio Command CW Mode” in the N1MM+ logger “Details” for the Elecraft K3 as shown in the attachment.  It was that simple!

Thanks to all that attempted to assist me.

W1UE - Dennis, I have answered your questions in bold in your response:

You have a K3/0 Mini.  Some questions:
1. Do you connect the paddle to the Mini, or to the RRC Control Box?  To the RRC box.
2. You are using the attached USB cable and the Microbit ports for radio control and Winkey.  Yes.
3. What version of the K3/0 mini firmware are you using?  0538.  I didn't disconnect the internet line because I wasn't connected to a remote station.  To see what is in your mini, you have to disconnect the Internet line to the RRC box, turn the Mini on, then enter the Config menu.  If you leave the Internet line connected, you will see the Firmware version of the Remote K3 unless RHR has disabled it.
4. If you aren't using Firmware 5.38, you should update.  There were several fixes related to ERR KEY in Firmware 5.38.

My view now is that this problem is not directly related to RHR or Remote Rig units, but has to do with your equipment, either the Firmware or the station setup.  Something is causing the ERR KEY message.  ERR KEY is telling us that the keying line is being grounded by something; if it was an RHR problem they would be having LOTS of complaints.  That makes sense.  Since you seem to be the only one with the problem, my conclusion is that it must be local to your setup.  What is wrong, though, is escaping us.

Dennis W1UE

Would you suggest that I send you a Private Message or use the email address posted on QRZ?

Thursday afternoon I requested RHR to record and report to me the "PTT activated by Keyer" and "PTT tail delay" for the stations that I operate on 160m, W1/Calais160, W2/Summit160 and W4/Atlanta.  So far, no response.

Being impatient as I am, last night I decided to do experiment to determine the settings myself.  First, I removed the space at the end of each function command definition.  Then, I turned off VOX (activates PTT).  That made no difference.  Since VOX was off, the logical conclusion is that "PTT activated by Keyer" is on.  Since I continued to receive ERR KEY messages, I suspect that "PTT tail delay" is set at 0.

Any comments?

W1UE - Dennis, would you please provide your two radio RRC Keyer settings?  The parameters are as follows:

PTT activated by Keyer (No/Yes)
PTT tail delay ms [0-999]

sm2o - Thanks for your insight!

Jan (Microbit) - I was doing what W1UE suggested (read the manual) while he was preparing his last post and answered my last questions.  I found that the radio RRC only has two settings:

PTT activated by Keyer (No/Yes)
PTT tail delay ms [0-999]

No recommended settings are listed.

Is the first setting supposed to be "On" when using the WinKey emulator?  What is a typical value for the second setting?  I would assume that it should be the same as the "Key delay" setting in the control RRC.

When I know what the settings should be or at least starting points, I will contact RHR and have them check and change the settings as needed.

W1UE - It would be helpful to know the values that you are using for the above settings.

W1UE - Dennis, I talked to Lee, WW2DX, one the co-owners of RHR, on the phone yesterday.  He told me that you should never use the KY CATA1ASC sequence in N1MM+ function key definitions when you are using a K3/0 or K3/0 Mini control head and an RRC1258.  He also told me that he has operated in several contests using the WinKey emulator built-in to the RRC1258 in the past and doesn't recall any problems.  Apparently, we had communications failures in the past.  He told me that he will that a look at my issue when he has some "on" time.

One probable difference between the RHR configuration and your configuration is that operation is in half-duplex because full duplex requires too much bandwidth.

Thanks for informing me that many Winkey emulators don't support the variable settings that N1MM+ has on it's Winkey page.

Jan (Microbit) - I found "PTT-off mute delay" listed in the Advanced Settings on my control RRC.  Does "PTT tail delay" only appear in the Advanced Settings of a radio RRC?

W1UE - So the truth comes out!  You have a space at the end of each function command, just like I did.  I'm going return Lf and Key delay to the original values and add the space again, because I just discovered that I still get an occasional ERR KEY message.

Here's the thing though.  The space shouldn't be required.  Here is why:

What does a "Key delay" of 50mS mean?  It appears to mean that the first dot or dash is delayed 50mS after PTT is enabled.  That suggests that PTT should be released 50mS after the last dot or dash.  That doesn't appear to be happening when the WinKey emulator output is controlled by ASCII characters it is receiving from the N1MM+ logger.  However, it does appear to be happening when the WinKey emulator output is controlled by a paddle.

In studying the information about the WinKey settings in the N1MM+ manual, I found that the PTT release delay is referred to as the "Tail Time".  I tried adjusting it (found on the Winkey tab), but it had no effect.

Also, I have been able to reproduce the issue by pressing the ESC key to release PTT while sending CQ.  The K3 hangs and I receive an ERR KEY message, if I do so during a dot or dash, but not otherwise.

Jan (Microbit) - Please review the above.  I believe that the problem is that the "Tail Time", if any, isn't equal to the "Key delay", as I believe that it should be.  This is only a problem when the WinKey emulator output is controlled by ASCII characters.

The subject of this thread is "WinKey emulator issue: Why is space(s) required at end of N1MM+ F-key command?".  I believe that I now have the answer to the question.  A space or spaces may be needed at the end of N1MM+ function key definitions to offset your Key Delay setting.

I have been using the suggested values of Lf and Key delay, 100 and 50 mS, respectively.  I just reduced the settings to 75 and 25 mS, and so far, I haven't had a problem with hang-up's and ERR Key messages with no spaces added to the end of my function key definitions.

sm2o - AhHA!  Mike, thanks for getting me pointed in the right direction!  I just checked and the OUT2 Mode is "Keyer" on my Control RRC.  According the CW-Keyer section of the RRC1258 User Manual, the settings for the Control RRC output modes are irrelevant, but the Radio RRC OUT0, OUT1 and OUT2 modes are supposed to be set to I/O, I/O and Keyer, respectively.

W1UE - Dennis, what values of Lf delay and Key delay are you using in your Control RRC?  The reason that I have to add a space to the end of all of my N1MM+ function key definitions may be related to the value of Key delay.

The reliability of the virtual COM1 connection appears to have improved since I increased the baud rate from 9600 to 38400.  I have yet to see communications lost between the N1MM+ logger and the RRC1258, but this is after only limited monitoring.

Also, prior to upgrading the RRC1258 firmware to version 2.90, I had to add two spaces to the end of each function key definition.  Now it appears that only one space is required.  Again, this is after only limited monitoring.

Dennis, thanks for reminding me to switch on COM1 rts/cts.  I just tried keying the transmitters at several stations directly from the N1MM+ logger and discovered that there was no output.  So, apparently, rts/dts keying has been disabled at all stations.  That means that the only method that works is the cable from the PAD jack on the remote RRC1258 to the KEY jack on the rear of the remote K3.  So let simplify my previous question:

How does the WinKey emulator key the remote transmitter?

Ok!  I just re-read the description of RS-232 port the K3 manual.  It describes the use of DTR and RTS for CW and PTT.  The N1MM+ logger communicates with the remote K3 via the following path:

1.  Cable from USB port on control PC to COM1 on the control RRC1258,
2.  Internet connection between control and remote RRC1258s,
3.  Cable from COM2 on the remote RRC1258 to the RS-232 connector on rear of the remote K3.

I have transmitted CW from a remote K3 in the past using this path after setting DTR to CW in the N1MM+ logger configuration for the connection to COM1.

Now I am concerned that the remote K2 may be keyed by both a DTR input via the RS232 input and the input provided by a cable from the PAD jack on the remote RRC1258 to the KEY jack on the rear of the remote K3.

The source of this concern is Figure 12 on p-16 of the K3 Remote Owner's Manual Rev D, which illustrates an RS232 cable from COM2 on the remote RRC1258 to the RS-232 connector on the rear of the remote K3 and a cable from the PAD jack on the remote RRC1258 to the KEY jack on the rear of the remote K3.

How does the WinKey emulator key the remote transmitter?  Does it use COM0 DTR or RTS?  The reason for the second question is that for the N1MM+ logger to key the transmitter directly, DTR must be set to CW.

W1UE - Ok!  I switched back to the virtual COM1 connection and upped the baud rate to 38400.  It will take a while to see if dropouts still occur, but I have already determined that I still get occasional ERR KEY messages if the spaces at the end of each N1MM+ command are stripped.  I had to put the spaces back in.

Pages: [1] 2