Hi,
I don't know what this patch does, but there is not software required
under certain circumstances. The reference clock is 200 MHz and there
are a few PLLs which are used to generate your LOs. When the PLLs run in
interger-N mode (which can be defined in the API, when explicitly
setting the frequencies), and they do not divide the clock, all LOs will
have the same phase. So in multiples of 200 MHz this should be the case.
For multiples of 50 MHz you will get 90° random phase jumps after the
PLLs are locked again.
Best regards,
Fabian
Am 03.04.2019 um 12:36 schrieb Piotr Krysik via USRP-users:
To answer my own question:
https://github.com/EttusResearch/uhd/blob/master/CHANGELOG#L226
it seems the answer is yes.
--
Piotr Krysik
W dniu 03.04.2019 o 12:34, Piotr Krysik via USRP-users pisze:
Hi,
W dniu 03.04.2019 o 12:15, Fabian Schwartau via USRP-users pisze:
(...)
Keep in mind that it is not necessary to use LO-sharing to get a well
defined phase relation between the channels. Depending on your
frequency and bandwidth settings, it is possible to also achive this,
as all LOs are driven from a common 200 MHz reference clock.
Do you mean TwinRXes might have similar initial phase reset capability
that UBXes and SBXes have?
--
Best Regards,
Piotr Krysik
Best regards,
Fabian
Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
Hi Fabian,
W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:
Hi Piotr,
we once had a very similar issue. But we also saw this on the same
frequency when switching between frequencies. Can you try this as
well? Just switch forth and back between two frequencies and just plot
one of them?
I'm not sure I understand correctly what you mean. You mean that the
result for a given frequency was not stable in your case across many
measurements? In our case this situation was repeating, but the
application doing the recording was restarted for each measurement.
As far as I remember the issue was because we were not using the
LO-Sharing. We were able to get everything running by using a C++
application and not gnuradio (I can see you are using python - which
is basically the same). There was a bug in gnuradio/python causing
this issue.
You can try to remove one of the LO-sharing cables while doing a
measurement and see if the phase suddenly starts to do crazy things
(the signal should also be lost). If that is not the case, you are not
actually using LO-sharing.
Do you know what this bug was exactly? GNU Radio didn't configure
LO-Sharing the way it was specified?
--
Best Regards,
Piotr Krysik
_______________________________________________
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
