2.6.8

ea3aqr
Posts: 270
Joined: Mon Mar 04, 2019 10:50 pm
Location: BCN

Re: 2.6.8

Postby ea3aqr » Mon Oct 14, 2019 5:28 pm

cLicari wrote:
ea3aqr wrote:ADVICE for all people having Seq errors:

After reading in Latency monitor help page, that "hard pagefaults are the most common cause of audio dropouts" I've followed one of the suggested solutions:

Disable the pagefile (windows Virtual Memory) altogether. You can disable the pagefile by right-clicking My Computer and selecting Advanced System Settings->Advanced->Performance Settings->Advanced->Virtual memory->Change. Note that if you have no pagefile, the system can run out of memory if not enough memory is available. Also the system will no longer create crash dump files in case of a system crash.


I can say that it worked for me... I don't have Seq Errors any more.


I haven't seen ANY "seq" errors since loading d1. In two days of use I have had three disconnects though. All I needed to do was click the "Power" button again and I was back up and running (ugh, now four, just had one as I was typing) again.
What OS are you running on your computer?

Carl
NX5T


Windows 10 Pro 64 bits.

It is a new build, just 15 days old:

CPU: Ryzen 3700x (8 cores and 16 threads)
Motherboard: Asus ROG Strix-E X570
GPU: Nvidia Geforce GTX 1050 Ti
Mem: 16gb of ram (3600@cl16)
SSD: 500Gb M.2 Samsung 970 EVO Plus
New call sign EA3CL
vk1hx
Posts: 184
Joined: Fri Sep 13, 2019 12:03 pm
Location: Australia

Re: 2.6.8

Postby vk1hx » Tue Oct 15, 2019 1:23 pm

.
Last edited by vk1hx on Sat Oct 19, 2019 1:14 am, edited 1 time in total.
73, Phil - VK1HX
User avatar
ULTIMAX
Posts: 50
Joined: Tue Apr 11, 2017 11:16 am

Re: 2.6.8

Postby ULTIMAX » Tue Oct 15, 2019 1:47 pm

I'm having a weird issue with Pure Signal using the 7000 blue face, everything works fine in the beginning of the QSO , then after I let go off the
PTT the pan-adapter goes blank (no signal) and the waterfall becomes all pink, at that point I turn off the radio and back on and is back to normal
until I TX again a few times and it happens again, I notice that I when I turn off the pure signal the problem goes away totally, now I do have the
Rx bypass in TX (check) and also I notice the TX att. never goes over 10db.

I try everything and nothing help, any help please.

Thank you

Al
N3YV
73's
DO2ZA Erwin
Posts: 115
Joined: Fri Apr 21, 2017 4:49 pm

Re: 2.6.8

Postby DO2ZA Erwin » Tue Oct 15, 2019 3:22 pm

Hello Guys,

i am using an Anan 200D fw 1.8 and Thetis 2.6.8 c5.
I have to switch off the Auto-ATT on Linearity/Advanced Window. I use a fixed ATT, Setup/General/ANT/Filters.
With Auto-ATT on, PS crash here after a few Minutes TX.

73 Erwin
Anan 7000DLE MK2 black, P.2 v2.1.18, WIN 10, 10.0.18362 (1903), i7-7700 @3.60 Ghz, 2x Monitor 24"@144 Hz and 1x 32" Monitor @120 FPS for Thetis
User avatar
w-u-2-o
Posts: 5539
Joined: Fri Mar 10, 2017 1:47 pm

Re: 2.6.8

Postby w-u-2-o » Tue Oct 15, 2019 3:25 pm

PureSignal related firmware crashes (firmware crash defined as having to power cycle the ANAN hardware unit), are not related to Thetis, any version. Try a different version of the firmware (usually an older version).

If you truly believe that Thetis is the problem then you need to identify what was the last version of Thetis that worked for you. Without that information nobody will be able to track down the problem (if there is one).
User avatar
ULTIMAX
Posts: 50
Joined: Tue Apr 11, 2017 11:16 am

Re: 2.6.8

Postby ULTIMAX » Tue Oct 15, 2019 4:52 pm

Scott,

in my case I'm using the latest versions of the Protocol 2 1.9 and Thetis v 2.6.8
I never use Thetis before or did the change to Protocol 2
Besides the PS doing that everything works perfect
so which FW do you recommend I try ?

Willing to try anything at this point ,,

Thank you

Al
N3YV
73's
User avatar
ULTIMAX
Posts: 50
Joined: Tue Apr 11, 2017 11:16 am

Re: 2.6.8

