SDR# Frequency Manager + Scanner is now available

[sdrs.freqmgr]

The SDR# Frequency Manager + Scanner is a privately-developed free plugin designed for use within the SDR Sharp software application.  It delivers a full-featured frequency management tool permitting you to manage and browse frequencies and to scan frequency ranges or groups of frequencies.

In addition, a Scanner Metrics plugin and a data import/export utility are now available.

Frequency Manager + Scanner
Frequency Manager + Scanner adds the following features to SDR#:

• A collapsible panel that displays information about the frequency currently tuned in the radio.
• An Edit dialog that allows you to add and update frequency records in the database.  15 radio settings and data fields are stored for each frequency.
• A Browse window that lets you browse through your database, selecting and sending frequencies to the radio.  You can also filter your database 3 different ways to limit the scope of frequencies that are displayed in the browse window.
• A Groups window that lets you define, edit, and delete frequency groups.
• A Scanner that allows you to select either a frequency Group or a range of frequencies to scan.  Depending on your hardware you can scan up to 1000 frequencies per second.

Scanner Metrics
The Scanner Metrics plugin is an accessory to Frequency Manager + Scanner.  When scanning, the Metrics plugin records the frequencies having activity to a database.  When desired you can run reports on the stored data, producing charts that illustrate the amount of activity on each active frequency.  By this method you can determine which of the millions of frequencies you can receive actually are worth spending time on.

Data Conversion Tools
This standalone utility for Frequency Manager + Scanner data can import and export CSV files of frequency data, and can convert existing data from the default SDR# Frequency Manager into a CSV file suitable for import.

System Requirements
Basically if you can run SDR Sharp, you can use Frequency Manager + Scanner.  As with any software, the more capable your hardware the better the software will run.

• OS: Windows XP Pro or Windows 7.  FM has not been tested on Windows 8 but it should work fine.  The binaries are compiled for a 32-bit environment for the broadest compatibility but run equally well in an x64 environment.
• Processor: 1-gigahertz processor or faster; 2 or more cores is recommended for suitable performance.
• Memory: 1 gigabyte or more total in the computer.
• Hard Disk: The software requires less than 900KB; the frequency database size is dependent on the number of records.  2000 records will fit in a 600KB database.
• .NET: Version 3.5 runtime as required by SDR Sharp.
• SDR Sharp: Revision 937 or newer.

Downloads
The software can be downloaded using the following links:

• The Frequency Manager + Scanner plugin and its related modules, plus a user’s guide, is available at http://goo.gl/3GWIE.
• The Scanner Metrics plugin and its user’s guide is available at http://goo.gl/kfoL7.
• The Data Conversion Tool and its user’s guide is available at http://goo.gl/ndIHy.

You can download each zip or individual files in each zip.  If you are asked to log in, disable your ad blocking tools or use another browser.

Thank you for taking a look at the software.
Jeff N8GJL

BONUS!
If you know C#, I’ve created an empty SDR# Plugin Project for your use.  Download it from http://goo.gl/SxvvZ and add it to an SDR# solution; I’ve already done the wiring for you so you only need to add your plugin-specific code.  Use it as a base for your own plugins!

[waismocha]

Is there any scanner plugins for Linux?

[sdrs.freqmgr]

Sorry, no.

Jeff

[murrij]

Awesome work! Thank you for this. The plugin "shell" project template looks very cool too. Now what to do as a plugin...  Maybe it's time to do an RTTY decoder plugin along with some other digital modes so ya don't have to use a virtual soundcard connection.

[Jens Stark]

On Sunday, 16 December 2012 03:49:55 UTC+1, murrij wrote:

Awesome work! Thank you for this. The plugin "shell" project template looks very cool too. Now what to do as a plugin...  Maybe it's time to do an RTTY decoder plugin along with some other digital modes so ya don't have to use a virtual soundcard connection.

