Has anyone tried the LibreCellular / LMS version of srsRAN with the LimeSDR Mini v2?
I’ve been using a LimeSDR-USB with it for some time now, which has been working flawlessly.
Swapping out the LimeSDR-USB for the new LimeSDR-Mini v2 performance is exactly the same for 20 minutes (as measured with iperf between the UE and eNodeB. Connected directly via cables the UE is able to download at 75Mbit/s and upload at 50Mbit/s as expected).
After 20 mins of iperf the UE is disconnected with a stream of device connections and disconnections appearing on srsran enb’s console.
Restarting the modem doesn’t appear to help however restarting srsran enb gives you another 20 mins before the same thing happens.
The problem seems to be repeatable, I’ve just tried 3 times back to back with the Mini 2 and experienced 3 failures.
Repeated the same with the original LimeSDR-USB and no issues given the same 3 x 20 minute runs.
Interesting, thanks for sharing! My first thought was possible overheating, but if you can simply restart srsENB and then get another 20 minutes, it suggests something quite different.
Building up a LimeSDR Mini v2 base station for the LibreCellular CI platform is on the roadmap, but will also discuss with colleagues.
I wondered if you were able to time a few runs, so we could confirm if it’s after some precise amount of time has elapsed.
Have thought if it could be related to sample timestamp FPGA implementation with Mini v2, but then I think it has been used fine with other cellular stacks. The other thing that occurred to me is whether the optimal time_adv_nsamples value could be different for Mini v2. I don’t know enough about this and whether it is more RFIC specific, or switching from one vendor FPGA to another could affect the delay time. From what I gather the value is found by trial and error!
Happy giving some more timings a go. Was proving a bit tricky, given having to start the enodeb, connect the modem which can take a while. Then fiddle with routing and kick off iperf.
I’ll give it a few more goes tonight and start a timer from when the enodeb is running.
I’ve currently got the timing advance set to your suggested value for the original mini. I would have expected that sort of timing error to occur randomly. This problem certainly seems to occur within a small window. My first thought was a timer misbehaving.
I’ll give my two cents here, but bear in mind I know very little about the complete software stack so I might be completely wrong.
These are things I’ve seen in my own project which also deals with time synchronization, so they may or may not apply here.
The packet timestamp basically reduces to a sample counter in the FPGA I think. An integer overflow somewhere might generate such issues (I have a change request on gr-limesdr for such a problem). But this seems unlikely here, At the sort of sample rates required (I assumed 20 Msps) I did some quick calculations and the issue would show up a lot sooner, in a matter of a hundred seconds or so for a 32 bit overflow. And after it overflowed it would probably no longer allow you to attach even briefly at all.
The second thing that comes to mind is the samples arriving after the timestamp expired, leading to dropped sample packets. This could be more likely here, but I have no insight into what might cause it after exactly 20 minutes.
In gr-limesdr, the function LMS_GetStreamStatus is used periodically to determine and output to console the stream status and the lms_stream_status_t struct has a number of interesting members, including droppedPackets, underrun and overrun. This could be used to potentially debug the issue.
I’ll just add that I’m also interested in the cause of the behaviour you observed.
I am running LimeSDR Mini v2 for 7 hours continuously today in the background. I am using LimeSuiteGUI to stream the data using timestamp synchronization. No problems whatsoever. So the problem should be at the upper software layers. At the LimeSuite layer I see no problems.
