Thetis v2.8.11 - UPDATES and current issues

[ea3aqr]

When coming back to 10m after band switching last used frequency is not restored.

The frequency is positioned in the last used band stack frequency.

[ramdor]

That is not true for 21b.
In 21b the panafall is automatically centered at the vfo-freq on band-switching. CTUN on, VFO-Sync off.

73 Ernst

that is not quite right. Info regarding this in upcoming post.

[ramdor]

Group reply time Essentially fix/release cycle is just that. To fix and clear away many of the niggles. I have to take breaks and implement some new stuff to keep my sanity from time to time (gradients/quickrecall). Doug has some bug/features that need to go in as well and that will do doubt happen when this cycle of 21x completes.

Going forward plans :
1) Continue with this fix/release/improvement cycle as part of 21x
2) Remove the convoluted band stack system totally and junk all the code. Re-implement in a oo fashion and provide a much better experience. Stacks will be stack per filter. So you can have a stack for band, or a stack for mode, or a stack for a frequency range, or combination of. Each 'filter' will be able to have a stack size defined. It needs to be scrapped and reimplemented.
3) Redesign the VFO boxes/areas into a re-usable user control. It will not know anything about receivers/dds frequencies or anything related to hardware. It will just be a visual VFO. This will be then used when moving towards the RXn implementation mentioned below.
4) Redesign all the band/mode/dsp display groups and implement each in resizable user controls that auto re-layout.

Yevgeni - yes, a full RX2 is in the pipeline as is RXn. This will however take time and is not something I have started look at yet. Included in that is being able to use any of the RXn as the transmit VFO source, and each RXn also having VFOb which can also be SubRX if you want to listen to VFOb freq.

Carl - cpu usage implications for active peak and gradient. I will post about this later today. Ok about the two instance issue. I will check this.

Dave - I will look into the out of range issue, thanks for report.

Erwin - see reply to Carl above.

Taiga - yes so would I It is in the list of things to sort out eventually.

Jeff - I will look into the vfosync oddities with ctun

K1LSB - is the bandstack entry locked for the band you are leaving? If this is the case it no longer will write changes back to the stack entry. This was fixed in 21a. Also, if the stack entry you are moving to is in CTUN a change to centre frequency is only made if needed, only if the frequency you are moving to is outside the sample area essentially. You may even see a bandstack entry sit on the edge of the spectral area (less margin) if the entry is CTUN. I will have a think about this. In the short term, add your band stack entries with CTUN off, this will ensure a re-centre.

DL8LAQ - yes, it has never worked for 7000/8000. See reply to Taiga above.

ea3aqr - this will happen if the band stack entry you are on when you left 10m was locked. As it is not saved. Previously is was actively overwriting a locked band stack entry. When you return to 10m, it will put you back on the frequency of that locked bandstack entry. Some more thought on this is required I feel as people tend to want to go back to where they were even if it is incorrect use of bandstack system. In the short term I could look for an unlocked entry in the stack, update it, select it, then you would return to that frequency. All a bit bodge really.

Richie.

[oe3ide]

Richie, great job

Here a short clip re centering on band-change:

https://www.oe3ide.com/wordp/wp-content ... ntered.mp4
So if the panafall is positioned to show a specific part of the band (in the example the 20m ssb) and you switch to another band and back, you have to re-position the panafall.

I reverted back to 21a. The panafall is always positioned like it was before the band-change.

73 Ernst

[K1LSB]

K1LSB - is the bandstack entry locked for the band you are leaving? If this is the case it no longer will write changes back to the stack entry. This was fixed in 21a. Also, if the stack entry you are moving to is in CTUN a change to centre frequency is only made if needed, only if the frequency you are moving to is outside the sample area essentially. You may even see a bandstack entry sit on the edge of the spectral area (less margin) if the entry is CTUN. I will have a think about this. In the short term, add your band stack entries with CTUN off, this will ensure a re-centre.

Richie.

Richie,

