Norvald H. Ryeng wrote: > I've been thinking of using gnuradio and a USRP to record > all channels simultaneously, and that would require some of these > blocks.
In case you missed it, I posted a couple weeks ago a "channelizer.py" program that does exactly this. You give it a frequency range and channel spacing, and some filtering parameters, and it will save to raw files all the NBFM demodulated audio in the range. It used the "skipping squelch" patch to prevent any audio when the carrier power was below threshold. I'm going to clean this up a bit and make it look more like the existing examples in the code tree, then check it in. But you can use the one previously posted to try out and it will use the regular (non skipping) squelch block if can't find the patched one. Beware, it has no parameter sanity checking and there's a list of parameter constraints in the email when I posted you'll need to understand. > There is one nice feature in listener that I would really like to see in > these blocks: the ability to start output a few seconds (or rather a > given number of samples) before the squelch opens and keep it open for a > while after the signal disappears. This corrects for bad tone modulation > and weak signals that otherwise would make the squelch block cut the > transmission into several chunks. Also, for my purposes, it makes the > squelch stay open during the "think time" between request and reply. Well, a 'hang' time parameter implementing a delay before closing squelch would be easy, but the pre-threshold opening would require buffering. Not sure the best way to do that. > Listener also has parameters that set a minimum and maximum time for the > squelch to stay open. The last one could easily be implemented as a > separate block, but the first one has to be implemented in the squelch > block. I'm not sure how useful these options are (I'm not using them), > but implementing them should be fairly straight-forward. I think about this. But I'll probably get something simple working first and add features later. > Me neither. I'm new to gnuradio (hi to the list, by the way -- I've been > lurking for a few months) and still at the getting-things-to-work stage. > I hope to spend some time this summer learning more about gnuradio, but > I'm still far from writing my own blocks. Welcome. And writing blocks isn't that hard if you do it inside a CVS checked out repository. Writing blocks outside the source tree is more difficult but the how-to covers it all. -Johnathan, AE6HO _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
