SDR# SDR# Plug-in: Frequency Scanner updated

[rumcajs_tr]

So after several days of testing, I didn't find any bugs - all is working fine and as expected

I have one suggestion regarding frequency manager from @thewraith2008 - now when the CTCSS and DCS tones are available to other plugins, it could be possible to update the frequency manager plugin to allow the user to store the TONE value together with name and frequency into the records and use it later for scanning known channels from frequency manager, which would pass the recorded TONE to the CTCSS/DCS plugin with the "set this tone" option enabled.
However - this is just an idea as I am not sure, how well it would work during scanning - obviously, the CTCSS/DCS plugin need some time to detect the tone so that would probably slow memory scan - not sure how much. Could you look at this feature, whether it is feasible?

 

[thewraith2008]

Would you consider please adding functionality to help those 8% of the male population either by allowing us to adjust the colours for the six categories of lockout state and presence in Frequency Manager or choose colour blind safe ones? It would make a great bit of software perfect.

It's something I can look at for future release, at this stage I've not been into SDR that much of late and I'm having a break from it for now.

Added: Store/Restore SDR# option 'Snap to Grid' state on start/stop
restores only to 12.5 kHz regardless of which step was set before. (translated by google)

The restoring of 'Snap to Grid' does not mean restoring of step size.
When the scanner is stopped, it uses the step size of the frequency range it stopped on.
This is in part by design.

Will the new CTCSS functionality exposed to the scanner plugin also allow the use of [Tone] parameter to determine the filename for audio recordings via audio recorder plugin?

i.e. if scanner lands on 160.500 (97.3) could I capture the tone to write the file to something like C:\somepath\recs\160.500-97.3-myalphatext.wav

No. CTCSS/DCS value is only passed to Frequency Scanner (at least for now).

I have one suggestion regarding frequency manager from @thewraith2008 - now when the CTCSS and DCS tones are available to other plugins, it could be possible to update the frequency manager plugin to allow the user to store the TONE value together with name and frequency into the records and use it later for scanning known channels from frequency manager, which would pass the recorded TONE to the CTCSS/DCS plugin with the "set this tone" option enabled.
However - this is just an idea as I am not sure, how well it would work during scanning - obviously, the CTCSS/DCS plugin need some time to detect the tone so that would probably slow memory scan - not sure how much. Could you look at this feature, whether it is feasible?

CTCSS/DCS value is only passed to Frequency Scanner, not to other plug-ins (at least for now).
Addition field(s) could be added to FreqMan to store the CTCSS/DCS values but scanning from FreqMan with detection of CTCSS/DCS is I think outside the scope of that plug-in.

Yes, the scanner (both of them) would be hindered considerably if it had to check every signal for CTCSS/DCS. (in the order of 60-250mS per signal)
Even once detected and then set the tone squelch, the scanner would still have to stop on the active frequency then determine if CTCSS/DCS is present then decide if to stay or continue scanning. I think this has more going against it than for it.

Personally I don't understand the desire to use CTCSS/DCS squelch when scanning.
Effectively all but one frequency is locked out. If this is the case then why bother scanning.



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

 

[causeway74]

The CTSCSS scenario for me is maybe better explained this way.

Ideally, I could have multiple entries in the frequencies.xml file for FreqMan where the frequency is the same, but there is a different tone value. At the moment I can only really have one entry for say 160.500 in my FreqMan database. If I review the associated recordings later I will not be able to detect what tone was actually used, so it is hard to ID the user.

If I were to have multiple entries in FreqMan database, each with a different tone, each with a different name/label, it would allow the audio recordings to be identified easier.

I think with this latest version it will still be a great help - I can simply look up the frequency + time in the scanner log and grab the tone from there. I rarely use on the VHF bands anyway so it is a minor point but hopefully this clarifies.

 

[thewraith2008]

This is a limitation of all the (Vasili) plug-ins that use the frequency manager unfortunately.
The frequency manager (standard and FreqMan) can allow multiple same frequency entries in the database but the plug-ins only retrieve the first occurrence of the frequency.



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

 

[rumcajs_tr]

Thanks for all replies. I agree that further modification of frequency scanner / frequency manager plugins regarding ctcss/dcs would make things much more complicated. For listening to memorized frequencies with ctcss, it is better to use a snad-alone hardware scanner and keep the SDR# and frequency scanner for fast searching of new frequencies.
Thanks again for great work ... the latest version is excellent.

 

[AM909]

