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
|