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. 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? -- Diftor heh smusma -Famous Vulcan Phrase ;) Previous Messages: Rob Kossler rkossler at 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> 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
