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" <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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
