Pitor:
We've seen a similar issue and have worked around it by just using a slightly
different frequency. Can you post the frequencies that you're seeing it on? I
think Ettus should be able to duplicate. I saw an issue with spectral inversion
(I think I and Q are getting swapped somewhere) at 2.8GHz but not 2.9GHz.
-Kevin
On 4/4/19, 12:00 PM, "USRP-users on behalf of
usrp-users-requ...@lists.ettus.com" <usrp-users-boun...@lists.ettus.com on
behalf of usrp-users-requ...@lists.ettus.com> wrote:
Hi,
After disconnecting LO cables signal on the daughter-board that imports
LOs disappears. So GNU Radio correctly configures distribution of LOs.
Also the +/- 90 degree changes happen completely deterministically in
given ranges of carrier frequencies.
So the question remains open: what is causing the issue described in the
first post of this thread?
--
Best Regards,
Piotr Krysik
W dniu 03.04.2019 o?12:15, Fabian Schwartau via USRP-users pisze:
>Hi,
>
>yes, the result for multiple measurements (start ups of the system) at
>a single frequency was different by multiples of 90?.
>We did not investigated the problem any further, but I am quite sure
>that gnuradio was not synchronizing the channels using the LO-sharing,
>although it was selected. So do the test I described. If you see that
>he is not using the LO-sharing, you know where to look further.
>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.
>
>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