Postby ULTIMAX » Tue Oct 15, 2019 6:13 pm

Just uploaded the protocol 2 v.18 and all seems to be working fine, I'll keep you guys posted of my findings thanks Scott for the advice.

Al
N3YV
73
vk1hx
Posts: 184
Joined: Fri Sep 13, 2019 12:03 pm
Location: Australia

Re: 2.6.8

Postby vk1hx » Tue Oct 15, 2019 9:14 pm

.
Last edited by vk1hx on Sat Oct 19, 2019 1:14 am, edited 2 times in total.
73, Phil - VK1HX
vk1hx
Posts: 184
Joined: Fri Sep 13, 2019 12:03 pm
Location: Australia

Re: 2.6.8

Postby vk1hx » Wed Oct 16, 2019 12:41 pm

.
Last edited by vk1hx on Sat Oct 19, 2019 1:14 am, edited 2 times in total.
73, Phil - VK1HX
User avatar
w-u-2-o
Posts: 5539
Joined: Fri Mar 10, 2017 1:47 pm

Re: 2.6.8

Postby w-u-2-o » Wed Oct 16, 2019 3:44 pm

vk1hx wrote:However since the introduction of the FPS red indicator (top left corner) it flashes every time I click on the MOX (on and off) or go into Settings. I am not sure if there is an option to turn this indicator off?

In Setup > Display > General uncheck the "Show FPS" box.
User avatar
ramdor
Posts: 1468
Joined: Wed Jul 03, 2019 3:07 pm
Contact:

Re: 2.6.8

Postby ramdor » Wed Oct 16, 2019 4:52 pm

w-u-2-o wrote:
vk1hx wrote:However since the introduction of the FPS red indicator (top left corner) it flashes every time I click on the MOX (on and off) or go into Settings. I am not sure if there is an option to turn this indicator off?

In Setup > Display > General uncheck the "Show FPS" box.


this option just removes the text FPS, not the warning indicator. It is probably all the extra 'stuff' going when mox is pressed and the display thread being fairly low priority. Not really looked into it. Does it show if your frame rate is set to 10fps I wonder.

there have been a couple of changes to channelmaster and wdsp dlls since c2. Fix in calc.c where a comparison was erroneously an assignment, and some fixes in network.c transmitted packet for transverter state on an 8x dle it looks like. So dll's in c5 distrib by Doug should be good to go really and the c2/c5 dll comparison perhaps is just a red herring?

Edit: I wonder if we need a version form, that obtains version numbers from all the dll's etc... hmm

Richie.
Last edited by ramdor on Thu Oct 17, 2019 5:12 pm, edited 1 time in total.
User avatar
ramdor
Posts: 1468
Joined: Wed Jul 03, 2019 3:07 pm
Contact:

Re: 2.6.8

Postby ramdor » Thu Oct 17, 2019 3:54 pm

vk1hx wrote:However since the introduction of the FPS red indicator (top left corner) it flashes every time I click on the MOX (on and off) or go into Settings. I am not sure if there is an option to turn this indicator off?


Does the red indicator flashing matter, if ever so briefly when mox is pressed or the setup form opened? Well technically yes, and as it turns out, investigating this has potentially opened a BIG can of worms.

For the coders out there...

Using invoke on a delegate to ensure that accessing a UI control from another thread making it thread safe is one thing. However, in certain cases, trying to access a UI control from another thread, say the display thread, when the UI (main) thread is suspended due to a Thread.Sleep will just end up blocking the display thread. This is the main cause for the red indicator showing in the above case.

Can it be resolved, yes. Is it a pita to do, yes. Time for some head scratching.

Richie.
vk1hx
Posts: 184
Joined: Fri Sep 13, 2019 12:03 pm
Location: Australia

Re: 2.6.8

Postby vk1hx » Fri Oct 18, 2019 8:46 am

....
Last edited by vk1hx on Sat Oct 19, 2019 1:13 am, edited 1 time in total.
73, Phil - VK1HX
User avatar
ramdor
Posts: 1468
Joined: Wed Jul 03, 2019 3:07 pm
Contact:

Re: 2.6.8

Postby ramdor » Fri Oct 18, 2019 11:35 am

vk1hx wrote:As a suggestion to the issue? maybe have the FPS indicator check box set to disable FPS monitoring all together? Could this work? I'm not a coder so I have no idea. The other option is I go back to an older version of the application without the feature and be problem solved?

I'm not trying to be a pita.


yes both an option, the latter will 100% guarantee the removal
NC3Z
Posts: 464
Joined: Sun Oct 29, 2017 8:57 pm
Location: Merritt, NC

