SSDR v1.8.3 cw N1MM with emulated winkey

Douglas Maxwell

IARU HF Championships contest is in full swing at the moment and I thought I'd get the 6300 back out the box to see if I can contest with it yet.
Problems:
1) Cannot get SSDR Winkey to hold PTT on during transmit despite setting up a "P" port and assigning it in N1MM for slice A. I have to rely on breakin being selected and a delay of "300" @30wpm which means it's too slow to transition to rx for contesting.
2) If I'm called by gm0elp and I get "gm0" typed then hit enter then proceed to type "elp" whilst "gm0" is being sent by the winkey emulator, the sidetone audio cuts when I hit the remaining callsign keys. A real pest as I'm a slow typer and make most qsos this way. I cannot tell if it affects the tx, but loads of stns repeating their call after my garbled?? return.
3) I can see stns on the spectrum scope than I can't hear. I can see that weak stations are calling me, but cannot hear them. I find playing with the RIT as little as 20Hz helps some of the time.

This could be all finger trouble on my behalf, but I seem to remember the same problems with 1.6.21 and 1.7.3 ? Anyone have any advice?
 

Douglas Maxwell

Ok got 2) working by following another post and reducing the priority of logger+ in task manager. Does this mean the winkey emulator was done in SSDR and not firmware?

ctate243

Hi Doug, The flex programming team is in the process of working on some of these issues as we speak.  another (the break in or MOX on ptt) is targeted for remediation in the nearish future  One possible solution to get you through IARU would be to move to a hardware  winkeyer I discovered that to work well but some issues remain with the lead character.

Feel free to contact me off list if you want further contest related guidance in this regard, I realize these can be frustrating issues.  I should be back at my home QTH in W6 Monday.

Chris

N6WM -- ZF2CT

 

Tim - W4TME

Neither.  The Winkeyer emulation protocol logic is done in SmartSDR CAT.  CAT then sends a command to the radio hardware to generate the actual CW.

Douglas Maxwell

I assume an embedded processor at the 6300 end of the ethernet link is being used to decode the commands and generate the cw?  

Douglas Maxwell

Thanks Chris, I love the idea of getting rid of all the cables and just having SSDR CAT and 1 ethernet cable. I have a K3 based contest station and the number of cables required is a nightmare (always something getting pulled out by mistake in a constantly changing shack). I didn't notice the lead character issue, but I had the delay set to stop unkeying throughout the message so this probably minimised disruption of the Q at the expense of missing some of the fast starting callers. I did however have to turn the volume of the sidetone up higher than the rx volume to help my ears pick up on my own tx initial character which seemed to meld in with the end of my rx. What do you have your Radio Setup -> Transmit -> Tx Delay set to?

ctate243

Not a problem.  Yes this is a priority of mine as well.  But it does need to be bullet proof functional for our contest shacks thus the temporary solution recommendation.  I will look up my functional delay settings and share them tonight. 

Tim - W4TME

Yes.  The same internal commands that are used to generate CWX is used for the emulated Winkeyer protocol.

Ria

Glad to see it's not just me. I used it for WW CW this weekend. A few things I've noticed:

Sometimes it will just fail to send CW. N1MM+ will apparently get the keypress and no CW would come out. Could be a N1MM+ problem though. 

Sometimes I stop CW mid-stream and try to send CW again only to get the tail end of what I was sending before.

Sometimes I will get a bust of 150wpm CW (sounds like it to me). I'm guessing this is a buffer emptying itself. 

I might switch back to serial port CW, even with a real serial port interface. However I'm hoping Flex will figure it out so I can keep the cabling simple which is one of the things I love about the whole system. 

Kevin

Hi Ria... I used N1MM+ (v1.0.5988.0) this weekend with a 6500. I didn't seem to have this problem. I only had about 200 Qs (though many many more calls) and I didn't hear a single glitch.

Is there any configuration comparison we could do to maybe figure out what might be the issue?



Kev

Ria

Sure. 

Ria

Forgive my billions of ports but I will explain them:
Com7 is for WSJT-X. I always keep it monitoring a slice except when contesting.

Com8 and Com9 are for my regular log (Log4OM). This way if I work, say, a DX station in sweepstakes I can just dump them in the regular log since N1MM+ won't log them. 

Com10 and Com11 are CAT ports for N1MM+

Com12 is WinKey 

Com13 is OTRSP

Com14 I forgot what it was. Maybe I should get rid of it.

Com15 is PTT

Com5 and Com6 are physical ports to bandswitch my amp. They'll be going away with 1.10.

I followed the K9CT instructions to a T. 

Kevin

Hmm, I guess not. Your setup is way more complex than my SO1V mind can handle. Maybe there's a clue there?

I do have an unrelated thought about connecting to Log4OM during a contest. From the N1MM+ docs:

Force logging - The program tries to help you by validating what you copy as the Exchange, but if it is balking and you don;'t want to stop to figure it out, you can force logging with Ctrl+Alt+Enter. A small Note window will pop up, pre-filled with the words "Forced QSO". You can type over to remind yourself later what you copied, or simply hit Enter to log the default note.

Maybe reducing some of the complexity may smooth things out. Good luck!

Kev

Ria

Sounds good! I am happy with the separate COM ports for OmniRig/LoG4OM but this is something I can definitely use. 

