Add wbfm receiver from lordmorgul master

[lordmorgul]

Update the integration of wbfm demodulator type to work in this fork; lordmorgul will work toward a pull request for this.

[lordmorgul]

Currently a command line input of "-d 2" which was wbfm is accepted by this fork and cursesgui shows type 2, but it defaults to type 0 nbfm silently.

[john-]

I had brought over pretty much everything from your master branch. I don't see the wbfm code there so that is probably why this feature got missed.

I normally think of wbfm as broadcast FM in the United States. Is it used for other things as well?

[lordmorgul]

In Amateur radio and GMRS the FM bandwidth can be either Narrow (12.5kHz) or Wide (25kHz). The FRS service uses Narrow only on its frequencies, as do most licensed commercial FM stations. The US did a "narrowbanding" of all the commercial licenses years back that made all Part 90 radios Narrow at 12.5kHz channel bandwidth.
I duplicated the NBFM tuner definition to make a wide one also.

It does help to match what you are trying to receive with the source to capture all the channel power and frequencies in the modulation. A narrow station received in wide will include extra noise level into the tuner, while a wide station received in narrow will exclude some of the channel power and clip the modulation frequencies some resulting in compressed voice range.

[lordmorgul]

Wide band: 5KHz deviation (noninal), uses a 25KHz wide channel.
Narrow band: 2.5KHz deviation (nominal), uses a 12.5KHz wide channel.

We currently channelize at 5kHz which is less than half the required maximum width of 11.2kHz for "narrowband" as FCC defined it, and good enough to catch near peak in one half or the other. Can channelize wider if knowing you are scanning for 25kHz channels, but that doesnt seem to have much performance benefit to ham2mon. I really just wanted to get the full 5kHz deviation plus some captured in the audio.

The Broadcast Wide FM is a 75kHz channel I think, that is not meant.

[john-]

Thanks for explaining this to me it helps a lot. I was thinking of broadcast FM which we do not need to support :)

It makes sense to support the wbfm even though where I am at and what I am interested in 12.5Khz is what is used.

I don't think I touched any of the core Receiver stuff so hopefully the changes go smooth.

[john-]

I am not able to see where WBFM code is in your master. Can you point an example of it out to me? I can bring it over to my repo here next.

[lordmorgul]

That is still not added back into master so that would be in the branch including wbfm in name. Now that I had that error in priority in there I would need to back up and havent had time, should do that for a stable last version. I am pointing to your repo instead and plan to make mine obsoleted but shouldnt leave it broken.

WBFM just duplicates the NBFM demodulator and changes its bandwidth, so could probably be done parametrically. I do not believe I added the optimization of changing the scanner bin count (step size) which would be possible for efficiency with wider channels.

[john-]

The one branch with WBFM I see is the one that also includes CTCSS:

wbfm-ctcss-processing

I am not clear how these two things are related. If I find some wide band signals around me maybe I can get at least that part working if I start with merging the code?

[lordmorgul]

Yeah those did not need to be combined so I should have kept separate branches.

WBFM is probably very easy for me to put in directly to yours as a new branch separately.

The CTCSS tone code is only partially tested in that the feature can be turned on without ill effects but may not have been preventing recording if the tone frequency did not match. This code has impact to receiver in the connection order within gnuradio elements; that is more intrusive since it adds elements to the rf processing chain to filter and isolate the near sub-audible tones. The recordings include the tones in the audio by default without this filter but actual radios do not because it is filtered before the speaker output, so it can leave a low humming sound in the recorded and monitored audio.
There is a gnuradio companion diagram file in the repo for wbfm with CTCSS that shows the intended connections of signal processing elements in the code.

[lordmorgul]

Before adding the new demodulator, it seems like it would be good housekeeping to pull demodulator classes out to new file. There will be three of them now, and I have a plan to add two more of them (SSB Lower and SSB Upper for HF listening).

[john-]

Agreed on separating out the demodulators.

I can take a pass at that. There are a couple of items I would like to get into master branch first. One is pretty much ready (channel log changes in the issues list) and the other uses that (wide range scanning). I will open a ticket for the wide range scanning one and give you some time to review them.

[lordmorgul]

Making an effort to get back at the review of these, WBFM, CTCSS, then the SSB demodulator planned.