Remote Rig Winkeyer and N1MMPlus

[OH2FT]

Winkey output from win-test over USB works with RRC keyer and paddle over com 3 !
However, I haven't figured out how to forward PTT signal over com 3, only coms 0/1/2 are selectable
from I/O page. I want a separate PC for win-test and an other PC for CAT etc (RS232 modes 3 and 4 in use).

In addition, if mode 8 in com 3 is configured, but the usb cable is not in place, and you transmit with
paddle and use hand mic PTT, PTT hangs on extra 5 seconds after transmission, probably wondering where the missing winkey signal was...

Joni OH2FT 

[w4rm]

Which is the prefer side to install the winkeyer?  Remote or control?

My control is currently sending the CW via the CAT port and its not perfect.  I want to install my winkeyer back into my remote set-up that it was remove when I configured the K3 for remote.

Will this help my control side CW that's being transmitted?

I was running  a laptop and N1MM+ last night in the 160M contest and I we repeatedly sent the other person call sign as if I send it back in my exchange incorrectly.  By changing the delay settings and moving up to 30WPMs it seemed to help but I'm hoping that the winkey will also help on the remote side.

Thanks for any help
73 Bill  W4RM

[dj0qn]

Bill,

They are referring to the built-in Winkeyer emulation in the RRC. You need to select Winkeyer (or FSK)
in the control RRC serial settings under COM3. Then use the COMEXTRA serial port in Windows as
the Winkeyer in your program.

73,
Mitch DJ0QN / K7DX

[w4rm]

What is the proper set-up configuration for Winkey?      (I'm using K3/0 Mini with 1258MKII twins, laptop at the control side with N1MM+ and K3 K-line at the remote site (Local LAN at present).

Install at the Control or remote site?

Install Winkey on COM 1 , 2 o3 ... doesn't matter?

What is the main reason for using winkey?      Is it to get N1MM (from control side) to send the data across the network and get the remote side Winkey to generate the CW?   By getting the remote side to generate the data to ensure purity of the CW being transmitted?

I'm ran the 160M contest over the weekend with the above set-up and had lots of people send me their callsign again as what I sent them was incorrect, I did copy it correctly, (CW was being generated from the control side laptop on the KAT port within N1MM+).

I'm assuming this is what driving people to install the Winkey?

Thanks for everyone's help

73 Bill  W4RM

[dj0qn]

I already described how to use Winkeyer in my last posting. It is not complicated, just use the virtual port in
Windows after changing COM3 over in the control RRC.

The reason for using is that some software has problems keying over CAT and that gets around that problem,
plus other preferences that some may have for Winkeyer. There is no difference from using the normal method
of generating CW over the RRC's, but with some software (like N1MM), it is easier to key using the Winkeyer
emulation.

73,
Mitch DJ0QN / K7DX

[EI3KD]

V2.84 firmware has fixed the general interaction problem with N1MM+, but I've just found another small problem: Once a message has been started, e.g. "CQ EI3KD EI3KD TEST", it cannot be interrupted using the manual paddles - this is true with N1MM+ and WinTest, at least.

I'm not sure if there's still some problem with a UST byte being required to indicate the paddles are activated (I didn't check whether remoterig sends this?), but "Paddle Input Priority" is also a feature of Winkeyer2: "Winkeyer2 accepts input from either its serial port or iambic paddle. The paddle will always take priority and will interrupt serial data, automatically clearing Winkeyer2’s serial input buffer. When a paddle break-in occurs, any additional serial data that arrives from the host will be processed, but will be ignored unless it is an immediate command. After paddling ceases, Winkeyer2 will pause for one word space time before it resumes serial data transmission."

It would be nice if this was working properly, but perhaps it's not feasible?

Regards, Mark

[Jan (Microbit)]

Thank you for pointing out that there are more issues regarding the WinKeyer "emulation".

Please give this new beta version a try and see if it works better(and that it has not regressed either!)

http://www.remoterig.com/firmwares/RRC1258-CRC-v2.85_2015-01-29-BETA.zip

 

[EI3KD]

Hi Jan,

once again thanks for looking at this!

The beta version worked as far as interrupting the serial cw using manual paddles - but at some point while I was testing it (using N1MM+) the remoterig control box "crashed", i.e. it restarted as if just powering up. That's the first time it's ever done that, so I guess there's something not quite right in that version. I'm trying to pin down whether I can reproduce it exactly, but in the meantime other people should be careful about using that file!

Regards, Mark

[EI3KD]

Ok, I wonder if this helps? I found this message when I went to my remoterig control box's web page:

Saved error message:
Data Abort at 0x00038e88, called by 0x00038ff4


I can reproduce the problem but it's very contrived and seems peculiar to something N1MM+ does, because I can't reproduce it in WinTest. Unfortunately, it's also in firmware V2.84

I can try and give more detail if required (or perhaps capture the serial data?), but briefly (with N1MM+ V1.0.4616.0):

1) N1MM+ menu Config/"CW Autosend Threshold" set to 1.

2) N1MM+ in Run mode, Rig in CW.

