On 20/04/2023 10:42, Leon Wabeke wrote:
I am using code utilizing the UHD library to capture samples from a
X310 with 2 TwinRX daughterboards. The sample rate is set to 25MSps.
This is to characterize the system to ultimately use it in for phase
interferometry direction finding similar to AN-244
(https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2).
(I tried installing that, but still some compiling issues to try to
resolve)
As a test setup, I am using another X310 with UBX to generate a test
signal, passing through a 4 way splitter to the 4 channels of the
TwinRX. In software I correlate with the transmitted signal and
extract the phase of the peak. I then plot it relative to ch0’s phase.
Theory says that if I do it for different frequencies, the slope of
the phase over frequency corresponds to path length differences of the
cables (and the splitter/receiver response).
Using an application developed a few years ago using UHD v3.13.0.0
directly (and UHD v3.15.0.0), I am able to successfully capture data.
The process is script driven, launch the custom app to initialize the
SDR on a specific frequency and capture data to a file. Then close and
quit the app and repeat this over 60 frequencies.
The application also supported a mode where instead of quitting
completely, it could stop streaming, change frequency and start
capturing again. I only tested this mode using UHD-3.13, however in
that case, I saw that after the frequency change, there was a random
multiple of 90 degrees phase offset present on some of the channels.
This implies there was some nuance in the process of stopping,
changing frequency and restarting streaming that was different from my
process of initializing (during which a frequency is selected).
Testing seemed to indicate that if I stopped and restarted on the same
frequency, these phase jumps did not occur.
When I tried upgrading to UHD v4.2.0.0 or UHD v4.4.0.0, I found that
this random frequency offset was also present if I captured just using
the initialize process.
The attached figure shows the phase in the frequency range 5.25GHz,
with the solid lines from the capturing using UHD 3.13 while the dots
are from the capture using UHD 4.4. The change in the lines between
5.21-53GHz and 5.51-5.6GHz I assume is due to changes in internal
mixing strategy chosen by the expert mode tuner to avoid mixing
products? While that is not nice, it atleast is repeatable while the
offsets in the dots are random multiples of 90.
I assume that the 90 degrees originate either from mixing up I and Q
somewhere in the data stream or what I suspect has to do with the
decimation process to reduce the sample rate down to 25MSps. Years ago
I worked with another sampler, where the clocks were not constrained
properly and it also exhibited this behaviour due to clocks locking on
one of 4 clock edges.
Any ideas where I can further dig to locate the problem? For the 3.13
the fact that it seemed consistent on initialization, while being
problematic on freq change hinted I need to carefully study the
sequence of events during those activities, but the fact that the
initialization sequence no longer gives consistent results in >=4.2,
makes me wonder that even if I chase that difference, it might only be
of historic value. Can someone confirm that they have either seen this
90 degree random phase and/or that they are getting consistent phases
(under what conditions?)
Thanks
Leon
Are you LO-sharing across channels, or relying on synthesizer
phase-reset and timed tuning?
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
