LimeSDR XTRX Operation on Raspberry Pi 5 via mPCIe HAT

[osqzss]

I recently purchased a LimeSDR XTRX (board version v1.2) from Mouser and am trying to use it with a Raspberry Pi 5 for an SDR project.

To connect the XTRX, I’m using a Mini PCIe to PCIe adapter HAT from 52Pi.

52Pi M02 PCIe Express to Mini PCIe HAT for Raspberry Pi 5, Support All Mini...

I enabled the PCIe interface on the Raspberry Pi by adding the “dtparam=pciex1” line to /boot/firmware/config.txt.

After rebooting, the LED1 on the XTRX is flashing slowly, and the LED2 is blinking more rapidly. I’m not sure if this is the expected behavior. Could someone clarify what these LEDs indicate?

When I run the ‘lspci’ command, I get the following output:

0001:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21)
0001:01:00.0 Multimedia audio controller: Xilinx Corporation Device 7023 (rev 01)

These lines do not appear when the XTRX is disconnected, so I assume the device is at least partially detected and shows up as a multimedia audio controller.

Is this the correct output for a properly recognized LimeSDR XTRX? If not, what should I expect to see when the device is correctly initialized?

I tried “dmesg | grep litepcie” as suggested by @sergey, but nothing showed up.

Limesdr xtrx not found

I think it is correct that it is detected as a Xilinx audio controller. Is something aligned with the information in other threads here. And I don’t think it is that uncommon for smaller teams of developers to re-use all those PCIe or USB identifiers, as registering your own is not that easy or cheap. But, again, that is my understanding I use CM4 IO Board, which, I think, is the official one. And for the adapter I got some generic adapter typically used for WiFi module. I think t…

I am also concerned about the device’s temperature. The XTRX becomes quite hot even when idle, and it seems to start transmitting immediately upon powering on the Raspberry Pi. This causes the WiFi connection on the Pi to drop, possibly due to interference. Is this expected behavior, and is there a way to prevent unintended transmission at startup?

Any advice on verifying the setup and ensuring full functionality would be greatly appreciated.

[osqzss]

Just after posting the questions above, I came across a very informative post by @tszn.

XTRX not found

Dear All, I come with good news, for the ones, who want to use the XTRX on the RPi5, and share with you this post as sort of Manual and Lessons Learnt, of how I was able to get my unit(s) to work. Note that I use the pineboards (former pineberrypi) HatMPCIe (my version is 2024/V1), as miniPCIe interface. I got a multitude of other adapter combinations first to PCIx1 and then to mPCIe, however I’ve been using the pineboards products from the beginning and would recommend all their products -…

My LimeSDR XTRX board does not have R114 populated, but it was still consistently recognized as a Multimedia audio controller, and LED2 was blinking. I decided to leave R114 open and move forward.

I followed the instructions and successfully built LimeSuiteNG as described in Step 2.2. I skipped Steps 2.3 and 2.4, and after that, running “limeDevice --full” correctly detected the LimeSDR XTRX without any trouble.

Many thanks to @tszn for the detailed and helpful guidance.

That said, I still have some concern about the board’s temperature. It runs noticeably hot even when idle. I saw a related comment by @0x12BFB9FA, but I’m still unsure if this behavior is considered normal or requires attention.

Temperature of LimeSDR XTRX

Hey, when running with sample rates around the max possible mine definitely gets uncomfortably warm (>85C, which is what the original fairwaves XTRX pro was rated for) [image] I ended up adding a small 40mm fan to actively cool it (after which it hovers ~50-55C on the onboard temp sensor)

Any insights on the thermal behavior of the XTRX would be appreciated.

[sergey]

Hey,

The blinking LEDs sounds correct.

The lspci output also seems correct to me: that is how the device has always been identified for me. At some point it seems to have changed to “Wireless controller: 2058:001b (rev 01)” for me. Not sure if that’s because I currently using different OS and adapter, or whether it changed in a gateware at some point.

I don’t think there is registered VID:PID for XTRX, so it will not be presented as XTRX in the output of lspci. And as long as the driver and gateware are using the same VID:PID it shouldn’t really matter.

So I’d suggest just to try building LimeSuiteNG and using utilities like limeDevice and limeOEM --test to see whether the driver can enumerate the device and that the software can communicate to the device.

The temperature could raise quite a bit. You need a good cooling. The carrier board can be equipped with a thermal pad to help dissipation. Some configurations might also require having active cooling – this is what i end up using in my dev setup as the system is open and there is no good airflow.

The TX during startup I has not been able to confirm so far. Some deeper investigation is needed.

[andrewback]

@osqzss

Any insights on the thermal behavior of the XTRX would be appreciated.

It’s a small board and depending upon various factors can get quite warm. In general we would recommend some sort of cooling. The Front-End Adapter board which we sell has a large copper section under the XTRX and a thermal pad supplied with it. In your case you might use a small fan.

@sergey

I don’t think there is registered VID:PID for XTRX,

I believe there should be with the latest gateware, but @VytautasB could confirm.

[sergey]

@andrewback

I believe there should be with the latest gateware, but @VytautasB could confirm.

Ah, great to know!
Would indeed be fantastic to confirm the expected VID:PID and how the lspci expected to name the device

[VytautasB]

With latest GW it should show as:

Wireless controller: Device 2058:001b (rev 01)

[markterry2]

The boards we have received since about March of this year no longer need R114 polulated. R89 and R90 values changed and it now works properly as shipped.