Re: 2.6.8

Postby NC3Z » Fri Oct 18, 2019 11:40 am

vk1hx wrote: Why have the FPS red indicator in the first place?


This was added by Ritchie during his excellent work on making improvements to Thetis, this was a very useful tool for diagnostics and troubleshooting when Ritchie was addressing bug reports from the field.

It culminated in the much needed implementation of DirectX.
Gary NC3Z
User avatar
w-u-2-o
Posts: 5539
Joined: Fri Mar 10, 2017 1:47 pm

Re: 2.6.8

Postby w-u-2-o » Fri Oct 18, 2019 12:01 pm

Until there is a mechanism to automatically limit display update rates when certain threads are overloaded/oversubscribed, the red box is HUGELY important because it is the only way to know if you've increased display update rates too high for your PC to handle. Indeed, it has already proven itself invaluable for not only detecting the gross problem of too high a display rate, but is also detecting fussy little details like blocked threads during RX-TX-RX transitions. Truly a BRILLIANTLY simple and valuable innovation--thank you again, Richie!

Right now we have the following diagnostics for detecting oversubscribed processors and networks:

- The red box (shows certain blocked threads)
- Seq error indicator (shows packet loss in the hardware-to-Thetis direction)
- OOOPs counter (shows packet loss in the hardware-to-Thetis direction)

I, for one, have absolutely no desire to turn any of it off, and desire even more. Indeed, I'd like the equivalent of a Seq detector for packet loss in the Thetis-to-hardware direction (but this will require more firmware, i.e. Rick to come out of "retirement" ;) )

73,

Scott
User avatar
nico
Posts: 22
Joined: Wed May 22, 2019 9:06 am

Re: 2.6.8

Postby nico » Fri Oct 18, 2019 1:24 pm

w-u-2-o wrote:Until there is a mechanism to automatically limit display update rates when certain threads are overloaded/oversubscribed, the red box is HUGELY important because it is the only way to know if you've increased display update rates too high for your PC to handle. Indeed, it has already proven itself invaluable for not only detecting the gross problem of too high a display rate, but is also detecting fussy little details like blocked threads during RX-TX-RX transitions. Truly a BRILLIANTLY simple and valuable innovation--thank you again, Richie!

Right now we have the following diagnostics for detecting oversubscribed processors and networks:

- The red box (shows certain blocked threads)
- Seq error indicator (shows packet loss in the hardware-to-Thetis direction)
- OOOPs counter (shows packet loss in the hardware-to-Thetis direction)

I, for one, have absolutely no desire to turn any of it off, and desire even more. Indeed, I'd like the equivalent of a Seq detector for packet loss in the Thetis-to-hardware direction (but this will require more firmware, i.e. Rick to come out of "retirement" ;) )

73,

Scott


+1 and yes VK1HX you are being a bif of a PITA ;-)
User avatar
ramdor
Posts: 1468
Joined: Wed Jul 03, 2019 3:07 pm
Contact:

Re: 2.6.8

Postby ramdor » Fri Oct 18, 2019 6:08 pm

Hi all,

Just a quick build as arm/body slowly returns to life :D :lol:

Please try : https://www.dropbox.com/s/dq27g8ylpae5i ... 2.zip?dl=0

Quite a few changes that are not really visible in the UI, so please test things that update VFOs split etc. I have hammered it quite a bit but still could have missed something. Also a first pass of a combined TX ALC/ALC_COMP meter called ALC GROUP on EDGE meter only atm (a Scott wish list :) ). Name to be decided on, and perhaps the scaling if someone wants to draw out a suitable scale or give it a name.

Something to note. It is quite possible to load your PC in such a way that a thread with below normal thread priority will not 'get a chance' to run, and permanently stay in a suspended state. I noticed this when using JTDX and capped out the decode threads, my PC would load to 100% and the spectrum would stop being updated, everything else in Thetis working as expected. Now there is an option to raise the priority of the draw/render thread so you ensure that the spectrum gets updated. Mileage may vary depending on how you set it, and how powerful your PC is.

Next on the list is to sort out the saving/loading and to give visual feedback during the save process. Also, I wonder what your opinions are on adding a status bar to the bottom of the expanded Thetis window, moving clock, cpu/volts/amps, SEQ errors, PS status, window size etc etc there, all along the bottom.

Anyway, that is it for now. 73 Richie.