I hate this virtual soundcard stuff - it is obvious that Windows wasn't designed with that in mind. SDR# could use a ton of decoders, I currently use sdr-radio 1.5 (from sdr-radio.com) for it's great data decoder, together with a Funcube Dongle Pro+. (SDR# used for tuning :) )

Disadvantages: Until the tech preview on the 24th, no full support for the FCD+ - and no idea if and how they support RTL SDR. Also, the thing is closed source with very infrequent releases.

So a good decoder for one or more digimodes is one of the few things I still miss from SDR#.

 

[Arnie W8DU]

Is there a way to arrange the SDR# screen so that the Freq Manager/Scanner plugin is near the top, just under Radio, instead at the bottom? Great plugin but a bit annoying to have to scroll down to the bottom to access the scanner menu each time.

Thanks...Arnie W8DU

On Thursday, December 6, 2012 1:48:35 PM UTC-5, sdrs.freqmgr wrote:

[David J Taylor]

Is there a way to arrange the SDR# screen so that the Freq Manager/Scanner
plugin is near the top, just under Radio, instead at the bottom? Great
plugin but a bit annoying to have to scroll down to the bottom to access the
scanner menu each time.
Thanks...Arnie W8DU

========================================

You might like to ask for this feature in the SDR# group:

http://uk.groups.yahoo.com/group/SDRSharp/

It's a feature I would like to see as well.

73,
David GM8ARV
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-...@blueyonder.co.uk

[jdow]

On 2012/12/25 12:31, David J Taylor wrote:
> Is there a way to arrange the SDR# screen so that the Freq Manager/Scanner
> plugin is near the top, just under Radio, instead at the bottom? Great plugin
> but a bit annoying to have to scroll down to the bottom to access the scanner
> menu each time.
> Thanks...Arnie W8DU
>
> ========================================
>
> You might like to ask for this feature in the SDR# group:
>
> http://uk.groups.yahoo.com/group/SDRSharp/
>
> It's a feature I would like to see as well.
>
> 73,
> David GM8ARV

I was going to mention that the source code is available and you
can relay it out for yourself. But that gets annoying if you have
to do it every time. Now, if somebody over there was to enable
the mouse wheel for scrolling that would enable you to get where
you want quicker.

{^_^} Joanne, W6MKU

[sdrs.freqmgr]

Not currently.  That's an ability that the SDR# authors would have to write software for. 

73s, Jeff

[KD4NSZ/Bob]

I installed the scanner/FM. I was really interested in the scanner. After the install, I got a "installed correctly" message. I also added the script line in the config file under the plugins. However, when I start SDR#, the upper frequency digits (at the top of the screen) are not functional and only have blank lines for digits. I tried to scan an lower to upper frequency from the plugin window at the bottom, but that isn't working for me either. If you have any ideas or can tell me what I am doing wrong, please let me know.Thanks for your work and help.

KD4NSZ / Bob D.

On Thursday, December 6, 2012 1:48:35 PM UTC-5, sdrs.freqmgr wrote:

> The SDR# Frequency Manager + Scanner is a privately-developed free plugin designed for use within the SDR Sharp software application.  It delivers a full-featured frequency management tool permitting you to manage and browse frequencies and to scan frequency ranges or groups of frequencies.
>
> In addition, a Scanner Metrics plugin and a data import/export utility are now available.
>
> Frequency Manager + Scanner
> Frequency Manager + Scanner adds the following features to SDR#:

> A collapsible panel that displays information about the frequency currently tuned in the radio.An Edit dialog that allows you to add and update frequency records in the database.  15 radio settings and data fields are stored for each frequency.A Browse window that lets you browse through your database, selecting and sending frequencies to the radio.  You can also filter your database 3 different ways to limit the scope of frequencies that are displayed in the browse window.A Groups window that lets you define, edit, and delete frequency groups.A Scanner that allows you to select either a frequency Group or a range of frequencies to scan.  Depending on your hardware you can scan up to 1000 frequencies per second. Scanner Metrics

> The Scanner Metrics plugin is an accessory to Frequency Manager + Scanner.  When scanning, the Metrics plugin records the frequencies having activity to a database.  When desired you can run reports on the stored data, producing charts that illustrate the amount of activity on each active frequency.  By this method you can determine which of the millions of frequencies you can receive actually are worth spending time on.
>
> Data Conversion Tools
> This standalone utility for Frequency Manager + Scanner data can import and export CSV files of frequency data, and can convert existing data from the default SDR# Frequency Manager into a CSV file suitable for import.
>
> System Requirements
> Basically if you can run SDR Sharp, you can use Frequency Manager + Scanner.  As with any software, the more capable your hardware the better the software will run.

> OS: Windows XP Pro or Windows 7.  FM has not been tested on Windows 8 but it should work fine.  The binaries are compiled for a 32-bit environment for the broadest compatibility but run equally well in an x64 environment.Processor: 1-gigahertz processor or faster; 2 or more cores is recommended for suitable performance.Memory: 1 gigabyte or more total in the computer.Hard Disk: The software requires less than 900KB; the frequency database size is dependent on the number of records.  2000 records will fit in a 600KB database..NET: Version 3.5 runtime as required by SDR Sharp.SDR Sharp: Revision 937 or newer.Downloads

> The software can be downloaded using the following links:

> The Frequency Manager + Scanner plugin and its related modules, plus a user’s guide, is available at http://goo.gl/3GWIE.The Scanner Metrics plugin and its user’s guide is available at http://goo.gl/kfoL7.The Data Conversion Tool and its user’s guide is available at http://goo.gl/ndIHy.You can download each zip or individual files in each zip.  If you are asked to log in, disable your ad blocking tools or use another browser.

[sdrs.freqmgr]

The makers of SDR# changed a bit of their architecture and that has caused problems with the plugin.  Please download the SDRSharp.FreqMgr.dll patch DLL at http://goo.gl/3GWIE and replace the old one with the new one.

Thanks,
Jeff

[Łukasz Parysz]

W dniu niedziela, 30 grudnia 2012 08:02:29 UTC+1 użytkownik sdrs.freqmgr napisał:

The makers of SDR# changed a bit of their architecture and that has caused problems with the plugin.  Please download the SDRSharp.FreqMgr.dll patch DLL at http://goo.gl/3GWIE and replace the old one with the new one.

Thanks,
Jeff

Hi there!
After update of dll file I lost the names of saved records from FreqMgr which was showned above the scale (near Configure button). Is the update the reason of such situation? It is really useful to see the name if the Frequency Manager + Scanner box is hidden.
Thanks for info!
Regards!

Luke

[sdrs.freqmgr]

That was removed due to one of the changes made by the authors of SDR#.  There's really no place else left to show that info.

Thanks,
Jeff

[jdow]

If SDRSharp were to grow a status bar at the bottom that would be
an excellent place to put this kind of information. Or you can
place the data in the collapsible side bar as another alternative.

{^_^} Joanne, W6MKU

[sdrs.freqmgr]

Hi Joanne,

A status bar would be great.  The station name is already in the collapsible panel; I'll look into include the service.

Cheers,
Jeff

[Foley]

On Tuesday, December 25, 2012 8:31:13 PM UTC, David Taylor, GM8ARV wrote:

You might like to ask for this feature in the SDR# group:

Best of luck with that one, from reading their group I don't think I've ever seen a developer less interested in user input and suggestions, even basic improvement requests go ignored or rejected.

[Robert Nickels]

On 1/1/2013 2:09 AM, Foley wrote:
>
> Best of luck with that one, from reading their group I don't think
> I've ever seen a developer less interested in user input and
> suggestions, even basic improvement requests go ignored or rejected.

As an avid SDR# user, I feel the need to respond to that statement.
The SDR# developers are exceptionally talented programmers who have
given us a powerful and expandable tool for SDR users and as a platform
for continued development. Consider an analogy to an architect who has
created a new building that embodies state-of-the-art construction
practices and materials. I think it is understandable that he would be
focused on the architecture and continued evolution of the building
design than what color the walls are painted or what style of window
coverings are preferred. It's a matter of focus.

Analogies are never perfect I I don't mean this to demean user requests
for new features (I have 'em too!), but only to point out that
improvements to the software happens on various levels, including some
that are not readily apparent to those of us who just want to use it for
various purposes, and have ideas for "bells and whistles" or ways of
improving ease of use. What is not as apparent for many of us is the
powerful algorithms and underlying architecture that make SDR# work so
well, and the hours of testing that goes on behind the scenes so that we
can enjoy using what has proven to be nearly bug-free code.

The solution I believe is unfolding before our eyes...the "nightly"
release of continuous integration releases shows how much "under the
hood" work is going on to improve the core of SDR#, and now with the
plug-in interface we now have a means for adding great new user features
such as the Frequency Manager and Scanner being developed by Jeff Knapp
and others. Both types of improvement are valuable and together they
will make a great "product" even better (keeping in mind this is an
all-volunteer endeavor that we enjoy for free).

If someone were to coordinate a list of "most wanted feature
improvements", adding and consolidating ideas as they pop up on the
various lists, I'd think that would be a big help for new developers who
may come along and have the skills to lend a hand. Just based on what
we've seen in the past 6 months, 2013 promises to be a terrific year for
SDR and ham/hobby radio!

73, and Happy New Year

Bob W9RAN

[Foley]

All I can do is quote the developer from November last year.

"First of all, please note that the SDR# is not a community driven project. It's an effort from a few people who have their own vision of software development. We have no aim adding any bells and whistles. <> please note that the only areas where we might be interested to exchange are: - DSP - GPU Processing The rest is of no added value to the project."

[murrij]

After reading through this, it's pretty long winded so be forewarned. After reading a post on the Yahoo SDR# list last Friday I do feel like I need to come out of lurker mode here. I have to say my plugin I started developing based on the excellent "plugin shell" that Jeff did is not on hold for now.

I also may be way off base here since I personally do not know the developers of SDR# or the developers to any of the plugins I've seen for SDR#.

As someone who used to do development for a living (which means I was getting paid, as compared to the SDR# developers doing their work where the only payment is gratitude from the community and most likely learning), I have a feel for what it's taken to get SDR# where it is. I applaud the group for what they've done, and years from now when someone does a writeup of "look how far we've come in inexpensive SDR" SDR# (and it's developers) will definitely have a section in the article giving them props. It also can grate on a person sometimes when all you hear is: "your software is broken because I can't get it to work on my Commodore Vic20 under OS2" questions from people who don't bother to read the posts and intro guides on the group you set up, etc.

The above being said, I have to agree with what Foley said to some extent. A recent thread on the Yahoo group essentially said "we will write plugins, you should not. If you choose to do so, you need to vet them through us first and since this is a hobby we'll get to it when we can because we've also got core development going on and we're trying to knock items off of the features list". That's kind of a bummer.

If Nmap, OpenVAS, Metasploit, Wireshark or countless other open source applications went the way SDR# has gone they would not be around now. Instead, they've been around for 5-10+ years and are going strong with large community involvement and submissions that make them better. You protect the core code and it goes through peer review, however if someone wants to write a plugin that does something special then so be it. The plugin architecture is setup so that, sure, a plugin may ultimately crash an app, but it's not an officially blessed plugin and you use it at your own risk. Everybody who uses that plugin understands that. This doesn't look like the way SDR# is heading. Read the "Safety first: Don't use untrusted plugins" post and replies on the Yahoo message group from last Friday. They pretty much back this up. Most open source apps I've seen actively encourage input as far as code, plugins, addins, etc. Heck, if it's good enough you see it getting added into the core code base. Nmap does this a lot. It's not the wild wild west, but once a plugin has been thoroughly reviewed by the community, hashed out, etc. then it's put up as "official". In the meantime, the attitude is "do whatever you want, but don't blame us if it breaks". Again, community input as far as development and addins is encouraged, not discouraged. I would also add that there's usually debate and input into things like when the plugin architecture changes (even nightly changes) so you don't break existing plugins with those open source apps.

This whole plugin deal with SDR# is actually pretty sad, and in all honesty this attitude is going to stifle innovation with the app. Heck, the developers may as well make it closed source and use the plugin architecture as a way for them to add features and not expose it to the outside if they don't want people doing plugins. It'd sure save them a lot of frustration so they don't just get tired of the whole deal and decide the hobby isn't worth investing in as far as SDR# itself.

[jdow]

> "*Safety first: Don't use untrusted plugins" *post and replies on the Yahoo

> message group from last Friday. They pretty much back this up. Most open source
> apps I've seen actively encourage input as far as code, plugins, addins, etc.
> Heck, if it's good enough you see it getting added into the core code base. Nmap
> does this a lot. It's not the wild wild west, but once a plugin has
> been thoroughly reviewed by the community, hashed out, etc. then it's put up as
> "official". In the meantime, the attitude is "do whatever you want, but don't
> blame us if it breaks". Again, community input as far as development and addins
> is encouraged, not discouraged. I would also add that there's usually debate and
> input into things like when the plugin architecture changes (even nightly
> changes) so you don't break existing plugins with those open source apps.
>
> This whole plugin deal with SDR# is actually pretty sad, and in all honesty this
> attitude is going to stifle innovation with the app. Heck, the developers may as
> well make it closed source and use the plugin architecture as a way for them to
> add features and not expose it to the outside if they don't want people doing
> plugins. It'd sure save them a lot of frustration so they don't just get tired
> of the whole deal and decide the hobby isn't worth investing in as far as SDR#
> itself.
>
> On Tuesday, January 1, 2013 1:07:50 PM UTC-5, Foley wrote:
>
> All I can do is quote the developer from November last year.
>
> "First of all, please note that the SDR# is not a community driven project.
> It's an effort from a few people who have their own vision of software
> development. We have no aim adding any bells and whistles. <> please note
> that the only areas where we might be interested to exchange are: - DSP -
> GPU Processing The rest is of no added value to the project."

murrij, if you go back further you can get an appreciation for some of
youssef's general grumpiness. One of the major support issues for him is
the rtldsr.dll code. The Osmocom authors got into a major huff about it
being included with SDRSharp because of incompatible licenses. I happen
to believe that flap was a severe misfire on the part of the Osmocom
people. It seems to have soured youssef's attitude a bit. It is not
intended to be a be-all-and-end-all for SDR users. It's a programming
toy for the enjoyment and education for him and his co-developers, many
of whom seem to be doing nothing.

He is developing a plugin architecture. If you want a fancier front end
then figure out how to leverage his architecture to make it into an giant
DLL that your program can call to replace his main dialog with yours. Or
go and develop your own. That is what I am doing, with the same general
philosophy as youssef displays. It's for MY fun. And later on if somebody
wants to play with it - "Maybe" I'll send them a copy. (I'm NOT ready to
go through the GPL hoops when distributing it mainly due to the time
overhead incurred AND dealing with requests for ever greater amounts of
my free time to satisfy other people's demands. That latter can cause me
to snap out at people, "Then bloody well fork the code and do it yourself."

(This is why I call it "Open Sores" development. When you do your best and
somebody demands hundreds more hours of free development it's really hard
not to snap out, "Then put some food on my table, pay my electric bill,
and help pay the mortgage, aWQERP+OILIK it all!")

{^_^} Joanne, W6MKU