Currently my application runs continuous tx and rx on two different frequencies, with B210 in full-duplex MIMO configuration. Let's call fA the tx freq and fB the rx freq. Now I need to read short rx burts at frequency fC (which is far from both fA and fB). Namely, I need to retune the rx stream to fC, receive samples there for a little, then retune back to fB and stay there for a long time. This goes on periodically, while the tx stream stays on fA for the whole time. The following questions are critical for the design of the architecture. 1. Can I assume that the rx retuning operations do not affect the tx stream on fA? I have a continuous stream there. 2. What is a ballpark value for the retuning time? I'm looking for the time after which retuning is done AND everything is settled, so that the samples streamed from the new frequency are clean. Thanks, Dario

On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: > Currently my application runs continuous tx and rx on two different > frequencies, with B210 in full-duplex MIMO configuration. Let's call > fA the tx freq and fB the rx freq. > > Now I need to read short rx burts at frequency fC (which is far from > both fA and fB). Namely, I need to retune the rx stream to fC, receive > samples there for a little, then retune back to fB and stay there for > a long time. This goes on periodically, while the tx stream stays on > fA for the whole time. > > The following questions are critical for the design of the architecture. > > 1. Can I assume that the rx retuning operations do not affect the tx > stream on fA? I have a continuous stream there. > 2. What is a ballpark value for the retuning time? I'm looking for > the time after which retuning is done AND everything is settled, > so that the samples streamed from the new frequency are clean. > > Thanks, > Dario > The TX and RX synthesizers on the AD9361 and the DSP chains in each direction are independent. Changing parameters of the RX stream will not affect the TX stream. For (2), the AD9361 is not the fastest-locking synthesizer in the world. There's not only the lock-time, but also a *lot* of internal recalibration knobs that have to be adjusted every time it's tuned. Ballpark would be several 10s of milliseconds.

On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users <usrp-users@lists.ettus.com> wrote: > On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >> Currently my application runs continuous tx and rx on two different frequencies, with B210 in full-duplex MIMO configuration. Let's call fA the tx freq and fB the rx freq. >> >> Now I need to read short rx burts at frequency fC (which is far from both fA and fB). Namely, I need to retune the rx stream to fC, receive samples there for a little, then retune back to fB and stay there for a long time. This goes on periodically, while the tx stream stays on fA for the whole time. >> >> The following questions are critical for the design of the architecture. >> Can I assume that the rx retuning operations do not affect the tx stream on fA? I have a continuous stream there. >> What is a ballpark value for the retuning time? I'm looking for the time after which retuning is done AND everything is settled, so that the samples streamed from the new frequency are clean. >> Thanks, >> Dario >> > The TX and RX synthesizers on the AD9361 and the DSP chains in each direction are independent. Changing parameters of the RX stream will not affect > the TX stream. > > For (2), the AD9361 is not the fastest-locking synthesizer in the world. There's not only the lock-time, but also a *lot* of internal recalibration knobs that have to be adjusted every time it's tuned. Ballpark would be several 10s of milliseconds. > > Just to add a little more to Marcus's reply. The distance you retune (in Hertz) affects the settling time. Certain re-calibrations are triggered when this exceeds a threshold. How far is "far"?

1. Can I assume that the rx retuning operations do not affect the tx
stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm looking for the
time after which retuning is done AND everything is settled, so that the
samples streamed from the new frequency are clean.

