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.

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.

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?).

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 ;-)

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.

>>>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... ;)

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)

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.

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.

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.

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.

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.

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.

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.

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.