Replies: 1 comment
-
Hi @apex-jpg, Thanks for reposting the question that you sent to the srsLTE user lists here, so it might reach the community better. I'll also repost my answer to you here with the same objective. The Zynq Timestamping solution was designed with the objective of being as generic as possible, but to be fair we did optimize it for medium/large Zynq devices, having in mind to enable accelerating big parts of the PHY on the FPGA too. This means that we never really took the time to fully optimize it for the ADALM-PLUTO. If you dive into the discussions and issues sections, you will see that different users have tried to use the ADALM-PLUTO with different levels of success. Unfortunately, it seems that the USB 2.0 in the ADALM-PLUTO has issues keeping a stable 1.92 MSPS exchange with the host when using regular IIO. Two main solutions can be applied to overcome that: i) using large iio_buffers, as described in this thread or ii) running the full srsRAN stack in the Zynq device. Unfortunately, using large buffers is not mixing well with LTE's HARQ requirements. Regarding the latter, while the bandwidth between the embedded ARM and the FPGA is no longer an issue, the truth is that without offloading part of the PHY processing to the FPGA, you will only be able to run applications with limited performance requirements. This being said, I can see three main options on your end:
Best regards, |
Beta Was this translation helpful? Give feedback.
-
Hello!
I'm currently involved in a project aimed at LTE signal analysis using the LTESniffer tool and an ADALM Pluto SDR device. I am exploring the potential of zynq timestamping implementation to tackle certain issues I am facing.
About LTESniffer
LTESniffer is a versatile, open-source tool built on top of FALCON and srsRAN. It provides a range of capabilities including uplink and downlink sniffing, image mapping, and information extraction.
Encountered Issues
I've been experiencing issues with uplink and downlink sniffing.
According to the authors of LTESniffer, this might stem from a hardware compatibility issue - the requirement of an SDR device to support 2 clock sources for 2 RX antennas. This is not an inherent feature of the PlutoSDR, which I am using.
I came across this repo while I was stumbling around for possible solutions, and have been curious about its precise sample alignment in SDR implementations through internal FPGA clock ticks counting, which might potentially provide the compatibility I am seeking.
For clarity, I am conducting this project responsibly within a controlled environment (utilizing a Faraday cage) to ensure compliance with relevant licensing and regulations.
I am seeking your insights on the following:
I appreciate you reading through this! Your input will be invaluable to my project.
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions