[USRP-users] What makes sense and what doesn't in the way carrier frequency is set for TwinRX currently?

Nate Temple nate.temple at ettus.com
Sat Mar 23 11:34:30 EDT 2019


Hi Piotr,

A quick update -- we have root caused the issue and will have an update
that fixes it on the 3.14.0.0 release.

Regards,
Nate Temple

On Sat, Mar 23, 2019 at 8:14 AM Piotr Krysik via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Hi all,
>
> Update to the previous post. Nate Temple on IRC pointed that what I
> observe might be a result of a bug in recent UHD's, where co-channel
> phase difference on TwinRX doesn't behave as expected.
> Nate's advice was to go back to UHD 3.13, which I did (I took the top
> from UHD-3.13 branch).
>
> I did tests with original twinrx_usrp_source.py (where on
> UHD_3.15.0.git-13-g52138314 I had problem with phase changes).
> With UHD 3.13 I didn't need additional call to set_time_unknown_pps. The
> co-channel phase differences were constant from one program running to
> another without it.
>
> So it seems the strange behavior of phase in signal coming from TwinRXes
> might be a result of a bug that Nate was informing about.
>
> --
> Best Regards,
> Piotr Krysik
>
> W dniu 13.03.2019 o 14:48, Piotr Krysik via USRP-users pisze:
> > Hello everyone,
> >
> > TwinRXes requires special treatment when setting frequency in order to
> > keep co-channel phase differences across multiple executions of a
> > program communicating with USRP.
> >
> > What exactly 'treatment' I mean can be seen for example here:
> >
> https://github.com/EttusResearch/gr-doa/blob/master/python/twinrx_usrp_source.py#L100
> >
> > or here:
> >
> >
> https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/apps/uhd_app.py#L298
> >
> >
> > The procedure is following (correct configuration of LO export and LO
> > sources is assumed):
> >
> > 1. set the frequency for the channel exporting LOs, and store result,
> > 2. set the frequency for the rest of the channels using the result saved
> > previously and POLICY_MANUAL for rf and dsp,
> > 3. set the frequency again for all channels with use of timed commands.
> >
> > In uhd_app's constructor there is also call to set_time_unknown_pps
> > between points 2 and 3. In twinrx_usrp_source.py set_time_unknown_pps is
> > called before point 1. The placement of this function call after the
> > first setting of the carrier frequency seems to be crucial. Without it
> > there are random 180 degree changes of phase differences between
> > channels from one run to another. And this issue can be observed for
> > twinrx_usrp_source.py, because it calls set_time_unknown_pps before
> > setting the frequency (checked on UHD_3.15.0.git-13-g52138314).
> >
> > I also changed different settings to see what effects they have. I
> > didn't notice any effect of POLICY_MANUAL setting in point 2. Setting
> > the frequency in regular way seems to work just as well. Also removing
> > point 3 completely (setting freq. with use of timed commands) seems to
> > not have any effect for TwinRX (I checked this with use of sine wave as
> > the input signal, in case it is important).
> >
> > In the end what I did was configuring LO export/sources in GNU Radio and
> > adding usrp.set_time_unknown_pps(..) at the end of the of the
> > constructor. As a result co-channel phase differences were (~) constant
> > across multiple runs.
> >
> >
> > My question:
> > 1. What is the rationale for all of the steps of frequency setting for
> > TwinRX? Did I have luck that most of them didn't have any effect for me?
> > 2. Why is the call to set_time_unknown_pps required at all? And why when
> > it is called after the first setting of carrier frequency in all
> > channels, it fixes the issue with 180 degree phase shifts from one run
> > to another? If it's called before, it doesn't seem to have this positive
> > effect.
> >
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190323/d1ab6c42/attachment.html>


More information about the USRP-users mailing list