WinKey emulator issue: Why is space(s) required at end of N1MM+ F-key command?

[w2huv]

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.

[W1UE]

In the N1MM+ radio setup, I use 38400-8-n-1, Always Off, Always Off, Nothing checked, Normal Polling rate, no foot switch.

In the N1MM+ Winkey setup, I use Always On, Always Off, PTT Delay 30, Allow ext Interruprs not checked, Winkey checked, two radio protocol none and footswitch none.

I get a radio timeout maybe once an hour.  I have yet to see a Winkey error message.

Dennis W1UE

[W1UE]

In N1mM+, on the Configure-Winkey tab, the Pin 5 function is PTT. 
Lead Time, Tail TIme, First Character, Keying Compensation are all 0.  Hang time is 1.33.

[Jan (Microbit)]

Jan (Microbit) - Ok, you are hoping that the Microbit software developers will implement the work-around in their software.  I am going to try increasing the COM1 baud rate to 38400 as suggested by Dennis and see what that does.

No, I am one of the software developers at Microbit and we are not the developers of Win-Test and similar programs  The work-around would have to be implemented in Win-Test and other Windows/PC programs using serial ports.

I got a reply from the maker of N1MM+ and he says they are using vb.net and not Win32 API directly(like Win-Test). That means they are most likely not able to implement the Win32 API work-around that the Win-Test developer found.

[w2huv]

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]

It functions just like a winkey.  The connection to key the transmitter is done inside the RR Box. 
I never thought about your question, because its always worked on my unit.
If it makes a difference, I do have Com 1 rts/dtr set to "yes"but I don't think that is how the keying is done.
It works, so I haven't changed it.

Dennis W1UE

[w2huv]

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.

[w2huv]

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?

[w2huv]

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.

[sm2o]

The Winkeyer keys the the transmitter via the output you have selected normally out 1 or out 2 which is connected through the PAD jack

/mike

[w2huv]

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.

[w2huv]

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.

[W1UE]

I use a LF of 0, and a KeyDel of 50.
I normally wouldn't have a problem with spaces at the end of N1MM+ key commands.  Every Fkey message
I use has a space at the end of it so that they can be "chained" without running together.

Dennis W1UE

[w2huv]

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.

[W1UE]

John

I'm going to go back to the first sentence you wrote in this thread: "I am a member of RHR".  In addition, RHR has told you how you need to send CW using N1MM+, and that did not include using the RRC Winkey Emulator.  Granted, this was before the improvements in the RRC Winkey Emulator, but RHR has apparently never revisted the issue.  I've used their setup and I can vouch that it works quite well and smoothly, but I'm not a member and have no access to test out the RRC Winkey usage with it.  It is also a "Winkey Emulator"; there are many versions of Winkey Emulators out there, and many of them don't support the variable setting that N1MM+ has on its Winkey page.  The Winkey Emulator was designed as an addition, or a bonus, to the package; most were never designed to be a full fledged Winkey.  That's neither good nor bad, it just is.

Your issue seems to be a timing issue- something somewhere in the chain between your computer, the Control RRC, Internet line, Remote RRC, and Remote Radio is disrupting the timing of the signal going to/coming back from the Remote RRC, resulting in ERR KEY or ERR PTT. 

My system is not the same as yours, as I have full control over the settings in both the Control and Remote RRCs (I believe that RHR locks the user out of the Remote RRC, and I can understand why).  I use a space at the end of all my N1mM+ messages, not because my unit needs it to work correctly but because it makes chaining messages go much smoother.  My setup works perfectly with NO spaces at the ends.

Bottom line, to make this work, and to make it work smoothly, RHR will most likely have to make changes in their system.   Until that happens, the best you can do is to use your workaround and live with the errors.  If you haven't contacted RHR lately, you may want to make another effort in getting them to look at the usage of the RRC Winkey. 

Dennis W1UE