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: Thu, 13 Feb 2014 18:18:56 +0000

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::vector<tag_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 address@hidden
Sent: 30 January 2014 15:56
To: David Halls; address@hidden
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

reply via email to

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