Thetis v2.8.11 - UPDATES and current issues

[w-u-2-o]

@Alexander, thanks for the video...

Richie: one moment, please. Let's make certain that the panadapter display remains correct.

The noise power in a given FFT bin depends on the bin width. An "x" dB change in bin width should equate to an "x" dB change in noise power.

Using the Auto-AGC level line, which accords very well with my "eyeball" of the noise floor (it's really a very handy little line ), and a little averaging just to make things a bit more accurate, I made the following measurements:

Capture.JPG (55.42 KiB) Viewed 19758 times

As you can see, at maximum zoom (smallest frequency range on panadapter), the increases in noise power match very well with the increases in bin size, just as they should. There's some kind of 2dB bobble in that first step which I can't explain (maybe Warren can?), but the additional steps accord well with theory. Whatever changes you are making should not disturb this behavior.

It's worth noting that at minimum zoom (largest frequency range on panadapter), there would appear to be some scaling going on in terms of bins per pixel, but I'm not sure I understand the math or if it is correct. In the RF instrumentation world a spectrum analyzer would display a value called "resolution bandwidth" that would define what unit bandwidth the displayed noise power should be referenced to. Again, another question for Warren, perhaps, and ultimately it would be good to determine this number and display it in the status line directly under the panadapter.

Note also that maximum zoom under these conditions gives a panadapter bandwidth of approx. 7.06KHz, and minimum zoom gives a panadapter bandwidth of approx. 706KHz.

Window size, i.e. absolute number of pixels, seems to make no difference.

Thanks,

Scott

[Yevgeni]

Hi
It is not possible to set the desired value of the RX1 attenuator for transmit mode. Always set to 31 dB.
For RX2, too, at the time of transmission, there is always a setting of 31 dB. Not very convenient for transmitting on one band and receiving at that moment on another.

[DL2XY]

@Alexander, thanks for the video...

Richie: one moment, please. Let's make certain that the panadapter display remains correct.

The noise power in a given FFT bin depends on the bin width. An "x" dB change in bin width should equate to an "x" dB change in noise power.

Using the Auto-AGC level line, which accords very well with my "eyeball" of the noise floor (it's really a very handy little line ), and a little averaging just to make things a bit more accurate, I made the following measurements:

Capture.JPG

As you can see, at maximum zoom (smallest frequency range on panadapter), the increases in noise power match very well with the increases in bin size, just as they should. There's some kind of 2dB bobble in that first step which I can't explain (maybe Warren can?), but the additional steps accord well with theory. Whatever changes you are making should not disturb this behavior.

It's worth noting that at minimum zoom (largest frequency range on panadapter), there would appear to be some scaling going on in terms of bins per pixel, but I'm not sure I understand the math or if it is correct. In the RF instrumentation world a spectrum analyzer would display a value called "resolution bandwidth" that would define what unit bandwidth the displayed noise power should be referenced to. Again, another question for Warren, perhaps, and ultimately it would be good to determine this number and display it in the status line directly under the panadapter.

Note also that maximum zoom under these conditions gives a panadapter bandwidth of approx. 7.06KHz, and minimum zoom gives a panadapter bandwidth of approx. 706KHz.

Window size, i.e. absolute number of pixels, seems to make no difference.

Thanks,

Scott

It's not only binwidth, it also depends on window function and detector characteristics.
One can find a good overview including math by this link: https://www.ap.com/technical-library/ff ... for-noise/

73 Walter

[ramdor]

@scott, "Whatever changes you are making should not disturb this behavior". It wont, it has nothing to do with it as it is just a change to the the auto adjusted AGC gain based on the 'noise floor'. The display, fft sizing, fft bin width etc, are not touched.

The display data is already offset according for a number of things including hard coded dB offset values based on hardware, alex offsets, preamp offset, 6m offset, calibration offset. This display data is used to generate the noise floor, and thus pre-offset. The auto agc function was then incorrectly offsetting again, and using the fftoffset incorrectly. I could change it to not use the adjusted data at all, but easier at this stage to to remove the adjustment for the time being.

So now, after the fix. the offsets from all those adjustment above are removed from the noise floor calculation, the shift applied that you specify in the AGC noise floor comp config, along with the fft size offset, and then a new gain is calculated.

For ref, I get the following,

readings.png (7.59 KiB) Viewed 19749 times

Yes the x resolution of the display area has seemingly zero impact on the data. Extreme decimation (general->refresh rates) does, but that would be expected as the data set reduces.

Richie.

[w-u-2-o]

It's not only binwidth, it also depends on window function and detector characteristics.
One can find a good overview including math by this link: https://www.ap.com/technical-library/ff ... for-noise/

Thanks, Walter, I'm very familiar with the math overall. It's just not clear to me what sort of resolution bandwidth scaling is going on in the WDSP and/or Thetis code as zoom level changes.

BREAK

@scott, "Whatever changes you are making should not disturb this behavior". It wont, it has nothing to do with it as it is just a change to the the auto adjusted AGC gain based on the 'noise floor'. The display, fft sizing, fft bin width etc, are not touched.

Perfect!

The display data is already offset according for a number of things including hard coded dB offset values based on hardware, alex offsets, preamp offset, 6m offset, calibration offset.

Yes. As you might remember we discussed all this some time ago, especially with regard to how auto-AGC interacts with changes to the attenuator. But as this was specifically addressing FFT bin width I was concerned about that, and only that.

For ref, I get the following,

Better linearity than I got with my measurements!

Thanks!

Scott

[ramdor]

Hi
It is not possible to set the desired value of the RX1 attenuator for transmit mode. Always set to 31 dB.
For RX2, too, at the time of transmission, there is always a setting of 31 dB. Not very convenient for transmitting on one band and receiving at that moment on another.

yes Yevgeni, the attenuation stuff really needs stripping out and re-doing. A quick look, and it seems 31dB is being applied if auto atten is on, PS is switched off OR you are in either CW modes. This might be a change related to QSK, or a hack to add max attenuation for PS in case it is turned on? I am not sure, it was in version 2.8.8 but not in 2.8.7.

Richie.

[Yevgeni]

This might be a change related to QSK, or a hack to add max attenuation for PS in case it is turned on? I am not sure, it was in version 2.8.8 but not in 2.8.7.

Richie.

When the PS mode is on, ATT is controlled by the program. Everything is clear here.
In other cases, the user should be able to set the ATT value for RX1 and RX2 to any desired value during transmission.

If there is time and desire for this. Thanks..

[ramdor]

It would have been added the for a reason. I expect if that was taken out we would have lots of AGC overload posts here. Somewhat concerned about just removing that, although I can't see any point having user adjustable TX attenuation with it there.

Set to 31

If PS-A is OFF
or mode is CWL/CWR

when TX is enabled

Somewhat odd.

Richie.

[Yevgeni]

Hi
It's just that no one is working on transmission on one band and at the same time has normal reception on another band. And when there is an ATT of 31 dB during transmission, then a sensitivity dip occurs on a different range.
Sorry for my questions if they distract from the case.

[w9ac]

"...A quick look, and it seems 31dB is being applied if auto atten is on, PS is switched off OR you are in either CW modes. This might be a change related to QSK, or a hack to add max attenuation for PS in case it is turned on? I am not sure, it was in version 2.8.8 but not in 2.8.7.

Richie.

Richie,

I do know that 31 dB of ATT on Tx is used when CW QSK is engaged. The prior default was 15 dB.

Some time ago, I asked W2PA to make that change. Otherwise, with lesser settings, CW artifacts develop during T/R transitions. That, plus high settings of the AGC hold line result in completely artifact-free QSK operation.

Paul, W9AC

[ramdor]

@Paul, W9AC, thanks for that Paul. Yes I have seen where the 31 is applied when qsk is switched on, and then reverted when switched off, tagged as change [W2PA_21a] in the code.

Probably the global 31 was added into the TX function for potential CW issues. Perhaps it needs to be :

if PS-A is off AND (CWL or CWR) then att = 31

at the moment since v2.8.8 it is :

if PS-A is off OR (CWL or CWR) then att = 31

Richie.

[w9mdb]

I'm using a pre-release version of JTDX 2.2.15-rc3 and the behavior with TCI cat control and Rig Split in JTDX is having problems.

If Thetis is in split and JTDX is not then JTDX gets an error in TCI Set Split. In this case I have to ensure Thetis split is off and then JTDX starts OK.
I don't think JTDX has a problem with SunSDR TCI as that who is mainly using it now.
If the blasted websockets thing wasn't encrypted I could see better what's going on with wireshark.

I'm hoping to get some better debug from the JTDX people to help track this down.

If I set JTDX to use Rig Split the behavior is very erratic.

Hopefully somebody else can duplicate this problem to ensure it's not just me.

[ramdor]

I'm using a pre-release version of JTDX 2.2.15-rc3 and the behavior with TCI cat control and Rig Split in JTDX is having problems.

If Thetis is in split and JTDX is not then JTDX gets an error in TCI Set Split. In this case I have to ensure Thetis split is off and then JTDX starts OK.
I don't think JTDX has a problem with SunSDR TCI as that who is mainly using it now.
If the blasted websockets thing wasn't encrypted I could see better what's going on with wireshark.

I'm hoping to get some better debug from the JTDX people to help track this down.

If I set JTDX to use Rig Split the behavior is very erratic.

Hopefully somebody else can duplicate this problem to ensure it's not just me.

No, JTDX wont have a problem with SunSDR because TCI was designed as part of that EE software. However aligning everything to Thetis that has no idea of VFOa on RX2, dubious control of centrefrequency, and a bunch of other things is not something I can implement in a few hours a day of free time. This TCI stuff is entirely work in progress in Thetis, especially around split and/or RX2.

Short story, don't use split atm. Heck don't even use TCI atm until it has settled. You are wasting your time even thinking about getting WireShark involved. Even the EE test client is not 100% as it replies with IF when it shouldn't be. There are lots of changes already in rc2, and I will be getting back to it mid week. I am working on something else atm.

Edit: and for what it is worth, 2.2.158 x64 works fine here with RX1 using split, off/rig/fake with split on/off on Thetis, at start up or mid use. Not sure about 2.2.15-rc3 that you reference without trying it.

Richie.

[Yevgeni]

Sorry, I'll try my idea again.
How to eat now
Check box "ATT on TX"= ON
receive S-ATT RX1=ab transmit S-ATT RX1=31
receive S-ATT RX2=ab transmit S-ATT RX2=31
Check box "ATT on TX"= OFF
receive S-ATT RX1=ab transmit S-ATT RX1=ab
receive S-ATT RX2=ab transmit S-ATT RX2=31
It should be
Check box "ATT on TX"= OFF
receive S-ATT RX2=ab transmit S-ATT RX2=ab

[w9mdb]

Yes...2.2.158 does work correctly.
I'm working with the JTDX people on this (Igor).
Looks like JTDX is now trying to turn off split when JTDX Split=None which it does not do in 2.2.158

Mike W9MDB

[ramdor]

Yes...2.2.158 does work correctly.
I'm working with the JTDX people on this (Igor).
Looks like JTDX is now trying to turn off split when JTDX Split=None which it does not do in 2.2.158

Mike W9MDB

ah ok, yes, that is not good, because none should not mess about with the radio, leaving it up to the user to pre-decide. In theory that should change the setting in ExpertSDR as well.

Also, as an aside, it wont matter to Thetis if it gets 1 or 1000 of them to turn it off, it only does if the request is different to what is currently set against the relevant RX. It will only send out a tci update if a change was made via a [split_enable] tci message. Of course the same message without true/false can be used to query current state.

R.

[w9mdb]

Not sure what you mean "that's not good".
When a client asks the rig to turn off split the rig should turn off split.

I'm going to be writing my own mini-websockets for hamlib so I can implement TCI in hamlib without having to drag in some humongous library like QtWebsockets which would make the TCI interface non-portable. I did the same for XML as all the XML libraries were overkill for FLRig.

[oe3ide]

Not sure what you mean "that's not good".
When a client asks the rig to turn off split the rig should turn off split.

Because, if split in JTDX is set to "none", JTDX should NOT turn on/off split.


73 Ernst

[oe3ide]

Btw: I am running JTDX 2.2.158 and it works like expected. Only Split=Rig switches Thetis into split mode.
"None" or "Fake-it" does not.

73 Ernst

[w9mdb]

Split=None means Split=Off.
WSJT-X does the same thing.

[ramdor]

split none should ideally not send any split commands out imo, so whatever is set on the radio stays set, exactly like Ernst said.

It could send split off, but not what I would do tbh. It should be changed to say Off not None if it sends OFF out.

R.

[w9mdb]

Written by people in England....go figgr'.

WSJTX/JTDX have to know split status and expect to control it as the audio frequency is adjusted based on it.

The both expect full control over the rig and pushing buttons can give erratic behavior.

[ramdor]

wsjtx - looking at the cat msgs, selecting split and hitting ok, will send FT1's and then always use FB's. Going from split in the software to either None or Fake will send an FT0 if previously on the split setting. It seems that FT0's are not then sent if you change frequency etc, I don't know if they keep track of split being changed on the front of the radio, but that would be easy to check to see if the radio moved in setup, as they certainly don't force it back to FT0 each time if it is set to None/Fake, only on the initial OK press from settings if it was previously on split mode.

Not really related to us either way, but interesting none the less.

Richie.

[ramdor]

Written by people in England....go figgr'.

time zone problem to communicate with them?

Richie.

[w9mdb]

If you turn split back on with the rig you will be transmitting on whatever VFOB is set to. And WSJT-X/JTDX will not know what that frequency is and you may well be above or below your own bandwidth.
That's why I said pushing buttons on the rig gives erratic results.
Lots of ops do not understand the split operation in WSJT-X/JTDX and would never know something is wrong...only that nobody is hearing them or they are getting no power out.

[W9BHI]

"Written by people in England....go figgr".
What's up with that comment?

[w9mdb]

Terminology varies by country...that's all.
Perhapase None is the same as Off.

[ramdor]

DirectX and Mouse Pointer Issue

There has been a report of mouse vanishing/flickering since the change to more modern DirectX present/rendering method recently introduced (DXGI_SWAP_EFFECT_FLIP_DISCARD vs the old DXGI_SWAP_EFFECT_DISCARD if you want to read up on them). I can add an option to bypass this and always use the old method, but I would rather get to the bottom of it.

If you have tried updating to the latest graphics drivers, have fully updated windows, and are still having mouse pointer issues when hovering over the spectral area, please post below. Issues such as flickering, mouse pointer vanishing. Please include the following info :

Windows version : 10/11
Display drivers are latest : yes/no
GPU : nvidia xyz
Latest windows updates : yes/no
Mouse drivers updated : yes/no
If you are suffering from this, try turning on mouse trails and/or change pointer scheme. Did this help? : yes/no

Cheers, Richie.

[Alexander UC]

@Alexander, thanks for the video. I have not been able to replicate the issue with the vac gain, but I have fixed some code related to vac2 rx/tx sliders shown when in digi u/l. Please could you send me your database.xml from C:\Users\<user>\AppData\Roaming\OpenHPSDR\Thetis-x64

Richie, I can't attach a file. I will try to make a fresh installation of Thetis.

Regarding the auto noise compensation and the AGC shift when you change FFT width and/or sample rate I have made some changes which have improved things. Please see video : https://youtu.be/hFSReBhhbjA
Those changes will be in rc2, which wont be out tomorrow, but sometime later in the week/next weekend.
Cheers, Richie.

Yes, it works better!

[ramdor]

Richie, I can't attach a file. I will try to make a fresh installation of Thetis.

email it ? my details are over on qrz.

Richie - MW0LGE