CW from other software (WinTest)

  • 3
  • Question
  • Updated 3 years ago
Hi Guys,
I need help to setting my Flex-6500 with Wintest for a CW operation, I using Wintest for a Contest, but I don't understand how-to set for using a Key of my flex.

Best 73 de IZ7AUH
Photo of Frank, IZ7AUH/AK1CQ

Frank, IZ7AUH/AK1CQ

  • 173 Posts
  • 6 Reply Likes

Posted 3 years ago

  • 3
Photo of Muhammad Alhashash

Muhammad Alhashash

  • 1 Post
  • 0 Reply Likes
still need the answer !
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1030 Posts
  • 1000 Reply Likes
Will Win-Test talk to a Winkeyer?  If so, you should be able to point it at the new Winkey emulation ports in CAT for v1.6 when it comes out.  If you do try this, I'd like to know how it works.  We've been looking for someone with experience with Win-Test to try this out.
Photo of Ken - NM9P

Ken - NM9P, Elmer

  • 4007 Posts
  • 1233 Reply Likes
Winkey Emulation ports?  Tell me more!
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1030 Posts
  • 1000 Reply Likes
You'll be able to point a logger at a port designed to look like a Winkeyer that will work through CWX.
Photo of James - K4JK

James - K4JK

  • 14 Posts
  • 1 Reply Like
Great news! Less clutter on the desk.
Photo of Douglas Maxwell

Douglas Maxwell

  • 88 Posts
  • 14 Reply Likes
This is great news, most cw contesters I know use Win-test and a Winkey (from K1EL or Microham). It will be great to get rid of more cabling...
Photo of Asher - K0AU

Asher - K0AU

  • 172 Posts
  • 21 Reply Likes
New WinKey emulation?  Looking forward to it.  Please, please, please test that the ESC key works to cancel an N1MM+ macro midstream.  Works with my external WinKeyer but does not work with the current CAT port emulation.
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1030 Posts
  • 1000 Reply Likes
Yes the ESC key will stop CW when you hit it.
Photo of Stan - VA7NF

Stan - VA7NF

  • 417 Posts
  • 95 Reply Likes
Thank-you Steve.  Been many years waiting to key the Flex without wires and keying transistors between it and the computer.  I'll be testing it as soon as possible (before the Canadian RAC contest this Saturday?).
Photo of Bob G   W1GLV

Bob G W1GLV

  • 661 Posts
  • 110 Reply Likes
Steve, does this mean that 1.6 is eminent?
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1030 Posts
  • 1000 Reply Likes
Yes we found one additional CW feature we need to add and then we are in the final testing.  We won't release until after the new year with a number of people out during the holidays.  Releasing a new product while your support team on vacation is generally a bad thing to do ;-)
Photo of EA4GLI - 8P9EH - Salvador

EA4GLI - 8P9EH - Salvador

  • 1752 Posts
  • 535 Reply Likes
Then on the other hand if you release during Christmas you will have a very large test base that will surely provide feedback by the time the workforce comes in January..... right? Can't wait to play with a new piece of software.
(Edited)
Photo of DrTeeth

DrTeeth

  • 1687 Posts
  • 387 Reply Likes
Excellent point, well made. I'd sign an NDA to get my hands on it just for fun.

@Steve. Now that you have let a little of the cat out of the bag, how abt going the whole hog and publish the changelog, hi hi?
(Edited)
Photo of Ken ve7kwa

Ken ve7kwa

  • 101 Posts
  • 32 Reply Likes
>>>Then on the other hand if you release during Christmas you will have a very large test base that will surely provide feedback by the time the workforce comes in January >>>     Sure... Kind of like leaving your kids with a chemistry set over the holidays... ;) 
Photo of Burt Fisher

Burt Fisher

  • 1067 Posts
  • 369 Reply Likes
eminent? Yes it is highly regarded.
Photo of Barry N1EU

Barry N1EU

  • 495 Posts
  • 121 Reply Likes
