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