3) Type F1TTT in call entry window: N1MM+ (and hence the winkeyer) starts sending after the "F1T" is entered, and sends the complete exchange - in my case that is "F1TTT 001 IO51VW". Actually, for some reason it only sends F1TT as the call but with the correct exchange, but that might be a different problem?

4) Don't log the QSO, instead hit F12 to wipe it.

5) Enter F1TTT in call entry window (again) - no cw is sent (it should be...) and the remoterig control box reboots.

I can't help feeling that this winkeyer stuff is causing you more trouble than it's worth, sorry!

Regards, Mark

[Jan (Microbit)]

Hi Mark (and others),

Thanks for testing and giving detailed explanations about how to reproduce the issues you have seen! 

After digging deeper into this it seems the crash was caused by the "buffer pointer manipulation commands" used by N1MM+(and maybe N1MM too). Also those commands were the reason "on the fly editing" did not send all characters.

Reading the Winkeyer documentation it seemed not that difficult to change the RRC's handling of those commands so it would work, but it was not that easy since what the documentation calls "overwrite" actually seems to be what I would call "insert"(in the context of how to handle characters after getting a "buffer pointer overwrite command"). The Winkeyer documentation also refers to a "Application note" which should elaborate on the subject of the "buffer pointer manipulation commands, but we have not been able to find it.

So what has been done is handling "overwrite" as "insert", and "append" as "overwrite". The  "overwrite" as "insert" seems to be the right way to deal with it since N1MM+ now works with "on the fly editing". But "insert" as "append" is not verified since we have not been able to force N1MM+(or any other software) to send that command.

WinTest, and other software, do no use the "buffer pointer manipulation commands" at all, so they worked ok.

There is a new 2.85 Beta for you to test here:

http://www.remoterig.com/firmwares/RRC1258-CRC-v2.85_2015-02-04-BETA.zip

It's a rather "heavy" redesign of the Winkeyer support so please keep your eyes open on other things than just "on the fly editing" 

[EI3KD]

Many thanks Jan,

it's early days yet, but I've been testing the winkeyer emulation in your latest beta today and it's looking great with N1MM+ V1.0.4646.0. None of the previous problems I had are there, no box crashes, N1MM+ auto-send is working perfectly, and I haven't found anything new... so far! I'll try a bit harder to break it

I've tried quick tests in DxLog and WinTest, which also seem fine. There are so many different contexts, hopefully a few others will check it out for their particular setup too...

Regards, Mark

[K3TN]

I am going to load this beta, as just ran into the problem today in the CWT contest. All of a sudden N1MM CW send would not work the way it used to  - if I hit Enter to start sending and kept typing in remainder of the call, it would not send the additional characters. I will try this beta tonight.
73 John K3TN

[Jan (Microbit)]

Many thanks Jan,

it's early days yet, but I've been testing the winkeyer emulation in your latest beta today and it's looking great with N1MM+ V1.0.4646.0. None of the previous problems I had are there, no box crashes, N1MM+ auto-send is working perfectly, and I haven't found anything new... so far! I'll try a bit harder to break it

I've tried quick tests in DxLog and WinTest, which also seem fine. There are so many different contexts, hopefully a few others will check it out for their particular setup too...

Regards, Mark

Great!

How about the CW speed? Another user reported that it seems to only send the first character using the N1MM+ speed and then revert to the speed set by the RRC. I do not see how that could be possible though.

[Jan (Microbit)]

I am going to load this beta, as just ran into the problem today in the CWT contest. All of a sudden N1MM CW send would not work the way it used to  - if I hit Enter to start sending and kept typing in remainder of the call, it would not send the additional characters. I will try this beta tonight.
73 John K3TN

It sounds less likely that the "on the fly" issue could be the cause since it happened suddenly. If so then N1MM must have changed from not using the "buffer pointer commands" used in "on the fly" scenarios to using them, just like that 

[K3TN]

The "all of a sudden" I mentioned really meant "the first time I used N1MM+ in a contest where I called CQ, the problem happened..."!

I loaded the latest 2.85 beta and it seems to have fixed the problem - if I am calling CQ and K4RUM calls me,  I can type in K4RU hit enter. N1MM will start to send and I can enter the last letter M and N1MM+ will send K4RUM - all is good.

I tested it out a bit last night in the CWT test it worked fine, but I was able to cause one bad crash. Not quite sure, I couldn't seem to repeat it, but it crashed N1MM and trashed my Com Ports, had to restart PC.

I *think* the actions that caused the crash: I called CQ (hitting F1), W3ABC answers. I start typing W3AB and then hit SPACEBAR by mistake, which advances cursor to next entry box (in this case that is the NAME field). Hitting SPACEBAR doesn't not initiate response, so I hit ENTER key - kerplooey. The ability to keep entering a callsign while CW is being sent I think should only happen after the ENTER key or LOG command is given - the cursor is still in the callsign entry box. If the cursor has been advanced, should not be going back to callsign  buffer unless cursor was moved back there.

I dunno if that makes sense - tonight will try it again in the NS Sprint and see what happens.

Thanks for all the updates on this.

73 John K3TN