You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(10) |
Nov
(7) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(38) |
Feb
(14) |
Mar
(25) |
Apr
(59) |
May
(25) |
Jun
(36) |
Jul
(39) |
Aug
(63) |
Sep
(98) |
Oct
(207) |
Nov
(116) |
Dec
(163) |
2010 |
Jan
(101) |
Feb
(105) |
Mar
(88) |
Apr
(68) |
May
(87) |
Jun
(46) |
Jul
(114) |
Aug
(183) |
Sep
(86) |
Oct
(70) |
Nov
(145) |
Dec
(78) |
2011 |
Jan
(80) |
Feb
(104) |
Mar
(87) |
Apr
(111) |
May
(91) |
Jun
(186) |
Jul
(204) |
Aug
(268) |
Sep
(91) |
Oct
(343) |
Nov
(351) |
Dec
(212) |
2012 |
Jan
(215) |
Feb
(205) |
Mar
(259) |
Apr
(157) |
May
(170) |
Jun
(155) |
Jul
(274) |
Aug
(172) |
Sep
(185) |
Oct
(162) |
Nov
(203) |
Dec
(218) |
2013 |
Jan
(278) |
Feb
(193) |
Mar
(155) |
Apr
(177) |
May
(204) |
Jun
(260) |
Jul
(127) |
Aug
(180) |
Sep
(185) |
Oct
(194) |
Nov
(84) |
Dec
(111) |
2014 |
Jan
(148) |
Feb
(165) |
Mar
(182) |
Apr
(365) |
May
(159) |
Jun
(224) |
Jul
(142) |
Aug
(82) |
Sep
(129) |
Oct
(128) |
Nov
(42) |
Dec
(180) |
2015 |
Jan
(198) |
Feb
(153) |
Mar
(98) |
Apr
(76) |
May
(54) |
Jun
(58) |
Jul
(42) |
Aug
(37) |
Sep
(19) |
Oct
(44) |
Nov
(49) |
Dec
(17) |
2016 |
Jan
(59) |
Feb
(50) |
Mar
(72) |
Apr
(33) |
May
(98) |
Jun
(52) |
Jul
(80) |
Aug
(28) |
Sep
(26) |
Oct
(44) |
Nov
(25) |
Dec
(33) |
2017 |
Jan
(108) |
Feb
(61) |
Mar
(42) |
Apr
(29) |
May
(34) |
Jun
(8) |
Jul
(13) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(6) |
Dec
(5) |
2018 |
Jan
(8) |
Feb
(6) |
Mar
(13) |
Apr
(10) |
May
(13) |
Jun
(10) |
Jul
(6) |
Aug
(1) |
Sep
(4) |
Oct
(11) |
Nov
(8) |
Dec
|
2019 |
Jan
(4) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(3) |
Jun
(6) |
Jul
(1) |
Aug
(8) |
Sep
(8) |
Oct
(2) |
Nov
(1) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(3) |
2021 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(6) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Uri S. <ur...@se...> - 2010-02-21 20:49:00
|
Tomas, We could always trace it back to having a too strong signal coming down the rx path: transmitting using a power amp and no diplexer; connecting a cable from tx to rx with no attenuator; etc. Uri ________________________________________ From: Tomas Kopsa [de...@vo...] Sent: Sunday, February 21, 2010 8:24 PM To: ope...@li... Subject: Re: [Openbts-discuss] USRP issue Uri - > This happened to us a couple of times. You definitely fried the amp (U4). If it fries, it also short-circuits the 3V power it gets. True mayhem ensues ... > Replacing the chip helps (not for the cardiacly challenged :-) - better leave that to Matt, if possible). > Uri > thanks for that advice ! So I have surely fried U4 on both daughterboards by changing antenna under working arrangements. May I ask, how this happened to you ? I wonder if those accidents could be prevented by powering off USRP when reconnecting RX2 channel. Does it help replacing only U4 or there is necessary to replace U2 as well ? I have attached a picture - U4 package seems to be not burned, but I guess its not visible :) Matt - >> I don't understand why you expect anything to work at all with no >> clock connected. Absolutely nothing will work if there is no clock. >> How could a PLL possibly lock if you take away the reference clock? >> I'm sorry for my obscurity. The idea was to present that the software results with / without clock are different and this issue is probably not a clock problem - as Alexander mentioned. Thanks. -- Tomas |
From: Tomas K. <de...@vo...> - 2010-02-21 18:24:25
|
Uri - > This happened to us a couple of times. You definitely fried the amp (U4). If it fries, it also short-circuits the 3V power it gets. True mayhem ensues ... > Replacing the chip helps (not for the cardiacly challenged :-) - better leave that to Matt, if possible). > Uri > thanks for that advice ! So I have surely fried U4 on both daughterboards by changing antenna under working arrangements. May I ask, how this happened to you ? I wonder if those accidents could be prevented by powering off USRP when reconnecting RX2 channel. Does it help replacing only U4 or there is necessary to replace U2 as well ? I have attached a picture - U4 package seems to be not burned, but I guess its not visible :) Matt - >> I don't understand why you expect anything to work at all with no >> clock connected. Absolutely nothing will work if there is no clock. >> How could a PLL possibly lock if you take away the reference clock? >> I'm sorry for my obscurity. The idea was to present that the software results with / without clock are different and this issue is probably not a clock problem - as Alexander mentioned. Thanks. -- Tomas |
From: Uri S. <ur...@se...> - 2010-02-21 13:25:18
|
This happened to us a couple of times. You definitely fried the amp (U4). If it fries, it also short-circuits the 3V power it gets. True mayhem ensues ... Replacing the chip helps (not for the cardiacly challenged :-) - better leave that to Matt, if possible). Uri -----Original Message----- From: Alexander Chemeris [mailto:ale...@gm...] Sent: Sunday, February 21, 2010 1:35 PM To: ope...@li... Subject: Re: [Openbts-discuss] USRP issue Matt, On Sun, Feb 21, 2010 at 08:02, Matt Ettus <ma...@et...> wrote: > I don't understand why you expect anything to work at all with no > clock connected. Absolutely nothing will work if there is no clock. > How could a PLL possibly lock if you take away the reference clock? I think idea of the test without a clock was to show that software behavior is different from the test when clock is present. -- Regards, Alexander Chemeris. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Openbts-discuss mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openbts-discuss |
From: Alexander C. <ale...@gm...> - 2010-02-21 11:35:28
|
Matt, On Sun, Feb 21, 2010 at 08:02, Matt Ettus <ma...@et...> wrote: > I don't understand why you expect anything to work at all with no clock > connected. Absolutely nothing will work if there is no clock. How > could a PLL possibly lock if you take away the reference clock? I think idea of the test without a clock was to show that software behavior is different from the test when clock is present. -- Regards, Alexander Chemeris. |
From: Matt E. <ma...@et...> - 2010-02-21 05:02:36
|
Tomas, I don't understand why you expect anything to work at all with no clock connected. Absolutely nothing will work if there is no clock. How could a PLL possibly lock if you take away the reference clock? Matt On 02/20/2010 04:34 PM, Tomas Kopsa wrote: > Matt, > thanks for reply. > > I was using USRP with external 52MHz clock about 3 months without > problems mainly for OpenBTS project (gnuradio 3.2.2 with 52MHz clock > modifications). > But 2 weeks ago I've got wrecked idea to use usrp_fft.py to measure some > RFID system. I run "./usrp_fft.py -R B" and during that time I have > switched current receiving antena (on RX2 side B) > to another antena (with correct frequency range and aerial matching); > gain of this antenna is probably better then the previous but I'm not > sure how much - I'm using it without problems with GPRS modem. > I don't remember which data I have seen, but it was probably crap. Since > that time I'm worried with the issue. > > If I run OpenBTS with external clock (and there is connected only > daugherboard side A) I get messages that RX and TX was tuned well and I > can scan the OpenBTS network with real networks > - this is in my opinion proof that it isn't a clock problem. If I run > OpenBTS with both daugherboards(no matter if clock is connected), TX, RX > and power fails to tune - probably because RX tune fails as first; I > can't scan OpenBTS. > If I run OpenBTS only with daughterboard A and disconnect clock, only TX > fails to tune - but everything else including RX is tuned well, I can't > scan OpenBTS. > > I tried usrp_siggen.py: > > /- connected both daugherboards with connected clock or only connected > daugherboard side A with clock/ > > [root@openBTS python]# ./usrp_siggen.py -f 920M > dac_rate(): 104000000 > dac_rate(): 104000000 > Using TX d'board A: Flex 900 Tx > dac_rate(): 104000000 > <nothing was happening there, I was waiting ~ 10 minutes> > > /- disconnected clock/ > > [root@openBTS python]# ./usrp_siggen.py -f 920M > dac_rate(): 104000000 > dac_rate(): 104000000 > Using TX d'board A: Flex 900 Tx > dac_rate(): 104000000 > Failed to set RF frequency > [root@openBTS python]# > > > /- disconnected both daughterboards or only connected daughterboard side > B , connected clock/ > > [root@openBTS python]# ./usrp_siggen.py -f 920M > dac_rate(): 104000000 > dac_rate(): 104000000 > Using TX d'board A:<none> > dac_rate(): 104000000 > <nothing was happening ...> > > Is that possible that I have "toasted" something by changing antenna ? > If yes, could it be daugherboard or even USRP motherboard ? > I'm not sure if the daughterboard connected as TX (side A) during "the > accident" was with good RX - not previously "toasted" (I had some > problem with tuning OpenBTS, > it was maybe only software issue, maybe hardware fixed by daughterboard > switch). So I don't know if there isn't a curious situation with both > daughterboard's "toasted" RX2. > > If there are any more tests I can do, please let me know. > > Thanks, > Tomas > > > > > >> >> Tomas, >> >> It is hard to say what happened. How do you know this is not a problem >> with the clock? For whatever reason, the daughterboard is failing to >> lock. What happens if you try to transmit: >> >> usrp_siggen.py -f 920M >> >> Does it report lock? >> >> Can you see the clock coming into the PLL chip? >> >> Are you using a 52 MHz clock or a 64 MHz one? Does the software know >> about this? If it thinks it is getting 64 MHz but is really getting 52 >> MHz (or vice versa) it will not lock properly. >> >> Matt >> >> >> On 02/18/2010 03:15 PM, Tomas Kopsa wrote: >>> If there is a daughterboard present I see "flicking blue wave" with 0MHz >>> central freq a message Failed to set initial frequency, just like in >>> attached screenshot. >>> If daughterboard is missing USRP FFT tunes on 900MHz correctly but the >>> graph area is blank - its equivalent with all kal-0.2 test cases (posted >>> previously): >>> >>> error: fcch not detected in 20 frames ~ USRP FFT tuned with blank >>> graph area >>> error: usrp_source::tune ~ "flicking blue wave" with faled tune - >>> "Failed to set initial frequency" >>> >>> >>> >>>> What do you see when you run usrp_fft.py on the tower frequency? >>>> (usrp_fft.py is part of the standard gnuradio installation.) >>>> >>>> Does it look like you can still see the signal from the tower? >>>> >>>> >>>> Quoting Tomas Kopsa (de...@vo...): >>>> >>>>> - All >>>>> >>>>> I have some (for me weird) issue with USRP and I will be glad if >>>>> somebody will suggest me anything. >>>>> I was changing antenna (50ohm aerial matching) during execution >>>>> usrp_fft.py and since that time I'm unable to tune RX channel with any >>>>> of two RFX900 (I have USRP + 2xRFX900). >>>>> >>>>> I have installed new machine with Fedora 11, gnuradio-3.2.2, OpenBTS >>>>> 2.5.3 to exclude corrupted build failure. So I have the same results >>>>> with the original SW setup. >>>>> 2) It's not a clock problem, reasons are described later. >>>>> >>>>> I have signed one daughterboard as DB1, second as DB2 and made some >>>>> test: >>>>> >>>>> *Test case 1 - only DB1 is connected in USRP side A* >>>>> >>>>> Attempt to run OpenBTS: >>>>> >>>>> Starting the system... >>>>> 1266436555.5621 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD POWEROFF >>>>> 1266436555.6352 FORCE 3087378128 Logger.cpp:90:gSetLogFile: setting >>>>> log >>>>> path to /dev/null >>>>> 1266436556.5832 WARNING 3086686016 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266436557.6049 WARNING 3086686016 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266436558.6276 WARNING 3086686016 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266436559.6494 WARNING 3086686016 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> dac_rate(): 104000000 >>>>> dac_rate(): 104000000 >>>>> 1266436560.6708 WARNING 3086686016 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266436560.6752 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETTSC 0 >>>>> 1266436560.6798 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD RXTUNE 890200 >>>>> 1266436560.6922 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD TXTUNE 935200 >>>>> dac_rate(): 104000000 >>>>> 1266436560.7206 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETSLOT 0 5 >>>>> 1266436560.7247 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD POWERON >>>>> 1266436560.7852 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETPOWER 0 >>>>> 1266436560.7899 INFO 3086686016 GSMLogicalChannel.cpp:42:open: >>>>> >>>>> I can scan OpenBTS with MS, but cant camp (there is no uplink - RX >>>>> channel), it is also a proof that clock unit works well. Without >>>>> connected clock there is a failure TXTUNE failed with status 1 >>>>> If I disconnect USRP power (USB cable) , I get following messages, >>>>> which >>>>> is correct. >>>>> fusb::_reap: No such device >>>>> fusb::_reap: No such device >>>>> fusb::_reap: No such device >>>>> >>>>> Attemtps to run Kalibrator: >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946600000 >>>>> USRP side: B >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: RX2 >>>>> Sample rate: 270833.343750 >>>>> error: fcch not detected in 20 frames >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX >>>>> USRP side: B >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: TX/RX >>>>> Sample rate: 270833.343750 >>>>> error: fcch not detected in 20 frames >>>>> >>>>> ARFCN on side B cannot be scanned because there is no DB connected but >>>>> works. >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A >>>>> USRP side: A >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: RX2 >>>>> error: usrp_source::tune >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX >>>>> USRP side: A >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: TX/RX >>>>> error: usrp_source::tune >>>>> >>>>> DB is connected to side A, but tune() fails. >>>>> >>>>> *Test case 2 - only DB1 is connected in USRP side B >>>>> >>>>> *Attempt to run OpenBTS: >>>>> * >>>>> *Starting the system... >>>>> 1266438092.1164 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD POWEROFF >>>>> 1266438092.1217 FORCE 3086087888 Logger.cpp:90:gSetLogFile: setting >>>>> log >>>>> path to /dev/null >>>>> 1266438093.1657 WARNING 3086882624 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266438094.1880 WARNING 3086882624 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266438095.2100 WARNING 3086882624 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266438096.2316 WARNING 3086882624 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> dac_rate(): 104000000 >>>>> dac_rate(): 104000000 >>>>> 1266438097.2548 WARNING 3086882624 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266438097.2590 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETTSC 0 >>>>> 1266438097.2632 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD RXTUNE 890200 >>>>> 1266438097.2763 ALARM 3086882624 TRXManager.cpp:359:tune: RXTUNE >>>>> failed >>>>> with status 1 >>>>> 1266438097.2764 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETSLOT 0 5 >>>>> 1266438097.2806 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD POWERON >>>>> 1266438097.2847 ALARM 3086882624 TRXManager.cpp:411:powerOn: POWERON >>>>> failed with status 1 >>>>> 1266438097.2847 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETPOWER 0 >>>>> 1266438097.2888 ALARM 3086882624 TRXManager.cpp:424:setPower: SETPOWER >>>>> failed with status 1 >>>>> 1266438097.2891 INFO 3086882624 GSMLogicalChannel.cpp:42:open: >>>>> >>>>> So there are lots of failures and when USRP is disconnected, CLI >>>>> detects >>>>> nothing* *and is still active. >>>>> >>>>> Attemtps to run Kalibrator: >>>>> [root@openBTS kal-0.2]# ./kal -f 946600000 >>>>> USRP side: B >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: RX2 >>>>> error: usrp_source::tune >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX >>>>> USRP side: B >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: TX/RX >>>>> error: usrp_source::tune >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A >>>>> USRP side: A >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: RX2 >>>>> Sample rate: 270833.343750 >>>>> error: fcch not detected in 20 frames >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX >>>>> USRP side: A >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: TX/RX >>>>> Sample rate: 270833.343750 >>>>> error: fcch not detected in 20 frames* >>>>> >>>>> **Test case 3 - only DB2 is connected in USRP side A* >>>>> * >>>>> *OpenBTS* >>>>> >>>>> *Starting the system... >>>>> 1266438821.8364 FORCE 3087906512 Logger.cpp:90:gSetLogFile: setting >>>>> log >>>>> path to /dev/null >>>>> 1266438821.8369 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD POWEROFF >>>>> 1266438822.8586 WARNING 3087877952 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266438823.8806 WARNING 3087877952 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266438824.9027 WARNING 3087877952 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266438825.9245 WARNING 3087877952 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> dac_rate(): 104000000 >>>>> dac_rate(): 104000000 >>>>> 1266438826.9477 WARNING 3087877952 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266438826.9522 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETTSC 0 >>>>> 1266438826.9568 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD RXTUNE 890200 >>>>> 1266438826.9693 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD TXTUNE 935200 >>>>> dac_rate(): 104000000 >>>>> 1266438826.9816 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETSLOT 0 5 >>>>> 1266438826.9858 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD POWERON >>>>> 1266438827.1147 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETPOWER 0 >>>>> 1266438827.1248 INFO 3087877952 GSMLogicalChannel.cpp:42:open:* >>>>> >>>>> *Its the same like test case 1,* *I can scan OpenBTS with MS and >>>>> disconnected USRP power (USB cable) messes with errors: >>>>> fusb::_reap: No such device >>>>> fusb::_reap: No such device >>>>> fusb::_reap: No such device >>>>> >>>>> Kalibrator: >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946000000 >>>>> USRP side: B >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: RX2 >>>>> Sample rate: 270833.343750 >>>>> error: fcch not detected in 20 frames >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX >>>>> USRP side: B >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: TX/RX >>>>> Sample rate: 270833.343750 >>>>> error: fcch not detected in 20 frames >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A >>>>> USRP side: A >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: RX2 >>>>> error: usrp_source::tune >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX >>>>> USRP side: A >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: TX/RX >>>>> error: usrp_source::tune >>>>> >>>>> *Test case 4 - only DB2 is connected in USRP side B >>>>> >>>>> *OpenBTS* >>>>> * >>>>> Starting the system... >>>>> 1266439630.8798 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD POWEROFF >>>>> 1266439630.8816 FORCE 3087140560 Logger.cpp:90:gSetLogFile: setting >>>>> log >>>>> path to /dev/null >>>>> 1266439631.9024 WARNING 3087316800 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266439632.9264 WARNING 3087316800 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266439633.9491 WARNING 3087316800 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266439634.9707 WARNING 3087316800 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> dac_rate(): 104000000 >>>>> dac_rate(): 104000000 >>>>> 1266439635.9923 WARNING 3087316800 >>>>> TRXManager.cpp:271:sendCommandPacket: >>>>> retrying transceiver command after response timeout >>>>> 1266439635.9969 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETTSC 0 >>>>> 1266439636.0023 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD RXTUNE 890200 >>>>> 1266439636.0313 ALARM 3087316800 TRXManager.cpp:359:tune: RXTUNE >>>>> failed >>>>> with status 1 >>>>> 1266439636.0314 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETSLOT 0 5 >>>>> 1266439636.0356 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD POWERON >>>>> 1266439636.0397 ALARM 3087316800 TRXManager.cpp:411:powerOn: POWERON >>>>> failed with status 1 >>>>> 1266439636.0397 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>>> command CMD SETPOWER 0 >>>>> 1266439636.0439 ALARM 3087316800 TRXManager.cpp:424:setPower: SETPOWER >>>>> failed with status 1 >>>>> 1266439636.0442 INFO 3087316800 GSMLogicalChannel.cpp:42:open: * >>>>> >>>>> *Same like test case 2 when USRP is disconnected, CLI detects nothing* >>>>> *and is still active. >>>>> * >>>>> *Kalibrator >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946000000 >>>>> USRP side: B >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: RX2 >>>>> error: usrp_source::tune >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX >>>>> USRP side: B >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: TX/RX >>>>> error: usrp_source::tune >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A >>>>> USRP side: A >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: RX2 >>>>> Sample rate: 270833.343750 >>>>> error: fcch not detected in 20 frames >>>>> >>>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX >>>>> USRP side: A >>>>> FPGA clock: 52000000 >>>>> Decimation: 192 >>>>> Antenna: TX/RX >>>>> Sample rate: 270833.343750 >>>>> error: fcch not detected in 20 frames >>>>> >>>>> Thanks, >>>>> Tomas >>>>> >>>>> >>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> Download Intel® Parallel Studio Eval >>>>> Try the new software tools for yourself. Speed compiling, find bugs >>>>> proactively, and fine-tune applications for parallel performance. >>>>> See why Intel Parallel Studio got high marks during beta. >>>>> http://p.sf.net/sfu/intel-sw-dev >>>>> _______________________________________________ >>>>> Openbts-discuss mailing list >>>>> Ope...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/openbts-discuss >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> Openbts-discuss mailing list >>>> Ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/openbts-discuss >>>> >>>> >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> >>> >>> >>> _______________________________________________ >>> Openbts-discuss mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/openbts-discuss >> >> >> > |
From: Tomas K. <de...@vo...> - 2010-02-21 00:51:06
|
Matt, thanks for reply. I was using USRP with external 52MHz clock about 3 months without problems mainly for OpenBTS project (gnuradio 3.2.2 with 52MHz clock modifications). But 2 weeks ago I've got wrecked idea to use usrp_fft.py to measure some RFID system. I run "./usrp_fft.py -R B" and during that time I have switched current receiving antena (on RX2 side B) to another antena (with correct frequency range and aerial matching); gain of this antenna is probably better then the previous but I'm not sure how much - I'm using it without problems with GPRS modem. I don't remember which data I have seen, but it was probably crap. Since that time I'm worried with the issue. If I run OpenBTS with external clock (and there is connected only daugherboard side A) I get messages that RX and TX was tuned well and I can scan the OpenBTS network with real networks - this is in my opinion proof that it isn't a clock problem. If I run OpenBTS with both daugherboards(no matter if clock is connected), TX, RX and power fails to tune - probably because RX tune fails as first; I can't scan OpenBTS. If I run OpenBTS only with daughterboard A and disconnect clock, only TX fails to tune - but everything else including RX is tuned well, I can't scan OpenBTS. I tried usrp_siggen.py: /- connected both daugherboards with connected clock or only connected daugherboard side A with clock/ [root@openBTS python]# ./usrp_siggen.py -f 920M dac_rate(): 104000000 dac_rate(): 104000000 Using TX d'board A: Flex 900 Tx dac_rate(): 104000000 <nothing was happening there, I was waiting ~ 10 minutes> /- disconnected clock/ [root@openBTS python]# ./usrp_siggen.py -f 920M dac_rate(): 104000000 dac_rate(): 104000000 Using TX d'board A: Flex 900 Tx dac_rate(): 104000000 Failed to set RF frequency [root@openBTS python]# /- disconnected both daughterboards or only connected daughterboard side B , connected clock/ [root@openBTS python]# ./usrp_siggen.py -f 920M dac_rate(): 104000000 dac_rate(): 104000000 Using TX d'board A: <none> dac_rate(): 104000000 <nothing was happening ...> Is that possible that I have "toasted" something by changing antenna ? If yes, could it be daugherboard or even USRP motherboard ? I'm not sure if the daughterboard connected as TX (side A) during "the accident" was with good RX - not previously "toasted" (I had some problem with tuning OpenBTS, it was maybe only software issue, maybe hardware fixed by daughterboard switch). So I don't know if there isn't a curious situation with both daughterboard's "toasted" RX2. If there are any more tests I can do, please let me know. Thanks, Tomas > > Tomas, > > It is hard to say what happened. How do you know this is not a > problem with the clock? For whatever reason, the daughterboard is > failing to lock. What happens if you try to transmit: > > usrp_siggen.py -f 920M > > Does it report lock? > > Can you see the clock coming into the PLL chip? > > Are you using a 52 MHz clock or a 64 MHz one? Does the software know > about this? If it thinks it is getting 64 MHz but is really getting > 52 MHz (or vice versa) it will not lock properly. > > Matt > > > On 02/18/2010 03:15 PM, Tomas Kopsa wrote: >> If there is a daughterboard present I see "flicking blue wave" with 0MHz >> central freq a message Failed to set initial frequency, just like in >> attached screenshot. >> If daughterboard is missing USRP FFT tunes on 900MHz correctly but the >> graph area is blank - its equivalent with all kal-0.2 test cases (posted >> previously): >> >> error: fcch not detected in 20 frames ~ USRP FFT tuned with >> blank graph area >> error: usrp_source::tune ~ "flicking blue wave" with faled >> tune - "Failed to set initial frequency" >> >> >> >>> What do you see when you run usrp_fft.py on the tower frequency? >>> (usrp_fft.py is part of the standard gnuradio installation.) >>> >>> Does it look like you can still see the signal from the tower? >>> >>> >>> Quoting Tomas Kopsa (de...@vo...): >>> >>>> - All >>>> >>>> I have some (for me weird) issue with USRP and I will be glad if >>>> somebody will suggest me anything. >>>> I was changing antenna (50ohm aerial matching) during execution >>>> usrp_fft.py and since that time I'm unable to tune RX channel with any >>>> of two RFX900 (I have USRP + 2xRFX900). >>>> >>>> I have installed new machine with Fedora 11, gnuradio-3.2.2, OpenBTS >>>> 2.5.3 to exclude corrupted build failure. So I have the same results >>>> with the original SW setup. >>>> 2) It's not a clock problem, reasons are described later. >>>> >>>> I have signed one daughterboard as DB1, second as DB2 and made some >>>> test: >>>> >>>> *Test case 1 - only DB1 is connected in USRP side A* >>>> >>>> Attempt to run OpenBTS: >>>> >>>> Starting the system... >>>> 1266436555.5621 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD POWEROFF >>>> 1266436555.6352 FORCE 3087378128 Logger.cpp:90:gSetLogFile: setting >>>> log >>>> path to /dev/null >>>> 1266436556.5832 WARNING 3086686016 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266436557.6049 WARNING 3086686016 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266436558.6276 WARNING 3086686016 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266436559.6494 WARNING 3086686016 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> dac_rate(): 104000000 >>>> dac_rate(): 104000000 >>>> 1266436560.6708 WARNING 3086686016 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266436560.6752 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETTSC 0 >>>> 1266436560.6798 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD RXTUNE 890200 >>>> 1266436560.6922 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD TXTUNE 935200 >>>> dac_rate(): 104000000 >>>> 1266436560.7206 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETSLOT 0 5 >>>> 1266436560.7247 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD POWERON >>>> 1266436560.7852 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETPOWER 0 >>>> 1266436560.7899 INFO 3086686016 GSMLogicalChannel.cpp:42:open: >>>> >>>> I can scan OpenBTS with MS, but cant camp (there is no uplink - RX >>>> channel), it is also a proof that clock unit works well. Without >>>> connected clock there is a failure TXTUNE failed with status 1 >>>> If I disconnect USRP power (USB cable) , I get following messages, >>>> which >>>> is correct. >>>> fusb::_reap: No such device >>>> fusb::_reap: No such device >>>> fusb::_reap: No such device >>>> >>>> Attemtps to run Kalibrator: >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946600000 >>>> USRP side: B >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: RX2 >>>> Sample rate: 270833.343750 >>>> error: fcch not detected in 20 frames >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX >>>> USRP side: B >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: TX/RX >>>> Sample rate: 270833.343750 >>>> error: fcch not detected in 20 frames >>>> >>>> ARFCN on side B cannot be scanned because there is no DB connected but >>>> works. >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A >>>> USRP side: A >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: RX2 >>>> error: usrp_source::tune >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX >>>> USRP side: A >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: TX/RX >>>> error: usrp_source::tune >>>> >>>> DB is connected to side A, but tune() fails. >>>> >>>> *Test case 2 - only DB1 is connected in USRP side B >>>> >>>> *Attempt to run OpenBTS: >>>> * >>>> *Starting the system... >>>> 1266438092.1164 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD POWEROFF >>>> 1266438092.1217 FORCE 3086087888 Logger.cpp:90:gSetLogFile: setting >>>> log >>>> path to /dev/null >>>> 1266438093.1657 WARNING 3086882624 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266438094.1880 WARNING 3086882624 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266438095.2100 WARNING 3086882624 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266438096.2316 WARNING 3086882624 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> dac_rate(): 104000000 >>>> dac_rate(): 104000000 >>>> 1266438097.2548 WARNING 3086882624 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266438097.2590 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETTSC 0 >>>> 1266438097.2632 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD RXTUNE 890200 >>>> 1266438097.2763 ALARM 3086882624 TRXManager.cpp:359:tune: RXTUNE >>>> failed >>>> with status 1 >>>> 1266438097.2764 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETSLOT 0 5 >>>> 1266438097.2806 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD POWERON >>>> 1266438097.2847 ALARM 3086882624 TRXManager.cpp:411:powerOn: POWERON >>>> failed with status 1 >>>> 1266438097.2847 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETPOWER 0 >>>> 1266438097.2888 ALARM 3086882624 TRXManager.cpp:424:setPower: SETPOWER >>>> failed with status 1 >>>> 1266438097.2891 INFO 3086882624 GSMLogicalChannel.cpp:42:open: >>>> >>>> So there are lots of failures and when USRP is disconnected, CLI >>>> detects >>>> nothing* *and is still active. >>>> >>>> Attemtps to run Kalibrator: >>>> [root@openBTS kal-0.2]# ./kal -f 946600000 >>>> USRP side: B >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: RX2 >>>> error: usrp_source::tune >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX >>>> USRP side: B >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: TX/RX >>>> error: usrp_source::tune >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A >>>> USRP side: A >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: RX2 >>>> Sample rate: 270833.343750 >>>> error: fcch not detected in 20 frames >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX >>>> USRP side: A >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: TX/RX >>>> Sample rate: 270833.343750 >>>> error: fcch not detected in 20 frames* >>>> >>>> **Test case 3 - only DB2 is connected in USRP side A* >>>> * >>>> *OpenBTS* >>>> >>>> *Starting the system... >>>> 1266438821.8364 FORCE 3087906512 Logger.cpp:90:gSetLogFile: setting >>>> log >>>> path to /dev/null >>>> 1266438821.8369 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD POWEROFF >>>> 1266438822.8586 WARNING 3087877952 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266438823.8806 WARNING 3087877952 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266438824.9027 WARNING 3087877952 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266438825.9245 WARNING 3087877952 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> dac_rate(): 104000000 >>>> dac_rate(): 104000000 >>>> 1266438826.9477 WARNING 3087877952 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266438826.9522 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETTSC 0 >>>> 1266438826.9568 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD RXTUNE 890200 >>>> 1266438826.9693 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD TXTUNE 935200 >>>> dac_rate(): 104000000 >>>> 1266438826.9816 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETSLOT 0 5 >>>> 1266438826.9858 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD POWERON >>>> 1266438827.1147 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETPOWER 0 >>>> 1266438827.1248 INFO 3087877952 GSMLogicalChannel.cpp:42:open:* >>>> >>>> *Its the same like test case 1,* *I can scan OpenBTS with MS and >>>> disconnected USRP power (USB cable) messes with errors: >>>> fusb::_reap: No such device >>>> fusb::_reap: No such device >>>> fusb::_reap: No such device >>>> >>>> Kalibrator: >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946000000 >>>> USRP side: B >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: RX2 >>>> Sample rate: 270833.343750 >>>> error: fcch not detected in 20 frames >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX >>>> USRP side: B >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: TX/RX >>>> Sample rate: 270833.343750 >>>> error: fcch not detected in 20 frames >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A >>>> USRP side: A >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: RX2 >>>> error: usrp_source::tune >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX >>>> USRP side: A >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: TX/RX >>>> error: usrp_source::tune >>>> >>>> *Test case 4 - only DB2 is connected in USRP side B >>>> >>>> *OpenBTS* >>>> * >>>> Starting the system... >>>> 1266439630.8798 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD POWEROFF >>>> 1266439630.8816 FORCE 3087140560 Logger.cpp:90:gSetLogFile: setting >>>> log >>>> path to /dev/null >>>> 1266439631.9024 WARNING 3087316800 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266439632.9264 WARNING 3087316800 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266439633.9491 WARNING 3087316800 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266439634.9707 WARNING 3087316800 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> dac_rate(): 104000000 >>>> dac_rate(): 104000000 >>>> 1266439635.9923 WARNING 3087316800 >>>> TRXManager.cpp:271:sendCommandPacket: >>>> retrying transceiver command after response timeout >>>> 1266439635.9969 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETTSC 0 >>>> 1266439636.0023 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD RXTUNE 890200 >>>> 1266439636.0313 ALARM 3087316800 TRXManager.cpp:359:tune: RXTUNE >>>> failed >>>> with status 1 >>>> 1266439636.0314 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETSLOT 0 5 >>>> 1266439636.0356 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD POWERON >>>> 1266439636.0397 ALARM 3087316800 TRXManager.cpp:411:powerOn: POWERON >>>> failed with status 1 >>>> 1266439636.0397 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>>> command CMD SETPOWER 0 >>>> 1266439636.0439 ALARM 3087316800 TRXManager.cpp:424:setPower: SETPOWER >>>> failed with status 1 >>>> 1266439636.0442 INFO 3087316800 GSMLogicalChannel.cpp:42:open: * >>>> >>>> *Same like test case 2 when USRP is disconnected, CLI detects >>>> nothing* >>>> *and is still active. >>>> * >>>> *Kalibrator >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946000000 >>>> USRP side: B >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: RX2 >>>> error: usrp_source::tune >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX >>>> USRP side: B >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: TX/RX >>>> error: usrp_source::tune >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A >>>> USRP side: A >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: RX2 >>>> Sample rate: 270833.343750 >>>> error: fcch not detected in 20 frames >>>> >>>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX >>>> USRP side: A >>>> FPGA clock: 52000000 >>>> Decimation: 192 >>>> Antenna: TX/RX >>>> Sample rate: 270833.343750 >>>> error: fcch not detected in 20 frames >>>> >>>> Thanks, >>>> Tomas >>>> >>>> >>> >>>> ------------------------------------------------------------------------------ >>>> >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> Openbts-discuss mailing list >>>> Ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/openbts-discuss >>>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Openbts-discuss mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/openbts-discuss >>> >>> >>> >> >> >> >> ------------------------------------------------------------------------------ >> >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> >> >> >> _______________________________________________ >> Openbts-discuss mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > > |
From: Matt E. <ma...@et...> - 2010-02-20 06:05:04
|
Tomas, It is hard to say what happened. How do you know this is not a problem with the clock? For whatever reason, the daughterboard is failing to lock. What happens if you try to transmit: usrp_siggen.py -f 920M Does it report lock? Can you see the clock coming into the PLL chip? Are you using a 52 MHz clock or a 64 MHz one? Does the software know about this? If it thinks it is getting 64 MHz but is really getting 52 MHz (or vice versa) it will not lock properly. Matt On 02/18/2010 03:15 PM, Tomas Kopsa wrote: > If there is a daughterboard present I see "flicking blue wave" with 0MHz > central freq a message Failed to set initial frequency, just like in > attached screenshot. > If daughterboard is missing USRP FFT tunes on 900MHz correctly but the > graph area is blank - its equivalent with all kal-0.2 test cases (posted > previously): > > error: fcch not detected in 20 frames ~ USRP FFT tuned with blank graph area > error: usrp_source::tune ~ "flicking blue wave" with faled tune - "Failed to set initial frequency" > > > >> What do you see when you run usrp_fft.py on the tower frequency? >> (usrp_fft.py is part of the standard gnuradio installation.) >> >> Does it look like you can still see the signal from the tower? >> >> >> Quoting Tomas Kopsa (de...@vo...): >> >>> - All >>> >>> I have some (for me weird) issue with USRP and I will be glad if >>> somebody will suggest me anything. >>> I was changing antenna (50ohm aerial matching) during execution >>> usrp_fft.py and since that time I'm unable to tune RX channel with any >>> of two RFX900 (I have USRP + 2xRFX900). >>> >>> I have installed new machine with Fedora 11, gnuradio-3.2.2, OpenBTS >>> 2.5.3 to exclude corrupted build failure. So I have the same results >>> with the original SW setup. >>> 2) It's not a clock problem, reasons are described later. >>> >>> I have signed one daughterboard as DB1, second as DB2 and made some test: >>> >>> *Test case 1 - only DB1 is connected in USRP side A* >>> >>> Attempt to run OpenBTS: >>> >>> Starting the system... >>> 1266436555.5621 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>> command CMD POWEROFF >>> 1266436555.6352 FORCE 3087378128 Logger.cpp:90:gSetLogFile: setting log >>> path to /dev/null >>> 1266436556.5832 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266436557.6049 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266436558.6276 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266436559.6494 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> dac_rate(): 104000000 >>> dac_rate(): 104000000 >>> 1266436560.6708 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266436560.6752 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETTSC 0 >>> 1266436560.6798 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>> command CMD RXTUNE 890200 >>> 1266436560.6922 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>> command CMD TXTUNE 935200 >>> dac_rate(): 104000000 >>> 1266436560.7206 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETSLOT 0 5 >>> 1266436560.7247 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>> command CMD POWERON >>> 1266436560.7852 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETPOWER 0 >>> 1266436560.7899 INFO 3086686016 GSMLogicalChannel.cpp:42:open: >>> >>> I can scan OpenBTS with MS, but cant camp (there is no uplink - RX >>> channel), it is also a proof that clock unit works well. Without >>> connected clock there is a failure TXTUNE failed with status 1 >>> If I disconnect USRP power (USB cable) , I get following messages, which >>> is correct. >>> fusb::_reap: No such device >>> fusb::_reap: No such device >>> fusb::_reap: No such device >>> >>> Attemtps to run Kalibrator: >>> >>> [root@openBTS kal-0.2]# ./kal -f 946600000 >>> USRP side: B >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: RX2 >>> Sample rate: 270833.343750 >>> error: fcch not detected in 20 frames >>> >>> [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX >>> USRP side: B >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: TX/RX >>> Sample rate: 270833.343750 >>> error: fcch not detected in 20 frames >>> >>> ARFCN on side B cannot be scanned because there is no DB connected but >>> works. >>> >>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A >>> USRP side: A >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: RX2 >>> error: usrp_source::tune >>> >>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX >>> USRP side: A >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: TX/RX >>> error: usrp_source::tune >>> >>> DB is connected to side A, but tune() fails. >>> >>> *Test case 2 - only DB1 is connected in USRP side B >>> >>> *Attempt to run OpenBTS: >>> * >>> *Starting the system... >>> 1266438092.1164 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>> command CMD POWEROFF >>> 1266438092.1217 FORCE 3086087888 Logger.cpp:90:gSetLogFile: setting log >>> path to /dev/null >>> 1266438093.1657 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266438094.1880 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266438095.2100 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266438096.2316 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> dac_rate(): 104000000 >>> dac_rate(): 104000000 >>> 1266438097.2548 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266438097.2590 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETTSC 0 >>> 1266438097.2632 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>> command CMD RXTUNE 890200 >>> 1266438097.2763 ALARM 3086882624 TRXManager.cpp:359:tune: RXTUNE failed >>> with status 1 >>> 1266438097.2764 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETSLOT 0 5 >>> 1266438097.2806 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>> command CMD POWERON >>> 1266438097.2847 ALARM 3086882624 TRXManager.cpp:411:powerOn: POWERON >>> failed with status 1 >>> 1266438097.2847 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETPOWER 0 >>> 1266438097.2888 ALARM 3086882624 TRXManager.cpp:424:setPower: SETPOWER >>> failed with status 1 >>> 1266438097.2891 INFO 3086882624 GSMLogicalChannel.cpp:42:open: >>> >>> So there are lots of failures and when USRP is disconnected, CLI detects >>> nothing* *and is still active. >>> >>> Attemtps to run Kalibrator: >>> [root@openBTS kal-0.2]# ./kal -f 946600000 >>> USRP side: B >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: RX2 >>> error: usrp_source::tune >>> >>> [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX >>> USRP side: B >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: TX/RX >>> error: usrp_source::tune >>> >>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A >>> USRP side: A >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: RX2 >>> Sample rate: 270833.343750 >>> error: fcch not detected in 20 frames >>> >>> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX >>> USRP side: A >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: TX/RX >>> Sample rate: 270833.343750 >>> error: fcch not detected in 20 frames* >>> >>> **Test case 3 - only DB2 is connected in USRP side A* >>> * >>> *OpenBTS* >>> >>> *Starting the system... >>> 1266438821.8364 FORCE 3087906512 Logger.cpp:90:gSetLogFile: setting log >>> path to /dev/null >>> 1266438821.8369 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>> command CMD POWEROFF >>> 1266438822.8586 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266438823.8806 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266438824.9027 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266438825.9245 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> dac_rate(): 104000000 >>> dac_rate(): 104000000 >>> 1266438826.9477 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266438826.9522 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETTSC 0 >>> 1266438826.9568 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>> command CMD RXTUNE 890200 >>> 1266438826.9693 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>> command CMD TXTUNE 935200 >>> dac_rate(): 104000000 >>> 1266438826.9816 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETSLOT 0 5 >>> 1266438826.9858 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>> command CMD POWERON >>> 1266438827.1147 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETPOWER 0 >>> 1266438827.1248 INFO 3087877952 GSMLogicalChannel.cpp:42:open:* >>> >>> *Its the same like test case 1,* *I can scan OpenBTS with MS and >>> disconnected USRP power (USB cable) messes with errors: >>> fusb::_reap: No such device >>> fusb::_reap: No such device >>> fusb::_reap: No such device >>> >>> Kalibrator: >>> >>> [root@openBTS kal-0.2]# ./kal -f 946000000 >>> USRP side: B >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: RX2 >>> Sample rate: 270833.343750 >>> error: fcch not detected in 20 frames >>> >>> [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX >>> USRP side: B >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: TX/RX >>> Sample rate: 270833.343750 >>> error: fcch not detected in 20 frames >>> >>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A >>> USRP side: A >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: RX2 >>> error: usrp_source::tune >>> >>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX >>> USRP side: A >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: TX/RX >>> error: usrp_source::tune >>> >>> *Test case 4 - only DB2 is connected in USRP side B >>> >>> *OpenBTS* >>> * >>> Starting the system... >>> 1266439630.8798 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>> command CMD POWEROFF >>> 1266439630.8816 FORCE 3087140560 Logger.cpp:90:gSetLogFile: setting log >>> path to /dev/null >>> 1266439631.9024 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266439632.9264 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266439633.9491 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266439634.9707 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> dac_rate(): 104000000 >>> dac_rate(): 104000000 >>> 1266439635.9923 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: >>> retrying transceiver command after response timeout >>> 1266439635.9969 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETTSC 0 >>> 1266439636.0023 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>> command CMD RXTUNE 890200 >>> 1266439636.0313 ALARM 3087316800 TRXManager.cpp:359:tune: RXTUNE failed >>> with status 1 >>> 1266439636.0314 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETSLOT 0 5 >>> 1266439636.0356 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>> command CMD POWERON >>> 1266439636.0397 ALARM 3087316800 TRXManager.cpp:411:powerOn: POWERON >>> failed with status 1 >>> 1266439636.0397 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >>> command CMD SETPOWER 0 >>> 1266439636.0439 ALARM 3087316800 TRXManager.cpp:424:setPower: SETPOWER >>> failed with status 1 >>> 1266439636.0442 INFO 3087316800 GSMLogicalChannel.cpp:42:open: * >>> >>> *Same like test case 2 when USRP is disconnected, CLI detects nothing* >>> *and is still active. >>> * >>> *Kalibrator >>> >>> [root@openBTS kal-0.2]# ./kal -f 946000000 >>> USRP side: B >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: RX2 >>> error: usrp_source::tune >>> >>> [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX >>> USRP side: B >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: TX/RX >>> error: usrp_source::tune >>> >>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A >>> USRP side: A >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: RX2 >>> Sample rate: 270833.343750 >>> error: fcch not detected in 20 frames >>> >>> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX >>> USRP side: A >>> FPGA clock: 52000000 >>> Decimation: 192 >>> Antenna: TX/RX >>> Sample rate: 270833.343750 >>> error: fcch not detected in 20 frames >>> >>> Thanks, >>> Tomas >>> >>> >> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Openbts-discuss mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/openbts-discuss >>> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Openbts-discuss mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss >> >> >> > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > > > > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss |
From: Javier D. <ja...@gm...> - 2010-02-19 21:05:47
|
Hi David, Who dictated the course? I mean if you or Harvinder dictated. Regards, 2010/2/4 David A. Burgess <dbu...@jc...> > > Arg. Yes. It is a total accident. > > On Feb 4, 2010, at 4:14 PM, Alexander Chemeris wrote: > > > David, > > > > Is that by accident that those dates are exactly when 2010 European > > SDR Forum is held in Mainz, Germany? > > http://groups.sdrforum.org/p/cm/ld/fid=21 > > > > > David A. Burgess > Kestrel Signal Processing, Inc. > > > > > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > -- Javier Dextre |
From: Tomas K. <de...@vo...> - 2010-02-19 01:03:54
|
Thanks Joshua, I will describe my problem on the gnuradio mailing list. > Quoting Tomas Kopsa (de...@vo...): > >> If there is a daughterboard present I see "flicking blue wave" with >> 0MHz central frequency and a message "Failed to set initial >> frequency", just like in attached screenshot. >> If daughterboard is missing, USRP FFT tunes on 900MHz correctly, but the >> graph area is blank - its equivalent with all kal-0.2 test cases (posted >> previously): >> > Sounds like you toasted your board. I'd ask on the gnuradio mailing > list -- don't bother mentioning openbts or kal, just talk about what you > see when you use usrp_fft.py. > > Perhaps its something easy like a blown fuse or a bad capacitor. > However, you probably fried the amp. > > In any case, hopefully Matt will help you track it down. > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > > |
From: Joshua L. <jl...@th...> - 2010-02-19 00:53:46
|
Quoting Tomas Kopsa (de...@vo...): > If there is a daughterboard present I see "flicking blue wave" with > 0MHz central frequency and a message "Failed to set initial > frequency", just like in attached screenshot. > If daughterboard is missing, USRP FFT tunes on 900MHz correctly, but the > graph area is blank - its equivalent with all kal-0.2 test cases (posted > previously): Sounds like you toasted your board. I'd ask on the gnuradio mailing list -- don't bother mentioning openbts or kal, just talk about what you see when you use usrp_fft.py. Perhaps its something easy like a blown fuse or a bad capacitor. However, you probably fried the amp. In any case, hopefully Matt will help you track it down. |
From: Tomas K. <de...@vo...> - 2010-02-18 23:21:28
|
If there is a daughterboard present I see "flicking blue wave" with 0MHz central frequency and a message "Failed to set initial frequency", just like in attached screenshot. If daughterboard is missing, USRP FFT tunes on 900MHz correctly, but the graph area is blank - its equivalent with all kal-0.2 test cases (posted previously): error: fcch not detected in 20 frames ~ USRP FFT tuned with blank graph area error: usrp_source::tune ~ "flicking blue wave" with failed tune - "Failed to set initial frequency" >> What do you see when you run usrp_fft.py on the tower frequency? >> (usrp_fft.py is part of the standard gnuradio installation.) >> >> Does it look like you can still see the signal from the tower? >> >> >> |
From: Tomas K. <de...@vo...> - 2010-02-18 23:15:47
|
If there is a daughterboard present I see "flicking blue wave" with 0MHz central freq a message Failed to set initial frequency, just like in attached screenshot. If daughterboard is missing USRP FFT tunes on 900MHz correctly but the graph area is blank - its equivalent with all kal-0.2 test cases (posted previously): error: fcch not detected in 20 frames ~ USRP FFT tuned with blank graph area error: usrp_source::tune ~ "flicking blue wave" with faled tune - "Failed to set initial frequency" > What do you see when you run usrp_fft.py on the tower frequency? > (usrp_fft.py is part of the standard gnuradio installation.) > > Does it look like you can still see the signal from the tower? > > > Quoting Tomas Kopsa (de...@vo...): > >> - All >> >> I have some (for me weird) issue with USRP and I will be glad if >> somebody will suggest me anything. >> I was changing antenna (50ohm aerial matching) during execution >> usrp_fft.py and since that time I'm unable to tune RX channel with any >> of two RFX900 (I have USRP + 2xRFX900). >> >> I have installed new machine with Fedora 11, gnuradio-3.2.2, OpenBTS >> 2.5.3 to exclude corrupted build failure. So I have the same results >> with the original SW setup. >> 2) It's not a clock problem, reasons are described later. >> >> I have signed one daughterboard as DB1, second as DB2 and made some test: >> >> *Test case 1 - only DB1 is connected in USRP side A* >> >> Attempt to run OpenBTS: >> >> Starting the system... >> 1266436555.5621 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >> command CMD POWEROFF >> 1266436555.6352 FORCE 3087378128 Logger.cpp:90:gSetLogFile: setting log >> path to /dev/null >> 1266436556.5832 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266436557.6049 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266436558.6276 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266436559.6494 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> dac_rate(): 104000000 >> dac_rate(): 104000000 >> 1266436560.6708 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266436560.6752 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETTSC 0 >> 1266436560.6798 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >> command CMD RXTUNE 890200 >> 1266436560.6922 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >> command CMD TXTUNE 935200 >> dac_rate(): 104000000 >> 1266436560.7206 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETSLOT 0 5 >> 1266436560.7247 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >> command CMD POWERON >> 1266436560.7852 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETPOWER 0 >> 1266436560.7899 INFO 3086686016 GSMLogicalChannel.cpp:42:open: >> >> I can scan OpenBTS with MS, but cant camp (there is no uplink - RX >> channel), it is also a proof that clock unit works well. Without >> connected clock there is a failure TXTUNE failed with status 1 >> If I disconnect USRP power (USB cable) , I get following messages, which >> is correct. >> fusb::_reap: No such device >> fusb::_reap: No such device >> fusb::_reap: No such device >> >> Attemtps to run Kalibrator: >> >> [root@openBTS kal-0.2]# ./kal -f 946600000 >> USRP side: B >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: RX2 >> Sample rate: 270833.343750 >> error: fcch not detected in 20 frames >> >> [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX >> USRP side: B >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: TX/RX >> Sample rate: 270833.343750 >> error: fcch not detected in 20 frames >> >> ARFCN on side B cannot be scanned because there is no DB connected but >> works. >> >> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A >> USRP side: A >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: RX2 >> error: usrp_source::tune >> >> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX >> USRP side: A >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: TX/RX >> error: usrp_source::tune >> >> DB is connected to side A, but tune() fails. >> >> *Test case 2 - only DB1 is connected in USRP side B >> >> *Attempt to run OpenBTS: >> * >> *Starting the system... >> 1266438092.1164 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >> command CMD POWEROFF >> 1266438092.1217 FORCE 3086087888 Logger.cpp:90:gSetLogFile: setting log >> path to /dev/null >> 1266438093.1657 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266438094.1880 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266438095.2100 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266438096.2316 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> dac_rate(): 104000000 >> dac_rate(): 104000000 >> 1266438097.2548 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266438097.2590 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETTSC 0 >> 1266438097.2632 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >> command CMD RXTUNE 890200 >> 1266438097.2763 ALARM 3086882624 TRXManager.cpp:359:tune: RXTUNE failed >> with status 1 >> 1266438097.2764 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETSLOT 0 5 >> 1266438097.2806 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >> command CMD POWERON >> 1266438097.2847 ALARM 3086882624 TRXManager.cpp:411:powerOn: POWERON >> failed with status 1 >> 1266438097.2847 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETPOWER 0 >> 1266438097.2888 ALARM 3086882624 TRXManager.cpp:424:setPower: SETPOWER >> failed with status 1 >> 1266438097.2891 INFO 3086882624 GSMLogicalChannel.cpp:42:open: >> >> So there are lots of failures and when USRP is disconnected, CLI detects >> nothing* *and is still active. >> >> Attemtps to run Kalibrator: >> [root@openBTS kal-0.2]# ./kal -f 946600000 >> USRP side: B >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: RX2 >> error: usrp_source::tune >> >> [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX >> USRP side: B >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: TX/RX >> error: usrp_source::tune >> >> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A >> USRP side: A >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: RX2 >> Sample rate: 270833.343750 >> error: fcch not detected in 20 frames >> >> [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX >> USRP side: A >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: TX/RX >> Sample rate: 270833.343750 >> error: fcch not detected in 20 frames* >> >> **Test case 3 - only DB2 is connected in USRP side A* >> * >> *OpenBTS* >> >> *Starting the system... >> 1266438821.8364 FORCE 3087906512 Logger.cpp:90:gSetLogFile: setting log >> path to /dev/null >> 1266438821.8369 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >> command CMD POWEROFF >> 1266438822.8586 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266438823.8806 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266438824.9027 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266438825.9245 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> dac_rate(): 104000000 >> dac_rate(): 104000000 >> 1266438826.9477 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266438826.9522 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETTSC 0 >> 1266438826.9568 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >> command CMD RXTUNE 890200 >> 1266438826.9693 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >> command CMD TXTUNE 935200 >> dac_rate(): 104000000 >> 1266438826.9816 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETSLOT 0 5 >> 1266438826.9858 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >> command CMD POWERON >> 1266438827.1147 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETPOWER 0 >> 1266438827.1248 INFO 3087877952 GSMLogicalChannel.cpp:42:open:* >> >> *Its the same like test case 1,* *I can scan OpenBTS with MS and >> disconnected USRP power (USB cable) messes with errors: >> fusb::_reap: No such device >> fusb::_reap: No such device >> fusb::_reap: No such device >> >> Kalibrator: >> >> [root@openBTS kal-0.2]# ./kal -f 946000000 >> USRP side: B >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: RX2 >> Sample rate: 270833.343750 >> error: fcch not detected in 20 frames >> >> [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX >> USRP side: B >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: TX/RX >> Sample rate: 270833.343750 >> error: fcch not detected in 20 frames >> >> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A >> USRP side: A >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: RX2 >> error: usrp_source::tune >> >> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX >> USRP side: A >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: TX/RX >> error: usrp_source::tune >> >> *Test case 4 - only DB2 is connected in USRP side B >> >> *OpenBTS* >> * >> Starting the system... >> 1266439630.8798 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >> command CMD POWEROFF >> 1266439630.8816 FORCE 3087140560 Logger.cpp:90:gSetLogFile: setting log >> path to /dev/null >> 1266439631.9024 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266439632.9264 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266439633.9491 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266439634.9707 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> dac_rate(): 104000000 >> dac_rate(): 104000000 >> 1266439635.9923 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: >> retrying transceiver command after response timeout >> 1266439635.9969 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETTSC 0 >> 1266439636.0023 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >> command CMD RXTUNE 890200 >> 1266439636.0313 ALARM 3087316800 TRXManager.cpp:359:tune: RXTUNE failed >> with status 1 >> 1266439636.0314 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETSLOT 0 5 >> 1266439636.0356 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >> command CMD POWERON >> 1266439636.0397 ALARM 3087316800 TRXManager.cpp:411:powerOn: POWERON >> failed with status 1 >> 1266439636.0397 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: >> command CMD SETPOWER 0 >> 1266439636.0439 ALARM 3087316800 TRXManager.cpp:424:setPower: SETPOWER >> failed with status 1 >> 1266439636.0442 INFO 3087316800 GSMLogicalChannel.cpp:42:open: * >> >> *Same like test case 2 when USRP is disconnected, CLI detects nothing* >> *and is still active. >> * >> *Kalibrator >> >> [root@openBTS kal-0.2]# ./kal -f 946000000 >> USRP side: B >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: RX2 >> error: usrp_source::tune >> >> [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX >> USRP side: B >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: TX/RX >> error: usrp_source::tune >> >> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A >> USRP side: A >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: RX2 >> Sample rate: 270833.343750 >> error: fcch not detected in 20 frames >> >> [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX >> USRP side: A >> FPGA clock: 52000000 >> Decimation: 192 >> Antenna: TX/RX >> Sample rate: 270833.343750 >> error: fcch not detected in 20 frames >> >> Thanks, >> Tomas >> >> > >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Openbts-discuss mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > > |
From: Joshua L. <jl...@th...> - 2010-02-18 22:23:40
|
What do you see when you run usrp_fft.py on the tower frequency? (usrp_fft.py is part of the standard gnuradio installation.) Does it look like you can still see the signal from the tower? Quoting Tomas Kopsa (de...@vo...): > - All > > I have some (for me weird) issue with USRP and I will be glad if > somebody will suggest me anything. > I was changing antenna (50ohm aerial matching) during execution > usrp_fft.py and since that time I'm unable to tune RX channel with any > of two RFX900 (I have USRP + 2xRFX900). > > I have installed new machine with Fedora 11, gnuradio-3.2.2, OpenBTS > 2.5.3 to exclude corrupted build failure. So I have the same results > with the original SW setup. > 2) It's not a clock problem, reasons are described later. > > I have signed one daughterboard as DB1, second as DB2 and made some test: > > *Test case 1 - only DB1 is connected in USRP side A* > > Attempt to run OpenBTS: > > Starting the system... > 1266436555.5621 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: > command CMD POWEROFF > 1266436555.6352 FORCE 3087378128 Logger.cpp:90:gSetLogFile: setting log > path to /dev/null > 1266436556.5832 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266436557.6049 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266436558.6276 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266436559.6494 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > dac_rate(): 104000000 > dac_rate(): 104000000 > 1266436560.6708 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266436560.6752 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: > command CMD SETTSC 0 > 1266436560.6798 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: > command CMD RXTUNE 890200 > 1266436560.6922 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: > command CMD TXTUNE 935200 > dac_rate(): 104000000 > 1266436560.7206 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: > command CMD SETSLOT 0 5 > 1266436560.7247 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: > command CMD POWERON > 1266436560.7852 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: > command CMD SETPOWER 0 > 1266436560.7899 INFO 3086686016 GSMLogicalChannel.cpp:42:open: > > I can scan OpenBTS with MS, but cant camp (there is no uplink - RX > channel), it is also a proof that clock unit works well. Without > connected clock there is a failure TXTUNE failed with status 1 > If I disconnect USRP power (USB cable) , I get following messages, which > is correct. > fusb::_reap: No such device > fusb::_reap: No such device > fusb::_reap: No such device > > Attemtps to run Kalibrator: > > [root@openBTS kal-0.2]# ./kal -f 946600000 > USRP side: B > FPGA clock: 52000000 > Decimation: 192 > Antenna: RX2 > Sample rate: 270833.343750 > error: fcch not detected in 20 frames > > [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX > USRP side: B > FPGA clock: 52000000 > Decimation: 192 > Antenna: TX/RX > Sample rate: 270833.343750 > error: fcch not detected in 20 frames > > ARFCN on side B cannot be scanned because there is no DB connected but > works. > > [root@openBTS kal-0.2]# ./kal -f 946600000 -R A > USRP side: A > FPGA clock: 52000000 > Decimation: 192 > Antenna: RX2 > error: usrp_source::tune > > [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX > USRP side: A > FPGA clock: 52000000 > Decimation: 192 > Antenna: TX/RX > error: usrp_source::tune > > DB is connected to side A, but tune() fails. > > *Test case 2 - only DB1 is connected in USRP side B > > *Attempt to run OpenBTS: > * > *Starting the system... > 1266438092.1164 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: > command CMD POWEROFF > 1266438092.1217 FORCE 3086087888 Logger.cpp:90:gSetLogFile: setting log > path to /dev/null > 1266438093.1657 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266438094.1880 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266438095.2100 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266438096.2316 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > dac_rate(): 104000000 > dac_rate(): 104000000 > 1266438097.2548 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266438097.2590 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: > command CMD SETTSC 0 > 1266438097.2632 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: > command CMD RXTUNE 890200 > 1266438097.2763 ALARM 3086882624 TRXManager.cpp:359:tune: RXTUNE failed > with status 1 > 1266438097.2764 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: > command CMD SETSLOT 0 5 > 1266438097.2806 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: > command CMD POWERON > 1266438097.2847 ALARM 3086882624 TRXManager.cpp:411:powerOn: POWERON > failed with status 1 > 1266438097.2847 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: > command CMD SETPOWER 0 > 1266438097.2888 ALARM 3086882624 TRXManager.cpp:424:setPower: SETPOWER > failed with status 1 > 1266438097.2891 INFO 3086882624 GSMLogicalChannel.cpp:42:open: > > So there are lots of failures and when USRP is disconnected, CLI detects > nothing* *and is still active. > > Attemtps to run Kalibrator: > [root@openBTS kal-0.2]# ./kal -f 946600000 > USRP side: B > FPGA clock: 52000000 > Decimation: 192 > Antenna: RX2 > error: usrp_source::tune > > [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX > USRP side: B > FPGA clock: 52000000 > Decimation: 192 > Antenna: TX/RX > error: usrp_source::tune > > [root@openBTS kal-0.2]# ./kal -f 946600000 -R A > USRP side: A > FPGA clock: 52000000 > Decimation: 192 > Antenna: RX2 > Sample rate: 270833.343750 > error: fcch not detected in 20 frames > > [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX > USRP side: A > FPGA clock: 52000000 > Decimation: 192 > Antenna: TX/RX > Sample rate: 270833.343750 > error: fcch not detected in 20 frames* > > **Test case 3 - only DB2 is connected in USRP side A* > * > *OpenBTS* > > *Starting the system... > 1266438821.8364 FORCE 3087906512 Logger.cpp:90:gSetLogFile: setting log > path to /dev/null > 1266438821.8369 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: > command CMD POWEROFF > 1266438822.8586 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266438823.8806 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266438824.9027 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266438825.9245 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > dac_rate(): 104000000 > dac_rate(): 104000000 > 1266438826.9477 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266438826.9522 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: > command CMD SETTSC 0 > 1266438826.9568 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: > command CMD RXTUNE 890200 > 1266438826.9693 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: > command CMD TXTUNE 935200 > dac_rate(): 104000000 > 1266438826.9816 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: > command CMD SETSLOT 0 5 > 1266438826.9858 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: > command CMD POWERON > 1266438827.1147 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: > command CMD SETPOWER 0 > 1266438827.1248 INFO 3087877952 GSMLogicalChannel.cpp:42:open:* > > *Its the same like test case 1,* *I can scan OpenBTS with MS and > disconnected USRP power (USB cable) messes with errors: > fusb::_reap: No such device > fusb::_reap: No such device > fusb::_reap: No such device > > Kalibrator: > > [root@openBTS kal-0.2]# ./kal -f 946000000 > USRP side: B > FPGA clock: 52000000 > Decimation: 192 > Antenna: RX2 > Sample rate: 270833.343750 > error: fcch not detected in 20 frames > > [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX > USRP side: B > FPGA clock: 52000000 > Decimation: 192 > Antenna: TX/RX > Sample rate: 270833.343750 > error: fcch not detected in 20 frames > > [root@openBTS kal-0.2]# ./kal -f 946000000 -R A > USRP side: A > FPGA clock: 52000000 > Decimation: 192 > Antenna: RX2 > error: usrp_source::tune > > [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX > USRP side: A > FPGA clock: 52000000 > Decimation: 192 > Antenna: TX/RX > error: usrp_source::tune > > *Test case 4 - only DB2 is connected in USRP side B > > *OpenBTS* > * > Starting the system... > 1266439630.8798 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: > command CMD POWEROFF > 1266439630.8816 FORCE 3087140560 Logger.cpp:90:gSetLogFile: setting log > path to /dev/null > 1266439631.9024 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266439632.9264 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266439633.9491 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266439634.9707 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > dac_rate(): 104000000 > dac_rate(): 104000000 > 1266439635.9923 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: > retrying transceiver command after response timeout > 1266439635.9969 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: > command CMD SETTSC 0 > 1266439636.0023 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: > command CMD RXTUNE 890200 > 1266439636.0313 ALARM 3087316800 TRXManager.cpp:359:tune: RXTUNE failed > with status 1 > 1266439636.0314 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: > command CMD SETSLOT 0 5 > 1266439636.0356 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: > command CMD POWERON > 1266439636.0397 ALARM 3087316800 TRXManager.cpp:411:powerOn: POWERON > failed with status 1 > 1266439636.0397 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: > command CMD SETPOWER 0 > 1266439636.0439 ALARM 3087316800 TRXManager.cpp:424:setPower: SETPOWER > failed with status 1 > 1266439636.0442 INFO 3087316800 GSMLogicalChannel.cpp:42:open: * > > *Same like test case 2 when USRP is disconnected, CLI detects nothing* > *and is still active. > * > *Kalibrator > > [root@openBTS kal-0.2]# ./kal -f 946000000 > USRP side: B > FPGA clock: 52000000 > Decimation: 192 > Antenna: RX2 > error: usrp_source::tune > > [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX > USRP side: B > FPGA clock: 52000000 > Decimation: 192 > Antenna: TX/RX > error: usrp_source::tune > > [root@openBTS kal-0.2]# ./kal -f 946000000 -R A > USRP side: A > FPGA clock: 52000000 > Decimation: 192 > Antenna: RX2 > Sample rate: 270833.343750 > error: fcch not detected in 20 frames > > [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX > USRP side: A > FPGA clock: 52000000 > Decimation: 192 > Antenna: TX/RX > Sample rate: 270833.343750 > error: fcch not detected in 20 frames > > Thanks, > Tomas > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss |
From: Tomas K. <de...@vo...> - 2010-02-18 20:30:33
|
- All I have some (for me weird) issue with USRP and I will be glad if somebody will suggest me anything. I was changing antenna (50ohm aerial matching) during execution usrp_fft.py and since that time I'm unable to tune RX channel with any of two RFX900 (I have USRP + 2xRFX900). I have installed new machine with Fedora 11, gnuradio-3.2.2, OpenBTS 2.5.3 to exclude corrupted build failure. So I have the same results with the original SW setup. 2) It's not a clock problem, reasons are described later. I have signed one daughterboard as DB1, second as DB2 and made some test: *Test case 1 - only DB1 is connected in USRP side A* Attempt to run OpenBTS: Starting the system... 1266436555.5621 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: command CMD POWEROFF 1266436555.6352 FORCE 3087378128 Logger.cpp:90:gSetLogFile: setting log path to /dev/null 1266436556.5832 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266436557.6049 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266436558.6276 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266436559.6494 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout dac_rate(): 104000000 dac_rate(): 104000000 1266436560.6708 WARNING 3086686016 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266436560.6752 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: command CMD SETTSC 0 1266436560.6798 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: command CMD RXTUNE 890200 1266436560.6922 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: command CMD TXTUNE 935200 dac_rate(): 104000000 1266436560.7206 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: command CMD SETSLOT 0 5 1266436560.7247 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: command CMD POWERON 1266436560.7852 INFO 3086686016 TRXManager.cpp:254:sendCommandPacket: command CMD SETPOWER 0 1266436560.7899 INFO 3086686016 GSMLogicalChannel.cpp:42:open: I can scan OpenBTS with MS, but cant camp (there is no uplink - RX channel), it is also a proof that clock unit works well. Without connected clock there is a failure TXTUNE failed with status 1 If I disconnect USRP power (USB cable) , I get following messages, which is correct. fusb::_reap: No such device fusb::_reap: No such device fusb::_reap: No such device Attemtps to run Kalibrator: [root@openBTS kal-0.2]# ./kal -f 946600000 USRP side: B FPGA clock: 52000000 Decimation: 192 Antenna: RX2 Sample rate: 270833.343750 error: fcch not detected in 20 frames [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX USRP side: B FPGA clock: 52000000 Decimation: 192 Antenna: TX/RX Sample rate: 270833.343750 error: fcch not detected in 20 frames ARFCN on side B cannot be scanned because there is no DB connected but works. [root@openBTS kal-0.2]# ./kal -f 946600000 -R A USRP side: A FPGA clock: 52000000 Decimation: 192 Antenna: RX2 error: usrp_source::tune [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX USRP side: A FPGA clock: 52000000 Decimation: 192 Antenna: TX/RX error: usrp_source::tune DB is connected to side A, but tune() fails. *Test case 2 - only DB1 is connected in USRP side B *Attempt to run OpenBTS: * *Starting the system... 1266438092.1164 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: command CMD POWEROFF 1266438092.1217 FORCE 3086087888 Logger.cpp:90:gSetLogFile: setting log path to /dev/null 1266438093.1657 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266438094.1880 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266438095.2100 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266438096.2316 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout dac_rate(): 104000000 dac_rate(): 104000000 1266438097.2548 WARNING 3086882624 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266438097.2590 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: command CMD SETTSC 0 1266438097.2632 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: command CMD RXTUNE 890200 1266438097.2763 ALARM 3086882624 TRXManager.cpp:359:tune: RXTUNE failed with status 1 1266438097.2764 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: command CMD SETSLOT 0 5 1266438097.2806 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: command CMD POWERON 1266438097.2847 ALARM 3086882624 TRXManager.cpp:411:powerOn: POWERON failed with status 1 1266438097.2847 INFO 3086882624 TRXManager.cpp:254:sendCommandPacket: command CMD SETPOWER 0 1266438097.2888 ALARM 3086882624 TRXManager.cpp:424:setPower: SETPOWER failed with status 1 1266438097.2891 INFO 3086882624 GSMLogicalChannel.cpp:42:open: So there are lots of failures and when USRP is disconnected, CLI detects nothing* *and is still active. Attemtps to run Kalibrator: [root@openBTS kal-0.2]# ./kal -f 946600000 USRP side: B FPGA clock: 52000000 Decimation: 192 Antenna: RX2 error: usrp_source::tune [root@openBTS kal-0.2]# ./kal -f 946600000 -A RX USRP side: B FPGA clock: 52000000 Decimation: 192 Antenna: TX/RX error: usrp_source::tune [root@openBTS kal-0.2]# ./kal -f 946600000 -R A USRP side: A FPGA clock: 52000000 Decimation: 192 Antenna: RX2 Sample rate: 270833.343750 error: fcch not detected in 20 frames [root@openBTS kal-0.2]# ./kal -f 946600000 -R A -A RX USRP side: A FPGA clock: 52000000 Decimation: 192 Antenna: TX/RX Sample rate: 270833.343750 error: fcch not detected in 20 frames* **Test case 3 - only DB2 is connected in USRP side A* * *OpenBTS* *Starting the system... 1266438821.8364 FORCE 3087906512 Logger.cpp:90:gSetLogFile: setting log path to /dev/null 1266438821.8369 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: command CMD POWEROFF 1266438822.8586 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266438823.8806 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266438824.9027 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266438825.9245 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout dac_rate(): 104000000 dac_rate(): 104000000 1266438826.9477 WARNING 3087877952 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266438826.9522 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: command CMD SETTSC 0 1266438826.9568 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: command CMD RXTUNE 890200 1266438826.9693 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: command CMD TXTUNE 935200 dac_rate(): 104000000 1266438826.9816 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: command CMD SETSLOT 0 5 1266438826.9858 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: command CMD POWERON 1266438827.1147 INFO 3087877952 TRXManager.cpp:254:sendCommandPacket: command CMD SETPOWER 0 1266438827.1248 INFO 3087877952 GSMLogicalChannel.cpp:42:open:* *Its the same like test case 1,* *I can scan OpenBTS with MS and disconnected USRP power (USB cable) messes with errors: fusb::_reap: No such device fusb::_reap: No such device fusb::_reap: No such device Kalibrator: [root@openBTS kal-0.2]# ./kal -f 946000000 USRP side: B FPGA clock: 52000000 Decimation: 192 Antenna: RX2 Sample rate: 270833.343750 error: fcch not detected in 20 frames [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX USRP side: B FPGA clock: 52000000 Decimation: 192 Antenna: TX/RX Sample rate: 270833.343750 error: fcch not detected in 20 frames [root@openBTS kal-0.2]# ./kal -f 946000000 -R A USRP side: A FPGA clock: 52000000 Decimation: 192 Antenna: RX2 error: usrp_source::tune [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX USRP side: A FPGA clock: 52000000 Decimation: 192 Antenna: TX/RX error: usrp_source::tune *Test case 4 - only DB2 is connected in USRP side B *OpenBTS* * Starting the system... 1266439630.8798 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: command CMD POWEROFF 1266439630.8816 FORCE 3087140560 Logger.cpp:90:gSetLogFile: setting log path to /dev/null 1266439631.9024 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266439632.9264 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266439633.9491 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266439634.9707 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout dac_rate(): 104000000 dac_rate(): 104000000 1266439635.9923 WARNING 3087316800 TRXManager.cpp:271:sendCommandPacket: retrying transceiver command after response timeout 1266439635.9969 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: command CMD SETTSC 0 1266439636.0023 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: command CMD RXTUNE 890200 1266439636.0313 ALARM 3087316800 TRXManager.cpp:359:tune: RXTUNE failed with status 1 1266439636.0314 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: command CMD SETSLOT 0 5 1266439636.0356 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: command CMD POWERON 1266439636.0397 ALARM 3087316800 TRXManager.cpp:411:powerOn: POWERON failed with status 1 1266439636.0397 INFO 3087316800 TRXManager.cpp:254:sendCommandPacket: command CMD SETPOWER 0 1266439636.0439 ALARM 3087316800 TRXManager.cpp:424:setPower: SETPOWER failed with status 1 1266439636.0442 INFO 3087316800 GSMLogicalChannel.cpp:42:open: * *Same like test case 2 when USRP is disconnected, CLI detects nothing* *and is still active. * *Kalibrator [root@openBTS kal-0.2]# ./kal -f 946000000 USRP side: B FPGA clock: 52000000 Decimation: 192 Antenna: RX2 error: usrp_source::tune [root@openBTS kal-0.2]# ./kal -f 946000000 -A RX USRP side: B FPGA clock: 52000000 Decimation: 192 Antenna: TX/RX error: usrp_source::tune [root@openBTS kal-0.2]# ./kal -f 946000000 -R A USRP side: A FPGA clock: 52000000 Decimation: 192 Antenna: RX2 Sample rate: 270833.343750 error: fcch not detected in 20 frames [root@openBTS kal-0.2]# ./kal -f 946000000 -R A -A RX USRP side: A FPGA clock: 52000000 Decimation: 192 Antenna: TX/RX Sample rate: 270833.343750 error: fcch not detected in 20 frames Thanks, Tomas |
From: Alexander C. <ale...@gm...> - 2010-02-17 21:43:42
|
Hi Erik, Does it call phones, registered with OpenBTS? If so, how do you plan to answer/drop the calls? Does it support Mobile Originated (MO) calls? PS I haven't looked through the dialplan itself, just read your description. -- Regards, Alexander Chemeris. |
From: Ben W. <bwo...@gm...> - 2010-02-15 15:51:51
|
Has anyone looked into radio link timeout issues. I have seen (with other non-openbts systems that I have worked on) some phones not decoding the SACCH properly and therefore decrementing the radio link counter (S) very quickly. This has led to call drops very close to the 30 seconds described here. Just a thought. Ben On Fri, Feb 12, 2010 at 12:35 PM, voipas <vo...@gm...> wrote: > > > 2010/2/11 David A. Burgess <dbu...@jc...> > > This doesn't sound like a clock problem. It sounds more like an L3 >> protocol problem, probably in CallControl.cpp. There are a few 30 >> second timers in Q.931 that will disconnect a call if specific >> conditions are not met during call setup. Try 2.5.3 and see if you >> have the same problem, since there are a few L3 bug fixes in there. >> >> >> > The problem still exists. Nothing changes. > > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > |
From: meetmecall <in...@me...> - 2010-02-14 11:28:57
|
Fellow OpenBts fans and users, I have put some effort in writing an Asterisk based routine to generate lots of phone calls so the success rate of setting up calls can be investigated. It is a combination of a bash script and some Asterisk magic. This is the basic idea: - a flat file contains a list of numbers to call in sequence. - a bash scrip starts the routine. - a sip trunk is setup between the Asterisk machine used for setting up the calls and the OpenBTS machine. - the assumption is that - call files are generated. The call files sets up a local channel (actually just an Asterisk context) where the Asterisk magic takes place. - cdr (call detail records, the relevant data of a call) stores relevant info (google for a howto about how to setup mysql for asterisk cdr and how to setup phpmyadmin). The routine can be used without mysql for cdr and phpmyadmin as the frontend but it will make this routine much more useful. - the meetme() application is used to bridge the legs of the calls while using a conference room. When using newer version of Asterisk the meetme() app will not be available if Dahdi is not in place. assumptions: - zaptel or dahdi is in place. Meetme() needs a time source and zaptel or dahdi wil provide one. For the newer versions of Asterisk you need dahdi. - there is some music on hold available. There should be some files in /var/lib/asterisk/moh - the two servers (Openbts and the autodial server) are on the same network. It is actually an autodial routine with one leg that continues and the other leg will be renewed with every new call that is set up. It isn't as simple as I had hoped it would be and some Asterisk magic is involved, but I still hope that this is useful in some way. I really hope the OpenBootts can be used to set this up (mysql for cdr and phpmyadmin for the frontend of the database, dahdi, moh etc.). This would make live much more easier. I copy the working version from my own system. There are some Dutch named variables used and some variables that aren't needed anymore but for now I keep them in place so I'm sure that the routine will work. When there seem to be some response I will add it to the wiki and "translate" the dutch named variables. Some parameters are hardcoded while it seem logic to pass them on while starting the script. I hope this can be used to get some hard data about the quality in terms of succesrate of setting up calls, maintaining calls for a certain period and data about the sound quality provided by a openBTS based solution. The legal stuff is pretty standard so don't be worried about it. I'm looking forward to reaction, critics and compliments ;-) Erik ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; auteur : Erik de Wild ; company : Tripple-o : Your Asterisk migration partner ; e-mail : info at tripple-o.nl ; phone : 0031621830837 ; ; Rights : Tripple-o owns the rights to this dialplan ; Country : the Netherlands ; Time Zone : GMT +1 ; ; version : 1.0 ; date : 14 februari 2010 ; License : This dialplan is GPL3 licensed with the condition that ; this header is kept in place, credits are addressed and you don't charge ; money for the autodial solution as it is. Under this conditions you are allowed to use, change and ; redistribute it. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; /////////////////////////////// /// example of flat file for numbers /var/lib/asterisk/agi-bin/ test_nummers //////////////////////////// 1006 1007 1008 1009 1010 1011 1012 1013 /////////////////////////// //// the bash script used to start the testing ////////////////////////// #!/bin/bash # read a file line by line #### # hardcoded variables so it runs without parameters #### account_code=1005 agent_nummer=1005 file=test_nummers x=0 lns=`wc -l $file` y=`expr "$lns" : '\([0-9]*\)'` regel=' ' while [ "$x" -lt "$y" ] do let x=x+1 ################## # add all numbers to one variable ################## regel=$regel$(head -n $x $file | tail -n 1)' ' done ################### # generate and move the file to /var/spool/asterisk/outgoing so the file is processed by Asterisk so the leg of the agent will be routed to conference room ################### echo $regel echo Channel: SIP/trunk-paris-lyon/$agent_nummer > /var/ spool/asterisk/meetmecall/accounts/$account_code/autodial_callfiles/ autodial.call echo MaxRetries: 0 >> /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial.call echo RetryTime: 60 >> /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial.call echo WaitTime: 30 >> /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial.call echo Context: autodial_agent >> / var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial.call echo Extension: s > > /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial.call echo Priority: 1 > > /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial.call echo SetVar: AGENT_NUMMER=$agent_nummer >> /var/spool/ asterisk/meetmecall/accounts/$account_code/autodial_callfiles/ autodial.call echo SetVar: ACCOUNT=$account_code >> / var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial.call echo SetVar: AANTAL_NUMMERS=$y >> / var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial.call echo ' ' > > /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial.call mv /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial.call /var/spool/asterisk/outgoing/ echo first call file ready sleep 15 # the 15 seconds gives time for the agent to pick up the phone before the first call comes in. ############# # generate a call file so the list with numbers and the relevant variables so they can be passed to Asterisk and use to set up calls to the numbers in the list ############# echo start making second callfile echo Channel: Local/ s@autodial_2 > /var/spool/ asterisk/meetmecall/accounts/$account_code/autodial_callfiles/ autodial_2.call echo MaxRetries: 0 >> /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial_2.call echo RetryTime: 60 >> /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial_2.call echo WaitTime: 30 >> /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial_2.call echo Context: autodial_fake_2 >> /var/ spool/asterisk/meetmecall/accounts/$account_code/autodial_callfiles/ autodial_2.call echo Extension: s >> /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial_2.call echo Priority: 1 > > /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial_2.call echo SetVar: AGENT_NUMMER=$agent_nummer >> /var/spool/ asterisk/meetmecall/accounts/$account_code/autodial_callfiles/ autodial_2.call echo SetVar: NUMMER_LIJST=$regel >> / var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial_2.call echo SetVar: ACCOUNT=$account_code >> /var/ spool/asterisk/meetmecall/accounts/$account_code/autodial_callfiles/ autodial_2.call echo SetVar: AANTAL_NUMMERS=$y >> / var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial_2.call echo SetVar: START_NUMMER=0 >> /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial_2.call echo SetVar: POSITION=1 >> / var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial_2.call echo ' ' > > /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial_2.call echo be ready to answer the calls ############ #move the call file to /var/spool/asterisk/outgoing so the call file is processed and the sequence of the calls of the list is started ############ mv /var/spool/asterisk/meetmecall/accounts/$account_code/ autodial_callfiles/autodial_2.call /var/spool/asterisk/outgoing/ $account_code echo calls are coming exit 0 ///////////////////////////////////// ////// /etc/asterisk/extensions.d/autodialer.conf //////////////////////////////////// ;############ ;# a call file pointing to a local channel always needs two legs. This fake leg makes Asterisk happy ;############ [autodial_fake_2] exten => s,1,Answer() exten => s,,NoOp(fake channel) exten => s,n,Wait(30000) exten => s,n,Hangup() [autodial_2] ;#################### ; You have to adjust this part to your needs. I use 4 digits numbers and the numbers are seperated by a space s every number takes ; 5 positions. Te lines below store the first 5 digits into variable TE_BELLEN_NUMMER (dutch for NUMBER_TO_CALL), strips the space in front so 4 digits are left ; removes the first 5 positions from the variable NUMMER_LIJST (dutch for NUMBER_LIST), set some cdr variables and makes the phone call ;################### exten => s,1,Answer() exten => s,n(start),Set(LENGTE_STRING=${LEN(${NUMMER_LIJST})}) ;;;;;;;;;; ; a check for the length of the variable has to be added. If ${LEN($ {NUMMER_LIJST})}=0 ; then routine can stp ;;;;;;;; exten => s,n,Set(TE_BELLEN_NUMMER=${NUMMER_LIJST:0:5}) exten => s,n,Set(TE_BELLEN_NUMMER=${TE_BELLEN_NUMMER:1:4}) exten => s,n,Set(NUMMER_LIJST=${NUMMER_LIJST:5:$[${LENGTE_STRING} - 5]}) exten => s,n,Set(CDR(accountcode)=${ACCOUNT}) exten => s,n,Set(CDR(userfield)=AD_${TE_BELLEN_NUMMER}) ;########### ; the g parameter keeps one leg alive after the other leg hangs up. ; the M parameter takes care of pointing directly to a macro after the call is picked up ;############ exten => s,n(bellen),Dial(SIP/trunk-paris-lyon/$[${TE_BELLEN_NUMMER}], 40,gM(enter_conference,${TE_BELLEN_NUMMER})) exten => s,n,wait(5) exten => s,n,ResetCDR(w) exten => s,n,NoOp(Call is finished and loop goes on) exten => s,n,Set(CDR(accountcode)=${ACCOUNT}) exten => s,n,Set(CDR(userfield)=AD_WRAPUP_TIME) exten => s,n,Hangup() ;###################### ; the "h" extension is executed after the call is hanged up on the callees side. The variables that has to be passed for the next call are added ; the call file is moved to /var/spool/asterisk/outgoing and context autodial_2 is executed again until all numbers are called. ;###################### exten => h,1,System(echo Channel: Local/ s@autodial_2 > /var/spool/ asterisk/meetmecall/accounts/${ACCOUNT}/autodial_callfiles/ autodial_2call_${LEN(${NUMMER_LIJST})}) exten => h,n,System(echo MaxRetries: 1 >> /var/spool/asterisk/meetmecall/accounts/${ACCOUNT}/ autodial_callfiles/autodial_2call_${LEN(${NUMMER_LIJST})}) exten => h,n,System(echo RetryTime: 60 >> /var/spool/asterisk/meetmecall/accounts/${ACCOUNT}/ autodial_callfiles/autodial_2call_${LEN(${NUMMER_LIJST})}) exten => h,n,System(echo WaitTime: 30 >> /var/spool/asterisk/meetmecall/accounts/${ACCOUNT}/ autodial_callfiles/autodial_2call_${LEN(${NUMMER_LIJST})}) exten => h,n,System(echo Context: autodial_fake_2 >> /var/ spool/asterisk/meetmecall/accounts/${ACCOUNT}/autodial_callfiles/ autodial_2call_${LEN(${NUMMER_LIJST})}) exten => h,n,System(echo Extension: s >> /var/spool/asterisk/meetmecall/accounts/${ACCOUNT}/ autodial_callfiles/autodial_2call_${LEN(${NUMMER_LIJST})}) exten => h,n,System(echo Priority: 1 > > /var/spool/asterisk/meetmecall/accounts/${ACCOUNT}/ autodial_callfiles/autodial_2call_${LEN($ {NUMMER_LIJST})}) $ exten => h,n,System(echo SetVar: AGENT_NUMMER=1005111 >> /var/spool/asterisk/ meetmecall/accounts/${ACCOUNT}/autodial_callfiles/autodial_2call_$ {LEN(${NUMMER_LIJST})}) exten => h,n,System(echo SetVar: NUMMER_LIJST=${NUMMER_LIJST} >> /var/spool/asterisk/meetmecall/accounts/${ACCOUNT}/ autodial_callfiles/autodial_2call_${LEN(${NUMMER_LIJST})}) ;exten => h,n,System(echo SetVar: START_NUMMER=${START_NUMMER} >> / var/spool/asterisk/meetmecall/accounts/${ACCOUNT}/autodial_callfiles/ autodial_2call_${LEN(${NUMMER_LIJST})}) ;exten => h,n,System(echo SetVar: POSITION=$ {POSITION} >> /var/spool/asterisk/ meetmecall/accounts/${ACCOUNT}/autodial_callfiles/autodial_2call_$ {LEN(${NUMMER_LIJST})}) exten => h,n,System(echo SetVar: ACCOUNT=1005 >> /var/ spool/asterisk/meetmecall/accounts/${ACCOUNT}/autodial_callfiles/ autodial_2call_${LEN(${NUMMER_LIJST})}) exten => h,n,System(echo ' ' > > /var/spool/asterisk/meetmecall/accounts/${ACCOUNT}/ autodial_callfiles/autodial_2call_${LEN(${NUMMER_LIJST})}) exten => h,n,System(echo ' ' > > /var/spool/asterisk/meetmecall/accounts/${ACCOUNT}/ autodial_callfiles/autodial_2call_${LEN(${NUMMER_LIJST})}) exten => h,n,System(echo ' ' > > /var/spool/asterisk/meetmecall/accounts/${ACCOUNT}/ autodial_callfiles/autodial_2call_${LEN(${NUMMER_LIJST})}) exten => h,n,NoOp( be ready to answer the next call) exten => h,n,System(cp /var/spool/asterisk/meetmecall/accounts/$ {ACCOUNT}/autodial_callfiles/autodial_2call_${LEN(${NUMMER_LIJST})} / var/spool/asterisk/outgoing/autodial_2call_${LEN(${NUMMER_LIJST})}) exten => h,n,NoOp(The next call is coming!!) [autodial_agent] exten => s,1,Answer() exten => s,n,Set(CDR(accountcode)=${ACCOUNT}) exten => s,n,Set(CDR(userfield)=AD_AGENT_${ACCOUNT}) ;exten => s,n,MusicOnHold() exten => s,n,Meetme(100,asM) exten => s,n,Hangup() [macro-enter_conference] ; used for the numbers that has been called exten => s,1,NoOp(start macro enter_conference in kamer 100 voor telefoonnummer ${ARG1}) ;exten => s,n,MusicOnHold() exten => s,n,Meetme(100) exten => s,n,MacroExit() ////////////////////// /// addition for the sip trunk in /etc/sip.sip.conf based on instruction on http://www.panoramisk.com/90/sip-trunk-with-asterisk/en/ ///////////////////// ////// on the machine with the autodial routine //////////////////// [trunk-paris-lyon] type=peer nat=no host=<IP number of OpenBTS machine> /////////////// // on the machine running OpenBTS /////////////// [trunk-lyon-paris] type=peer host=<IP number of the autodialer Asterisk box> nat=no call-limit=7 ; the number of available channels context=from-asterisk-paris ; context in use to "catch" calls coming in over the trunk. If you use the hotdeks routine (see the wiki) then you can call to normal numbers, otherwise you have to call to IMSI numbers. //////////////////////// // add room 100 to /etc/asterisk/meetme.conf exten => 100 (if you add it below the example room ;exten => 1234 it would be fine ) |
From: Donald C. K. <don...@op...> - 2010-02-12 22:49:09
|
Hi Giedrius, *//* On 2/12/10 5:24 AM, voipas wrote: > Hi, > One more question. Does smqueue need for OpenBTS, if I want use sms > gateway (for example Kannel)? Or smqueue is only used for local > OpenBTS subscribers? > Thanks Right now smqueue only supports local delivery. In the future it will support SMPP so that you can use Kannel. There are example configurations in apps/OpenBTS.config.example for using an SMS HTTP Gateway. This will bypass smqueue. -Donald |
From: voipas <vo...@gm...> - 2010-02-12 18:35:53
|
2010/2/11 David A. Burgess <dbu...@jc...> > This doesn't sound like a clock problem. It sounds more like an L3 > protocol problem, probably in CallControl.cpp. There are a few 30 > second timers in Q.931 that will disconnect a call if specific > conditions are not met during call setup. Try 2.5.3 and see if you > have the same problem, since there are a few L3 bug fixes in there. > > > The problem still exists. Nothing changes. |
From: voipas <vo...@gm...> - 2010-02-12 13:24:22
|
Hi, One more question. Does smqueue need for OpenBTS, if I want use sms gateway (for example Kannel)? Or smqueue is only used for local OpenBTS subscribers? Thanks -- Best Regards, Giedrius |
From: David A. B. <dbu...@jc...> - 2010-02-11 16:50:24
|
This doesn't sound like a clock problem. It sounds more like an L3 protocol problem, probably in CallControl.cpp. There are a few 30 second timers in Q.931 that will disconnect a call if specific conditions are not met during call setup. Try 2.5.3 and see if you have the same problem, since there are a few L3 bug fixes in there. On Feb 11, 2010, at 5:31 AM, Alexander Chemeris wrote: > Giedrius, > > What clock do you use? > > On Thu, Feb 11, 2010 at 16:20, voipas <vo...@gm...> wrote: >> The problem appears only when I'm using Sony Ericsson P900. With >> other >> mobile phones I've made test calls with durations > 2 mins. >> -- >> Best Regards, >> Giedrius >> David A. Burgess Kestrel Signal Processing, Inc. |
From: Alexander C. <ale...@gm...> - 2010-02-11 15:38:10
|
Giedrius, Try checking frequency offset with spectrum analyzer or with 'kal' utility. On Thu, Feb 11, 2010 at 18:27, voipas <vo...@gm...> wrote: > The log file archive's size is 7 MB. I think it's not good idea to send it. > I've read http://students.ee.sun.ac.za/~gshmaritz/?p=152 , and I think that > I have the same problem. Some my mobile phones can't find my network, but > one exception was (the mob received a lot of sms, but after restart - again > didn't find). -- Regards, Alexander Chemeris. |
From: voipas <vo...@gm...> - 2010-02-11 15:27:14
|
The log file archive's size is 7 MB. I think it's not good idea to send it. I've read http://students.ee.sun.ac.za/~gshmaritz/?p=152 , and I think that I have the same problem. Some my mobile phones can't find my network, but one exception was (the mob received a lot of sms, but after restart - again didn't find). -- Best Regards, Giedrius |
From: Alexander C. <ale...@gm...> - 2010-02-11 14:47:03
|
On Thu, Feb 11, 2010 at 17:38, voipas <vo...@gm...> wrote: > I've only bought from Kestrel Online Store Development KIT. Then frequency drift should not a problem here, I guess. Still, you may check frequency offset before a call and right after the call has been dropped. Post here OpenBTS log at DEBUG level of a dropped call. May be there will be some clue. -- Regards, Alexander Chemeris. |
From: voipas <vo...@gm...> - 2010-02-11 14:45:29
|
The USRP has installed 52MHz clock board -- Best Regards, Giedrius |