Thank you both for your answers. Anything above a few ms forces me to cross off one of the two design routes I had in mind, so " several 10s of milliseconds" leaves me with a clean path. About the frequency separation of the retuning, it could be up to one GHz. Thanks, Dario On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < usrp-users@lists.ettus.com> wrote: > > On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > > On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: > > Currently my application runs continuous tx and rx on two different > frequencies, with B210 in full-duplex MIMO configuration. Let's call fA the > tx freq and fB the rx freq. > > Now I need to read short rx burts at frequency fC (which is far from both > fA and fB). Namely, I need to retune the rx stream to fC, receive samples > there for a little, then retune back to fB and stay there for a long time. > This goes on periodically, while the tx stream stays on fA for the whole > time. > > The following questions are critical for the design of the architecture. > > 1. Can I assume that the rx retuning operations do not affect the tx > stream on fA? I have a continuous stream there. > 2. What is a ballpark value for the retuning time? I'm looking for the > time after which retuning is done AND everything is settled, so that the > samples streamed from the new frequency are clean. > > Thanks, > Dario > > The TX and RX synthesizers on the AD9361 and the DSP chains in each > direction are independent. Changing parameters of the RX stream will not > affect > the TX stream. > > For (2), the AD9361 is not the fastest-locking synthesizer in the world. > There's not only the lock-time, but also a *lot* of internal recalibration > knobs that have to be adjusted every time it's tuned. Ballpark would be > several 10s of milliseconds. > > > Just to add a little more to Marcus's reply. The distance you retune (in > Hertz) affects the settling time. Certain re-calibrations are triggered > when this exceeds a threshold. How far is "far"? > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >

 On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users
 <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
 wrote:

 On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote:

 Currently my application runs continuous tx and rx on two
 different frequencies, with B210 in full-duplex MIMO
 configuration. Let's call fA the tx freq and fB the rx freq.

 Now I need to read short rx burts at frequency fC (which is far
 from both fA and fB). Namely, I need to retune the rx stream to
 fC, receive samples there for a little, then retune back to fB
 and stay there for a long time. This goes on periodically, while
 the tx stream stays on fA for the whole time.

 The following questions are critical for the design of the
 architecture.

  1. Can I assume that the rx retuning operations do not affect
     the tx stream on fA? I have a continuous stream there.
  2. What is a ballpark value for the retuning time? I'm looking
     for the time after which retuning is done AND everything is
     settled, so that the samples streamed from the new frequency
     are clean.

 Thanks,
 Dario

 The TX and RX synthesizers on the AD9361 and the DSP chains in
 each direction are independent. Changing parameters of the RX
 stream will not affect
   the TX stream.

 For (2), the AD9361 is not the fastest-locking synthesizer in the
 world.  There's not only the lock-time, but also a *lot* of
 internal recalibration knobs that have to be adjusted every time
 it's tuned.  Ballpark would be several 10s of milliseconds.

 Just to add a little more to Marcus's reply. The distance you
 retune (in Hertz) affects the settling time. Certain
 re-calibrations are triggered when this exceeds a threshold. How
 far is "far"?


 _______________________________________________
 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

On 08/06/2015 09:32 PM, Dario Fertonani wrote: > Thank you both for your answers. Anything above a few ms forces me to > cross off one of the two design routes I had in mind, so " several 10s > of milliseconds" leaves me with a clean path. > About the frequency separation of the retuning, it could be up to one GHz. > > Thanks, > Dario I think the current code does "recal avoidance" if the re-tune is less than 100MHz. > > > On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > > On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> > wrote: > >> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>> Currently my application runs continuous tx and rx on two >>> different frequencies, with B210 in full-duplex MIMO >>> configuration. Let's call fA the tx freq and fB the rx freq. >>> >>> Now I need to read short rx burts at frequency fC (which is far >>> from both fA and fB). Namely, I need to retune the rx stream to >>> fC, receive samples there for a little, then retune back to fB >>> and stay there for a long time. This goes on periodically, while >>> the tx stream stays on fA for the whole time. >>> >>> The following questions are critical for the design of the >>> architecture. >>> >>> 1. Can I assume that the rx retuning operations do not affect >>> the tx stream on fA? I have a continuous stream there. >>> 2. What is a ballpark value for the retuning time? I'm looking >>> for the time after which retuning is done AND everything is >>> settled, so that the samples streamed from the new frequency >>> are clean. >>> >>> Thanks, >>> Dario >>> >> The TX and RX synthesizers on the AD9361 and the DSP chains in >> each direction are independent. Changing parameters of the RX >> stream will not affect >> the TX stream. >> >> For (2), the AD9361 is not the fastest-locking synthesizer in the >> world. There's not only the lock-time, but also a *lot* of >> internal recalibration knobs that have to be adjusted every time >> it's tuned. Ballpark would be several 10s of milliseconds. >> >> > Just to add a little more to Marcus's reply. The distance you > retune (in Hertz) affects the settling time. Certain > re-calibrations are triggered when this exceeds a threshold. How > far is "far"? > > > _______________________________________________ > 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 > >

