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