Re: [Discuss-gnuradio] Half-Duplex Relay
Hi Martin and all,
I am looking at some AF stuff for now, where the delay is much better.
I am using something similar to HPD at the relay to implement some gain to the
payload samples only. I call
// Copy header
copy_n_symbols(in, out, 0, samples_per_header);
// Copy payload
copy_n_symbols(in, out, 0, samples_per_payload);
where the function is:
void packet_detector_impl::copy_n_symbols(const unsigned char *in, unsigned
char *out, int port, int n_symbols)
{
// Copy samples
memcpy((void *) out, (void *) in, n_symbols*sizeof(gr_complex));
// Copy tags
std::vectortag_t tags;
get_tags_in_range(tags, 0, nitems_read(0), nitems_read(0) + n_symbols);
for (unsigned t = 0; t tags.size(); t++)
{
int new_offset = tags[t].offset - nitems_read(0);
add_item_tag(port, nitems_written(port) + new_offset, tags[t].key,
tags[t].value);
}
}
My questions is probably stupid, but I want to multiply the payload symbols by
a certain gain, say 'G', but I am not clear how to do it. I am not clear how
to access the items individually to scale them.
As a first step, I tried first replacing the memcpy with
for(int i = 0; i samples_per_packet; i++) out[i] = in[i];
but that of course doesn't successfully replace the functionality?
Regards,
David
From: Martin Braun [martin.br...@ettus.com]
Sent: 30 January 2014 15:56
To: David Halls; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Half-Duplex Relay
On 30.01.2014 16:49, David Halls wrote:
Thanks Martin,
So your recommendation would be not to spend too much time poking around
with USRP latency stuff:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/latency
This is an excellent guide, and a good read. In this case, I doubt UHD
is the limiting factor.
Is there an obvious way to benchmark the latency in GNU Radio? I have
basically stuck your decoder and encoders back to back in the relay
code, so it is pretty intensive. I suppose that implementing some of it
in the FPGA may help? I have no experience in that field at all though...
It would certainly help, but you'd be looking at an absurd amount of
work. I can't think of a good pure GNU Radio way to measure latency, though.
The current implementation is enough to show proof of concept but is
very inefficient.
That's true, but given that it's clicked together, 10 ms latency is not
all that bad.
Is there an obvious way to increase the payload length without getting
buffer issues in the code - have you ever tried increasing it
significantly in your implementation?
See Aditya's question. Tagged stream blocks operate on one packet at a
time, so it's limited.
MB
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
Re: [Discuss-gnuradio] Half-Duplex Relay
On 13.02.2014 10:18, David Halls wrote: My questions is probably stupid, but I want to multiply the payload symbols by a certain gain, say 'G', but I am not clear how to do it. I am not clear how to access the items individually to scale them. As a first step, I tried first replacing the memcpy with for(int i = 0; i samples_per_packet; i++) out[i] = in[i]; but that of course doesn't successfully replace the functionality? Sure, why not? However, it probably be the solution with the best performance. You could stick with the memcpy() and use a VOLK kernel afterwards. But your solution seems correct. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Half-Duplex Relay
Hi Johannes, Thanks for your email. Have been reading through the link you sent me, just trying to relate the direct UHD stuff with the equivalent in gr-uhd code. I am planning to implement some LDPC code that I wrote for another application. Have you tried implementing something similar? Regards, David From: Johannes Demel [johannes.de...@ettus.com] Sent: 29 January 2014 18:53 To: David Halls Cc: Martin Braun; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Half-Duplex Relay Hi David, you could consider to tweak the latency [1] of your system between host and USRP. This way your relay is less dependent on that and you can reduce the gaps between packets if the host side signal processing can keep up. If you increase the packet size of your OFDM system you might also consider to use channel coding, e.g. a convolutional code. happy hacking Johannes [1] http://code.ettus.com/redmine/ettus/projects/uhd/wiki/latency On Wed, Jan 29, 2014 at 10:11 AM, David Halls david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote: Hi Martin, and all, I am making good progress with the relay. At the source, I transmit packets interspersed with 0's to create a silent period. This is achieved using vector_insert. Perhaps there are better ways, but it works well. Currently the gap is 20ms (2e4 samples at 1e6Ms/s) between tx'd packets from source. At the relay I take the rx_time UHD tag, then in HPD I work out the actual time that each trigger is received (i.e. beginning of each packet) using nitems_read(0) with rx_time and sample_rate, I then decode, re-encode, and then add sob, eob, and a tx_time created by adding 10ms to the rx_time, so that it is transmitted half-way between the packets from the source. This works but gives large gaps - each burst is (3+3+16)*80 = 1760 samples, a lot of time is wasted. The decoding/encoding delay in the relay seems to vary between around 3000 and 1 samples, so I can't reduce the timeslot length without some packets at the relay arriving at the USRP late 'L'. I am not sure how to proceed. I can increase the packet length at the transmitter to fill the gap, but not sure if this will lengthen the relay decoding delay or not. Also with the OFDM_tx code, I get buffer errors with a payload longer than 96Bx2. i.e. 32 symbol payload. Any thoughts? David From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.orgmailto:discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.orgmailto:toshiba-trel@gnu.org] on behalf of Martin Braun [martin.br...@ettus.commailto:martin.br...@ettus.com] Sent: 14 January 2014 16:56 To: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Half-Duplex Relay On Tue, Jan 14, 2014 at 11:29:51AM +, David Halls wrote: 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. Sounds good. Tell us how you're coming along, and do ask for advice if necessary. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.orgmailto: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/trlhttp://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
Re: [Discuss-gnuradio] Half-Duplex Relay
On 30.01.2014 16:49, David Halls wrote: Thanks Martin, So your recommendation would be not to spend too much time poking around with USRP latency stuff: http://code.ettus.com/redmine/ettus/projects/uhd/wiki/latency This is an excellent guide, and a good read. In this case, I doubt UHD is the limiting factor. Is there an obvious way to benchmark the latency in GNU Radio? I have basically stuck your decoder and encoders back to back in the relay code, so it is pretty intensive. I suppose that implementing some of it in the FPGA may help? I have no experience in that field at all though... It would certainly help, but you'd be looking at an absurd amount of work. I can't think of a good pure GNU Radio way to measure latency, though. The current implementation is enough to show proof of concept but is very inefficient. That's true, but given that it's clicked together, 10 ms latency is not all that bad. Is there an obvious way to increase the payload length without getting buffer issues in the code - have you ever tried increasing it significantly in your implementation? See Aditya's question. Tagged stream blocks operate on one packet at a time, so it's limited. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Half-Duplex Relay
Hi Martin, and all, I am making good progress with the relay. At the source, I transmit packets interspersed with 0's to create a silent period. This is achieved using vector_insert. Perhaps there are better ways, but it works well. Currently the gap is 20ms (2e4 samples at 1e6Ms/s) between tx'd packets from source. At the relay I take the rx_time UHD tag, then in HPD I work out the actual time that each trigger is received (i.e. beginning of each packet) using nitems_read(0) with rx_time and sample_rate, I then decode, re-encode, and then add sob, eob, and a tx_time created by adding 10ms to the rx_time, so that it is transmitted half-way between the packets from the source. This works but gives large gaps - each burst is (3+3+16)*80 = 1760 samples, a lot of time is wasted. The decoding/encoding delay in the relay seems to vary between around 3000 and 1 samples, so I can't reduce the timeslot length without some packets at the relay arriving at the USRP late 'L'. I am not sure how to proceed. I can increase the packet length at the transmitter to fill the gap, but not sure if this will lengthen the relay decoding delay or not. Also with the OFDM_tx code, I get buffer errors with a payload longer than 96Bx2. i.e. 32 symbol payload. Any thoughts? David From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org [discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org] on behalf of Martin Braun [martin.br...@ettus.com] Sent: 14 January 2014 16:56 To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Half-Duplex Relay On Tue, Jan 14, 2014 at 11:29:51AM +, David Halls wrote: 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. Sounds good. Tell us how you're coming along, and do ask for advice if necessary. 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 --- attachment: Screenshot from 2014-01-29 18:08:36.png___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Half-Duplex Relay
Hi David, you could consider to tweak the latency [1] of your system between host and USRP. This way your relay is less dependent on that and you can reduce the gaps between packets if the host side signal processing can keep up. If you increase the packet size of your OFDM system you might also consider to use channel coding, e.g. a convolutional code. happy hacking Johannes [1] http://code.ettus.com/redmine/ettus/projects/uhd/wiki/latency On Wed, Jan 29, 2014 at 10:11 AM, David Halls david.ha...@toshiba-trel.comwrote: Hi Martin, and all, I am making good progress with the relay. At the source, I transmit packets interspersed with 0's to create a silent period. This is achieved using vector_insert. Perhaps there are better ways, but it works well. Currently the gap is 20ms (2e4 samples at 1e6Ms/s) between tx'd packets from source. At the relay I take the rx_time UHD tag, then in HPD I work out the actual time that each trigger is received (i.e. beginning of each packet) using nitems_read(0) with rx_time and sample_rate, I then decode, re-encode, and then add sob, eob, and a tx_time created by adding 10ms to the rx_time, so that it is transmitted half-way between the packets from the source. This works but gives large gaps - each burst is (3+3+16)*80 = 1760 samples, a lot of time is wasted. The decoding/encoding delay in the relay seems to vary between around 3000 and 1 samples, so I can't reduce the timeslot length without some packets at the relay arriving at the USRP late 'L'. I am not sure how to proceed. I can increase the packet length at the transmitter to fill the gap, but not sure if this will lengthen the relay decoding delay or not. Also with the OFDM_tx code, I get buffer errors with a payload longer than 96Bx2. i.e. 32 symbol payload. Any thoughts? David From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org[discuss-gnuradio-bounces+david.halls= toshiba-trel@gnu.org] on behalf of Martin Braun [ martin.br...@ettus.com] Sent: 14 January 2014 16:56 To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Half-Duplex Relay On Tue, Jan 14, 2014 at 11:29:51AM +, David Halls wrote: 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. Sounds good. Tell us how you're coming along, and do ask for advice if necessary. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Half-Duplex Relay
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
Re: [Discuss-gnuradio] Half-Duplex Relay
On Tue, Jan 14, 2014 at 11:29:51AM +, David Halls wrote: 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. Sounds good. Tell us how you're coming along, and do ask for advice if necessary. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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
[Discuss-gnuradio] Half-Duplex Relay
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? Many thanks! David --- David Halls Ph.D. Research Engineer Toshiba Research Europe Limited 32 Queen Square, Bristol, BS1 4ND, UK Tel: +44 (0) 117 906 0790 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
Re: [Discuss-gnuradio] Half-Duplex Relay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, this is not an easy question by itself -- what you're describing is the implementation of slotted medium access. This implies synchronization and some considerations regarding arbitration etc. There have been several attempts at MAC with GNU Radio, with differing results. What kind of MAC you actually want depends on a multitude of factors - -- a priori knowledge of involved transceivers, knowledge of geometry, acceptable interference power, acceptable length of preamble, acceptable latencies and so on. As soon as all your transceivers know when to start and stop transmitting/listening, you can use the USRPs' timed_commands to time your frames. Please refer to the GNU Radio doxygen - UHD source/sinks - - set_command_time. Greetings, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS0DqVAAoJEAFxB7BbsDrLZasH+wSS8ARSCrnD+VSUKEfTLzEU OXIXrjWACiKjw60duFDoYMlyaRFjKWVWTfEN5P6LdLqPO4PyKm/qt5Fj77A07/1v Yqt/e9xhjvY04WDB6QvrNV+ig0rQuGHR/Z+k76SyasDvWwjg3KpXRc6MH+5UzBxi 004YwFyuW7pqvuFo4jZWEqg+TN0qnjFtKwHSJfgn39z6MnaEQxvk1YrBpwdtAQ/g fbxlD00lN8oQ5xF1CDp9VKHxJ9236NazcMSE8dfnVfI27ekPBiB89BuVcJBkOBMo 6at8kt1bY+aWkR0eUMK+f446N8/MOGUk2AWMjvIpLSe+Hs6octi0iy4p8djtPJk= =8J8F -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
