cw intermittent during sending

BG5ILX

2023_09_15_15_59_IMG_2456 (1).rar

CW transmission will be intermittent, video file is attached. Thank you.

Mark Aaker K6UFO

Whenever I have CW sending issues, I do a shutdown, wait, and restart of the radio. That almost always solves the problem for a day or two.

Mark K6UFO

fpmacko

Concur. More specifically, I always cycle DC power and not just a shutdown from the front panel.

73…. Frank / WA3NHK

BG5ILX

I tried disconnecting the DC power supply and then switching it back on. After restoring to factory settings, the problem remains. The same is true for win10 and win11 system tests, which can rule out computer problems. I have tested almost all versions of V3 and the problem is the same.

fpmacko

Hmmm. Another thought…when you cycled DC power did you pause at least 30 seconds before turning it back on? I always do that because flex says that a background processor can still be running if the DC doesn’t decay sufficiently before you restore power. Otherwise, you may want to submit a support request. This is a common problem that’’s usually resolved by a power cycle. But apparently not in this case.

73…Frank / WA3NHK

fpmacko

Yet another thought….Instead of using the internal keyer try using a straight key or an external keyer if you have one. See if the behavior changes.

BG5ILX

I tried disconnecting the DC power supply and then switching it back on. After restoring to factory settings, the problem remains. The same is true for win10 and win11 system tests, which can rule out computer problems. I have tested almost all versions of V3 and the problem is the same.

BG5ILX

Inexplicably, I feel normal again, and I'm also ****.😄

fpmacko

Great. Did you do something to resolve it or did the problem go away on its own?

k0oks

Are you running 3.5.9 ? I believe this improves it, though it is not mentioned in the release notes; so it could just be the procedure below.

Also, here is the procedure I have found that resolves any cutout issues I was having:

Shut down SmartSDR if you are using it remotely.

Power down the Flex with the button on the radio.

Wait at least 30 sec AFTER the lights go out on the Flex.

Turn off the 12V supply.

Wait at least 30 sec after anything you have connected to the 12V supply goes off.

Turn on the 12V supply.

Wait at least 2 mins.

Turn on the Flex.

Wait for all the startup screens and loading screens. Do NOT log in to the radio remotely, and do not touch the front screen on the Maestro until...

Wait at least 2 mins AFTER all the changes happen on the screen (so at least 2 mins after you get to the final screen before you chose to operate OR connect from a computer).

Connect with SmartSDR or click Operate on the Maestro and enjoy.

Slow procedure, I know, but it does seem to get rid of any of the cutouts or ticking on my end. I think the most important "pause" is actually waiting for the radio to "settle" AFTER you power it on, but before you connect or operate from the Maestro front panel.

k0oks

So the procedure I described above does seem to help with many problems (at least with SSB and AM), but I am still sometimes seeing these CW dropouts, where a dit or dash is not sent.

I wonder if there isn't a software bug involving a race condition between the Delay (hang time) in the CW settings and the instant the RF output is on (to send a dit or dash). The persisting dropouts on CW seem to be related to the Delay setting. Perhaps it is compounded by the TX delay setting for amplifiers.

I find if I increase Delay to a fairly large number where I basically go to semi-breakin between words then I am not getting the issue. I am curious what other with the issue have their Delay setting set to, and also if they are using a TX Delay (for an amp-- even if the amp is off).

I am using a Straight Key, and sending slowly (new to CW).

k0oks

OK. This most definitely IS a bug with regard to the TX Delay and the Delay (hang time) in the CW settings.

Very easy to test. Set your keyer set up to just send dits using the built in keyer (i.e. Iambic rather than straight key)

Set the TX Delay to 0 and all the dits get through no matter what the cw Delay (this is the Delay Slider in the cw interface, not the TX Delay) is set to.

To get it to fail every time I can set the TX Delay to 30 and then set the cw Delay (hang time) to 29. Set the Speed to 19. Hold down the key to send a string of Dits. You will hear the dits in the sidetone, but most are not transmitted. The power meter shows a couple of dits and then no output, even though the sidetone continues to sound correct. Only an occasional dit or two gets through. The waterfall also shows when the dropouts occur.

Can someone at Flex please forward this to the QA/software development department? This is your bug that you need to analyze and fix right here. I have provided a reproducible scenario that should make analysis easy.

I hear nothing but negativity towards Flex from CW operators. They keep telling me that the "filters are too slow and the dits and dashes get dropped." I believe this is the bug-- not the filters, but a simple oversight on how the TX Delay interacts with the cw Delay (which really should be called hang time, but I get that it is based on the old Vox Delay).

Obviously, this could be in some ways called a type of operator error, because you can't expect the radio to send faster that the TX Delay is configured. Increasing the cw Delay (hang time) setting can get around the issue, but it alters the CW experience in terms of break in. Setting the delay to zero can also help. There will always be a practical limit to how fast you can send with a particular TX Delay. It would be nice if the sidetone could be muted in this case so that the operator would know that they needed to adjust their settings to get the code out at the desired speed.

