Forum: GNU Radio How to reduce reconfiguration latency

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
536a718bcab85951ca7aa13289f7c8dd?d=identicon&s=25 Bolin Hsu (Guest)
on 2014-04-23 03:05
(Received via mailing list)
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
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
and the sampling ratio of the re-sampler accordingly. Debug log shows
the latency from time scaling detected to meaningful data coming out of
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
the flow graph, data continue to flow through the graph. I need to keep
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?

Bolin Hsu
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 Marcus Müller (Guest)
on 2014-04-23 14:51
(Received via mailing list)
Hi Bolin Hsu,

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

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.

This topic is locked and can not be replied to.