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@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@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
