[srsran-users] Send Sounding Reference Signal with srsLTE
Francisco Paisana
francisco.paisana at srs.io
Sun Apr 2 20:59:02 UTC 2023
Hey,
Unfortunately, the eNB doesnt support SRS.
Regards,
Francisco
On Mon, Mar 27, 2023 at 10:27 AM Antonio Albanese <
antonioalbanese15 at gmail.com> wrote:
> Hey Alessio,
>
> try your luck with the mailing list archive
> https://lists.srsran.com/pipermail/srsran-users/
>
> I remember someone asking about this a while back. For instance,
> https://lists.srsran.com/mailman/search?query=sounding&submit=Search%21&idxname=srsran-users&max=20&result=normal&sort=score
> .
>
> Cheers,
> Antonio
>
>
>
>
>
> ᐧ
>
> On Fri, 24 Mar 2023 at 19:18, Alessio Scalingi <alessio.scalingi at imdea.org>
> wrote:
>
>> Hi all,
>>
>> Repost this from an open issue. I am trying to enable the UE to send the
>> SRS. But I can't find any guide or information about how to do that.
>>
>> I have seen into the lib/src/phy/ch_estimate.cc module that there is a
>> function to estimate the srs signal (when it is received), but I don't know
>> how to enable it from the eNB.
>> Looking at the configuration files, enb.conf, ue.conf, rr.conf I can't
>> find any reference, so I don't know how to proceed.
>>
>> Does anyone has already worked with it? I appreciate if someone can help
>> me to deal with that. We can update the issue on git such that other people
>> can face the same issue.(https://github.com/srsran/srsRAN_4G/issues/1126)
>>
>> Best,
>> *Alessio Scalingi
>> *
>> *PhD Student*
>> IMDEA Networks Institute
>>
>> E-mail: alessio.scalingi at imdea.org <alessio.scalingi at imdea.org>
>> Phone: +34 623 067 475
>> Address: Av. Del Mar Mediterraneo, 22, 28918, Leganés, Madrid, Spain
>>
>> *This message may contain confidential or privileged information. If you
>> have received it in error, please do not use it, notify the sender and
>> delete it. See legal notice
>> <https://networks.imdea.org/legal-notice-email/>. Este mensaje puede
>> contener información confidencial o privilegiada. Si le ha llegado por
>> error, rogamos no haga uso del mismo, avise al remitente y bórrelo.
>> Consulte aviso legal
>> <https://networks.imdea.org/es/aviso-legal-correo-electronico/>.*
>>
>>
>>
>> Il giorno 24 mar 2023, alle ore 4:23 PM, Antonio Albanese <
>> antonioalbanese15 at gmail.com> ha scritto:
>>
>> Hey guys,
>>
>> a bit of a particular question for those of you who have experimented
>> with srsRAN and docker.
>>
>> I built a docker image for srsRAN 21.10 based on Ubuntu 20.04. I am aware
>> that this is not the latest srsRAN release but it should be unrelated to my
>> issue, I hope!
>>
>> I am experiencing a weird behavior, particularly with srsue. I am using a
>> bladerf 2.0 xA4, which comes with its own problems with srsue (see the open
>> issue on the Nuand github about the board easily getting stuck when
>> changing sampling rate). Nonetheless, I managed to have a working srsRAN
>> image for srsepc, srsenb and srsue.
>>
>> I can run it using docker-compose with docker-compose up srsue with *no
>> problem*. However, whenever I call it from Python with
>>
>> import subprocess
>> cmd = "docker-compose up --detach srsue"
>> p = subprocess.Popen(cmd, cwd=paths["docker"], shell=True)
>>
>> srsue never tries to attach. I had this in the past and it all boiled
>> down to srsue failing to lock synchronization with PSS and SSS. I have not
>> looked into the logs and the PCAPs yet, just because it is a little more
>> cumbersome to extract them from a container but I will. Anyway, I would not
>> know what to do if they confirmed my assumption.
>>
>> To make matters worse, I can run the container in terminal with the CPU
>> governor in power save mode while I cannot run it from Python even in
>> performance mode.
>>
>> I wonder how Python is increasing the overhead on the container here or
>> even if the problem is Python or something else altogether!
>> Please note that I also tried with stdout=subprocess.PIPE,
>> stderr=subprocess.PIPE reading the console output using p.stdout.readline
>> for that matter.
>>
>> Lastly, something else that I found quite interesting (I let you imagine
>> how long it took to figure this out). The container would not work using
>> Ubuntu 22.04 as base and I had to downgrade it to 20.04 to have it stable.
>> This happens also at host level, meaning that I have a clean installation
>> of Ubuntu 22.04 that would not run srsue on bare metal but it would in a
>> container using Ubuntu 20.04 as base (in fact, Ubuntu 20.04 host would run
>> srsue on bare metal too). The same Ubuntu 22.04 is the host I use when I
>> call the container from Python, maybe this somehow affects things?
>>
>> I will keep troubleshooting the problem. Meanwhile, has anyone had any
>> similar experience and would like to share any hints?
>> Thank you very much!
>>
>> Cheers,
>> Antonio
>>
>>
>>
>>
>>
>>
>> ᐧ
>> _______________________________________________
>> srsran-users mailing list
>> srsran-users at lists.srsran.com
>> https://lists.srsran.com/mailman/listinfo/srsran-users
>>
>>
>> _______________________________________________
>> srsran-users mailing list
>> srsran-users at lists.srsran.com
>> https://lists.srsran.com/mailman/listinfo/srsran-users
>>
> _______________________________________________
> srsran-users mailing list
> srsran-users at lists.srsran.com
> https://lists.srsran.com/mailman/listinfo/srsran-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20230402/7a5d6079/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Immagineallegata-1.tiff
Type: image/tiff
Size: 22252 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20230402/7a5d6079/attachment-0001.tiff>
More information about the srsran-users
mailing list