I don't think it would be an unreasonable feature to allow spec of a DCS/CTCSS decode value in a table of individual frequency to scan. I think the usual approach is to sense carrier as usual to stop the scan, then resume after a (perhaps configurable) period of time if the specific DCS/CTCSS is not decoded, and not log it as a "hit". That could even be expanded to decoding of a specific type of trunking, network, system, site, talkgroup, radio ID by talking to something like DSD+ (or even just watching its logs if a less-cooperative approach is needed).

This approach makes even some band-scan scenarios not too bad, as it only has to stop and try to decode on carrier sense, where it would stop anway, right?

I know that some of this exists already in different forms; nothing wrong with building a better-featured mousetrap when you feel energetic.

 

[rumcajs_tr]

One suggestion regarding logfiles of the new frequency scanner plugin:
In plugin settings, there is option to set "Delete rows with activity < xx every yy seconds". However, this option affects only the small activity table in the plugin and not the logfile. Also the recording plugin has option "Delete file if the size < xx seconds".
The "Logging" tab in the frequency scanner plugin doesn't have this option. Is it possible to implement this feature also to the logfiles - e.g. delete (do not log) records with activity less than xx seconds in the logfile?
This way, the recordings, and the logfiles would be consistent, while in the current plugin version, I have many lines with logs <1sec while there is no recording relevant to this line because I set "Delete file if the size <1 second" in the recording plugin.
Regards, Ondrej

 

[flanker86]

@thewraith2008 I would like to thank you for your superb job. In this latest release you managed to implement all of my suggestions - specially regarding the skip/lockout timer separated from the dynamic noise floor reset timer and a ability to purge temporary locked freqs periodically.

I would like to know if there is a way to view temporary locked frequencies.
What is more I would like to know how the Auto lock timer is evaluated. I've noticed that for example I have it set to 45, but an active frequency turns to dark violet after 20 seconds in act time debug line. I've tried to log the time, but I think locked freqs are absent from the log file.

 

[thewraith2008]

One suggestion regarding logfiles of the new frequency scanner plugin:
In plugin settings, there is option to set "Delete rows with activity < xx every yy seconds". However, this option affects only the small activity table in the plugin and not the logfile. Also the recording plugin has option "Delete file if the size < xx seconds".
The "Logging" tab in the frequency scanner plugin doesn't have this option. Is it possible to implement this feature also to the logfiles - e.g. delete (do not log) records with activity less than xx seconds in the logfile?
This way, the recordings, and the logfiles would be consistent, while in the current plugin version, I have many lines with logs <1sec while there is no recording relevant to this line because I set "Delete file if the size <1 second" in the recording plugin.
Regards, Ondrej

Currently logging activity is hard coded so that any activity under 500mS will not be logged.
For next release I have just tied in the option "Delete rows with activity < X" to also apply the logging as well.
If it would be preferred to have this as a separate control, let me know otherwise I leave it.

@thewraith2008
I would like to know if there is a way to view temporary locked frequencies.
What is more I would like to know how the Auto lock timer is evaluated. I've noticed that for example I have it set to 45, but an active frequency turns to dark violet after 20 seconds in act time debug line. I've tried to log the time, but I think locked freqs are absent from the log file.

You can see the color difference on the channel analyzer for temporary lockouts but there is no list viewing of temporary lockouts.

There appears to be a regression with this feature. (thanks for bringing attention to it)
Normally the Auto Skip/Lock(out) timer is a free running counter.
On activity it counts down from the set value (e.g. 45) to zero.
Depending on option state of "Reset timer on 'over'", it will either reset on when scanner resumes or on every over.
Currently the timer is not been correctly reset causing unexpected behavior.

I will try and do a release soon.



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

 

[thewraith2008]

This is a update v2.2.13.0 to the great Frequency Scanner plug-in for SDR#.

Just some minor changes

Please note the addition of a 2nd DLL requirement for this plug-in now.
Failure to install it will result in plug-in not starting in SDR# or errors been thrown.
NOTE: This DLL may already be installed as it has been used by some of Vasili's other plug-ins in the past.

This plug-in version adds/changes and fixes some items:

2.2.13.0 - Release

Fixed: A regression that affected Auto Skip/Lock timer from been correctly reset
Changed: From hard coded logging activity minimum which was 500mS (0.5 sec) to adjustable.
Updated: PDF Documentation
- Please read it

see changelog.txt for more details

Documentation has been created to help with it's installation and usage, please read it.
NOTE: Support is not guaranteed. Especially if the answers are contained in the documentation or on this forum.

I have tried to be as thorough as possible with the documentation to explain usage and features.
I believe any questions can be answered by reading this documentation.
This documentation most likely is not complete and may contain errors and is not laid out as good as it could be.

