Page 7 of 19

Re: 2.6.8

Posted: Sat Sep 28, 2019 4:34 pm
by Tony EI7BMB
Resource monitor for Thetis C1 build currently showing 5.17 Average CPU here. CPU is Ryzen 7 1700

Re: 2.6.8

Posted: Sat Sep 28, 2019 6:46 pm
by SA3ATF
Running c1 384KHz sample rate on 50" 4k 60Hz monitor 60fps currently showing around 7% CPU here on a newly built i9 9900K @5GHz.

Re: 2.6.8

Posted: Sat Sep 28, 2019 6:47 pm
by w2ner
SA3ATF wrote:Running c1 384KHz sample rate on 50" 4k 60Hz monitor 60fps currently showing around 7% CPU here on a newly built i9 9900K @5GHz.


50" monitor???? Holy crap.

Re: 2.6.8

Posted: Sat Sep 28, 2019 7:15 pm
by SA3ATF
50" monitor???? Holy crap.[/quote]

Really like to have such a big monitor. Think there is a picture on my QRZ page on my setup. Is not up to date, but about anyway ;)

Re: 2.6.8

Posted: Sat Sep 28, 2019 7:31 pm
by ramdor
Interesting results everyone. I do not see such low cpu loads unfortunately.... yet :)

Just some thoughts on things......

When in DX mode the time taken to actually process the data is now the bottle-neck. Time taken is directly proportional to the width of your display, which determines the data returned from wdsp.GetPixels. On a system with a decent graphics card it will now become CPU bound before it becomes GPU bound. As a test internally, with limiting removed, I could run full screen panafall at over 110fps although I would only see 60 per second on this monitor. The cpu became the limiting factor, how fast it could get through that 2560 element array of pixel data.

One of the things that is a problem (or cause for change) at the moment is that everything in the Display.cs class, every single frame update, checks to see if 1 or 2 rx's are to be displayed, if the display is on the top half/bottom half in the case of panafall's, and if in CWU/CWL/DRM to apply offsets. This is just the legacy way and is how it has been coded over time. It needs a full rework, but that is for the future I think.

Anyway, some average numbers for those interested.

Collapsed view, 2554 x 440 pixels (client width/height of display area under test)
Running in VS2019 debug mode
FPS delays excluded from timings


Time spent calculating and displaying 1000 panadapter frames

no pana fill, no background (disable picDisplay checked)
GDI+ = 11500ms
DirectX = 5300ms

pana fill, no background (disable picDisplay checked)
GDI+ = 13011ms
DirectX = 6745ms (same as with background)

pana fill, with background (disable picDisplay unchecked)
GDI+ = 21900ms
DirectX = 6745ms

Summary

  • Worse case GDI+ to display 1 frame 21.9ms
  • Best case GDI+ to display 1 frame 11.5ms
  • Worse case DX to calculate and 'present for rendering' 1 frame 6.75ms
  • Best case DX to calculate and 'present for rendering' 1 frame 5.3ms
  • Using DX there is no impact in using a background image, yet it 'kills' GDI.

I'm glad everyone has seen improvement :D The DX level support has been set very low (10_0) so most graphics cards will be supported.

73 Richie,

Re: 2.6.8

Posted: Sat Sep 28, 2019 8:48 pm
by W4WMT
Hi Scott,

In Process Explorer it’s easy to spot the threads that are running DDC, DUC, and audio streams: they’re the only ones that have priority 26. Also note, your UMC thread will also be running at priority 26.

73

Re: 2.6.8

Posted: Sun Sep 29, 2019 7:49 am
by vk1hx
.

Re: 2.6.8

Posted: Sun Sep 29, 2019 1:45 pm
by w-u-2-o
Well color me jealous of all those 4's and 5's, compared to my 9%.

I'm guessing it's a matter of how many real cores your CPU has? My i7-7700k has 4 real cores whereas the Ryzen 7 1700 has 8 cores. I wonder if other folk's data can confirm or deny this wild guess?

Note that it's number of pixels that count, not the physical size of the display, although that can be impressive for other reasons ;)

However, based on my measurements here, the number of pixels in play, the FFT bin size, and the sample rate no longer seem to be strong drivers of CPU utilization when using DirectX rendering. This makes sense: DirectX and the hardware is doing the heavy lifting for rendering, and therefore all of those things are only affecting the size and speed requirements of the FFT that create the data for display. If speed claims for FFTW can be believed, it would seem the next logical step to speed things up would be to process FFTs using CUDA.

