PowerSDR 2.7.2 Affecting Clock

Ed, K0KC

I sent my Flex 6700 to Austin for a **** and oil change (aka product enhancement) last Wednesday and fired-up my trusty Flex 5000 to fill the void. I operate mostly JT65 and JT9 and used the 5000 successfully for several years before I acquired the 6700 about a year and a half ago.

 About the time that I started using the 5000 this week, I noticed that the DT (time differential between my system and the decoded station's system) was consistently running 2 seconds or more high (using WSJT-X, but the problem is the same on JT65-HF). Typically, this value runs +/- 0.5 second or so if both systems are periodically synchronized to an NTP server.

One would not expect such values of DT to be decoded, but I did not have any problem on the receive end. I also did a test with a local ham (K8SAR) and he indicated that my transmitted signal at his end had a DT of 0.2 to 0.3 seconds. I checked everything that I could imagine including changing the battery in the computer and trying a different time sync application...no dice. I am using VAC 4.12, but that version has worked fine for me in the past.

On a whim, I hooked-up the computer to my IC-7700 via a Signal Link USB interface. To my surprise, the DT values were normal and I made a few contacts just to be sure. When I went back to the Flex 5000 with PowerSDR 2.7.2, the problem returned. I did play with a few different sampling rates and buffer sizes and was able to see a little improvement in some cases, but I still have the problem. I also did not have this problem with the 6700 before it was shipped to Flex.

Any ideas as to what  may be going on here would be appreciated! I am certainly not off the air, but I would like to resolve this issue if possible.

Thanks,

Ed, K0KC

Tim - W4TME

I can't tell from your description is you are having this problem with the 5000 and the 6700 or just the 5000?

Ed, K0KC

Tim,

The problem is only with the 5000 which I started using again when I sent the 6700 in for "Product Enhancement". The 6700 was fine and the IC-7700 is fine. I still have a 3000 here and I might try that today, but I do not think that it is the hardware that is causing the problem.

Ed, K0KC

Tim - W4TME

With the 5000, the audio processing for DIGx goes though several layers to turn the bit stream from the digital mode program into RF.  There is latency in the VAC stage and in the DSP / audio buffer stage.  To minimize the latency, you want your PowerSDR DSP TX and audio buffers to be small (there are three levels of audio buffers; the firewire (hardware), the audio and  the VAC buffer) to minimize latency.  When you use an external sound card, you are bypassing the VAC component.  There can also be a CAT delay where the radio does not key up as soon as the digital mode program tells it too.  All of the system latencies can contribute to the DT delay assuming your PC clock is synced with a good external NTP source.

We have also had reports of VAC misbehaving and taking a long tome for audio to start passing through it.  Not sure what is going on there, as v4.12 has been stable for me (v4.13 was downright evil) and I have some limited time using 4.14 and it seems to work OK.

Ed, K0KC

Tim,

Thanks for you comments!

I have played with the buffer sizes and still experience the issue. I do not use an external sound card. I do not think there is a CAT delay problem since I can just leave the 5000 on receive and the DT values continue to be high. One puzzle is that I can decode fine despite what the WSJT-X program is showing for DT values. Another is that if I quit PowerSDR and then restart it again, the DT values are reasonable for a while and gradually build-up to +2 seconds or more.

I have been using VAC 4.12 for quite a while now and it did not give me any problems before, but that was before several Windows 7 updates. Perhaps I should give 4.14 a try.

Again, this is not a big deal for me as I will start using my 6700 again in a week or so when it comes back from Austin. Additionally, I am having no problem with the 5000 decoding signals and making contacts despite the DT issue.

Ed, K0KC