Transmit waterfall "jump or pop"

Mike

I have a 6600 running 2.10.1 and a problem(?) has popped up in the last few days.When in xmit (rtty and the FT modes) I was noticing a "jump" in the xmit sort of looks like a pop. I haven't had this problem before that (at least not for a while since I upgraded my computer). Anyone have an idea of what I might have changed by accident orwhat I might need to change?

Kevin_1969

Welcome to the world of snap, crackle, and pop as experienced by many, including myself. Poor UDP packet handling, and many, including myself, are tired of it.

I've went so far as to isolate the entire radio system, putting it on its own NIC card in my PC. Added the card, isolated it, and I still experience the dreaded pop.

I seriously doubt many monitor or even care about audio, I have hours of recorded conversation on the air, and there are a number of Flex users I hear the same popping on.

I'm watching it on FT8 this morning as I type this. Later I will once again hear it on my transmitted audio both on SSB and AM.

By the way it's not an RF issue. If you are familiar with the XVTR feature to hear your own transmitted audio without the use of RF, it is easily noticeable as well.

Yet many services including Skype do not display this same behavior.

Good luck, I am sorry that no one has taken the time to answer your question before now, and I am afraid I cannot be of much help, as I am still dealing with it myself.

Mike-VA3MW

There is 1 test you can try to and see if the problem is the radio or the network. The pops are one thing. The jumps are another.

The jumps are related to DAX and yes you can see them in the transmitted signals at times. It is something the engineering teams are working on and are getting closer to solving it. It has been a very difficult issue to resolve. The good news is that it doesn't seem to affect digital operations.

The pops while in RX are related to lost data in the network and are generally external to the radio. The simple test is to connect your PC to the radio directly with a very a good CAT5 or better cable. Turn off the PC and the Radio, connect the cable and turn on both. Start SmartSDR and test and hear how it sounds. The odds are, the problem goes away.

I spend some serious time working on this on my own personal network. It took some time, but it came down to a bad switch and 2 bad CAT5 cables. Replacing the cables with CAT8 made a significant improvement.

The best change I made was putting in a managed switch (not that much more expensive). I use everything in a default mode. BUT, the one feature it had was the ability to actually look at a web page and see if I was having packet transmission errors. Low and behold, I actually was. This was the clue I need to change out cables.

I just went and looked to see what it was saying. You can see ports 1, 2 and 3 seem to have an issue. They do, but those are my 3 KMTronic web switches that only run 10M 1/2 duplex. I can't remember what Port 8 is, but it isn't critical.

Ports 20-23 are the Radio, PGXL, TGXL and Antenna Genius. I think it is about 2 weeks since I reset the counters.

When I operate my radio remotely at the cottage, the packet radio path is a bit of a dogs breakfast since it is not a simple lan path. It looks like this:

6600 Radio <> TP-Link Switch <> MOCA media converter -- MOCA media converter <> TP-Link Switch 16 port <> TP-LINK switch 8 port (yes, another one 40ft away) <> Maestro

If I am going to drop UDP packets, it is going to be in the above path. But, the good news is I don't. If I check my packet loss on the Maestro, I show over 15M packets and only 4 dropped. (Amazing actually).

Before I started down the path to replace everything, it was Anna NH6Z our Networking Guru who had looked at a WireShark trace for another issue we were chasing she and told me that my network was a mess. She could see all the retries and packet loss. At first, I didn't listen to her, after all, it had been 'good enough'.

But, I made the changes I mentioned in the other posting and it has been seamless. It was well worth the effort. Just like working on antennas.

The only time I hear packet loss is when I am running remote and someone starts a download on the network that 100% consumes the available bandwidth from my ISP.

I spent a lot of time working on this and documented it here:

https://community.flexradio.com/discussion/8028378/network-cleanup-and-the-results

I am not saying you need to do all this just yet. Just try the simple cable test I mentioned above and see how that goes. Let us know how you make out.

73, Mike va3mw

Mike-VA3MW

@Kevin_1969

Yet many services including Skype do not display this same behavior.

Certainly, your mention of Skype is noteworthy. Unlike some real-time communication systems, Skype employs an audio buffering mechanism. Consequently, while you will eventually receive the complete transmission, it may exhibit latency or delay in its delivery.

This characteristic became evident in an experiment conducted by a colleague and me in the past. During this experiment, we were both utilizing dial-up internet connections. Our communication occurred via Skype, and the latency was so pronounced that we found it necessary to use the traditional "over" signal to indicate the completion of our individual transmissions. It's worth noting that I was located in Canada, while my associate was using a dial-up connection through CompuServe in Austria.

To expand on UDP packets, they are more efficient than TCP, but come with the risk of being dropped.

Switches and routers dropping UDP (User Datagram Protocol) packets can occur due to various factors. One common reason is network congestion, where devices prioritize certain traffic over UDP packets to manage the load. Additionally, these devices may have limited buffer space, leading to packet drops if the buffers fill up.

Fragmentation problems and difficulties in handling fragmented UDP packets can lead to drops.

It's essential to remember that UDP lacks the reliability features of TCP, making it susceptible to packet loss.