# How to reduce reconfiguration latency

**URL:** <https://www.ruby-forum.com/t/how-to-reduce-reconfiguration-latency/240610>\
**Category:** GNU Radio\
**Created:** [April 23, 2014, 3:05am UTC](https://www.ruby-forum.com/t/how-to-reduce-reconfiguration-latency/240610 "2014-04-23T03:05:46Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\
**Post date:** [April 23, 2014, 3:05am UTC](https://www.ruby-forum.com/t/how-to-reduce-reconfiguration-latency/240610/1 "2014-04-23T03:05:46Z")

</div>

I have a GNU radio based software that uses IQ modulation on the sending  
side and IQ demodulation on the receiving side. In my application, the  
transmitted signal could be scaled up to +/-5% in time domain. I don’t  
have  
control to this scaling. So I take two actions to compensate for the  
scaling: (1) Scale the frequency of the sinusoidal signal used for IQ  
demodulation. (2) Resample the IQ demodulator output to recover the time  
scale. In order to detect the time scaling, I added to the transmitted  
signal an additional fixed frequency sinusoidal signal whose frequency  
doesn’t overlap with the IQ carrier frequency. On the receiving side, I  
estimate the time scaling by checking the deviation of the addition  
sinusoidal signal from the expected value. Once the time scale is  
estimated, I adjust the frequency of the signal source for IQ  
demodulation  
and the sampling ratio of the re-sampler accordingly. Debug log shows  
that  
the latency from time scaling detected to meaningful data coming out of  
IQ  
demodulation is 600-700 ms.

My question for the GNU radio experts is how to reduce the latency.

I suspect part of the latency is due to the fact that while I  
reconfigure  
the flow graph, data continue to flow through the graph. I need to keep  
the  
data in the graph during reconfiguration so I don’t want to call  
lock/unlock. I’m thinking of finding ways to pause/resume the scheduler.  
Does this approach make sense?

Regards,  
Bolin H.

---

<div class="post-metadata">

**Author:** ![Bolin\_H](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/a183cd/32.png) [@Bolin\_H](https://www.ruby-forum.com/u/Bolin_H)\
**Post date:** [April 23, 2014, 2:51pm UTC](https://www.ruby-forum.com/t/how-to-reduce-reconfiguration-latency/240610/2 "2014-04-23T14:51:56Z")

</div>

Hi Bolin H.,

I hope I understand you correctly, so let’s ask some questions:

> In my application, the transmitted signal could be scaled up to +/-5%  
> in time domain.  
> This is most probably not what you wanted to say. Scaling something in  
> time domain means “multiplying it with a factor of X”, usually.  
> Do you mean it’s frequency shifted? Does the transmitted burst vary in  
> length?

Your further text suggests you’re experiencing frequency offset (what  
ever these 5% relate to), so I recommend looking into the various  
frequency correction possibilities. Usually you know quite a lot about  
your signal which can be used to correct an inaccurate rx freq - in many  
cases, a maximum signal bandwidth is sufficient to use something like a  
frequency locked loop. Take a look into the “synchronizers” category in  
GNU Radio Companion.

I don’t really understand what you’re trying to say about latency, but  
from what I understand it is mostly due to your specific implementation  
of the frequency correction; these numbers are vastly meaningless  
without at least something like a sampling rate, information about the  
estimator you use to “check the deviation” etc.

Reconfiguring does not seem to be a good idea in your case, I agree. I  
don’t really understand why you do it, though.

Greetings,  
Marcus