Beginning of transmission spike

[KC9RF]

Hi All
First running Protocol 1 and ANAN 7000 DKE III firmware 2.8 Thetis version 2.10.3.5 x 64. I'm getting a momentary spike just after pressing mox or ptt running remote on transmit. Thoughts/settings?

Bob KC9RF

[NC3Z]

What are your settings here?

Screenshot 2024-02-08 184450.jpg (40.53 KiB) Viewed 1739 times

Also, got to ask, why Protocol 1??

[KC9RF]

Gary
Current using protocol 1 because of sequence errors. I will be doing a firmware update when I get back to QTH in April as I'm
running remote from South Texas.
The settings were similar to what you displayed on options menu.
I tried what you had but neither works.
Bob

Thetis settings.jpg (212.33 KiB) Viewed 1691 times

[KC9RF]

Gary also put a post on ANAN Groups I/O which shows a better video of the spike.
I just tested again and it appears that when I have NR on it goes away. NR off or NR2
I tested both remote using RCFORB PTT from remote hams software and also just selecting MOX I get the same results.
the spike reappears. Have no reason for why this happens but it does.

Bob KC9RF

[PA3GVQ]

I had the same problem when I used a new audio device as VAC.

Everytime I made a TX a burst of noise came before my own audio. It took me some days to find and fix the problem.

But in the end it turned out to be receiver noise from the RX audiochannel, shortly passed to the TX audio channel before it passed my speech.

It was solved in my case to block (notch) the RX audio to my TX audio channel. And that fixed in my case the problem.

Good luck.

Edwin

[ramdor]

not sure if mentioned in the thread, but if using vac, try and use different vcables/lines for in/out. eg :

vac_2lines.png (11.55 KiB) Viewed 1648 times

[w4bf]

Yes, rx noise will do it. My usb mic is / was always ON, so the TX mic buffer was capturing it prior to PTT and out came a short burst of whatever is going on in the rx. Had to use relay tied to mox output to keep mike muted until tx. Of course it all depends on level of rx audio vs placement of speakers near mic, etc.

This was discovered first with RCForb remote.

One of those delays in the PTT setup can also stop it, but I recall it had to be out about 400 msec and you can't start talking until that delay expires.

[KC9RF]

EDWIN & all who have replied

Thanks for the input

I reduced Master AF and RX1 AF and no spike was observed. I'm operating remote so won't be able to do any hardware changes. Using virtual audio cables.

So how can I block the RX audio from causing this problem with a setting or software?

Bob KC9RF

[PA3GVQ]

Hi Bob,

Nice that you have found the problem!

For me it was a easy fix using a Rodecaster Pro mixer. Just block/notch the TX channel in the mixer console.

But it took me some time to figure out wat was wrong the first place.

Good luck with finding a fix for this problem, maybe others who use there system remote can help you.

73, Edwin PA3GVQ

[S_Car_Go]

This problem could easily be fixed with a code change to Thetis.

I suggest that the transmit audio buffer should be cleared just before a transmission when the PTT is activated. That way any sounds collected my the mic would be purged. I fought this problem and my only solution was to use headphones so the mic did not pick any ambient noise in the room, like the receive audio coming from the speakers, or add the 400ms delay. The 400ms delay is required to eliminate the unwanted sound pickup.

If the buffer was cleared then there would be no need for the 400ms delay on transmission.

Dave... WB5QFZ

[K1LSB]

This problem could easily be fixed with a code change to Thetis.

I suggest that the transmit audio buffer should be cleared just before a transmission when the PTT is activated. That way any sounds collected my the mic would be purged. I fought this problem and my only solution was to use headphones so the mic did not pick any ambient noise in the room, like the receive audio coming from the speakers, or add the 400ms delay. The 400ms delay is required to eliminate the unwanted sound pickup.

If the buffer was cleared then there would be no need for the 400ms delay on transmission.

Dave... WB5QFZ

Dave,

I was thinking the same thing until it occurred to me that in many cases there's latency (and resulting "buffer" storage effect) in the upstream audio that's not under Thetis' control, such as Windows-based mixers (Voicemeeter), rack gear, etc.

Mark

[w-u-2-o]

This problem occurs even without external source of latency like Voicemeeter. The problem is that the Thetis TX audio pipeline is not flushed prior to the start of the transmission.

This problem can be mitigated by setting General > Options > Options-1 > RF Delay to an appropriate value. I've never measured what that value might be, however. FWIW I use 15 milliseconds for that setting.

[K1LSB]

Scott,

I understand that. My point was that even if the Thetis pipeline is flushed there may still be some not-yet-delivered audio in the upstream pipeline that's going to come through when the PTT is pushed, notwithstanding any particular settings in the General > Options > Options-1 page.

Mark

[K1LSB]

Also, it hasn't been explicitly stated in this thread but there's an option in Thetis to purge the buffers on TX:

Capture.jpg (164.55 KiB) Viewed 1404 times

Mark

[w-u-2-o]

AFAIK the Purge Buffers option only affects the spectral display and not any audio.

[DO2ZA Erwin]

AFAIK the Purge Buffers option only affects the spectral display and not any audio.

Yep, you are right, Scott
73 Erwin

[K1LSB]

AFAIK the Purge Buffers option only affects the spectral display and not any audio.

Thanks, Scott -- that would also explain why that setting is in the Dispay tab instead of the Audio tab.

Mark

[KC9RF]

FYI
I have put in a delay of 450ms which temporary works around the problem. However this amount of delay is a problem
with a normal conversation if I don't pause it will more than likely cut off the first part of a sentence or call sign.

Looks as though there should be software solution to this issue. who should be contacted to ask if this could be taken care of?

Bob KC9RF

[W4WMT]

Hi Bob,
You can't find a downward expander (DEXP) setting that helps with this?
73,
Bryan

[KC9RF]

Bryan
Have already setup downward expander. However I tried playing around with settings but there is no improvement on what I already have
setup.

Bob KC9RF

[K4IBC]

Yes a downward expander might work but it would have to be external of the radio. Since he is using it remotely this does complicate the problem.

He would need the downward expander on the remote end. Simple way without using external gear is to use a "VST HOST" program and find a Free downward expander VST to use. Route audio thru this before sending it. Don't know what he is using to remote with.

[W4WMT]

Yes a downward expander might work but it would have to be external of the radio.

I don't see why that should be the case.
If the threshold were set above the ambient noise in the shack, then the expansion ratio could be set deeply enough to attenuate it below where it would be objectionable.
73

[K4IBC]

Yes a downward expander might work but it would have to be external of the radio.

I don't see why that should be the case.
If the threshold were set above the ambient noise in the shack, then the expansion ratio could be set deeply enough to attenuate it below where it would be objectionable.
73

It probably has more to do with him operating remotely that effects the audio processing chain in Thetis.

[KC9RF]

Note:
Others are having the same issue as I have a post on groups IO as well. Remotely I can click Mox on my local computer through
remote desktop and observe the same issue. Also I can mute my usb mic which I'm using remotely and see a spike using RCFORB from
remote hams eliminating any background noise that might have been present.

Disabling VAC1 and simulating running the radio with headphones and a mic locally there is no spike. So the problem appears to be
using VAC. I have also tried VAC2 and observe the same issue.

Bob KC9RF