If this is not a bug, I have a feeling RF is getting in and mucking with something, but nothing else seems amiss. I have common mode chokes and all transmit antennas are at least 100ft away from the house. So it's pretty baffling. Maybe I'll run a few non-contest pileups on different bands and powers and see if I can reproduce it. 

K1DBO

This weekend I was seeing a problem simlar to (same as) what Ria was describing.  N1MM Logger+ would be sending CW via a SmartSDR CAT winkeyer port just fine.. right up until it didnt.  I could hit any of the send buttons in the logger and get nothing in return.  The only fix was to restart the logger.  It seems that closing and reopening the winkeyer port would make it all right again, but sadly Logger+ doesnt have a button to press that makes that happen.  There is the "reset radios" button that seems to do just that with the CAT ports, but for some reason the winkeyer port doesnt get reset during that command... or my guess is wrong.  But, if instead of shutting down and restarting I could go into the "configure ports..." dialog and toggle which winkeyer port to use.  This would fix things some time but mostly it was more difficult than a restart.

I'm not going to jump to the conclusion that Logger+ is to blame, but it's pretty clear it could either avoid the problem by use of a watchdog timer or provide a reset button.  Now with that said, I'll also point out that I suspect RFI to be part of the problem.  And if it is RFI related I also think the problem is very close to the Flex, not the computer running Logger+ or SmartSDR CAT.  The reason I suspect this is that the problem happened much more often on 15m than any other band.  But then again, I've also seen it happen when transmitting at only 1watt.  I apologize for the conflicting information, but it's all I have.

A year or so ago and a few SmartSDR releases back I had nearly this CAT winkeyer hanging problem with HRD's DM780.  It was far to easy to get it to cause the hang.  But at that same time Logger+ was working flawlessly.  For the record, I'm currently running SmartSDR 1.9.13.173.

Phil M0VSE

I noticed what I think is a similar problem at the weekend where N1MM wouldn't accept function key presses. I noticed a couple of things, firstly when this happens, the sent echo at the bottom of the entry window would be missing a character (instead of my callsign M0VSE, it would say MVSE for example) and the TX indicator would still be amber as if N1MM hasn't detected that the winkeyer has stopped transmitting.

Pressing 'ESCAPE' would sort this and I could then press function keys and transmit but it was pretty annoying and happened quite frequently (probably 1 in every 10 TXs)

In my mind this seems to have started only on the latest version of N1MM and I didn't notice it during previous CW contests with SSDR v1.9 but I may be wrong?

73 Phil M0VSE

Tim - W4TME

We have addressed many of these Winkeyer and N1MM+ issues in the upcoming SmartSDR v1.10 release. We are working diligently to get it released as soon as possible.

K1DBO

Ah the "escape" key... I wish I thought of that.  It would have saved a couple of contacts.  ...and now that you mention it, I did notice the "1" missing from my call when it happened.

K1DBO

Good to hear... with luck the fix will cover the the DM780 problems as well.  Thanks.

Ria

I was running last night in QRP Fox hunt as the fox. Basically stations try to find you, call you, and you run QRP (5W). 

When I call CQ using N1MM+ it would send the winkey command but SmartSDR would turn off the sidetone until the next keypress. That is not that big of a deal but it's somewhat mentally disruptive since I expect to hear the CQs. 

I'm wondering if anyone has had that issue and what was done to resolve it. 

I can send the .MC files if you want. 

ctate243

Ria there are a number of the winkey emulator issues that have been resolved in the soon to be released beta.   FWIW if you would like to, send me your macros and I can test them.

ctate243

n6wm  -at - Largeradio -dot- org

Ria

Thanks. I'll see what the new release brings then I'll go from there. 

Steve Gw0gei

Glad this issue is getting sorted in the next release. I worked soab hp 24hr classic section in cqww cw and had the same not sending the f key or esm message issue - i also discover ed that pressing the escape key sorted the non keying issue and got the messages sending again. Hope its fully sorted in the release as i mainly use my 6300 for hf and vhf contesting. Steve gw0gei / gw9j

Kevin

Been a release or two since Tim's comment. Will the fix possibly make it to v1.10 if it doesn't show up in the beta?

ctate243

load the current beta released today and give it a try......

Kevin

Hi Chris. I did load the new beta and tried. That's why I came here to ask. Was it supposed to be included? If so, it still isn't working.

Kev

ctate243

What specifically is not working.  We have done some extensive testing of the WK emulator in Alpha, including major contest runs and it was holding up pretty darn well.. what are your expectations and what are your experiences?  I am wondering if you have s different issue.

Douglas Maxwell

Hi Chris,
I'm on the latest beta here and the original problem that I reported 7 months ago is still stopping me using the 6300 for contesting. Here is a copy of the original post:

"1) Cannot get SSDR Winkey to hold PTT on during transmit despite setting up a "P" port and assigning it in N1MM for slice A. I have to rely on breakin being selected and a delay of "300" @30wpm which means it's too slow to transition to rx for contesting."

Try turning your key speed down and listen to the rx in between sent words (according your delay setting). This is called break-in. Why is it happening when N1MM+ is telling the 6300 to be in constant tx whilst sending a message?

ctate243

I will try and duplicate what you are experiencing. At the office right now so cant do it this second.   In the meantime I would review the Keyer setup in the SO2R document particularly in regards to the timing setup, and see if you get the behavior that you think you should be seeing. I was under the impression this was fixed several revisions ago. 

ctate243

btw please download the lastest SO2R n1mm doc..  there have been changes that are important.