6600M transmitter stops intermittently on CW

Mike-VA3MW

I did some research on the history of this (key word, some) and had a quick conversation about it with engineering.

The short story is that it came down to de-bounce issues in the software as the root cause thanks to some work other users had done and we confirmed. You could clearly see the bouncing on a Scope.

Bouncing is the tendency of any two metal contacts in an electronic device to generate multiple signals as the contacts close or open; debouncing is any kind of hardware device or software that ensures that only a single signal will be acted upon for a single opening or closing of a contact.

In this diagram, you should see the trace go from high to low without any noise as an example. This is an easy enough test to do by supplying a voltage via a resistor and watching it go from high to low. I hate to say it, but my Bengali key is the worst at it.

I can't speak about a target fix time yet on the de-bounce issues (sorry, policy).

This explains why some see the problem and others do not as it related to the mechanics of the key. Since the algorithms that handle the CW key are the same for all users (and it doesn't wear out or change) you have to look at all the parts involved (physical CW key, SmartSDR, Radio, etc).

73

Lasse SM5GLC

Mike, excellent findings! But this might not be the only reason, as we have seen the powerloss even when using an external keyer, which using a switch transistor to the key Flex and should not have any bouncing.

Cheers

Lasse

James Charlton

Mike,

Thanks for the comment. But I don't quite understand what's happening. My first experiences with the problem were with a Chinese mil surplus straight key - certainly a prime candidate for key bounce. The problem was rare, but when it did occur and I was able to trap it, it was always with the key held down. As long as I held the key down, the rig (6600m) appeared to be transmitting, but no RF was being produced. All bouncing effects would have long passed after 5-10 seconds.

Most recently, I saw the problem using a paddle on a Winkeyer. I was sending continuous strings of dots at 30+wpm. As long as I kept the dots going, the transceiver stayed in 'transmit' with the on-off button glowing red, but no RF output. Releasing the paddle and stopping the string of dots for even the briefest of instances (say 100ms) restored normal operation.

As before, it is very difficult to cause the problem. I am summarizing dozens of long trials to trap one event.

I have not tried causing the problem using my logger to generate dots through the Winkeyer.

Assuming that the problem is related to contact bounce, how fast would the dots have to be sent for the radio to interpret them as contact bounce?

Regards,

Jim Charlton AD0AB

Mike-VA3MW

There might be a few issues here but the symptom is the same. Can you find some way to recreate it all the time?

The hard part in any software company is finding the root cause. Once you find the root cause (different than the symptom) then it is easier to actually fix it.

73

James Charlton

Mike,

I'm workin' on it. It is a very rare event and never seems to occur when I'm trying to trap it. It is always a surprise when it happens.

I hope to operate the CQ contest this weekend so maybe that will bring it out of hiding, LOL!

Regards,

Jim Charlton AD0AB

Roger G3LDI

This problem happens whatever paddle or key you use, whatever speed, whatever power supply you use for the Flex, and I have had the paddle held on dash while I demonstrated the fault to another local on 2 metres.

I agree with Mike in that an intermittent fault is the worse type of fault you could possibly have. Having been an engineer for 32 years, I have been in lots of similar situations, just waiting for the fault to become permanent. I do hope we are not in a similar situation though!

73 de Roger, G3LDI

Lasse SM5GLC

Michael,

When I first opened a help ticket, Tim Ellison advised me that this was a software defect assigned G7759, and the only remedie is to drop back to 2.4.10 (it was 2.4.9 at the time). This, to me, shows someone at Flex has noticed what was going on and realised that from 2.51 and onwards there is a problem with the software.

I'm puzzled and surprised that when other users report the same problem, this is "news to Flex". We have been nagging about the issue for years! As far as I can see, this affect ALL CW operators who uses semi break-in and use paddle/or key. Do everybody notice? No, unless you keep track of the output power. Beeing spurious, noone has found a way to force the problem, it just happens, especially when you do not want it to show :)

James Charlton

Hi Mike,

I worked a little of the WPX contest over the weekend and did not experience the CW loss of power problem.  I worked all bands 160 – 10m using a Winkeyer and occasionally a straight key, about 20-30wpm, about 1200 watts into various tuned antennas – no tuner. So, I don’t have any new information to help identify the problem.

 But reviewing my notes, I can say the following.

The problem rarely occurs. If one doesn’t operate CW for long periods and over long periods, it is unlikely that the problem will be observed. In fact, it could occur and the sender would not notice it. The far end would simply ask for a resend and the QSO would go on.  I suspect the Flex engineers have never actually observed/trapped the problem.

The type of key or keyer doesn’t matter. I have experienced the problem with a bug, straight key and a Winkeyer with a paddle.

Power output doesn’t seem to matter, but I don’t think some RF feedback or other interaction can be ruled out.

In the few instances I have observed the problem, it has occurred while trying to send a dash. The symptoms are always the same: the key is down (contacts closed), the on-off button is red, the relay(s) click indicating a switch to transmit, but there is on RF output. The transceiver will stay in this state as long as the key is held down. Releasing the key immediately restores normal operation.  

Recently, I observed the problem while using a paddle and Winkeyer to send (into a dummy load) long strings of dots with short, but random spacings. The speed was over 40wpm. The problem occurred and stayed as long as the string of dots continued. That tells me the space between the dots was insufficient to clear the problem.  Or, that the dots were so close together that the transceiver saw them as a continuous dash.  Releasing the paddle immediately restored normal operation.

To me, my 6600M is truly a black box with a pretty face in that I have no knowledge as to how it works inside. So, I can only SPECULATE as to what’s happening. The first thing to keep in mind is that the Flex transceiver is not a radio and should not be thought of as operating like one. It is a data processing device with some really cool I/O.

The red on-off switch does not really indicate that the transceiver is transmitting. Instead, it indicates that the transmitter has been ‘told’ to generate RF. To me, that means that the ‘key up/key down’ sensor detects the state of the key contacts and sends messages to the transmitter telling it to start or stop generating RF. It also sends messages to the button display as well as other functions related to switching between transmit and receive. The problem occurs when one of the messages is corrupted.

For example, the key sensor determines that the key contact is closed and messages the processor to turn on the red light, switch the T/R relay to transmit and turn on the RF. When the key is released, messages reversing the sequence are sent and the transceiver returns to the ‘receive’ state.

But then the key is pressed again and messages are sent calling for the transceiver to switch to the ‘transmit’ state again. But the message calling for RF is lost. Perhaps the processor was doing something that caused it to miss the message or noise corrupted the message. Whatever the reason, the message was not acted upon. The result is that the message calling for the red button was acted upon and the switching the T/R relay was acted upon, but there was no RF.

As long as the key is down, this state remains. When the key is released, the key sensor sends messages to turn off the red light and switch the T/R relay back to receive. It also sends a message to turn off the RF, but it is already off so that message has no effect. Now the transceiver is back to its normal receive state.  

So, why didn’t the radio reset when I was sending a barrage of dots? I believe the answer is in the oscillograph of the key bounce. The dots looked like key bounce so the debouncing function in the radio considered them to be just one long dash.

Remember, this is pure conjecture on my part. “I know nothing” about the inside of a Flex. But maybe this little story will spark an idea in the mind of someone who does.

Regards,

Jim Charlton  AD0AB

PS: I use the following settings – transmit delay of 25ms and hang time of 150ms. 

Ted S

The reason that your radio did not reset with the string of dots is that there must be more than 150 ms between the elements before the radio cycles back to receive. If you don't let off of the key long enough for the 150ms hang time to expire the radio will continue to not generate any RF. People running full break-in, hang time set to zero, generally don't notice this bug because only one element is shortened or mis-keyed, the radio cycles back to receive after each element for full break-in and it clears the issue before the next dot or dash is sent.

Ted WR4T

DL2CC

Just to let the community know that I have had the issue of missing dots for a very long time.

Notably it began when USB ports were introduced into the software.

I've opened issue tickets with Flex support previously and talked to engineers in person, but the problem never vanished completely. While in the meantime I also have had plenty of CW timing / lag issues, I don't feel them now.

However, just I just was in a longer CW QSO and once again had a missing dot.

It is not a debounce/connection issue. Why? Because I use an external keyer which produces it's own sidetone which I hear in addition to the Flex' own sidetone.

In case of the missing dot I can hear the external sidetone, but not the Flex internal one.

However, I have the feeling that the actual transmit signal is there, just the sidetone is missing. But I am totally unsure about that as I can't really see that.

Currently running v3.2.34.3128, with a WinKey keyer connected to the ACC input in the back.

I will open another trouble ticket with flex support to let them know the issue is still there.

73 Frank DL2CC

James Charlton

That's interesting! I never thought of comparing an external sidetone with the one generated by the Flex. I will try that, too. I am absolutely sure in the few cases I was able to trap, no signal was transmitted. I am sure of that because I trapped them while sending dashes with a straight key. When I saw the event I held the key down for a number of seconds while I examined what was happening and determined that there was no RF output. Releasing the key restored normal operation. I don't know how many times it occurred while sending dots - especially with a keyer - that I didn't notice.

The fact that each of us experiences the problem under slightly different circumstances tells me that we have not discovered the root cause. I think it's important to remember that the Flex transceivers are not radios, they are computers, with very fancy I/O, programmed to simulate a very high quality radio.

The fact that we have experienced the problem across a couple of software upgrades indicates, to me, that the problem lies deeper than a simple feature addition. Possibly at the firmware/hardware levels.

I have no idea how the Flex transceivers work or what goes on 'behind the curtain'. But I envision it is something like a swan swimming gracefully across a placid pond. To a viewer, the bird appears to be gliding smoothly across the surface. But underneath, the feet are frantically paddling.

Regards,

Jim Charlton AD0AB

Hunter - K3IE

I am currently having this same issue with the latest SSDR v 3.2.39 and stumbled across this thread. Happens whether I use an external key or the N1MM Winkeyer. Initially, it seemed to happen only when I had my PGXL engaged but now also occurring when barefoot.

Very annoying and random.

Curious if this remains a persistent problem within the group?

• Hunter K3IE

James Charlton

Update:

Since my last post, I have made several hundred CW contacts and not experienced the problem. I am running v3.2.39 on my 6600m and one version before the latest on my PGXL. The only change to the station is the addition of common mode current chokes on the two short coax jumpers between the transceiver and the amp.

In response to my request for help with an unrelated problem, Flex suggested the cause may be excessive common mode current in my shack. Checking around, I did find some CM current on one of the two antenna feedlines, but I found a much higher level on both of the coax jumpers between the transceiver and the amp. I don't have actual numbers because I used an uncalibrated homemade RF ammeter.

I installed temporary chokes (10 turns of coax on mix 31 torroids) which greatly reduced the CM current and the problem went away.

More to the point, I have not experienced the CW problem since installing the chokes.

Because the CW problem is so rare, I can't say whether or not it is cured until I make a lot more contacts.

It's not much, but maybe there's some relationship between CM current and the CW problem.

That's the latest from my shack.

Jim Charlton AD0AB

PS: Yes, the "temporary" chokes are still installed.