(10/7/19) d2
  • change: vfoa/b/suba now all use property get/set with single point of text conversion, and member variables to hold frequencies instead of direct access to text boxes
  • add: thread priority setting for display thread in setup->Display->General->Driver Engine
  • fix: reading certain UI controls from display child thread would block the child thread if main UI thread was suspended due to a Thread.Sleep. Text boxes were the main issue it seems. This caused the red warning indicator to flick when entering TX(mox) due to Thread.Sleep(rf_delay). It really is a bad idea to sleep the main UI thread, but leaving as is for now
  • add: first pass of combined ALC and ALC_COMP transmit meter, called ALC_GROUP, a good name required? Initial implementation on EDGE meter appearance only

Full change log : https://docs.google.com/document/d/1xh4 ... 5-ibeIBt_k
DL8LAQ
Posts: 212
Joined: Sun Apr 09, 2017 3:28 pm
Location: JO43XU

Re: 2.6.8

Postby DL8LAQ » Fri Oct 18, 2019 6:46 pm

ramdor wrote:Also, I wonder what your opinions are on adding a status bar to the bottom of the expanded Thetis window, moving clock, cpu/volts/amps, SEQ errors, PS status, window size etc etc there, all along the bottom.


Thumbs up for a status bar :-) Thank you, Richie.
73, Norbert - DL8LAQ - ANAN-G2 w/display - Richie's latest Thetis version and pihpsdr by N1GP&DL1YCF
SA3ATF
Posts: 95
Joined: Mon Apr 10, 2017 9:42 pm
Location: Vasterasen, Bispgarden, Sweden JP82HX
Contact:

Re: 2.6.8

Postby SA3ATF » Fri Oct 18, 2019 6:56 pm

Wow, more news, thank you so much Ramdor!
It seems to work great.

One thing I noticed at the first d revision is that if you have CTUN enable and restart the radio then the passband is always start in the middle of the window and not where I left it.

As far as adding a status bar to the bottom of the expanded Thetis window I think sounds like a very good idea.

Thanks again and happy weekend to everyone from Sweden :P
I don’t suffer from insanity, I enjoy every second of it!
User avatar
Tony EI7BMB
Posts: 651
Joined: Sun Apr 09, 2017 2:31 pm
Location: Dublin
Contact:

Re: 2.6.8

Postby Tony EI7BMB » Fri Oct 18, 2019 8:08 pm

Are these still visible in Thetis Scott ? I remember OOPS in powersdr but don't see it in Thetis ?

w-u-2-o wrote:- Seq error indicator (shows packet loss in the hardware-to-Thetis direction)
- OOOPs counter (shows packet loss in the hardware-to-Thetis direction)

User avatar
w-u-2-o
Posts: 5539
Joined: Fri Mar 10, 2017 1:47 pm

Re: 2.6.8

Postby w-u-2-o » Fri Oct 18, 2019 9:03 pm

Ooops! You are right, Tony. Only Seq errors on Thetis. How very unobservant of me!

BREAK

Richie--I hope this finds you fast on the mend! Question: is the packet reordering code from PowerSDR ported into Thetis? If not, then it probably should be.

Explanation: it was discovered some time ago that certain NIC protocol stacks had the propensity to deliver up UDP packets to the application layer with the UDP packets out of order. Although it never seemed that it was more than a couple of packets swapped, Warren and Doug added in a user adjustable packet reordering facility into PowerSDR that buffers from 0 (off) to 4 (max) packets and then reorders those packets as necessary before passing them deeper into the application. There was also an out of order packet (OOOP) counter that totaled up the instances of this so that you could know there was an issue, even if the packet reordering mechanism was making everything OK.

73,

Scott
NC3Z
Posts: 464
Joined: Sun Oct 29, 2017 8:57 pm
Location: Merritt, NC

Re: 2.6.8

Postby NC3Z » Sat Oct 19, 2019 12:03 pm

ALC_GROUP Where should the target level be for this new metering?
Gary NC3Z
NC3Z
Posts: 464
Joined: Sun Oct 29, 2017 8:57 pm
Location: Merritt, NC

Re: 2.6.8

Postby NC3Z » Sat Oct 19, 2019 12:06 pm

Priority setting for display thread - I noticed on mine it picked up the level as Below Normal, is this where it was hard coded before this option?

I have since selected Normal.
Gary NC3Z
W4WMT
Posts: 325
Joined: Sun Apr 09, 2017 10:12 pm

Re: 2.6.8

Postby W4WMT » Sat Oct 19, 2019 12:52 pm

Hi Scott,

