Set_auto_tr(), gr_stall, and PTT

This email is to verify 2 items:

A) As per emails (1) and (2) below, in order to use the set_auto_tr()
feature on RFX boards, I need to stall the TX path somehow since -
any- input on the TX path will result in no RX (even all 0’s).

B) After searching through gnuradio-core/src/lib, I find no
“gr_stall” or similar. Does this block exist anywhere, and if not,
is there a simple way around it or should I just write the block
(it’s not difficult, but why reinvent the wheel)? Or does someone
have an implementation that I can leverage?

The “set_auto_tr()” method sounds from my reading to be a great way
to go, but the examples I’ve found in gnuradio-examples instead use
“subdev.set_enable()” instead … which from reading through the GNU
Radio email archives is quite a bit slower than the former. Thus my
wondering if anyone is using the former, and if so, how?

Thanks! - MLD

1: < http://lists.gnu.org/archive/html/discuss-gnuradio/2006-09/
msg00233.html >

From: Eric B. [email protected]
Date: September 23, 2006 6:30:33 PM EDT
To: Bdale Garbee [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] USRP push-to-talk?

[snip]

(2) Take advantage of the hooks for “auto T/R switching”.
The RFX boards use this, but it’s ignored by the basic tx and rx.

[snip]

all this depends on your application “stalling” the
transmit path unless it’s got something to do. I seem to recall
that somebody built a “stall” block, but in looking through “general”,
I don’t see it. Does this sound familiar to anyone? Johnathan,
weren’t you looking at this? (It might have been a mute/squelch
block, with the same idea).

As I recall it was going to work like this:

stall = gr.stall(sizeof_item)


stall.set_stall(True) # Causes the block to consume all input,
# but produce no output

stall.set_stall(False) # block copies input to output, producing
# and consuming in the normal way

Then your “push to talk” button would just call the set_stall method
as appropriate.

2: < http://lists.gnu.org/archive/html/discuss-gnuradio/2006-11/
msg00234.html >

From: Eric B. [email protected]
Date: November 14, 2006 10:34:56 PM EST
To: [email protected]
Cc: gnuradio mailing list [email protected]
Subject: Re: [Discuss-gnuradio] Re: USRP push-to-talk?

On Mon, Nov 13, 2006 at 09:39:30PM -0500, [email protected] wrote:
[snip]

Also, in a previous e-mail you suggested using Auto T/R in a push-
to-talk case.
Would this help in the situation where I want just a half-duplex
system? My
understanding of the Auto T/R says no, but that doesn’t mean that
I’m right :wink:

If you stall the transmit pipeline unless the user is pressing the PTT
button, then Auto T/R is what you want. In that case, the receiver is
always running, but the transmitter is only producing output when it’s
not stalled.

If Tom’s around, check with him. He and I talked about ways to do this.

Eric

On Mon, Sep 10, 2007 at 03:19:53PM -0400, Michael D. wrote:

have an implementation that I can leverage?
There’s no gr_stall. Currently auto_tr mode is used with the packet
data examples. See gnuradio-examples/python/digital. There is no
explicit “stall”, the transmitter pipeline stalls when no packets are
being fed into the PHY via the message source.

The “set_auto_tr()” method sounds from my reading to be a great way
to go, but the examples I’ve found in gnuradio-examples instead use
“subdev.set_enable()” instead … which from reading through the GNU
Radio email archives is quite a bit slower than the former. Thus my
wondering if anyone is using the former, and if so, how?

Eric

On Sep 10, 2007, at 10:07 PM, Eric B. wrote:

There’s no gr_stall. Currently auto_tr mode is used with the packet
data examples. See gnuradio-examples/python/digital. There is no
explicit “stall”, the transmitter pipeline stalls when no packets are
being fed into the PHY via the message source.

OK. Well, I’ll create a “stall” block and see how it works under a
standard PTT scenario.

Upon further reflection, I think doing simultaneous TX/RX might work
better when doing the “push” of PTT. That way I can see the TXd
signal on the RX side - but then mute it so that the (loopback) sound
doesn’t come through. From reading the GNU Radio list archives,
doing simultaneous TX/RX seems possible using either separate TX and
RX daughtercards, or different antennas on a single RFX series
daughtercard. I was really hoping to to simultaneous TX/RX using -
just- the TX/RX antenna on an RFX board, but I’ve had no luck doing
that. Anyone know if this last scenario is possible? Thanks again.

  • MLD

Robert M. wrote:

Michael,

Any luck in answering your last question?:

“I was really hoping to simultaneous TX/RX using -
just- the TX/RX antenna on an RFX board, but I’ve had no luck doing
that. Anyone know if this last scenario is possible?”

I am very much interested in the same functionality.

You simply can’t transmit and receive on the same antenna at the same
time. If you look at the schematics you will see why. If you want to
transmit and receive at the same time, you need to use the TX/RX port
for transmit and the RX2 port for receive. That’s why it is there.

Matt

Thanks for the quick reply Matt. However, my main question is whether
or not
transmission and reception can be time multiplexed using the TX/RX port
of a
single RFX daughterboard. My main goal is to switch back and forth
between
transmitting and receiving using the same TX/RX port. Is this possible,
and
if so, how would one go about about implementing it in code? I would
like
to do it as fast as possible.

Thanks again,

Rob

Matt E. wrote:

