[USRP-users] Unexpected (increasing) latency for set_rx_gain

Brais Ares bares at gradiant.org
Thu Feb 7 13:27:43 EST 2019


Hi Marcus,

My mistake, there was a bug in my code. Sorry for any inconvenience.

However I was expecting the latency to be more gaussian-like distributed,
but in my new tests I can see an obvious trend so far (see upper figure
<https://drive.google.com/open?id=1YaSrTT96aDd1kmzRjdyfvlzmQbwNvas_>).
I tried also by executing rx_samples_to_file example with minor
modifications, and also tried to increase the sampling rate, but I saw the
same trend in latency. This is not a problem for our application though.

The gain step detection algorithm is as simple as this (example output
<https://drive.google.com/open?id=1FlElDUMhPwGozVLP6RWLIbClLhRkS9dM>):

for each received radio block:

max(  ( abs(s[n]) - abs(s[n-D]) )^2  );  (with D=2 in this case)



With respect to CIC, I'm using 32 kS/s as our signal is only 1 KHz in
bandwidth. Would you recommend to increase fs anyway? What could we expect
to be the main issues (unwanted effects) if we don't?

Regards,
Brais.

El lun., 4 feb. 2019 a las 20:24, Marcus Müller (<marcus.mueller at ettus.com>)
escribió:

> Hi Brais,
>
> On Mon, 2019-02-04 at 18:34 +0100, Brais Ares via USRP-users wrote:
> > Hello,
> >
> > I'm trying to implement an AGC software in our RF application. The
> > setup is the following:
> > B200mini
> > master clock rate: 16 MSPS
> > fs = 32 KSPS
>
> Are you sure? That's a decimation of 500, 125 of which you're doing
> with a CIC. 32 kS/s is really an extremely low sampling rate for SDR
> applications, and there's little reason not to do the resampling with
> "nicer" software filters on your host PC; even the slowest Linux
> computer should have plenty CPU power to do that.
>
> A higher sampling rate would also allow a much more fine-grained
> examination of these delays. I'd ask you to examine this option.
>
> Generally, in the interest of reproducability: how are you doing that
> gain step detection, en detail?
>
> Best regards,
> Marcus
>
> > Receive samples in blocks of 32k (1 second).
> > I made a tiny program, where I change rx_gain every 1 seconds (just
> > after rx_streamer->recv() returns) adding or substracting 30 dB.
> > To find out when a change in rx_gain actually affects the received
> > samples I implemented a simple detection algorithm.
> >
> > Ignoring the non-deterministic latency, at least I would expect the
> > time between changes to be 1 seconds as well (µ = 1 seconds, with
> > some non-zero variance), the same periodicity they were invoked
> > with.
> >
> > However, this change takes on average 1.016 seconds (see figure).
> > This means for each set_rx_gain call the radio is taking longer and
> > longer to apply the change (see figure). Example:
> >
> > t = 1 s -> Recv previous block and change gain
> > t = 2 s -> Recv previous  block and change gain
> > t = 1.016 -> Change in gain detected in previous block (OK, latency
> > to change gain is around ~0.016 ms)16 µs would indeed be a pretty *gp
> > t = 3 s -> Recv previous nd change gain
> > t = 2.032 s -> Change in gain detected in previous block  (I would
> > expect ~2.016)
> > t = 4 s -> Recv previous block and change gain
> > t = 3.048 s -> Change in gain detected in previous block (I would
> > expect ~3.016)
> > (...)
> > t = 60 s -> Recv previous block and change gain
> > t = 59.96 s -> Change in gain detected in previous block (After 60th
> > call to rx_gain, latency has increased to almost 1 second!)
> >
> > Is there any rational reason why this is happening?
> > (I've tried longer periods, up to 10 seconds, with the same result).
> >
> > Regards,
> > Brais.
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190207/abab9c7f/attachment.html>


More information about the USRP-users mailing list