-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing Uplink Decoding #57
Comments
Hi, could you share your experiment setup? I have not been successful in using PPS reference signal for synchronizing multiple USRPs. Did you change some code of LTESniffer to make it work? Based on my experiments before, using PPS seems to have bad sync. |
Hi @hdtuanss, I will happily share my setup. I have two B205mini USRPs taking a PPS reference from a GPS evaluation kit (just the easiest precision time pulse I have available). I am using UHD 4.6.0 with b2xx_b205mini_fpga_default (from I did make some code changes to LTESniffer: LTESniffer Diff 1
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 5ec2d0d..6afe713 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -188,6 +188,10 @@ else(SRSRAN_FOUND AND NOT FORCE_SUBPROJECT_SRSRAN)
# let the compiler find included files from subdirectories
include_directories(".")
+ file(COPY "${CMAKE_BINARY_DIR}/srsRAN-src/lib/src/phy/rf/"
+ DESTINATION "${CMAKE_BINARY_DIR}/srsRAN-src/lib/include/srsran/phy/rf"
+ FILES_MATCHING PATTERN "rf_uhd_*.h")
+
# Add srsRAN directly to our build.
add_subdirectory("${CMAKE_BINARY_DIR}/srsRAN-src"
"${CMAKE_BINARY_DIR}/srsRAN-build") LTESniffer Diff 2
I also made additions to your multi-usrp fork of srsRAN: srsRAN Diff 1
srsRAN Diff 2
srsRAN Diff 3
srsRAN Diff 4
My changes to your multi-usrp fork of srsRAN kind of break API boundaries so some other hacks (a copy directive in CMakeLists.txt and an include in LTESniffer_core.cc - seen in LTESniffer diffs 1 and 2 above) are required to compile. For this same reason, I decided not to share these changes to GitHub. I would be happy to push branches with these code changes if that is desired. |
Hi, |
Hi @hdtuanss thanks for getting back. Could you please share info about your setup when you attempted PPS synchronization? More specifically, what USRPs did you attempt with? I am curious if you had similar issues with a different model of USRP. |
After thinking about this problem more, I decided it might be useful to provide some additional information. With the aforementioned PPS-synchronized dual-USRP setup, I have attempted some different eNB/UE combinations. This table shows PUSCH decoding reliability of LTESniffer with each combination of eNB and UE implementation. The sniffer was placed close to the eNB in each case to mitigate propagation delay.
Many different physical layer configurations were tested for both eNB implementations. I believe this is a partial validation of the PPS-synchronized setup. |
Hi, |
Hi @hdtuanss thanks for getting back again. This project is of high importance to me. I am in the position to offer compensation in return for improvements to decoding reliability and 4-port cell support in general. I will send you an email to continue this discussion. If anyone else reading this is interested in the contract offer, please email me at [email protected]. |
Hello again! For context, this post serves as a continuation of a previous one where I was attempting uplink decoding using a pair of USRP B205minis w/ a PPS for time alignment. That thread ended with a discussion about the limitation of the underlying srsRAN library to 1 and 2 port cells.
I have recently found a 2-port eNB (10 MHz bandwidth) that my COTS phones will connect to. I placed the sniffer in an area with good signal quality (>20 SNR). With a phone ~1 meter from the USRPs, I switched airplane mode on and off several times. Upon switching airplane mode off, the RACH and RRC Connection Setup can be seen, but no further results are present.
The following text shows 5 instances of switching airplane mode from a run with arguments
... -m 1 -z 3 -d
. It was generated by filtering LTESniffer output with the commandgrep -v Paging <sniffer output file> | grep -A 10 PRACH
.I expected further messages to be decoded (e.g., Attach Request). I was also surprised to see such variance in SNR for any one RNTI, and this appears to affect decoding reliability.
Thanks in advance!
The text was updated successfully, but these errors were encountered: