SDR# SDR# Plug-in: Frequency Scanner updated

[Samg381]

How do I scale the vertical area in the channel analyzer? Am I really expected to be able to make any meaningful adjustments to the red/yellow lines when my screen looks like this?



The scanning for the air band is also ineffective.. after significant tweaking to get the scanner to even select the proper transmissions, all I hear is static.

 

[morfis]

How do I scale the vertical area in the channel analyzer?

Currently you don't. You can zoom the display from the controls which may help a bit

Am I really expected to be able to make any meaningful adjustments to the red/yellow lines when my screen looks like this?

Yes. That is how Vasili designed the plugin display

The scanning for the air band is also ineffective.. after significant tweaking to get the scanner to even select the proper transmissions, all I hear is static.

This is unusual as the majority of users seem to use the plugin almost exclusively for airband scanning. Something is not correct in your settings.

 

[radiostationx]

Am I really expected to be able to make any meaningful adjustments to the red/yellow lines when my screen looks like this?

I cannot see any red or yellow lines, in the channel analyser window perhaps that is the issue.

 

[mw0cqu]

Hi All,

There seems to be differences of opinion about different builds of frequency scanner so I thought,
as I had a new I7 based PC running my airspy 2.0, I should do some comparative testing.

And the results are interesting , so I thought I would share them in the hope it helps other users and
Messrs Wraith / Vasilli

My metrics were:

People want usability
People want the fastest scan rate

My caveat is that I hate the new UI (dont re-write a hit!) which came in at SDR# version >1700 , so I baselined my findings on
V1700.

So then I had to think about what to measure?

Three key metrics came to mind

* height of noise floor displayed on the screen - because the narrower the noise floor and height of relative signal peaks, the
harder to set the red and yellow lines accurately - I chose centimetres as my scale and have an accurate monitor calibration of 92 dPI
(measured with a ruler and Quark Xpress )

* Height of highest peak relative to noise on graticule - the higher the peak above the noise, the easier it is to detect and adjust
I took the graticule scale as my metric

* Scan Rate - pick a wide frequency range and measure the highest scan speed reported - I chose Mil airband - 230-400. mainly because
here in the UK 380-400 is assigned to emergency services with some BIG signals and I wanted to see how the scanner coped with the dynamic range. For this I just used the debug figures

So the results :

Column A - Plugin version number (dots removed)
Column B - Reported time to scan (in MHz per second) 230-400Mhz in 25KHz steps
Column C - Height of noise floor (cm) displayed on monitor
Column D - Height of highest peak signal on graticule
Column E - other observations



So what did I learn ?

* The change in displayed noise floor height came in with version 2.0.0.0

* versions above 1.4.4.0. showed speed increases but the dynamic range displayed was lost, making it much harder to detect signals due to less visible SNR, and much harder to set the red line.

* The outright fastest version was 2.2.2.0


Based upon my findings here, I will be going back to 1.4.4.0 with SDR# 1700 , yes its 20MHz / second slower but if it trips more signals I can live with that.

As they say on the BBC "Other opinions are available" - these are not definitive, but I hope it gives some real world user metrics to help people
decide which version to use for their own purpose

73 de 'CQU

 

[mw0cqu]

just to back up my figures:

Here's a screenshot clip of V 1.4.4.0, specifically the top end of the mil air spectrum where there are large constant carriers
here in the UK:



Those large 25KHz TETRA carriers are clearly visible, head and shoulders above the noise, and implicitly easy to lock out !

However, when I revert to 2.7.7.0:



yes its faster , but its now "so fast" it seems (and my "in use" experience here backs it up) to no longer to accurately sample the spectrum,
to detect carriers - so implicitly it seems, the 20MHz / second speed hike has come at the cost of display accuracy, and potentially carrier detection ?

I would be very interested for others to share their findings.

I'm tempted to go back through the last few releases of SDR# and see which one is the fastest with 1.4.4.0 - but I do actually "have a life"

73 again de 'CQU

 

[morfis]

Interesting.
No time to do a comparison like that at the moment, but the TETRA signals show NO difference in signal strength here. Looking at your screenshots I wish I could have a day with them as low as your high ones

 

[mw0cqu]

if you had seen the multistage filter chain I have on the input to the LNA feeding this , you wouldn't!

Cavity filters for Pager, DAB and TETRA ,
2 x series bandstop filters for Band II FM

 

[thewraith2008]

You seem to be misunderstanding how the dynamic noise floor is used here.

