SDR# SDR# Plug-in: Frequency Scanner updated

[thewraith2008]

Thanks for quick fix - this is working perfectly now.

Re. questions above...

8.33 spacing - I use frequency manager and so for a local frequency of 122.125 with 8.33khz steps, my vfo will actually land on something like 122.124.680. When I look at the recordings I get 'unknown groups' because the frequency manager frequency and the slightly offset vfo frequency aren't 'linked up'. I suspect this is a rounding problem with cumulative error given the recurring step values involved. I'd assume the scanner plugin will use 8.333 as opposed to 8.3333333 so with each pass the deviation may become more exaggered - 118.000 x 3(8.33) may stop on 118.0249 instead of 118.0250 if using 8.33R . This is a rubbish explanation but hopefully you get the idea.

Can you confirm the the frequencies listed here (in last column shown) is what you expect the frequencies to be.
I have made a change that aligns to those frequencies.
If you can confirm that this is correct, I can compile a version and get you to test it out to see if it's OK.

Noise protection - is this value a number of seconds for example i.e. default is 5 seconds? Or is it like squelch setting on a scanner than ranges from 1-10 let's say? My understanding is that the red line is more like traditional squelch in that any signal that rises above the red line opens the squelch and the transmission in heard. So my question is, is there a link between red line and noise protection delay settings? If the red line controls the trigger level, what does the noise protection do at this same moment if anything?

OK a clarification on the 'Use audio mute' and 'Noise protection delay' to which I was mixed up with as well to it's function.

'Use audio mute'
All this does is put the SDR# mute button under plug-in control.
On scanner start, it mutes the audio.
On scanner stop, it un-mutes the audio.
When the scanner stops on a active frequency, it un-mutes the audio.
When the scanner continues scanning, it mutes the audio.
This is not a squelch but in a way is working like one. It blocks the noise floor.
Using the SDR# squelch with scanner may cause unexpected results.
e.g. Scanner may stop on a active frequency but no audio will be heard because the SDR# squelch could be set higher than the scanner trigger level.

'Noise protection delay'
All this does is delay the un-muting action of the SDR# mute when scanner stops on an active frequency.
This is to stop any noise heard at beginning of the un-muting (not the end as previously stated)
The delay value is a count and does not represent an unit of time (mS, S)
The value will delay by an unspecified amount. Probably in the order of a few hundred mS

 

[morfis]

Here is what works for me for the freq ranges I am looking at -

Don't you miss things using 50kHz steps in the 230-400 MHz search? I've found quite a few US mil aircraft use 25kHz spaced freqs.
I use 6000k bandwidth for milair which is more than enough.

Seems like civ and mil air should be 10k bandwidth due to AM instead of 12.5k.

20 years ago 15k bandwidth was required to allow for offset ATC transmitters (if two transmitters they use centre freq +/-7.5kHz and for three it is centre freq AND +/-5kHz). International aircraft radios had to allow for that whether the same scheme was used elsewhere or not). This is no longer the case for civair (so I'd use 6000Hz, but I do have a UHF ATC freq locally which uses an offset (the actual freq being programmed in another radio so it's locked out in the plugin anyway).

I'd assume the scanner plugin will use 8.333 as opposed to 8.3333333 so with each pass the deviation may become more exaggered - 118.000 x 3(8.33) may stop on 118.0249 instead of 118.0250 if using 8.33R .

I don't use sdrsharp for civil airband but just tried the plugin with 8.33kHz channels. The incorrect frequency display is annoying but the the error doesn't compound.

 

[causeway74]

Can you confirm the the frequencies listed here (in last column shown) is what you expect the frequencies to be.
I have made a change that aligns to those frequencies.
If you can confirm that this is correct, I can compile a version and get you to test it out to see if it's OK.

Exactly - I'd like to be able to save an entry like 118.0833 in the Frequency Manager, and have the scanner plugin stop on the same. Perhaps this just needs some special rounding when a scan range is set to use 8,333 as the step size. If this was set to 4 decimal places then it should tie up nicely with both the FreqMan and also the Audio Recorder (which works off the same FreqMan entries). More than happy to test.

OK a clarification on the 'Use audio mute' and 'Noise protection delay' to which I was mixed up with as well to it's function.

'Use audio mute'
All this does is put the SDR# mute button under plug-in control.
On scanner start, it mutes the audio.
On scanner stop, it un-mutes the audio.
When the scanner stops on a active frequency, it un-mutes the audio.
When the scanner continues scanning, it mutes the audio.
This is not a squelch but in a way is working like one. It blocks the noise floor.
Using the SDR# squelch with scanner may cause unexpected results.
e.g. Scanner may stop on a active frequency but no audio will be heard because the SDR# squelch could be set higher than the scanner trigger level.