The behavior I was describing has nothing to do with the bandstack, or whether the last-visited frequency is even mentioned anywhere in the bandstack.

In 21b, whenever I go back to a previous band, the active (i.e., last-used) frequency filter always gets repositioned to the physical center of the scope regardless of where it was physically (to the right or left of the center of the scope) when I was last on that band. Consequently, my pre-arranged band edges are also no longer where I had previously set them.

V2.8.11 didn't operate that way.

For the record, CTUN is always enabled in my sessions.

Thanks,
Mark

[ramdor]

Display vs CPU usage

Ok, first off there are two modes to display cpu usage. You set these by clicking on the cpu% on the status bar to get the menu. I have selected Thetis only for this. I am ignoring GPU load.

Width
Spectral area width is the main contributing factor to delay and cpu load. For each horizontal pixel there will be a line segment node generated just to draw the top line. So for 1000 pixels of display. 999 directX2d line draw calls, per frame, 59,940 lines per second at 60fps.

Pana FIll
During tests is was far faster for directX2d to render width number of vertical lines instead of creating a complex fill poly. I assume the complexity of the poly caused flood fill delay. To have a filled panadaptor with topline, you are now looking at 1999 directX2d line draw calls, per frame, 119,940 lines per second at 60fps.

Active peak
This adds another vertical line draw per horizontal pixel per frame. So if you have a filled display of 1000 width with active peak you are now looking at 2999 line draws per frame, 179,940 lines per second at 60fps !! There is some extra code per frame that will check for hold time and decrement dBm of these if needed.

Gradient
Gradient brushes are built once at the start, and rebuilt if grid_min/grid_max, display area is resized or if you change the colours in setup. Whilst this does seem to have a measurable impact on directX2d line draw speed most of the work I feel is done by the GPU. So, for a filled panadaptor of 1000 width + topline we are looking again at 1999 line draws (active peak will add another 1000 but does not use the gradient brush).

Blobs
Each dBm value across the whole width of display is checked for > max. This is bound to add some measurable amount of delay and much like active peak decrements the recorded dBm values, per frame if hold time has passed.

Moving towards multithreaded display
It would technically be possible to create threads that will render a portion of each frame width. So for example 4 worker threads could build 1/4 of the width of the display. DirectX2d can be run in a multithreaded render mode. I may investigate this at some point.

Oh and remember, everything doubles if you are showing RX2 with the same settings

Cheers, Richie.

[ramdor]

Richie, great job

Here a short clip re centering on band-change:

https://www.oe3ide.com/wordp/wp-content ... ntered.mp4
So if the panafall is positioned to show a specific part of the band (in the example the 20m ssb) and you switch to another band and back, you have to re-position the panafall.

I reverted back to 21a. The panafall is always positioned like it was before the band-change.

73 Ernst

ok ernst, thank for that vid. I will investigate pronto, that should not be happening. I have replicated it here.

Richie.

[PD3LK]

Hi Richie, would you be so kind to incorporate a small change in the next release?
Changing the frequency database limit from 20.000 to 50k?
A few months ago Chris Codella made that change for me so i can use Dan Furguson's database (now > 23000 entries).
Chris has send the change to Doug but it has still to be implemented)

Thanks for your continuous good work for our radio community!
73, Leon, PD3LK

[ramdor]

Hi Richie, would you be so kind to incorporate a small change in the next release?
Changing the frequency database limit from 20.000 to 50k?
A few months ago Chris Codella made that change for me so i can use Dan Furguson's database (now > 23000 entries).
Chris has send the change to Doug but it has still to be implemented)

Thanks for your continuous good work for our radio community!
73, Leon, PD3LK

this went into 21a, as Chris pm'ed me direct with the array size increase info. Have you tested? Perhaps something else needs changing in there, I just mindlessly increased array size to 50k i think it was, without checking if any of the code used a hard limit instead of looking at array length.

Richie.

[NJ2US]

