Hi Marcus, Thanks for the instant tips. One question. As I aware the latest bug free UHD package is uhd-master. Though my last build was related with uhd-master, since I have tried different ways of GNURadio and UHD installations (pybombs option, download-unzip-build option, debian download),* I suspect a uhd version mismatch and thereby hindering the USRP transmission?* (Please pardon me for my lack of knowledge in this field. And I am pretty sure that there should not be duplicate versions though).
Hi Openbts, 1) Please address the issues specified in previous threads. 2) According to the link [1], once after OpenBTS build, should run, ln -s ../Transceiver52M/transceiver . whereas in another link [2], the executions are, ln -s ../TransceiverRAD1/transceiver . ln -s ../TransceiverRAD1/ezusb.ihx . ln -s ../TransceiverRAD1/fpga.rbf . Does this confuse the OpenBTS same as me? Does this have an impact on the issues given in 1)? Thanks. [1] http://opensource.telkomspeedy.com/wiki/index.php/OpenBTS:_N210_Instalasi_OpenBTS [2] https://wush.net/trac/rangepublic/wiki/BuildInstallRun On Tue, Mar 24, 2015 at 8:59 PM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Hi Zamrath, > > Could I know the reason for USRP connection loss? > > there's no connection loss -- the USRP is just now talking to the OpenBTS > application, and won't talk to other applications, including uhd_usrp_probe. > > Surely transmission LED (labeled A) is not working. > > Ok, that means the USRP is not configured to receive samples, ie. the > software (OpenBTS) has not yet started to talk to it, possibly because > something went wrong. Since we already constantly cross-post with the > OpenBTS list (hi, people!), I recommend going through the output of > OpenBTS, and talking to the OpenBTS community about these messages. > > I am bit confused here whether this is a deal of OpenBTS or GNURadio. > > GNU Radio is completely unrelated to this problem -- it's not a part of > OpenBTS. > > Does the processor speed come in to play in this scenario? > > At this point, probably not. Even with a lot of Under-/Overflows, which > would be typical for a case of CPU bottleneck, the A LED should be shining. > > Greetings, > Marcus > > > On 03/24/2015 04:19 PM, Zamrath Nizam wrote: > > Thanks for the early reply Ralph. > > >>> First of all, it is normal that the USRP is not detected anymore > with the uhd tools when it is claimed by OpenBTS. So this looks not > alarming. > > Note that our successful implementation did not have any issue with > UHD-USRP connection. It worked as it was before OpenBTS claims it. Hope > this is 'actually normal' without interrupting the main intended functions. > Right? Could I know the reason for USRP connection loss? > > >>> Are you able to verify if RF is transmitted? Is there some spectrum > analyzer available, or a receiver that can tune into the used GSM > frequency, best is AM mode and open squelch, to see if a carrier is > present? This way you can find out if it transmits at all, and if so, it > must be continously, uninterruptes, without stuttering. > > Yes. Oh no! Surely transmission LED (labeled A) is not working. Which > means that there is a RF transmission problem in our build. Reading through > several threads on similar problem, I don't think it is a hardware issue, > rather software compatibility issue. What would be the remedy for this? > > >>> I assume your successful tests used the very same USRP, so the > frequency should not be off too far?! > > Yes. The similar N210 version was tried with the same set of software. > > Could you please address above issues. > > Best, > Zamrath Nizam > > On Tue, Mar 24, 2015 at 12:16 PM, Ralph A. Schmid, dk5ras < > ra...@schmid.xxx> wrote: > >> First of all, it is normal that the USRP is not detected anymore with >> the uhd tools when it is claimed by OpenBTS. So this looks not alarming. >> >> >> >> Are you able to verify if RF is transmitted? Is there some spectrum >> analyzer available, or a receiver that can tune into the used GSM >> frequency, best is AM mode and open squelch, to see if a carrier is >> present? This way you can find out if it transmits at all, and if so, it >> must be continously, uninterruptes, without stuttering. >> >> >> >> I assume your successful tests used the very same USRP, so the frequency >> should not be off too far?! >> >> >> >> Ralph. >> >> >> >> From: Zamrath Nizam [mailto:zamiguy...@gmail.com] >> Sent: Tuesday, March 24, 2015 5:33 AM >> To: openbts-disc...@lists.sourceforge.net; GNURadio Discussion List >> Subject: [Openbts-discuss] -------'Range' network is not detected------- >> >> >> >> Hi all, >> >> >> >> I have recently installed OpenBTS-2.8 on a Banana-Pi (Processor: ARMv7) >> board for USRP N210 functioning. All the prerequisites including GNURadio, >> UHD were successfully built on the board prior to OpenBTS installation. >> With all configurations done, still there is a problem in the USRP >> connection. >> >> I have configured MCC, MNC and ethernet IP connection. "ping >> 192.168.10.2" works fine. Once the ethernet connection is established and >> until "./OpenBTS" is executed, "uhd_find_devices" and "uhd_usrp_probe" >> detect USRP. After the execution of "./OpenBTS", surprisingly >> "uhd_find_devices" and "uhd_usrp_probe" do not detect the device and say >> "No device found..." ('ping' is still working though). The strangest thing >> is even at this stage, "./OpenBTS" works fine even at a re-run. >> >> After all these drama, no ('range') network is detected by a properly >> configured mobile phone. (Note: We have successfully placed calls and SMS >> with almost same procedure using a PC instead of B-Pi). >> >> I am bit confused here whether this is a deal of OpenBTS or GNURadio. >> Does the processor speed come in to play in this scenario? >> >> Any valuable suggestions would be highly appreciated. >> >> >> >> Thank you. >> >> >> >> Zamrath Nizam >> > > > > _______________________________________________ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
