discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NBFM Tx Block High quad rate results in filter error


From: Marcus Müller
Subject: Re: NBFM Tx Block High quad rate results in filter error
Date: Mon, 21 Jun 2021 15:28:57 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

Hi Solomon!

That's a very good question, and it boils down to numerical math.
In your failing case, the ratio between audio rate and quadrature rate is 100. 
That means
that the NBFM TX block (which is a hier block) needs to create an interpolator.

Since an interpolator needs to suppress the 99 images that you get when you 
extend your
Nyquist rate hundredfold, that involves designing a low-pass filter with a 
1/100 passband
width.

Now, this is theoretically not a problem; the tool uses the Parks-McClellan 
Remez
algorithm. That needs an estimate of how many taps the filter will have, so it 
calls the
`remezord` function to figure that out:

    (n, fo, ao, w) = remezord ([freq1, freq2], desired_ampls,
                               [passband_dev, stopband_dev], Fs)
    # The remezord typically under-estimates the filter order, so add 2 taps by 
default

Um, what?
This function doesn't really seems to do what it's supposed to do. Sadly, 
optfir.py
doesn't try to figure out what goes wrong there :(

Consequently, the next line in gnuradio/filter/python/filter/optfir.py fails:

    taps = filter.pm_remez (n + nextra_taps, fo, ao, w, "bandpass")

yeah, adding 2 taps doesn't seem to suffice for this extreme resampling.

I'd recommend working around this for now: use a quadrature rate of 4×audio 
rate, and then
do the remaining interpolation by 25 with a rational resampler.

Not quite sure how to fix that - essentially, we're already using GSL, maybe 
that has a
better `remezord` function that we could use?

Best regards,
Marcus

On 21.06.21 14:30, Solomon Tan wrote:
> Hi all,
> 
> Could someone share why a high quadrature rate in the NBFM Transmit
> Block results in a "Runtime Error: insufficient extremals"? I dont get
> it. In my example, I wanted to NBFM modulate some audio. I resampled the
> audio to 80kHz from 48kHz. These are the parameters in the NBFM Transmit
> Block:
> 1. Audio Rate: int(80e3)
> 2. Quadrature Rate: int(8e6)
> 3. Tau: 75e-6
> 4. Max Deviation: 5e3
> 5. Preemphasis High Corner Freq: -1.0
> 
> When I run the flowgraph, I get the following error:
> ```
> gr::log :ERROR: pm_remez - insufficient extremals -- cannot continue
> Traceback (most recent call last):
>   File "/home/solomonbstoner/learn_tx_hackrf.py", line 183, in <module>
>     main()
>   File "/home/solomonbstoner/learn_tx_hackrf.py", line 161, in main
>     tb = top_block_cls()
>   File "/home/ladmin/learn_tx_hackrf.py", line 98, in init
>     self.analog_nbfm_tx_0 = analog.nbfm_tx(
>   File
> "/usr/local/lib/python3/dist-packages/gnuradio/analog/nbfm_tx.py", line
> 52, in init
>     interp_taps = filter.optfir.low_pass(interp_factor,   # gain
>   File "/usr/local/lib/python3/dist-packages/gnuradio/filter/optfir.py",
> line 45, in low_pass
>     taps = filter.pm_remez (n + nextra_taps, fo, ao, w, "bandpass")
> RuntimeError: insufficient extremals -- cannot continue
> ```
> 
> But when I change the Quadrature Rate to a lower value, int(80e3), the
> flowgraph runs. Why? What does quad rate have to do with "extremals",
> whatever that is?
> 
> Thanks
> Cheers,
> Sol
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]