SDR# SDR# Plug-in: Frequency Scanner updated

[rumcajs_tr]

well i have the same experience with Prog... rude reactions sometimes...
In fact, I stick to the legendary 1700 version (install size 2.0 MBytes)... fast, reliable, clean and simple interface, all plugins work, can run stable for many days, low CPU consumption... I think the Prog went wrong way when he tried to implement all this graphical fancy stuff in the last sdr# versions... actually I don't understand why would somebody use the last releases of sdr# ... lot of useless functions, skins, aux windows, install size more than 10 times bigger, more cpu consumption...
Using Prog's own own words ... bad code will perish - in this case - the bad code is the last sdr# versions... I know many users who refuse to use the skinned versions ... and I am VERY happy that developers like @thewraith2008 still support all the plugins (especially this one) for the original non-skinned releases as I would never upgrade to the latest sdr# versions.

 

[hamradionl]

Some programmers developers are reacting that way also on github or elswhere.
I still wonder good plugins like the scanner and manager, not emigrate to SDR++ use differ programmer language, lots of work to be done.
Sometime need to coorparation between SDR++ and plugin developers, but when not ask for it, things not get be done.

 

[Tim-B]

Is there a way to lockout a frequency when using the frequency scanner plugin so that it will not stop on that frequency while it is going through a programmed search range?

 

[Andyjuk]

Click the padlock in the Frequency Scanner Channel Analyser panel.
The instructions are in the pdf file in the download folder. It's worth reading.

 

[slicerwizard]

The quality of that code has degraded so dramatically over the different iteration, and has become so fragile, it can't survive strict memory allocation. This means the plugin is using unallocated memory - that's not even a beginner mistake. You really don't want to run that.

Accessing unallocated or deallocated memory isn't just a newbie mistake, so he's definitely overstating that. Over the years, many commercial programs that broke after a Windows version upgrade did so because they were sloppily coded and better enforcement of the Windows API rules and other things caught them out.

He is right in that you don't really want to be running code that sharts all over memory; that typically leads to a 0xC0000005 access violation exception. If you see a program crash with a 0xC0000005 error, it's got some sloppy code that's driving over the lane markers like a drunk. Back in the early 2000's, I had to deal with a vendor and their horrible AVL app that kept crashing with 0xC0000005 exceptions. At the time, I didn't know what a 0xC0000005 exception was, but now I know that their code was utter garbage. If you can't stay in your lane, get the eff off the highway!

 

[AM909]

... In response to someone who can't live without the scanner plugin over on prog's own bulletin board......

Can you provide a link please? Thanks!

 

[thewraith2008]

The scanner plug-in is throwing an error on 'Start' of scanning.
This is a error caused by SDR#. (using one of it's API methods)
SDR# now claims a buffer used is a NULL. (see debug log below to see this is not the case)
The allocation of this buffer is the same as when it was added by Vasili many moons ago.
I have not changed it and it has been working perfectly fine until SDR# 1845.
The point of failure is when the buffer is cleared (at scanner 'Start') using the SDR# UnsafeBuffer .Clear() method.
- Which is in SDRSharp.Radio.dll - UnsafeBuffer class
If I use a for loop to manually clear the buffer (instead of the SDR# method) all works fine.

This is a debug trace when the .Clear() is used:

[9392] Constructor: InitFFTBuffers() - Start 
[9392]  buffer.Create() 
[9392]  buffer.Create() - Done - LEN: 100 
[9392] Constructor: InitFFTBuffers() - End 
[9392] Waiting for user to start scanner 

[9392] ScanStart(): User clicked 'Start' 
[9392]  Check if buffer is NULL: buffer LEN = 100 
[9392]  buffer.Clear() 
[9392] Object reference not set to an instance of an object.

This is a debug trace when the for loop is used:

[5224] Constructor: InitFFTBuffers() - Start 
[5224]  buffer.Create() 
[5224]  buffer.Create() - Done - LEN: 100 
[5224] Constructor: InitFFTBuffers() - End 
[5224] Waiting for user to start scanner 

[5224] ScanStart(): User clicked 'Start' 
[5224]  Check if buffer is NULL: buffer LEN = 100 
[5224]  Manually clear buffer (via for loop) 
[5224]  Manually clear buffer (via for loop) - Done 
[5224] Scanning started

Prog: "I will probably decompile that dll and fix the code after the high priority tasks are done. "

This was the very thing Prog was raving on about a year ago calling them "Pirates".
He can do it to Vasili's original if Vasili gives him the OK, but not this one. (I don't give the OK on this version)

Is the plug-in "fragile", probably.
This is only because I was trying to keep this great plug-in going to support two different versions of SDR#.
It doesn't help that the new SDR# is in constant state of flux.

I have more people telling me they use the scanner with the older versions of SDR# (pre v1717) than the newer version.
Maybe I should forget about the support for the newer SDR# and keep it going on the older versions.

 

[thewraith2008]

Can you provide a link please? Thanks!

This is the thread here morfis quoted from.

It is now reported (in that thread) that the build-in BB noise blanker plugin (but also applies too AF and IF versions) throws the same error (as scanner plug-in) when they are enabled when no other plug-ins are installed.

Object reference not set to an instance of an object.
at <Unknown>.UnsafeBuffer.Clear  (IL offset: 0x0)

I wonder how this is going to be explained away.

 

[thewraith2008]

And now with SDR# v1854 released, the scanner plug-in magically works again.

 

[VladeDoddy]