Steve, this is great news.  PLEASE support WinKey PTT functionality, so that transmit is maintained for the duration of a cw message transmission.  And please do this even if Breakin is enabled in SSDR.  (that's the way it works on all my other radios)

 (from N1MM Logger+ Winkey setup)

Thanks & 73,
Barry N1EU
(Edited)
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1030 Posts
  • 1000 Reply Likes
Barry, we've talked about your request internally and we're not certain we understand what you're trying to accomplish.  Can you tell me the end result of how this setting is different than not having it?  We're trying to figure out how N1MM, Winkeyer and a radio react to these settings.
Photo of Barry N1EU

Barry N1EU

  • 495 Posts
  • 121 Reply Likes
A real hardware Winkeyer has a PTT output.  N1MM will assert (i.e., hold down) Winkey PTT for the duration of a keyed cw message.  On the Orion, K3 Omni VI+ and ANAN-100D (all my other radios), this PTT connection will hold the radio in transmit mode (MOX) for the duration of the keyed cw message whether or not the radio has breakin or VOX enabled.  This allows you to use your paddle for breakin/VOX keying alongside N1MM/Winkey keying the radio in PTT/MOX.  The Flex 6K doesn't provide this currently - if breakin is enabled, the 6K isn't reliably held in transmit mode for the duration of the PTT/message - there are breaks where the 6K goes into receive.  We want to keep the receiver muted for the duration of the keyed cw message and still allow occasional use of the paddles in breakin.

(fwiw, the Orion goes the full nine yards and user settings are provided to treat PTT in CW as key, MOX, or ignore).

Barry N1EU
(Edited)
Photo of Barry N1EU

Barry N1EU

  • 495 Posts
  • 121 Reply Likes
We've been talking only about cw.  But in terms of implementing virtual WinKey support, it's also important to support PTT for ssb contesters - they typically use the hardware Winkeyer PTT output cabled to their rig's PTT input for phone contests. So, the WinKey is functional in phone contests as well as cw contests.
(Edited)
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1030 Posts
  • 1000 Reply Likes
Barry, what I believe you are talking about it the PTT hang delay which we call simply "delay" on the CW control panel in SmartSDR.  We have not implemented command 0x04 of the Winkeyer protocol, but you can set the same thing in SmartSDR by adjusting the delay slider.  It should behave the same way.  Does this address your concern?  

So with SmartSDR you do not need a physical Winkeyer box and so there is no hardware, no "PIN 5" in the mix.  All you would have in play is N1MM Logger+, SmartSDR and the radio.  

Incidentally, if you use Maestro instead of SmartSDR, we use a genuine Winkeyer 3 in Maestro and we route this to the radio so that if N1MM makes this adjustment in the Winkeyer 3 in Maestro, it will do exactly what you are asking for.
Photo of Douglas Maxwell

Douglas Maxwell

  • 88 Posts
  • 14 Reply Likes
Will the winkey emulation functionality be in firmware or software? Hopefully it won't be subject to delays from it being done on the embedded processor.
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1030 Posts
  • 1000 Reply Likes
What kind of delay are you concerned about?
Photo of Douglas Maxwell

Douglas Maxwell

  • 88 Posts
  • 14 Reply Likes
Cw requires a regular time constant to correctly form di, dah elements and letter, word spaces. It also needs to be responsive to the user without unexplained delays to tx\rx. A general purpose processor like the DaVinci with an OS rather than an RTOS may mess this up dependent on the profile of tasks it is running at the time. Paris has 50 time constants within it, so at 30wpm this makes 1500 time constants, so 60secs/1500=40ms per time constant. Listening to Morse that is generated from a variable time constant is unpleasant and doesn't decode well on other PCs. The winkey does this well as it is isolated from the PC in terms of profile load.
Photo of Barry N1EU

Barry N1EU

  • 495 Posts
  • 121 Reply Likes
NO Steve, it's NOT delay.  It's assertion of transmit for the precise duration of the cw message via the PTT signal generated by WinKey.  When the last element is keyed, PTT turns off precisely at the same time.  Delay is a poor work-around.  You use delay (150msec?) to keep transmit asserted between characters and you end up with an unwanted delay at the end of xmsn.  Delay is what cw users are forced to use now.  

I uploaded a video showing the current behavior of the 6500 just to make sure we're all on the same page: https://youtu.be/CKSceQT2m-o

With breakin disabled, the receiver stays muted by the Winkey PTT throughout the message.  With break enabled, the receiver unmutes frequently during the message as SSDR ignores PTT.  The Orion, K3, and ANAN all stay muted throughout the message, even with breakin enabled.
(Edited)
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1030 Posts
  • 1000 Reply Likes
We have two separate conversations in one comment thread so let me address each individually.  

Douglas: it's all about specs and what you think is great CW.  When you build a CW keyer, you can either do it in "hardware" or "software."  If I built what I would call a hardware keyer, I might build it with one-shots that have specific time constants and always start when the key is depressed and released after a specific interval of time programmed in hardware.  But even if I used a one-shot, it would probably have jitter/latency caused by temperature differences in the RC network programming it.  If I built a software keyer in an FPGA and asked a group of 100 engineers if I had just built a hardware of software keyer, I would start a riot!  Even if I use a CPLD or an FPGA, I have to decide at what clock rate I will run the part which causes jitter/latency of at least the clock cycle.  Same goes for a microprocessor.  It's probably no secret that the Winkeyer uses a microprocessor.  A microprocessor keyer is a software keyer.  It's jitter could be no better than probably 20x it's clock speed and this is pretty optimistic. Take a typical processor running at 30MHz or so and you get something like 1us jitter at best case.  Would 1us be acceptable jitter or latency for a keyer?  I would argue that it is more than sufficient, but I've never measured the jitter in a Winkeyer.  I do know that a large segment of the population as judges the Winkeyer as a "gold standard" so when we went to put a keyer in Maestro, we just put in a Winkeyer.

So we get to the question of: what can you hear and what sounds good?  When you depress the paddles on a typical iambic keyer, they don't make instant contact.  There is typically ringing as it struggles to make contact and this lasts something like 2-3ms.  I've seen it last for 5ms (three of us wrote the keyer in the 6000 and it has evolved over a 6-year span and I've seen a lot of key closures in that time).  This says that I could build a microsecond-accurate keyer, but the input stimulus is no better than a millisecond or two so that is probably overkill.  How close can you judge the speed of a dit?  If I send one at 33WPM can you tell me that it is 33?  Can you tell the difference in a single dit at 30 vs 33WPM?  That's a 4ms difference.  Could you hear it?  I think a fair number of seasoned CW ops could tell me that CW they hear at 33WPM is "a little faster than 30WPM."  Maybe 75% could.  Just a guess.  This all tells me that folks threshold is somewhere in the 3-5ms range for a seasoned operator.  I believe that CW with repetitive jitter in the 5ms range would be noticeable and would sound "wrong."  By the time you get to the 1-2ms range, I don't know anyone that can tell.

The DaVinci is a GPP, but it doesn't run at 10-30MHz.  It runs in excess of 1GHz.  This is a 30-40x advantage over a small microprocessor like what is used in a Winkeyer.  We could theoretically build a keyer that has substantially smaller jitter and latency.  We could probably start a specmanship war in keyers and suggest that our latency is "15dB better than a Winkeyer" -- take the log(40).  This is silly, of course, and we're back to what works well for the CW operator.  

We also have the keying envelope to worry about -- how does the radio do this?  You could have an extremely accurate (1us) keyer fed into a triangle-wave ramp generator for RF generation and it would produce RF artifacts that are undesirable.

In the end, what we've built is a keyer that runs in a preemptive multitasking operating system.  We decided the service interval for the keyer, set this in the OS and then we ensure that we "make" the service interval.  If you do this, the keyer is guaranteed to have the jitter and latency specifications you defined as an engineer.  This is the way it works.  This is not Windows where any misbehaved application or driver can cause an issue -- this is linux with real-time patches that behaves as we tell it to.  We key the RF envelope in an FPGA and we use a cycle-accurate transcendental function designed to spread the frequency-domain artifacts of a rising waveform for minimal close-in interference.  If you look at our keying waveform on an 1GHz oscilloscope, I dare say it is "beautiful" and a work of engineering art (there are pictures of this somewhere in the community).

After saying all of this, I'm back to what I say to every CW operator -- try it and see if you like it.  If you don't you're always welcome to use a Winkeyer.  It's a good piece of hardware.  One of our goals at FlexRadio is to simplify what's required to operate.  We'd like for you to only have to buy a minimal set of pieces to build a glorious station.  Winkeyer emulation/integration is one more step in this direction.

Barry: I'm still lost.  In your video, you have the radio set to QSK (delay = 0).  Most radios I know have this selection.  If you set the delay to your dit length (in your case here it would be 40ms), you will not hear any inter-symbol receiver noise.  After the last element is sent, there will be a 40ms delay before PTT is released and you hear the receiver again.  You WILL hear inter-word receiver noise.  If you want to eliminate this, you need to set the delay above the duration between words.  You will also have to wait for this to time-out when you compete a transmission.  

If you want the transmitter to unkey right as you finish your last element, I have to know when this is --how do I know whether you are sending another element?  For example, if you want no receiver noise between dits and you set the delay at 40ms, there is 40ms after the last element you sent where I'm in non-causal-confusion-land because I don't know whether another element is forthcoming.  Do I stay keyed or unkey in this time?  If I unkey, you will hear receiver noise.  If I get the next element in that time and we are back at QSK and you're upset because I gave you receiver noise.  If I stay keyed and you don't send any more, you're upset that I'm left the transmitter keyed for 40ms when you were done.  How do I know?  We often joke about needing non-causal software in the lab, but none of us has written any yet.

I *could* look-ahead in the element buffer and if it is empty, ignore the delay and immediately unkey.  My belief is that this will make many operators feel "rushed."  I've found that the sound change in the unkeying helps operators pace their conversation (rag chewing implied here) and they get used to sending with the cadence.  Altering this behavior will "rush" operators.  It would make the keyer feel less forgiving, in my opinion.  But I'm more of a casual CW operator and if many believe this is what we should do, it's something we could look into.  Do I understand the problem or did I miss it again?
Photo of Barry N1EU

Barry N1EU

  • 495 Posts
  • 121 Reply Likes
Steve, I think you're over-complicating the issue.  Going back to the start, all I'm asking for is that you support PTT MOX in cw mode when breakin is enabled.  You already support this when breakin is disabled.  All I'm asking for is to not ignore PTT when breakin is enabled in cw mode.  Still allow PTT to switch the 6K in and out of transmit mode (and mute the rx), regardless of the key state.  The other radios I mentioned all do this.
(Edited)
Photo of Ken - NM9P

Ken - NM9P, Elmer

  • 4007 Posts
  • 1233 Reply Likes
Can I take a stab at rephrasing the issue?
Leave the "internal keyer" alone so that it functions as usual, complete with delays. But allow an external program like Winkey, or the Winkey simulator in SSDR, to assert PTT to keep the rig in transmit mode when sending a preset message, but return it to receive mode immediately, without regard to the display setting, when the message is finished.

Is this what you mean, Barry?
Photo of Douglas Maxwell

Douglas Maxwell

  • 88 Posts
  • 14 Reply Likes
The winkey is probably a bare metal implementation (without an OS) with limited functionality which will enable it to have predicable timing. The Davinci runs Linux and could be interrupted for any number of reasons. This issue is less about hardware clock jitter and clock speeds and more about availability and immediacy when morse generation is required.
Photo of Barry N1EU

Barry N1EU

  • 495 Posts
  • 121 Reply Likes
The edits to my last message got posted and then disappeared - this is very disconcerting.

Please see the video I posted clearly showing the issue: https://www.youtube.com/watch?v=CKSceQT2m-o

The 6500 is being keyed from N1MM and WinKey with PTT connected.  Unfortunately the sidetone audio is not heard.  A CQ message is transmitted 0:02 and 0:09 with Breakin disabled and the 6500 correctly stays in transmit mode throughout with rx muted.  The CQ message is transmitted at 0:18 and 0:25 with Breakin enabled and you can hear the breaks in the message where the Flex is ignoring PTT and the rx momentarily unmutes.  Then Breakin is disabled again and CQ message transmitted at 0:33

If this were a video of the non-Flex radios, the receiver would stay muted throughout the message xmsn.

Yes Ken, you got it.
(Edited)
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1030 Posts
  • 1000 Reply Likes
Barry/Ken: OK I think I have it now.  Let me check this and get back to you.

Douglas: What I was trying to communicate is that we are using Linux with RT patches and it does not get interrupted.  We measure this and ensure that it operates without interruption.  In this case, everything is under our control.
Photo of Douglas Maxwell

Douglas Maxwell

  • 88 Posts
  • 14 Reply Likes
This sounds great, looking forward to trying it out
Photo of Barry N1EU

Barry N1EU

  • 495 Posts
  • 121 Reply Likes
A follow-up comment on the desire for rx muting during cw message xmsn.  Unfortunately, in its current state, the Flex 6K doesn't always make the smoothest audio transitions when changing from tx to rx.  Comparing to a K3 for example, the K3 is silky smooth swish-swish while the 6500 occasionally is pop-pop.  It might be an issue of waveform transition smoothing (or lack of it) in the Flex 6K dsp firmware.  Flex has accomplished so much in providing FAST QSK (or pseudo-QSK because of latency) but needs to go a bit further for the 6K to be considered a truly great CW radio.
Photo of Mal G3PDH

Mal G3PDH

  • 48 Posts
  • 2 Reply Likes
Further to using SSDR/6500 with N1MM+,  Whilst using the revised macros in N1MM to operate via CWX I find the following issues. Firstly, in RUN/ESM mode the cursor will not automatically jump from the call sign entry box to the receive number field when transmitting the exchange. Secondly, despite N1MM being set for cut numbers it will not send cut numbers in the EXCH. Does anyone have an answer or experience the same?  I am a new 6500 user and just trying to set up for upcoming UK contests.
Photo of W7NGA

W7NGA

  • 405 Posts
  • 166 Reply Likes
Oh dear ... I am feeling like such the dinosaur. I do not contest so I am trying to understand the functionality of the Winkeyer. From the YouTube videos it appears to be just a nice keyer with memory functions, and a USB port that supports a protocol to transfer call sign information to an auto-logging program. Is this correct? How do you capture the station's call and how do you notify the logging program to log it? Escape sequences?

All I have ever used is the ARRL logbook and a #2 pencil 

Clueless but interested ... because apparently the next SSDR release will facilitate these requirements in some fashion.

W7NGA  dan
(Edited)
Photo of Barry N1EU

Barry N1EU

  • 495 Posts
  • 121 Reply Likes
Dan, it has nothing to do with transferring call sign information to a logging program???

It functions as a traditional stand-alone iambic keyer when you attach a paddle to it.  When you connect it to a PC via the USB port, you can control a slew of keying parameters and you can send characters/messages from the PC to the WinKeyer for output on either of 2 keying lines (some guys contest with two radios).  It also has 2 PTT lines to connect to either of 2 radios.

Among other things, it was an important innovation that solved the problem of occasional stuttering exhibited by LPT/COM port keying interfaces.

Barry N1EU
Photo of W7NGA

W7NGA

  • 405 Posts
  • 166 Reply Likes
Barry, thanks! How does the callsign information migrate to the logging program? You are blazing away as you were in your video, and yet, somehow you were logging these contacts (transparent to me)?
Photo of Barry N1EU

Barry N1EU

  • 495 Posts
  • 121 Reply Likes
What you don't see is my fingers on the PC keyboard.  I hit F1 -> rig keys CQ message; as caller responds, I type in his callsign; I hit <enter> and rig keys his callsign (that I just typed), "599 NY"; he sends his exchange, I type his state (or serial number if he was dx); I hit <enter> and the QSO is logged and the rig keys CQ message and we start all over again.
(Edited)
Photo of W7NGA

W7NGA

  • 405 Posts
  • 166 Reply Likes
ahhh ... the light turns on. Thanks Barry!