# Choosing LimeSDR XTRX v1.3 for GPR

**URL:** <https://discourse.myriadrf.org/t/choosing-limesdr-xtrx-v1-3-for-gpr/13332>\
**Category:** LimeSDR\
**Created:** [17 September 2026 07:22 UTC](https://discourse.myriadrf.org/t/choosing-limesdr-xtrx-v1-3-for-gpr/13332 "2026-09-17T07:22:12Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![PHASEONE\_big](https://avatars.discourse-cdn.com/v4/letter/p/a183cd/32.png) [@PHASEONE\_big](https://discourse.myriadrf.org/u/PHASEONE_big)\
**Post date:** [17 September 2026 07:22 UTC](https://discourse.myriadrf.org/t/choosing-limesdr-xtrx-v1-3-for-gpr/13332/1 "2026-09-17T07:22:12Z")

</div>

Dear All,

We are considering the LimeSDR XTRX v1.3 (CS-LIME-27) for a stepped-frequency radar research prototype, and I would like to clarify a few details before ordering the hardware.

Our intended RF range is approximately **40 MHz to 3.44 GHz**. We want to acquire complex measurements (amplitude and phase) at many discrete frequency points and later use these measurements for range processing and 2D/3D reconstruction.

I found the previous discussions about XTRX frequency coverage and SFCW use. In particular, I understand that the “non-continuous coverage” wording does not necessarily mean actual frequency gaps, but rather that different matching networks are optimized for different frequency ranges. I also found the discussion about an SFCW radar implementation being moved from an Ettus SDR to XTRX.

Our main remaining concern is therefore **phase repeatability during LO retuning**.

The measurement architecture we are considering is:

- TX → antenna

- RX1 → radar echo

- RX2 → attenuated/coupled sample of the same TX signal used as a phase reference

RX1 and RX2 would be acquired simultaneously at every frequency step.

The idea is to calculate, after calibration:

**H(f) = RX1(f) / RX2(f)**

so that any unknown TX/LO phase offset common to both measurements after each frequency retune would cancel.

Could you please clarify the following:

1. **Is this reference-channel approach valid on XTRX/LMS7002M?**

2. **Are RX1 and RX2 guaranteed to share the same RX LO and sampling clock, with a deterministic relative phase relationship?**

3. I found the recent discussion concerning **RX channel alignment on XTRX with LimeSuiteNG** , where channel alignment available in Classic LimeSuite was reported as not yet implemented in LimeSuiteNG.

4. **Does changing frequency or RF path introduce any independent phase discontinuity between RX1 and RX2?**

5. For a stepped-frequency measurement, what is the recommended sequence after changing LO frequency?

6. We may use hundreds or thousands of predetermined frequency points per sweep.

7. Longer term, we would prefer the timing-critical sweep sequencing not to depend on Linux/host scheduling.

8. Finally, for phase-coherent measurements, are there any particular **calibration operations that should NOT be performed between frequency points** , because they would change an otherwise stable RX1↔RX2 phase relationship?

Our first validation experiment would be entirely conducted over cables: TX would be attenuated and split/coupled into RX1 and RX2, and we would repeat a 40–3440 MHz sweep many times to characterize amplitude, phase, channel alignment, retuning repeatability, and temperature drift before connecting antennas.

If there are known limitations of XTRX for this measurement architecture, or a better synchronization/reference method that you recommend, we would be very interested to hear it.

Thank you!

---

<div class="post-metadata">

**Author:** ![ricardas](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/ricardas/32/86_2.png) [@ricardas](https://discourse.myriadrf.org/u/ricardas)\
**Post date:** [17 September 2026 12:01 UTC](https://discourse.myriadrf.org/t/choosing-limesdr-xtrx-v1-3-for-gpr/13332/2 "2026-09-17T12:01:17Z")

</div>

Hi,

> [@PHASEONE\_big](#):
>
> I understand that the “non-continuous coverage” wording does not necessarily mean actual frequency gaps, but rather that different matching networks are optimized for different frequency ranges.

Yes, that is correct.

> [@PHASEONE\_big](#):
>
> 1. **Are RX1 and RX2 guaranteed to share the same RX LO and sampling clock, with a deterministic relative phase relationship?**
> 
> 2. I found the recent discussion concerning **RX channel alignment on XTRX with LimeSuiteNG** , where channel alignment available in Classic LimeSuite was reported as not yet implemented in LimeSuiteNG.

Yes, both Rx channels share the same RX LO and sampling clock. In the LMS7002M digital side there can be initial non deterministic phase difference between channels, but there is a procedure to bring both channels into matching phases. [LMS7002M-docs/LimeSDR-USB\_channel\_alignment\_v01r00.pdf at master · myriadrf/LMS7002M-docs · GitHub](https://github.com/myriadrf/LMS7002M-docs/blob/master/LimeSDR-USB_channel_alignment_v01r00.pdf)  
It’s currently not available in LimeSuiteNG, but can be added relatively easily.  
Once the channel phases are matched, they would remain that way as long as the LMS7002M digital part clocking is not reconfigured (meaning the sampling rate is not modified).

> [@PHASEONE\_big](#):
>
> 1. Does changing frequency or RF path introduce any independent phase discontinuity between RX1 and RX2?

No, changing LO frequency or antenna path should not affect it.

> [@PHASEONE\_big](#):
>
> 1. For a stepped-frequency measurement, what is the recommended sequence after changing LO frequency?

tuneLO, set DC/QEC correctors(if needed), Rx stream start and data acquisition.  
It would be hard to detect the exact point of LO change in a continuous Rx stream, or how many samples would need to be discarded. So the Rx stream should be stopped, and restarted after LO change, that would ensure you would get RF samples instantly with the new parameters.

> [@PHASEONE\_big](#):
>
> 1. Is there a recommended lock/settling indication or minimum settling time rather than using a conservative fixed delay?

There is lock indicator register.

> [@PHASEONE\_big](#):
>
> 1. I saw the discussion suggesting approximately 500 µs retuning after optimization and potentially faster operation if frequency-dependent synthesizer values are precomputed.

Yes, LO frequency tune in \<500us is possible, if the PLL tune value for that frequency is already known. Then the time is dependent only on SPI speed, and the fixed amount of registers that need to be written. If the frequency jump is small, then it could be even faster, as most of the registers values would not need changing.

> [@PHASEONE\_big](#):
>
> 1. Is there currently an API or recommended method in LimeSuiteNG/XTRX gateware to precompute the required tuning values and perform a fast deterministic frequency sequence?

There is no dedicated API for that. The computed values can simply be readback/written using SPI functions.

> [@PHASEONE\_big](#):
>
> 1. Longer term, we would prefer the timing-critical sweep sequencing not to depend on Linux/host scheduling.

FPGA’s gateware has an MCU core running firmware, so the frequency step sequencing could be implemented in C. At this moment I’m not aware of how much resources would be available for that. [LimeSDR\_GW/firmware/main.c at master · myriadrf/LimeSDR\_GW · GitHub](https://github.com/myriadrf/LimeSDR_GW/blob/master/firmware/main.c)

> [@PHASEONE\_big](#):
>
> 1. Finally, for phase-coherent measurements, are there any particular **calibration operations that should NOT be performed between frequency points** , because they would change an otherwise stable RX1↔RX2 phase relationship?

No sampling rate changes or DC/QEC calibration algorithms should be executed. For DC/QEC corrections, the values could be precomputed ahead of time, so that during your sweep, they would be already known and just a simple register write.

---

<div class="post-metadata">

**Author:** ![PHASEONE\_big](https://avatars.discourse-cdn.com/v4/letter/p/a183cd/32.png) [@PHASEONE\_big](https://discourse.myriadrf.org/u/PHASEONE_big)\
**Post date:** [20 September 2026 12:59 UTC](https://discourse.myriadrf.org/t/choosing-limesdr-xtrx-v1-3-for-gpr/13332/3 "2026-09-20T12:59:22Z")

</div>

Thanks for taking the time to explain all of this — it’s really helpful.

We’ll start with a cable-only setup: split an attenuated TX signal into both RX channels, then check the RX1/RX2 ratio across repeated sweeps and with a known cable delay. We’ll keep the sample rate fixed and prepare the DC/QEC correction values before the sweep.

There’s one detail I’d like to clarify. You recommend stopping and restarting the RX stream around each LO change. Does that preserve the channel alignment, including the relative sample timing, or can a stream restart reset something that requires alignment again?

Also, is there an issue or an existing code example we should follow for bringing the alignment procedure into LimeSuiteNG on XTRX? We’re happy to test it and share measurements; a pointer to the right starting point would help a lot.

Thanks again — this gives us a much clearer path for the first bench tests.

---

<div class="post-metadata">

**Author:** ![ricardas](https://yyz2.discourse-cdn.com/flex034/user_avatar/discourse.myriadrf.org/ricardas/32/86_2.png) [@ricardas](https://discourse.myriadrf.org/u/ricardas)\
**Post date:** [21 September 2026 07:15 UTC](https://discourse.myriadrf.org/t/choosing-limesdr-xtrx-v1-3-for-gpr/13332/4 "2026-09-21T07:15:02Z")

</div>

> [@PHASEONE\_big](#):
>
> You recommend stopping and restarting the RX stream around each LO change. Does that preserve the channel alignment, including the relative sample timing, or can a stream restart reset something that requires alignment again?

Yes, everything would be preserved. Streaming start/stop is essentially just data buffers clearing in FPGA, it does not affect LMS7002M.

> [@PHASEONE\_big](#):
>
> Also, is there an issue or an existing code example we should follow for bringing the alignment procedure into LimeSuiteNG on XTRX?

There has been some initial work done, but I haven’t reviewed or tested that yet. [Channel Alignment · Issue #356 · myriadrf/LimeSuiteNG · GitHub](https://github.com/myriadrf/LimeSuiteNG/issues/356)