73,

Scott

Re: 2.6.8

Posted: Sun Sep 29, 2019 1:48 pm
by w-u-2-o
SA3ATF wrote:Really like to have such a big monitor. Think there is a picture on my QRZ page on my setup. Is not up to date, but about anyway ;)

I looked at your QRZ page and your new setup is beautiful! You should post a photo of it here running Thetis in 4K.

73,

Scott

Re: 2.6.8

Posted: Sun Sep 29, 2019 2:36 pm
by K0MO
Richie,

I have been using your DirectX version of Thetis 2.6.8 c1 with my ANAN-100B, 14-bit, 10.3 firmware with success. However, would like to report two issues that I hope could be fixed:

1. PureSignal doesn't work. 100B crashes when PS is enabled during TX, probably due to firmware timing issues.

2. Transmit Profiles get changed even when "Auto Save TX Profile on Thetis close" and
"Auto Save TX Profile on change" boxes are unchecked under "Setup/Transmit" tab.

Thank you and congratulations on the great Thetis updates!

73,
Manny K0MO

Re: 2.6.8

Posted: Sun Sep 29, 2019 7:19 pm
by SA3ATF
w-u-2-o wrote:
SA3ATF wrote:Really like to have such a big monitor. Think there is a picture on my QRZ page on my setup. Is not up to date, but about anyway ;)

I looked at your QRZ page and your new setup is beautiful! You should post a photo of it here running Thetis in 4K.

73,

Scott



Thanks for that Scott!
I'm just waiting for my graphics card that is not in stock yet, when it comes I will take some pictures and post here.
Have some wiring to improve too before it gets as I want it :)

Re: 2.6.8

Posted: Mon Sep 30, 2019 7:12 am
by ramdor
Hi all,

Please try

https://www.dropbox.com/s/pqoee6gqvzs0b ... 2.zip?dl=0

Cheers, Richie. MW0LGE


2.6.8 (c2)
- add: directX integration, all views implemented. display.cs will need a rework eventually
- fix: issue fixed with map2 embedded resource (Spots)
- change: picDisable code changed
- change: change to config initialisation order (setup), should fixe issues with spot system
- add: notch popup toolwindow on right click
- fix: scopes now resize arrays correctly so that drawlines knows correct limit and does not draw 'old data'
- fix: Panascope & Spectrascope views now use min/max data to display lower scope, the same as Scope view
- tempfix: CWX window now shows correctly when cat connection exists (see known issues)
- fix: autosave profile on close now obeys check box in setup form
- fix: console controls - tx profile initialised from tx profile data instead of saved control data
- change: added min to scope2 in audio.cs

UI issues:
- no scale drag on Panascope/Spectrascope
- move high SWR warning display to common point instead of 'everywhere'
- option to show/hide fps
- draw progress line on scope/scope2
- option to increase particle size in phase
- if the RF/TX passband moves outside IF, need to move at edge, or disable tx/rx
- notch: can be dragged below 0hz (wont apply the notch, but will look like it has)
- notch: can be dragged above max_freq (wont apply the notch, but will look like it has)
- notch: need to look into xvtr implications/implementation
- notch: no colour options for notches
- new link spectrum does not use correct values when band changed
- band panel will not resize correctly when app started in collapsed view. Due to panel.visible check being done before window itself is visible. Needs full rework of visible code
- if pan is used, and then TX without DUP enabled, active TX area can be off screen. Check zoom etc
- gap appears on top of filter when in panafall, related to step/top of grid
- size difference in compressed view of rx1/rx2 meters
- skin backgound lost when using track map from spot system
- issue with CWX window and selectedindex, further investigation required, temp fix implemented
- Special Panafall Mode (from spot) no longer works. (NC3Z) --- re-implement

Re: 2.6.8

Posted: Mon Sep 30, 2019 7:27 am
by SA3ATF
Exciting!
Will be testing this as soon as I get home from work tonight :)

Re: 2.6.8

Posted: Mon Sep 30, 2019 7:58 am
by Tony EI7BMB
Thanks for the update Richie . One thing I notice on start up is it reverts to the IK3VIG skin which happens to be the first one on the drop down list . Changing to my usual skin of K2GX brushed black works ok though.

