![Sad :(](./images/smilies/icon_e_sad.gif)
![Wink ;)](./images/smilies/icon_e_wink.gif)
ramdor wrote:Hi folks,
....
However, just a small teaser...
...
w-u-2-o wrote: I use this all the time to monitor a frequency or two in the afternoon when I am working.
Tony EI7BMB wrote:Thanks Richie , running at 144 now with acc timing enabled with no red indicators . CPU up by a few per cent but nothing to worry about.
sv1jso wrote:but very close to saturate one core.
ramdor wrote:UPDATE
HI all,
Small update with the peak indicators, and a couple of other bits and bobs. Most of it is only implemented in DirectX at the moment. The peak detect is a simple algorithm, and does not use crossing point/smoothing/slope.
Quite handy for this sort of thing, with PS on :
psON.png
Also, an experimental change to frame rate calculations that can be enabled with 'accurate frame timings' option. However, It sits in a very tight loop until the expected delay has passed and consequently is quite cpu hungry. It is perhaps only worth using if you have a work horse of a PC and want to test if it improves the micro-stutter in the waterfall.
Link : https://www.dropbox.com/s/psqkr8p22m8g1 ... 2.zip?dl=0
Cheers, Richie.
(11/19/19) b2
-add(*): peak markers on the panadapter. Configure through Setup>Display>General. Note: this is a very simple algorithm and does not consider slope
-add(*): experimental accurate frame timing. This will probably have a substantial impact on cpu usage
-change(*): if a timed waterfall update is ‘late’ the next update will be made ‘early’
-change: now using hiperf timer in RunDisplay
(*) only implemented in DirectX atm
sv1jso wrote:Tony EI7BMB wrote:Thanks Richie , running at 144 now with acc timing enabled with no red indicators . CPU up by a few per cent but nothing to worry about.
What cpu do you use? Could you please tell me the difference per logical processor? I have a twelve core processor and one core goes up from 20% to 90% Of course combining all of them is a few percent in total but very close to saturate one core.
Regards
ramdor wrote:sv1jso wrote:but very close to saturate one core.
It will, which is why I dont really recommend using it. It should jump around perhaps from core to core as it is not fixed to a specific one, at least that is what I see on this 3800X processor. It is purely experimental and will probably be removed at some point.
Unfortunately using Thread.Sleep for a short time delay, say 16.odd ms for 60fps, whilst removes the load on the cpu does not guarantee that the thread will resume when we want. This is one of the main reasons for the jitters that can be seen sometimes in the waterfall. Games and what not don't really care and just run a tight loop to give timed physics and fps stability.
Also, in cases such as 60fps, the delay required is 16.66666r ms, less the time it took to draw the frame, and Thread.Sleep takes an integer. The next version (b3) will see this fraction accumulated and applied, but still does not fix the fundamental problem that Thread.Sleep is not a guaranteed accurate time delay.
I will keep researching it, but at the mo there doesn't really seem to be an ideal solution. It is only noticeable in the waterfall due to the nature in which it fix rate 'falls'. It is quite impossible to see anything odd happening to the panadapter for example.
Edit: b3 will also see the thread.sleep timed, and any late return from it will be removed from the next frame delay. Blimey... should have thought of this a while ago.. sheesh, lol.
Richie.
ramdor wrote:Hi Perry
I had a quick look at the cpu% code and it is currently reporting total cpu% usage of the entire system, which is why we tend to use resmon or something similar to find out how much Thetis is actually taking. I have quickly changed it to reflect the process %cpu that is being used by Thetis. This calculation is an averaged value based on 'cpu count' in the system and will more accurately display how much % thetis is actually using. It now shows the same value as ResMon +- 1%
I have been thinking about the warning symbol for seq errors and may change it to only show it if there are -ve numbers. Positives alone are somewhat meaningless, only telling us that there has been some missing packets. I don't think we have yet seen any major repeatable widespread occurrences of -ve value patterns that could be fixed by an implementation of the pack reordering system.
I wouldn't worry about where the threads are running, we don't set any affinity, so they get scheduled onto which ever processor (core/virtualcpu) the OS thinks is best. As a result you may see a peak on one compared to others(s).
73 Richie.
ramdor wrote:Hi Carl,
I have added option to pick which one you want. Right click the cpu in status bar.
Also working on this at the mo, for some extra eye candy. Probably all released later tonight or tomorrow.
73 Richie.
w-u-2-o wrote:You can get your "alarm" right now, as long as the "selectable bandwidth" is 20KHz or less. Just turn on the squelch and set the level as desired. When a signal breaks squelch you will hear it. I use this all the time to monitor a frequency or two in the afternoon when I am working.
DO2ZA Erwin wrote:Hi all and Ritchie,
at first 2.6.9 b2 is running perfekt here, many thanks !!
Right Click on CPU in Status-Bar ?? No funktion here??
Sometimes I have a problem to save my Setting in the Database, here it is on DSP - Options, the Filter-Type. Sometimes it is saved, some
time not?? (B1 Version).
73 Erwin
wa1oxt wrote:WOW , so much fun Richie.
Look's great.
What's next ......a 3D Waterfall ?
tnx.
wa1oxt / /garyradio
ramdor wrote:wa1oxt wrote:What's next ......a 3D Waterfall ?
wa1oxt / /garyradio
Hah yes it has been running around my head for a while. A 3d landscape that moves into the background over time, a new 'row'/'land' added at the front. On my personal list, perhaps never to be crossed off, but it is on there