Hi Richie, would you be so kind to incorporate a small change in the next release?
Changing the frequency database limit from 20.000 to 50k?
A few months ago Chris Codella made that change for me so i can use Dan Furguson's database (now > 23000 entries).
Chris has send the change to Doug but it has still to be implemented)

Thanks for your continuous good work for our radio community!
73, Leon, PD3LK

Hello Leon, what is this "Dan Furguson Database" you speak of?

Thanks,

Jeff NJ2US

[K1LSB]

Richie, great job

Here a short clip re centering on band-change:

https://www.oe3ide.com/wordp/wp-content ... ntered.mp4
So if the panafall is positioned to show a specific part of the band (in the example the 20m ssb) and you switch to another band and back, you have to re-position the panafall.

I reverted back to 21a. The panafall is always positioned like it was before the band-change.

73 Ernst

Ernst,

Your video illustrates exactly what I was trying to describe!

Thanks,
Mark

[ramdor]

Ah, issue found regarding the returning to expected view when in CTUN. A 21c will be up shortly, next 30mins, just to fix that problem. Thank god for github being able to look back at commits to find out what was done. Thanks for all the reports, but keep in mind my comments above regarding locked bandstack entries.

Richie.

[Yevgeni]

Group reply time

Yevgeni - yes, a full RX2 is in the pipeline as is RXn. This will however take time and is not something I have started look at yet. Included in that is being able to use any of the RXn as the transmit VFO source, and each RXn also having VFOb which can also be SubRX if you want to listen to VFOb freq.

Richie.

Hi
Thank you very much for your attention and the work done.

[PD3LK]

"what is this "Dan Furguson Database" you speak of?
Thanks, Jeff NJ2US

https://groups.io/g/swskeds/files
(i think you have to join the group first)
The latest file is A21-210626-1900.zip, it contains a .cvs that you have to convert it a bit before you can import it in Thetis.
Hopefully Richie (or someone else) can make it more simple for us: direct conversion or use in Thetis...

[PD3LK]

Hi Richie, would you be so kind to incorporate a small change in the next release?
Changing the frequency database limit from 20.000 to 50k?
A few months ago Chris Codella made that change for me so i can use Dan Furguson's database (now > 23000 entries).
Chris has send the change to Doug but it has still to be implemented)

Thanks for your continuous good work for our radio community!
73, Leon, PD3LK

this went into 21a, as Chris pm'ed me direct with the array size increase info. Have you tested? Perhaps something else needs changing in there, I just mindlessly increased array size to 50k i think it was, without checking if any of the code used a hard limit instead of looking at array length.

Richie.

Yes the change made was a limit of 50k entries.
It works great Richie, although i could not test it above 33k entries yet. 73, Leon

[ramdor]

Just looking into why on startup we are not getting a call to SetBand. 21c delayed atm.

Richie.

[ramdor]

UPDATE 21c

21c is now up in the first post. There is also a fix at startup where any rx with CTUN enabled would not appear correctly. Please test the start up state in this regard. Sorry for the cock up with the CTUN band issue.

Also, I am working through the diversity form at the moment. Scaling has been implemented so far. So just a heads up if anything goes wrong in there

Richie.

[ramdor]

32 and 64 bit links were swapped in post 1, now sorted. You'll know if you are running the wrong one, it is in the titlebar.

Richie.

[dl5tt]

UPDATE 21c

21c is now up in the first post. There is also a fix at startup where any rx with CTUN enabled would not appear correctly. Please test the start up state in this regard. Sorry for the cock up with the CTUN band issue.

Also, I am working through the diversity form at the moment. Scaling has been implemented so far. So just a heads up if anything goes wrong in there

Richie.

Dear Richie,
thanks for your excellent work.
Concerning the diversity form / function, I have two additional wishes:

a) It would be useful (in my opinion), if the value LOCKING for GAIN is only valid for using the circle with the mouse, to find the best diversity parameters.
For typing any values into the GAIN field (I need values between 1.6 and 3.5), the locking should not be valid, because: if I am typing any values in this field, I want to do that really and the unchecking of the LOCKING-box is additional work, because after ENTERING the value, I have to LOCK again, for searching the best angle / phase. And if the GAIN value ist greater than "1", I have to lock in either case, to hold this value.