No real testing has been done with the newer SDR# from v1717 and above.
Main testing has been done with SDR# 1700.
NOTE: SDR# has been going through some changes (1732+) and it's new features may see this plug-in play up.

NOTE: To use the CTCSS/DCS feature (added in v2.2.12.0), you are required to update the CTCSS and DCS plug-ins to v1.3.2.0+. (use same link below)


Download
NOTE: Use 7zip or WinRAR to extract files from the .7z file and read the .PDF file for installation and usage of files with SDR#.
NOTE: Don't select the Download as ZIP option in MEGA, just select standard download.

HASH: 75e3716ef4d9aa8f0ddfd6e68e8791b0

 

[flanker86]

@thewraith2008 It works as it should right now. I will test it in the following days, but I think the scanner is much better as it is not stopping on fake signals that often. I've narrowed the channel bandwidth for signal detection and resetting noise floor every 2 minutes.

One more question - reset timer on 'over' has no meaning when you have Wait time set to 0, correct?

 

[thewraith2008]

One more question - reset timer on 'over' has no meaning when you have Wait time set to 0, correct?

Probably not, it will just reset when scanner resumes as a 'over' will leave a pause(wait) greater than 0.



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

 

[PatrickPierre73]

Hi there !

I just downloaded CTCSS 1.3.2 and Frequency Manager 2.2.13 and SDR# latest rev, #1845.
Frequency Scanner simply won't start.
I suppose I did the install properly (unzipped the compressed file and dragged it to the 'plugin' folder, as usual). Attached is the error message I get.

Note that the same issue occurs if running Frequency Scanner 2.2.10.0.

I will run some old SDR# versions for the time being, 1716 and 1732.

Many thanks for your great work.

 

[morfis]

Hi there !

I just downloaded CTCSS 1.3.2 and Frequency Manager 2.2.13 and SDR# latest rev, #1845.
Frequency Scanner simply won't start.
I suppose I did the install properly (unzipped the compressed file and dragged it to the 'plugin' folder, as usual). Attached is the error message I get.

Note that the same issue occurs if running Frequency Scanner 2.2.10.0.

I will run some old SDR# versions for the time being, 1716 and 1732.

Difficult to keep up with Prog's releases as sometimes there are multiple releases of a 'number' never mind new numbers. .1844 and .1845 lasted seconds and as I type we are on the fourth number today... .1846

Scanner plugin works fine with .1843, I missed .1844 but plugin fails to run with .1845 and .1846

One can only guess that Prog breaks things regularly...but of course it is his sofware users and plugin authors who he treats like idiots.

It really is easier to keep a working directory of one of the older sdrsharp variants (as per the documentation thewraith2008 helpfully provides) for use with the scanner plugin - it works fine and saves the hairpulling when you think you might have done something wrong

 

[thewraith2008]

Looks like all these SDR# changes have busted the scanner plug-in for good. (and maybe other plug-ins)
Bad luck for the new SDR#. Long live legacy SDR# (v1716).



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

 

[R0am3r]

And long live SDR# v1732. I am using Frequency Manager v1.1.7.1 and Frequency Scanner v2.2.13.0 with zero issues. These plug-ins are my go-to-tools for managing and scanning large chunks of spectrum. My latest hunt [again] is sweeping across the air-band looking for new offerings. It never ends. Thank you @thewraith2008!

 

[hamradionl]

stopt upgrade SDR# after 1700 And switch to SDR++ just suggestion for those give it a try make some plugin

 

[PatrickPierre73]

Running SDR# 1716 and 1732, I notice something wrong with "Show 8.33 KHz channel name (in main spectrum)" feature.
It's of course enabled, SDR# step is set to 8.33. as usual. Before scanning, the "channel name" is displayed as expected, but as soon as I run the scan, it disappears. I don't have the '8.33 channel selector' plug-in installed.

Anyone ?
Is there something I'm doing wrong ? (was perfectly working with 2.2.10.0)

Thanks !

 

[PatrickPierre73]

Got it !
The "channel name" is now hidden while scanning but is displayed when a station is detected (I had chosen the "scan only new" option, and as it did not stop on any signal, I did not realize that this information was now visible only when a station was detected).

 

[morfis]

Now up to .1853 according to the download page (though probably increased as I type)

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

"The train goes on. Bad code will perish. Good code will prevail."

"The thing is that the fast scanner plugin uses the same API that other well written plugins are still happily using right now. What's more amazing is that I made the said API for Vasili and gave him some example code to write the original scanner. 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. I will probably decompile that dll and fix the code after the high priority tasks are done. "

Prog comes across as one of the rudest people I have ever seen on the internet (often worse than people who are actually tring to be!).