Re: 2.6.8

Posted: Mon Sep 30, 2019 9:22 am
by ramdor
Tony EI7BMB wrote:Thanks for the update Richie . One thing I notice on start up is it reverts to the IK3VIG skin which happens to be the first one on the drop down list . Changing to my usual skin of K2GX brushed black works ok though.


thanks Tony. Yep, error on my part, will fix shortly

Re: 2.6.8

Posted: Mon Sep 30, 2019 9:56 am
by Tony EI7BMB
No worries Richie

Re: 2.6.8

Posted: Mon Sep 30, 2019 10:35 am
by ramdor
Tony EI7BMB wrote:No worries Richie


link updated in post above, issue sorted hopefully

Re: 2.6.8

Posted: Mon Sep 30, 2019 11:31 am
by W2SDR
I have noticed on Thetis that the transmit profile does not change on a mode change like in protocol1. I found that to be very convenient using protocol 1 because I use different TX profiles for different modes. Now with Thetis its a two step operation when I change modes.
Can this be incorporated in Thetis in the future?
Thanks,
Frank, W2SDR

Re: 2.6.8

Posted: Mon Sep 30, 2019 12:10 pm
by Tony EI7BMB
All good Richie, thanks again

ramdor wrote:
Tony EI7BMB wrote:No worries Richie


link updated in post above, issue sorted hopefully

Re: 2.6.8

Posted: Mon Sep 30, 2019 12:46 pm
by w2ner
Thanks Riche for the updates. I'm sure I speak for everyone, wish you lived closer as we all need to take you out to the pub and live it up!!

Re: 2.6.8

Posted: Mon Sep 30, 2019 1:03 pm
by SA3ATF
w2ner wrote:Thanks Riche for the updates. I'm sure I speak for everyone, wish you lived closer as we all need to take you out to the pub and live it up!!


+ 1 on this :lol:

Re: 2.6.8

Posted: Mon Sep 30, 2019 1:35 pm
by NJ2US
Pints for Richie! Cheers!
73, NJ2US

Re: 2.6.8

Posted: Mon Sep 30, 2019 3:49 pm
by K2BU
Hi Richie,
Thank you for all your work concerning the CWX issue with CAT commands. Everything appears to be stable now. One other small concern has to do with the timing between letters when running full QSK. Having full QSK on CW has been a great addition. In this mode the AGC is normally set in the Custom mode which means I should be able to hear between the dots and dashes even at 30 WPM. However this only occurs if I switch to a different AGC setting temporarily and then go back to the Custom setting. To my ears, there is a distinct difference difference between the CW timing in the original Custom setting and then changing to lets say Med AGC and then back to Custom. I hope I have explained my findings so that some one else can duplicate this. Maybe I have a setting in the Thetis setup that is wrong. Thanks in advance for reading. Again great job with the CWX situation!

"
ramdor wrote:Hi all,

Please try

https://www.dropbox.com/s/pqoee6gqvzs0b ... 2.zip?dl=0

Cheers, Richie. MW0LGE


2.6.8 (c2)
- add: directX integration, all views implemented. display.cs will need a rework eventually
- fix: issue fixed with map2 embedded resource (Spots)
- change: picDisable code changed
- change: change to config initialisation order (setup), should fixe issues with spot system
- add: notch popup toolwindow on right click
- fix: scopes now resize arrays correctly so that drawlines knows correct limit and does not draw 'old data'
- fix: Panascope & Spectrascope views now use min/max data to display lower scope, the same as Scope view
- tempfix: CWX window now shows correctly when cat connection exists (see known issues)
- fix: autosave profile on close now obeys check box in setup form
- fix: console controls - tx profile initialised from tx profile data instead of saved control data
- change: added min to scope2 in audio.cs

UI issues:
- no scale drag on Panascope/Spectrascope
- move high SWR warning display to common point instead of 'everywhere'
- option to show/hide fps
- draw progress line on scope/scope2
- option to increase particle size in phase
- if the RF/TX passband moves outside IF, need to move at edge, or disable tx/rx
- notch: can be dragged below 0hz (wont apply the notch, but will look like it has)
- notch: can be dragged above max_freq (wont apply the notch, but will look like it has)
- notch: need to look into xvtr implications/implementation
- notch: no colour options for notches
- new link spectrum does not use correct values when band changed
- band panel will not resize correctly when app started in collapsed view. Due to panel.visible check being done before window itself is visible. Needs full rework of visible code
- if pan is used, and then TX without DUP enabled, active TX area can be off screen. Check zoom etc
- gap appears on top of filter when in panafall, related to step/top of grid
- size difference in compressed view of rx1/rx2 meters
- skin backgound lost when using track map from spot system
- issue with CWX window and selectedindex, further investigation required, temp fix implemented
- Special Panafall Mode (from spot) no longer works. (NC3Z) --- re-implement

Re: 2.6.8

Posted: Mon Sep 30, 2019 5:06 pm
by w-u-2-o
K2BU wrote:Hi Richie,
Thank you for all your work concerning the CWX issue with CAT commands. Everything appears to be stable now. One other small concern has to do with the timing between letters when running full QSK. Having full QSK on CW has been a great addition. In this mode the AGC is normally set in the Custom mode which means I should be able to hear between the dots and dashes even at 30 WPM. However this only occurs if I switch to a different AGC setting temporarily and then go back to the Custom setting. To my ears, there is a distinct difference difference between the CW timing in the original Custom setting and then changing to lets say Med AGC and then back to Custom. I hope I have explained my findings so that some one else can duplicate this. Maybe I have a setting in the Thetis setup that is wrong. Thanks in advance for reading. Again great job with the CWX situation!
Chris, W2PA, wrote the QSK code. He would probably be a good resource to help out on the AGC QSK problem.

73,

Scott

Re: 2.6.8

Posted: Mon Sep 30, 2019 5:53 pm
by W1AEX
Thanks for all the work on the c2 release Richie. It's running beautifully here with the panafall doing its thing incredibly smoothly at 60fps with picDisplay.png enabled along with Fill Panadapter. Amazing!

73, Rob W1AEX

Re: 2.6.8

Posted: Mon Sep 30, 2019 11:00 pm
by vk1hx
.

Re: 2.6.8

Posted: Tue Oct 01, 2019 6:05 am
by ramdor
vk1hx wrote:
W2SDR wrote:I have noticed on Thetis that the transmit profile does not change on a mode change like in protocol1. I found that to be very convenient using protocol 1 because I use different TX profiles for different modes. Now with Thetis its a two step operation when I change modes.
Can this be incorporated in Thetis in the future?
Thanks,
Frank, W2SDR


Hi Frank,

This is on table for implementation. I mentioned this to Richie a couple of weeks ago. It is a great feature to have and like you have different profiles for different modes (digi is one of them).

Cheers mate
Phil - VK1HX


Hi both,

This is now in, direct port from powersdr. Bug squashing release hopefully over the next couple of days.

Richie.

Re: 2.6.8

Posted: Tue Oct 01, 2019 6:51 am
by nico
Hi Richie

Thanks for your fantastic work on version 2.6.8 - the UX is so much smoother and better now and I have started enjoying using the software and my anan again.

I am controlling the VFO via CAT commands and an external controller (TM2). Despite selecting the CTUN button the waterfall is smearing when changing frequency.

I do not get this issue with the waterfall moving/smearing when I use a Midi controller and select CTUN or when using the mouse and selecting CTUN

Unless there is an option that I am not selecting correctly I suspect that this is a bug - would it be PLEASE possible to look into this and replicate how CTUN works when changing frequency via Midi/Mouse?

THANKS

Nicholas

Re: 2.6.8

Posted: Tue Oct 01, 2019 8:37 am
by ramdor
nico wrote:Hi Richie

Thanks for your fantastic work on version 2.6.8 - the UX is so much smoother and better now and I have started enjoying using the software and my anan again.

I am controlling the VFO via CAT commands and an external controller (TM2). Despite selecting the CTUN button the waterfall is smearing when changing frequency.

I do not get this issue with the waterfall moving/smearing when I use a Midi controller and select CTUN or when using the mouse and selecting CTUN

Unless there is an option that I am not selecting correctly I suspect that this is a bug - would it be PLEASE possible to look into this and replicate how CTUN works when changing frequency via Midi/Mouse?

THANKS

Nicholas


Hi Nicholas,

I have added an option and made the changes.



Cheers, Richie.

Re: 2.6.8

Posted: Tue Oct 01, 2019 8:44 am
by vk1hx
.