b) I think, that the actual step size of 0.001 is to small. I think a step size of 0.05 would fit most requirements.

0-Beat: If the radio tuning is on CTUN (the button below AVG), in my version, the 0-BEAT function doesn't work. The VFO is not adjusted to the correct frequency of the incoming CW signal.

73 de Josef (DL5TT)

Another question: How can I include a screenshot in the post (CTRL V) does not work.

[ramdor]

Hi Josef,

ok about 0beat - I will look into it. It is not working in CTUN here either.

I am adding log scale options, and max gain option. Gain limit in text box is 5.0 iirc, but this will be adjustable. Watch this space as they say

Cheers, Richie.

[W1AEX]

All button packs at the link below have been updated to support the Quick Recall Buttons and the 2TON button in Thetis version 2.8.11 21c.

http://www.w1aex.com/hpsdr/hpsdr.html

If you simply want to add the Quick Recall Buttons to any currently installed skin you can download this simple pack that will install only the buttons that Richie made:

http://www.w1aex.com/hpsdr/packs/21B_Quick_Recall_Buttons.zip

The full button packs can be unzipped into the Console folder of any skin to apply the updated 2TON and Quick Recall Buttons. Scroll down near the bottom of the skins page and you will find pictures of the button packs displayed. Grab any pack you need or want and unzip it into the skin's Console folder. Note that Thetis cannot be open or running when you do this!

73, Rob W1AEX

[ramdor]

70MHz transverter 'Out of Band' message appears at first set-up of XVTR. It is corrected by re-selecting region in the General settings and re-starting Thetis. Just a small bug to add to the list.

Richie, Many thanks for your great attention to the fine details in Thetis.

73 Dave G3ZQH

Hi Dave, I checked into this and it is to do with the database merge. BandText is not copied to the merged database. Easiest way to rebuild is to select another country, and then re-select UK for example. I will need to find out why the block of code is commented out that moves this over to the merged DB.

Cheers, Richie.

[ea3aqr]

ea3aqr - this will happen if the band stack entry you are on when you left 10m was locked. As it is not saved. Previously is was actively overwriting a locked band stack entry. When you return to 10m, it will put you back on the frequency of that locked bandstack entry. Some more thought on this is required I feel as people tend to want to go back to where they were even if it is incorrect use of bandstack system. In the short term I could look for an unlocked entry in the stack, update it, select it, then you would return to that frequency. All a bit bodge really.

Richie.

Hi Richie,

I've aways had 2 locked band stacks on 10m, one for quick beacons check and one for my favorite 10m frequency. I use the band stack as a "quick memory recall", clicking on 10m button the frequency jumps from one band stack to the next one.

