1.7.30/32 Winkeyer sending wrong morse!

Phil M0VSE

I worked my first CW contest with the Maestro/6500 and N1MM+ tonight and found myself having to repeat my callsign many times and lots of people came back with 2E0DSK (not 2E0DSQ) I assumed that it was simply QSB/QRM but one of our club members recorded our QSO and although the sidetone was definitely correct, his (very clear) recording sounds very much like 2E0DSK! There is also a definite pause before the first 'dah' of K so that I guess is what is making it a K instead of a Q. It doesn't happen every time but it was enough to be a problem.

I have uploaded the audio to my web server so anybody that's interested can hear.

I'm not sure what to do for the best, maybe go back to my external Winkeyer until this is resolved as it isn't fair on other entrants who are going to drop points because I am sending the wrong callsign!

www.2e0dsq.uk/images/2E0DSK_de_G4SGX_RSGB80MCC_CW_20160519_201959Z_3.5MHz.mp3

73 Phil 2E0DSQ

ctate243

having this recording is very useful to the developers while troubleshooting.  assuming you were using the flex 6000 winkey emulation in SSDR CAT? 

your short term solution is sound while some of these bugs get fixed.  It's what I did.  This stuff will get dialed in pretty soon but a hardware winkeyer in the interim makes sense.

Simon Lewis

listening to the audio its sounded like 2E0DS ..then a gap and then a K

what in your message memories .. is the K coming from N1MM and your missing a character in the message memory?

I've not had a problem with N1MM and SSDR around CW memories

It might be something simple

Cheers

Simon

Phil M0VSE

It was my F4 callsign macro that I was sending and that is definitely correct as most times people come back with the correct callsign so I can only assume it is intermittent. I also watch the TX stream at the bottom of the ALE window and N1MM+ thought it was sending 2E0DSQ! 

Simon Lewis

Phil M0VSE

Yes I will try that Simon thanks. The macros are just standard N1MM+ macro files as I am using the Flex Winkeyer CAT port so there shouldn't be anything special to setup? As far as Comms delay, I can't see how as it is simply sending and ASCII string to the com port. My macros don't send a K so my guess is it is the Q but missing the first dah!

Simon Lewis

Phil M0VSE

No i'm using the Flex built in Winkeyer emulation that has been available since 1.6.... I might revert to the CWX method though as that 'used' to work fine!

Simon Lewis

ahh ok - not used the 'new' method - not recall seeing any issues of it dropping chars .. but can't say I tried it yet

Barry N1EU

Your external Winkeyer, definitely.

Phil M0VSE

Just to confirm this, I tried the test that Simon suggested and it seems to have a problem every other macro. The WinKeyer support in N1MM+ is pretty robust so I suspect it is something specific to the Flex implementation although I can't get DM780 to exhibit the same problem? Here is a video. You will notice that alonw with sending 2E0DSK alternately, it also sends 2E0DMQ at the end!

https://www.youtube.com/watch?v=5_rPqo0BZ4g

Phil M0VSE

I just did a similar test with DM780 (HRD 6.3) and it was similarly intermittent although it was pretty random what would be missing!

DH2ID

Phil, look at my comments here and on the HRD forum on that problem:

https://community.flexradio.com/flexradio/topics/winkeyer-and-hrd-dm780-character-spacing-character-...

73, Alex - DH2ID

Phil M0VSE

Yes I saw your comment Alex, I will try it and report whether your fix also works for n1mm+ but dm780/n1mm+ work with every other Winkeyer so I suspect that the problem is still a flex one?

DH2ID

Phil, as both CWType and Log4OM work flawlesslay with the SSDR software
winkeyer, I am sure that it's not a Flex but a HRD problem. If you look at the
HRD forum, you'll find a lot of posts (lots of mine, also ;-)) about winkeyer
bugs, although they were mosty hardware ones.

The HRD DM780 program works very well with both of my hardware
winkeyers: The microHAM DigiKeyer II, which uses the K1EL chip
http://www.microham.com/contents/en-us/d164_DKII.html
and the CW Keyer by G4ZLP
http://www.g4zlp.co.uk/unified/DigiMaster_CW.htm

Both of these keyers are just great and permit the use of a paddle
to seamlessly change from automatic CQing to a chat.

Phil M0VSE

Maybe I have just been unlucky as the only two programs that I routinely use for CW, N1MM and DM380 both exhibit this problem? My G4ZLP keyer worth flawlessly with both so I have gone back to this while the issue is resolved. I wonder if log4om/cwtype perform a more comprehensive initialisation than DM380/N1MM+ which would explain why your fix works? I may have a play with a serial port sniffer and try to compare them. 73 Phil

Phil M0VSE

I would still say that it 'is' a flex problem as the issue doesn't occur with a real Winkeyer, only with the 6x00 emulation of one. This indicates that there are operational differences between the reference hardware implementation and flexes software emulation even if it is possible to work around the problem by using other software first. 73 Phil

DH2ID

Ok, Phil, you're right there: it's a combined Flex and HRD problem.
That won't be easy to solve :-(

Barry N1EU

It's easy to solve when there's a hardware WinKeyer sitting on Phil's table.

Stan VA7NF

While Flex has the WinKeyer code open - Please see if N1MM+ CTL+T (Tune) can be activated.  Such a common function doesn't work - apparently by design.

ctate243

I document this Stan and see if its something we can implement

ctate243

All there is definitely some bugs and known issues that are currently in remediation with the SSDR winkeyer emulation. Developers are working through a number or these issues now and hopefully will nail them down.   Reviewing a number of the posts in this thread shows lots of them tied into the same issues the team is aware of.   Having a solid and properly working winkey emulation is a top need for contesters as well as all cw operators and its being treated with high priority.

hang in there..   technicians are working on the problem.  :-).

km9r.mike

Real quick Chris. The only issue I have with the winkey emulation and n1mm+ is the buffer feature seems to need more attention to detail. In other words, when I type in the prefix of a call or there a bouts into n1mm+ entry field then select enter (enter sends message enabled) then type in the remainder of the call, the call is not sent smoothly. It is as if it emulation skips a beat or stutters, however, the remainder of the exchange is sent perfectly. If my typing skills were better and I could quickly type in the full call and hit enter then the call along with the exchange is sent flawlessly. This only occurs when I am utilizing the buffer feature. Just wanted to make sure developers are aware.

Varistor

The more likely culprit is the winkey emulator. N1MM+ with a real hardware keyer (eg microHam MK2R+ and DigiKeyer) works flawlessly.

ctate243

Yes this sounds like a defect in the Winkey emulator and is similar to some others I have seen.  Wintest treats cw differently than N1MM and it stutters as well.   I will test for this to confirm during cqwpx this weekend to verify and ensure its listed as a known reproducible defect.