# Updated NBFM Recorder

**URL:** <https://www.ruby-forum.com/t/updated-nbfm-recorder/230384>\
**Category:** GNU Radio\
**Created:** [June 15, 2014, 2:25am UTC](https://www.ruby-forum.com/t/updated-nbfm-recorder/230384 "2014-06-15T02:25:15Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jason\_sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7993a0/32.png) [@jason\_sam](https://www.ruby-forum.com/u/jason_sam)\
**Post date:** [June 15, 2014, 2:25am UTC](https://www.ruby-forum.com/t/updated-nbfm-recorder/230384/1 "2014-06-15T02:25:15Z")

</div>

Hi all,

I updated my multi-channel, narrow-band FM recorder, tested with B200  
and  
N210, and put it on GitHub.

> **[GitHub - madengr/nbfm\_rec: Multi-channel narrow-band FM recorder for GNU Radio](https://github.com/madengr/nbfm_rec)**
>
> Multi-channel narrow-band FM recorder for GNU Radio - GitHub - madengr/nbfm\_rec: Multi-channel narrow-band FM recorder for GNU Radio

Features:

```
Parallel demodulation and recording of NBFM radio channels
Up to N channels limited by CPU and bandwidth of SDR (tested to 25 

```

MHz)  
Squelched audio blocked from recording  
Mixed audio for real-time monitoring  
Channels recorded to individual \*.wav files

Tested with:

```
GNU Radio 3.7
Ettus N210 + WBX
Ettus B200

```

Lou  
KD4HSO

–  
View this message in context:  
[http://gnuradio.4.n7.nabble.com/Updated-NBFM-Recorder-tp48925.html](http://gnuradio.4.n7.nabble.com/Updated-NBFM-Recorder-tp48925.html)  
Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com).

---

<div class="post-metadata">

**Author:** ![madengr](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ec9cab/32.png) [@madengr](https://www.ruby-forum.com/u/madengr)\
**Post date:** [June 15, 2014, 5:12pm UTC](https://www.ruby-forum.com/t/updated-nbfm-recorder/230384/2 "2014-06-15T17:12:15Z")

</div>

On Sat, Jun 14, 2014 at 8:23 PM, madengr [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> ```
> Up to N channels limited by CPU and bandwidth of SDR (tested to 25 MHz)
> 
> ```
> 
> Lou  
> KD4HSO

Nice work.

I recommend seeing if you can replace the bank for xlating\_fir\_filters  
with  
a pfb\_channelizer\_ccf block. This should be more computationally  
efficient  
than all of the xlating filters, so I’d really like to see if that’s  
true  
for you app.

Tom

---

<div class="post-metadata">

**Author:** ![madengr](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ec9cab/32.png) [@madengr](https://www.ruby-forum.com/u/madengr)\
**Post date:** [June 15, 2014, 6:29pm UTC](https://www.ruby-forum.com/t/updated-nbfm-recorder/230384/3 "2014-06-15T18:29:56Z")

</div>

I actually started with that, but the US 2 meter “suggested” channels  
are  
either 15 kHz or 20 kHz spacing depending on location. It’s interesting  
to  
dump all the 2 meter repeater traffic in my city to disk for several  
days.  
Even the busy ones are only active about 2 hours/day. Unfortunately the  
800  
MHz public saftey band is so wide it’s difficult to capture many  
channels,  
and they are P25 anyway. I patched in the DSD P25 decoder, but it can  
only  
handle two channels simultaneously. The public safety channel spacing  
may  
work well with the pfb\_channelizer.

Thanks,  
Lou  
KD4SHO

Tom R.-2 wrote

> * * *
> 
> Discuss-gnuradio mailing list

> Discuss-gnuradio@

> [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

–  
View this message in context:  
[http://gnuradio.4.n7.nabble.com/Updated-NBFM-Recorder-tp48925p48929.html](http://gnuradio.4.n7.nabble.com/Updated-NBFM-Recorder-tp48925p48929.html)  
Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com).

---

<div class="post-metadata">

**Author:** ![madengr](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ec9cab/32.png) [@madengr](https://www.ruby-forum.com/u/madengr)\
**Post date:** [June 17, 2014, 6:12pm UTC](https://www.ruby-forum.com/t/updated-nbfm-recorder/230384/4 "2014-06-17T18:12:43Z")

</div>

On Sun, Jun 15, 2014 at 12:28 PM, madengr [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Thanks,  
> Lou  
> KD4SHO

Gotcha. That makes sense. Thanks for the explanation.

There are ways to handle this situation of non-equal bandwidths, but I’d  
wonder if it’s more complicated for this project than it’s worth (using  
the  
concept of the reconstruction filters). Could be a good testing ground,  
though, to build a system that channelizes the entire band, does some  
signal detection for those channels that are active, figures out their  
channel bandwidth, and pulls them out or reconstructs them as necessary.  
It’s a pretty advanced use of the PFB channelizers, though, so it’s not  
a  
trivial experiment to just run.

Nice work!

Tom