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 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
On 04/23/2014 03:04 AM, Bolin Hsu wrote:
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 Hsu
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
