[USRP-users] missing rx_freq tags when frequency changes

David Rose David.Rose at govsco.com
Wed Nov 8 18:55:24 EST 2017


Hi Gilad, thanks for the response.

I’ve figured out part of the problem, but there are still some mysteries.

In my top_block, I was changing the frequency as follows:

----------------------------CODE--------------------------
def main(top_block_cls=my_top_block, options=None):
    tb = top_block_cls()
    delay = 0.01

    tb.start()
    time.sleep(delay)

    for n in range(3):
        tb.lock()
        tb.set_rf_freq(tb.get_rf_freq() + 100000)
        tb.unlock()
        time.sleep(delay)

    tb.stop()
    tb.wait()
----------------------------END CODE--------------------------

It turns out that there is apparently no need to lock() and unlock() when changing the frequency.  When I comment out the lock() and unlock() statements, the ‘rx_freq’ tags suddenly started appearing in subsequent blocks.  But I’m not sure why.
One thing I noticed was that every time lock() / unlock() was called, the item count reset to zero.  But I don’t know why that would prevent the tags from propagating.  The simplest explanation is that calling lock() / unlock() somehow disables the adding of ‘rx_freq’ tags.  Is that possible?  In any case, if I leave the lock() / unlock() out, that part of the program seems to work.

But there is a remaining problem relating to the tags.  My blocks are connected like this (blocks 2 and 5 are custom blocks coded by me):

uhd_usrp_source_0  -> valk_stream_to_vec_and_tag -> fft_vxx_0 -> blocks_complex_to_mag_0 -> valk_read_tags -> blocks_vector_to_stream_0 -> blocks_file_sink_0

At the moment, the second block (valk_stream_to_vec_and_tag) converts the input stream into 1024-elment complex vectors, reads the ‘rx_freq’ tags, and adds a new tag called ‘freq_tag’ to every output item.  That all works now that I’ve removed the lock() /unlock() statements.
Also, the data written to the file is exactly as expected:  I can see the energy from individual FM radio stations at the expected frequencies, and they move as I tune the receiver.
The problem is, while I can read the ‘rx_freq’ tags in valk_stream_to_vec_and_tag, only the very first ‘rx_freq’ tag makes it to valk_read_tags.  Valk_read tags is a synchronous block that reads and writes 1024-element real vectors, and also looks for all tags.

What I suspect is happening is that if the frequency change happens in the middle of a 1024-element vector, that tag doesn’t get propagated through valk_stream_to_vec_and_tag (which is a decimation block).  But I thought the default behavior for decimation blocks was to make an educated guess as to where to stick the tag.  It may be a bad guess, but the tag shouldn’t disappear altogether.

Of course, the alternative explanation is simply that I have a bug in my code somewhere—always a possibility.

Anyway, if you can give me any insight into tag propagation through a decimation block, I’d appreciate it.

--Dave Rose
Valkyrie Systems

PS:


  *   Oracle VM VirtualBox Manager (version 5.1.28)
  *   Ubuntu 16.04.3 LTS - Desktop version
  *   Python 2.7.12
  *   GNURadio version 3.7.9
  *   GNU Radio Companion 3.7.12
  *   UHD version: 3.11.0.git-191-g1cd96dde


From: Gilad Beeri (ApolloShield) [mailto:gilad at apolloshield.com]
Sent: Wednesday, November 8, 2017 12:53 AM
To: David Rose <David.Rose at govsco.com>
Cc: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] missing rx_freq tags when frequency changes

Hi David,

UHD should write that rx_freq tag whenever you change the frequency. Maybe others will know to explain why it doesn't. Which GR version are you using? Open usrp_source_impl.cc and verify that your version has `_tag_now = true` in `set_center_freq()` and that `work()` responds to that flag by adding the `rx_freq` tag (and others).
Using a downstream block will be less accurate then tagging it in UHD (which, if I understand correctly, isn't accurate by itself but the best one can get using host code). Think about it this way: you call set_center_freq which (assuming) tags the next sample to come from the USRP Source and also tells your block to add that tag. But there are some samples in the pipeline between USRP Source and your tagging block, which will be assumed to be from the new freq, but actually aren't. In addition, it's probable that UHD tags too early (before the RF frontend actually finished changing frequencies) - but I'm not sure about that as it depends whether the low-level call is synchronous or not (haven't checked).


Regarding settling time, I asked a similar question a few weeks ago, regarding the B205mini, which uses the same AD chip as your B200mini:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-October/026851.html



On Wed, Nov 8, 2017 at 4:22 AM David Rose via USRP-users <usrp-users at lists.ettus.com<mailto:usrp-users at lists.ettus.com>> wrote:
I’m programming a USRP B200mini-i in Python.

When the receiver starts up, it automatically inserts a ‘rx_freq’  tag into the stream.

In my application I periodically change the receiver frequency using a command such as: self.uhd_usrp_source_0.set_center_freq(self.rf_freq, 0).  This does indeed change the frequency, but it doesn’t look like the source block is adding new ‘rf_freq’ tags to mark the changes.  Does anyone know how to make that happen?

I tried directly setting a class variable in a downstream block from top_block every time I change the frequency.  That sort of works, but I don’t think it’s marking the exact right place in the stream, so I assume that’s not a recommended approach.

Finally, does the B200mini-i require any settling time after a frequency change, and if so, how much time?  Is there a chance of getting bad samples during a frequency transition, or does the stream shut down until things stabilize?

Thanks,

Dave Rose
Valkyrie Systems Corp.


_______________________________________________
USRP-users mailing list
USRP-users at lists.ettus.com<mailto:USRP-users at lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171108/0e34db75/attachment-0002.html>


More information about the USRP-users mailing list