Pulsing during transmit FT8

Paul Carff

I get theses pulse when I transmit for FT8. Any ideas what could be causing them?

Al K0VM

That looks like short breaks in the TX audio stream usually attributed to DAX buffer corruption. The usually fix is to close and restart the DAX GUI. If they return soon, rebooting the PC may help as will reducing the load CPU load on the PC.

AL, K0VM

Paul Carff

I have a beefy gaming PC that I have converted for ham radio and nothing else is running - so I don't think it is loading.

I have restarted the computer and I am seeing this same behavior using different computers.

Mike W9OJ

I've had transmit audio cut out intermittently on FT8 on some bands while running higher power. I'm running 450 Ohm line and may have some RF in the shack.

Does it happen to you on all bands at all power levels?

73 de Mike W9OJ

Frederic HB9CQK

You are not alone Paul!!!

I have been trying to solve this issue for several weeks now and it is most likely network related. Let me describe our setup and issue:

We (HB9RYZ, Wolfgang and myself) are operating the Mount Rigi Remote Station at 1660m ASL in Central Switzerland. We are using the FLEX-6700 and an spe Expert 1.3K - FA PA. The antennas are a LZA-10-5 and a 54m Longwire using a JC-4s remote antenna tuner. Before anybody jumps at me an shouts: "RF FEEDBACK!" I can assure you that this is not causing our pulsing. Pulsing ONLY happens when we are using SmartLink. Pulsing is NOT influenced by the power output level or band! We have a local PC up there and if we do FT8 locally there is no pulsing. We have observed pulsing in SSB as well, but it is more difficult to detect. It reduces the audio quality, which is bad news, because we used to get excellent audio reports. Since we have the pulsing issue we get mediocre reports.

Now before you say "Bad Internet connection" let me tell you that we have a fiber connection up there with 100 MBit/s up and down. Latency is 5ms!!!! This is a very good fiber connection. Both operators have this issue and we both have very fast internet connections at 600 Mbit/s with low latency that we have thoroughly checked. I usually check for pulsing using a 1 kHz tune tone on FT8. Here you can see two screenshots that I took at home using the Colibri SDR that I operate as a panadapter with my IC-7800. First operating locally (using Anydesk to the local PC) and second operating remote with SmartLink:

The large horizontal bar is probably a lightning - ignore that, but the rest is ugly enough! Considering all checks that we have done so far we think that the issue is related to the network. It was OK before, so we do not think it is a SmartLink issue. We have pulsing with the PC and the Mac version of SmartSDR. Our Router is a FritzBox 7590. It is possible that the issue is with the router, but whatever we have tried so far did not change the pulsing issue. It cannot be a local network issue because when operating locally all is fine, nevertheless we checked all cables and are using CAT6 shielded cables with ferrite cores. We tried different MTU values - no change. The next thing we may try is changing the router, but since the site IS remote in all respects it will take some time.

If you want to learn more about the Remote Station you can lookup my website at https://hb9cqk.ch/news.html or the website of Wolfgang at http://www.hb9ryz.ch/remote-dx-station/index.html

I hope we can solve that together!

73, Frederic, HB9CQK

k4mjg

Me too folks... IC-705 with Marcus' SDR anyone figure this out yet? cheers. K4MJG

Mike-VA3MW

@Frederic HB9CQK

Just a few thoughts. My apologies for the long post.

Regardless of pipe size, I have seen similar on my remote. I tracked it down to other data being moved on the network at the same time. I was nowhere near maxed out on the Pipe.

Here is an example (and I am not saying it is your problem). I was watching over my VPN using Ping Plotter pinging every 500ms.

Then, I got this next slide. I was watching the data transfer rate on the pfSense firewall and it was 10% of capacity. Yet, Ping started to get pushed aside (due to being a low priority ICMP message).

I finally figued it out that, in my case, it was related to my RDP connection to my remote PC. Everything the Windows Desktop screen redrew, it briefly fragmented the data stream.

I don't know enough networking to give you detailed steps to dig further, but my thought is that something is a bit grumpy in the transport layer. The root cause may not be the radio (doing a Link.Local test will prove this—but not practical on a remote setup). The key part to this is that you mention it only fails on SmartLink.

And, what about Jitter?

Jitter refers to the variation in the time it takes for packets to travel from their source to their destination over a network. In other words, it's the variability in packet arrival times. In a perfectly consistent network, packets would arrive at regular intervals, but in reality, various factors cause these intervals to fluctuate.

Are you using DAX over SmartLink as well? If so, the UDP packet stream from the radio back to the end user can be easily fractured as those packets are the first to be tossed if the router deems some reason to do it.

There are several reasons why a router might drop UDP packets:

1. Network Congestion: If the network is congested, routers may drop packets to manage the load and maintain overall network performance. Since UDP doesn't have congestion control, it can overwhelm the network more easily than TCP.
2. Buffer Overflow: Routers have limited buffer space to hold incoming packets. If the buffer overflows due to high traffic, packets will be dropped. The Pipe does not have to be full for this to happen.
3. Quality of Service (QoS) Policies: Some networks implement QoS policies that prioritize certain types of traffic over others. If UDP traffic is considered lower priority, it might be dropped in favor of higher-priority traffic.
4. Error Handling: Unlike TCP, UDP does not have built-in mechanisms for error checking and retransmission. If a router detects errors in UDP packets, it might drop them instead of forwarding corrupted data.
5. Rate Limiting: Some routers implement rate limiting to control the bandwidth usage of different types of traffic. If the rate of UDP packets exceeds the configured threshold, the excess packets may be dropped. (I doubt this is your case, but it is worth checking)
6. Security Measures: To prevent DoS (Denial of Service) attacks, routers might be configured to drop UDP packets if they are coming in at an unusually high rate or from suspicious sources.

Your diagnosis so far is very good. You might want to test/try another router (at both ends). Sadly, we have no way of telling what happens in-between, do we?

73