CW from other software (WinTest)

Steve-N5AC

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?

Barry N1EU

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.

Ken - NM9P

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?

Douglas Maxwell

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.

Barry N1EU

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

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.

Steve-N5AC

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.

Douglas Maxwell

This sounds great, looking forward to trying it out

Barry N1EU

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.