'Noise protection delay'
All this does is delay the un-muting action of the SDR# mute when scanner stops on an active frequency.
This is to stop any noise heard at beginning of the un-muting (not the end as previously stated)
The delay value is a count and does not represent an unit of time (mS, S)
The value will delay by an unspecified amount. Probably in the order of a few hundred mS

This is making sense now. I had experimented with different delay settings in the past but couldn't detect much impact - I was wary of increasing too much that shorter transmissions would be missed.

One thing I have noticed though is that when stopped on an active frequency, on some occasions the audio mute is toggled on/off during transmission. It happens so quickly on the mute button you'd barely notice, but it does cause some chopping of the audio. I was thinking that this might be due to my trigger being too high, but based on the logic explained in the manual I wouldn't expect the audio mute to reactivate until after the wait time has expired. Unfortunately I cannot reproduce the scenario but seem to recall reducing the trigger level may have helped. I always have sdr# squelch disabled. It would be great if you could confirm if there is any scenario where the audio mute recycles during active transmission (between scanner stop and resume).

What happens if the wait time is 0 and the signal drops beneath the red line? I suspect nothing since the red line is only used for the initial trigger, and the yellow line controls the resume logic. Usually I have the yellow line set as low as it goes. Is my thinking correct?

Thanks again.

 

[thewraith2008]

One thing I have noticed though is that when stopped on an active frequency, on some occasions the audio mute is toggled on/off during transmission. It happens so quickly on the mute button you'd barely notice, but it does cause some chopping of the audio. I was thinking that this might be due to my trigger being too high, but based on the logic explained in the manual I wouldn't expect the audio mute to reactivate until after the wait time has expired. Unfortunately I cannot reproduce the scenario but seem to recall reducing the trigger level may have helped. I always have sdr# squelch disabled. It would be great if you could confirm if there is any scenario where the audio mute recycles during active transmission (between scanner stop and resume).

While scanning and after it stops on an active signal:
If the signal drops below the yellow line, then the SDR# mute will enable (become muted)
The signal returning above red line is required to disable the SDR# mute and to hear audio again.
Is the transmission a strong or weak one. A weaker signal bouncing around could cause what you describe.

What happens if the wait time is 0 and the signal drops beneath the red line? I suspect nothing since the red line is only used for the initial trigger, and the yellow line controls the resume logic. Usually I have the yellow line set as low as it goes. Is my thinking correct?

Signal dropping below yellow line is required to start the wait timer. If delay is '0' then scanning while resume straight away.
I normally set yellow line averaged around the top of noise floor. The active signal when it ceases needs to be able to go below it to allow scanning logic to function correctly.

Experimentation is required in setting these options to find what best works for you and your setup.

 

[causeway74]

While scanning and after it stops on an active signal:
If the signal drops below the yellow line, then the SDR# mute will enable (become muted)
The signal returning above red line is required to disable the SDR# mute and to hear audio again.
Is the transmission a strong or weak one. A weaker signal bouncing around could cause what you describe.


Signal dropping below yellow line is required to start the wait timer. If delay is '0' then scanning while resume straight away.
I normally set yellow line averaged around the top of noise floor. The active signal when it ceases needs to be able to go below it to allow scanning logic to function correctly.

Experimentation is required in setting these options to find what best works for you and your setup.

I'll have a look at this again to better understand the scenario. If an active signal becomes inactive when it reaches the 'noise floor level' then I'm not sure what use it is me having the hysteresis line at the very bottom (well below noise floor) - would the signal even drop this far or be recognised as such by sdr#? If it doesn't drop this far then there must be some scenario where the resume scanning logic is based on something other than the yellow line being crossed - the line red in some scenario perhaps?

 

[thewraith2008]

I'll have a look at this again to better understand the scenario. If an active signal becomes inactive when it reaches the 'noise floor level' then I'm not sure what use it is me having the hysteresis line at the very bottom (well below noise floor) - would the signal even drop this far or be recognised as such by sdr#? If it doesn't drop this far then there must be some scenario where the resume scanning logic is based on something other than the yellow line being crossed - the line red in some scenario perhaps?

The channel analyzer is only a representation of the spectrum is scans.
The first few pixels at bottom exist as a solid blue area so the lockouts/memorized frequencies can be easier seen.

The lowest level the hysteresis (yellow line) can be set too is not the lowest level the signal can reach.
This is why it still scans at it's lowest value.

Setting trigger and hysteresis is always going to be a personal preference setting.
It's function is better used for those signals that are on the edge been average and not so average.

 

[Warlord21]

Hey van you add dynamic noisefloor it is in 1 of the versions from 2018

 

[Magpie]

Good Morning all,

I´ve briefje looked at the fast_scanner update and compared it to previous version.
I cannot find the button for Dynamic Noise Floor. I prefer that to Static Noise Floor.

Is Dynamic Noise Floor still available?

Regards, Henk in NL

 

[Warlord21]

Good Morning all,