First image is using 'static noise floor' and shows the noise and the TETRA BS constant carriers.

The second image is using 'dynamic noise floor' and is not showing as much noise or the TETRA carriers because they have been null out.
Depending on scan mode used, the use of 'dynamic noise floor' can help eliminate detection of constant carriers (trunking, birdies or other noise) during scan. In theory, you should be only seeing the active signal above the 'noise floor'.
A few Milscanner users swear by 'dynamic noise floor'.

When scan is first started, one pass is made (of all ranges selected to scan) and levels are taken to use as a baseline.
On following passes, any signal above that baseline is considered to be the active signal and is shown as SNR value.
This is a simplification of how this is done but hopefully gets the point across.

The use of the trigger (red) and hysteresis (yellow) is not rocket science, I find setting red lower than approx 13 begins to start stopping on noisy active transmissions.
I use approx red:13, yellow:6.

The standard scanner plug-in (Vasili's and earlier updated versions by me) only uses 'static noise floor'.
A special version Vasili made (Airspy version) and later updated versions by me use either 'static noise floor' or 'dynamic noise floor'.

As it stands now with the latest version available here, it's a merger of both Vasili's plug-in versions (standard and Airspy) with the fixes for the bugs and the addition of some optional features and tweak for the UI when used with later SDR# version.



Latest version (v2.2.7.0) can be found here: MEGA - Download

 

[mw0cqu]

Thanks for the clarification thewraith

So with that in mind I have reloaded 2.7.7.0:

static Noise Floor:



stopped scan , switched to dynamic , restarted scan, let the first pass run through:



nowhere near as much detail in the blue as I get in 1.4.4.0 (see previous post)

So I set up two identical vanilla copies of sdr# 1700 in two adjacent folders on the desktop
put 2.7.7.0 in one, 1.4.4.0 in the other (more fun than lockdown lunch !) .

Both airspys are connected to a common antenna chain via a stridsburg 4 port multicoupler (spare ports terminated R50)

I set "candidate 1" (1440) to stream from the left speaker and candidate 2 (2770) from the right

fine tuned red and yellow on both....

then started scanning on both instances

and 1.4.4.0. whipped 2.7.7.0 - totally! , it was fortunate 2 copters were working a JTAC about 50 miles away at the time . 1.4.4.0 got it every pass almost without fail - 2.7.7.0 got it maybe one pass in 5 or 6. even after tweaking the levels to favour it .

On that basis , and that basis alone, I will be sticking with 1.4.4.0 and sdr# 1700.

Please understand - not trolling / knocking your work - just sharing my real world experiences of using these plugin variants

73 de CQU

 

[thewraith2008]

You are free to use it how you like and what best suits your situation.

What do you see if you run 2.2.7.0 with static noise floor with 1.4.4.0.
I find it strange if you got different results because the base scanner code is the same with these two versions.

Just a note that in you images, you don't seem to be using much hysteresis.
You may benefit by having the yellow line around the 6 mark.
Having the two lines so close together would make detection a bit flakey. Mobile transmitters would be worse as they would fluctuate all over the place changing the detected state quite quickly.



Latest version (v2.2.7.0) can be found here: MEGA - Download

 

[Magpie]

Very interesting to read thank you for that. I do need some help here.

I currently use v1672, v1700 and v1716 in combination with Vasili's last fastscanner. That works great. However I'd like to use a newer fastscanner from thewraith. I don't need freqlogging or any fancy stuff but I do need Dynamic Noise Floor. Which fastscanner version should I install? And which Ms Detect value should I use. I'm on 50 currently but I've used lower values too. Any advise is much apprecicated. Mtia.

 

[Magpie]

I tried v1700 with 2.2.7.0 but found that scanning 230.000 - 389.975 showed incorrect freqs in the display. For instance 300.100.500 (MHz) instead of 300.100.000 (MHz). Stepsize is 25000. Am I doing something wrong here? Mtia.

 

[thewraith2008]

Very interesting to read thank you for that. I do need some help here.

I currently use v1672, v1700 and v1716 in combination with Vasili's last fastscanner. That works great. However I'd like to use a newer fastscanner from thewraith. I don't need freqlogging or any fancy stuff but I do need Dynamic Noise Floor. Which fastscanner version should I install? And which Ms Detect value should I use. I'm on 50 currently but I've used lower values too. Any advise is much apprecicated. Mtia.

The addition features are optional.
How about the latest - v2.2.7.0
The setting of the 'Detect' value I find varies on SDR used, PC CPU and it's current load (of system).
I can sometimes set it to 1 with Airspy R2 other times to about 17 but a higher value is needed when CPU is loaded.

I tried v1700 with 2.2.7.0 but found that scanning 230.000 - 389.975 showed incorrect freqs in the display. For instance 300.100.500 (MHz) instead of 300.100.000 (MHz). Stepsize is 25000. Am I doing something wrong here? Mtia.

If start range is 230.000 with 25000 step size, then frequency 300.100.500 is not valid.
..
300.075.000
300.100.000 (+25000)
300.125.000 (+25000)
..

Where is this 'bad' 300.100.500 frequency displayed. The VFO or in the channel analyzer window (the active frequency or frequency at mouse)
I tried here but could not see 300.100.500 been displayed.



Latest version (v2.2.7.0) can be found here: MEGA - Download

 

[Magpie]

The bad freqs are shows in the SDR# screen. This is not new but until now I was able to avoid them by finetuning my searchranges. Usually making freqranges in 8 MHz does the trick. I didn't succeed now. I wonder what ranges other monitors use and if they see bad freqs on the screen.

 

[ATCTech]

Magpie, do you have SDR# "Snap to Grid" off or on when this happens? I'm trying to figure out if that setting interacts with the scanner plugin for better or worse.

 

[Magpie]

Yes I have on at 25 kHz.

FYI I did a lot of testing with scanranges in combi with Vasili's fastscanner. I found that an even number of scanranges should be 8 MHz long. For instance 230.000 - 245.975 (= 230.000-237.975 and 238.000-245.975). The last range of an odd number of scanranges best look like this: 396.500-404.500 (instead of 396.500-404.475). Hope this helps.

 

[ATCTech]

Thanks for confiming the setting. I'm not having any problem with scan ranges. I've just noticed in the past few weeks that certain settings in SDR# (like "Snap to Grid") don't seem to 'stick' in certain but as of now unknown combinations of operation. When that setting isn't enabled the frequencies displayed when scanning can be off by any number of Hz but it doesn't seem to affect the centering of the scan results or require any limitations to the width of the scan range. (Using an Airpsy here with various release of SDR# from 1490 to 178x.)

 

[Magpie]

Thanks, I'll re-check the Snap to Grid settings.

 

[ATCTech]

Magpie, here's what I see happening:

- Start SDR# then select the appropriate step size for the range you're going to scan.

- Enable Snap to Grid.

- Sweep mouse pointer across either spectrum or waterfall display, frequencies displayed alongside the pointer as mouse moves are in selected step size.

- Select the Frequency Scanner plug-in, select desired range to scan, click SCAN.

- Note the SDR# Snap to Grid option immediately disables. Moving the mouse pointer across spectrum or waterfall displays non-step size frequencies .

- Stop the Frequency Scanner plug-in when actual activity causes the scan to pause on a carrier. The display automatically centers on the frequency the scan was stopped at. Slowly move mouse pointer across spectrum or waterfall. Frequencies displayed beside pointer are not at the previously selected step size however when mouse pointer hits onto the exact frequency the scan stopped at it will be at the expected value and display as (for example) VFO: 132.8000MHz. Any other frequency highlighted by the moving the mouse pointer will NOT be displayed at the expected step value. (132.9516 for example when there had also been an active on-air carrier at 132.9500 at the same time.)

- SDR# Snap to Grid does NOT re-enable when the plug-in scan was user-stopped, which is what throws me off when I want to manually select a frequency using the mouse/mouse wheel in a hurry.

Clearly the plug in isn't using user-selected steps to scan with, which is not a problem as far as I'm concerned but not restoring the SDR# Snap to Grid item when the plug-in scan is user-stopped is what was confusing me.

I don't see any other issues, and I'm not so sure even this is an issue but it is optically confusing when you use the mouse to look through a chunk of spectrum during after a scan is run, especially when the user knows the step values for the band being scanned and expects activity displayed by the mouse pointer to conform to the band plan. I guess if the user is looking at (or looking for) for off-frequency-step carriers the plug-in NOT having specific display steps enabled is actually an advantage, but I'd like to see the plugin work IN steps when the SDR# option is enabled but NOT use defined steps when it's not enabled prior to the scan starting. Maybe too much to ask?

 

[Magpie]

Thank you for this explanation. I didn't realise that the Snap to Grid value is not linked to the step size in the fast scanner.
I always have it at 25 kHz but reading your message I now understand there's no real need for that. Thanks again.