On 01.04.2015 10:49, Anderson, Douglas J. wrote:
Martin,
I think we could have the same effect with a much simpler solution:
What about adding an lo_locked metadata tag to the stream of
samples?
This would require the FPGA to automatically send some kind of
notification that the LO has locked (our packet format doesn't have such
a field), and the USRP sink to parse async messages or something like
that for every sample (at least, every sample after an rx_freq tag).
This would mean both architectural changes and added processing load.
My assertion 'depends on everything' also was a bit pessimistic. Tune
time depends on certain parameters, such as devices used (mboard/dboard)
and some DSP settings; possibly even temperature and other analogs. For
a given setup, it won't change massively during operation.
So you're right that we're pushing this to the user, but without a
really tight coupling between the app and the analog front-end (and I
consider USB or Ethernet not fall into this category), there's not a
simple solution -- unless you count measuring the delay between the
first sample with the rx_freq tag and the end of the transition, and
then statically adding another tag after X many samples, which I don't
think you were asking for.
Cheers,
M
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