1. Can I assume that the rx retuning operations do not affect the tx
stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm looking for
the time after which retuning is done AND everything is settled, so that
the samples streamed from the new frequency are clean.

The attached example gives me retuning times of 400 ms or more, which is order of magnitudes beyond what is expected. Am I calling the API in some suboptimal way? I cleaned up the code so that it does nothing but retuning between two frequencies. Interestingly, the retuning time doesn't vary much with the frequency separation. Thanks, Dario On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech <mleech@ripnet.com> wrote: > On 08/06/2015 09:32 PM, Dario Fertonani wrote: > > Thank you both for your answers. Anything above a few ms forces me to > cross off one of the two design routes I had in mind, so " several 10s of > milliseconds" leaves me with a clean path. > About the frequency separation of the retuning, it could be up to one GHz. > > Thanks, > Dario > > I think the current code does "recal avoidance" if the re-tune is less > than 100MHz. > > > > On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> >> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >> >> Currently my application runs continuous tx and rx on two different >> frequencies, with B210 in full-duplex MIMO configuration. Let's call fA the >> tx freq and fB the rx freq. >> >> Now I need to read short rx burts at frequency fC (which is far from both >> fA and fB). Namely, I need to retune the rx stream to fC, receive samples >> there for a little, then retune back to fB and stay there for a long time. >> This goes on periodically, while the tx stream stays on fA for the whole >> time. >> >> The following questions are critical for the design of the architecture. >> >> 1. Can I assume that the rx retuning operations do not affect the tx >> stream on fA? I have a continuous stream there. >> 2. What is a ballpark value for the retuning time? I'm looking for >> the time after which retuning is done AND everything is settled, so that >> the samples streamed from the new frequency are clean. >> >> Thanks, >> Dario >> >> The TX and RX synthesizers on the AD9361 and the DSP chains in each >> direction are independent. Changing parameters of the RX stream will not >> affect >> the TX stream. >> >> For (2), the AD9361 is not the fastest-locking synthesizer in the world. >> There's not only the lock-time, but also a *lot* of internal recalibration >> knobs that have to be adjusted every time it's tuned. Ballpark would be >> several 10s of milliseconds. >> >> >> Just to add a little more to Marcus's reply. The distance you retune (in >> Hertz) affects the settling time. Certain re-calibrations are triggered >> when this exceeds a threshold. How far is "far"? >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > >

1. Can I assume that the rx retuning operations do not affect the tx
stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm looking for
the time after which retuning is done AND everything is settled, so that
the samples streamed from the new frequency are clean.

Hi Dario, I took your code and replaced the std::chrono and std::thread stuff with boost equivalents and was able to achieve retuning times of ~150-200 microseconds after the initial tune (which took ~220 ms). No appreciable difference over USB 2.0 or 3.0. The modified code is attached. Regards, Michael On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users < usrp-users@lists.ettus.com> wrote: > The attached example gives me retuning times of 400 ms or more, which is > order of magnitudes beyond what is expected. Am I calling the API in some > suboptimal way? > I cleaned up the code so that it does nothing but retuning between two > frequencies. Interestingly, the retuning time doesn't vary much with the > frequency separation. > > Thanks, > Dario > > > On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech <mleech@ripnet.com> wrote: > >> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >> >> Thank you both for your answers. Anything above a few ms forces me to >> cross off one of the two design routes I had in mind, so " several 10s of >> milliseconds" leaves me with a clean path. >> About the frequency separation of the retuning, it could be up to one GHz. >> >> Thanks, >> Dario >> >> I think the current code does "recal avoidance" if the re-tune is less >> than 100MHz. >> >> >> >> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> >>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>> >>> Currently my application runs continuous tx and rx on two different >>> frequencies, with B210 in full-duplex MIMO configuration. Let's call fA the >>> tx freq and fB the rx freq. >>> >>> Now I need to read short rx burts at frequency fC (which is far from >>> both fA and fB). Namely, I need to retune the rx stream to fC, receive >>> samples there for a little, then retune back to fB and stay there for a >>> long time. This goes on periodically, while the tx stream stays on fA for >>> the whole time. >>> >>> The following questions are critical for the design of the architecture. >>> >>> 1. Can I assume that the rx retuning operations do not affect the tx >>> stream on fA? I have a continuous stream there. >>> 2. What is a ballpark value for the retuning time? I'm looking for >>> the time after which retuning is done AND everything is settled, so that >>> the samples streamed from the new frequency are clean. >>> >>> Thanks, >>> Dario >>> >>> The TX and RX synthesizers on the AD9361 and the DSP chains in each >>> direction are independent. Changing parameters of the RX stream will not >>> affect >>> the TX stream. >>> >>> For (2), the AD9361 is not the fastest-locking synthesizer in the >>> world. There's not only the lock-time, but also a *lot* of internal >>> recalibration knobs that have to be adjusted every time it's tuned. >>> Ballpark would be several 10s of milliseconds. >>> >>> >>> Just to add a little more to Marcus's reply. The distance you retune (in >>> Hertz) affects the settling time. Certain re-calibrations are triggered >>> when this exceeds a threshold. How far is "far"? >>> >>> >>> _______________________________________________ >>> USRP-users mailing list >>> 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 > >

