How to reduce reconfiguration latency

GNU Radio
1

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.

2

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