Thanks Martin,

Yes, I am using USRP N210. I aim to have separate code on S, R and D as you 
suggest. I have built a 2 x 1 MISO system developing from your OFDM GRC code - 
thanks :)

I have added a number of new elements including 802.16e randomiser, random 
vector source, SNR estimate, BER estimate and orthogonal headers... anyway I 
digress.

I am already using some tagging. I hope I can use the rx_time timestamp and 
number of samples received to work out the time I want to begin and end 
transmission at the relay. This, as Marcus comments, will be much more 
complicated as the network topology grows. Currently I will assume just two 
time slots and allow a generous amount of time for propagataion and 
decoding/reencoding delay.

I will then try to use 'set_command_time' to control when the relay txs.

Do you feel this makes sense? I will let you know how I progress.

Regards,

David


-----Original Message-----
From: discuss-gnuradio-bounces+david.halls=toshiba-trel....@gnu.org 
[mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel....@gnu.org] On 
Behalf Of Martin Braun
Sent: 10 January 2014 21:16
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Half-Duplex Relay

On 01/10/2014 03:06 PM, David Halls wrote:
> Hi all,
>
> Hopefully a very easy question! How do I implement a relay such that
> it will not begin transmitting until it has received a whole 'burst'
> of data. As there will be a direct path from source to destination, I
> don't want the relay to start transmitting until the source has
> finished transmitting. Thus I want to implement a TDMA restriction
> where source transmits in time slot 1, then transmits nothing during
> time slot 2 (easy), then I want the relay to listen only in time slot
> 1 and then not begin transmitting until time slot 2.
>
> I was wondering if I should use some kind of tagging?

Most likely, yes. Although I know one student at CEL wrote a relay before tags 
were around (I doubt the code is still available...).

Not transmitting is not as trivial as it sounds :) I'm assuming you're using 
UHD devices (USRPs). In this case, have a look at the tx_sob and tx_eob tags 
and what they do in the UHD sink (they shut down the transmitter and fire it up 
again, so your USRP doesn't expect samples when you're in an idle slot).

There's a couple of things to consider. If you're doing some relay-specific 
experiment, you probably have dedicated code for source, relay and destination.

The source will only send out a burst (use the mentioned tags to mark
that) and wait. Alternatively, you can also send out zeros between tags.

The destination node is even simpler -- you rx all the time and pass packets to 
an upper layer for combining. Nothing special here.
Same with the relay, although you'll need the tags again for retransmission. 
Also, you should keep timing in mind, which can sometimes be a bit random in 
GNU Radio. If you're expecting decoding within a certain time after decoding 
(or just reception if you do AaF).

Have a look at the manual page for tagged streams and PDUs as well as the 
examples for packet-based transceivers (e.g. the OFDM code).
If you need anything more specific, just ask here!

MB



_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


________________________________

NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to