pfb_taps is (with some variable names simplified for clarity):
firdes.low_pass(2.0, oversampled_width, fm_dev*2 ,1000,
firdes.WIN_HAMMING, 6.76)
where oversampled_width = channel_width * (num_chan + 1)
for channel_width = 15 kHz, fm_dev = 5 kHz, and num_chan = 7.
For what it's worth, lpf_taps (used in the frequency xlating filter) is
firdes.low_pass(1.0, hardware_rate, oversampled_width /
2,chan_width, firdes.WIN_HAMMING, 6.76)
where hardware rate = 1 msps.
On 05/24/2017 01:00 PM, Marcus Müller wrote:
what's the pfb_taps design spec? (i.e. what did you use as argument for
firdes.lowpass()?)
Best regards,
Marcus
On 05/24/2017 04:38 PM, John Ackermann N8UR wrote:
Here's the whole flowgraph.
Once I get the code functioning, I'm planning to clean this up, maybe
add a few more channels, and make it easier to customize -- so you'd
just enter the ch0 carrier frequency and channel spacing, and the rest
is automatic.
On 05/23/2017 07:24 PM, John Ackermann N8UR wrote:
Interesting point, Marcus. I'll post the complete flowgraph tomorrow
when I am at my development machine. I did revert the audio rate out of
the demod to 15ksps and that helped somewhat. So maybe that can go
further.
On May 23, 2017, at 7:18 PM, "Marcus Müller" <marcus.muel...@ettus.com
<mailto:marcus.muel...@ettus.com>> wrote:
Hi John,
3 to 5 seconds doesn't sound all that much considering that
you're doing
stuff at a nominal 7.5 kS/s – compare [1]; the typical buffer size
between two blocks is 8 kB, and with floats (i.e. 32 b = 4 B),
that's
2000 S, and at 7.5 kS/s, that's 2/7.5 s = 0.26667 seconds for the
buffers between NBFM demod and add, and between add and
resampler. In
fact, NBFM demod internally is a hier block (might have more
low-rate
buffers); so, that's half a second for these two buffers alone...
In your very specific use case, using a higher sampling rate
might make
the problem more manageable. If you'd share the first half of
your flow
graph, we could discuss options for that!
Best regards,
Marcus
[1] http://gnuradio.org/blog/buffers
On 23.05.2017 22:04, John Ackermann N8UR wrote:
Hi Marcus and Kevin, and thanks for the info.
I've set all squelch gates off. In that case, I get good audio
if "OK
to block" in the audio sink is set to "yes" but the latency
is awful
-- 3 to 5 seconds! If "OK to block" is "no", then I get lots
of aU
and unusable audio.
If setting the squelch gates off means that samples are
continuously
sent through the adder to the sink, I don't understand why
blocking
makes the difference, or why the latency builds up so fast.
I'd try
using 44.1ksps on the sink, but the dropdown doesn't allow that
choice.
John
----
On 05/23/2017 02:51 PM, Kevin Reid wrote:
On Tue, May 23, 2017 at 11:31 AM, John Ackermann N8UR
<j...@febo.com
<mailto:j...@febo.com>> wrote:
I'm continuing to work on a multi-channel NBFM receiver
using the
polyphase filter. I have the basic system working, but am
hung up
on how to get audio out of the system; most of my attempts
end up
either with audio underruns, or stalls that result in
overruns.
You're using only one RF source hardware device, correct?
Even then, /some/ amount of overrun/underrun is inevitable
because the
RF receiver and the audio output are not using the same
clock
oscillator, so the resampling rate you've implemented is
not the
resampling rate you would ideally need (which there is no
way in GR to
actually detect or implement).
The relevant portion of the flowgraph is attached. Each
channel
ends up at a 15ksps rate and is fed into a power squelch,
then a
mult block that's used to mute or unmute the audio, then
NBFM
demod. The demodulated outputs are at 7.5ksps (though I
get the
same results with 15ksps) and the seven channels are added.
Then a
rational resample to 48ksps, volume control, and audio
sink at
48ksps.
I've tried the "gate" param of the power squelch block both
off and
on, and the "OK to block" option of the audio sink in
various
combinations, but I'm not able to get clean audio.
"Gate" should be off. What that option does is drop samples.
The problem
is that the Add block requires samples from every input to
produce an
output, so if any one of the inputs drops samples then
eventually your
flowgraph will not be able to make progress because some
buffers are
overfull and some are empty.
Any flowgraph that has paths that split (here, polyphase
channelizer)
and rejoin (here, add) MUST have exactly the same
input-samples-to-output-samples ratio on all of the paths,
or it will
eventually lock up.
"OK to block" does not do very much, but in this type of
application it
should be off. This means that if there is an overrun, the
audio sink
will discard samples rather than the internal buffers
filling up and
causing the RF source block to have to discard them instead;
while this
is very similar in principle, it means a higher
input-to-output latency.
The time to use "OK to block" is when your source has no
clock (e.g. it
is a file or an internal signal source of some sort) so the
audio sink
has to be responsible for deciding when it's time to take
more samples.
I'd appreciate any suggestions. One thing I wonder about
is the
placement of the blocks in the stream; would a different
order work
better?
The ordering should not matter (as long as it is not
incorrect in some
other way, of course).
When you have "Gate" off, which type of misbehavior do
you get?
Have you confirmed that your sound card/driver actually
supports 48 kHz?
What happens if you try a different sample rate?
Have you tried resampling to a rate slightly under or over
48 kHz, as
appropriate? That will help if you actually have a severe
clock skew
problem.
------------------------------------------------------------------------
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------------------------------------------------
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
