[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

From: Martin Braun
Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked
Date: Wed, 01 Apr 2015 14:31:06 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 01.04.2015 10:49, Anderson, Douglas J. wrote:

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]