I seem to have come across a possible bug with the frequency scanner plugin. While scanning it sometimes ignores the "Wait" time I have set, and it immediately starts scanning again once a transmission ends. There doesn't seem to be any pattern to it doing this, sometimes it waits and others it starts scanning immediately. The times it does immediately resume scanning the "act time: " in the analyzer window will stay at 0.000s instead of counting up the elapsed time the frequency is active. Also, when the "act time" indicator doesn't count up on a transmission and another transmission starts in the same segment, it will immediately switch to that transmission.

I'm using v2.2.13.0 of the frequency scanner with the standard frequency manager that comes with SDR#. So far this is what I've tried to do to fix this issue without success:

-Adjusted the wait time
-Increased the Detect time
-Tried it with SDR# versions 1716 and 1854
-Tried "Scan all without save new" and "Scan only memorized - exclude new"
-Tried a fresh copy of SDR# with no other plugins except Frequency Scanner

I also recently reinstalled Windows and the problem still persists. I'm not sure when this started because I haven't been using it that much lately and only noticed it because conversations were getting cut off mid-sentence. If there's anything else I can do to try to alleviate this please let me know.

Thanks in advance and thanks for continuing to work on this plugin!

 

[flanker86]

@thewraith2008 I think found another issue with timers. It is about auto lock function - some signals tend to escape my auto lock 45 s timer and the scanner stops on them until they disappear (can stop on them even for hours).

Thank you in advance for checking the problem.

 

[thewraith2008]

I seem to have come across a possible bug with the frequency scanner plugin. While scanning it sometimes ignores the "Wait" time I have set, and it immediately starts scanning again once a transmission ends. There doesn't seem to be any pattern to it doing this, sometimes it waits and others it starts scanning immediately. The times it does immediately resume scanning the "act time: " in the analyzer window will stay at 0.000s instead of counting up the elapsed time the frequency is active. Also, when the "act time" indicator doesn't count up on a transmission and another transmission starts in the same segment, it will immediately switch to that transmission.

I'm using v2.2.13.0 of the frequency scanner with the standard frequency manager that comes with SDR#. So far this is what I've tried to do to fix this issue without success:

-Adjusted the wait time
-Increased the Detect time
-Tried it with SDR# versions 1716 and 1854
-Tried "Scan all without save new" and "Scan only memorized - exclude new"
-Tried a fresh copy of SDR# with no other plugins except Frequency Scanner

I also recently reinstalled Windows and the problem still persists. I'm not sure when this started because I haven't been using it that much lately and only noticed it because conversations were getting cut off mid-sentence. If there's anything else I can do to try to alleviate this please let me know.

Thanks in advance and thanks for continuing to work on this plugin!

Do you have the option "Auto Skip" enabled with a lower timeout value?



Latest version (v2.2.13.0) can be found here: MEGA - Download
Release post here

 

[thewraith2008]

@thewraith2008 I think found another issue with timers. It is about auto lock function - some signals tend to escape my auto lock 45 s timer and the scanner stops on them until they disappear (can stop on them even for hours).

Thank you in advance for checking the problem.

Are you using the latest version v2.2.13.0? If not then update to this version.
There was an issue with v2.2.12.0 with the Auto Skip/Lock timer.



Latest version (v2.2.13.0) can be found here: MEGA - Download
Release post here

 

[flanker86]

@thewraith2008 Yes, I am using the latest one (and SDR# 1830 -mainly- and 1854-for testing). I was the person that reported the previous problem with the timer in v2.2.12.0.

 

[thewraith2008]

@thewraith2008 Yes, I am using the latest one (and SDR# 1830 -mainly- and 1854-for testing). I was the person that reported the previous problem with the timer in v2.2.12.0.

OK, the Auto Lock is something I don't use at all (so testing is limited).

I would need to know how all the scanner plug-in options are configured. (screenshots - can send PM if like)
Also what kind of signals is the scanner jamming up on. (constant carrier, pulsing, other whatever...)
Testing/reproducing this issue is probably not going to be easy.



Latest version (v2.2.13.0) can be found here: MEGA - Download
Release post here

 

[flanker86]

OK, the Auto Lock is something I don't use at all (so testing is limited).

I would need to know how all the scanner plug-in options are configured. (screenshots - can send PM if like)
Also what kind of signals is the scanner jamming up on. (constant carrier, pulsing, other whatever...)
Testing/reproducing this issue is probably not going to be easy.



Latest version (v2.2.13.0) can be found here: MEGA - Download
Release post here

OK - I will send you the config in PM. What is more I will also add a .wav file of the signal.

I do not know the dependencies between the variables, but the act time in debug mode rather shows good signal duration and I am wondering if it can be used as the timer for Auto Lock/Auto Skip?

 

[VladeDoddy]

Do you have the option "Auto Skip" enabled with a lower timeout value?



Latest version (v2.2.13.0) can be found here: MEGA - Download
Release post here

No, auto skip is disabled. I've also tried turning off/on the Use narrow CH bandwidth setting and tried the Static noise floor option, but the problem persists. I've attached a screenshot showing the settings for the plugin.

 

[thewraith2008]

I will have to keep an eye out for it occurring here.
Not much I can do until I can see it happening.



Latest version (v2.2.13.0) can be found here: MEGA - Download
Release post here

 

[hamradionl]

SDR# 1700 - CLEAN + AIRSPY + SCANNER 2.2.13.0
I not use very often, today monitor UHF airband i notice the scanner is no longer scanning. The spectrum screen is "stutter", hangs.
RTL-SDR seem to work okee,
Did i mis something in the newer version?

 

[Magpie]

Which scanrange(s) have you defined and which are selected to scan?