|
Hi John,
more of a note pad than an email:
PFB
firdes.low_pass(2.0,
oversampled_width, fm_dev*2 ,1000,
firdes.WIN_HAMMING, 6.76)
low_pass(double gain, double sampling_freq, double cutoff_freq,
double transition_width, gr::filter::firdes::win_type window,
double beta=6.76)
gain = 2
sampling_freq = oversampled_width =15e3*8 = 120e3,
cutoff = fm_dev *2 = 10e3,
transition_width= 1000 = sampling_freq/120
Those are pretty reasonable numbers; if anything, you could try
to slightly relax the transition width; the ratio between sampling
rate and transition width of a FIR typically [1] influences the
length, and thus the delay, of a linear phase filter.
eyeballing, this should be a filter of about 300 taps length
LPF
firdes.low_pass(1.0, hardware_rate,
oversampled_width /
2,chan_width, firdes.WIN_HAMMING, 6.76)
transition_width = chan_width = sampling_rate/66.66
this filter should be about half as long as the one above.
Conclusion
While these filters aren't the smallest filters in the world, a
group delay of ca 150 and 75 samples shouldn't be the issue here.
Best regards,
Marcus
[1] https://dsp.stackexchange.com/a/31077/13320
On 24.05.2017 20:45, John Ackermann
N8UR wrote:
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"
<address@hidden
<mailto:address@hidden>> 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
<address@hidden
<mailto:address@hidden>> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------------------------------------------------
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|