GRC squelch block with separate control signal?

I want to implement the equivalent of a carrier-operated relay – a
squelch block that provides an “on” signal at a threshold input signal
level, which then passes or blocks data at some point further downstream
rather than right at the point where the sensing is happening.

Are there GRC blocks that will allow this?

Thanks,

John

On Tue, Sep 6, 2011 at 10:22 AM, John Ackermann N8UR [email protected]
wrote:

John,
Yes, look in “Level Controls,” there is a “Simple Squelch,” “Standard
Squelch,” and “Power Squelch” as well as a simple “Threshold.” You’ll
have
to look closer into this blocks to find out how they work.

Tom

Tom R. said the following on 09/06/2011 11:28 AM:

Tom

Hi Tom –

The challenge is that the three squelch blocks all sense and switch the
data stream at the same point – the input signal is passed or not based
on its level. What I need instead is to sense the stream at one point,
and use that information to switch a different data stream.

I could picture two blocks – one that sets (and updates) a boolean
variable based on the current signal level, and another that switches a
separate sample stream based on whether that variable is true or false.
Does GRC support message passing between blocks in that fashion?

The practical example is an FM repeater where the transmitted signal is
turned on only when the received signal level exceeds a threshold.

Thanks,

John

On Wed, Sep 7, 2011 at 7:58 AM, John Ackermann N8UR [email protected]
wrote:

downstream rather than right at the point where the sensing is
John,
data stream at the same point – the input signal is passed or not based on

Thanks,

John

You can use a message for this, or you can use the stream tagging
interface
where a message is tagged specifically to a sample number. It’s a way of
passing synchronous messages where the message passing interface
doesn’t.

The problem is, you really have to work inside of the C++ code to get to
the
stream tags, so you won’t be able to work in GRC for it.

Tom

Hi John et al,

First, my apologies for waking up this very old thread. Only the other
night I had one of those “lightbulb” moments, as I have been trying to
implement something similiar for a while myself.

On 07/09/11 12:58, John Ackermann N8UR wrote:

happening.
Yes, look in “Level Controls,” there is a “Simple Squelch,” "Standard
and use that information to switch a different data stream.
Use a squelch block as normal. Use a function probe block to grab the
state of the “gate”. Function name you want from the squelch block is
unmuted. Returns 1 if un-muted (I.E squelch open), 0 otherwise.

Use that variable as the input to a selector. If you are clever, your
selector has two inputs, 0 and 1. input 0 feeds a null source via a
throttle, 1 is your (squelched) input from your RX.

The output from the selector feeds the rest of your TX stream

I could picture two blocks – one that sets (and updates) a boolean
variable based on the current signal level, and another that switches a
separate sample stream based on whether that variable is true or false.
Does GRC support message passing between blocks in that fashion?

The practical example is an FM repeater where the transmitted signal is
turned on only when the received signal level exceeds a threshold.

My own “design” is for a bi-directional cross-band repeater in both
directions, sometimes called a talk-thru unit. Very important to
disable the TX on the same band when you have a signal :slight_smile:

Another method would be to have an XML client get the values of the
squelch gate, and turn on/off each transmitter as appropriate by setting
the value of the TX selector.

Of course it being software, the possibilities are endless…multi
channel input and output…Multiple repeaters running on one URSP
[esp the USRP1 with two daughter boards…]

73s

Iain

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs