Hi Marcus
After stripping out the wrappers and replacing variables etc. it looks like we are using the following lines to attempt to setup the code to share the LO: USRP->set_rx_lo_export_enabled(true, USRP->ALL_LOS, 0); USRP->set_rx_lo_source(“internal”, USRP->ALL_LOS, 0); USRP->set_rx_lo_export_enabled(true, USRP->ALL_LOS, 0); USRP->set_rx_lo_source(“companion”, USRP->ALL_LOS, 1); USRP->set_rx_lo_export_enabled(true, USRP->ALL_LOS, 0); USRP->set_rx_lo_source(“external”, USRP->ALL_LOS, 2); USRP->set_rx_lo_export_enabled(true, USRP->ALL_LOS, 0); USRP->set_rx_lo_source(“external”, USRP->ALL_LOS, 3); I did wonder about the fact that channel 2 and 3 use “external” and whether that shouldn’t somehow be “reimport” or “companion” to indicate it should be sharing the LO, instead of getting an LO from external to the X310. Or should “external” only be interpreted as external to the TwinRX daughterboard? What I am seeing here that is also bothering me is that we are calling set_rx_lo_export_enabled 4 times with the same settings, with the intention that it should be setting up each of the channels, to use channel 0. Should that actually be 0 to 3 or should we be explicitly be disabling 1 to 3? Oh, something possibly unrelated is that for the mode where the code changes frequency after running, I initially tried to do that using a timed tune request, however I found that after 48 such requests the firmware crashed as stopped working, then I reverted to the mode of stopping the streaming and using tune request without a command time. I know after initialisation we do start at a specific time, but am not sure if the tune request during initialisation is timed or not. Leon From: Marcus D. Leech <patchvonbr...@gmail.com> Date: Thursday, 20 April 2023 at 16:51 To: usrp-users@lists.ettus.com <usrp-users@lists.ettus.com> Subject: [USRP-users] Re: TwinRX phase synchronisation using different versions of UHD You don't often get email from patchvonbr...@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> [The e-mail server of the sender could not be verified (SPF Record)] 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<http://pta-smg4.csir.co.za:32224/?dmVyPTEuMDAxJiZhNzg5YTc0YzlmOGY1ZTVkNj02NDQxNTE3Nl8xNjc3Ml81MjUyXzEmJjllNzFhZmQ2YTMwMzg1Mj0xMzMzJiZ1cmw9aHR0cHMlM0ElMkYlMkZrYiUyRWV0dHVzJTJFY29tJTJGRGlyZWN0aW9uJTVGRmluZGluZyU1RndpdGglNUZ0aGUlNUZVU1JQJTI1RTIlMjU4NCUyNUEyJTVGWC1TZXJpZXMlNUZhbmQlNUZUd2luUlglMjVFMiUyNTg0JTI1QTI=>). (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