1. Can I assume that the rx retuning operations do not affect the
tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm looking for
the time after which retuning is done AND everything is settled, so that
the samples streamed from the new frequency are clean.

Thank you Micheal. I ran your code and found the same values (400 ms or more) as my code. Which is good news because: 1. It rules out the measurement error (boost vs std::chrono, both of which I trust from past experiences). 2. It points out that the problem is somewhere in my setup, since I get much higher values than you do. I ran my code on two identical setups, both with B210 and Ubuntu 14.04 low latency running on Haswell 4 GHz CPUs. I reverted back to UHD_003.008.005-10-g3dbced2d since the latest version created problems discussed in a different thread. Any suggestion on what to check? Or, any chance anybody else can run the code to see if this is really a unique problem of my setup? Thanks, Dario On Thu, Sep 10, 2015 at 7:30 PM, Michael West <michael.west@ettus.com> wrote: > Hi Dario, > > I took your code and replaced the std::chrono and std::thread stuff with > boost equivalents and was able to achieve retuning times of ~150-200 > microseconds after the initial tune (which took ~220 ms). No appreciable > difference over USB 2.0 or 3.0. The modified code is attached. > > Regards, > Michael > > On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> The attached example gives me retuning times of 400 ms or more, which is >> order of magnitudes beyond what is expected. Am I calling the API in some >> suboptimal way? >> I cleaned up the code so that it does nothing but retuning between two >> frequencies. Interestingly, the retuning time doesn't vary much with the >> frequency separation. >> >> Thanks, >> Dario >> >> >> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech <mleech@ripnet.com> >> wrote: >> >>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>> >>> Thank you both for your answers. Anything above a few ms forces me to >>> cross off one of the two design routes I had in mind, so " several 10s of >>> milliseconds" leaves me with a clean path. >>> About the frequency separation of the retuning, it could be up to one >>> GHz. >>> >>> Thanks, >>> Dario >>> >>> I think the current code does "recal avoidance" if the re-tune is less >>> than 100MHz. >>> >>> >>> >>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> >>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> >>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>> >>>> Currently my application runs continuous tx and rx on two different >>>> frequencies, with B210 in full-duplex MIMO configuration. Let's call fA the >>>> tx freq and fB the rx freq. >>>> >>>> Now I need to read short rx burts at frequency fC (which is far from >>>> both fA and fB). Namely, I need to retune the rx stream to fC, receive >>>> samples there for a little, then retune back to fB and stay there for a >>>> long time. This goes on periodically, while the tx stream stays on fA for >>>> the whole time. >>>> >>>> The following questions are critical for the design of the architecture. >>>> >>>> 1. Can I assume that the rx retuning operations do not affect the >>>> tx stream on fA? I have a continuous stream there. >>>> 2. What is a ballpark value for the retuning time? I'm looking for >>>> the time after which retuning is done AND everything is settled, so that >>>> the samples streamed from the new frequency are clean. >>>> >>>> Thanks, >>>> Dario >>>> >>>> The TX and RX synthesizers on the AD9361 and the DSP chains in each >>>> direction are independent. Changing parameters of the RX stream will not >>>> affect >>>> the TX stream. >>>> >>>> For (2), the AD9361 is not the fastest-locking synthesizer in the >>>> world. There's not only the lock-time, but also a *lot* of internal >>>> recalibration knobs that have to be adjusted every time it's tuned. >>>> Ballpark would be several 10s of milliseconds. >>>> >>>> >>>> Just to add a little more to Marcus's reply. The distance you retune >>>> (in Hertz) affects the settling time. Certain re-calibrations are triggered >>>> when this exceeds a threshold. How far is "far"? >>>> >>>> >>>> _______________________________________________ >>>> USRP-users mailing list >>>> 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 >> >> >

