Display Glitch

[Mike_N1JEZ]

I'm seeing a rather large spike in my display when I transition from transmit to receive. Video here:

https://drive.google.com/file/d/1Sk8jiu ... sp=sharing

Using the latest Thetis with protocol 1 on a bare Hermes card and also an ANAN-100. I see the same on both systems.

Win 10 Pro. No VAC - audio direct via the front panel.

Any thoughts??

Mike

[ramdor]

yeah, same here on 7000, has always happened afaik. I have talked with Warren about it, resetting the data on a tx/rx switch but it is not easily solvable. One of those things you have to live with. Long averaging will exaggerate it.

[ramdor]

same results here : https://youtu.be/ujB7vVyVEE0

[Mike_N1JEZ]

Tnx Richie. I can live with it.

Mike

[w-u-2-o]

This has always disturbed me as well. I'd really like to know if that is truly an indication of hot switching, or if it is just leftover/garbage data in the RX pipeline that needs to be emptied/zeroed before starting the RX panadapter again.

I've not been able to wholly eradicated it even if I set Setup > General > Options > Options-1 > RX Delay to a ridiculous number like 500ms.

[Mike_N1JEZ]

Hi Scott,

I tried the same thing increasing the RX Delay and can minimize it but it is still there. Richie can correct me, but this appears to be a display issue only?

Mike

[ramdor]

my video reply

vid: https://youtu.be/i8EIAIxsVL8

It is consequently somewhat impossible to use the display as any method to detect a hot switch issue.

[w-u-2-o]

Great video, Richie. So, as already suspected, it is just leftover data in the RX pipeline that needs to be emptied/zeroed at the proper time to make a clean transition to RX mode.

Just to be clear, of course in DUP mode it's all "RX data", but we must make a distinction between RX data received during TX, and RX data received during RX.

Certainly we don't want to do anything that would mess with latency. We want very fast RX-to-TX and TX-to-RX transitions. But the same need not be said for the presentation of panadapter/waterfall data. If the display data was zeroed at the precise moment that TX-to-RX starts plus any delay from RX1 input to display, and the RX averaging and data allowed to build back up again from that point, then it should eliminate the issue.

Also, I was surprised by the revelation that the TX display tab was mostly useless if DUP was on. I've been fooled by this for years because I always made the RX and TX settings identical except for the position of the vertical scale. And, since the vertical scale does move on TX, it was easy to assume that all of the TX display tab settings had meaning!

Thanks!

Scott

[ramdor]

yeah, the rx1 in use when dup is on is obvious to us lot, but personally I feel it should switch to use the TX settings when in use (need to look at the latency implications with that), or modify the RX1 tab to RX1/TXdup text, or add as minimum add a label Note: also used for TX when DUP is on. However, some of the stuff in the TX tab is used, like the waterfall/grid scale, etc. So a bit of a mess.

[W4WMT]

FWIW, I don't get the "display glitch" here.
How does one produce it?

[ramdor]

FWIW, I don't get the "display glitch" here.
How does one produce it?

this video talks about it : https://youtu.be/i8EIAIxsVL8