Transmit spectrum bad behavior

[w9mdb]

This is actually a long-standing issue I've had on two different computers.
Is it just me?
At some random time the transmit spectrum display starts showing wide-band behavior.

Here's an example of a normal transmission

Screenshot 2022-02-23 091537.png (75.92 KiB) Viewed 9677 times

The at some point multiple times per day it will look like this...wiith wide-bad noise bouncing up and down and toggling the Power in Thetis fixes it.

Screenshot 2022-02-23 091752.png (52.67 KiB) Viewed 9677 times

[ramdor]

not really seen that. I get the odd 'bounce' of the spectrum when in TX (dup on), which sometimes is related to a SEQ error, or some external signal/lightning. It doesn't stay 'stuck on' though requiring a stop/start.

[w9mdb]

Yes...this is with Dup on.
I need to check with Dup off and also ensure this is not being transmitted.

Then I need to capture the network traffic and see what's getting sent to the rig.

Mike

[w9mdb]

Starting a new thread on this long standing problem.
Apache 7000DLE MKII and several times per day the DUP spectrum will show what looks like broadband noise constantly. This is in lieu of the "normal" behavior of just showing spiky noise levels.
I've had this problem on two different computers so I don't think it's the computer. I'm using VBCable at 48KHz and have played with different samples rates with no change in behavior.
Cycling the Power button on Thetis fixes the problem so this makes me want to point the finger at Thetis.
To be fair my computer is a busy puppy as I have VirtualBox running Ubuntu doing development work on Hamlib while also keeping Thetis and 8 other ham apps running. My computer is plenty fast and not breathing hard.
Processor AMD Ryzen 9 5950X 16-Core Processor 3.40 GHz
Installed RAM 64.0 GB
System type 64-bit operating system, x64-based processor

[ramdor]

It will be interesting to see if others are suffering with this. If no one else is having this, perhaps the issue is following the radio as you have had the issue on different computers. When you switch out to RX and then TX again, does the high noise spectrum move or is it stationary?

Also need to include some additional info such as :

firmware version on the radio
rx1/rx2 F/W set sample rates
if rx2 is in use at the time
if SEQ errors are showing
if this happens when the pc is not being used for other tasks

[w-u-2-o]

Where I've seen this behavior is with Protocol 2 firmware that is not quite making timing. Things might start off good, then as the hardware, and FPGA, warms up, the problem starts. Or it may be random. By restarting Thetis with the "power" button, not only are you reinitializing the software but you are commanding a reinitialization of the firmware, too.

You can also get similar behavior on receive.

All the same questions as Richie: versions, etc. Also, are you running PureSignal? Does this happen with PureSignal disabled?

[PD3LK]

and a full print screen of Thetis maybe? ....

[w9mdb]

I found another clue -- changing the Buffer Size on VAC1 also cures the problem.
I imagine that also resets the audio stream.

[K9RX]

Mike,

I see this on PSDR 3.4.9 so it's something that has been there. It generally is associated or at least exacerbated by changing the power while transmitting causing PureSignal to have to go look for a different solution. It generally is stable once a power level is set - but can take several seconds for it to settle. It is very wide band with high power levels off the normal tx passband - as you show.

Gary
K9RX

[w-u-2-o]

I found another clue -- changing the Buffer Size on VAC1 also cures the problem.
I imagine that also resets the audio stream.

That's a BIG clue. Changing any setting in VAC will cause a lot of audio stuff to reset/restart. That strongly implies a software issue.

[w9mdb]

I bumped up the buffer size and it seems to be behaving a lot better now. I don't see the bounces during transmit and, so far, no constant wide-band behavior.
So maybe this has something to do with overrunning the buffer?

[w-u-2-o]

That's a good bet!

Are you 48KHz "clean" all the way through the chain? Device -- VB Cable -- VAC? Have you double checked the device advanced tabs in the old Windows Sound Control Panel? What audio devices are you using?

[w9mdb]

Yes...all 48KHz.
I've tried all the VBCable devices A/B and the default.
Using A right now.
I've got the buffer size at 512 right now -- was at 64 on the new computer which seems to work OK when nothing else is going on.
It's just that once it apparently starts getting overflows perhaps it exceed some limit and gets "stuck" producing garbage.

[w9mdb]

Poking through the code I see this suspicious section

void upslew2 (IOB a, INREAL* pIin, INREAL* pQin)
{
int i;
double *pout;
double I, Q;
pout = a->r1_baseptr + 2 * a->r1_inidx;
for (i = 0; i < a->in_size; i++)

pout is point into an offset of a but the loop is using the entire size of a.
Maybe this should be this?
for (i = 0; i < a->in_size - 2*a->r1_inidx; i++)

[w-u-2-o]

The code seems to work fine for most of us. I'm not qualified to answer the code question.

You did not answer the question about what sort of audio devices you are using.

[w9mdb]

VBCable

[ramdor]

Poking through the code I see this suspicious section

void upslew2 (IOB a, INREAL* pIin, INREAL* pQin)
{
int i;
double *pout;
double I, Q;
pout = a->r1_baseptr + 2 * a->r1_inidx;
for (i = 0; i < a->in_size; i++)

pout is point into an offset of a but the loop is using the entire size of a.
Maybe this should be this?
for (i = 0; i < a->in_size - 2*a->r1_inidx; i++)

A quick check, upslew2 defined in iobuffs.c, used in the whole project by fexchange2 also defined in iobuffs.c, which is used in the project by......

nothing. Not checked upslew0, perhaps worth talking to Warren.

R.

[w-u-2-o]

VBCable

What's at the other end of VBCable?

[w9mdb]

Thetis -> VBCable A -> JTDX