Re: [Discuss-gnuradio] [Openbts-discuss] -------'Range' network is not detected-------
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 list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Openbts-discuss] -------'Range' network is not detected-------
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
Re: [Discuss-gnuradio] [Openbts-discuss] -------'Range' network is not detected-------
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 list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Openbts-discuss] -------'Range' network is not detected-------
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
