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

Reply via email to