Bug #3341
openosmo-trx-lms RF Envelope FAIL on LimeSDR, but not on LimeSDR-mini
90%
Description
I'm observing a strange behavior when comparing the RF envelope of osmo-trx-lms on a LimeSDR and a LimeSDR-mini.
The LimeSDR-mini envelope is within spec. Specifically, the transmit power level is at full strength before the start of the next burst.
On the LimeSDR however, the next burst/timeslot starts too late, (or the slew rate is too low?):
This is using the exact same versions of LimeSuite (f1e5444496923890ad7d030abef9c224c37c46cf) and osmo-trx (70621b74844a6ea08d6da5f5b1e1835b9af91771). All I'm doing is swapping the hardware and re-starting osmo-trx-lms and osmo-bts.
It's very odd, and I currently have no clue of what might be going on here.
Files
Related issues
Updated by laforge over 5 years ago
- Related to Feature #2919: Native LimeSDR support added
Updated by laforge over 5 years ago
- Assignee set to roh
roh: please re-perform the LimeSDR (non-mini) tests using a LimeSDR that is clocked from the 10MHz reference of the E4406.
Please also try to modify the ts_offset found in the following line of the source code in osmo-trx/Transceiver52M/device/lms/LMSDevice.cpp:
ts_offset = static_cast<TIMESTAMP>(8.9e-5 * GSMRATE * tx_sps); /* time * sample_rate */
Updated by roh over 5 years ago
- File limesdr_usb_871.png limesdr_usb_871.png added
- % Done changed from 0 to 10
still debugging on a full limesdr usb. using todays nighly builds.
i am using this config:
log stderr logging filter all 1 logging color 1 logging print category 1 logging timestamp 1 logging print file basename logging level all info logging level main notice logging level lms notice logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice logging level lmgcp notice logging level ljibuf notice ! stats interval 5 ! line vty no login ! trx bind-ip 127.0.0.1 remote-ip 127.0.0.1 rx-sps 4 clock-ref external multi-arfcn disable swap-channels disable egprs disable rt-prio 18 chan 0 rx-path LNAW tx-path BAND1
i've seen it crash once' but sadly i dont have a complete log: (the intention was to find the "Setting External clock reference" line.
/usr/bin/osmo-trx-lms -C /etc/osmocom/osmo-trx-lms.cfg 2>&1 |grep -i ref
Reference............... 1
Fri Aug 17 19:09:30 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] Estimated reference clock 30.6588 MHz
Fri Aug 17 19:09:30 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] Reference clock 30.72 MHz
Fri Aug 17 19:09:31 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] VCO 5000.00 MHz, RefClk 30.72 MHz
Fri Aug 17 19:09:31 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] VCO 4800.00 MHz, RefClk 30.72 MHz
Fri Aug 17 19:09:31 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] VCO 2400.00 MHz, RefClk 30.72 MHz
Fri Aug 17 19:09:31 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] VCO 2400.00 MHz, RefClk 30.72 MHz
Fri Aug 17 19:09:31 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] VCO 2218.67 MHz, RefClk 30.72 MHz
Fri Aug 17 19:09:31 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] VCO 2218.67 MHz, RefClk 30.72 MHz
Fri Aug 17 19:09:31 2018 DMAIN <0000> LMSDevice.cpp:158 [tid=139746895380288] Setting External clock reference to 1e+07
Fri Aug 17 19:09:32 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] MCU Ref. clock: 30.72 MHz
Fri Aug 17 19:09:32 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] VCO 2334.72 MHz, RefClk 30.72 MHz
Fri Aug 17 19:09:32 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] MCU Ref. clock: 30.72 MHz
Fri Aug 17 19:09:32 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895380288] VCO 2334.72 MHz, RefClk 30.72 MHz
Fri Aug 17 19:09:34 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895599360] VCO 7128.00 MHz, RefClk 30.72 MHz
Fri Aug 17 19:09:34 2018 DLMS <0001> LMSDevice.cpp:74 [tid=139746895599360] VCO 7508.00 MHz, RefClk 30.72 MHz
telnet_connection contains 1 bytes in 1 blocks (ref 0) 0x5620c10659c0
logging contains 2014 bytes in 7 blocks (ref 0) 0x5620c0ff86f0
struct trx_ctx contains 383 bytes in 5 blocks (ref 0) 0x5620c0ff7410
msgb contains 0 bytes in 1 blocks (ref 0) 0x5620c0ff73a0
telnet_connection contains 1 bytes in 1 blocks (ref 0) 0x5620c10659c0
logging contains 2014 bytes in 7 blocks (ref 0) 0x5620c0ff86f0
logging.c:1033 contains 937 bytes in 1 blocks (ref 0) 0x5620c1034cb0
logging.c:950 contains 196 bytes in 1 blocks (ref 0) 0x5620c1034b80
struct log_target contains 200 bytes in 2 blocks (ref 0) 0x5620c0ff8ae0
struct log_category contains 40 bytes in 1 blocks (ref 0) 0x5620c0ff8bf0
struct log_info contains 680 bytes in 2 blocks (ref 0) 0x5620c0ff8760
struct log_info_cat contains 640 bytes in 1 blocks (ref 0) 0x5620c0ff87f0
struct trx_ctx contains 383 bytes in 5 blocks (ref 0) 0x5620c0ff7410
BAND1 contains 6 bytes in 1 blocks (ref 0) 0x5620c1065eb0
LNAW contains 5 bytes in 1 blocks (ref 0) 0x5620c1065a30
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x5620c0ff7660
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x5620c0ff75e0
msgb contains 0 bytes in 1 blocks (ref 0) 0x5620c0ff73a0
so far i have not been able to get it running well enough so the 4406 will do a gmsk phase and frequency plot. pwr vs time screenshot below. most the time i cannot even get it to trigger properly.
the clock output on the limesdr seems to be disabled (no signal according to the scope)
even in the case of osmo-trx-lms continuing to run the rf signal isnt visible on the 4406 anymore after 3-5 minutes.
the output of osmo-trx-lms keeps printing this kind of information one line per second tho.
Fri Aug 17 19:25:22 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140577027438336] ClockInterface: sending IND CLOCK 1189661 Fri Aug 17 19:25:23 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140577027438336] ClockInterface: sending IND CLOCK 1189877 Fri Aug 17 19:25:24 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140577027438336] ClockInterface: sending IND CLOCK 1190094 Fri Aug 17 19:25:25 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140577027438336] ClockInterface: sending IND CLOCK 1190310 Fri Aug 17 19:25:26 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140577027438336] ClockInterface: sending IND CLOCK 1190527 Fri Aug 17 19:25:27 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140577027438336] ClockInterface: sending IND CLOCK 1190743
to get it working it is not enough to restart osmo-trx-lms. one has also to physically disconnect the limesdr-usb and reconnect it.
LimeQuickTest [ TESTING STARTED ] ->Start time: Fri Aug 17 19:32:53 2018 ->Device: LimeSDR-USB, media=USB 3.0, module=FX3, addr=1d50:6108, serial=0009060B00472227 Serial Number: 0009060B00472227 [ Clock Network Test ] ->FX3 GPIF clock test Test results: 28260; 32016; 35772 - PASSED ->Si5351C test CLK0: 17554 / 17554 - PASSED CLK1: 17554 / 17554 - PASSED CLK2: 17554 / 17554 - PASSED CLK3: 17554 / 17554 - PASSED CLK4: 17554 / 17554 - PASSED CLK5: 17554 / 17554 - PASSED CLK6: 17554 / 17554 - PASSED ->ADF4002 Test Result: 10 - PASSED ->VCTCXO test Results : 5112948 (min); 5113078 (max) - PASSED ->Clock Network Test PASSED [ FPGA EEPROM Test ] ->Read EEPROM ->Read data: 11 05 11 11 05 11 02 ->FPGA EEPROM Test PASSED [ LMS7002M Test ] ->Perform Registers Test ->External Reset line test Reg 0x20: Write value 0xFFFD, Read value 0xFFFD Reg 0x20: value after reset 0x0FFFF ->LMS7002M Test PASSED [ RF Loopback Test ] ->Configure LMS ->Run Tests (TX_2-> LNA_L): CH0 (SXR=800.0MHz, SXT=805.0MHz): Result:(-15.1 dBFS, 5.00 MHz) - PASSED CH1 (SXR=800.0MHz, SXT=805.0MHz): Result:(-17.1 dBFS, 5.00 MHz) - PASSED ->Run Tests (TX_1 -> LNA_W): CH0 (SXR=1800.0MHz, SXT=1805.0MHz): Result:(-19.2 dBFS, 5.00 MHz) - PASSED CH1 (SXR=1800.0MHz, SXT=1805.0MHz): Result:(-17.9 dBFS, 5.00 MHz) - PASSED ->Run Tests (TX_2-> LNA_H): CH0 (SXR=2500.0MHz, SXT=2505.0MHz): Result:(-16.7 dBFS, 5.00 MHz) - PASSED CH1 (SXR=2500.0MHz, SXT=2505.0MHz): Result:(-14.7 dBFS, 5.00 MHz) - PASSED ->RF Loopback Test PASSED => Board tests PASSED <= Elapsed time: 1.87 seconds
the installed limesuite is 18.06 from the debian nighly feeds (everything updated today)
the limesdr usb got updated by using 'LimeUtil --update' (also today)
version dumping in osmo-trx-lms seems still broken:
usr/bin/osmo-trx-lms -C /etc/osmocom/osmo-trx-lms.cfg -V Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU OsmoTRX version UNKNOWN
i will repeat these tests with limesdr-mini now.
Updated by roh over 5 years ago
limesdr mini seems not to accept the clock external command:
/usr/bin/osmo-trx-lms -C /etc/osmocom/osmo-trx-lms.cfg Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU Fri Aug 17 19:59:35 2018 DLGLOBAL <0002> telnet_interface.c:104 telnet at 127.0.0.1 4237 Fri Aug 17 19:59:35 2018 DLCTRL <0009> control_if.c:887 CTRL at 127.0.0.1 4236 Config Settings Log Level............... 1 Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM BTS Address......... 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ 0 Reference............... 1 C0 Filler Table......... 1 Multi-Carrier........... 0 Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 Tx Antennas............. 'BAND1' Rx Antennas............. 'LNAW' Setting SCHED_RR priority(18) Fri Aug 17 19:59:35 2018 DMAIN <0000> LMSDevice.cpp:49 [tid=140719660293952] creating LMS device... Fri Aug 17 19:59:35 2018 DMAIN <0000> LMSDevice.cpp:99 [tid=140719660293952] Opening LMS device.. Fri Aug 17 19:59:35 2018 DMAIN <0000> LMSDevice.cpp:105 [tid=140719660293952] Devices found: 1 Fri Aug 17 19:59:35 2018 DMAIN <0000> LMSDevice.cpp:115 [tid=140719660293952] Device [0]: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1D3C03216CC90D Fri Aug 17 19:59:35 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] Claimed Interface Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] Estimated reference clock 40.0015 MHz Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] Reference clock 40.00 MHz Fri Aug 17 19:59:36 2018 DMAIN <0000> LMSDevice.cpp:126 [tid=140719660293952] Init LMS device Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] INT 121, FRAC 0, DIV_LOCH 1, EN_DIV2_DIVPROG 0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCO 5000.00 MHz, RefClk 40.00 MHz Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] ICT_VCO: 180 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=64 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=96 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=112 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=120 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=124 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=126 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=127 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] Failed to lock Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=192 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=224 cmphl=2 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=240 cmphl=3 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=232 cmphl=3 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=228 cmphl=2 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=230 cmphl=3 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=229 cmphl=3 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] Failed to lock Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] cmphl=2 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCOL : csw=226 tune ok Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] ICT_VCO: 180 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] TuneVCO(SXT) - VCO too high Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCOM : csw=0 tune fail Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] ICT_VCO: 180 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] TuneVCO(SXT) - VCO too high Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCOH : csw=0 tune fail Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] Selected: VCOL Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] INT 116, FRAC 0, DIV_LOCH 1, EN_DIV2_DIVPROG 0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCO 4800.00 MHz, RefClk 40.00 MHz Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] ICT_VCO: 180 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=64 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=96 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=112 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=120 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=124 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=126 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=127 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] Failed to lock Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=192 cmphl=0 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=224 cmphl=3 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=208 cmphl=3 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=200 cmphl=2 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=204 cmphl=3 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=202 cmphl=3 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw=201 cmphl=2 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] CSW: lowest=198, highest=201, selected=199 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] cmphl=2 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCOL : csw=199 tune ok Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] ICT_VCO: 180 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] TuneVCO(SXR) - VCO too high Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCOM : csw=0 tune fail Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] ICT_VCO: 180 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] TuneVCO(SXR) - VCO too high Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCOH : csw=0 tune fail Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] Selected: VCOL Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] INT 57, FRAC 385875, DIV_OUTCH_CGEN 18 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCO 2334.72 MHz, RefClk 40.00 MHz Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw 155; interval [152, 159] Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] INT 57, FRAC 385875, DIV_OUTCH_CGEN 18 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCO 2334.72 MHz, RefClk 40.00 MHz Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw 155; interval [152, 159] Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] M=160, N=4, Fvco=614.400 MHz Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] M=160, N=4, Fvco=614.400 MHz Fri Aug 17 19:59:36 2018 DMAIN <0000> LMSDevice.cpp:85 [tid=140719660293952] Sample Rate: Min=100000 Max=3.072e+07 Step=0 Fri Aug 17 19:59:36 2018 DMAIN <0000> LMSDevice.cpp:136 [tid=140719660293952] Setting sample rate to 1.08333e+06 4 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] INT 54, FRAC 489335, DIV_OUTCH_CGEN 7 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCO 2218.67 MHz, RefClk 40.00 MHz Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw 129; interval [125, 133] Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] INT 54, FRAC 489335, DIV_OUTCH_CGEN 7 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] VCO 2218.67 MHz, RefClk 40.00 MHz Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] csw 129; interval [125, 133] Fri Aug 17 19:59:36 2018 DMAIN <0000> LMSDevice.cpp:142 [tid=140719660293952] Sample Rate: Host=1.08333e+06 RF=3.46667e+07 Fri Aug 17 19:59:36 2018 DMAIN <0000> LMSDevice.cpp:158 [tid=140719660293952] Setting External clock reference to 1e+07 Fri Aug 17 19:59:36 2018 DLMS <0001> LMSDevice.cpp:74 [tid=140719660293952] Command not supported Fri Aug 17 19:59:36 2018 DMAIN <0000> LMSDevice.cpp:205 [tid=140719660293952] Error in LMS open, closing: Command not supported Fri Aug 17 19:59:36 2018 DMAIN <0000> osmo-trx.cpp:453 [tid=140719660293952] Failed to create radio device Shutting down transceiver...
Updated by laforge over 5 years ago
roh wrote:
limesdr mini seems not to accept the clock external command:
[...]
Please file this as bug at https://github.com/myriadrf/LimeSuite/issues
Updated by roh over 5 years ago
it seems a limesdr mini behaves similar to a -usb after it 'stopped working' (no signal on rf) when one does comment the "clock-ref external" from the config.
commenting out the rx and tx path from the config does not change anything visible.
Updated by roh over 5 years ago
- File usrp_usb871_env.png usrp_usb871_env.png added
- File usrp_usb871_phase.png usrp_usb871_phase.png added
i did some comparison tests with a usrp and the same software builds used to generate the lms measurements. (just swapping osmo-trx-lms for osmo-trx-uhd)
the results seem flawless and pass the 4406.
versions used:
OsmoBTS version 0.8.1.37-2222
Osmo-PCU version 0.5.1.1-54af
OsmoTRX version UNKNOWN <- uhd
linux; GNU C++ version 6.3.0 20170221; Boost_106200; UHD_003.009.005-0-unknown
OsmoTRX version UNKNOWN <- lms
OsmoBSC version 1.3.0.34-0c877
OsmoGGSN version 1.2.2.9-ee44
OsmoMGW version 1.4.0.13.9a7c
OsmoSGSN version 1.3.0.32-c503f
OsmoSTP version 0.10.0.4-39fd
OsmoMSC version 1.2.0.46-381370
OsmoHLR version 0.2.1.47-1eb9
this install is about 1 week old and uses nightly images from out debian package feed.
my next experiment is to use a second system to downgrade the lms hardware to older gateware/firmware
Updated by roh over 5 years ago
- File limesdr_usb_871_lms1706_env.png added
- % Done changed from 10 to 20
i flashed firmware from http://downloads.myriadrf.org/project/limesuite/17.12/ to the limeSDR-USB by copying it to ~/.local/share/LimeSuite/images/17.12/ symlinking it to 18.06 and symlinking LimeSDR-USB_HW_1.4_r2.14.rbf to LimeSDR-USB_HW_1.4_r2.17.rbf (otherwise LimeUtil --update would not flash these files but the global installed ones from 18.06)
i reset the sdr (un- and replug) and redid the tests from last week.
results are basically the same. the signal slope is out of bounds, the 4406 has a hard time syncing at all on the bursts and i could not get it to trigger well enough for a phase plot.
shot attached.
it was stable for like 20 minutes and i actually saw a rollover on the clock indication output but now it failed with a device timeout.
....
Fri Aug 24 17:57:49 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140620449900288] ClockInterface: sending IND CLOCK 2613878
Fri Aug 24 17:57:50 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140620449900288] ClockInterface: sending IND CLOCK 2614095
Fri Aug 24 17:57:51 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140620449900288] ClockInterface: sending IND CLOCK 2614312
Fri Aug 24 17:57:51 2018 DMAIN <0000> LMSDevice.cpp:517 [tid=140620449900288] LMS: Device receive timed out
Fri Aug 24 17:57:51 2018 DMAIN <0000> radioInterface.cpp:319 [tid=140620449900288] Receive error 1620
Fri Aug 24 17:57:52 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140620449900288] chan 0 recv buffer of len 0 expect eef5b4c got 0 (0) diff=fffffffff110a4b4
Fri Aug 24 17:57:52 2018 DMAIN <0000> LMSDevice.cpp:517 [tid=140620449900288] LMS: Device receive timed out
Fri Aug 24 17:57:52 2018 DMAIN <0000> radioInterface.cpp:319 [tid=140620449900288] Receive error 0
Fri Aug 24 17:57:52 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140620449900288] chan 0 recv buffer of len 0 expect eef5b4c got 0 (0) diff=fffffffff110a4b4
Fri Aug 24 17:57:52 2018 DMAIN <0000> LMSDevice.cpp:517 [tid=140620449900288] LMS: Device receive timed out
Fri Aug 24 17:57:52 2018 DMAIN <0000> radioInterface.cpp:319 [tid=140620449900288] Receive error 0
Fri Aug 24 17:57:52 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140620449900288] chan 0 recv buffer of len 0 expect eef5b4c got 0 (0) diff=fffffffff110a4b4
...
Fri Aug 24 17:57:58 2018 DMAIN <0000> LMSDevice.cpp:517 [tid=140620449900288] LMS: Device receive timed out
Fri Aug 24 17:57:58 2018 DMAIN <0000> radioInterface.cpp:319 [tid=140620449900288] Receive error 0
Fri Aug 24 17:57:58 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140620450166528] command is POWEROFF
Fri Aug 24 17:57:58 2018 DMAIN <0000> Transceiver.cpp:292 [tid=140620450166528] Stopping the transceiver
Fri Aug 24 17:57:58 2018 DMAIN <0000> LMSDevice.cpp:515 [tid=140620449900288] chan 0 recv buffer of len 0 expect eef5b4c got 0 (0) diff=fffffffff110a4b4
Fri Aug 24 17:57:58 2018 DMAIN <0000> LMSDevice.cpp:517 [tid=140620449900288] LMS: Device receive timed out
terminate called without an active exception
signal 6 received
talloc report on 'OsmoTRX' (total 2398 bytes in 15 blocks)
telnet_connection contains 1 bytes in 1 blocks (ref 0) 0x55bd6b01bda0
logging contains 2014 bytes in 7 blocks (ref 0) 0x55bd6afaeaf0
struct trx_ctx contains 383 bytes in 5 blocks (ref 0) 0x55bd6afae410
msgb contains 0 bytes in 1 blocks (ref 0) 0x55bd6afae3a0
full talloc report on 'OsmoTRX' (total 2398 bytes in 15 blocks)
telnet_connection contains 1 bytes in 1 blocks (ref 0) 0x55bd6b01bda0
logging contains 2014 bytes in 7 blocks (ref 0) 0x55bd6afaeaf0
logging.c:1033 contains 937 bytes in 1 blocks (ref 0) 0x55bd6afeb090
logging.c:950 contains 196 bytes in 1 blocks (ref 0) 0x55bd6afeaf60
struct log_target contains 200 bytes in 2 blocks (ref 0) 0x55bd6afaeee0
struct log_category contains 40 bytes in 1 blocks (ref 0) 0x55bd6afaeff0
struct log_info contains 680 bytes in 2 blocks (ref 0) 0x55bd6afaeb60
struct log_info_cat contains 640 bytes in 1 blocks (ref 0) 0x55bd6afaebf0
struct trx_ctx contains 383 bytes in 5 blocks (ref 0) 0x55bd6afae410
BAND1 contains 6 bytes in 1 blocks (ref 0) 0x55bd6b01c290
LNAW contains 5 bytes in 1 blocks (ref 0) 0x55bd6b01be10
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x55bd6afae660
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x55bd6afae5e0
msgb contains 0 bytes in 1 blocks (ref 0) 0x55bd6afae3a0
Aborted
i do not believe it was a cable issue since i am using quite short, and well shielded usb3 cables and was not shuffling around on them at the time.
just downgrading to 17.12 lms firmware does not seem to solve the issue
Updated by roh over 5 years ago
Updated by roh over 5 years ago
i tried repeating the tests with 2017.09 firmware, but could not find the correct images on http://downloads.myriadrf.org/project/limesuite/17.09/
there is either no firmware support for V1.4 hardware in limesuite 17.09 or i don't know which images to flash (limesdr usb needs 2 files. one .img and one .rbf)
see http://downloads.myriadrf.org/project/limesuite/17.09/ and its neighbours
Updated by roh over 5 years ago
opened a issue on github about the clocking option missing in firm/gateware https://github.com/myriadrf/LimeSuite/issues/213
Updated by roh over 5 years ago
i repeated the test with the limesdr-mini (v1.1) with firmware from limesuite 18.04 (LimeSDR-Mini_HW_1.1_r1.24.rpd)
there is some kind of carrier like with 18.06 but the 4406 cannot sync/trigger on it at all.
Updated by roh over 5 years ago
note to self: limesdr usb ref clock output needs to be enabled first by placing a resistor on R151 ( https://github.com/myriadrf/LimeSDR-USB/blob/master/hardware/plug/1v4/Project%20Outputs%20for%20LimeSDR-USB_1v4_LMS031pad/LimeSDR-USB_1v4_schematic_r7.PDF page 14)
Updated by roh over 5 years ago
i just tested osmo-trx-lms nighty against limesuite18.06 from the packages and against a fresh limesuite build from today
in both cases the signal slope on the limesdr-usb looks awful (see limesdr_usb_871.png or limesdr_usb_871_lms1712_env.png)
i could not yet test the -mini since i currently have this issue updating the fw: (with the same cables which work for -usb)
root@test123:~/src# LimeUtil --update Connected to [LimeSDR Mini [USB 3.0] 1D3C03216CC90D] Read(64 bytes) failed Update not supported: UNKNOWN[HW=0] Programming update failed! : Update not supported: UNKNOWN[HW=0]
Updated by roh over 5 years ago
- File 00001.png 00001.png added
- File limesdr_mini_871_no_modulation.gif limesdr_mini_871_no_modulation.gif added
- File limesdr_mini_871_no_modulation_waveform.gif limesdr_mini_871_no_modulation_waveform.gif added
i checked 3 limesdr-mini v1.1 now, of which one is working (with $unknown firmware version) somehow, but not correctly (no visible tx carrier anywhere near the intended arfcn)
instead i can see a wideband burst for a short while when i start osmo-trx-lms:
/usr/bin/osmo-trx-lms -C /etc/osmocom/osmo-trx-lms.cfg Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU Tue Sep 4 16:32:51 2018 DLGLOBAL <0003> telnet_interface.c:104 telnet at 127.0.0.1 4237 Tue Sep 4 16:32:51 2018 DLCTRL <000a> control_if.c:887 CTRL at 127.0.0.1 4236 Config Settings Log Level............... 3 Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM BTS Address......... 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ 0 Reference............... 0 C0 Filler Table......... 1 Multi-Carrier........... 0 Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 Tx Antennas............. 'BAND1' Rx Antennas............. 'LNAW' Setting SCHED_RR priority(18) Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:49 [tid=140694087274304] creating LMS device... Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:99 [tid=140694087274304] Opening LMS device.. Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:105 [tid=140694087274304] Devices found: 1 Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:115 [tid=140694087274304] Device [0]: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1D3ACA1B10B681 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] Claimed Interface Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] Estimated reference clock 40.0013 MHz Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] Reference clock 40.00 MHz Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:126 [tid=140694087274304] Init LMS device Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] INT 121, FRAC 0, DIV_LOCH 1, EN_DIV2_DIVPROG 0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCO 5000.00 MHz, RefClk 40.00 MHz Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] ICT_VCO: 180 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=64 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=96 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=112 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=120 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=124 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=126 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=127 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] Failed to lock Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=192 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=224 cmphl=2 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=240 cmphl=3 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=232 cmphl=3 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=228 cmphl=3 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=226 cmphl=2 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=227 cmphl=2 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] CSW: lowest=222, highest=227, selected=224 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] cmphl=2 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCOL : csw=224 tune ok Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] ICT_VCO: 180 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] TuneVCO(SXT) - VCO too high Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCOM : csw=0 tune fail Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] ICT_VCO: 180 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] TuneVCO(SXT) - VCO too high Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCOH : csw=0 tune fail Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] Selected: VCOL Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] INT 116, FRAC 0, DIV_LOCH 1, EN_DIV2_DIVPROG 0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCO 4800.00 MHz, RefClk 40.00 MHz Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] ICT_VCO: 180 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=64 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=96 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=112 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=120 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=124 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=126 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=127 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] Failed to lock Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=192 cmphl=0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=224 cmphl=3 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=208 cmphl=3 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=200 cmphl=2 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=204 cmphl=3 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=202 cmphl=3 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw=201 cmphl=3 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] Failed to lock Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] cmphl=2 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCOL : csw=198 tune ok Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] ICT_VCO: 180 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] TuneVCO(SXR) - VCO too high Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCOM : csw=0 tune fail Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] ICT_VCO: 180 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] TuneVCO(SXR) - VCO too high Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCOH : csw=0 tune fail Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] Selected: VCOL Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] INT 57, FRAC 385875, DIV_OUTCH_CGEN 18 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCO 2334.72 MHz, RefClk 40.00 MHz Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw 155; interval [152, 159] Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] INT 57, FRAC 385875, DIV_OUTCH_CGEN 18 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCO 2334.72 MHz, RefClk 40.00 MHz Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw 155; interval [152, 159] Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] M=160, N=4, Fvco=614.400 MHz Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] M=160, N=4, Fvco=614.400 MHz Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:85 [tid=140694087274304] Sample Rate: Min=100000 Max=3.072e+07 Step=0 Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:136 [tid=140694087274304] Setting sample rate to 1.08333e+06 4 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] INT 54, FRAC 489335, DIV_OUTCH_CGEN 7 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCO 2218.67 MHz, RefClk 40.00 MHz Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw 128; interval [124, 132] Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] INT 54, FRAC 489335, DIV_OUTCH_CGEN 7 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCO 2218.67 MHz, RefClk 40.00 MHz Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw 128; interval [124, 132] Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:142 [tid=140694087274304] Sample Rate: Host=1.08333e+06 RF=3.46667e+07 Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:149 [tid=140694087274304] Setting Internal clock reference Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:153 [tid=140694087274304] Setting VCTCXO to 180 Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:85 [tid=140694087274304] LPFBWRange Rx: Min=1.4001e+06 Max=1.3e+08 Step=0 Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:85 [tid=140694087274304] LPFBWRange Tx: Min=1.4001e+06 Max=1.3e+08 Step=0 Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:177 [tid=140694087274304] LPFBW: Rx=1.4001e+06 Tx=5.2e+06 Tue Sep 4 16:32:51 2018 DMAIN <0000> LMSDevice.cpp:203 [tid=140694087274304] Antennas configured successfully Tue Sep 4 16:32:51 2018 DDEV <0001> LMSDevice.cpp:186 [tid=140694087274304] Setting LPFBW chan 0 Tue Sep 4 16:32:51 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 10 ms Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 0 ms Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU Ref. clock: 40 MHz Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 0 ms Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 191 ms Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] RX LPF configured Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] INT 57, FRAC 385875, DIV_OUTCH_CGEN 18 Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCO 2334.72 MHz, RefClk 40.00 MHz Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw 155; interval [152, 159] Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 0 ms Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 0 ms Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU Ref. clock: 40 MHz Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 0 ms Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 61 ms Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] Filter calibrated. Filter order-4th, filter bandwidth set to 5.2 MHz.Real pole 1st order filter set to 2.5 MHz. Preemphasis filter not active Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] INT 57, FRAC 385875, DIV_OUTCH_CGEN 18 Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] VCO 2334.72 MHz, RefClk 40.00 MHz Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] csw 155; interval [152, 159] Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] TX LPF configured Tue Sep 4 16:32:54 2018 DDEV <0001> LMSDevice.cpp:191 [tid=140694087274304] Calibrating chan 0 Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 0 ms Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 0 ms Tue Sep 4 16:32:54 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 0 ms Tue Sep 4 16:32:55 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 97 ms Tue Sep 4 16:32:55 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] Rx calibration finished Tue Sep 4 16:32:55 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 0 ms Tue Sep 4 16:32:55 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 0 ms Tue Sep 4 16:32:55 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 0 ms Tue Sep 4 16:32:55 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087274304] MCU algorithm time: 84 ms -- Transceiver active with 1 channel(s) Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is POWEROFF Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is RXTUNE 1782000 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] INT 85, FRAC 104857, DIV_LOCH 1, EN_DIV2_DIVPROG 1 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] VCO 7128.00 MHz, RefClk 40.00 MHz Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] ICT_VCO: 180 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] TuneVCO(SXR) - VCO too low Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] VCOL : csw=0 tune fail Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] ICT_VCO: 180 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] TuneVCO(SXR) - VCO too low Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] VCOM : csw=0 tune fail Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] ICT_VCO: 180 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=64 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=96 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=112 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=120 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=124 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=126 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=127 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] Failed to lock Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=192 cmphl=3 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=160 cmphl=3 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=144 cmphl=2 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=152 cmphl=2 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=156 cmphl=2 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=158 cmphl=3 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=157 cmphl=3 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] Failed to lock Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] cmphl=2 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] VCOH : csw=146 tune ok Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] Selected: VCOH Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is TXTUNE 1877000 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] INT 89, FRAC 891289, DIV_LOCH 1, EN_DIV2_DIVPROG 1 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] VCO 7508.00 MHz, RefClk 40.00 MHz Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] ICT_VCO: 180 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] TuneVCO(SXT) - VCO too low Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] VCOL : csw=0 tune fail Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] ICT_VCO: 180 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] TuneVCO(SXT) - VCO too low Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] VCOM : csw=0 tune fail Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] ICT_VCO: 180 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=64 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=96 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=112 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=120 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=124 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=126 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=127 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] Failed to lock Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=192 cmphl=0 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=224 cmphl=3 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=208 cmphl=2 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=216 cmphl=2 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=220 cmphl=2 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=222 cmphl=3 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] csw=221 cmphl=3 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] Failed to lock Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] cmphl=2 Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] VCOH : csw=211 tune ok Tue Sep 4 16:32:56 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140694087501568] Selected: VCOH Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is SETTSC 7 Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:811 [tid=140694087501568] Changing TSC from 0 to 7 Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is POWERON Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:238 [tid=140694087501568] Starting the transceiver Tue Sep 4 16:32:56 2018 DMAIN <0000> radioInterface.cpp:168 [tid=140694087501568] Starting radio device Tue Sep 4 16:32:56 2018 DDEV <0001> LMSDevice.cpp:212 [tid=140694087501568] starting LMS... Tue Sep 4 16:32:56 2018 DDEV <0001> LMSDevice.cpp:315 [tid=140694087501568] Setting TX gain to 36.5 dB. Tue Sep 4 16:32:56 2018 DDEV <0001> LMSDevice.cpp:335 [tid=140694087501568] Setting RX gain to 34 dB. Tue Sep 4 16:32:56 2018 DDEV <0001> LMSDevice.cpp:382 [tid=140694087501568] Initial timestamp 27500 Tue Sep 4 16:32:56 2018 DMAIN <0000> radioInterface.cpp:189 [tid=140694087501568] Radio started Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is SETRXGAIN 1 Tue Sep 4 16:32:56 2018 DDEV <0001> LMSDevice.cpp:335 [tid=140694087501568] Setting RX gain to 1 dB. Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140694087227136] ClockInterface: sending IND CLOCK 1599964 Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is SETPOWER 1 Tue Sep 4 16:32:56 2018 DDEV <0001> LMSDevice.cpp:315 [tid=140694087501568] Setting TX gain to 72 dB. Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is SETSLOT 0 5 Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is SETSLOT 1 1 Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is SETSLOT 2 1 Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is SETSLOT 3 1 Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is SETSLOT 4 1 Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is SETSLOT 5 1 Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is SETSLOT 6 1 Tue Sep 4 16:32:56 2018 DMAIN <0000> Transceiver.cpp:709 [tid=140694087501568] command is SETSLOT 7 1 Tue Sep 4 16:32:57 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140694087227136] ClockInterface: sending IND CLOCK 1600180 Tue Sep 4 16:32:58 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140694087227136] ClockInterface: sending IND CLOCK 1600397 Tue Sep 4 16:32:59 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140694087227136] ClockInterface: sending IND CLOCK 1600613 Tue Sep 4 16:33:00 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140694087227136] ClockInterface: sending IND CLOCK 1600830 Tue Sep 4 16:33:01 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140694087227136] ClockInterface: sending IND CLOCK 1601046 Tue Sep 4 16:33:02 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140694087227136] ClockInterface: sending IND CLOCK 1601263 Tue Sep 4 16:33:03 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140694087227136] ClockInterface: sending IND CLOCK 1601479 Tue Sep 4 16:33:04 2018 DMAIN <0000> Transceiver.cpp:1018 [tid=140694087227136] ClockInterface: sending IND CLOCK 1601696 ^Csignal 2 received shutting down Shutting down transceiver... Tue Sep 4 16:33:05 2018 DMAIN <0000> Transceiver.cpp:292 [tid=140694087274304] Stopping the transceiver Tue Sep 4 16:33:05 2018 DMAIN <0000> Transceiver.cpp:305 [tid=140694087274304] Stopping the device Tue Sep 4 16:33:05 2018 DMAIN <0000> Transceiver.cpp:318 [tid=140694087274304] Transceiver stopped libusb: warning [libusb_exit] application left some devices open
the burst is happening a short time before the "ClockInterface: sending IND CLOCK" messages start coming through. see screenshot.
on the second device which i modified for 10mhz input i cannot get the application started (10mhz external clock is connected)
root@test123:~/src# /usr/bin/osmo-trx-lms -C /etc/osmocom/osmo-trx-lms.cfg Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU Tue Sep 4 17:19:16 2018 DLGLOBAL <0003> telnet_interface.c:104 telnet at 127.0.0.1 4237 Tue Sep 4 17:19:16 2018 DLCTRL <000a> control_if.c:887 CTRL at 127.0.0.1 4236 Config Settings Log Level............... 3 Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM BTS Address......... 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ 0 Reference............... 1 C0 Filler Table......... 1 Multi-Carrier........... 0 Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 Tx Antennas............. 'BAND1' Rx Antennas............. 'LNAW' Setting SCHED_RR priority(18) Tue Sep 4 17:19:16 2018 DDEV <0001> LMSDevice.cpp:49 [tid=140019953102656] creating LMS device... Tue Sep 4 17:19:16 2018 DDEV <0001> LMSDevice.cpp:99 [tid=140019953102656] Opening LMS device.. Tue Sep 4 17:19:16 2018 DDEV <0001> LMSDevice.cpp:105 [tid=140019953102656] Devices found: 1 Tue Sep 4 17:19:16 2018 DDEV <0001> LMSDevice.cpp:115 [tid=140019953102656] Device [0]: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1D3C03216CC90D Tue Sep 4 17:19:16 2018 DLMS <0002> LMSDevice.cpp:74 [tid=140019953102656] Claimed Interface Tue Sep 4 17:19:17 2018 DDEV <0001> LMSDevice.cpp:126 [tid=140019953102656] Init LMS device Tue Sep 4 17:19:17 2018 DDEV <0001> LMSDevice.cpp:128 [tid=140019953102656] LMS_Init() failed Tue Sep 4 17:19:17 2018 DMAIN <0000> osmo-trx.cpp:453 [tid=140019953102656] Failed to create radio device Shutting down transceiver... libusb: warning [libusb_exit] application left some devices open
i assume this is due to the broken firmware state (all 3 devices do not allow updating via LimeUtil --update)
the 3rd device (with internal clock again) starts on osmo-trx-lms, but the resulting spectrum seems to be a unmodulated sine carrier.
see screenshots.
the tests today were all done with a LimeSuite build from git ef2625631a02b29dfbcbe172ed88d1bb92f7a0ca built into debian packages and used with osmo-trx-lms OsmoTRX version 0.4.0 from our nightly builds
Updated by laforge over 5 years ago
I managed to reproduce this behavior using a fourth LimeSDR-mini now, again both with LimeSuite master as well as LimeSuite 17.12
There is no recovery.
LimeUtil --find * [LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1D3AD713BD327A]
LimeSuiteGUI reports:
23:13:12] INFO: Disconnected control port [23:13:18] ERROR: Read(64 bytes) failed [23:13:18] ERROR: Read(64 bytes) failed [23:13:18] ERROR: Read(64 bytes) failed [23:13:18] ERROR: Read(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] ERROR: Write(64 bytes) failed [23:13:22] INFO: Connected Control port: UNKNOWN FW:0 HW:0 Protocol:0 GW:0.0 Ref Clk: -0.00 MHz
And pretty much anything that you ever try to do with the device will report the same "ERROR: Write(64 bytes) failed"
Updated by roh about 5 years ago
- File limesdr_usb_871_phase_lms1810.gif limesdr_usb_871_phase_lms1810.gif added
- File limesdr_usb_871_env_lms1810.gif limesdr_usb_871_env_lms1810.gif added
all these tests were done with a limesdr usb sn:0009060B00472227 and external 10mhz clock from the E4406A rx LNAW tx BAND1
- updated all software (limesuite is now 18.10)
- tested with osmo-trx-lms - result was signal but after a few seconds without any busts! (cw carrier)
- updated limesdr usb from gateware version 2, revision 17 to revision 18.
- tested with osmo-trx-lms - results in a minimal more stable setup. this does NOT qualify as 'PASS' on the 4406 either. i could not get enough burst lock to get a phase measurement, but the slope shot is attached
interestingly i could actually attach 2 phones in the resulting network and get a voicecall to work for a moment, but one of the devices was much more prone to loose the network (motorola). the (old) nokia had less trouble there. (more robust error handling?)
Updated by roh about 5 years ago
compared testsetups with pau - same results like my last measurements.
after some time i still have 'missing bursts' behaviour (no sync anymore, cw signal visible on free-running sync) on -14dBm
this is repeatable after restarting the process with a cw at +12dBm
osmo-bts-trx.cfg:
osmotrx rx-gain 1 osmotrx tx-attenuation 1
osmo-bsc.cfg
! arfcn 871 arfcn 5 nominal power 23 max_power_red 10
to 'fix' it again i need to un- and replug the limesdr-usb (hardware reset)
the resulting signal (if its not CW) has a power of ~3.2dBm in this setup.
on gsm900 i have had a bit better results on getting the 4406 to sync on the 'bursts' which are produced for some time, but the switch-to-cw is the same in that band.
osmo-trx-lms.cfg (for reference)
! ! OsmoTRX (UNKNOWN) configuration saved from vty !! ! log stderr logging filter all 1 logging color 1 logging print category 1 logging timestamp 1 logging print file basename logging level all info logging level main notice logging level lms notice logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice logging level lmgcp notice logging level ljibuf notice ! stats interval 5 ! line vty no login ! trx bind-ip 127.0.0.1 remote-ip 127.0.0.1 rx-sps 4 tx-sps 4 clock-ref external multi-arfcn disable swap-channels disable base-port 5700 egprs disable rt-prio 18 chan 0 rx-path LNAW tx-path BAND1
Updated by ptrkrysik about 5 years ago
- File openbsc.cfg openbsc.cfg added
- File osmo-bts.cfg osmo-bts.cfg added
- File osmo-trx-limesdr.cfg osmo-trx-limesdr.cfg added
- File LimeQuickTest LimeQuickTest added
- File LimeUtil_info LimeUtil_info added
In the setup I have osmo-trx runs constantly with LimeSDR for whole the time I did test it, which is over 3 hours. It worked correctly at least on Tx side - gr-gsm is able to decode the signal correctly. I didn't check the Rx side yet.
My setup:
I'm running osmo-nitb.
The config files for openbsc, open-bts and osmo-trx are in the attachments.
I also attached output of "LimeQuickTest" and "LimeUtil --info" commands.
Software revisions:
libosmocore: 73b7fa61096c
osmo-trx: e7d267f17883
osmo-bts: 12ee1e12b3a1
openbsc: cd8c5f3fa4ee
limesuite: eff75aef81f2
In case more information is needed please ask.
If someone would share a software setup and config files for which LimeSDR failed, I could try to test it with my LimeSDR.
Updated by duo_kali about 5 years ago
- File LimeQuicktest LimeQuicktest added
- File LimeUtil --info LimeUtil --info added
in my tested: (strange result actually for rfloopback on LNAH but work for the rest)
It was failed on LNAH RFloopback LimeQuickTest (but we are not going test on that freq on GSM anyway)
I've downgrade the Limesuite to 17.09 which use latest osmo-trx-lms. using this gateware: (the most stable for me)
(http://downloads.myriadrf.org/project/limesuite/17.09/LimeSDR-USB_HW_1.3_r3.0.img
http://downloads.myriadrf.org/project/limesuite/17.09/LimeSDR-USB_HW_1.4_r2.9.rbf
(testing also with 18.10 which is fine for me for osmo-trx-lms site), using this gateware:
http://downloads.myriadrf.org/project/limesuite/18.10/LimeSDR-USB_HW_1.4_r4.0.img
http://downloads.myriadrf.org/project/limesuite/18.10/LimeSDR-USB_HW_1.4_r2.18.rbf
The result for GSM network: (TX = BAND1, RX= LNAL)
900mhz and 1800mhz run constantly then test the call fine with all 5 subscribers which connection never failed in the start or in the middle of osmo-trx running and the longest network stay running for 18-24 hours and test call again after I woke up from sleep and keep it a try and seems all phone keep stay in the network with LimeSDR-USB until I switched off (using legacy osmo-nitb and new splits both also tested).
another test:
LimeSDR-USB using USB.3 has interference with other electricity (which has big watt) and make osmo-trx failed in the middle of connection, example as using other things (tools with big watt in same power plug source). you need to unplug and replug for make connection again. but it was fine when using USB.3 with only laptop attached to powerplug source alone with LimeSDR.
USB.2 are fine and no interference on USB.2 port.
But using USB2 cable in USB3 port, the downlink modulation waveform is changing continuosly (sound from GQRX), which causing phone also hard to camped to the network.
Updated by duo_kali about 5 years ago
- File LimeUtil --info 1810 LimeUtil --info 1810 added
This is the tested when phone camped and call between phone using latest LimeSuite 18.10 with newest gateware I mention above. Its running latest osmo-trx-lms with New Splits (current master):
its running stable constantly with USB3 cable in USB3 Port. TX=BAND1, RX=LNAL in 1800MHZ.
Updated by ptrkrysik about 5 years ago
I can't reproduce the issue with LimeSDR-USB stopping to work after several minutes.
I checked two of them without being able to obtain the problem.
If I would have both working and not working setup it would allow me to identify what might cause the problem.
Could someone share the configs and software revisions for which this problem was encountered on LimeSDR-USB?
Updated by roh about 5 years ago
i continued my experiments with lime-usb:
using usb2 only (forced by adding a usb2 only power meter in the line) i could make the following observations:- the device pulls 500-700mA constantly, regardless of the tx state
- the device has usb structures filled to announce itself as 'bus powered' and 100mA (no external feed connected, the board is in a metal enclosure) thus violating usb spec.
- the device can be listed by 'lsusb -d 1d50:6108' properly all the time (regardless of usb2 or usb3)
- the device fails immediately (see below) when using 'lsusb -d 1d50:6108 -v' and connected to usb2. this does not fail when connected via usb3!
- failing does also generate a CW carrier as long as osmo-trx-lms keeps running (it does till it gets killed even when constantly in the state as logged below)
... Tue Oct 23 16:27:25 2018 DMAIN <0000> Transceiver.cpp:1038 [tid=139643218388736] ClockInterface: sending IND CLOCK 183676 Tue Oct 23 16:27:26 2018 DMAIN <0000> Transceiver.cpp:1038 [tid=139643218388736] ClockInterface: sending IND CLOCK 183893 Tue Oct 23 16:27:26 2018 DDEV <0001> LMSDevice.cpp:520 [tid=139643218388736] chan 0 recv buffer of len 2500 expect 246e2c got 248218 (248218) diff=13ec Tue Oct 23 16:27:26 2018 DDEV <0001> LMSDevice.cpp:520 [tid=139643218388736] chan 0 recv buffer of len 2500 expect 2477f0 got 248bdc (248bdc) diff=13ec ...
Updated by roh about 5 years ago
note:
my last few measurements (16.10 to now) were all taken with LimeSDR-USB_HW_1.4_r2.18.rbf and LimeSDR-USB_HW_1.4_r4.0.img from limesuite 18.10
Updated by ptrkrysik about 5 years ago
On my side LimeSDR-USB was powered from two USB ports with use of cable that was supplied together with the device.
One port was USB3.0 (to which Lime's data lines were connected) and additional port was USB2.0.
Updated by ptrkrysik about 5 years ago
I checked also if BTS based on LimeSDR-USB is able to maintain calls. To test it I made silent calls to a real mobile phone. They didn't break anything either.
Updated by laforge about 5 years ago
- Status changed from Stalled to In Progress
- % Done changed from 20 to 70
the root cause of this seemed to be that we're not using the full scale of the sample/dac.
There's #define LIMESDR_TX_AMPL 0.3 which basically means we're using only 30% of the scale (0.3*32767 for the signed 16bit integer). We compensate that by using a lot of analog tx gain (up to 73?).
We tested with LIMESDR_TX_AMPL 1.0 and reducing analog tx gain to about 60 dB (tx-attenuation of 12: 73 - 12 = 61) and the RF envelope looked excellent compared to before - both on LimeSDR-USB and LimeSDR-mini.
The remaining unrelated problem is related to the phase error not passing the E4406, which apparently can be achieved by tuning the PLL settings. The phase error in the 900 MHz band is OK, while the phase error in 1800 was fail (rms > 5 degrees).
Updated by roh about 5 years ago
some more experiments resulted in
// this was 0.3 before - values above 0.8 generate more phase noise, values below 0.6 give too much amplitude noise(not enough resolution) to pass gmsk validation on a E4406
#define LIMESDR_TX_AMPL 0.7
Updated by Zack about 5 years ago
Definition of LIMESDR_TX_AMPL limits maximum amplitude of I and Q channels separately. Hence LIMESDR_TX_AMPL value must be 1/sqrt(2) = 0.7071.... to get an amplitude of 1 of the complex signal:
A^2 = I^2 + Q^2
A^2 = (1/sqrt(2))^2 + (1/sqrt(2))^2
A^2 = 1/2 + 1/2
A^2 = 1
Hence if you assign LIMESDR_TX_AMPL to be more than 1/sqrt(2), complex amplitude is greater than 1 and leads to the issues.Updated by laforge about 5 years ago
- Priority changed from Immediate to High
See https://gerrit.osmocom.org/#/c/osmo-trx/+/12006/ https://gerrit.osmocom.org/#/c/osmo-trx/+/12007/ https://gerrit.osmocom.org/#/c/osmo-trx/+/12008/
roh please re-test using those changes, and without using any 'osmotrx tx-attenuation' in your config files
Updated by laforge almost 5 years ago
laforge wrote:
roh please re-test using those changes, and without using any 'osmotrx tx-attenuation' in your config files
ping?
Updated by roh almost 5 years ago
i tried to get the clock issue on limesdr mini resolved first:
https://github.com/myriadrf/LimeSuite/issues/213 says its fixed.
sadly there is no documentation (i found) about what kind of signal (slope, amplitude) the external clock should be.
some experiments gained that a sinusoidal clock with 40MHz is completely ignored as long as its smaller than ~3dBm. 3-6dBm seem to work for now.
also one needs to completely restart the device for every test (replug usb), since it will not start up when the clock is not available on reset.
this experiment was done on a limesdr mini serial 0x1d42568b4d0f48 which was updated to gateware 28 just before moving the resistor to enable the external input.
i could not get the modified limesdr mini v1.1 serial 0x1d3c03216cc90d to work. (led stays off) i guess it needs to be unbricked by jtag first.
so far i can only get it to 'work' with 40mhz clock. all other clocks do not allow LimeQuickTest to run at all. even with 40mhz i can not get it to 'PASS' the clock section:
[ Clock Network Test ] ->REF clock test Test results: 1498; 14695; 27892 - PASSED ->VCTCXO test Results : 6711179 (min); 6711179 (max) - FAILED FAILED ->Clock Network Test FAILED
i am not sure whats up with this, but i am recompiling osmo-lms-trx to test it against 40mhz external clock for now.
how one should be able to use anything different than 40mhz when that is what the fpga needs to get configured and controlled is not obvious to me yet.
Updated by roh almost 5 years ago
osmo-trx-lms works when using a patch which changes the expected external clock from 10mhz to 40mhz. phase errors are a bit too high, for a pass yet. may need more work on pga settings to see if the phase noise can be reduced.
Updated by roh almost 5 years ago
phase noise on limesdr mini is ok for 900mhz band.
on the dcs 1800 band i can not get it to pass quality requirements, even with reduced tx-gain (experiment used '64dB' +-~10db)
Updated by roh almost 5 years ago
it seems the clockchip used on lime mini (ti LMK00105) is not happy with sinewaves and wants sharp rectangles 2V/ns or better.
this means i need to redo all these measurements as soon as i have a clockgenerator with proper rectangle output.
Updated by roh almost 5 years ago
- File limesdr_mini_5_env_lms1810git_extclock10.gif limesdr_mini_5_env_lms1810git_extclock10.gif added
- File limesdr_mini_5_env_lms1810git_extclock10_tx-att_9.gif limesdr_mini_5_env_lms1810git_extclock10_tx-att_9.gif added
- File limesdr_mini_5_phase_lms1810git_extclock10.gif limesdr_mini_5_phase_lms1810git_extclock10.gif added
- File limesdr_mini_5_phase_lms1810git_extclock10_tx-att_9.gif limesdr_mini_5_phase_lms1810git_extclock10_tx-att_9.gif added
- File limesdr_mini_871_env_lms1810git_extclock10.gif limesdr_mini_871_env_lms1810git_extclock10.gif added
- File limesdr_mini_871_env_lms1810git_extclock10_tx-att_9.gif limesdr_mini_871_env_lms1810git_extclock10_tx-att_9.gif added
- File limesdr_mini_871_phase_lms1810git_extclock10.gif limesdr_mini_871_phase_lms1810git_extclock10.gif added
- File limesdr_mini_871_phase_lms1810git_extclock10_tx-att_9.gif limesdr_mini_871_phase_lms1810git_extclock10_tx-att_9.gif added
new measurement series:
arfcn 5 and arfcn 871, envelope and phase. all done with limesdr mini 1.2, on external 10MHz reference clock (square wave, slope see #3775)
please note: tx-att_9 files are done with a tx-power of '64dB' (lms api setting). the files without are done on '73dB' (full power)
Updated by roh almost 5 years ago
- Blocked by Bug #3775: properly debug limesdr usb and limesdr mini clocking requirements and osmo-trx support added
Updated by roh almost 5 years ago
- File limesdr_usb_5_env_lms1901git_extclock10_tx-att_0.gif limesdr_usb_5_env_lms1901git_extclock10_tx-att_0.gif added
- File limesdr_usb_871_env_lms1901git_extclock10_tx-att_9.gif limesdr_usb_871_env_lms1901git_extclock10_tx-att_9.gif added
- File limesdr_usb_5_env_lms1901git_extclock10_tx-att_9.gif limesdr_usb_5_env_lms1901git_extclock10_tx-att_9.gif added
- File limesdr_usb_871_env_lms1901git_extclock10_tx-att_0.gif limesdr_usb_871_env_lms1901git_extclock10_tx-att_0.gif added
latest limesuite (19.01) made the already quite ok results from limesdr usb worse again.
this test is limesuite 19.01-git limesdr usb connected via usb2 (usb3 is still not reliable and looses data)
no phase-plots this time.. i simply could not get the E4406A to properly trigger on this.
tldr: 18.10 is working better with limesdr usb
Updated by roh over 4 years ago
- Related to Bug #3861: fix function call ordering to support LimeSuite 19.01 added
Updated by roh over 4 years ago
- File limenet_micro_5_env_lms1904.gif limenet_micro_5_env_lms1904.gif added
- File limenet_micro_5_phase_lms1904.gif limenet_micro_5_phase_lms1904.gif added
- File limenet_micro_871_env_lms1904.gif limenet_micro_871_env_lms1904.gif added
- File limenet_micro_871_phase_lms1904.gif limenet_micro_871_phase_lms1904.gif added
- % Done changed from 70 to 90
this ticket is basically superseeded by work done on #3861 and #3775 as well as #3342
this means the really bad slopes are gone (they resulted from different parts of calibration not happening at all, order of function calls etc)
also we do now have code in place to limit the txpower on lime boards (see #3342), so they do not overdrive their gain stages and generate more phase-noise than necessary.
attached are some new screengrabs of the 4406 for limenet micro, limesdr usb and limesdr mini
Updated by roh over 4 years ago
- File limesdr-mini_5_env_lms1904.gif limesdr-mini_5_env_lms1904.gif added
- File limesdr-mini_5_phase_lms1904.gif limesdr-mini_5_phase_lms1904.gif added
- File limesdr-mini_871_env_lms1904.gif limesdr-mini_871_env_lms1904.gif added
- File limesdr-mini_871_phase_lms1904.gif limesdr-mini_871_phase_lms1904.gif added
- File limesdr-usb_5_env_lms1904.gif limesdr-usb_5_env_lms1904.gif added
- File limesdr-usb_5_phase_lms1904.gif limesdr-usb_5_phase_lms1904.gif added
- File limesdr-usb_871_env_lms1904.gif limesdr-usb_871_env_lms1904.gif added
- File limesdr-usb_871_phase_lms1904.gif limesdr-usb_871_phase_lms1904.gif added
the rest of the attachments.
please note that the DCS1800 band seems more of an issue for the lms hardware
Updated by roh about 4 years ago
i think this can be closed.
the only board not adhering to the slope is limesdr-usb in dcs1800 mode when using full power.
when running with a 5dB max_power_red this also comes into compliance.
will work out the details with lime, if we can reconfigure sth. or need to limit power for dcs1800 separately
please see also https://osmocom.org/projects/osmotrx/wiki/LimeSDR_Family for an overview of recommended settings and to be expected power levels.
Updated by roh about 4 years ago
- File limenet_micro_5_phase_lms1904.gif limenet_micro_5_phase_lms1904.gif added
- File limenet_micro_5_env_lms1904.gif limenet_micro_5_env_lms1904.gif added
- File limenet_micro_871_phase_lms1904_max_pow_red_-2.gif limenet_micro_871_phase_lms1904_max_pow_red_-2.gif added
- File limenet_micro_871_env_lms1904_max_pow_red_-2.gif limenet_micro_871_env_lms1904_max_pow_red_-2.gif added
yes, this can be closed.
the issue is high crest values on dcs1800, which can be mitigated by reducing the pa input values a bit.
these are new captures from a lime net micro with latest gateware:
root@raspberrypi:~# LimeUtil --make Make device Device name: LimeNET-Micro Expansion name: UNSUPPORTED Firmware version: 6 Hardware version: 19 Protocol version: 1 Gateware version: 1 Gateware revision: 2 Gateware target: LimeNET-Micro Serial number: 0x58399493f179 Free connection... OK
reducing tx power by 2dB (via max_power_red 2) is enough to generate nice output.
see also the attached env and phase plots
Updated by roh about 4 years ago
note. these plots are only valid after some warm-up of 5-15minutes and after the gpsdo is locked (>100sec)
Updated by laforge about 3 years ago
- Status changed from In Progress to Stalled
