[Discuss-gnuradio] Squelch developments
I am creating a new squelch block: gr.pwr_squelch_cc ..that will replicate the current functionality of simple_squelch_cc, and add an optional gating function. When gating is on, there will be no output samples when the historical power is below threshold. With gating off (the default), the block will output zeros. This latter is identical to the existing simple_squelch_cc. I had previously implemented this as a 'skipping' patch to simple_squelch_cc but because it changes the block from a 1:1 synchronous block to a variable output block (when skipping is on), it really needs to be a new class derived from gr_block instead of gr_sync_block. As far as naming goes, calling this pwr_squelch_xx is anticipation of other squelch type blocks: gr.pwr_squelch_ff - same as pwr_squelch_cc but for audio, like a "VOX" switch gr.ctcss_squelch_ff - gate or zero audio output when a ctcss tone is not present gr.noise_squelch_ff - gate or zero audio output when noise is present (I think this what standard_squelch is detecting) gr.dcs_squelch_ff - gate or zero audio output when digitally coded squelch is not present etc. (Not that I'm signing up to write all these!) If anyone thinks this is a misguided approach let me know. -Johnathan, AE6HO ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp_basic and gr_block
I'm trying to use a function in the usrp_basic class, but there's no SWIG .i script for it. While looking at the tutorials, I read that all processing blocks need to derive from the class gr_block. However, this isn't the case for usrp_basic. I guess this makes sense, as usrp_basic isn't really a processing block - the function I'm wanting to use just reads input from the RSSI circuit. Should I be consulting the Dawei Shen's processing block tutorial at all then? the usrp_basic class isn't even under the gr package. -Michael Ford- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Threading in python?
On Wed, 2006-06-14 at 22:09 -0700, Eric Blossom wrote: > On Thu, Jun 15, 2006 at 12:35:50AM -0400, Ilia Mirkin wrote: > > Quoting Michael Ford <[EMAIL PROTECTED]>: > > > > > > A somewhat more generic answer than Eric's: > > Thanks Ilia. > > > Python and threads don't mix easily. There's one python interpreter/state, > > and if it's interpreting in one thread, and you try to get it to do > > something > > else from another thread, things will go bad (trying to access state, > > running > > functions, etc may all do Bad Things (tm)). Python 2.4 and up has the > > concept of a GIL (Global Interpreter Lock), which you must acquire before > > doing > > anything else with the interpreter in a thread context. Alternatively you > > can dedicate one thread to synchronize access to the python interpreter. To > > my > > knowledge neither SWIG nor Boost.Python are aware of the GIL, so you must > > acquire/release it for them. > > Actually it's not too bad. The GIL has been around for quite a > while. Pretty sure it was before 2.4. Anyhow, if your threads are > all in python everything "just works". You're right, the concept of the GIL has been around for a while. But Python 2.4 added a couple of crucial convenience functions: PyGILState_Ensure() and PyGILState_Release() Which allow a thread which doesn't have (direct) access to the interpreter pointer to still be able to run python code. This is particularly useful if instead of spawning an interpreter the interpreter spawns you (e.g. swig/boost.python wrapper dlopen'd by python) and you spawn some threads that still need to deal with the interpter. -Ilia ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Squelch developments
On Sat, Jun 17, 2006 at 12:58:12PM -0700, Johnathan Corgan wrote: > I am creating a new squelch block: > > gr.pwr_squelch_cc [...] > As far as naming goes, calling this pwr_squelch_xx is anticipation of > other squelch type blocks: > > gr.pwr_squelch_ff - same as pwr_squelch_cc but for audio, like a "VOX" > switch > > gr.ctcss_squelch_ff - gate or zero audio output when a ctcss tone is not > present > > gr.noise_squelch_ff - gate or zero audio output when noise is present (I > think this what standard_squelch is detecting) > > gr.dcs_squelch_ff - gate or zero audio output when digitally coded > squelch is not present > > etc. Great! I would definitely want to see those. In some cases it is nice to have a recording of all communications without all the noise in between. I've been doing this for some time using the "listener" program (http://www.vanheusden.com/listener/) and input through the soundcard from a radio, but with that approach I need one radio and soundcard for each channel. I've been thinking of using gnuradio and a USRP to record all channels simultaneously, and that would require some of these blocks. 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. 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. > (Not that I'm signing up to write all these!) 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. Regards, Norvald H. Ryeng, LA6YKA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Squelch developments
May I sound a cautionary note. Squelches that do not have a ramp are not particularly kind to your listening sensibilities if this is to be used to produce an audible signal. This means that the squelch will ideally need a setting function for the ramp. The events are the same as "key clicks". Bob N4HY Johnathan Corgan wrote: I am creating a new squelch block: gr.pwr_squelch_cc -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Squelch developments
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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Squelch developments
Robert McGwier wrote: > May I sound a cautionary note. Squelches that do not have a ramp are > not particularly kind to your listening sensibilities if this is to be > used to produce an audible signal. This means that the squelch will > ideally need a setting function for the ramp. The events are the same > as "key clicks". Good catch. Would a linear ramp from 0.0 to 1.0 as a multiplier against the audio stream, applied over a user specified number of samples, be sufficient? I better get writing before you guys spec this into oblivion :-) -Johnathan, AE6HO ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Squelch developments
Johnathan Corgan wrote: Good catch. Would a linear ramp from 0.0 to 1.0 as a multiplier against the audio stream, applied over a user specified number of samples, be sufficient? Yes, although half a cycle of a raised cosine is almost as easy, and analytically correct. 73 Frank AB2KT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Squelch developments
Frank Brickle wrote: > Yes, although half a cycle of a raised cosine is almost as easy, and > analytically correct. 1/2 - cos(x)/2, for x from 0 to pi? Should this be applied (in reverse) as a decay window when squelch cuts in, as well as the attack window we've been talking about? -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Squelch developments
Exactly. 73 Frank AB2KT Johnathan Corgan wrote: Frank Brickle wrote: Yes, although half a cycle of a raised cosine is almost as easy, and analytically correct. 1/2 - cos(x)/2, for x from 0 to pi? Should this be applied (in reverse) as a decay window when squelch cuts in, as well as the attack window we've been talking about? -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] bugfix for TVRX2/3
I've just checked in a bugfix for the TVRX2 and TVRX3 boards. If you have one of them, please update to the latest CVS version of gr-usrp. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
