VAC SIGNAL NOT STEADY

[w-u-2-o]

Very true, Stu. Unfortunately the VAC control code dates from the legacy Flex days and is total spaghetti

73,

Scott

[w9mdb]

I started having problems too. Latency mon sees no problems. 2048 buffer size didn't change things. But dropping the Primary sample rate to 96000 did solve it. Recording the transmission could see half a dozen dropouts running FT8 on WSJT-X.

de Mike W9MDB

[Tony EI7BMB]

Mike if you have time could you post a pic of what the drop outs look like on the waterfall , think I may be seeing the same here?

[w-u-2-o]

I started having problems too. Latency mon sees no problems. 2048 buffer size didn't change things. But dropping the Primary sample rate to 96000 did solve it. Recording the transmission could see half a dozen dropouts running FT8 on WSJT-X.

de Mike W9MDB

Mike,

I saw where you posted in the other thread that your LatencyMon results are OK. I'm going to assume that you read through my entire VAC tutorial as well? I.e., that all your settings are correct, that you are 48KHz "clean", etc.

If so, then the only thing I can suggest is that, based on the improvement in your situation when changing the primary sample rate to 96KHz, your computer simply isn't powerful enough. Of course, now you are probably going to tell me that you have some sort of i7, crypto smashing, bit coin mining, kind of machine

There are three basic sources of dropout (RX or TX, it's the same):

1. Non-optimal buffer settings (primary, VAC, latency, DSP). These will cause under and overflow type errors thereby resulting in dropouts.
2. Sound driver related issues (PortAudio), which can lead to PortAudio related buffer under and overflow type errors. Other than selecting sound drivers and checking your machine with LatencyMon, you have no direct control over this.
3. DSP processing related issues that caused by untimely PowerSDR thread execution. Again, this is the sort of thing you check for with LatencyMon, and you have no direct control over it other than to lower CPU load, things that affect CPU thread execution latency, and creating a faster, more powerful computer.

There used to be a fourth issue, which is the Ethernet packet out of order problem, but that has been fixed for a few versions now.

It's worth noting that because of the somewhat less than optimal architecture of PowerSDR DSP processing, it can be more challenging to run than even more complex sound related software such as Pro Tools or other DAWs. Much, if not all, of this has been fixed in Thetis. Unfortunately the Protocol 2 firmware necessary for Thetis is not ready for prime time yet.

This issue is one of the reasons I decided to build a faster PC.

73,

Scott

[w9mdb]

Here's my system calling CQ top one no dropouts, bottom one has some. I'm running 48kHz sampling right now and still seeing dropouts but not as bad. Latency mon shows no problems. I see this show up as power variation on Fwd Pwr and the "flashing" of the spectra as these sharp transitions occur. Going to do some more testing here. Latencymon shows no problems on my system.
Would be nice if there was some sort of dropout detection in PowerSDR as I'm wondering how many people are experiencing this? I had the problem a few months ago and then a reboot seemed to fix things. But now that doesn't fix it either.
de MIke W9MDB

[AB2EZ]

All

VAC1 + FT8 has been working flawlessly (no glitches on the waterfall, etc) for about 1
month now. I have installed the last several HPSDR updates without any problems. As I cycle through various bands and band segments... VAC1 automatically turns on or off... depending upon how I have set it for those modes/band segments. I have installed several Windows 10 updates. I have turned the HPSDR application off each evening. I have restarted the computer from time to time.

No problems EXCEPT if I turn VAC1 off and on manually (which I don't do). Turning VAC1 off and on manually causes a return of the waterfall glitches and various other problems...which requires me to "fiddle" with the sampling rate and the buffer sizes to fix.

I am using an ANAN 10E and a three year old I7 Dell computer. The if sampling rate is set at 192k samples per second. Latency monitor shows no problems. It can run for several hours before it registers a hiccup. Every once in a while, the transmit waterfall registers a single glitch during an FT8 transmission... which I assume is due to an overflow of one of the digital audio buffers. I.e. the clock inside the Dell computer is running about 18ppm fast compared to the GPS-disciplined clock that is driving the ANAN 10E.

Stu

[w-u-2-o]

No problems EXCEPT if I turn VAC1 off and on manually (which I don't do). Turning VAC1 off and on manually causes a return of the waterfall glitches and various other problems...which requires me the "fiddle" with the sampling rate and the buffer sizes to fix.

This is a known bug. You can fiddle, or you can just restart PowerSDR. It's a huge pain for people who switch between VAC and non-VAC operations. I'm always in VAC mode so it doesn't affect me

73,

Scott