1. It rules out the measurement error (boost vs std::chrono, both of
which I trust from past experiences).
2. It points out that the problem is somewhere in my setup, since I
get much higher values than you do. I ran my code on two identical setups,
both with B210 and Ubuntu 14.04 low latency running on Haswell 4 GHz CPUs.
I reverted back to UHD_003.008.005-10-g3dbced2d since the latest version
created problems discussed in a different thread.

1. Can I assume that the rx retuning operations do not affect the
tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm looking for
the time after which retuning is done AND everything is settled, so that
the samples streamed from the new frequency are clean.

Hi Dario, My original run was based on our UHD 3.9.1 development branch. I re-ran using the same version you tested (UHD_003.008.005-10-g3dbced2d) and observed that the initial tuning took 477 milliseconds and retuning took ~400 microseconds. My set up is a Lenovo T430s laptop running Ubuntu 14.04. Perhaps running perf to profile the system while running the code will help you narrow down the issue on your system. Also, have you tried using USB 2.0 to see if there is a difference? Some USB 3.0 controllers are known to have issues. Regards, Michael On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani <dario.fertonani@gmail.com> wrote: > Thank you Micheal. > I ran your code and found the same values (400 ms or more) as my code. > Which is good news because: > > 1. It rules out the measurement error (boost vs std::chrono, both of > which I trust from past experiences). > 2. It points out that the problem is somewhere in my setup, since I > get much higher values than you do. I ran my code on two identical setups, > both with B210 and Ubuntu 14.04 low latency running on Haswell 4 GHz CPUs. > I reverted back to UHD_003.008.005-10-g3dbced2d since the latest version > created problems discussed in a different thread. > > Any suggestion on what to check? Or, any chance anybody else can run the > code to see if this is really a unique problem of my setup? > > Thanks, > Dario > > > > On Thu, Sep 10, 2015 at 7:30 PM, Michael West <michael.west@ettus.com> > wrote: > >> Hi Dario, >> >> I took your code and replaced the std::chrono and std::thread stuff with >> boost equivalents and was able to achieve retuning times of ~150-200 >> microseconds after the initial tune (which took ~220 ms). No appreciable >> difference over USB 2.0 or 3.0. The modified code is attached. >> >> Regards, >> Michael >> >> On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> The attached example gives me retuning times of 400 ms or more, which is >>> order of magnitudes beyond what is expected. Am I calling the API in some >>> suboptimal way? >>> I cleaned up the code so that it does nothing but retuning between two >>> frequencies. Interestingly, the retuning time doesn't vary much with the >>> frequency separation. >>> >>> Thanks, >>> Dario >>> >>> >>> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech <mleech@ripnet.com> >>> wrote: >>> >>>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>>> >>>> Thank you both for your answers. Anything above a few ms forces me to >>>> cross off one of the two design routes I had in mind, so " several 10s of >>>> milliseconds" leaves me with a clean path. >>>> About the frequency separation of the retuning, it could be up to one >>>> GHz. >>>> >>>> Thanks, >>>> Dario >>>> >>>> I think the current code does "recal avoidance" if the re-tune is less >>>> than 100MHz. >>>> >>>> >>>> >>>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> >>>>> >>>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>>> usrp-users@lists.ettus.com> wrote: >>>>> >>>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>>> >>>>> Currently my application runs continuous tx and rx on two different >>>>> frequencies, with B210 in full-duplex MIMO configuration. Let's call fA the >>>>> tx freq and fB the rx freq. >>>>> >>>>> Now I need to read short rx burts at frequency fC (which is far from >>>>> both fA and fB). Namely, I need to retune the rx stream to fC, receive >>>>> samples there for a little, then retune back to fB and stay there for a >>>>> long time. This goes on periodically, while the tx stream stays on fA for >>>>> the whole time. >>>>> >>>>> The following questions are critical for the design of the >>>>> architecture. >>>>> >>>>> 1. Can I assume that the rx retuning operations do not affect the >>>>> tx stream on fA? I have a continuous stream there. >>>>> 2. What is a ballpark value for the retuning time? I'm looking for >>>>> the time after which retuning is done AND everything is settled, so that >>>>> the samples streamed from the new frequency are clean. >>>>> >>>>> Thanks, >>>>> Dario >>>>> >>>>> The TX and RX synthesizers on the AD9361 and the DSP chains in each >>>>> direction are independent. Changing parameters of the RX stream will not >>>>> affect >>>>> the TX stream. >>>>> >>>>> For (2), the AD9361 is not the fastest-locking synthesizer in the >>>>> world. There's not only the lock-time, but also a *lot* of internal >>>>> recalibration knobs that have to be adjusted every time it's tuned. >>>>> Ballpark would be several 10s of milliseconds. >>>>> >>>>> >>>>> Just to add a little more to Marcus's reply. The distance you retune >>>>> (in Hertz) affects the settling time. Certain re-calibrations are triggered >>>>> when this exceeds a threshold. How far is "far"? >>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list >>>>> 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 >>> >>> >> >

