CW problems continue for 3.4.24

Stan VA7NF

Field Day clearly showed the poor quality of CW forming. The environment is:

• Flex 6600 with active N1MM programmed key selections - All generated CW strings
• Headphones plugged into the 6600 headset so transmitted signal can be heard
• Version 3.4.24
• No key contact bounce, unless software latency "bounce"
• I have built electronic keyers since the early '60s and know the proper sound of dot/dash forming and weight adjustments. Every character element was mis-timed with the leading edge delayed for part of the clock cycle, and then not evenly across all generated elements. Very rough sounding result
• On occasion entire letters are missing leaving a timing gap where the character should be sent. When I heard that I sent my call sign again so the contact could catch the correct character.

K1ESE

Yes, that's CW on the Flex. There are some workarounds. They don't always work. You can restart the radio. You can adjust Delay settings, some say more and some say less. You can use the internal keyer or the SmartCAT N1MM virtual keyer. You can use an external keyer. And so on...

The CW keying is not as good or reliable as the cheapest radio offered by competitors.

I fell in love with the panadapter. I've owned a Flex for 8 years. My CW-perfect K3 sits in a closet. Like the guy who fell in love with a ****, I keep hoping things will change. Each upgrade brings disappointment.

If you want the latest features, you upgrade. If you want decent CW you go back to firmware 2.4.10. But that is not without peril. You lose SmartLink. If you install SmartCAT 2.4.10 you cannot go back to newer versions without reinstalling Windows. It's not worth the risk.

Anyone who says the Flex CW is fine either doesn't operate CW much or is fooling themselves. So like the rest of the active CW operators, you just keep hoping.

73 K1ESE

Stan VA7NF

Thanks for your comment. My own 6700 has held up very well on CW over the last decade but this club station 6600 was of the worst I've ever heard.

FRS - Many of our complaints are really requests of "How can we help fix this problem?" Questions from 1/2 century of software debugging are:

Have you (FRS) already determined the failing component area? Which side of the API introduces the erratic behavior? Does delay settings balance out any latency variations? Is the internal CW element generating clock (speed) stable or does networking latency/variance affect the clock rate? Why is there a RF out delay between element clock dot/dash start? What part of the RF chain is being delayed? Is there a noticeable difference between driving the hardware key closure, or auxiliary key closure, or API signal? etc.

Any suggestions/requests on how we can gather information to help out?

Lasse SM5GLC

Agree, the panafall made me fall in love with the Flex. It still is excellent, and makes DX hunting a joy, but for contest and ragchew on CW it really show its ugly side!

Have been lusting for the dual SCU 6600 but will not happen unless they get their act together and fix the CW! I can live with 2.4.10, but it still have its warts, and would be nice to use the new features that the newer releases offer, but every time I try the latest, I have to fall back to 2.4.10. Features are pretty useless if it cannot transmit proper CW (Well 2.4.10 do fail on CW from time to time too).

It would be interesting to be a fly on the wall at Flex s/w meetings discussing these items.... They cannot simply just igore this. Such a pity as they are so close to have the best product on the market.....

Troy NW1B

My operation with v3.4.23 on CW makes me sound like a Novice. Any method of keying gives unpredictable results. Here is to hoping that V4 will remedy this major issue.

Barry GM3YEH

Another voice expressing continuing disappointment with CW performance. For the 2023 IOTA contest we had a 6400 and a 6500 running. Both on SSDR 3.4.23. The 6400 behaved fine on CW but the 6500 was very erratic (again!). When I raised a ticket about the CW issue a while back the reply was to re-boot to clear the problem and the ticket was closed without further dialogue. Re-booting does not solve the problem. I have to use an old Icom rig for local CW ragchews so that it doesn't sound as if I've lost my ability to send CW...after 53 years of practice.

Barry GM3YEH.

Russ Ravella

Just wanted to check to see if anyone has seen this problem after upgrading to 3.5.8 ? I have reason to believe some things were addressed in the upgrade that could have helped but I saw a report yesterday that indicated someone was still seeing the problem.

Thanks, Russ KR6W

Jim G3YLA

Hello CW Flexers,

The ongoing drop out of TX output, despite the internal keyer continuing to generate sidetone, has affected quite a number of CW users and so far very little progress despite new SSDR releases or roll back to previous versions. As a result of some of us (G3PDH, G3LDI) recently recreating the fault and capturing possibly useful pointers, I have now also managed to capture a drop out running into a dummy load with an intermittent series of dots. It kinda feels like it may be the leading edge of the TXing that triggers it, but not sure.

Of course, we all know that dropping TX will reinstate the power output, but this may be after quite a lot of material has been missed. Running with 500ms delay is a work-around, but generally far too long for fast break-in rag-chewing CW or contesting. Reducing to, say, 100-200ms gives a higher incidence of drop out faults.

In normal condition, if you leave the mouse pointer hovering over the MOX button it shows the standard tool tip 'Key and unkey the transmitter. However, in fault state the message changes to 'TX Inhibit: Transmit Slice not selected' as shown in photo.

Hope this helps shorten the long journey we CW folk are on... 73 de Jim G3YLA

Steve...

Does the use of an external WinKeyer mitigate these problems? I'm guessing that most or perhaps all of these problems are associated with the internal WinKeyer emulator.

Steve...K3SW...