Spectrum Analyzer Persistance

WA2ZKD

One of my users who was doing some A/B testing on antennas passed along this comment

When tuned to a signal, enable the spectrum function.  Then, disconnect the antenna.  The time for the display to decay down to the noise floor is quite long.

jks

The current spectrum filter is a non-linear one from Rocky (Alex, VE3NEA). See http://www.dxatlas.com/rocky/advanced.asp

Markone

Hi John,

i know very well Rocky from VE3NEA, i used it a lot many years ago with my early
Softrock kits and i remember very well that its spectrum decay time is
much faster than Kiwisdr spectrum display.

As James,  i was too wondering if there is the possibility to modify its time constant, maybe changing some Beagle configuration file via SSH connection.

jks

In a very early version of the software the spectrum averaging had several choices. From no averaging, which was very noisy, but reacted instantly to changes, to simple averaging with a time constant adjustable with a slider. And the time constant for the non-linear filter was also slider adjustable.

I use the same time constant as Rocky, but I think because my waterfall update rate is less this results in too slow a response. There are also (still) glitches in the spectrum when changing frequency/zoom that I haven't been able to fix.

Markone

I just downloaded the last Rocky release and played a bit with it, it's spectrum graph is way faster then Kiwisdr, by orders of magnitude, as i was remembering.

Currently Kiwisdr spectrum takes something like 60 seconds to fall down after a signal drop, that seems way too much.

Can i modify the time constants / averaging factor in a fixed way simply changing a configuration file under Beagle file system, or such settings are "hard coded" in the source code and require a system re-build ?

KA7U

This discussion is interesting to me because I use the latency of the spectrum graph to "see" what has been for a time. If it were real time, spectrum activity wouldn't leave a footnote, as it were. So if this is to change, I hope that it is changed with an adjustable latency slider, or averaging slider, whatever it is to be called.

Ron

KA7U

jks

Okay, go to one of the three Kiwis mentioned in the "demo of new user interface" thread. Bring up the spectrum. Open the extension called "devl" (development). In the first input field enter a number to replace the -0.2 exponential decay time constant used in the Rocky non-linear formula. Try e.g. -0.3 to -0.8 to make the spectrum recover faster. The parsed value you type will be echoed in the second field as a format check.

Try this for a strong AM signals zoomed in to, say, z11. -0.8 will look pretty good. But then when you look at the whole spectrum (z0) the -0.8 value seems to be too fast. This could definitely be an item to add to the (future) user preferences list. With maybe some optional scaling to the zoom level.

G8JNJ

Hi John,

Would it be possible to add something like a fast acting  white 'peak' value 'outline' behind the coloured spectrum graph, so that it's easy to see fast changes whilst still retaining the decaying 'what was there' coloured spectrum graph. 

Then when the 'Slow Dev' waterfall is selected, just the white graph could remain.

Regards,

Martin - G8JNJ

G8JNJ

Hi All,

Some other thoughts.

-0.5 seems to be a good compromise.

However why not vary the time constant with the waterfall speed slider. So that when it's running very slow the spectrum value is -0.2 or longer and when it's running at the normal speed the value is -0.8. By doing this the spectrum graph would always respond slightly faster than the waterfall, which is probably how it would mostly be used.

Regards,

Martin - G8JNJ

WA2ZKD

I also use the S-meter extension for related things

Markone

I gave a try to http://kiwisdr.jks.com:8073/ Kiwi, testing different exponential time constant values, my compromise setting was around 1.0, but with faster refresh rate (than the current maximum one) would a lot higher.

I think that the main issue pertains to the asymmetrical attack versus decay spectrum ratio, attack is almoast instant while decay is in a different order of magnitude.

The result is that increasing the exponential factor to obtain a live spectrum representation renders the graph base line very prone to suddenly rise to very high level with lightning, ionosonde and pulsing noise occurring.
A possible solution would be to implement separate attack and decay time constant settings, even better if differentiated for spectrum an waterfall functions, in the Sdr# style.

I have a question for John :

waterfall stuttering and slow refresh rate are due to Beagle computational constrains or  the consequence of the choice to limit the network bandwidth ?

I already know that waterfall to audio synchronization brought to a worst update behaviour, the option to disable this mechanism in favor of more constant update rate could be a nice to have point.

G8JNJ

Hi Jim,

"I also use the S-meter extension for related things"

So do I - I just wish it had better resolution for antenna testing.

Average, Max and Min traces would be good too :-)

Regards,

Martin - G8JNJ