discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Half-Duplex Relay


From: David Halls
Subject: Re: [Discuss-gnuradio] Half-Duplex Relay
Date: Tue, 14 Jan 2014 11:29:51 +0000

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: address@hidden [mailto:address@hidden On Behalf Of Martin Braun
Sent: 10 January 2014 21:16
To: address@hidden
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
address@hidden
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]