I´ve briefje looked at the fast_scanner update and compared it to previous version.
I cannot find the button for Dynamic Noise Floor. I prefer that to Static Noise Floor.

Is Dynamic Noise Floor still available?

Regards, Henk in NL

It is Not in there i hope hé Will add this soon

 

[OZ1DJA]

Thanks, it works perfect on 1732

John in Denmark
----------------------------------------------------------------------------------------
Airspy R2 / Airspy Mini / Airspy HF+ / UBC9000XLT / CXL 118-138 / CXL 225-400

 

[gizmo436]

Thks for the updates thewraith2008 !!

Works perfect! ... and if you got some time left ,pls add : Dynamic Noise Floor in the plugin

greetz Giz

 

[Magpie]

I installed #1700 with the new fastscanner plugin yesterday and added 2 scanranges. Left it running tonight and found the PC asleep this morning with (after starting up again) #SDR switched off. Seems it crashed after running 5 or 6 hours. Will do the same again today to see what happens.

The scanranges used are the same one I normally use with #1700 or #1732 with the previous version of the fastscanner.

 

[Magpie]

Am using W10 64 bits on i5 PC.

 

[OZ1DJA]

No problems here after 5 hours uptime
Running 2 x airspy on 2 W10 64bit i7 machines

 

[morfis]

i3, windows 10 64bit home (up to date), 8GB ram,
sdrsharp 1700, latest scanner, Airspy R2, 230-400MHz scan (......guess one of yours is similar)
sdrsharp 1700, latest scanner, Airspy R2, different scanrange

I run two as the settings need to be somewhat differtent

Only time they have stopped in the past week was when I stopped them to reboot the micro PC

 

[Magpie]

i3, windows 10 64bit home (up to date), 8GB ram,
sdrsharp 1700, latest scanner, Airspy R2, 230-400MHz scan (......guess one of yours is similar)
sdrsharp 1700, latest scanner, Airspy R2, different scanrange

I run two as the settings need to be somewhat differtent

Only time they have stopped in the past week was when I stopped them to reboot the micro PC

Thanks Morfis. At the time I scanned 2 ranges: 230-389.975 and 396.500-399.975.
I'm afraid the second range was too short for #SDR causing it to crash.
Normally my 2nd range is 396.500-412.475 (2 x 8 MHz) which works nicely.
I'm now back to the previous scanner because of the missing Dynamic Noise option but may try out the new one at a later stage.

 

[morfis]

I'm afraid the second range was too short for #SDR causing it to crash.

Useful to know. Thanks for reporting back what the issue was...few people bother!

 

[thewraith2008]

I find it odd the three people out of the blue ask about the same obscure feature that was found in a buggy experimental version of the scanner plug-in. Are these users really unique?

When I've looked at this 'dynamic noise floor', it did not show signal levels properly (if at all) and the SNR value shown varies to the one SDR# displays. At this stage I don't see any reason to add it when it does not seem to be 100%.

I installed #1700 with the new fastscanner plugin yesterday and added 2 scanranges. Left it running tonight and found the PC asleep this morning with (after starting up again) #SDR switched off. Seems it crashed after running 5 or 6 hours. Will do the same again today to see what happens.

The scanranges used are the same one I normally use with #1700 or #1732 with the previous version of the fastscanner.

At the time I scanned 2 ranges: 230-389.975 and 396.500-399.975.
I'm afraid the second range was too short for #SDR causing it to crash.
Normally my 2nd range is 396.500-412.475 (2 x 8 MHz) which works nicely.
I'm now back to the previous scanner because of the missing Dynamic Noise option but may try out the new one at a later stage.

When I try the two ranges you mention 230-389.975 and 396.500-399.975 (I used 12500 for both bandwidth and step size) It scans OK with no crash.

How exactly are the two ranges defined? (what are all the fields)
I know when 'Bandwidth' and 'Step size' are incorrectly set, SDR# will crash or grind to a slow pace.
e.g. Want 50 KHz but use 50 when it should be 50000

I have fixed this for next version so the lowest value is 5000 Hz (5KHz)

 

[Magpie]

Hi, big advantage of DNR was that Airspy birdies on 240.000, 260.000, 280.000,300.000, 320.000, 340.000, 360.000, 380.000 and 400.000 + a lot of interfering frequencies were blocked by it. Without DNR I have to lockout say 15 frequencies, with DNR none. I think all UHF mil air monitors I know love it.

My ranges are shown in the attached file. Hope you can help.

 

[Magpie]

Hi, big advantage of DNR was that Airspy birdies on 240.000, 260.000, 280.000,300.000, 320.000, 340.000, 360.000, 380.000 and 400.000 + a lot of interfering frequencies were blocked by it. Without DNR I have to lockout say 15 frequencies, with DNR none. I think all UHF mil air monitors I know love it.

My ranges are shown in the attached file. Hope you can help.

Although it's possible that the second range ended at 399975000 during the crashed session..