Previously, with band stack locked, Thetis was always returning to the last used frequency (different from band stack frequencies) on band change, nor to the closer (or last used, I don't know) band stack frequency.

Right now if I unlock my band stacks, as suggested by you, one of the band stacks is overwriten with the last used frequency. That is not usefull to my purpouse.

The problem is that Thetis is not remembering last used frequency on band change as previously.

Thanks for your great job!

[ramdor]

Jordie, at the moment the only way to do this is to add a third and unlock that and to leave the band with that one selected. There is nothing in the code to 'store last used but don't update the stack' at the moment. Previously it was always overwriting the stack entry selected even it was locked. I think it was just luck that users left the band on the same stack entry and so didn't notice the problem.

The main issue is that if you have two entries in the stack, and they are both locked they can not now be updated when you leave the band. So an 'invisible' entry has to exist somewhere. Also if you change the VFO frequency manually the band stack entry needs de-selecting so you come back to the 'invisible' one. Another thing to consider is that you may change the vfo manually to the same frequency that already exists on the stack. In this case the stack entry needs selecting. It does none of this at the moment and never has afaik. It just ignored the locked status and wrote over it.

I will look into sorting something later today, but will be a bandaid fix/change until the new stack system goes in.

Richie.

[ea3aqr]

Jordie, at the moment the only way to do this is to add a third and unlock that and to leave the band with that one selected. There is nothing in the code to 'store last used but don't update the stack' at the moment. Previously it was always overwriting the stack entry selected even it was locked. I think it was just luck that users left the band on the same stack entry and so didn't notice the problem.

The main issue is that if you have two entries in the stack, and they are both locked they can not now be updated when you leave the band. So an 'invisible' entry has to exist somewhere. Also if you change the VFO frequency manually the band stack entry needs de-selecting so you come back to the 'invisible' one. Another thing to consider is that you may change the vfo manually to the same frequency that already exists on the stack. In this case the stack entry needs selecting. It does none of this at the moment and never has afaik. It just ignored the locked status and wrote over it.

I will look into sorting something later today, but will be a bandaid fix/change until the new stack system goes in.

Richie.

I think I'm missunderstanding something, sorry but english is not my languaje and is quite difficult to me to try to explain the problem in english...

Lets forget about band stack... my problem is that when manually changing the VFO frequencies and then leaving the band, the last used frequency isn't restored when coming back. It was working fine in previous releases, right now it always returns to my band stack frequency.

I'm starting to suspect that it could be a problem with databe corruption after the Thetis update and forced database import.

[ramdor]

It is the same for me. It is because the locked entry is no longer updated. It needs a temporary fix which I will look ar after some sleep

[ea3aqr]

It is the same for me. It is because the locked entry is no longer updated. It needs a temporary fix which I will look ar after some sleep

Take it easy Richie!

Just to clarify... on band change my locked entries never changed.
On band change I was able to return to my previous used frequency and my 2 band stacks frequencies where unchanged.

[oe3ide]

I am not sure if this is intended, but it is not very userfriendly

1) changing a value in the GUI (i.e. TX low or waterfall low/high via midi controller)
2) open "Setup"
3) close "Setup" with "cancel"

=> all changes (tx low, waterfall low/high) made in step 1) are reverted to the last values. I assume since last Thetis start or last "ok"/"apply" in Setup.

I didn't check it in 21a, but I am sure the behavior was different.

How to reproduce it:

1) change agc gain via gui from 83 to 115
2) open setup (ie to check vac over/underruns) and close it with "cancel" ("cancel", because you do not have changed something in setup)
=> agc gain is reverted to 83

73 Ernst

[NJ2US]

Richie, ignore this if not a priority, (it's not), but I've noticed:

Appearance -> RX Display -> Waterfall, even if SHOW FILTER, Show Zero Line, Show TX Filter are ALL UNCHECKED, the display still initializes with Filter and Zero Line showing at "Power" on. Cycling with a checkmark, fixes it for that session.

Cheers!

Jeff
NJ2US

i9, 32GB, RTX2060, Thetis 64bit

[ramdor]

Just to clarify... on band change my locked entries never changed.
On band change I was able to return to my previous used frequency and my 2 band stacks frequencies where unchanged.

I didn't check it in 21a, but I am sure the behavior was different.

How to reproduce it:

1) change agc gain via gui from 83 to 115
2) open setup (ie to check vac over/underruns) and close it with "cancel" ("cancel", because you do not have changed something in setup)
=> agc gain is reverted to 83

73 Ernst

Jordie : if you were using 2_8_11 from 2020 then it DID change the locked bandstack frequency if you left the band on a different frequency with everything locked. It has been like that for ages.

Ernst: yes we know about this, it is not ideal at all. It has been in there like that for years.

I decided to make vid response to you both where you can see it all happening in the original 2_8_11 version from 2020.

Going forward I need people to check the old version if they think any problem has been introduced in 21x updates. Either that or just don't use the updates because as you can imagine for me to do this checking it eats into free time that could be better spent writing code.

The video : https://youtu.be/gOqkU-BNVbQ

Richie.