I don't know much, but this is what I do know: The "OOOPs" counter in openHPSDR/PowerSDR is a packet serialization fault indicator for packets coming OUT of the packet reordering (PRO) algorithm, that is if an out-of-order packet coming in from the radio is able to be put back into correct order by the PRO, the OOOPs counter does not increment. It was done that way to give users the means to adjust the PRO Latency setting as low as possible for a given computer system. Also, the OOOPs counter was located on the VAC1 form to serve as a go/no-go indicator for the adaptive variable resampler, i.e. dropped packets inbound from the radio leave no hope for the resampler. Dropped packets will drive the resampler matching loop absolutely bonkers!

This might be a good time to circle back and see what Warren thinks about implementing the PRO system in Thetis. At the time, the devel team leaders (W5WC & NR0V) had already made the conscious decision to cease feature development in PowerSDR to focus entirely on Thetis. So Warren must have had a good reason to implement the PRO system in PowerSDR and not Thetis. Maybe Warren is reading this topic?

In PowerSDR the PRO is located in the JanusAudio project which, of course, doesn't exist in Thetis due to the advent of The ChannelMaster. If the PRO were to be implemented in Thetis, I'm guessing it would have to go into The ChannelMaster.

73, Bryan W4WMT
User avatar
ramdor
Posts: 1468
Joined: Wed Jul 03, 2019 3:07 pm
Contact:

Re: 2.6.8

Postby ramdor » Sat Oct 19, 2019 2:35 pm

NC3Z wrote:Priority setting for display thread - I noticed on mine it picked up the level as Below Normal, is this where it was hard coded before this option?

I have since selected Normal.


yes this was the hard coded setting before

the ALC_GROUP meter, is a sum of ALC and ALC COMP, something that Scott asked for. If above 0db there will be some ALC compression.

Richie.
NC3Z
Posts: 464
Joined: Sun Oct 29, 2017 8:57 pm
Location: Merritt, NC

Re: 2.6.8

Postby NC3Z » Sat Oct 19, 2019 2:50 pm

ramdor wrote:yes this was the hard coded setting before.


Preferred setting then, Normal??
Gary NC3Z
NC3Z
Posts: 464
Joined: Sun Oct 29, 2017 8:57 pm
Location: Merritt, NC

Re: 2.6.8

Postby NC3Z » Sat Oct 19, 2019 2:51 pm

ramdor wrote:the ALC_GROUP meter, is a sum of ALC and ALC COMP, something that Scott asked for. If above 0db there will be some ALC compression.


Scott - Any words of advise on how we should be using this metering?
Gary NC3Z
User avatar
w-u-2-o
Posts: 5539
Joined: Fri Mar 10, 2017 1:47 pm

Re: 2.6.8

Postby w-u-2-o » Sat Oct 19, 2019 3:06 pm

NC3Z wrote:
ramdor wrote:the ALC_GROUP meter, is a sum of ALC and ALC COMP, something that Scott asked for. If above 0db there will be some ALC compression.


Scott - Any words of advise on how we should be using this metering?

First: Brian, thank you for the clarification. I'm pretty sure that packet reordering is needed in Thetis. I know that Warren is away right now and probably not reading this, so don't expect a quick response there.

Second: Gary, I'm not seeing an "ALC Group" meter option in d1, and that's not how I'd recommend it to be implemented anyhow.

The problem is that ALC metering is hopelessly convoluted in PowerSDR and, as a carry over, in Thetis. Any ALC meter on any other radio simply reads from say -30 to +10dB, and it will display ALC action across that entire scale. Instead on PowerSDR/Thetis, the two parts of the scale are split across two meters such that ALC reads up to 0dB and stops, and ALC Comp reads down to 0dB and stops. That's just silly, and makes it difficult to see exactly how ALC is being operated, as you need to look at both meters in turn.

My recommendation is to eliminate the ALC Comp meter entirely and make the ALC meter read above 0dB in accordance with whatever internal data currently drives the ALC Comp meter. There is no need for a third kind of metering. The intent is to simplify, not complicate. However, it sounds like the ALC Group meter is doing what I suggested. If that is the case, delete the existing ALC and ALC Comp, rename ALC Group simply ALC, and enjoy!

73!

Scott
NC3Z
Posts: 464
Joined: Sun Oct 29, 2017 8:57 pm
Location: Merritt, NC

Re: 2.6.8

Postby NC3Z » Sat Oct 19, 2019 3:19 pm

w-u-2-o wrote:Second: Gary, I'm not seeing an "ALC Group" meter option in d1, and that's not how I'd recommend it to be implemented anyhow.


That is because you are using an "old" version of 2.6.8. It was added in D2.
Gary NC3Z

Return to “Thetis”