From alexander.chemeris at gmail.com Mon Jul 8 08:25:17 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 8 Jul 2013 12:25:17 +0400 Subject: Fwd: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DA72E3.1080708@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> Message-ID: Hi Thomas, Could you look into this crash dump of the OpenBTS transceiver? We're trying to run the version from the umtrx_dual_test branch with OsmoBTS. ---------- Forwarded message ---------- From: Andreas Eversberg Date: Mon, Jul 8, 2013 at 12:05 PM Subject: Crash of UmTRX transceiver with dual TRX To: Alexander Chemeris using umtrx_dual_test will cause this crash. even when only using a single trx as usual. openbsc osmo-trx # sh /root/run.umtrx net.core.rmem_max = 50000000 net.core.wmem_max = 524288 linux; GNU C++ version 4.5.4; Boost_104900; UHD_003.004.000-unknown transceiver: radioInterface.cpp:329: virtual void RadioInterface::pullBuffer(): Assertion `num_rd == (625)' failed. /root/run.umtrx: line 4: 15668 Aborted (core dumped) /files/projects/gsm/osmo-trx/Transceiver52M/transceiver (gdb) bt full #0 0xb77b1424 in __kernel_vsyscall () No symbol table info available. #1 0xb71a92b1 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb71aaa8e in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb71a213b in ?? () from /lib/libc.so.6 No symbol table info available. #4 0xb71a21f6 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #5 0x08050562 in RadioInterface::pullBuffer (this=0x85bd3c8) at radioInterface.cpp:329 num_rd = 135212791 __FUNCTION__ = "pullBuffer" __PRETTY_FUNCTION__ = "virtual void RadioInterface::pullBuffer()" #6 0x08050ba3 in RadioInterface::driveReceiveRadio (this=0x85bd3c8) at radioInterface.cpp:254 tN = symbolsPerSlot = rcvSz = readSz = samplesPerBurst = #7 0x08051d63 in DriveLoop::driveReceiveFIFO (this=0x85bdc38) at DriveLoop.cpp:245 No locals. #8 0x08052f60 in RadioDriveLoopAdapter (drive=0x85bdc38) at DriveLoop.cpp:291 No locals. #9 0xb7795f07 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #10 0xb726864e in clone () from /lib/libc.so.6 No symbol table info available. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From tom at tsou.cc Mon Jul 8 09:17:12 2013 From: tom at tsou.cc (Thomas Tsou) Date: Mon, 8 Jul 2013 11:17:12 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 10:25 AM, Alexander Chemeris wrote: > ---------- Forwarded message ---------- > From: Andreas Eversberg > Date: Mon, Jul 8, 2013 at 12:05 PM > Subject: Crash of UmTRX transceiver with dual TRX > To: Alexander Chemeris > > > using umtrx_dual_test will cause this crash. even when only using a > single trx as usual. > > openbsc osmo-trx # sh /root/run.umtrx > net.core.rmem_max = 50000000 > net.core.wmem_max = 524288 > linux; GNU C++ version 4.5.4; Boost_104900; UHD_003.004.000-unknown > > transceiver: radioInterface.cpp:329: virtual void > RadioInterface::pullBuffer(): Assertion `num_rd == (625)' failed. Can you post the error log? This almost certainly a zero return condition related to timestamps on the write/read with the ring buffer. The error should report buffer state. Thomas From wyjiang at ljshuoda.com Mon Jul 8 10:05:58 2013 From: wyjiang at ljshuoda.com (jiangwy) Date: Mon, 8 Jul 2013 18:05:58 +0800 Subject: How to Get libusrp Message-ID: <2013070818055881331238@ljshuoda.com> Hi All, I want to build kal-v0.4.1. When use CXXFLAGS='-W -Wall -O3' ./configure Output errors: configure: error: Package requirements (usrp >= 3.3) were not met: No package 'usrp' found I'm using ubuntu 12.04. How can I install libusrp? ' sudo apt-get install libusrp-dev' not working! Jiang Wenyi -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at eversberg.eu Mon Jul 8 10:06:35 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 08 Jul 2013 12:06:35 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> Message-ID: <51DA8F2B.1080701@eversberg.eu> Thomas Tsou wrote: > Can you post the error log? hi thomas, i never cared about error logging. where is it stored? do i need to enable it somewhere? are there options for deeper debugging? regards, andreas From alexander.chemeris at gmail.com Mon Jul 8 10:18:02 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 8 Jul 2013 14:18:02 +0400 Subject: How to Get libusrp In-Reply-To: <2013070818055881331238@ljshuoda.com> References: <2013070818055881331238@ljshuoda.com> Message-ID: Jiang, libusrp is only used for USRP1, for UmTRX you should use UHD instead of libusrp. A version of kal with the UHD support is available at Thomas Tsou's repository, but we have never tested it with UmTRX. Please let everyone know if you could get it working: https://github.com/ttsou/kalibrate-uhd On Mon, Jul 8, 2013 at 2:05 PM, jiangwy wrote: > Hi All, > > I want to build kal-v0.4.1. > When use CXXFLAGS='-W -Wall -O3' ./configure > Output errors: > > configure: error: Package requirements (usrp >= 3.3) were not met: > > No package 'usrp' found > > I'm using ubuntu 12.04. How can I install libusrp? > ' sudo apt-get install libusrp-dev' not working! > > ________________________________ > Jiang Wenyi -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From tom at tsou.cc Mon Jul 8 10:34:41 2013 From: tom at tsou.cc (Thomas Tsou) Date: Mon, 8 Jul 2013 12:34:41 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DA8F2B.1080701@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 12:06 PM, Andreas Eversberg wrote: > i never cared about error logging. where is it stored? do i need to enable > it somewhere? are there options for deeper debugging? There are syslog instructions here. http://wush.net/trac/rangepublic/wiki/DebuggingCode Alternatively, if you don't like the OpenBTS logging mechanism, you might consider just changing the LOG macros here. CommonLibs/Logger.h Thomas From andreas at eversberg.eu Mon Jul 8 12:32:48 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 08 Jul 2013 14:32:48 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> Message-ID: <51DAB170.6050908@eversberg.eu> Thomas Tsou wrote: > Alternatively, if you don't like the OpenBTS logging mechanism, you > might consider just changing the LOG macros here. > > CommonLibs/Logger.h > hi thomas, this is the output from start to crash: Jul 8 14:30:13 openbsc transceiver: opening configuration table from path /etc/OpenBTS/OpenBTS.db Jul 8 14:30:14 openbsc transceiver: INFO 3069425408 14:30:14.8 UHDDevice.cpp:563:open: Using discovered UHD device type=umtrx,addr=192.168.10.2,name=UmTRX,serial=14 Jul 8 14:30:15 openbsc transceiver: INFO 3069425408 14:30:15.0 UHDDevice.cpp:335:uhd_msg_handler: Opening a UmTRX device... Jul 8 14:30:15 openbsc transceiver: INFO 3069425408 14:30:15.1 UHDDevice.cpp:335:uhd_msg_handler: Current recv frame size: 1472 bytes Jul 8 14:30:15 openbsc transceiver: INFO 3069425408 14:30:15.1 UHDDevice.cpp:335:uhd_msg_handler: Current send frame size: 1472 bytes Jul 8 14:30:16 openbsc transceiver: INFO 3069425408 14:30:16.4 UHDDevice.cpp:544:parse_dev_type: Using fixed transmit window for UmTRX Device UMTRX-REV0 Jul 8 14:30:16 openbsc transceiver: INFO 3069425408 14:30:16.4 UHDDevice.cpp:618:open: Jul 8 14:30:16 openbsc Single USRP: Jul 8 14:30:16 openbsc Device: UmTRX Device Jul 8 14:30:16 openbsc Mboard 0: UMTRX-REV0 Jul 8 14:30:16 openbsc RX Channel: 0 Jul 8 14:30:16 openbsc RX DSP: 0 Jul 8 14:30:16 openbsc RX Dboard: A Jul 8 14:30:16 openbsc RX Subdev: LMS6002D (0xfa07) - 0 Jul 8 14:30:16 openbsc RX Channel: 1 Jul 8 14:30:16 openbsc RX DSP: 1 Jul 8 14:30:16 openbsc RX Dboard: B Jul 8 14:30:16 openbsc RX Subdev: LMS6002D (0xfa07) - 0 Jul 8 14:30:16 openbsc TX Channel: 0 Jul 8 14:30:16 openbsc TX DSP: 0 Jul 8 14:30:16 openbsc TX Dboard: A Jul 8 14:30:16 openbsc TX Subdev: LMS6002D (0xfa09) - 0 Jul 8 14:30:16 openbsc TX Channel: 1 Jul 8 14:30:16 openbsc TX DSP: 1 Jul 8 14:30:16 openbsc TX Dboard: B Jul 8 14:30:16 openbsc TX Subdev: LMS6002D (0xfa09) - 0 Jul 8 14:30:16 openbsc transceiver: DEBUG 3069425408 14:30:16.4 DriveLoop.cpp:52:DriveLoop: gsmPulse: 0.182762 0j 0.966021 0j 0.182762 0j Jul 8 14:30:16 openbsc transceiver: DEBUG 3069425408 14:30:16.4 Transceiver.cpp:67:Transceiver: gsmPulse: 0.182762 0j 0.966021 0j 0.182762 0j Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.5 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.5 Transceiver.cpp:369:driveControl: command is CMD POWEROFF Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.5 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.6 Transceiver.cpp:369:driveControl: command is CMD RXTUNE 1781600 Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.8 UHDDevice.cpp:927:setRxFreq: Jul 8 14:30:16 openbsc Tune Result: Jul 8 14:30:16 openbsc Target RF Freq: 1781.600000 (MHz) Jul 8 14:30:16 openbsc Actual RF Freq: 1781.600000 (MHz) Jul 8 14:30:16 openbsc Target DSP Freq: -0.000000 (MHz) Jul 8 14:30:16 openbsc Actual DSP Freq: -0.000000 (MHz) Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.8 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.8 Transceiver.cpp:369:driveControl: command is CMD TXTUNE 1876600 Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 UHDDevice.cpp:913:setTxFreq: Jul 8 14:30:17 openbsc Tune Result: Jul 8 14:30:17 openbsc Target RF Freq: 1876.600000 (MHz) Jul 8 14:30:17 openbsc Actual RF Freq: 1876.599999 (MHz) Jul 8 14:30:17 openbsc Target DSP Freq: 0.000001 (MHz) Jul 8 14:30:17 openbsc Actual DSP Freq: 0.000001 (MHz) Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 Transceiver.cpp:369:driveControl: command is CMD SETTSC 7 Jul 8 14:30:17 openbsc transceiver: DEBUG 3051350848 14:30:17.0 sigProcLib.cpp:885:generateMidamble: midamble autocorr: 0.182759 1.34932e-06j 0.966021 -0.182756j -0.18276 7.19389e-07j -0.966021 -0.182765j -2.01039 7.0521e-08j -10.6262 -0.182759j -2.01038 9.81044e-07j -0.966021 0.182763j -0.182762 1.55789e-07j 3.22465e-08 -4.63739e-07j -3.39939e-07 -7.24713e-07j -1.10399e-06 -2.67657e-06j 2.92419 2.28714e-06j 15.4563 1.35901e-05j 2.9242 1.58791e-06j 2.43788e-06 -4.25888e-06j 7.91297e-06 7.79799e-07j 8.01918e-07 8.40149e-06j -0.182766 -8.68613e-07j -0.966024 0.548273j -1.64487 1.93203j -8.69419 0.182726j -1.27933 -3.94435e-06j 0.966019 -0.182755j 0.548286 -1.93204j 0.966024 -0.913802j Jul 8 14:30:17 openbsc transceiver: DEBUG 3051350848 14:30:17.0 sigProcLib.cpp:887:generateMidamble: TOA: 13.002 Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 Transceiver.cpp:369:driveControl: command is CMD POWERON Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 UHDDevice.cpp:672:start: Starting USRP... Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.1 UHDDevice.cpp:691:start: The current time is 0.0100679 seconds Jul 8 14:30:17 openbsc transceiver: DEBUG 3051350848 14:30:17.1 radioInterface.cpp:174:start: Radio started Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.1 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:17 openbsc transceiver: ERR 3051318080 14:30:17.1 UHDDevice.cpp:774:readSamples: Number of requested channels does not match build Jul 8 14:30:17 openbsc transceiver: DEBUG 3051318080 14:30:17.1 radioInterface.cpp:328:pullBuffer: Rx read -1 samples from device regards, andreas From andreas at eversberg.eu Mon Jul 8 12:58:21 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 08 Jul 2013 14:58:21 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DAB170.6050908@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> Message-ID: <51DAB76D.2050709@eversberg.eu> Andreas Eversberg wrote: > Jul 8 14:30:17 openbsc transceiver: ERR 3051318080 14:30:17.1 > UHDDevice.cpp:774:readSamples: Number of requested channels does not > match build got it working. just started transceiver with option "2". now i got the following problem while provisioning second trx: (debug output of osmo-bts) trx_if.c:362 transceiver rejected TRX command with response: 'RSP SETTSC 1 7' (trx 1) From andreas at eversberg.eu Mon Jul 8 13:07:24 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 08 Jul 2013 15:07:24 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DAB76D.2050709@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> Message-ID: <51DAB98C.5040501@eversberg.eu> Andreas Eversberg wrote: > trx_if.c:362 transceiver rejected TRX command with response: 'RSP SETTSC > 1 7' (trx 1) > just made osmo-bts ignore that. now i can provision both trx with similar setting, except slot type and and ARFCN. it seems to work now, but i get no rf power on second trx. i use ARFCN and 869 and 877. From tom at tsou.cc Mon Jul 8 13:07:44 2013 From: tom at tsou.cc (Thomas Tsou) Date: Mon, 8 Jul 2013 15:07:44 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DAB76D.2050709@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 2:58 PM, Andreas Eversberg wrote: > Andreas Eversberg wrote: >> Jul 8 14:30:17 openbsc transceiver: ERR 3051318080 14:30:17.1 >> UHDDevice.cpp:774:readSamples: Number of requested channels does not >> match build > got it working. just started transceiver with option "2". Great. I will create a patch to dynamically handle the single channel case. Currently it's hard coded at build time. > now i got the following problem while provisioning second trx: (debug > output of osmo-bts) > > trx_if.c:362 transceiver rejected TRX command with response: 'RSP SETTSC > 1 7' (trx 1) The transceiver control portion is setup for OpenBTS, which expects that the TSC value is set statically for all TRX's. It's rejecting because the TSC value is being set twice; more specifically, the OpenBTS assumption is that these are set once before power on. This needs to be changed. Should we now assume that each TRX is setup an independent manner? Thomas From andreas at eversberg.eu Mon Jul 8 13:27:28 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 08 Jul 2013 15:27:28 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> Message-ID: <51DABE40.9020802@eversberg.eu> Thomas Tsou wrote: > The transceiver control portion is setup for OpenBTS, which expects > that the TSC value is set statically for all TRX's. It's rejecting > because the TSC value is being set twice; more specifically, the > OpenBTS assumption is that these are set once before power on. This > needs to be changed. > > Should we now assume that each TRX is setup an independent manner? > i see no problem with that reject. i think it makes sense to reject TSC, if it does not match the TSC of first TRX. since trx manager interface seems to be designed to handle each TRX individually (even might be possible to run on different transceivers for one BTS), i would think it is a good idea to set TSC for every TRX. From andreas at eversberg.eu Mon Jul 8 13:33:48 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 08 Jul 2013 15:33:48 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DAB98C.5040501@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DAB98C.5040501@eversberg.eu> Message-ID: <51DABFBC.4020001@eversberg.eu> Andreas Eversberg wrote: > just made osmo-bts ignore that. now i can provision both trx with > similar setting, except slot type and and ARFCN. it seems to work now, > but i get no rf power on second trx. i use ARFCN and 869 and 877. > i do also get no reception from the phone at second trx (late assignment, my tester showed me power on TS0 uplink). seems that rx and tx does not work for some reason. also i found that the transceiver leaks about 2 megabytes every second. after some minutes my test machine runs out of mem space. From tom at tsou.cc Mon Jul 8 13:36:48 2013 From: tom at tsou.cc (Thomas Tsou) Date: Mon, 8 Jul 2013 15:36:48 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DAB98C.5040501@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DAB98C.5040501@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 3:07 PM, Andreas Eversberg wrote: > Andreas Eversberg wrote: >> trx_if.c:362 transceiver rejected TRX command with response: 'RSP SETTSC >> 1 7' (trx 1) >> > just made osmo-bts ignore that. now i can provision both trx with > similar setting, except slot type and and ARFCN. it seems to work now, > but i get no rf power on second trx. i use ARFCN and 869 and 877. If the slot isn't set then the burst will be zero'd at the output of the filler table. There is an assumption of the order of commands. Global Settings 1. SETTSC 2. POWERON TRX Specific 3. SETSLOT Thomas From tom at tsou.cc Mon Jul 8 13:58:38 2013 From: tom at tsou.cc (Thomas Tsou) Date: Mon, 8 Jul 2013 15:58:38 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DABFBC.4020001@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DAB98C.5040501@eversberg.eu> <51DABFBC.4020001@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 3:33 PM, Andreas Eversberg wrote: > Andreas Eversberg wrote: >> just made osmo-bts ignore that. now i can provision both trx with >> similar setting, except slot type and and ARFCN. it seems to work now, >> but i get no rf power on second trx. i use ARFCN and 869 and 877. >> > i do also get no reception from the phone at second trx (late > assignment, my tester showed me power on TS0 uplink). seems that rx and > tx does not work for some reason. If the slots aren't enabled, then both uplink and downlink will be disabled. This patch should cause Tx slot setting to be ignored and will send whatever core submits. We need the slot setting to set the TSC / RACH correlation, so Rx is not as simple. > also i found that the transceiver leaks about 2 megabytes every second. > after some minutes my test machine runs out of mem space. Should be resolved in the same patch. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Transceiver52M-Disable-dynamic-filler-table-setting-.patch Type: application/octet-stream Size: 1675 bytes Desc: not available URL: From andreas at eversberg.eu Mon Jul 8 14:19:30 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 08 Jul 2013 16:19:30 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DAB98C.5040501@eversberg.eu> <51DABFBC.4020001@eversberg.eu> Message-ID: <51DACA72.9020808@eversberg.eu> Thomas Tsou wrote: >> also i found that the transceiver leaks about 2 megabytes every second. >> > after some minutes my test machine runs out of mem space. >> > Should be resolved in the same patch. > > yes, it is gone. i managed to make it work. i had a bug, so second TRX was ARFCN 0. thanx allot, i will do more testings. From tom at tsou.cc Mon Jul 8 14:34:31 2013 From: tom at tsou.cc (Thomas Tsou) Date: Mon, 8 Jul 2013 16:34:31 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DABE40.9020802@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DABE40.9020802@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 3:27 PM, Andreas Eversberg wrote: > Thomas Tsou wrote: >> Should we now assume that each TRX is setup an independent manner? >> > i see no problem with that reject. i think it makes sense to reject TSC, > if it does not match the TSC of first TRX. since trx manager interface > seems to be designed to handle each TRX individually (even might be > possible to run on different transceivers for one BTS), i would think it > is a good idea to set TSC for every TRX. We can easily move to separate TSC settings be removing the static identifier. The only issue then is that OpenBTS will no longer work. Perhaps the larger limitation is that we can't set TSC dynamically after POWERON. This is because the midamble correlation sequence is regenerated and is not thread safe. In summary, we can easily have separate TSC, but they need to be set before the POWERON command is received. Thomas From alexander.chemeris at gmail.com Mon Jul 8 15:21:48 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 8 Jul 2013 19:21:48 +0400 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DABE40.9020802@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 6:34 PM, Thomas Tsou wrote: > On Mon, Jul 8, 2013 at 3:27 PM, Andreas Eversberg wrote: >> Thomas Tsou wrote: >>> Should we now assume that each TRX is setup an independent manner? >>> >> i see no problem with that reject. i think it makes sense to reject TSC, >> if it does not match the TSC of first TRX. since trx manager interface >> seems to be designed to handle each TRX individually (even might be >> possible to run on different transceivers for one BTS), i would think it >> is a good idea to set TSC for every TRX. > > We can easily move to separate TSC settings be removing the static > identifier. The only issue then is that OpenBTS will no longer work. > Perhaps the larger limitation is that we can't set TSC dynamically > after POWERON. This is because the midamble correlation sequence is > regenerated and is not thread safe. There could be two command sets - one for OpenBTS compatibility, one for more advanced systems. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From alexander.chemeris at gmail.com Mon Jul 8 15:24:58 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 8 Jul 2013 19:24:58 +0400 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DAB98C.5040501@eversberg.eu> <51DABFBC.4020001@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 5:58 PM, Thomas Tsou wrote: > On Mon, Jul 8, 2013 at 3:33 PM, Andreas Eversberg wrote: >> Andreas Eversberg wrote: >>> just made osmo-bts ignore that. now i can provision both trx with >>> similar setting, except slot type and and ARFCN. it seems to work now, >>> but i get no rf power on second trx. i use ARFCN and 869 and 877. >>> >> i do also get no reception from the phone at second trx (late >> assignment, my tester showed me power on TS0 uplink). seems that rx and >> tx does not work for some reason. > > If the slots aren't enabled, then both uplink and downlink will be > disabled. This patch should cause Tx slot setting to be ignored and > will send whatever core submits. We need the slot setting to set the > TSC / RACH correlation, so Rx is not as simple. > >> also i found that the transceiver leaks about 2 megabytes every second. >> after some minutes my test machine runs out of mem space. > > Should be resolved in the same patch. Could you please push this to the osmo-trx repository? https://github.com/fairwaves/osmo-trx -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From tom at tsou.cc Mon Jul 8 15:53:26 2013 From: tom at tsou.cc (Thomas Tsou) Date: Mon, 8 Jul 2013 17:53:26 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DAB98C.5040501@eversberg.eu> <51DABFBC.4020001@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 5:24 PM, Alexander Chemeris wrote: > On Mon, Jul 8, 2013 at 5:58 PM, Thomas Tsou wrote: >>> i do also get no reception from the phone at second trx (late >>> assignment, my tester showed me power on TS0 uplink). seems that rx and >>> tx does not work for some reason. >> >> If the slots aren't enabled, then both uplink and downlink will be >> disabled. This patch should cause Tx slot setting to be ignored and >> will send whatever core submits. We need the slot setting to set the >> TSC / RACH correlation, so Rx is not as simple. >> >>> also i found that the transceiver leaks about 2 megabytes every second. >>> after some minutes my test machine runs out of mem space. >> >> Should be resolved in the same patch. > > Could you please push this to the osmo-trx repository? > https://github.com/fairwaves/osmo-trx Do we want to permanently disable the filler table? This is a breaking change for OpenBTS. Or do you just mean the memory leak fix. Thomas From alexander.chemeris at gmail.com Mon Jul 8 16:04:06 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 8 Jul 2013 20:04:06 +0400 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DAB98C.5040501@eversberg.eu> <51DABFBC.4020001@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 7:53 PM, Thomas Tsou wrote: > On Mon, Jul 8, 2013 at 5:24 PM, Alexander Chemeris > wrote: >> On Mon, Jul 8, 2013 at 5:58 PM, Thomas Tsou wrote: >>>> i do also get no reception from the phone at second trx (late >>>> assignment, my tester showed me power on TS0 uplink). seems that rx and >>>> tx does not work for some reason. >>> >>> If the slots aren't enabled, then both uplink and downlink will be >>> disabled. This patch should cause Tx slot setting to be ignored and >>> will send whatever core submits. We need the slot setting to set the >>> TSC / RACH correlation, so Rx is not as simple. >>> >>>> also i found that the transceiver leaks about 2 megabytes every second. >>>> after some minutes my test machine runs out of mem space. >>> >>> Should be resolved in the same patch. >> >> Could you please push this to the osmo-trx repository? >> https://github.com/fairwaves/osmo-trx > > Do we want to permanently disable the filler table? This is a breaking > change for OpenBTS. Or do you just mean the memory leak fix. Memory leak is a must. Constant Rx on disabled slots is only useful for testing. It would be nice if this could be configurable (e.g. over the transceiver API), but that's not a hard requirement. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From andreas at eversberg.eu Mon Jul 8 17:04:03 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 08 Jul 2013 19:04:03 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DABE40.9020802@eversberg.eu> Message-ID: <51DAF103.7010604@eversberg.eu> >>> i see no problem with that reject. i think it makes sense to reject TSC, >>> if it does not match the TSC of first TRX. since trx manager interface >>> seems to be designed to handle each TRX individually (even might be >>> possible to run on different transceivers for one BTS), i would think it >>> is a good idea to set TSC for every TRX. >>> >> We can easily move to separate TSC settings be removing the static >> identifier. The only issue then is that OpenBTS will no longer work. >> Perhaps the larger limitation is that we can't set TSC dynamically >> after POWERON. This is because the midamble correlation sequence is >> regenerated and is not thread safe. >> > There could be two command sets - one for OpenBTS compatibility, one > for more advanced systems. > i think that is not requited. TSC at openbsc is a global setting. by the specs, it can be set for every timeslot individualy. i think it would be good to keep it global, so the transceiver remains compatible to openbsc. i can remove the TSC command from osmo-bts. alternatively, as stated above, setting the same TSC, which is already running at TRX 0 could be just acknowledged, different TSC rejected. From andreas at eversberg.eu Mon Jul 8 19:12:06 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 08 Jul 2013 21:12:06 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DAF103.7010604@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DABE40.9020802@eversberg.eu> <51DAF103.7010604@eversberg.eu> Message-ID: <51DB0F06.5050706@eversberg.eu> Andreas Eversberg wrote: > >>>> i see no problem with that reject. i think it makes sense to reject TSC, >>>> if it does not match the TSC of first TRX. since trx manager interface >>>> seems to be designed to handle each TRX individually (even might be >>>> possible to run on different transceivers for one BTS), i would think it >>>> is a good idea to set TSC for every TRX. >>>> >>>> >>> We can easily move to separate TSC settings be removing the static >>> identifier. The only issue then is that OpenBTS will no longer work. >>> Perhaps the larger limitation is that we can't set TSC dynamically >>> after POWERON. This is because the midamble correlation sequence is >>> regenerated and is not thread safe. >>> >>> >> There could be two command sets - one for OpenBTS compatibility, one >> for more advanced systems. >> >> > i think that is not requited. TSC at openbsc is a global setting. by the > specs, it can be set for every timeslot individualy. i think it would be > good to keep it global, so the transceiver remains compatible to > openbsc. i can remove the TSC command from osmo-bts. alternatively, as > stated above, setting the same TSC, which is already running at TRX 0 > could be just acknowledged, different TSC rejected. > once TSC is set, it cannot be changed, even after poweroff. i must restart transceiver before every new start of osmo-bts. before osmo-bts start provisioning transceiver, it sends poweroff to all trx. also if bsc fails, transceiver is turned off and provisioned after bsc link is restored. with the single trx version of transceiver it worked all the time. i think there should be a solution for that problem. From alexander.chemeris at gmail.com Mon Jul 8 19:54:04 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 8 Jul 2013 23:54:04 +0400 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DB0F06.5050706@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DABE40.9020802@eversberg.eu> <51DAF103.7010604@eversberg.eu> <51DB0F06.5050706@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 11:12 PM, Andreas Eversberg wrote: >>>>> i see no problem with that reject. i think it makes sense to reject TSC, >>>>> if it does not match the TSC of first TRX. since trx manager interface >>>>> seems to be designed to handle each TRX individually (even might be >>>>> possible to run on different transceivers for one BTS), i would think it >>>>> is a good idea to set TSC for every TRX. >>>>> >>>>> >>>> We can easily move to separate TSC settings be removing the static >>>> identifier. The only issue then is that OpenBTS will no longer work. >>>> Perhaps the larger limitation is that we can't set TSC dynamically >>>> after POWERON. This is because the midamble correlation sequence is >>>> regenerated and is not thread safe. >>>> >>>> >>> There could be two command sets - one for OpenBTS compatibility, one >>> for more advanced systems. >>> >>> >> i think that is not requited. TSC at openbsc is a global setting. by the >> specs, it can be set for every timeslot individualy. i think it would be >> good to keep it global, so the transceiver remains compatible to >> openbsc. i can remove the TSC command from osmo-bts. alternatively, as >> stated above, setting the same TSC, which is already running at TRX 0 >> could be just acknowledged, different TSC rejected. >> > once TSC is set, it cannot be changed, even after poweroff. i must > restart transceiver before every new start of osmo-bts. before osmo-bts > start provisioning transceiver, it sends poweroff to all trx. also if > bsc fails, transceiver is turned off and provisioned after bsc link is > restored. with the single trx version of transceiver it worked all the > time. i think there should be a solution for that problem. And this leads us to the question that POWEROFF in the umtrx_dual_test is not implemented at all. Thomas, could you please rebase the umtrx_dual_test onto the recent "fairwaves/master" branch? The DriveLoop/Transceiver split breaks a number of patches and it would be better if you do it yourself. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From andreas at eversberg.eu Mon Jul 8 20:01:48 2013 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 08 Jul 2013 22:01:48 +0200 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DABE40.9020802@eversberg.eu> <51DAF103.7010604@eversberg.eu> <51DB0F06.5050706@eversberg.eu> Message-ID: <51DB1AAC.8060902@eversberg.eu> Alexander Chemeris wrote: > And this leads us to the question that POWEROFF in the umtrx_dual_test > is not implemented at all. > > Thomas, could you please rebase the umtrx_dual_test onto the recent > "fairwaves/master" branch? The DriveLoop/Transceiver split breaks a > number of patches and it would be better if you do it yourself. oops, i did a mistake. even single trx support never supported poweroff. the reason why it worked for me is that i send "SETTSC" and "SETBSIC" commands to the transceiver. (calypso-bts requires "SETBSIC" because it generates SCH itself). because one of these commands will fail, osmo-bts ignores the response, so it does for "SETTSC". i think it is not a clean solution to send both commands and ignore the result. the "POWEROFF" should shutdown transmitter, stop receiving and allow "SETTSC" (even with different value) again. From tom at tsou.cc Mon Jul 8 20:13:02 2013 From: tom at tsou.cc (Thomas Tsou) Date: Mon, 8 Jul 2013 16:13:02 -0400 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DABE40.9020802@eversberg.eu> <51DAF103.7010604@eversberg.eu> <51DB0F06.5050706@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 3:54 PM, Alexander Chemeris wrote: > And this leads us to the question that POWEROFF in the umtrx_dual_test > is not implemented at all. This is not a problem caused by the dual_trx branch. POWEROFF has never been implemented in _any_ branch. It has been always been dummy command since the first OpenBTS release. The dual_trx branch does maintain slightly stricter state variables in order to manage shared resource control, and may return more error conditions (instead of ignoring them). That's the likely the cause of different behaviour. Yes, as you know, it's a major problem and the transceiver code doesn't release resources in a sane way. Shutdown is broken, and it always has been. > Thomas, could you please rebase the umtrx_dual_test onto the recent > "fairwaves/master" branch? The DriveLoop/Transceiver split breaks a > number of patches and it would be better if you do it yourself. I will do that. Thomas From tom at tsou.cc Mon Jul 8 20:35:09 2013 From: tom at tsou.cc (Thomas Tsou) Date: Mon, 8 Jul 2013 16:35:09 -0400 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: <51DB1AAC.8060902@eversberg.eu> References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DABE40.9020802@eversberg.eu> <51DAF103.7010604@eversberg.eu> <51DB0F06.5050706@eversberg.eu> <51DB1AAC.8060902@eversberg.eu> Message-ID: On Mon, Jul 8, 2013 at 4:01 PM, Andreas Eversberg wrote: > oops, i did a mistake. even single trx support never supported poweroff. the > reason why it worked for me is that i send "SETTSC" and "SETBSIC" commands > to the transceiver. (calypso-bts requires "SETBSIC" because it generates SCH > itself). because one of these commands will fail, osmo-bts ignores the > response, so it does for "SETTSC". > > i think it is not a clean solution to send both commands and ignore the > result. the "POWEROFF" should shutdown transmitter, stop receiving and allow > "SETTSC" (even with different value) again. Agreed. The larger issue isn't that the POWEROFF command isn't implemented, it's that the transceiver was written without explicit state management. Thread deallocation is the most annoying issue. We can't shutdown threads right now because we don't know what threads are running. https://github.com/ttsou/openbts-multi-arfcn/commit/0cbdb59b61 https://github.com/ttsou/openbts-multi-arfcn/commit/8f2d863485 IMO, the preferred solution is to replace thread abstraction or make the signals work. I think the latter was the original intention with shutdown triggering on pthread_cancel(), but for whatever reason that was never implemented. Thomas From wyjiang at ljshuoda.com Tue Jul 9 08:39:12 2013 From: wyjiang at ljshuoda.com (jiangwy) Date: Tue, 9 Jul 2013 16:39:12 +0800 Subject: kalibrate-uhd is OK References: <2013070818055881331238@ljshuoda.com>, Message-ID: <2013070916391221048818@ljshuoda.com> I have downloaded the source code from https://github.com/ttsou/kalibrate-uhd and built it. It can work. By the way, my system is Ubuntu 12.04. jiangwy From: Alexander Chemeris Date: 2013-07-08 18:18 To: wyjiang CC: UmTRX Subject: Re: How to Get libusrp Jiang, libusrp is only used for USRP1, for UmTRX you should use UHD instead of libusrp. A version of kal with the UHD support is available at Thomas Tsou's repository, but we have never tested it with UmTRX. Please let everyone know if you could get it working: https://github.com/ttsou/kalibrate-uhd On Mon, Jul 8, 2013 at 2:05 PM, jiangwy wrote: > Hi All, > > I want to build kal-v0.4.1. > When use CXXFLAGS='-W -Wall -O3' ./configure > Output errors: > > configure: error: Package requirements (usrp >= 3.3) were not met: > > No package 'usrp' found > > I'm using ubuntu 12.04. How can I install libusrp? > ' sudo apt-get install libusrp-dev' not working! > > ________________________________ > Jiang Wenyi -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyjiang at ljshuoda.com Tue Jul 9 12:15:35 2013 From: wyjiang at ljshuoda.com (jiangwy) Date: Tue, 9 Jul 2013 20:15:35 +0800 Subject: LMS6002DCalibration Message-ID: <2013070920153569485530@ljshuoda.com> Hi All, I use the following functions to calibration uhd_cal_tx_dc_offset uhd_cal_tx_iq_balance uhd_cal_rx_iq_balance I got three *.csv files in .uhd/cal/{rx_iq_cal_v0.1_38.A.csv tx_iq_cal_v0.1_38.A.csv tx_dc_cal_v0.1_38.A.csv} How can I use the contents in these files? ~$ cat .uhd/cal/tx_dc_cal_v0.1_38.A.csv name, TX Frontend Calibration serial, 38.A timestamp, 1373370847 version, 0, 1 DATA STARTS HERE lo_frequency, correction_real, correction_imag, measured, delta 9.3e+08, 0.0046875, 0.0101563, -105.406, 32.9285 9.302e+08, 0.0046875, 0.0101563, -99.0923, 26.9516 9.304e+08, 0.0046875, 0.0101563, -102.352, 29.6946 9.306e+08, 0.0046875, 0.0101563, -104.045, 31.523 9.308e+08, 0.0046875, 0.0101563, -103.354, 30.8814 9.31e+08, 0.0046875, 0.0101563, -108.024, 35.4699 9.312e+08, 0.0046875, 0.0101563, -110.951, 38.5388 9.314e+08, 0.00546875, 0.0101563, -99.2159, 26.6738 9.316e+08, 0.0046875, 0.0101563, -103.085, 30.5324 9.318e+08, 0.00546875, 0.0101563, -104.854, 32.0656 9.32e+08, 0.0046875, 0.0101563, -111.759, 38.9142 9.322e+08, 0.0046875, 0.0101563, -101.731, 29.0089 9.324e+08, 0.0046875, 0.0101563, -107.722, 35.0989 9.326e+08, 0.00546875, 0.0101563, -107.25, 34.6358 9.328e+08, 0.0046875, 0.0101563, -109.739, 37.0523 9.33e+08, 0.0046875, 0.0101563, -111.463, 38.951 9.332e+08, 0.0046875, 0.0101563, -112.302, 39.8637 9.334e+08, 0.0046875, 0.0101563, -110.057, 37.4139 9.336e+08, 0.0046875, 0.0101563, -103.617, 31.0364 9.338e+08, 0.0046875, 0.0101563, -104.47, 31.8644 9.34e+08, 0.00546875, 0.0101563, -103.053, 30.3361 9.342e+08, 0.0046875, 0.0101563, -106.426, 33.7277 9.344e+08, 0.0046875, 0.0101563, -112.463, 39.6667 9.346e+08, 0.0046875, 0.0101563, -106.765, 34.1277 9.348e+08, 0.00546875, 0.0101563, -126.977, 54.3251 9.35e+08, 0.00546875, 0.0101563, -103.487, 30.8681 Jiang Wenyi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Tue Jul 9 15:08:28 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Tue, 9 Jul 2013 19:08:28 +0400 Subject: kalibrate-uhd is OK In-Reply-To: <2013070916391221048818@ljshuoda.com> References: <2013070818055881331238@ljshuoda.com> <2013070916391221048818@ljshuoda.com> Message-ID: Does it show proper frequency offset? I suspect it might give wrong offsets due to different sampling frequency. On Tue, Jul 9, 2013 at 12:39 PM, jiangwy wrote: > I have downloaded the source code from > https://github.com/ttsou/kalibrate-uhd and built it. > It can work. > > By the way, my system is Ubuntu 12.04. > > ________________________________ > jiangwy > > From: Alexander Chemeris > Date: 2013-07-08 18:18 > To: wyjiang > CC: UmTRX > Subject: Re: How to Get libusrp > Jiang, > > libusrp is only used for USRP1, for UmTRX you should use UHD instead > of libusrp. A version of kal with the UHD support is available at > Thomas Tsou's repository, but we have never tested it with UmTRX. > Please let everyone know if you could get it working: > https://github.com/ttsou/kalibrate-uhd > > > > On Mon, Jul 8, 2013 at 2:05 PM, jiangwy wrote: >> Hi All, >> >> I want to build kal-v0.4.1. >> When use CXXFLAGS='-W -Wall -O3' ./configure >> Output errors: >> >> configure: error: Package requirements (usrp >= 3.3) were not met: >> >> No package 'usrp' found >> >> I'm using ubuntu 12.04. How can I install libusrp? >> ' sudo apt-get install libusrp-dev' not working! >> >> ________________________________ >> Jiang Wenyi > > > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ??? ??????? > http://fairwaves.ru -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From wyjiang at ljshuoda.com Wed Jul 10 08:32:15 2013 From: wyjiang at ljshuoda.com (jiangwy) Date: Wed, 10 Jul 2013 16:32:15 +0800 Subject: kalibrate-uhd is OK References: <2013070818055881331238@ljshuoda.com> <2013070916391221048818@ljshuoda.com>, Message-ID: <2013071016321497832612@ljshuoda.com> $ ./kal -s GSM900 linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.000-unknown -- Opening a UmTRX device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam kal: Scanning for GSM-900 base stations. -- Loaded /home/gsmrlab/.uhd/cal/rx_iq_cal_v0.1_38.A.csv chan: 9 (936.8MHz - 613Hz) power: 6418.15 chan: 12 (937.4MHz - 620Hz) power: 12117.75 chan: 83 (951.6MHz - 643Hz) power: 6134.54 chan: 84 (951.8MHz - 650Hz) power: 6960.67 chan: 85 (952.0MHz - 637Hz) power: 6300.51 chan: 86 (952.2MHz - 689Hz) power: 6887.63 chan: 88 (952.6MHz - 638Hz) power: 8117.66 chan: 90 (953.0MHz - 675Hz) power: 8154.05 chan: 92 (953.4MHz - 607Hz) power: 19237.80 chan: 93 (953.6MHz - 644Hz) power: 5920.77 chan: 95 (954.0MHz - 599Hz) power: 6156.47 chan: 97 (954.4MHz - 653Hz) power: 6850.15 chan: 99 (954.8MHz - 621Hz) power: 9758.86 chan: 101 (955.2MHz - 611Hz) power: 14142.66 chan: 103 (955.6MHz - 612Hz) power: 8194.55 chan: 105 (956.0MHz - 622Hz) power: 6900.42 chan: 106 (956.2MHz - 605Hz) power: 5699.32 chan: 109 (956.8MHz - 618Hz) power: 6037.80 chan: 110 (957.0MHz - 609Hz) power: 5979.92 chan: 112 (957.4MHz - 621Hz) power: 6714.83 chan: 114 (957.8MHz - 616Hz) power: 7686.20 chan: 116 (958.2MHz - 628Hz) power: 8990.54 chan: 118 (958.6MHz - 627Hz) power: 6750.71 chan: 120 (959.0MHz - 607Hz) power: 6218.47 chan: 124 (959.8MHz - 642Hz) power: 6230.74 jiangwy From: Alexander Chemeris Date: 2013-07-09 23:08 To: wyjiang CC: UmTRX Subject: Re: kalibrate-uhd is OK Does it show proper frequency offset? I suspect it might give wrong offsets due to different sampling frequency. On Tue, Jul 9, 2013 at 12:39 PM, jiangwy wrote: > I have downloaded the source code from > https://github.com/ttsou/kalibrate-uhd and built it. > It can work. > > By the way, my system is Ubuntu 12.04. > > ________________________________ > jiangwy > > From: Alexander Chemeris > Date: 2013-07-08 18:18 > To: wyjiang > CC: UmTRX > Subject: Re: How to Get libusrp > Jiang, > > libusrp is only used for USRP1, for UmTRX you should use UHD instead > of libusrp. A version of kal with the UHD support is available at > Thomas Tsou's repository, but we have never tested it with UmTRX. > Please let everyone know if you could get it working: > https://github.com/ttsou/kalibrate-uhd > > > > On Mon, Jul 8, 2013 at 2:05 PM, jiangwy wrote: >> Hi All, >> >> I want to build kal-v0.4.1. >> When use CXXFLAGS='-W -Wall -O3' ./configure >> Output errors: >> >> configure: error: Package requirements (usrp >= 3.3) were not met: >> >> No package 'usrp' found >> >> I'm using ubuntu 12.04. How can I install libusrp? >> ' sudo apt-get install libusrp-dev' not working! >> >> ________________________________ >> Jiang Wenyi > > > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / ??? ??????? > http://fairwaves.ru -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at tsou.cc Wed Jul 10 08:50:13 2013 From: tom at tsou.cc (Thomas Tsou) Date: Wed, 10 Jul 2013 04:50:13 -0400 Subject: kalibrate-uhd is OK In-Reply-To: <2013071016321497832612@ljshuoda.com> References: <2013070818055881331238@ljshuoda.com> <2013070916391221048818@ljshuoda.com> <2013071016321497832612@ljshuoda.com> Message-ID: On Wed, Jul 10, 2013 at 4:32 AM, jiangwy wrote: > kal: Scanning for GSM-900 base stations. > -- Loaded /home/gsmrlab/.uhd/cal/rx_iq_cal_v0.1_38.A.csv > chan: 9 (936.8MHz - 613Hz) power: 6418.15 > chan: 12 (937.4MHz - 620Hz) power: 12117.75 > chan: 83 (951.6MHz - 643Hz) power: 6134.54 > chan: 84 (951.8MHz - 650Hz) power: 6960.67 > chan: 85 (952.0MHz - 637Hz) power: 6300.51 > chan: 86 (952.2MHz - 689Hz) power: 6887.63 > chan: 88 (952.6MHz - 638Hz) power: 8117.66 > chan: 90 (953.0MHz - 675Hz) power: 8154.05 > chan: 92 (953.4MHz - 607Hz) power: 19237.80 > chan: 93 (953.6MHz - 644Hz) power: 5920.77 > chan: 95 (954.0MHz - 599Hz) power: 6156.47 > chan: 97 (954.4MHz - 653Hz) power: 6850.15 > chan: 99 (954.8MHz - 621Hz) power: 9758.86 > chan: 101 (955.2MHz - 611Hz) power: 14142.66 > chan: 103 (955.6MHz - 612Hz) power: 8194.55 > chan: 105 (956.0MHz - 622Hz) power: 6900.42 > chan: 106 (956.2MHz - 605Hz) power: 5699.32 > chan: 109 (956.8MHz - 618Hz) power: 6037.80 > chan: 110 (957.0MHz - 609Hz) power: 5979.92 > chan: 112 (957.4MHz - 621Hz) power: 6714.83 > chan: 114 (957.8MHz - 616Hz) power: 7686.20 > chan: 116 (958.2MHz - 628Hz) power: 8990.54 > chan: 118 (958.6MHz - 627Hz) power: 6750.71 > chan: 120 (959.0MHz - 607Hz) power: 6218.47 > chan: 124 (959.8MHz - 642Hz) power: 6230.74 The offsets look fine, but Kal is reporting an extremely dense GSM environment. I wonder if some of these are false values. May I ask where these measurements were taken? Thomas From wyjiang at ljshuoda.com Wed Jul 10 09:16:19 2013 From: wyjiang at ljshuoda.com (jiangwy) Date: Wed, 10 Jul 2013 17:16:19 +0800 Subject: kalibrate-uhd is OK References: <2013070818055881331238@ljshuoda.com> <2013070916391221048818@ljshuoda.com> <2013071016321497832612@ljshuoda.com>, Message-ID: <201307101716194980804@ljshuoda.com> It's tested in downtown of Beijing China. I think also there are no so GSM BTS. I will use test phone to do scanning later. jiangwy From: Thomas Tsou Date: 2013-07-10 16:50 To: wyjiang CC: Alexander Chemeris; UmTRX Subject: Re: Re: kalibrate-uhd is OK On Wed, Jul 10, 2013 at 4:32 AM, jiangwy wrote: > kal: Scanning for GSM-900 base stations. > -- Loaded /home/gsmrlab/.uhd/cal/rx_iq_cal_v0.1_38.A.csv > chan: 9 (936.8MHz - 613Hz) power: 6418.15 > chan: 12 (937.4MHz - 620Hz) power: 12117.75 > chan: 83 (951.6MHz - 643Hz) power: 6134.54 > chan: 84 (951.8MHz - 650Hz) power: 6960.67 > chan: 85 (952.0MHz - 637Hz) power: 6300.51 > chan: 86 (952.2MHz - 689Hz) power: 6887.63 > chan: 88 (952.6MHz - 638Hz) power: 8117.66 > chan: 90 (953.0MHz - 675Hz) power: 8154.05 > chan: 92 (953.4MHz - 607Hz) power: 19237.80 > chan: 93 (953.6MHz - 644Hz) power: 5920.77 > chan: 95 (954.0MHz - 599Hz) power: 6156.47 > chan: 97 (954.4MHz - 653Hz) power: 6850.15 > chan: 99 (954.8MHz - 621Hz) power: 9758.86 > chan: 101 (955.2MHz - 611Hz) power: 14142.66 > chan: 103 (955.6MHz - 612Hz) power: 8194.55 > chan: 105 (956.0MHz - 622Hz) power: 6900.42 > chan: 106 (956.2MHz - 605Hz) power: 5699.32 > chan: 109 (956.8MHz - 618Hz) power: 6037.80 > chan: 110 (957.0MHz - 609Hz) power: 5979.92 > chan: 112 (957.4MHz - 621Hz) power: 6714.83 > chan: 114 (957.8MHz - 616Hz) power: 7686.20 > chan: 116 (958.2MHz - 628Hz) power: 8990.54 > chan: 118 (958.6MHz - 627Hz) power: 6750.71 > chan: 120 (959.0MHz - 607Hz) power: 6218.47 > chan: 124 (959.8MHz - 642Hz) power: 6230.74 The offsets look fine, but Kal is reporting an extremely dense GSM environment. I wonder if some of these are false values. May I ask where these measurements were taken? Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Wed Jul 10 14:59:21 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 10 Jul 2013 18:59:21 +0400 Subject: LMS6002DCalibration In-Reply-To: <2013070920153569485530@ljshuoda.com> References: <2013070920153569485530@ljshuoda.com> Message-ID: Jiang, These files are internal for UHD and should be used by UHD automatically. I recommend you to calibrate the LMS chip itself, as described in LMS6002Dr2-Programming and Calibration Guide: https://github.com/chemeris/lms6002-documentation For sccessing LMS registers and some common operations you could use umtrx_lms.py script from this repo: https://github.com/fairwaves/umtrx_scripts/tree/master/python_lib Note, that automatic calibrations are performed by UHD automatically on every start. On Tue, Jul 9, 2013 at 4:15 PM, jiangwy wrote: > Hi All, > > I use the following functions to calibration > uhd_cal_tx_dc_offset > uhd_cal_tx_iq_balance > uhd_cal_rx_iq_balance > > I got three *.csv files in .uhd/cal/{rx_iq_cal_v0.1_38.A.csv > tx_iq_cal_v0.1_38.A.csv tx_dc_cal_v0.1_38.A.csv} > How can I use the contents in these files? > > ~$ cat .uhd/cal/tx_dc_cal_v0.1_38.A.csv > name, TX Frontend Calibration > serial, 38.A > timestamp, 1373370847 > version, 0, 1 > DATA STARTS HERE > lo_frequency, correction_real, correction_imag, measured, delta > 9.3e+08, 0.0046875, 0.0101563, -105.406, 32.9285 > 9.302e+08, 0.0046875, 0.0101563, -99.0923, 26.9516 > 9.304e+08, 0.0046875, 0.0101563, -102.352, 29.6946 > 9.306e+08, 0.0046875, 0.0101563, -104.045, 31.523 > 9.308e+08, 0.0046875, 0.0101563, -103.354, 30.8814 > 9.31e+08, 0.0046875, 0.0101563, -108.024, 35.4699 > 9.312e+08, 0.0046875, 0.0101563, -110.951, 38.5388 > 9.314e+08, 0.00546875, 0.0101563, -99.2159, 26.6738 > 9.316e+08, 0.0046875, 0.0101563, -103.085, 30.5324 > 9.318e+08, 0.00546875, 0.0101563, -104.854, 32.0656 > 9.32e+08, 0.0046875, 0.0101563, -111.759, 38.9142 > 9.322e+08, 0.0046875, 0.0101563, -101.731, 29.0089 > 9.324e+08, 0.0046875, 0.0101563, -107.722, 35.0989 > 9.326e+08, 0.00546875, 0.0101563, -107.25, 34.6358 > 9.328e+08, 0.0046875, 0.0101563, -109.739, 37.0523 > 9.33e+08, 0.0046875, 0.0101563, -111.463, 38.951 > 9.332e+08, 0.0046875, 0.0101563, -112.302, 39.8637 > 9.334e+08, 0.0046875, 0.0101563, -110.057, 37.4139 > 9.336e+08, 0.0046875, 0.0101563, -103.617, 31.0364 > 9.338e+08, 0.0046875, 0.0101563, -104.47, 31.8644 > 9.34e+08, 0.00546875, 0.0101563, -103.053, 30.3361 > 9.342e+08, 0.0046875, 0.0101563, -106.426, 33.7277 > 9.344e+08, 0.0046875, 0.0101563, -112.463, 39.6667 > 9.346e+08, 0.0046875, 0.0101563, -106.765, 34.1277 > 9.348e+08, 0.00546875, 0.0101563, -126.977, 54.3251 > 9.35e+08, 0.00546875, 0.0101563, -103.487, 30.8681 > > ________________________________ > Jiang Wenyi -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From alexander.chemeris at gmail.com Sun Jul 14 20:11:28 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 15 Jul 2013 00:11:28 +0400 Subject: Crash of UmTRX transceiver with dual TRX In-Reply-To: References: <51DA72E3.1080708@eversberg.eu> <51DA8F2B.1080701@eversberg.eu> <51DAB170.6050908@eversberg.eu> <51DAB76D.2050709@eversberg.eu> <51DABE40.9020802@eversberg.eu> <51DAF103.7010604@eversberg.eu> <51DB0F06.5050706@eversberg.eu> <51DB1AAC.8060902@eversberg.eu> Message-ID: On Tue, Jul 9, 2013 at 12:35 AM, Thomas Tsou wrote: > IMO, the preferred solution is to replace thread abstraction or make > the signals work. I think the latter was the original intention with > shutdown triggering on pthread_cancel(), but for whatever reason that > was never implemented. I've posted a big patchset for this to the OpenBSC mailing list. A bit more effort and it'll be working. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From wyjiang at ljshuoda.com Tue Jul 16 12:04:54 2013 From: wyjiang at ljshuoda.com (jiangwy) Date: Tue, 16 Jul 2013 20:04:54 +0800 Subject: transceiver starting error Message-ID: <2013071620045413018718@ljshuoda.com> Hi All, I install all the OpenBTS and UHD packages according to manual pages. When I start transceiver, it output some errors and exit. $ sudo ./transceiver 1 linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.000-unknown ALERT 3048163072 19:59:34.7 UHDDevice.cpp:345:set_rates: Failed to set master clock rate ALERT 3048163072 19:59:34.7 UHDDevice.cpp:346:set_rates: Actual clock rate 1.3e+07 ALERT 3048163072 19:59:34.7 runTransceiver.cpp:94:main: Transceiver exiting... Jiang Wenyi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Sat Jul 20 14:27:56 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 20 Jul 2013 18:27:56 +0400 Subject: transceiver starting error In-Reply-To: <2013071620045413018718@ljshuoda.com> References: <2013071620045413018718@ljshuoda.com> Message-ID: Jiang, Look like you're using a wrong transceiver version. Please use 'umtrx' (default) branch from here: https://github.com/fairwaves/osmo-trx On Tue, Jul 16, 2013 at 4:04 PM, jiangwy wrote: > Hi All, > > I install all the OpenBTS and UHD packages according to manual pages. When I > start transceiver, it output some errors and exit. > > $ sudo ./transceiver 1 > linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.000-unknown > > ALERT 3048163072 19:59:34.7 UHDDevice.cpp:345:set_rates: Failed to set > master clock rate > ALERT 3048163072 19:59:34.7 UHDDevice.cpp:346:set_rates: Actual clock rate > 1.3e+07 > ALERT 3048163072 19:59:34.7 runTransceiver.cpp:94:main: Transceiver > exiting... > > > ________________________________ > Jiang Wenyi > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From wyjiang at ljshuoda.com Tue Jul 23 10:54:27 2013 From: wyjiang at ljshuoda.com (jiangwy) Date: Tue, 23 Jul 2013 18:54:27 +0800 Subject: How to syncronizing two UmTRXs Message-ID: <2013072318542795237710@ljshuoda.com> Hi All, I have two UmTRXs v2. How to make the clock of them syncronized? Jiang Wenyi -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreysviyaz at gmail.com Tue Jul 23 14:59:36 2013 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Tue, 23 Jul 2013 18:59:36 +0400 Subject: How to syncronizing two UmTRXs In-Reply-To: <2013072318542795237710@ljshuoda.com> References: <2013072318542795237710@ljshuoda.com> Message-ID: Hi Jiang Wenyi. To synchronize clock of several UmTRX you have to leave one of them in master mode, but all others must be switched to slave mode. Master/slave control switch for 26MHz clock is S3(MHz). I/O connector for 26 MHz clock is X7. In case of master mode X7 becomes output and input in case of slave mode. To set master mode turn switch S3 to the downward and to upward for the slave mode. Please find text on the PCB board to be sure. BTW, if you would like to use external clock source then all of UmTRX's must be in slave mode, i.e. their clock connectors must be inputs. Best regards, Andrey Sviyazov. 2013/7/23 jiangwy > ** > Hi All, > > I have two UmTRXs v2. How to make the clock of them syncronized? > > ------------------------------ > Jiang Wenyi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreysviyaz at gmail.com Tue Jul 23 15:05:03 2013 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Tue, 23 Jul 2013 19:05:03 +0400 Subject: How to syncronizing two UmTRXs In-Reply-To: References: <2013072318542795237710@ljshuoda.com> Message-ID: Hi Jiang Wenyi. Sorry, I forget to say about cable. You have to use UFL-UFL cable to connect X7 of all synchronized UmTRX's. It will be simple cable in case of two UmTRX and star (in parallel) if more then two. Best regards, Andrey Sviyazov. 2013/7/23 Andrey Sviyazov > Hi Jiang Wenyi. > > To synchronize clock of several UmTRX you have to leave one of them in > master mode, > but all others must be switched to slave mode. > Master/slave control switch for 26MHz clock is S3(MHz). > I/O connector for 26 MHz clock is X7. > In case of master mode X7 becomes output and input in case of slave mode. > To set master mode turn switch S3 to the downward and to upward for the > slave mode. > Please find text on the PCB board to be sure. > > BTW, if you would like to use external clock source then all of UmTRX's > must be in slave mode, > i.e. their clock connectors must be inputs. > > Best regards, > Andrey Sviyazov. > > > 2013/7/23 jiangwy > >> ** >> Hi All, >> >> I have two UmTRXs v2. How to make the clock of them syncronized? >> >> ------------------------------ >> Jiang Wenyi >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyjiang at ljshuoda.com Wed Jul 24 00:42:04 2013 From: wyjiang at ljshuoda.com (jiangwy) Date: Wed, 24 Jul 2013 08:42:04 +0800 Subject: How to syncronizing two UmTRXs References: <2013072318542795237710@ljshuoda.com>, Message-ID: <201307240842046699745@ljshuoda.com> Andrey Sviyazov If I connect X7 between master and slave, then the clock of master is 13MHz and the clock of slave is 26MHz. Is that right? Best regards, Jiang Wenyi From: Andrey Sviyazov Date: 2013-07-23 22:59 To: wyjiang CC: UmTRX Subject: Re: How to syncronizing two UmTRXs Hi Jiang Wenyi. To synchronize clock of several UmTRX you have to leave one of them in master mode, but all others must be switched to slave mode. Master/slave control switch for 26MHz clock is S3(MHz). I/O connector for 26 MHz clock is X7. In case of master mode X7 becomes output and input in case of slave mode. To set master mode turn switch S3 to the downward and to upward for the slave mode. Please find text on the PCB board to be sure. BTW, if you would like to use external clock source then all of UmTRX's must be in slave mode, i.e. their clock connectors must be inputs. Best regards, Andrey Sviyazov. 2013/7/23 jiangwy Hi All, I have two UmTRXs v2. How to make the clock of them syncronized? Jiang Wenyi -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreysviyaz at gmail.com Wed Jul 24 04:44:40 2013 From: andreysviyaz at gmail.com (Andrey Sviyazov) Date: Wed, 24 Jul 2013 08:44:40 +0400 Subject: How to syncronizing two UmTRXs In-Reply-To: <201307240842046699745@ljshuoda.com> References: <2013072318542795237710@ljshuoda.com> <201307240842046699745@ljshuoda.com> Message-ID: Hi Jiang Wenyi. System clock of UmTRX is 26 MHz. And the same for synchronizing clock I/O. Thereafter system clock devided by 2 in each UnTRX to get 13 MHz interleaved I/Q sample clock. Best regards, Andrey Sviyazov. (Sent from mobile) 24.07.2013 4:42 ???????????? "jiangwy" ???????: > > Andrey Sviyazov > > If I connect X7 between master and slave, then the clock of master is 13MHz and the clock of slave is 26MHz. Is that right? > > Best regards, > Jiang Wenyi > > From: Andrey Sviyazov > Date: 2013-07-23 22:59 > To: wyjiang > CC: UmTRX > Subject: Re: How to syncronizing two UmTRXs > Hi Jiang Wenyi. > > To synchronize clock of several UmTRX you have to leave one of them in master mode, > but all others must be switched to slave mode. > Master/slave control switch for 26MHz clock is S3(MHz). > I/O connector for 26 MHz clock is X7. > In case of master mode X7 becomes output and input in case of slave mode. > To set master mode turn switch S3 to the downward and to upward for the slave mode. > Please find text on the PCB board to be sure. > > BTW, if you would like to use external clock source then all of UmTRX's must be in slave mode, > i.e. their clock connectors must be inputs. > > Best regards, > Andrey Sviyazov. > > > 2013/7/23 jiangwy >> >> Hi All, >> >> I have two UmTRXs v2. How to make the clock of them syncronized? >> >> ________________________________ >> Jiang Wenyi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyjiang at ljshuoda.com Wed Jul 24 05:30:08 2013 From: wyjiang at ljshuoda.com (jiangwy) Date: Wed, 24 Jul 2013 13:30:08 +0800 Subject: How to syncronizing two UmTRXs References: <2013072318542795237710@ljshuoda.com> <201307240842046699745@ljshuoda.com>, Message-ID: <2013072413300892228810@ljshuoda.com> Hi Andrey Sviyazov, I understand now. I have seen the code in UHDDevice.cpp as following: const double master_clk_rt = 13e6; So I have made a mistake. jiangwy From: Andrey Sviyazov Date: 2013-07-24 12:44 To: wyjiang CC: umtrx Subject: Re: Re: How to syncronizing two UmTRXs Hi Jiang Wenyi. System clock of UmTRX is 26 MHz. And the same for synchronizing clock I/O. Thereafter system clock devided by 2 in each UnTRX to get 13 MHz interleaved I/Q sample clock. Best regards, Andrey Sviyazov. (Sent from mobile) 24.07.2013 4:42 ???????????? "jiangwy" ???????: > > Andrey Sviyazov > > If I connect X7 between master and slave, then the clock of master is 13MHz and the clock of slave is 26MHz. Is that right? > > Best regards, > Jiang Wenyi > > From: Andrey Sviyazov > Date: 2013-07-23 22:59 > To: wyjiang > CC: UmTRX > Subject: Re: How to syncronizing two UmTRXs > Hi Jiang Wenyi. > > To synchronize clock of several UmTRX you have to leave one of them in master mode, > but all others must be switched to slave mode. > Master/slave control switch for 26MHz clock is S3(MHz). > I/O connector for 26 MHz clock is X7. > In case of master mode X7 becomes output and input in case of slave mode. > To set master mode turn switch S3 to the downward and to upward for the slave mode. > Please find text on the PCB board to be sure. > > BTW, if you would like to use external clock source then all of UmTRX's must be in slave mode, > i.e. their clock connectors must be inputs. > > Best regards, > Andrey Sviyazov. > > > 2013/7/23 jiangwy >> >> Hi All, >> >> I have two UmTRXs v2. How to make the clock of them syncronized? >> >> ________________________________ >> Jiang Wenyi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyjiang at ljshuoda.com Fri Jul 26 11:41:29 2013 From: wyjiang at ljshuoda.com (jiangwy) Date: Fri, 26 Jul 2013 19:41:29 +0800 Subject: How about the UmSEL Message-ID: <2013072619412984670121@ljshuoda.com> Hi Alexander Chemeris, How about the UmSEL? What time can We try to use the UmSEL? Best Regards. Jiang Wenyi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Sat Jul 27 18:00:41 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 27 Jul 2013 22:00:41 +0400 Subject: Public installation powered by UmTRX Message-ID: Hi all, Just want to let you know what kept us busy recently - we've deployed UmTRX based UmSITE base station at two big events in the Netherlands: http://fairwaves.ru/news/2013-07-24-open-source-telecom-rocks-at-Dutch-events.php The installation used UmTRX and 2W amplifiers for RF hardware and ran OsmoBTS/OsmoNITB/LCR/Freeswitch stack for software. A couple of bugs fixed, a couple of bugs workarounded, but generally it provided good service and users are very happy. More news and more real life testing to come! -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru From alexander.chemeris at gmail.com Sat Jul 27 18:03:20 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Sat, 27 Jul 2013 22:03:20 +0400 Subject: How about the UmSEL In-Reply-To: <2013072619412984670121@ljshuoda.com> References: <2013072619412984670121@ljshuoda.com> Message-ID: Hi Jiang, Our UmSEL development was somewhat delayed, as we were busy with installations (see my previous e-mail). We should be able to sell few UmSEL units at the second half of Aug and more in Sept. The price is not known yet, though. On Fri, Jul 26, 2013 at 3:41 PM, jiangwy wrote: > Hi Alexander Chemeris, > > How about the UmSEL? What time can We try to use the UmSEL? > > Best Regards. > > ________________________________ > Jiang Wenyi -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru