From: HW W. <ffp...@gm...> - 2011-04-12 17:04:40
|
It works when I put an antenna at the TX, while it was not a must when using the old clock. On Wed, Apr 13, 2011 at 12:57 AM, HW Wong <ffp...@gm...> wrote: > Thanks for advice. The 52M clock should works as I can listen to the FM > radio. > > I fixed it according to your email and the error has gone. > > However, my handsets still can't search for the BTS. (It seems that one of > my handset had joined it suddenly for once only. Then I can never search for > it) > > I get the following value for wFreq-actFreq and m_uTx->tx_freq(0) : > > > 1302626266.2814 ALARM 3078085488 USRPDevice.cpp:635:setTxFreq: 52M set TX: > -3875000.0000 actual TX: -3874999.2847 > > > but > > 1302600410.3125 ALARM 3074415472 USRPDevice.cpp:533:setTxFreq: 64M set TX: > -5000000.0000 actual TX: -5000000.0000 > > for the 64M clock > > > and what's the LO_OFFSET use for? > tx_setFreq(wFreq+LO_OFFSET,&actFreq); > > > > On Tue, Apr 12, 2011 at 11:25 PM, Joshua Lackey <jl...@th...> wrote: > >> Checking it with kal pretty much proved that your clock modification >> worked. >> >> You need to patch OpenBTS and remove some experimental code that >> accidently went out in 2.6.0. (This has been mentioned here before and >> should really be in a FAQ somewhere...) >> >> >> jl@hackphoo:~/src/openbts$ diff -C 3 >> openbts-2.6.0Mamou/Transceiver52M/USRPDevice.cpp >> openbts-2.6.0Mamou-DEFENSICS-SMS/Transceiver52M/USRPDevice.cpp >> *** openbts-2.6.0Mamou.orig/Transceiver52M/USRPDevice.cpp 2010-07-16 >> 17:01:45.000000000 -0700 >> --- openbts-2.6.0Mamou/Transceiver52M/USRPDevice.cpp 2011-04-05 >> 15:59:06.279967994 -0700 >> *************** >> *** 607,613 **** >> bool USRPDevice::setTxFreq(double wFreq) { >> // Tune to wFreq+LO_OFFSET, to prevent LO bleedthrough from >> interfering with transmitted signal. >> double actFreq; >> ! if (!tx_setFreq(wFreq+9*LO_OFFSET,&actFreq)) return false; >> bool retVal = m_uTx->set_tx_freq(0,(wFreq-actFreq)); >> LOG(INFO) << "set TX: " << wFreq-actFreq << " actual TX: " << >> m_uTx->tx_freq(0); >> return retVal; >> --- 607,613 ---- >> bool USRPDevice::setTxFreq(double wFreq) { >> // Tune to wFreq+LO_OFFSET, to prevent LO bleedthrough from >> interfering with transmitted signal. >> double actFreq; >> ! if (!tx_setFreq(wFreq+LO_OFFSET,&actFreq)) return false; >> bool retVal = m_uTx->set_tx_freq(0,(wFreq-actFreq)); >> LOG(INFO) << "set TX: " << wFreq-actFreq << " actual TX: " << >> m_uTx->tx_freq(0); >> return retVal; >> *************** >> *** 621,627 **** >> // in front of the ADC. This possibly gives us an extra 10-20dB >> Tx/Rx isolation. >> double actFreq; >> // FIXME -- This should bo configurable. >> ! if (!rx_setFreq(wFreq-5*LO_OFFSET,&actFreq)) return false; >> bool retVal = m_uRx->set_rx_freq(0,(wFreq-actFreq)); >> LOG(DEBUG) << "set RX: " << wFreq-actFreq << " actual RX: " << >> m_uRx->rx_freq(0); >> return retVal; >> --- 621,627 ---- >> // in front of the ADC. This possibly gives us an extra 10-20dB >> Tx/Rx isolation. >> double actFreq; >> // FIXME -- This should bo configurable. >> ! if (!rx_setFreq(wFreq-2*LO_OFFSET,&actFreq)) return false; >> bool retVal = m_uRx->set_rx_freq(0,(wFreq-actFreq)); >> LOG(DEBUG) << "set RX: " << wFreq-actFreq << " actual RX: " << >> m_uRx->rx_freq(0); >> return retVal; >> >> >> >> >> Quoting HW Wong (ffp...@gm...): >> > Thanks for your reply. >> > I am using the same config with another 64M USRP. The handsets can >> register >> > it. >> > >> > The Kal 0.4 runs with the 52M clock. >> > >> > I follow the >> > Reclocking the USRP-1 for >> > OpenBTS<http://gnuradio.org/redmine/wiki/gnuradio/OpenBTS> >> > * No changes to gnuradio are necessary if do not need default gnuradio >> > applications and examples (like usrp_fft.py). If you need them, then you >> > should apply the following patch: >> > >> > >> > I trace the coding in Transceiver52M, till USRPDevice.cpp >> > >> > >> > #ifndef SWLOOPBACK >> > bool USRPDevice::setTxFreq(double wFreq) { >> > ... >> > bool retVal = m_uTx->set_tx_freq(0,(wFreq-actFreq)); >> > LOG(ALARM) << "52M set TX: " << wFreq-actFreq << " actual TX: " << >> > m_uTx->tx_freq(0); >> > >> > } >> > >> > the retVal is false, >> > 1302599970.4680 ALARM 3078830960 USRPDevice.cpp:636:setTxFreq: 52M set >> TX: >> > -36375000.0000 actual TX: 0.0000 >> > >> > >> > While the value of an original USRP is: >> > true >> > >> > 1302600410.3125 ALARM 3074415472 USRPDevice.cpp:533:setTxFreq: 64M set >> TX: >> > -5000000.0000 actual TX: -5000000.0000 >> > >> > >> > Any idea? >> > Thanks! >> > >> > >> > >> > On Tue, Apr 12, 2011 at 4:25 PM, Axelle <aaf...@gm...> wrote: >> > >> > > Hi, >> > > >> > > >> > > > It's a 52M TXCO the same kind with the one in OpenBTS for dummy's >> > > > introduction. >> > > > I then updated the OpenBTS.config to use Transceiver52M and get the >> > > follow >> > > > error: >> > > > 1302589150.3524 ALARM 3077639024 Transceiver.cpp:551:driveControl: >> TX >> > > failed >> > > > to tune >> > > > 1302589150.3526 ALARM 3074148576 TRXManager.cpp:371:tune: TXTUNE >> failed >> > > with >> > > > status 1 >> > > > Would anyone please kindly to advice? Thanks! >> > > >> > > Did you patch GnuRadio too ? >> > > Have you tested your USRP like in 6.1. and 6.2 of the For dummies ? >> > > Does it show a peek for ~1800Mhz (figure 7) ? >> > > >> > > Good luck, >> > > Axelle >> > > >> > > >> > > >> ------------------------------------------------------------------------------ >> > > Forrester Wave Report - Recovery time is now measured in hours and >> minutes >> > > not days. Key insights are discussed in the 2010 Forrester Wave Report >> as >> > > part of an in-depth evaluation of disaster recovery service providers. >> > > Forrester found the best-in-class provider in terms of services and >> vision. >> > > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo >> > > _______________________________________________ >> > > Openbts-discuss mailing list >> > > Ope...@li... >> > > https://lists.sourceforge.net/lists/listinfo/openbts-discuss >> > > >> >> > >> ------------------------------------------------------------------------------ >> > Forrester Wave Report - Recovery time is now measured in hours and >> minutes >> > not days. Key insights are discussed in the 2010 Forrester Wave Report >> as >> > part of an in-depth evaluation of disaster recovery service providers. >> > Forrester found the best-in-class provider in terms of services and >> vision. >> > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo >> > _______________________________________________ >> > Openbts-discuss mailing list >> > Ope...@li... >> > https://lists.sourceforge.net/lists/listinfo/openbts-discuss >> >> > |