I am very much interested in the same functionality.


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://www.nabble.com/set_auto_tr()%2C-gr_stall%2C-and-PTT-tp12600639p14540565.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Robert - To answer a few questions (and some background to answer them):

  1. I did get the PTT working, and can see the TX on the RX antenna -
    no matter which antenna I select (on an RFX board). If I select the
    TX/RX antenna, then the RX is attenuated ~25 dB or so. If I select
    the RX antenna, then the RX is not significantly attenuated.

  2. I also got simultaneous TX/RX working, using different antennas
    (“full duplex”). It was -quite- handy that the “select_rx_antenna()”
    method was added just as I was searching for it :wink: If only this had
    been there a week earlier (9/1; it was added in r6377 on 9/10), my in-
    house demo would have been well-received! At least I got those bugs
    worked out in time for “the big demo”.

  3. I also got the PTT working on a single TX/RX antenna (“half
    duplex”), by turning on the USRP_TX object (“enable(true)” I think)
    when the PTT is “pushed”, then turning it off when the PTT is
    “released”. This works quite well, and is modeled after the USRP
    NBFM PTT example.

  4. I never got to the “gr_stall()” block, because I got (1) and (2)
    working. It would still be interesting to see if “set_auto_tr()” and
    the scheduler would work with a “stall” block on the TX side. I
    don’t have time to look into this right now.

  5. What Matt says is true, roughly, regarding simultaneous TX/RX on a
    single antenna. I haven’t tried this yet, it’s purely observational
    at this time (as per 0 above) but: You actually can do simultaneous
    TX/RX on that antenna of an RFX board, but there’s a penalty on the
    RX side in terms of attenuation … something like 25 dB. I believe
    that simultaneous TX/RX could be made to work if the penalty is OK
    for your needs.

  6. You can do time multiplexed switching of the TX/RX antenna (as per
    2 above). You do this by disabling the USRP_TX object, to allow for
    RX. Then you enable the USRP_TX to do TX. There have been
    discussions on this email list regarding how quickly you can enable /
    disable TX … something like a few ms IIRC. Keep in mind that the
    flow-graph side of GNU Radio has no concept of “time” and isn’t
    designed to do TDMA; you can probably implement “coarse” TDMA via OS-
    specific timers. I think for anything reasonably fine-grained or
    time-precise, you’ll need to use the USRP-server and mblock modules
    of GNU Radio.

Hope this helps! - MLD

Michael,

Any luck in answering your last question?:

“I was really hoping to simultaneous TX/RX using -
just- the TX/RX antenna on an RFX board, but I’ve had no luck doing
that. Anyone know if this last scenario is possible?”

I am very much interested in the same functionality.

Thanks,
Rob

Michael D.-2 wrote:

Upon further reflection, I think doing simultaneous TX/RX might work


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://www.nabble.com/set_auto_tr()%2C-gr_stall%2C-and-PTT-tp12600639p14538630.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Your message stated you wanted to do “simultaneous TX/RX”. If you want
to switch back and forth, then you do not want simultaneous, which is a
good thing. You want to use the auto t/r switching mode.

Matt

On Dec 29, 2007, at 4:03 PM, Matt E. wrote:

Your message stated you wanted to do “simultaneous TX/RX”. If you
want to switch back and forth, then you do not want simultaneous,
which is a good thing. You want to use the auto t/r switching mode.

Just to clarify, and IIRC so please correct:

The “auto_tr()” mode works as follows: If -nothing- is on the TX
stream on the USRP hardware (e.g. data is stalled, by whatever
means), then RX will happen. If -anything- is going across USRP TX
hardware (e.g. all 0’s, your desired signal, whatever), then TX will
happen.

The best way to make use of “auto_tr()” is via packets, not
streams … thus my comment about not yet trying out a “gr_stall”
block for streaming, since I haven’t really tried “packets” yet.

Given my PPT example, it makes more sense to use half-duplex on 1
antenna (not auto_tr), or full-duplex on 2 antennas (not auto_tr),
rather than try to packetize the data stream to make use of auto_tr.

Thus, if your application can be easily packetized, then the use of
“auto_tr” is warranted. Otherwise, either use different antennas or
manually switch the USRP_TX object on and off.

Guys,
Thanks for your help. I think my best path forward is to modify the
usrp_nbfm_ptt.py code and use set_enable. My intended application
requires
the reuse of the same antenna for TX and RX. My data is not packetized
(it
is simply tones to begin with), so it seems the easiest path forward.
My
end goal is to transmit and receive between 2 RFX daughterboards using
only
the RX/TX ports in a time-multiplexed fashion (see post “TX/RX
Coordination”). Step one will be to perform the switching based on
space-bar depression, but eventually I’d like to incorporate a system
timer
for this functionality.
Thanks again,
Rob

Michael D.-2 wrote:

stream on the USRP hardware (e.g. data is stalled, by whatever
rather than try to packetize the data stream to make use of auto_tr.
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://www.nabble.com/set_auto_tr()%2C-gr_stall%2C-and-PTT-tp12600639p14541974.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Michael D. wrote:

then RX will happen. If -anything- is going across USRP TX hardware
(e.g. all 0’s, your desired signal, whatever), then TX will happen.

yes

The best way to make use of “auto_tr()” is via packets, not streams
… thus my comment about not yet trying out a “gr_stall” block for
streaming, since I haven’t really tried “packets” yet.

I guess that would be correct

Given my PPT example, it makes more sense to use half-duplex on 1
antenna (not auto_tr), or full-duplex on 2 antennas (not auto_tr),
rather than try to packetize the data stream to make use of auto_tr.

No, I would use auto_tr on 1 antenna. When there is nothing being sent
on TX, it will receive. Just send a stream to the TX when you want to
talk.

Matt

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