Dear manager:
Please help unsubscribe E-mail list from usrp-users-requ...@lists.ettus.com.
Thank you!
-------- Forwarding messages --------
From: usrp-users-requ...@lists.ettus.com
Date: 2021-11-25 16:30:18
To: usrp-users@lists.ettus.com
Subject: USRP-users Digest, Vol 135, Issue 54
Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Trouble with TwinRX frequency tuning (Rob Kossler)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Nov 2021 23:12:00 -0500
From: Rob Kossler <rkoss...@nd.edu>
Subject: [USRP-users] Re: Trouble with TwinRX frequency tuning
To: "Marcus D. Leech" <patchvonbr...@gmail.com>
Cc: usrp-users@lists.ettus.com
Message-ID:
<cab__hts2hwxkbjhec_dcyv15sqe0a8hc9oomltfqwlpei99...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="000000000000dbecaf05d1952d39"
Nice catch Marcus. I hadn’t noticed the use of set_time_now() rather than
set_time_unknown_pps().
Emanuele, I think if you use set_time_unknown_pps(0) you can get consistent
phase behavior.
On Wed, Nov 24, 2021 at 9:41 PM Marcus D. Leech <patchvonbr...@gmail.com>
wrote:
> On 2021-11-24 12:47, emanuele.tolo...@intecs.it wrote:
>
> It was not clear to me from your email if using a time setting of zero
> will
> solve the issue. It seemed that you still have a phase issue in this case?
>
> Yes. If we use a time setting of zero, the application runs smoothly
> without crashes, but there is an unpredictable phase shift between the
> channels.
>
> Our problem occurs only when the tuning and synchronization instructions
> are repeated in a loop, even if tuning always at the same frequency.
> Instead, if we tune and synchronize the channels only once, such as in the
> attached snippet (a modified version of the rx_multi_samples UHD example),
> everything runs smooth and the phase shift between the channels is coherent
> each time we start the application. As you can see, in the attached code
> the set_time_now(uhd::time_spec_t(0.0)) command is never called, and if we
> add that command the phase shifts between the channels change at every run.
> In our application, however, removing this command leads the aforementioned
> crashes.
>
> That is, the FPGA
> time reference can be zero and the CPU time reference can be system-time
> and whenever you need a time from the FPGA you can apply the appropriate
> reference in the CPU.
>
> What do you mean with CPU time reference? In our application the
> system-time is the host CPU time.
>
> Emanuele Tolomei
>
> The problem with set_time_now(), is that it sets the time register(s) to
> whatever you supply, and since there are a couple of unknown latencies, the
> time will necessarily be
> very imprecise. The first latency is how long it takes to conduct the
> transaction across the network link between your computer and the USRP.
> The 2nd is that in X310, as
> I recall, there are TWO time-keepers, one for each notional "radio"
> object. Since they will necessarily be set serially, the time registers
> won't necessarily be consistent with
> each other, and definitely won't be consistent with whatever the hosts
> notion of time is.
>
> If you use actual host time-of-day, the time-of-day on the USRP will VERY
> likely drift relative to the time-of-day on the USRP device, since they're
> operating from
> disjoint clocks.
>
> THIS is why the 1PPS input is important in synchronization. Even on a
> single X310, since it has two timekeepers, the 1PPS input provides a
> predictable and *parallel*
> load of the desired time-of-day into the time registers.
>
>
>
> Rob Kossler wrote:
>
> Hi Emanuele, I have never tried to use set_time_now() with anything other
> than zero as the time setting. Of course, this does not mean that it is
> impossible. But, I am wondering if your application can work just as easily
> by always translating the time on the CPU rather than in the FPGA. That is,
> the FPGA time reference can be zero and the CPU time reference can be
> system-time and whenever you need a time from the FPGA you can apply the
> appropriate reference in the CPU.
>
> It was not clear to me from your email if using a time setting of zero
> will solve the issue. It seemed that you still have a phase issue in this
> case? Rob
>
> On Wed, Nov 24, 2021 at 11:25 AM emanuele.tolo...@intecs.it wrote:
>
> Hi Marcus,
>
> as I said in the previous post I tried to do a get_time_now() just before
> the timed command, but without success.
>
> // Tune all channels to the desired frequency
>
> uhd::tune_result_t tune_resp = m_MultiUsrp->set_rx_freq(nRxFrequency,0);
>
> //set time on the master (mboard 0)
>
> struct timespec now;
>
> clock_gettime(CLOCK_REALTIME, &now);
>
>
> m_MultiUsrp->set_time_now(uhd::time_spec_t(now.tv_sec,(double)now.tv_nsec/1.0e6));
>
> uhd::time_spec_t usrp_time = m_MultiUsrp->get_time_now();
>
> m_MultiUsrp->set_rx_gain(nGain, 1);
>
> m_MultiUsrp->set_rx_gain(nGain, 2);
>
> m_MultiUsrp->set_rx_gain(nGain, 3);
>
> uhd::tune_request_t tune_req;
>
> tune_req.rf_freq = tune_resp.actual_rf_freq;
>
> tune_req.rf_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
>
> tune_req.dsp_freq = tune_resp.actual_dsp_freq;
>
> tune_req.dsp_freq_policy = uhd::tune_request_t::POLICY_MANUAL;
>
> m_MultiUsrp->set_rx_freq(tune_req, 1);
>
> m_MultiUsrp->set_rx_freq(tune_req, 2);
>
> m_MultiUsrp->set_rx_freq(tune_req, 3);
>
> usrp_time = m_MultiUsrp->get_time_now() ;
>
> // Synchronize the tuned channels
>
> m_MultiUsrp->set_command_time(usrp_time + uhd::time_spec_t(0.1));
>
> m_MultiUsrp->set_rx_freq(tune_req, 0);
>
> m_MultiUsrp->set_rx_freq(tune_req, 1);
>
> m_MultiUsrp->set_rx_freq(tune_req, 2);
>
> m_MultiUsrp->set_rx_freq(tune_req, 3);
>
> m_MultiUsrp->clear_command_time();
>
> Thank you.
> ------------------------------
>
> USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send
> an email to usrp-users-le...@lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 7993 bytes
Desc: not available
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 135, Issue 54
*******************************************
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
