Sticky TX anyone?

Lasse SM5GLC · February 22

After upgrading to SSDR 2.12.0 I have noticed 2 or 3 times that the transmitter "hangs" i.e. not reverting back to receive when transmitting CW using CWX. A quick push on the paddle will bring things back to normal. I never noticed this while running 2.4.10

As this have happened duing a QSO or calling in a pile-up, I had no time investigate the issue. It seems to occure very seldom, so no major issue. Reason for even bringing this up is that someone mentioned a similar issue. Cannot find this post now... but if others have noted this with 2.12.0 or 3.7.3 please make a comment...

73

/Lasse SM5GLC

Tim K9WX · February 27

Lasse: were you using an amplifier when you had the sticky TX?

Tim K9WX

Lasse SM5GLC · February 27

Tim,

yes that is correct. But as fas as I could see this is not a amp relay issue.

The waterfall did show just black, rather than the internal noise from the receiver. So the radio clearly shows it was still in transmit.

Hitting the paddle would "release" the radio.

As I'm about to replace the radio SD card, this issue is on the back-burner until I have the other issues sorted out.

/Lasse SM5GLC

Mike-VA3MW · February 28

This is not an SD Card issue, but likely an interlock issue. Please open a support ticket.

Lasse SM5GLC · February 28

Ok,

so it happened again today. This time I had a chance to investigate... and what happens is that the TX2 which is KEY IN to amp gets stuck. I physically removed the KEY IN cable and the amp did un-key. Re-seated the connector, and amp was on again.

Just one short touch on the keyer, and the TX2 got un-stuck.

Will open a ticket, but guess it is a nightmare to investigate, as it rarely happens.

/Lasse SM5GLC

Mike-VA3MW · February 29

Can you test with TX1 or TX3?

WX7Y · February 29

Mike,

For a very long time I have had the TX Stick on but ONLY after a long TX like describing something to some one or what ever about 5 minutes long.

I run JUST the F6700, PGXL,TGXL.ANTGEN over Ethernet, NO wired TX lines connected.

This is not often enough to worry about so I have not commented on it before and I thought maybe there was just RF currents built up keeping the AMP keyed so long.

THE RADIO does NOT stayed keyed.

Tim K9WX · February 29

I can report a similar experience as SM5GLC.

I installed v2.12.0 on Sunday afternoon. On 4 different occasions since then, I was operating CW and became aware of a problem when I stopped sending and expected to hear band noise resume in my headphones. Instead, the audio from the radio was dead quiet and and I noticed that the display on the Maestro showed highly attenuated RX.

The first 3 times it happened to me I was not quick enough to see what might be going on. The auto CQ of N1MM resumed and things returned to normal as Lasse describes.

I was ready for it the 4th time (I was sending CW by hand). I was using a KPA500 but driven with only 5 watts of input power to produce about 100 watts of output power. The Maestro went virtually blank with no audible audio out and the MOX button was not lit up. I looked at the KPA500 and there was an asterisk on the KPA500's LCD display indicating that the amp was receiving a PA Key signal from the radio. In my case I use TX1 for this.

That's 4 times in about 400 CW QSOs. This only started after I installed v2.12.0

Tim K9WX

Lasse SM5GLC · March 1

Tim,

excellent feedback! And good to know you did notice the MOX status, I failed to do so. This should point to a s/w bug rather than an issue with the TX control line.

I had a support ticket going, but it was closed, as there was no more substance to show.

/Lasse SM5GLC

Lasse SM5GLC · April 3

So it happened again, still on 2.12.0…. this time the radio stuck in TX mode when using CW, and refused to switch back to RX. I had to restart the client to get things going. Slightly frustrating as YJ0VK came back to me when the TX hang. But mangaged to get through once things were OK again.

Mike-VA3MW · April 3

Lasse, you'll have to open a support ticket so they can track it down at your station.

Lasse SM5GLC · April 3

Mike, I did open a ticket but this was closed, due to lack of further data. This appears to extremely rare, but somewhat comforting that others sees similar things.

It's been a month since I previously noticed this but to day it was far more persistant as I had to restart SSDR.

I will keep an eye open for this, and if it start to occure more frequently I will re-open the ticket.

/Lasse SM5GLC

Mike-VA3MW · April 3

RR … It is such a small sample rate (a few?) that I wonder what the root cause might be? Initially, I doubt the root is in the radio as everyone would be reporting it.

It sounds like the TX=0 command traveling over the LAN is being dropped. Just for a test, can you try a different network switch?

My very unofficial thought based on reading pretty much everything posted everywhere is that moving from a Gig switch to a 100mb switch might resolve it. I have read lots that the auto negotiate in Gig switches isn't always flawless. Or, some sort of other network interruption which can be very noticeable if you are dealing with real-time communications.

If you had a managed switch in play, then at least you could log into the switch and see if some ports are showing a lot of dropped packets or retries.

The only other thought is to 'change something' and see if it gets worse or better. That would be another clue to help narrow down the root cause.

73

Lasse SM5GLC · April 4

Agree it may be a network related issue. But the problem seems to have started with SSDR 2.12 and the instance yesterday, was a bit different as I could not get the radio to switch back to receive, I tried various things, i.e. PTT switch, MOX button, send a few chars to name a few, so this one was slightly different from earlier incidents.

The switch I use has been in use for several years, and have optical fiber to my other home net, so changing is not "trivial". What I have done is to set the ports in use only to Advertise as 10/100 Mb, lets see if this changes anything :)

And reason for adding stuff to the thread is to see if others have similar issues while running SSDR 2.12, just to collect more data.

Mike-VA3MW · April 4

I had an issue with my Maestro B on a LAN . It always had broken audio if anything on the same switch did a data burst, such as a web page load or download and I spent a long time trying to isolate it knowing it wasn't likely the Maestro. I even updated the NIC drivers on the Maestro.

Andy, VA3CW, gave me this idea.

On my VoIP phone, there is a courtesy LAN port at 100mb (it might be 10, I can't remember). I guess this is for plugging a desktop into in case your desk didn't have a spare LAN cable.

The phone is on the same subnet.

I plugged the Maestro into that port and I have never had LAN issue since. No, you shouldn't have to do that. But, it worked. And, I don't notice any additional latency.

Try sticking a 4 or 8 port 100mb Desk switch between the Radio and the Prime network switch. See if it makes a difference.

73

Lasse SM5GLC · April 4

I'll keep this in mind… Not sure I do have a 10/100 switch, as the one I had ended up at a friends Flex radio a few years ago :) But I'll get one if the problem gets annoying enough :)

But remember the "issue" did occure after upgrading to 2.12.0. Never ever seen when using 2.4.10.

73

Mike-VA3MW · April 4

If you go back to 2.4.10, is the problem still there?

There may be fixes that fix things but broke something else. This is not an uncommon scenario in the sustaining world. Maybe network packet stuff that resulted in significantly less latency, but often, there are many trade offs.

Networking internals is really detailed stuff. That is why a CISCO CCIE Person easily starts at $120K annually in the US. I had a friend of mine, who is one, that it is easy to make a network work. It is HARD to make it work perfectly and fast. Switches drop data all the time he told me. The good switches do a much better job recovering.

Sticky TX anyone?

Comments

Leave a Comment

Categories