However, the radio could simply truncate the beginning of the dits and dashes sent during the TX Delay period. Right now if the sending of a dit or dash is initiated during the delay the radio doesn't transmit until the next key up / key down cycle. I see this with a straight key, even sending very slow code. If I happen to make along dash at just the wrong time it does not get sent at all, where as with any other radio it would get sent after the TX Delay, but would just be that much shorter in duration.

If Flex wants to just say this is operator error then please at least update the manual and create a FAQ entry to reflect these suggestions below, as otherwise you will continue to get support tickets and product returns (I personally know two people who are CW ops who returned their 6600M within a week due to it being what they perceived as useless on CW).

So for now if you are having troubles with CW dropouts set your TX Delay (Radio Setup->TX tab) as low as you can for your amp, etc. Then either set the cw Delay (hang time-- in the UI above the CW Speed setting, in the same panel with the ALC and Sidetone settings, etc.)) to 0, or (I think preferably) to a value higher than the TX Delay (ideally 2.5x or more).

Please report back if this helps anyone or any other observations. Let's get the set the naysayers straight on CW on the Flex. It could be a really great platform for it. Thanks!

KD0RC

WOW... good catch. I have not been able to reproduce this issue reliably on my 6400, but did discover some time ago that a higher Delay value leads to the issue not happening, or happening so rarely that I don't notice it. I also seldom operate at exactly 19 WPM.

Here is another data point: With TX Delay set to 30, Delay set to 29, 30 or 31 and Speed set to 19, almost no code elements make it through. While sending any combination of dots and dashes, the Tune and MOX buttons gray-out in time to the sending. This happens with a paddle plugged in to the Key jack or an external keyer using the ACC jack (pins 4 and 5). It does not happen when using CWX.

If you move TX Delay a bit or Delay a bit then all is well again. So far, I can only get this to happen at exactly 19 WPM.

My Flex command "sniffer" gives me this at 19 WPM (note the invalid handles):

S4627FE6D|interlock acc_txreq_enable=0 rca_txreq_enable=0 acc_tx_enabled=0 tx1_enabled=1 tx2_enabled=0 tx3_enabled=0 tx_delay=30 acc_tx_delay=0 tx1_delay=0 tx2_delay=0 tx3_delay=0 acc_txreq_polarity=0 rca_txreq_polarity=0 timeout=600000
S0|interlock tx_client_handle=0x00000000 state=PTT_REQUESTED reason= source=HWCW tx_allowed=0 amplifier=
S0|interlock tx_client_handle=0x00000000 state=TRANSMITTING reason= source=HWCW tx_allowed=0 amplifier=

S4627FE6D|interlock acc_txreq_enable=0 rca_txreq_enable=0 acc_tx_enabled=0 tx1_enabled=1 tx2_enabled=0 tx3_enabled=0 tx_delay=30 acc_tx_delay=0 tx1_delay=0 tx2_delay=0 tx3_delay=0 acc_txreq_polarity=0 rca_txreq_polarity=0 timeout=600000

S0|interlock tx_client_handle=0x00000000 state=UNKEY_REQUESTED reason= source= tx_allowed=1 amplifier=
S0|interlock tx_client_handle=0x00000000 state=READY reason= source= tx_allowed=1 amplifier=
S4627FE6D|interlock acc_txreq_enable=0 rca_txreq_enable=0 acc_tx_enabled=0 tx1_enabled=1 tx2_enabled=0 tx3_enabled=0 tx_delay=30 acc_tx_delay=0 tx1_delay=0 tx2_delay=0 tx3_delay=0 acc_txreq_polarity=0 rca_txreq_polarity=0 timeout=600000

S0|interlock tx_client_handle=0x00000000 state=PTT_REQUESTED reason= source=HWCW tx_allowed=0 amplifier=

S0|interlock tx_client_handle=0x00000000 state=TRANSMITTING reason= source=HWCW tx_allowed=0 amplifier=

S0|interlock tx_client_handle=0x00000000 state=UNKEY_REQUESTED reason= source= tx_allowed=1 amplifier=

S0|interlock tx_client_handle=0x00000000 state=READY reason= source= tx_allowed=1 amplifier=

S0|interlock tx_client_handle=0x00000000 state=READY reason= source= tx_allowed=1 amplifier=

At 20 WPM I get this:

S58CDA786|cwx wpm=20 break_in_delay=30 qsk_enabled=1

S4627FE6D|interlock acc_txreq_enable=0 rca_txreq_enable=0 acc_tx_enabled=0 tx1_enabled=1 tx2_enabled=0 tx3_enabled=0 tx_delay=30 acc_tx_delay=0 tx1_delay=0 tx2_delay=0 tx3_delay=0 acc_txreq_polarity=0 rca_txreq_polarity=0 timeout=600000