1. It rules out the measurement error (boost vs std::chrono, both of
which I trust from past experiences).
2. It points out that the problem is somewhere in my setup, since I
get much higher values than you do. I ran my code on two identical setups,
both with B210 and Ubuntu 14.04 low latency running on Haswell 4 GHz CPUs.
I reverted back to UHD_003.008.005-10-g3dbced2d since the latest version
created problems discussed in a different thread.

1. Can I assume that the rx retuning operations do not affect the
tx stream on fA? I have a continuous stream there.
2. What is a ballpark value for the retuning time? I'm looking
for the time after which retuning is done AND everything is settled, so
that the samples streamed from the new frequency are clean.

I tried USB 2.0 and the results are almost identical. In summary, retuning takes 450 ms in my system, every time. Michael gets similar values in the first tuning, but after that there are sub ms values. My app can live with a few tens of ms for retuning (100x compared to Michael's results), but 450 ms is too much. The app performs well without retuning, reliably streaming 2x2 MIMO full duplex at LTE bandwidths, so I doubt it's a problem of CPU or USB driver, or UHD version. At this point I'm lost. Any suggestion is appreciated. Thanks, Dario On Fri, Sep 11, 2015 at 10:32 AM, Michael West <michael.west@ettus.com> wrote: > Hi Dario, > > My original run was based on our UHD 3.9.1 development branch. I re-ran > using the same version you tested (UHD_003.008.005-10-g3dbced2d) and > observed that the initial tuning took 477 milliseconds and retuning took > ~400 microseconds. My set up is a Lenovo T430s laptop running Ubuntu > 14.04. Perhaps running perf to profile the system while running the code > will help you narrow down the issue on your system. Also, have you tried > using USB 2.0 to see if there is a difference? Some USB 3.0 controllers > are known to have issues. > > Regards, > Michael > > On Thu, Sep 10, 2015 at 8:02 PM, Dario Fertonani < > dario.fertonani@gmail.com> wrote: > >> Thank you Micheal. >> I ran your code and found the same values (400 ms or more) as my code. >> Which is good news because: >> >> 1. It rules out the measurement error (boost vs std::chrono, both of >> which I trust from past experiences). >> 2. It points out that the problem is somewhere in my setup, since I >> get much higher values than you do. I ran my code on two identical setups, >> both with B210 and Ubuntu 14.04 low latency running on Haswell 4 GHz CPUs. >> I reverted back to UHD_003.008.005-10-g3dbced2d since the latest version >> created problems discussed in a different thread. >> >> Any suggestion on what to check? Or, any chance anybody else can run the >> code to see if this is really a unique problem of my setup? >> >> Thanks, >> Dario >> >> >> >> On Thu, Sep 10, 2015 at 7:30 PM, Michael West <michael.west@ettus.com> >> wrote: >> >>> Hi Dario, >>> >>> I took your code and replaced the std::chrono and std::thread stuff with >>> boost equivalents and was able to achieve retuning times of ~150-200 >>> microseconds after the initial tune (which took ~220 ms). No appreciable >>> difference over USB 2.0 or 3.0. The modified code is attached. >>> >>> Regards, >>> Michael >>> >>> On Thu, Sep 10, 2015 at 5:24 PM, Dario Fertonani via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> The attached example gives me retuning times of 400 ms or more, which >>>> is order of magnitudes beyond what is expected. Am I calling the API in >>>> some suboptimal way? >>>> I cleaned up the code so that it does nothing but retuning between two >>>> frequencies. Interestingly, the retuning time doesn't vary much with the >>>> frequency separation. >>>> >>>> Thanks, >>>> Dario >>>> >>>> >>>> On Thu, Aug 6, 2015 at 6:43 PM, Marcus D. Leech <mleech@ripnet.com> >>>> wrote: >>>> >>>>> On 08/06/2015 09:32 PM, Dario Fertonani wrote: >>>>> >>>>> Thank you both for your answers. Anything above a few ms forces me to >>>>> cross off one of the two design routes I had in mind, so " several 10s of >>>>> milliseconds" leaves me with a clean path. >>>>> About the frequency separation of the retuning, it could be up to one >>>>> GHz. >>>>> >>>>> Thanks, >>>>> Dario >>>>> >>>>> I think the current code does "recal avoidance" if the re-tune is less >>>>> than 100MHz. >>>>> >>>>> >>>>> >>>>> On Thu, Aug 6, 2015 at 4:25 PM, Ian Buckley via USRP-users < >>>>> usrp-users@lists.ettus.com> wrote: >>>>> >>>>>> >>>>>> On Aug 6, 2015, at 4:00 PM, Marcus D. Leech via USRP-users < >>>>>> usrp-users@lists.ettus.com> wrote: >>>>>> >>>>>> On 08/03/2015 12:54 AM, Dario Fertonani via USRP-users wrote: >>>>>> >>>>>> Currently my application runs continuous tx and rx on two different >>>>>> frequencies, with B210 in full-duplex MIMO configuration. Let's call fA the >>>>>> tx freq and fB the rx freq. >>>>>> >>>>>> Now I need to read short rx burts at frequency fC (which is far from >>>>>> both fA and fB). Namely, I need to retune the rx stream to fC, receive >>>>>> samples there for a little, then retune back to fB and stay there for a >>>>>> long time. This goes on periodically, while the tx stream stays on fA for >>>>>> the whole time. >>>>>> >>>>>> The following questions are critical for the design of the >>>>>> architecture. >>>>>> >>>>>> 1. Can I assume that the rx retuning operations do not affect the >>>>>> tx stream on fA? I have a continuous stream there. >>>>>> 2. What is a ballpark value for the retuning time? I'm looking >>>>>> for the time after which retuning is done AND everything is settled, so >>>>>> that the samples streamed from the new frequency are clean. >>>>>> >>>>>> Thanks, >>>>>> Dario >>>>>> >>>>>> The TX and RX synthesizers on the AD9361 and the DSP chains in each >>>>>> direction are independent. Changing parameters of the RX stream will not >>>>>> affect >>>>>> the TX stream. >>>>>> >>>>>> For (2), the AD9361 is not the fastest-locking synthesizer in the >>>>>> world. There's not only the lock-time, but also a *lot* of internal >>>>>> recalibration knobs that have to be adjusted every time it's tuned. >>>>>> Ballpark would be several 10s of milliseconds. >>>>>> >>>>>> >>>>>> Just to add a little more to Marcus's reply. The distance you retune >>>>>> (in Hertz) affects the settling time. Certain re-calibrations are triggered >>>>>> when this exceeds a threshold. How far is "far"? >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> USRP-users mailing list >>>>>> 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 >>>> >>>> >>> >> >