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.muel...@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@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
