On 01/24/2021 03:08 PM, Glenn Hazelwood via USRP-users wrote:
Thanks for your replies. I only saw e-mail for the first reply,
strangely. I saw the other replies from the daily digest.
I initially tried one thread with two channels with a
set_rx_frequency() call for each and the tune time was roughly twice
as much as one channel, one tune ( ~240 ms ).
I then tried the two channel two thread case with channel 0 and 1 and
got a weird error about epsilon for difference between the new
frequency compared to the 'previous' frequency? (Very rough
paraphrase, sorry)
At first I was completely lost. But then I noticed that the error
message had a path to the source file with the set_rx_frequency()
function for the N310. The set_rx_frequency() function uses a mutex
lock. That definitely blocks the other thread calling set_rx_frequency().
That means that even with two threads/two channels or even four
threads/four channels.... it can only tune one channel at a time.
The fix for my error, was to use channel 0 and channel 2, not channel
0 and channel 1. Channels 0 and 1 share an LO and Channels 2 and 3
share an LO? The tune time was still double (~240 ms ) since only one
channel could be tuned at a time.
That may be a hardware architecture thing--the AD9371 uses either an SPI
or I2C interface for command and control (can't remember which),
and there may only be one of those busses on the N310--I don't know
for sure. So you have to mutex access to that bus.
The AD936x and AD937x have an architecture where the two channels share
an LO. On the N310, there are *TWO* AD9371, giving
a total of 4 channels, but with shared LO for 0,1 and 2,3. But
likely they share an I2C/SPI bus for command/control. The main
latency, however, is the time it takes for the chips to re-tune. The
buses themselves are reasonably speedy, as far as I know--probably
operating at 1Mbit.
I know that I cannot avoid the AD9731s taking ~120 ms to retune. I was
hoping that I could at least do more tunings per 120 ms with multiple
channels.
Maybe an X310 with the TwinRX daughterboards and something like in the
examples:
https://github.com/EttusResearch/uhd/blob/master/host/examples/twinrx_freq_hopping.cpp
will work better?
Certainly more flexible, since there are various LO-sharing topologies
available to you, depending on what you want to do.
The underlying PLL synthesizers are likely much faster, but decidedly
not "instant". There's an inherent tension in PLL synthesizer
design between residual phase-noise and tuning time. Radios that do
fast frequency hopping use specialized synthesizers that
sacrifice some things to get very-fast hopping times. But such
synthesizers aren't really appropriate for a general-purpose
radio.
--
Diftor heh smusma
-Famous Vulcan Phrase ;)
Previous Messages:
Rob Kossler rkossler at nd.edu <http://nd.edu>
Thu Jan 21 17:53:14 EST 2021
After reading Marcus' reply, it occurred to me that you really might not
need multiple threads to achieve the factor of 2 improvement you are
looking for. I think if you call set_rx_freq() it is a non-blocking call
so you should be able to set the 2 freqs, wait for them both to settle,
then get the results simultaneously. I think you can do it from 1 thread.
Rob
On Thu, Jan 21, 2021 at 4:01 PM Marcus D. Leech via USRP-users <
usrp-users at lists.ettus.com <http://lists.ettus.com>> wrote:
> On 01/21/2021 02:56 PM, Glenn Hazelwood via USRP-users wrote:
>
> I have an N310 and I wish to scan from 10 MHz to 5910 MHz with two
> channels. The frontend bandwidth is 100 MHz. So I do 60 tunings
overall. I
> am directly using the UHD 3.15.0.0 C++ API
>
> The retune time is typically ~120 ms. My sample rate is 125 Msps.
> Therefore, the time to receive samples is relatively small. For example,
> receiving time for 32768 samples is ~1.3 ms. WIth one thread and one
> channel, my overall tune and receive time for the 60 tunings is
~7200 ms.
>
> I wanted to try to reduce the overall runtime by using two threads
and two
> channels. One thread would do half the tunings and the other thread
would
> do the other half at the same time.
>
> I see that I can make separate rx_streamers in separate threads,
each with
> its own channel to receive samples. I think rx_streamers[chan].recv()
> should work for two threads. I'm not so confident about
> 'usrp->set_rx_frequency()' for two threads.
>
> Is it possible to have two separate threads each tune to different
> frequencies at the same time with the N310?
>
> Also: Is there a way to search the Archives to see if someone has
already
> asked this question. Google doesn't always seem to help.
>
> -
> Diftor heh smusma
> -Famous Vulcan Phrase ;)
>
> Tuning time is an artifact of the hardware (AD9371 in this case)--which
> isn't really fast on re-tuning. It has nothing to do with thread
> architecture/layout.
>
> Further, channels 0 and 1 will always be tuned to the same RF frequency,
> due to the LO architecture of the AD9371, similarly 2 and 3 will
> always use the same LO frequency.
>
>
> You can certainly spread sample-handling across multiple threads,
and use
> the two available RF tunings (across the two RF chips) to speed
> things up a bit (cut the effective latency in half by interleaving).
> But you're not going to get more than a factor of two.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