S4627FE6D|interlock acc_txreq_enable=0 rca_txreq_enable=0 acc_tx_enabled=0 tx1_enabled=1 tx2_enabled=0 tx3_enabled=0 tx_delay=30 acc_tx_delay=0 tx1_delay=0 tx2_delay=0 tx3_delay=0 acc_txreq_polarity=0 rca_txreq_polarity=0 timeout=600000

S0|interlock tx_client_handle=0x4627FE6D state=PTT_REQUESTED reason= source=HWCW tx_allowed=1 amplifier=

S0|interlock tx_client_handle=0x4627FE6D state=TRANSMITTING reason= source=HWCW tx_allowed=1 amplifier=

S0|interlock tx_client_handle=0x4627FE6D state=TRANSMITTING reason= source=HWCW tx_allowed=1 amplifier=

S0|interlock tx_client_handle=0x4627FE6D state=TRANSMITTING reason= source=HWCW tx_allowed=1 amplifier=

S0|interlock tx_client_handle=0x4627FE6D state=TRANSMITTING reason= source=HWCW tx_allowed=1 amplifier=

S0|interlock tx_client_handle=0x4627FE6D state=TRANSMITTING reason= source=HWCW tx_allowed=1 amplifier=

S0|interlock tx_client_handle=0x4627FE6D state=TRANSMITTING reason= source=HWCW tx_allowed=1 amplifier=

S0|interlock tx_client_handle=0x00000000 state=UNKEY_REQUESTED reason= source= tx_allowed=1 amplifier=

S0|interlock tx_client_handle=0x00000000 state=READY reason= source= tx_allowed=1 amplifier=

Hopefully, this will help isolate the issue.

k0oks

Somehow I lost me original post here...

After further testing I am hypothesizing that this is indeed a bug related to the TX Delay (Radio Setup-TX Tab) and the CW Delay (the delay setting in the same panel as the Speed and Sidetone settings). These two settings alias in timing and produce the dropouts.

You can easily reproduce the issue:

• Set your radio to use Iambic keying (even with a straight key connected you can still turn this on for the test), be setup to send a string of dits by holding down the key.
• Set your TX Delay to 30 (Radio Setup->TX tab). After setting this reopen the window and be sure the value "sticks" because if you don't change to another text field this value will not be saved.
• Set the cw Delay (hang time) to 29 in the CW panel of the UI.
• Set the Speed to 19 wpm
• Hold down the key and you will hear all the dits via sidetone, however only a few are sent. This can be seen on your power meter, or even in the waterfall display. There will be black where the dits are not actually being sent.

So how can you avoid this?

• Set the TX Delay as low as you are able to for your amp (or to zero if you don't need it-- a value of zero will fix it completely).
• Either set the cw Delay (hang time) to 0, or set it to a value over 2.5x the TX delay. Of course this begins to limit full break-in operation for those who desire it. But you are never going to get better than your TX Delay anyway. The higher the cw Delay the less likely to encounter the problem. I would set it to a value where you will be able to hear between words, but not between letters.
• A value of 0 for the cw Delay (hang time) can still cause the issue at certain sending speeds. So your safest bet is a longer Delay.

What could Flex do to improve this?

• They could possibly synchronize the clocks for the TX Delay and the cw Delay, and the built in keyer in order to reduce the issue. It is basically an issue of signal aliasing.
• They could definitely permit the dit or dash to be sent AFTER the TX delay, even if that dit or dash is slightly truncated at the head due to the TX Delay. Right now if the sending of a dit or dash is initiated at the inhibited moment it is not sent at all, even if you have a long 5wpm dash-- nothing gets transmitted. This is probably the least desirable behavior possible, as a slightly shorter dit or dash is better than a missing dit or dash.
• With the steps above Flex can reproduce the issue, and hopefully come up a with a method to fix this to make Flex a quality radio for CW. I know two people who recently purchased Flex 6600M radios and then promptly returned them due to these CW issues (they are 30-50wpm + cw ops). So these bugs are costing Flex real money.

Please report back with any other observations or ideas.

k0oks

Oh, I now see my old post as well as the latest one above. They both say similar things... Anyway, this is easy to reproduce and Flex can now design a method to fix it and make Flex an awesome CW rig.

k0oks

Well, I have to slightly amend my post. A TX Delay of 0 does NOT completely fix the issue. I was still getting missing slow dashes when sending with a straight key... However, Flex can still reproduce the bug with the data above. So hopefully they can fix.

BG5ILX

Thank you very much for your suggestions, thank you. My version is flexRadio 3.5.9. I had intermittent problems with CW transmission before, but it became normal again inexplicably a week later (not using flex remotely). I suspect that the normal use of FLEX is related to the flex (manufacturer) server?

In other words, the prerequisite for normal use of flex is that the flex (manufacturer) server must be normal?