Open smunaut opened 2 years ago
Hey @smunaut,
thanks for the report. Do you mind sharing the full UE logs as well, and maybe also the PCAP if you have? You definitely have lates there so this might explain the disconnect. In theory it shouldn't harm, but also give it a try without anylogs (or only to warning) and without PCAP.
/home/tnt/data/lte/srsLTE/lib/src/phy/mimo/precoding.c:1221: Error predecoding CCD: Invalid combination of ports 2 and rx antennax 1 /home/tnt/data/lte/srsLTE/lib/src/phy/phch/pdsch.c:880: Error predecoding
This is probably because the eNB tries to use a higher transmission mode that requires more Rx antennas. Note that the b205 only has one and actually the LTE standard requires 2. Have a look maybe you can select the TM in the configs for the cell?
Hi @andrepuschmann So I have just re-ran a bunch of test with the release_22_10
.
With the B205mini, it now seems to work fairly reliably. Connection works vast majority of the time, I was able to run iperf
and ping
for > 10 min. So I'm pretty happy with the performance there.
With the B210 however, I can't get those results.
Same exact config as with the B205mini (just unplug one and plug the other). Also tried several USB ports (on different controllers), several USB cables, tried different device_args
, I tried with the B210 on external power or with USB power, nothing works.
The majority of the time, it connects fine, but then after a coupe of seconds, there is a RF status: O=0, U=1, L=0
message and then nothing. And it takes a reload of the B210 to even get it to work again at all.
The B205mini and B210 are similar devices but there are definitely some differences (B205mini is actually closer to a B200 ...), including some buffer sizes. So this could explain why the B210 sometime has a over/under-run, but still I'd expect it to recover. Not sure if the B205mini would recover since it just doesn't happen with it.
Does it work for you with a B210 ? With what UHD version ?
Here are the log of a typical failed run with the B210 :
Mhh, good question. Yeah, I guess the underflow could be the culprit. I also noticed this in the log:
2022-12-05T15:51:10.070588 [PHY_LIB] [E] [ 6106] Error receiving samples
2022-12-05T15:51:10.070589 [PHY ] [E] [ 6105] SYNC: Receiving from radio.
That really looks like the B210 is gone out of a sudden.
I noticed that the CFO of that B210 is quite high (Found Cell: Mode=FDD, PCI=480, PRB=50, Ports=2, CP=Normal, CFO=6.9 KHz
). The PHY will measure and correct up to half subcarrier spacing, so 7.5kHz. However, maybe give it a try to shift it manually and see if that helps. Also compare with the b200 you have. Sometimes different batches are sooo far off from each other.
Regarding UHD, we also use 3.15 LTS in the CI. But also there its not a 100% stable either.
Issue Description
I run srsUE 22.04.01 (
ce8a3cae171f08c9bce83ae3611e56f2d168d073
) and I can't get the connection to be stable / last for more than a few seconds.Setup Details
Code running on Ubuntu 20.04 on a Ryzen 3700X. Process started with nice -20 priority, scheduling governor set to 'performance'. USRP B205mini running latest 3.15 LTS UHD (tried latest 4.x, same results. Also tried a B210 with same results. Tried different USB3 cables, different USB ports and also running the B210 on external power).
Remote cell is a RBS6402 that's right next to the USRP with Open5GS stack. The whole network side is running on other machines.
The options I changed compared to the example configs :
rf.rxgain = 30
&rf.txgain = 75
rat.eutra.dl_earfcn
set to the RBS cellusim.*
to setup a virtual sim cardlog.all_leve = info
( Also tried to leave it on warning or no logs to see if this was causing delay / issues, didn't change result )device_args
: Tried a bunch of combinations, including the two in the examples. It does change some of the messages of what happens exactly but no combination yield anythng stable. It always connects just fine within a few seconds of starting srsUE, ping works for 1-2 second then nothing ever again until restart.I also have a ping continuously running that should keep the channel active.
Expected Behavior
Ideally it should connect to the cell and keep the connection active indefinitely.
Actual Behaviour
See logs below.
It always finds the cell and initially connects very quickly and reliably, but then fails almost as quickly and never recovers.
Steps to reproduce the problem
See above
Additional Information
Well the log files can be hundreds of Megabytes so I can search for something specific if you point to what I should be looking for .
Heres a typical output :