Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
On 03/01/2012 11:14 AM, George Nychis wrote: A quick question on how the trigger works in UHD. I have some basic code integrated with the help of your suggestions. Burst tagger port 0 is the raw complex sample stream. Burst tagger port 1 is the trigger. Let's say the raw complex sample stream has an outgoing packet. I'm assume that I change the value on port 1 that corresponds to the first sample of the preamble to a value of '1': which is the trigger like hey, here is the start of the burst! My question is, for *all* indexes on port 1 that correspond to samples in the packet on port 1, should those also be of value 1? Or only just the first sample? What about the last sample? Just trying to understand exactly how the trigger works. Sorry, I dont know anything about the burst tagger. But I can tell you about the stream tags that I guess burst tagger is producing. Basically in the gnuradio framework, arbitrary metadata can be associated with a sample, aka sample tags. When the scheduler calls work in the uhd sink block, work looks for any start/end of burst tags and timestamp tags. UHD sends packets of samples into the USRP. Each packet can have metadata associated with it (burst flags, times). The job of the work function is to slice the stream up such that the tag metadata gets setup to go out with the metadata for the packet of samples. So burst tagger should only be causing 1 start of burst tag and 1 end of burst tag. The start of burst is sort of optional as far as the hardware cares. Mostly, you want to communicate end of burst when there will be no more data. -josh On Mon, Feb 27, 2012 at 9:12 PM, Josh Blum j...@ettus.com wrote: On 02/27/2012 05:30 PM, George Nychis wrote: It's be good if you can chime in here, Josh :) It seems like this is something that should be fixed about tunnel.py in future GNU Radio releases for use with UHD. Like removing it altogether :-) That is clearly documented as control of samples to the host to be continuous or not. Basically, RX is intended to work on a continuous streaming model, which is why stream command inst swigged up. The start()/stop() methods are actually the ones issuing the command. When and if the pmt based message passing gets merged, i was going to implement control messages to deal with streaming, possibly other things. This lets you tie the uhd source block into a control plane. As is stands now, i guess someone could just forward the stream command stuff, so long as the work() function knew to block when there is definitely not supposed to be samples. That way you avoid the scheduler marking the block done on a timeout. However, I don't see that same control for the TX stream. Tx_metadata_t and t_streamer control the bursts, but don't seem to control the overall stream? Maybe I am missing something. You can use stream tags to control start/stop of burst and transmit times. See the usrp sink header or the tags demo in gr-uhd. Now that being said, the framer blocks in tunnel.py could be more intelligent and properly shutoff streaming (aka end a burst) when there is no data. That way you avoid underflow when there isnt a continuous supply of data to modulate. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
Sorry, I dont know anything about the burst tagger. But I can tell you about the stream tags that I guess burst tagger is producing. Basically in the gnuradio framework, arbitrary metadata can be associated with a sample, aka sample tags. When the scheduler calls work in the uhd sink block, work looks for any start/end of burst tags and timestamp tags. UHD sends packets of samples into the USRP. Each packet can have metadata associated with it (burst flags, times). The job of the work function is to slice the stream up such that the tag metadata gets setup to go out with the metadata for the packet of samples. So burst tagger should only be causing 1 start of burst tag and 1 end of burst tag. The start of burst is sort of optional as far as the hardware cares. Mostly, you want to communicate end of burst when there will be no more data. -josh The way the burst-tagger appears to work is that it watches the trigger input, and when that trigger input changes state, it inserts the tag corresponding to the new state into the stream. That sounds *almost* like what is needed, except that in a GRC flow-graph, data will continue to flow after the EOB tag has been inserted, which won't really make things happy. On 02/27/2012 05:30 PM, George Nychis wrote: It's be good if you can chime in here, Josh :) It seems like this is something that should be fixed about tunnel.py in future GNU Radio releases for use with UHD. Like removing it altogether :-) That is clearly documented as control of samples to the host to be continuous or not. Basically, RX is intended to work on a continuous streaming model, which is why stream command inst swigged up. The start()/stop() methods are actually the ones issuing the command. When and if the pmt based message passing gets merged, i was going to implement control messages to deal with streaming, possibly other things. This lets you tie the uhd source block into a control plane. As is stands now, i guess someone could just forward the stream command stuff, so long as the work() function knew to block when there is definitely not supposed to be samples. That way you avoid the scheduler marking the block done on a timeout. However, I don't see that same control for the TX stream. Tx_metadata_t and t_streamer control the bursts, but don't seem to control the overall stream? Maybe I am missing something. You can use stream tags to control start/stop of burst and transmit times. See the usrp sink header or the tags demo in gr-uhd. Now that being said, the framer blocks in tunnel.py could be more intelligent and properly shutoff streaming (aka end a burst) when there is no data. That way you avoid underflow when there isnt a continuous supply of data to modulate. -Josh -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
A quick question on how the trigger works in UHD. I have some basic code integrated with the help of your suggestions. Burst tagger port 0 is the raw complex sample stream. Burst tagger port 1 is the trigger. Let's say the raw complex sample stream has an outgoing packet. I'm assume that I change the value on port 1 that corresponds to the first sample of the preamble to a value of '1': which is the trigger like hey, here is the start of the burst! My question is, for *all* indexes on port 1 that correspond to samples in the packet on port 1, should those also be of value 1? Or only just the first sample? What about the last sample? Just trying to understand exactly how the trigger works. On Mon, Feb 27, 2012 at 9:12 PM, Josh Blum j...@ettus.com wrote: On 02/27/2012 05:30 PM, George Nychis wrote: It's be good if you can chime in here, Josh :) It seems like this is something that should be fixed about tunnel.py in future GNU Radio releases for use with UHD. Like removing it altogether :-) That is clearly documented as control of samples to the host to be continuous or not. Basically, RX is intended to work on a continuous streaming model, which is why stream command inst swigged up. The start()/stop() methods are actually the ones issuing the command. When and if the pmt based message passing gets merged, i was going to implement control messages to deal with streaming, possibly other things. This lets you tie the uhd source block into a control plane. As is stands now, i guess someone could just forward the stream command stuff, so long as the work() function knew to block when there is definitely not supposed to be samples. That way you avoid the scheduler marking the block done on a timeout. However, I don't see that same control for the TX stream. Tx_metadata_t and t_streamer control the bursts, but don't seem to control the overall stream? Maybe I am missing something. You can use stream tags to control start/stop of burst and transmit times. See the usrp sink header or the tags demo in gr-uhd. Now that being said, the framer blocks in tunnel.py could be more intelligent and properly shutoff streaming (aka end a burst) when there is no data. That way you avoid underflow when there isnt a continuous supply of data to modulate. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
On 02/28/2012 11:51 PM, George Nychis wrote:
It's be good if you can chime in here, Josh :)
It seems like this is something that should be fixed about tunnel.py in
future GNU Radio releases for use with UHD.
tunnel.py should be burned at the stake :)
This flow graph creates more bad press for gnuradio than anything else
in the world.
A good GSoC project would be to re-implement the flow graph in a real
grc flow graph and add all the cool new features in gnuradio to it.
Philip
I'm trying to do my fair share of research here and tackle it. If what you
say is true, Marcus, the control I need is over the TX chain.
I did a bunch of reading through the UHD docs here:
http://files.ettus.com/uhd_docs/doxygen/html/annotated.html
I see various controls using tx_streamer and tx_metadata_t to use tags to
control samples to be part of a burst. Like, marking the start and end of
my TX burst of samples which can construct a packet.
No prob, I can do that. But it seems like there needs to be some sort of
UHD stream command which turns the TX chain in to an on-demand chain and
not continuously streaming. On the other hand, I would like RX to be
continuous.
I see the RX control to specify stream controls here:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html
That is clearly documented as control of samples to the host to be
continuous or not.
However, I don't see that same control for the TX stream. Tx_metadata_t and
t_streamer control the bursts, but don't seem to control the overall
stream? Maybe I am missing something.
On Sunday, February 26, 2012, Marcus D. Leech wrote:
**
On 02/26/2012 08:54 PM, George Nychis wrote:
On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech
mle...@ripnet.comjavascript:_e({}, 'cvml', 'mle...@ripnet.com');
wrote:
On 02/26/2012 02:29 PM, Apurv Bhartia wrote:
Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I
do, is to start both the flowgraphs, and just listen for packets.
In which case, the TX side is running--even if you aren't sending any
*data* bits, it's still transmitting, and blocking the receiver.
You'll have to get more sophisticated about half-duplex flow management,
using tagging to tell UHD to turn on/off the TX side.
Josh probably has better words of wisdom on this than I.
Hi Marcus,
I'm working with Apurv, so I'm going to chime in here :)
I tried doing some searching on the mailing list, but I wasn't really
able to find much on this. I also thought that auto tr would handle this.
I found a post from Josh on the mailing list that said Auto TR is always
enabled in UHD.
http://www.ruby-forum.com/topic/1527488
Yes, it is enabled in UHD. But since Gnu Radio is a *streaming* model,
you need to take special measures to control TX from within a
Gnu Radio flow-graph. YOu need to insert a tag in the stream to control
the transmitter, otherwise, you'll be continuously streaming.
What you do is insert a burst-tagger into your stream, and set it to send
the appropriate tags for UHD into the stream using the trigger
input. I just can't off the top of my head, remember what those stream
tags are at the moment. But the basic issue is that Gnu Radio
uses a streaming model, and while UHD itself (at the C++ level) has
fine-grianed control over transmitter functions, etc, gr-uhd doesn't
directly expose any of that, because there's just not mechanism within
Gnu Radio to expose that stuff. The stream tagging, however,
does allow you to control the transmitter state. In the particular case
of the XCVR2450, the hardware is physically incapable of
TX and RX at the same time.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
___
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
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
It's be good if you can chime in here, Josh :)
It seems like this is something that should be fixed about tunnel.py in
future GNU Radio releases for use with UHD.
I'm trying to do my fair share of research here and tackle it. If what you
say is true, Marcus, the control I need is over the TX chain.
I did a bunch of reading through the UHD docs here:
http://files.ettus.com/uhd_docs/doxygen/html/annotated.html
I see various controls using tx_streamer and tx_metadata_t to use tags to
control samples to be part of a burst. Like, marking the start and end of
my TX burst of samples which can construct a packet.
No prob, I can do that. But it seems like there needs to be some sort of
UHD stream command which turns the TX chain in to an on-demand chain and
not continuously streaming. On the other hand, I would like RX to be
continuous.
I see the RX control to specify stream controls here:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html
That is clearly documented as control of samples to the host to be
continuous or not.
However, I don't see that same control for the TX stream. Tx_metadata_t and
t_streamer control the bursts, but don't seem to control the overall
stream? Maybe I am missing something.
On Sunday, February 26, 2012, Marcus D. Leech wrote:
**
On 02/26/2012 08:54 PM, George Nychis wrote:
On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech
mle...@ripnet.comjavascript:_e({}, 'cvml', 'mle...@ripnet.com');
wrote:
On 02/26/2012 02:29 PM, Apurv Bhartia wrote:
Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I
do, is to start both the flowgraphs, and just listen for packets.
In which case, the TX side is running--even if you aren't sending any
*data* bits, it's still transmitting, and blocking the receiver.
You'll have to get more sophisticated about half-duplex flow management,
using tagging to tell UHD to turn on/off the TX side.
Josh probably has better words of wisdom on this than I.
Hi Marcus,
I'm working with Apurv, so I'm going to chime in here :)
I tried doing some searching on the mailing list, but I wasn't really
able to find much on this. I also thought that auto tr would handle this.
I found a post from Josh on the mailing list that said Auto TR is always
enabled in UHD.
http://www.ruby-forum.com/topic/1527488
Yes, it is enabled in UHD. But since Gnu Radio is a *streaming* model,
you need to take special measures to control TX from within a
Gnu Radio flow-graph. YOu need to insert a tag in the stream to control
the transmitter, otherwise, you'll be continuously streaming.
What you do is insert a burst-tagger into your stream, and set it to send
the appropriate tags for UHD into the stream using the trigger
input. I just can't off the top of my head, remember what those stream
tags are at the moment. But the basic issue is that Gnu Radio
uses a streaming model, and while UHD itself (at the C++ level) has
fine-grianed control over transmitter functions, etc, gr-uhd doesn't
directly expose any of that, because there's just not mechanism within
Gnu Radio to expose that stuff. The stream tagging, however,
does allow you to control the transmitter state. In the particular case
of the XCVR2450, the hardware is physically incapable of
TX and RX at the same time.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
It's be good if you can chime in here, Josh :)
It seems like this is something that should be fixed about tunnel.py in
future GNU Radio releases for use with UHD.
I'm trying to do my fair share of research here and tackle it. If what you
say is true, Marcus, the control I need is over the TX chain.
I did a bunch of reading through the UHD docs here:
http://files.ettus.com/uhd_docs/doxygen/html/annotated.html
I see various controls using tx_streamer and tx_metadata_t to use tags to
control samples to be part of a burst. Like, marking the start and end of
my TX burst of samples which can construct a packet.
No prob, I can do that. But it seems like there needs to be some sort of
UHD stream command which turns the TX chain in to an on-demand chain and
not continuously streaming. On the other hand, I would like RX to be
continuous.
I see the RX control to specify stream controls here:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html
That is clearly documented as control of samples to the host to be
continuous or not.
However, I don't see that same control for the TX stream. Tx_metadata_t and
t_streamer control the bursts, but don't seem to control the overall
stream? Maybe I am missing something.
On Sunday, February 26, 2012, Marcus D. Leech wrote:
**
On 02/26/2012 08:54 PM, George Nychis wrote:
On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech
mle...@ripnet.comjavascript:_e({}, 'cvml', 'mle...@ripnet.com');
wrote:
On 02/26/2012 02:29 PM, Apurv Bhartia wrote:
Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I
do, is to start both the flowgraphs, and just listen for packets.
In which case, the TX side is running--even if you aren't sending any
*data* bits, it's still transmitting, and blocking the receiver.
You'll have to get more sophisticated about half-duplex flow management,
using tagging to tell UHD to turn on/off the TX side.
Josh probably has better words of wisdom on this than I.
Hi Marcus,
I'm working with Apurv, so I'm going to chime in here :)
I tried doing some searching on the mailing list, but I wasn't really
able to find much on this. I also thought that auto tr would handle this.
I found a post from Josh on the mailing list that said Auto TR is always
enabled in UHD.
http://www.ruby-forum.com/topic/1527488
Yes, it is enabled in UHD. But since Gnu Radio is a *streaming* model,
you need to take special measures to control TX from within a
Gnu Radio flow-graph. YOu need to insert a tag in the stream to control
the transmitter, otherwise, you'll be continuously streaming.
What you do is insert a burst-tagger into your stream, and set it to send
the appropriate tags for UHD into the stream using the trigger
input. I just can't off the top of my head, remember what those stream
tags are at the moment. But the basic issue is that Gnu Radio
uses a streaming model, and while UHD itself (at the C++ level) has
fine-grianed control over transmitter functions, etc, gr-uhd doesn't
directly expose any of that, because there's just not mechanism within
Gnu Radio to expose that stuff. The stream tagging, however,
does allow you to control the transmitter state. In the particular case
of the XCVR2450, the hardware is physically incapable of
TX and RX at the same time.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
On 27/02/12 08:30 PM, George Nychis wrote:
It's be good if you can chime in here, Josh :)
It seems like this is something that should be fixed about tunnel.py
in future GNU Radio releases for use with UHD.
I've attached a skeletal piece of GRC that uses the Burst Tagger block
with a 10Hz trigger input to insert
tx_eob/tx_sob tags into the stream. I'm not sure whether this will
have the desired effect or not, but at
least in theory it should.
I'm trying to do my fair share of research here and tackle it. If what
you say is true, Marcus, the control I need is over the TX chain.
I did a bunch of reading through the UHD docs here:
http://files.ettus.com/uhd_docs/doxygen/html/annotated.html
I see various controls using tx_streamer and tx_metadata_t to use tags
to control samples to be part of a burst. Like, marking the start and
end of my TX burst of samples which can construct a packet.
No prob, I can do that. But it seems like there needs to be some sort
of UHD stream command which turns the TX chain in to an on-demand
chain and not continuously streaming. On the other hand, I would like
RX to be continuous.
I see the RX control to specify stream controls here:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html
That is clearly documented as control of samples to the host to be
continuous or not.
However, I don't see that same control for the TX stream.
Tx_metadata_t and t_streamer control the bursts, but don't seem to
control the overall stream? Maybe I am missing something.
On Sunday, February 26, 2012, Marcus D. Leech wrote:
On 02/26/2012 08:54 PM, George Nychis wrote:
On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech
mle...@ripnet.com javascript:_e({}, 'cvml',
'mle...@ripnet.com'); wrote:
On 02/26/2012 02:29 PM, Apurv Bhartia wrote:
Its an XCVR2450, but I do *not* start any 'packet'
transmissions. All I do, is to start both the flowgraphs,
and just listen for packets.
In which case, the TX side is running--even if you aren't
sending any *data* bits, it's still transmitting, and
blocking the receiver.
You'll have to get more sophisticated about half-duplex flow
management, using tagging to tell UHD to turn on/off the TX side.
Josh probably has better words of wisdom on this than I.
Hi Marcus,
I'm working with Apurv, so I'm going to chime in here :)
I tried doing some searching on the mailing list, but I wasn't
really able to find much on this. I also thought that auto tr
would handle this. I found a post from Josh on the mailing list
that said Auto TR is always enabled in UHD.
http://www.ruby-forum.com/topic/1527488
Yes, it is enabled in UHD. But since Gnu Radio is a *streaming*
model, you need to take special measures to control TX from within a
Gnu Radio flow-graph. YOu need to insert a tag in the stream to
control the transmitter, otherwise, you'll be continuously streaming.
What you do is insert a burst-tagger into your stream, and set it
to send the appropriate tags for UHD into the stream using the trigger
input. I just can't off the top of my head, remember what those
stream tags are at the moment. But the basic issue is that Gnu Radio
uses a streaming model, and while UHD itself (at the C++ level)
has fine-grianed control over transmitter functions, etc, gr-uhd
doesn't
directly expose any of that, because there's just not mechanism
within Gnu Radio to expose that stuff. The stream tagging, however,
does allow you to control the transmitter state. In the
particular case of the XCVR2450, the hardware is physically
incapable of
TX and RX at the same time.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
burst_tagger_uhd.grc
Description: application/gnuradio-grc
#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Burst Tagger Uhd
# Generated: Mon Feb 27 20:52:20 2012
##
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import wx
class burst_tagger_uhd(grc_wxgui.top_block_gui):
def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title=Burst Tagger Uhd)
_icon_path = /usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png
self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))
##
# Variables
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
On 02/27/2012 05:30 PM, George Nychis wrote: It's be good if you can chime in here, Josh :) It seems like this is something that should be fixed about tunnel.py in future GNU Radio releases for use with UHD. Like removing it altogether :-) That is clearly documented as control of samples to the host to be continuous or not. Basically, RX is intended to work on a continuous streaming model, which is why stream command inst swigged up. The start()/stop() methods are actually the ones issuing the command. When and if the pmt based message passing gets merged, i was going to implement control messages to deal with streaming, possibly other things. This lets you tie the uhd source block into a control plane. As is stands now, i guess someone could just forward the stream command stuff, so long as the work() function knew to block when there is definitely not supposed to be samples. That way you avoid the scheduler marking the block done on a timeout. However, I don't see that same control for the TX stream. Tx_metadata_t and t_streamer control the bursts, but don't seem to control the overall stream? Maybe I am missing something. You can use stream tags to control start/stop of burst and transmit times. See the usrp sink header or the tags demo in gr-uhd. Now that being said, the framer blocks in tunnel.py could be more intelligent and properly shutoff streaming (aka end a burst) when there is no data. That way you avoid underflow when there isnt a continuous supply of data to modulate. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
On 02/26/2012 10:38 AM, Apurv Bhartia wrote: Hi, I'm running Ubuntu 11.10 + UHD 003.004.000 + USRP2. I'm trying to run a transceiver script for OFDM, which has both the tx and rx flowgraphs (very similar to tunnel.py except the TUN interface). But, I can't seem to receive anything successfully in that case. Even the preamble correlation fails, it barely sees anything substantial in the air at the RF end. On the other hand, if I just disable the uhd_transmitter in the script, the receiver then works just about great. I've run the transceiver script earlier on USRP2 with the eth driver - could it be something to do with the UHD? Is it possible that the transmitter is in some way locking the receiver? P.S: Individually, tx and rx work just fine. You did not mention which daughterboard you're using. If it's the XCVR2450 db and you continuously transmit you sort of block your receiver indeed. That's because the XCVR2450 is only half-duplex. -Andre ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I do, is to start both the flowgraphs, and just listen for packets. On Sun, Feb 26, 2012 at 6:13 AM, Andre Puschmann andre.puschm...@tu-ilmenau.de wrote: On 02/26/2012 10:38 AM, Apurv Bhartia wrote: Hi, I'm running Ubuntu 11.10 + UHD 003.004.000 + USRP2. I'm trying to run a transceiver script for OFDM, which has both the tx and rx flowgraphs (very similar to tunnel.py except the TUN interface). But, I can't seem to receive anything successfully in that case. Even the preamble correlation fails, it barely sees anything substantial in the air at the RF end. On the other hand, if I just disable the uhd_transmitter in the script, the receiver then works just about great. I've run the transceiver script earlier on USRP2 with the eth driver - could it be something to do with the UHD? Is it possible that the transmitter is in some way locking the receiver? P.S: Individually, tx and rx work just fine. You did not mention which daughterboard you're using. If it's the XCVR2450 db and you continuously transmit you sort of block your receiver indeed. That's because the XCVR2450 is only half-duplex. -Andre ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
On 02/26/2012 02:29 PM, Apurv Bhartia wrote: Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I do, is to start both the flowgraphs, and just listen for packets. In which case, the TX side is running--even if you aren't sending any *data* bits, it's still transmitting, and blocking the receiver. You'll have to get more sophisticated about half-duplex flow management, using tagging to tell UHD to turn on/off the TX side. Josh probably has better words of wisdom on this than I. On Sun, Feb 26, 2012 at 6:13 AM, Andre Puschmann andre.puschm...@tu-ilmenau.de mailto:andre.puschm...@tu-ilmenau.de wrote: On 02/26/2012 10:38 AM, Apurv Bhartia wrote: Hi, I'm running Ubuntu 11.10 + UHD 003.004.000 + USRP2. I'm trying to run a transceiver script for OFDM, which has both the tx and rx flowgraphs (very similar to tunnel.py except the TUN interface). But, I can't seem to receive anything successfully in that case. Even the preamble correlation fails, it barely sees anything substantial in the air at the RF end. On the other hand, if I just disable the uhd_transmitter in the script, the receiver then works just about great. I've run the transceiver script earlier on USRP2 with the eth driver - could it be something to do with the UHD? Is it possible that the transmitter is in some way locking the receiver? P.S: Individually, tx and rx work just fine. You did not mention which daughterboard you're using. If it's the XCVR2450 db and you continuously transmit you sort of block your receiver indeed. That's because the XCVR2450 is only half-duplex. -Andre ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech mle...@ripnet.com wrote: ** On 02/26/2012 02:29 PM, Apurv Bhartia wrote: Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I do, is to start both the flowgraphs, and just listen for packets. In which case, the TX side is running--even if you aren't sending any *data* bits, it's still transmitting, and blocking the receiver. You'll have to get more sophisticated about half-duplex flow management, using tagging to tell UHD to turn on/off the TX side. Josh probably has better words of wisdom on this than I. Hi Marcus, I'm working with Apurv, so I'm going to chime in here :) I tried doing some searching on the mailing list, but I wasn't really able to find much on this. I also thought that auto tr would handle this. I found a post from Josh on the mailing list that said Auto TR is always enabled in UHD. http://www.ruby-forum.com/topic/1527488 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
On 02/26/2012 08:54 PM, George Nychis wrote: On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: On 02/26/2012 02:29 PM, Apurv Bhartia wrote: Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I do, is to start both the flowgraphs, and just listen for packets. In which case, the TX side is running--even if you aren't sending any *data* bits, it's still transmitting, and blocking the receiver. You'll have to get more sophisticated about half-duplex flow management, using tagging to tell UHD to turn on/off the TX side. Josh probably has better words of wisdom on this than I. Hi Marcus, I'm working with Apurv, so I'm going to chime in here :) I tried doing some searching on the mailing list, but I wasn't really able to find much on this. I also thought that auto tr would handle this. I found a post from Josh on the mailing list that said Auto TR is always enabled in UHD. http://www.ruby-forum.com/topic/1527488 Yes, it is enabled in UHD. But since Gnu Radio is a *streaming* model, you need to take special measures to control TX from within a Gnu Radio flow-graph. YOu need to insert a tag in the stream to control the transmitter, otherwise, you'll be continuously streaming. What you do is insert a burst-tagger into your stream, and set it to send the appropriate tags for UHD into the stream using the trigger input. I just can't off the top of my head, remember what those stream tags are at the moment. But the basic issue is that Gnu Radio uses a streaming model, and while UHD itself (at the C++ level) has fine-grianed control over transmitter functions, etc, gr-uhd doesn't directly expose any of that, because there's just not mechanism within Gnu Radio to expose that stuff. The stream tagging, however, does allow you to control the transmitter state. In the particular case of the XCVR2450, the hardware is physically incapable of TX and RX at the same time. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
