Hi,
I have just received a limesdr mini, and I am trying to get that sdr to the same level as I had with
uhd B100. I managed to get the whole config working properly, but stability was bad, as you have read.
As I was recommended, I have been runnig "nightly" binaries, and see where I end up.... :-)
limesdr installed in Orange Pi Zero, (armhf). Limesuite 18.10.0-1, LimeUtil seems happy, and I can see the SDR
However, I cannot get stability enough to get a stable signal....
Gullik
TRX LIME CONFIG
log stderr logging filter all 1 logging color 1 logging print category 1 logging timestamp 1 logging print file basename logging level set-all info ! line vty no login ! trx bind-ip 127.0.0.1 remote-ip 127.0.0.1 base-port 5700 egprs disable tx-sps 4 rx-sps 4 rt-prio 18 chan 0 tx-path BAND1 rx-path LNAW
bsc 1.3.0.287 or .284 will not run, fails with error in sysmalloc(), so I try running .283, from dec 19....
maybe this problem is armhf related...??
this is the bsc config......
osmobsc config file
! osmo-bsc default configuration ! (assumes STP to run on 127.0.0.1 and uses default point codes) ! e1_input e1_line 0 driver ipa network network country code 1 mobile network code 1 encryption a5 0 neci 1 paging any use tch 0 handover 0 handover algorithm 1 handover1 window rxlev averaging 10 handover1 window rxqual averaging 1 handover1 window rxlev neighbor averaging 10 handover1 power budget interval 6 handover1 power budget hysteresis 3 handover1 maximum distance 9999 dyn_ts_allow_tch_f 0 periodic location update 30 bts 0 type sysmobts band DCS1800 cell_identity 0 location_area_code 1 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 early-classmark-sending forbidden ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 codec-support fr gprs mode none trx 0 rf_locked 0 arfcn 871 nominal power 20 ! to use full TRX power, set max_power_red 0 max_power_red 3 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 msc 0 no bsc-welcome-text no bsc-msc-lost-text no bsc-grace-text type normal allow-emergency allow amr-config 12_2k forbidden amr-config 10_2k forbidden amr-config 7_95k forbidden amr-config 7_40k forbidden amr-config 6_70k forbidden amr-config 5_90k allowed amr-config 5_15k forbidden amr-config 4_75k forbidden codec-list fr1 fr2 fr3 hr1 hr3 mgw remote-ip 127.0.0.1 mgw remote-port 2427 mgw local-port 2727 mgw endpoint-range 1 31 bsc mid-call-timeout 0 no missing-msc-text
bsc does not seem to want to speak with trx-lms, I don't understand which config entry is wrong....
osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 871 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 <0007> a_reset.c:106 A-RESET(msc-0)[0xdb2e98]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> osmo_bsc_bssap.c:58 RESET ACK from MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> a_reset.c:74 A-RESET(msc-0)[0xdb2e98]{DISC}: SIGTRAN connection succeded. <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-0-CCCH_SDCCH4)[0xddfcd8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-1-TCH_F)[0xde0038]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-2-TCH_F)[0xde0398]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-3-TCH_F)[0xde06f8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-4-TCH_F)[0xde0a58]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-5-TCH_F)[0xde0db8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-6-TCH_F)[0xde1118]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-7-TCH_F)[0xde1478]{UNUSED}: Event TS_EV_OML_READY not permitted <0015> input/ipaccess.c:248 Sign link vanished, dead socket <0015> input/ipaccess.c:74 Forcing socket shutdown with no signal link set <0015> bts_ipaccess_nanobts.c:416 (bts=0) Dropping OML link. <0015> bts_ipaccess_nanobts.c:397 (bts=0,trx=0) Dropping RSL link. <0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002 <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix.
So, has anyone config files for Limesdr mini -> trx-lms -> osmo-bts-trx_0.8.1.199 -> osmo-msc or can point me in the
right direction....
Gullik
Try this : https://osmocom.org/attachments/3389/config%20osmo-splits.tar.gz
On Sat, Jan 5, 2019 at 12:56 AM Gullik Webjorn gullik.webjorn@corevalue.se wrote:
Hi,
I have just received a limesdr mini, and I am trying to get that sdr to the same level as I had with
uhd B100. I managed to get the whole config working properly, but stability was bad, as you have read.
As I was recommended, I have been runnig "nightly" binaries, and see where I end up.... :-)
limesdr installed in Orange Pi Zero, (armhf). Limesuite 18.10.0-1, LimeUtil seems happy, and I can see the SDR
However, I cannot get stability enough to get a stable signal....
Gullik
TRX LIME CONFIG
log stderr logging filter all 1 logging color 1 logging print category 1 logging timestamp 1 logging print file basename logging level set-all info ! line vty no login ! trx bind-ip 127.0.0.1 remote-ip 127.0.0.1 base-port 5700 egprs disable tx-sps 4 rx-sps 4 rt-prio 18 chan 0 tx-path BAND1 rx-path LNAW
bsc 1.3.0.287 or .284 will not run, fails with error in sysmalloc(), so I try running .283, from dec 19....
maybe this problem is armhf related...??
this is the bsc config......
osmobsc config file
! osmo-bsc default configuration ! (assumes STP to run on 127.0.0.1 and uses default point codes) ! e1_input e1_line 0 driver ipa network network country code 1 mobile network code 1 encryption a5 0 neci 1 paging any use tch 0 handover 0 handover algorithm 1 handover1 window rxlev averaging 10 handover1 window rxqual averaging 1 handover1 window rxlev neighbor averaging 10 handover1 power budget interval 6 handover1 power budget hysteresis 3 handover1 maximum distance 9999 dyn_ts_allow_tch_f 0 periodic location update 30 bts 0 type sysmobts band DCS1800 cell_identity 0 location_area_code 1 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 early-classmark-sending forbidden ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 codec-support fr gprs mode none trx 0 rf_locked 0 arfcn 871 nominal power 20 ! to use full TRX power, set max_power_red 0 max_power_red 3 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 msc 0 no bsc-welcome-text no bsc-msc-lost-text no bsc-grace-text type normal allow-emergency allow amr-config 12_2k forbidden amr-config 10_2k forbidden amr-config 7_95k forbidden amr-config 7_40k forbidden amr-config 6_70k forbidden amr-config 5_90k allowed amr-config 5_15k forbidden amr-config 4_75k forbidden codec-list fr1 fr2 fr3 hr1 hr3 mgw remote-ip 127.0.0.1 mgw remote-port 2427 mgw local-port 2727 mgw endpoint-range 1 31 bsc mid-call-timeout 0 no missing-msc-text
bsc does not seem to want to speak with trx-lms, I don't understand which config entry is wrong....
osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 871 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 <0007> a_reset.c:106 A-RESET(msc-0)[0xdb2e98]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> osmo_bsc_bssap.c:58 RESET ACK from MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <0007> a_reset.c:74 A-RESET(msc-0)[0xdb2e98]{DISC}: SIGTRAN connection succeded. <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-0-CCCH_SDCCH4)[0xddfcd8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-1-TCH_F)[0xde0038]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-2-TCH_F)[0xde0398]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-3-TCH_F)[0xde06f8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-4-TCH_F)[0xde0a58]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-5-TCH_F)[0xde0db8]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-6-TCH_F)[0xde1118]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-7-TCH_F)[0xde1478]{UNUSED}: Event TS_EV_OML_READY not permitted <0015> input/ipaccess.c:248 Sign link vanished, dead socket <0015> input/ipaccess.c:74 Forcing socket shutdown with no signal link set <0015> bts_ipaccess_nanobts.c:416 (bts=0) Dropping OML link. <0015> bts_ipaccess_nanobts.c:397 (bts=0,trx=0) Dropping RSL link. <0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002 <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix.
So, has anyone config files for Limesdr mini -> trx-lms -> osmo-bts-trx_0.8.1.199 -> osmo-msc or can point me in the
right direction....
Gullik
This is the sequence of events that preceedes a failure in osmo-trx-lime. Before this event everything looks
normal, and sometimes I can see the messages relating to phones selecting this bts. But, then I get many hundreds
of fail messages, overfilling the terminal buffer.
I managed to catch ONE event, it follows....at 17:53:26......
Fri Jan 4 17:53:22 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2012824 Fri Jan 4 17:53:23 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013041 Fri Jan 4 17:53:24 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013257 Fri Jan 4 17:53:25 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013474 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331871c got 3318b18 (3318b18) diff=3fc Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 33190e0 got 3320c64 (3320c64) diff=7b84 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 3319aa4 got 3321628 (3321628) diff=7b84 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331a468 got 3321fec (3321fec) diff=7b84 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331ae2c got 33229b0 (33229b0) di
after this, possibly 30 seconds later ?? the BTS restarts ?? and the trx synchronizes up, config is done, and log starts logging IND CLOCK every second...
then this same event happens.....and we have a loop.....
This is on an orange PI Zero, arm, so maybe not visible on your platforms.....
Gullik
Hi Gullik, you might have same issued as here https://osmocom.org/issues/3339
On Sat, Jan 5, 2019 at 2:59 AM Gullik Webjorn gullik.webjorn@corevalue.se wrote:
This is the sequence of events that preceedes a failure in osmo-trx-lime. Before this event everything looks
normal, and sometimes I can see the messages relating to phones selecting this bts. But, then I get many hundreds
of fail messages, overfilling the terminal buffer.
I managed to catch ONE event, it follows....at 17:53:26......
Fri Jan 4 17:53:22 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2012824 Fri Jan 4 17:53:23 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013041 Fri Jan 4 17:53:24 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013257 Fri Jan 4 17:53:25 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3043908688] ClockInterface: sending IND CLOCK 2013474 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331871c got 3318b18 (3318b18) diff=3fc Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 33190e0 got 3320c64 (3320c64) diff=7b84 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 3319aa4 got 3321628 (3321628) diff=7b84 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331a468 got 3321fec (3321fec) diff=7b84 Fri Jan 4 17:53:26 2019 DDEV <0002> LMSDevice.cpp:600 [tid=3043908688] chan 0 recv buffer of len 2500 expect 331ae2c got 33229b0 (33229b0) di
after this, possibly 30 seconds later ?? the BTS restarts ?? and the trx synchronizes up, config is done, and log starts logging IND CLOCK every second...
then this same event happens.....and we have a loop.....
This is on an orange PI Zero, arm, so maybe not visible on your platforms.....
Gullik
Yes, I just spotted that bug report #3339, and one thing that is similar to
a completely other system is the USB2 vs USB3, which is the only type available on the Opi Z.
Regards,
Gullik
Watching a phone, the phone associates with the BTS, after about 15-25 seconds the strength indicator
shrinks, and after 30 seconds, the Operator Logo disappears , and the phone diplays "select operator".
After 30-60 seconds, the signal indicator again shows full scale + operator, then slowly goes down to zero and
repeat.....
Could this indicate some dependency on the power regulation loop ?
Gullik
On 2019-01-04 21:29, Gullik Webjorn wrote:
Yes, I just spotted that bug report #3339, and one thing that is similar to
a completely other system is the USB2 vs USB3, which is the only type available on the Opi Z.
Regards,
Gullik
And after a fairly long time the trx exits. Restarting it, everything goes back to the
OK, bug 3339 cycle once per minute approx.
Any suggestions on how I could help identifying the problem?
Gullik
On 2019-01-04 21:53, Gullik Webjorn wrote:
Watching a phone, the phone associates with the BTS, after about 15-25 seconds the strength indicator
shrinks, and after 30 seconds, the Operator Logo disappears , and the phone diplays "select operator".
After 30-60 seconds, the signal indicator again shows full scale + operator, then slowly goes down to zero and
repeat.....
Could this indicate some dependency on the power regulation loop ?
Gullik
On 2019-01-04 21:29, Gullik Webjorn wrote:
Yes, I just spotted that bug report #3339, and one thing that is similar to
a completely other system is the USB2 vs USB3, which is the only type available on the Opi Z.
Regards,
Gullik
I have found an interesting log entry, I cannot see where it is called...
Sat Jan 5 11:58:42 2019 DDEV <0002> LMSDevice.cpp:386 [tid=3070102608] chan 0: Setting TX gain to 73 dB Sat Jan 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L Sat Jan 5 11:58:42 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3012840528] ClockInterface: sending IND CLOCK 920402
the message of a single L seems a little cryptic, and I have not found it's origin......
Gullik
Well, we just have to find out what is happening. I have currently built the trx-lms from source, so
once I can figure out how to build with debug....without breaking everything....
In the mean time:
<0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002 <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'CBCH' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech EFR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is unreported
Yes, it would be nice to fix, I imagine this is a configuration mismatch, where should these be set, and using what keywords?
This also indicates a problem, but I am to much a beginner to realize its importance.....
<0003> osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 871 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-0-CCCH_SDCCH4)[0xe641d0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-1-TCH_F)[0xe64530]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-2-TCH_F)[0xe64890]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-3-TCH_F)[0xe64bf0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-4-TCH_F)[0xe64f50]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-5-TCH_F)[0xe652b0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-6-TCH_F)[0xe65610]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-7-TCH_F)[0xe65970]{UNUSED}: Event TS_EV_OML_READY not permitted <0015> input/ipaccess.c:248 Sign link vanished, dead socket
Is it because BSC and BTS are out of sync over their A-if ? As a consequence of trx restart ??
Regards,
Gullik
On 2019-01-05 12:02, Gullik Webjorn wrote:
I have found an interesting log entry, I cannot see where it is called...
Sat Jan 5 11:58:42 2019 DDEV <0002> LMSDevice.cpp:386 [tid=3070102608] chan 0: Setting TX gain to 73 dB Sat Jan 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L Sat Jan 5 11:58:42 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3012840528] ClockInterface: sending IND CLOCK 920402
the message of a single L seems a little cryptic, and I have not found it's origin......
Gullik
Hello Gentlemen, ( and Ladies also of course )
Here is again a small Monologue from me, with an attempt to fix a bug....
My osmo-trx-lms is not stable, and I have reported it's strange behaviour.
Some things made me think of memory corruption, and when I found that one thread
was logging a single letter "L" suspicion increased....
I have rebuilt the debian package from source, and tried to have a look at the log message print,
but failed to place a breakpoint in LMSDevice.cpp:102 with meaningful result, typically gdb
could not retrieve general registers....again, memory corruption??
However, after numerous tries I managed to "continue" the correct number of times to hit exactly
the right instance of the breakpoint, without trx-lms giving up due to timeouts,
and here is a bt when this happens:
(gdb) bt #0 lms_log_callback (lvl=<optimized out>, msg=0xb415353c "L") at LMSDevice.cpp:102 #1 0xb6d0c6c8 in lime::log(lime::LogLevel, char const*, std::__va_list) () from /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 #2 0xb6d26b22 in ?? () from /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 #3 0xb6d299f6 in ?? () from /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 #4 0xb6c75a6a in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 #5 0xb6fab5e8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0 #6 0xb6aee4fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)
Last line: corrupt stack ??
Since I have had very little reaction, I deduce that most of you developers do NOT use my particular make of CPU,
so this might be related to the Armbian ( Debian 9 ) I am running on this particular hardware. I am using the armhf
variety of the source.
Next step for me is rebuilding LimeSuite from source to get debugging info, so that backtraces etc. become more meaningful.
The thinking here is that the subtle error in logging has a more general cause, and that memory corruption surely prevents
the program to operate stable and as intended....
Best Regards,
Gullik
On 2019-01-05 21:54, Gullik Webjorn wrote:
Well, we just have to find out what is happening. I have currently built the trx-lms from source, so
once I can figure out how to build with debug....without breaking everything....
In the mean time:
<0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002 <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'CBCH' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech EFR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is unreported
Yes, it would be nice to fix, I imagine this is a configuration mismatch, where should these be set, and using what keywords?
This also indicates a problem, but I am to much a beginner to realize its importance.....
<0003> osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 871 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-0-CCCH_SDCCH4)[0xe641d0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-1-TCH_F)[0xe64530]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-2-TCH_F)[0xe64890]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-3-TCH_F)[0xe64bf0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-4-TCH_F)[0xe64f50]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-5-TCH_F)[0xe652b0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-6-TCH_F)[0xe65610]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-7-TCH_F)[0xe65970]{UNUSED}: Event TS_EV_OML_READY not permitted <0015> input/ipaccess.c:248 Sign link vanished, dead socket
Is it because BSC and BTS are out of sync over their A-if ? As a consequence of trx restart ??
Regards,
Gullik
On 2019-01-05 12:02, Gullik Webjorn wrote:
I have found an interesting log entry, I cannot see where it is called...
Sat Jan 5 11:58:42 2019 DDEV <0002> LMSDevice.cpp:386 [tid=3070102608] chan 0: Setting TX gain to 73 dB Sat Jan 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L Sat Jan 5 11:58:42 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3012840528] ClockInterface: sending IND CLOCK 920402
the message of a single L seems a little cryptic, and I have not found it's origin......
Gullik
A small update from Sweden,
I have built LimeSuite and osmo-trx-lms from source, this time on a Intel Atom, i386 distribution.
I have redirected the bts - trx ip addresses, and yes, I could briefly see the beacon, and i managed
to get two phones on the network, though not stable.
However, I can see the exact behaviour of the osmo-trx-lms as on the armhf kit, i.e. the logging of
a single L like this...
Sat Jan 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L
I have not verified that the reason is exactly the same yet, since I don't have debug environment
on the 386 yet, but the symptom is exactly the same, with strange length packets and a lot of
packet flushing, all probably related to recovering synch.
This reduces the previously assumed probability that the problem lies in hardware or hardware related
software (armbian Linux) , but actually is a memory problem within osmo-trx (lms)
What is relatively easy is to move the B100 to the "new" platform, and try to isolate the problem
with regards to uhd device vs. lms device, so I will do that test and report back.
Regards,
Gullik
On 2019-01-06 16:30, Gullik Webjorn wrote:
Hello Gentlemen, ( and Ladies also of course )
Here is again a small Monologue from me, with an attempt to fix a bug....
My osmo-trx-lms is not stable, and I have reported it's strange behaviour.
Some things made me think of memory corruption, and when I found that one thread
was logging a single letter "L" suspicion increased....
I have rebuilt the debian package from source, and tried to have a look at the log message print,
but failed to place a breakpoint in LMSDevice.cpp:102 with meaningful result, typically gdb
could not retrieve general registers....again, memory corruption??
However, after numerous tries I managed to "continue" the correct number of times to hit exactly
the right instance of the breakpoint, without trx-lms giving up due to timeouts,
and here is a bt when this happens:
(gdb) bt #0 lms_log_callback (lvl=<optimized out>, msg=0xb415353c "L") at LMSDevice.cpp:102 #1 0xb6d0c6c8 in lime::log(lime::LogLevel, char const*, std::__va_list) () from /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 #2 0xb6d26b22 in ?? () from /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 #3 0xb6d299f6 in ?? () from /usr/lib/arm-linux-gnueabihf/libLimeSuite.so.18.10-1 #4 0xb6c75a6a in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 #5 0xb6fab5e8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0 #6 0xb6aee4fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)
Last line: corrupt stack ??
Since I have had very little reaction, I deduce that most of you developers do NOT use my particular make of CPU,
so this might be related to the Armbian ( Debian 9 ) I am running on this particular hardware. I am using the armhf
variety of the source.
Next step for me is rebuilding LimeSuite from source to get debugging info, so that backtraces etc. become more meaningful.
The thinking here is that the subtle error in logging has a more general cause, and that memory corruption surely prevents
the program to operate stable and as intended....
Best Regards,
Gullik
On 2019-01-05 21:54, Gullik Webjorn wrote:
Well, we just have to find out what is happening. I have currently built the trx-lms from source, so
once I can figure out how to build with debug....without breaking everything....
In the mean time:
<0015> input/ipa.c:262 accept()ed new link from 127.0.0.1 to port 3002 <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'CBCH' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech EFR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is unreported
Yes, it would be nice to fix, I imagine this is a configuration mismatch, where should these be set, and using what keywords?
This also indicates a problem, but I am to much a beginner to realize its importance.....
<0003> osmo_bsc_main.c:284 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 871 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63 <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-0-CCCH_SDCCH4)[0xe641d0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-1-TCH_F)[0xe64530]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-2-TCH_F)[0xe64890]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-3-TCH_F)[0xe64bf0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-4-TCH_F)[0xe64f50]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-5-TCH_F)[0xe652b0]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-6-TCH_F)[0xe65610]{UNUSED}: Event TS_EV_OML_READY not permitted <0011> bts_ipaccess_nanobts.c:315 timeslot(0-0-7-TCH_F)[0xe65970]{UNUSED}: Event TS_EV_OML_READY not permitted <0015> input/ipaccess.c:248 Sign link vanished, dead socket
Is it because BSC and BTS are out of sync over their A-if ? As a consequence of trx restart ??
Regards,
Gullik
On 2019-01-05 12:02, Gullik Webjorn wrote:
I have found an interesting log entry, I cannot see where it is called...
Sat Jan 5 11:58:42 2019 DDEV <0002> LMSDevice.cpp:386 [tid=3070102608] chan 0: Setting TX gain to 73 dB Sat Jan 5 11:58:42 2019 DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L Sat Jan 5 11:58:42 2019 DMAIN <0000> Transceiver.cpp:1039 [tid=3012840528] ClockInterface: sending IND CLOCK 920402
the message of a single L seems a little cryptic, and I have not found it's origin......
Gullik
Hello Gullik,
[...] managed to get two phones on the network, though not stable.
It's known issue that LimeSDR is not stable as a PHY for OsmoTRX. I wouldn't expect any miracles, trying it on different hardware, until the problem is investigated and the fix is merged.
[...] the message of a single L seems a little cryptic [...] DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L
AFAIK, this message comes from the LMS driver, and it means that you're sending TX samples too [L]ate. Most likely, your CPU is too slow. However, you can play with the real-time priority.
I've never seen such messages with LimeSDR though.
With best regards, Vadim Yanitskiy.
Thanks Vadim,
I just saw the code in Streamer.cpp, so my conclusions were wrong....
Interesting though is that a backtrace in the armhf version shows something the debugger thinks
is a corrupted stack :-)
OK, so this was a blind shot, I will try to concentrate on the "main" error, the inability to serve
the device data at proper rate and the problems with reading....
Regards,
Gullik
On 2019-01-07 20:36, Vadim Yanitskiy wrote:
Hello Gullik,
[...] managed to get two phones on the network, though not stable.
It's known issue that LimeSDR is not stable as a PHY for OsmoTRX. I wouldn't expect any miracles, trying it on different hardware, until the problem is investigated and the fix is merged.
[...] the message of a single L seems a little cryptic [...] DLMS <0003> LMSDevice.cpp:102 [tid=3021294672] L
AFAIK, this message comes from the LMS driver, and it means that you're sending TX samples too [L]ate. Most likely, your CPU is too slow. However, you can play with the real-time priority.
I've never seen such messages with LimeSDR though.
With best regards, Vadim Yanitskiy.
-
Gullik Webjorn -
Sandi Suhendro -
Vadim Yanitskiy