Is OpenBTS going to support USRP2?

Hi all,

 Is anyone working on OpenBTS with USRP2? On the website,
http://www.gnuradio.org/trac/wiki/OpenBTS/DesktopTestingKit, OpenBTS has
not been used with URSP2. However, USRP2 is new and fast. I think more
and more people are going to use USRP2 to develp their SDR. Should IÂ
buy a USRP1 or a USRP2 to run OpenBTS?Â

http://www.gnuradio.org/trac/wiki/OpenBTS/DesktopTestingKit shows that
“Do notuse a transmit antenna.”
What does it mean “Do notuse a transmit antenna”? Does it mean that
I don’t need to connect a antenna to a daughter board?
 http://gnuradio.utah.edu/trac/ticket/334 shows "  one RFX-stype
receive section ". Does it mean that “one RFX-style”? A typo?
Â
Â
Thank you,
Jane

Jane -

We (Harvind and I) have no foreseeable plans to use OpenBTS with the
USRP2. There are several reasons we will stick with the USRP1, but
if I detail them on this list I’ll risk getting cited for contempt of
court. Really. http://openbts.sourceforge.net/order.pdf

But OpenBTS is open source, after all, so if more and more people
want to hack OpenBTS to work with the USRP2 they are welcome to do so.

“Do not use a transmit antenna” means “Do not use a transmit
antenna”. I don’t know how to state that more clearly. The reason
is that if you DO use a transmit antenna you will probably be
violating your local radio spectrum regulations, whatever those might
be, and you risk disrupting cellular telephone service for your
immediate neighbors. This would be BAD and I do not sanction it. So
unless you REALLY know what you are doing, you should not use a
transmit antenna. Plenty of power leaks out of the USRP for benchtop
testing and development.

You will need a receive antenna, though. That’s an entirely
different matter.

“RFX-style” means “of the same general style as the RFX900 or
RFX1800”. These two boards are nearly identical, so I lumped them
together in the group “RFX-style”.

– David

On Mar 9, 2009, at 5:36 PM, Jane C. wrote:

http://www.gnuradio.org/trac/wiki/OpenBTS/DesktopTestingKit shows


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

David A. Burgess
Kestrel Signal Processing, Inc.

Hi David,

We (Harvind and I) have no foreseeable plans to use OpenBTS with the
USRP2. Â There are several reasons we will stick with the USRP1, but if I
detail them on this list I’ll risk getting cited for contempt of court.
 Really.  http://openbts.sourceforge.net/order.pdfÂ

Could you please just give me some key words without detail to let me
know how hard it will be to use OpenBTS with USRP2? I read the the
datasheet of USRP1 and USRP2. USRP2 has larger FPGA and higer sample
rate than USRP1. I don’t see a lot of work to use OpenBTS with USRP2.
What are my blind spots?

“Do not use a transmit antenna” means “Do not use a transmit antenna”.
 I don’t know how to state that more clearly.  The reason is that if you
DO use a transmit antenna you will probably be violating your local
radio spectrum regulations, whatever those might be, and you risk
disrupting cellular telephone service for your immediate neighbors.
 This would be BAD and I do not sanction it.  So unless you REALLY know
what you are doing, you should not use a transmit antenna. Â Plenty of
power leaks out of the USRP for benchtop testing and development.

I am sorry! I did not describe my question clearly.
In Antenna (radio) - Wikipedia , it mentioned “antennas
convert electromagnetic waves into electrical currents and vice versa”,
so I thought that antennas are necessary components in transmitting
process. I thought that I can reduce the gain or don’t use an amplifier
to avoid violating my local radio spectrum regulations.

Thank you so much for your time and reply!
Jane

muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ ./OpenBTS

OpenBTS, Copyright 2008-2010 Free Software Foundation, Inc.
Release 2.6PUBLIC built Apr 19 2012
“OpenBTS” is a trademark of Kestrel Signal Processing, Inc.,
regsitered with the US Patent and Trademark Office.

Contributors:
Kestrel Signal Processing, Inc.:
David B., Harvind Samra, Raffi Sevlian, Roshan B.
GNU Radio:
Johnathan C.
Others:
Anne Kwong, Jacob Appelbaum, Joshua L., Alon Levy
Alexander C., Alberto Escudero-Pascual
Incorporated GPL libraries and components:
libosip2, liportp2, readline

This program comes with ABSOLUTELY NO WARRANTY.

This is free software; you are welcome to redistribute it
under the terms of AGPLv3.
Please see the COPYING file in the source code for information
about the AGPLv3 license and recommended procedures for compliance
with the Affero requirements of that license.

Use of this software may be subject to other legal restrictions,
including patent licsensing and radio spectrum licensing.
All users of this software are expected to comply with applicable
regulations and laws.

Starting the system…
1339182654.2386 ALARM 3074128576 OpenBTS.cpp:517:main: OpenBTS starting,
ver
2.6PUBLIC build date Jun 6 2012
linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-1156d9b

1339182654.2560 FORCE 3052370400 Logger.cpp:196:gLogInit: Setting
initial
global logging level to NOTICE
1339182655.3935 ALARM 3052370400 UHDDevice.cpp:335:set_rates: Cannot set
clock rate on this device
1339182655.3936 ALARM 3052370400 UHDDevice.cpp:336:set_rates: Please
compile
with host resampling support
1339182662.2433 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX
clock
interface timed out, assuming TRX is dead.
1339182665.2448 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX
clock
interface timed out, assuming TRX is dead.
1339182668.2481 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX
clock
interface timed out, assuming TRX is dead.
1339182671.2508 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX
clock
interface timed out, assuming TRX is dead.
1339182674.2541 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX
clock
interface timed out, assuming TRX is dead.
1339182677.2574 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX
clock
interface timed out, assuming TRX is dead.
1339182680.2589 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX
clock
interface timed out, assuming TRX is dead.
1339182683.2622 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX
clock
interface timed out, assuming TRX is dead.
1339182686.2628 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX
clock
interface timed out, assuming TRX is dead.
1339182689.2631 ALARM 3065289584 TRXManager.cpp:90:clockHandler: TRX
clock
interface timed out, assuming TRX is dead.
1339182689.2726 ALARM 3074128576 TRXManager.cpp:273:sendCommandPacket:
lost
control link to transceiver
1339182689.2728 ALARM 3074128576 OpenBTS.cpp:672:main: Uncaught
exception.
Shutting down.

exiting…


View this message in context:
http://old.nabble.com/Is-OpenBTS-going-to-support-USRP2--tp22425805p33985231.html
Sent from the GnuRadio mailing list archive at Nabble.com.

OpenBTS works on USRP2s just fine. You need to compile OpenBTS with
host
resampling support, as the build instructions and your error log are
telling you.

http://wush.net/trac/rangepublic/wiki/BuildInstallRun

Cheers,
Ben

Muhammad -

The link I provided has a full list of the commands you need to run.

Cheers,
Ben