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:gi...@apolloshield.com]
Sent: Wednesday, November 8, 2017 12:53 AM
To: David Rose <david.r...@govsco.com>
Cc: usrp-users@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@lists.ettus.com<mailto:usrp-users@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@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
