Re:Simultaneously transmitting on two transmitters

GNU Radio
1

Hey shinhan,

Could you post your changed .py code so that the issues may be clear?

I guess, your transmitted signals are still transmitted separately in
s1 and s2 sequence, not “simultaneously”.

2

Hey jiqun,

Thanks for the reply. Alright heres how i structure my
codes. I define two payloads at the transmitter-
payload0 and payload1. Lets say payload0 is 10101010
and payload1 is 01010101. In transmit_path.py i
specify 2 different function, send_pkt0 and send_pkt1
as :

def send_pkt0(self, payload0=‘’, eof=False):

print “Antennna 0”
self.subdev0 = (self.u.db[0][0])
self.subdev0.set_enable(bool(1)

self.subdev0.set_gain(self.subdev0.gain_range()[1])

self.packet_transmitter.send_pkt(payload0, eof)
return True

def send_pkt1(self, payload1=‘’, eof=False):

print “Antennna 1”
self.subdev1 = (self.u.db[1][0])
self.subdev1.set_enable(bool(1)

self.subdev1.set_gain(self.subdev0.gain_range()[1])

self.packet_transmitter.send_pkt(payload1, eof)
return True

So i forced payload0 to be sent by antenna0 and
payload1 to be sent by antenna1. Then in
benchmark_tx.py i used the following codes to send the
data:

send_pkt0(payload)
send_pkt1(payload1)

Now i think the transmitter is still sending the
payloads in sequence and not simultaneously. The
question is how to code the transmitter such that
simultaneous transmission is possible? I currently
have no idea on how and any suggestions or ideas will
be greatly appreciated. Thanks in advance.

Regards,
ShinHan

— jiqun qi [email protected] wrote:

Hey shinhan,

Could you post your changed .py code so that the
issues may be clear?

I guess, your transmitted signals are still
transmitted separately in
s1 and s2 sequence, not “simultaneously”.

  ____________________________________________________________________________________

Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

3

Hi Jiqun,

Thanks for your reply, i greatly appreciate the help,
I would try your suggestion, another idea is what if i
used 2 USRP? is the idea feasible? Thanks again for
the help.

— jiqun qi [email protected] wrote:

simultaneously" from the view point
because there is the time cycle consumption that you
send symbol s2 to the
transmit buffer.

I am not sure how actually it would be in practice.
And I will try my best
to do it in the following days.

  ____________________________________________________________________________________

Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

4

On Wed, Mar 5, 2008 at 8:43 PM, Wee S. [email protected]
wrote:

   return True
   return True

So i forced payload0 to be sent by antenna0 and
payload1 to be sent by antenna1. Then in
benchmark_tx.py i used the following codes to send the
data:

           send_pkt0(payload)
           send_pkt1(payload1)

In principle, in USRP, if these two transmit daughter boards share “one
common clock”, it could not achieve the “strict-sense simultaneously
transmitting” because your program is executed in “sequence”, not
“parallel”. However, you can “first” transmit the symbol s1 on antenna
1,
“then” transmit s2 on antenna 2 “almost simultaneously” from the view
point
of well programming.

For example, you can send symbols s1 and s2 to the transmit buffer
first,
then enable the two antennas for transmitting, so the transmit time
cycle
difference \delta_t will be smaller than the way that you send symbol s1
to
the antenna 1, and enable it for transmitting, then do the symbol s2,
because there is the time cycle consumption that you send symbol s2 to
the
transmit buffer.

I am not sure how actually it would be in practice. And I will try my
best
to do it in the following days.

5

Hi Wee S.,

Short answer: The idea is feasible.

Long answer:
Using two USRP’s is a little more complicated because of the same issue
of
synchronization.

The first step is synchronization of the on-board clocks. The current
solution requires some hands-on work using directions here
->(http://www.gnuradio.org/trac/wiki/MultiUsrp). NOTE: This reversible
process disables one of the USRP board clocks and so the “slave” USRP
can no
longer be used as a stand-alone board.

The next issue is synchronization of the actual waveforms in TX and RX.
This
can be accomplished in two ways (that I know of):

  1. Using the m-block/inband timestamps: Using M-blocks, you can define
    timestamps that allow you to control when data is transmitted and
    appropriately synchronize RX. The m-block/inband code is still in
    development but is sufficiently stable to start some experiments. The
    m-block code is all in c++ and does not use gr-flowgraphs so you might
    have
    to build your application around it, or find some way to integrate
    m-blocks
    into your flowgraphs (hint: SWIG). The m-block code can also be used for
    many other functions (search the list for more details). Most of the
    code is
    available in the trunk.

  2. Custom FPGA code: the current gr-flowgraphs can already handle
    multiple
    receivers(see http://www.gnuradio.org/trac/wiki/MultiUsrp for multi-USRP
    description). There is no implemented TX parallel, but it is possible to
    build a multi-TX FPGA and gr code using the same ideas.

So the multi board radios are possible, but it is not necessarily
straightforward to implement right now.

-Sanmi

6

Sanmi wrote:

  1. Using the m-block/inband timestamps: Using M-blocks, you can define
    timestamps that allow you to control when data is transmitted and
    appropriately synchronize RX. The m-block/inband code is still in
    development but is sufficiently stable to start some experiments. The
    m-block code is all in c++ and does not use gr-flowgraphs so you might have
    to build your application around it, or find some way to integrate m-blocks
    into your flowgraphs (hint: SWIG). The m-block code can also be used for
    many other functions (search the list for more details). Most of the code is
    available in the trunk.

The m-blocks will allow you to toy with everything you want at the host
level, but the in-band code is what you need to get this information to
the USRP. The m-blocks are stable and in the trunk, the in-band code is
still in development and we are NOT supporting it (please read on).

The host level in-band code is stable, I’ve been using it for several
months now without a problem. The FPGA in-band code is just wrapping
up, I have two outstanding issues to fix: timestamp insertion and making
the TX code a little more modular. It will have support for dual RX and
TX channels for which you can use a timestamp to synchronize.

The biggest missing piece in this architecture is the standard GR block
to m-block connection, this is severely limiting and would force you to
use an abundance of nasty SWIG hacks to use the standard GR library with
your code. When I say nasty, I mean it. I believe Eric is scheduled to
work on this while he works on the multi-threaded scheduler within the
next week or two (I hope!).

Until then, I’d strongly advise waiting the extra time so I can wrap up
the FPGA in-band code and Eric can wrap up the block connections. It
will save you tons of headaches, and we are not supporting the in-band
code until then. AKA, you can’t come to us with your problems and we
won’t help you use it :wink:

So in summary, GNU Radio will support exactly what you need to do
through m-blocks and the in-band code, its just not quite there yet.

  • George