ad: k1jek

Some FT8 Intervals Don't Decode

Discussion in 'Working Different Modes' started by KG6MZS, Apr 30, 2020.

ad: L-HROutlet
ad: l-rl
ad: Subscribe
ad: abrind-2
ad: Left-2
ad: L-MFJ
ad: Left-3
  1. KG6MZS

    KG6MZS Premium Subscriber QRZ Page

    RS-232 - so I am going out of the Macbook's USB 3.0 port > USB.3.o to 2.o adapter > USB 2.1 to RS-232 adapter cable > K3

    I will try your settings. It has also been suggested to me that I try the CAT control in one of the logging programs made for the Mac. RUMlogNG or MacLoggerDX.

    I appreciate all your help K7GQ

    73 de Eric, KG6MZS

    PS; last night I worked New Zealand, Australia, New Caledonia and Norfolk Island dodging the bad decodes on the Windows 8 machine. This really makes me want to get on this mode with a stable machine!
  2. W4KJG

    W4KJG Subscriber QRZ Page

    I think I may have a clue to at least part of the decoding problem. I am now thinking it has to do with computer processing power -- or the software cannot handle more than about 40-50 signals in the 3 kHz bandwidth.

    I feel I have a pretty decent computer in my shack, so I'm not sure computing power should be an issue. It was a top-of-the-line Windows 10 HP tower when I bought it 4-5 years ago. I sure don't plan to upgrade it anytime soon. It has a lot of IO ports, including two RS-232 ports, a mix of eight front and rear USB 2.0/3.0 ports. Its got simultaneously usable front and rear separate audio I/O ports. I think the HDD is 2 TB.

    What I believe I'm seeing seems to be happening when there are multiple signals in the passband. It seems to happen when there are probably at least 25-50 decoded signals. It doesn't finish all of the decodes before the next cycle starts. That next cycle then shows up shorter on the waterfall, and it doesn't decode. Something it then misses the next cycle which also has multiple signals to decode, and sometimes up to about five 15 second cycles.

    Since I started using the WSJT program a couple of years ago, I've usually set the audio from the receiver to WSJT to approximately "40" on the left-side level indicator (it was adjustable in WSJT in the older versions. Now it relies on the audio card level.)

    I'm not using AGC in any of my receivers. The AGC is almost always set so that I'm not seeing any noticeable intermod signals in the IF display.

    I've switched from monitoring 30 meters to monitoring 40 meters in the last couple of hours. Since then, I've added 10, 20, 30 of attenuation in the receiver antenna input line. With the 30 dB attenuator in the antenna line, I'm still often seeing in excess of 50 decodes on those cycles that decode. It then doesn't decode for 2 to 5 more cycles.

    With the 30 dB attenuator in the antenna line I'm still seeing decodes reporting S/Ns of -23 to about +12 dB.

    I don't want to jump to any conclusions. But, right now, it seems like decodes of more than 35 signals per cycle, and several signal levels greater than about +10 to +15 dB in that cycle, keep the next cycle, or several cycles from decoding.

    It is past my bedtime. But, I'd be interested to know if anybody else is seeing any patterns that lead to non-decoding.
  3. KE5MC

    KE5MC Premium Subscriber QRZ Page

    I'm not on PC now for specific details, but you can monitor system usage with a control panel application. My HP tower and configuration is similar to your. If CPU usage gets near 100% that could be the issue. Any chance you have 3rd party software protection running? I've not had any problems. I'm not sure what to think about signal level and attenuators. I just turn the gain down on the receive if I have too.
  4. KE5MC

    KE5MC Premium Subscriber QRZ Page

    This morning activity on 20m with 21/22 decodes. Spike in CPU is during the decode period. other time hovers between 10-15%. My task manager came up in name order and I clicked on CPU column to get highest to lowest percentage. Hope this helps.

    W4KJG likes this.
  5. KG6MZS

    KG6MZS Premium Subscriber QRZ Page

    This theory should be easy to check. Does the problem happen on uncrowded bands with few decodes per interval? It seems to me that I still have the problem on low-activity bands. But I will check.

    Thanks for the post,
    73 de Eric,KG6MZS
    W4KJG likes this.
  6. KG6MZS

    KG6MZS Premium Subscriber QRZ Page

    Here's a screen shot that illustrates the characteristics of the problem. Notice that the skirts of the bandpass seem to disappear when the decoding fails. Again, there is no audible difference at these times.

    W4KJG likes this.
  7. KE5MC

    KE5MC Premium Subscriber QRZ Page

    My waterfall with fall off like that if I forget to switch to data mode. Data mode for me is flat audio receive to 3K and all DSP receive enhancements are off. Odd that other signals in the "DOESN"T" are "fuzzy" like said before. I also see horizontal band blue streaks of maybe 5 seconds in some of the yellow. Example is next to right side "S" in lower "DECODES". It looks like a shorter (time) version of the "DOESN'T" bands. I would not expect to be able to hear a difference in sound as minor appearing as the differences are when listening to the entire audio bandwidth. Maybe narrowing the receive bandwidth down to one signal you might pick something out. I'm not sure if that would help, but something might come out of it.

    P.S. Looking over earlier post I see Windows/Mac/bootcamp. I'm really not bashing that setup at all as I use a iMac/iPad/iPhone, totally in the Apple zone. I do have a PC for all radio activities. Maybe your setup had more going on than what can easily been seen/monitored. I think I saw something about Windows 8.1. I skipped that going from 7 to 10, but on a PC. Maybe a Windows upgrade might be in order in your configuration.

    2nd decode at the top time decode 18:25:00 has two blue horizontal strips that impact signals in that time slot all across it. No clue what it means or where to look to fix. :-(
    Last edited: May 7, 2020
  8. W4KJG

    W4KJG Subscriber QRZ Page


    Why didn't I think of that? Thanks everybody.

    I had SDR _Console running at a 3 MHz bandwidth. I'm not sure why I was running it that wide. That was taking up almost 65% of my CPU usage. I also had several other programs running, like my browser with several windows open for things like PSKreporter. When there were more than about 15 decodes WSJT was pushing the system to 100% usage for as long as the decodes were happening. Dropping the SDR_Console scan bandwidth down to 300 kHz dropped its CPU usage to about 8%.

    With everything back running, including having this window open, it is CPU is running along at about 30-33% usage. During WSJT decodes it bumps up to 40%-45%. It is now decoding every cycle.

    Thankyou, thankyou, thankyou.

    KP4SX and KE5MC like this.
  9. KG6MZS

    KG6MZS Premium Subscriber QRZ Page

    The K3 is in Data mode - this is what the waterfall looks like in Data mode.

    The thing about Boot Camp is that it runs Windows native off a drive partition. Unlike emulators, there shouldn't be any overhead. Famous last words. :)

    Due to the lockdown I'm having a heck of a time getting another machine in here to test. Until then I'm just dodging the "fuzzies." Sometimes the whole QSO goes just fine. Other times I'll bet some stations are wondering why I send "[THEIR CALL] KG6MZS R+10" five times before we can complete the QSO :(

    Thanks for hanging in there with me.
    73 de Eric, KG6MZS
    Last edited: May 7, 2020
  10. KG6MZS

    KG6MZS Premium Subscriber QRZ Page

    Here's the waterfall on 17m a few minutes ago. CPU usage peaks out at 15-20% with so few decodes and the problem persists.

Share This Page