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 <mailto: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 > <mailto:zamiguy...@gmail.com>] > Sent: Tuesday, March 24, 2015 5:33 AM > To: openbts-disc...@lists.sourceforge.net > <mailto: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 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
