Forum: GNU Radio Openbts patches

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3719f4fea703e38bcbf8de6fe6bcdf55?d=identicon&s=25 Martin DvH (Guest)
on 2009-01-19 23:23
(Received via mailing list)
Attachment: mdvh_openbts_tranceiver_patch1.diff (319 Bytes)
Attachment: mdvh_openbts_tranceiver_patch2.diff (326 Bytes)
Hi,

I have been working with OpenBTS in trying to get it to compile and
found two bugs and solved them.

The first bug prevents the OpenBTS tranceiver from starting with the
error "make failed on Rx"

The check on line 173 in USRPDevice should be for !m_uRx in stead of !
m_uTx

The second is that HAVE_BYTESWAP_H is not defined in
Transceiver/USRPDevice.h

This forces usrp_bytesex.h in using its own byteswap code which does NOT
work on 64 bit systems.

The disadvantage of putting #define HAVE_BYTESWAP_H in USRPDevice.h is
that it should be checked first that you actually have byteswap.h.
This should be done by the configure script and put into config.h.
USRPDevice.h then should include config.h

I haven't gotten to implementing the configure stuff yet.

Attached are two mini-patches which implement the changes.

I think patch1 can be submitted to svn right away (Jonathan, I could do
that, should I ?)
patch2 should be changed to use configure stuff to check for byteswap.h.
But for people wanting a quick-and-dirty hack it can be used.

I am not sure if there are more bugs in openbts in gnuradio.
I still get a lot of messages when I start it all up.
1232403472.992511 1085643088: RadioResource.cpp:347 Pager blocking for
signal
1232403472.992521 1085643088: RadioResource.cpp:347 Pager blocking for
signal
1232403472.992530 1085643088: RadioResource.cpp:347 Pager blocking for
signal
Repeats until infinity

I am not sure if this is an error or normal behaviour.

As it is in gnuradio svn, it could not have worked.
Did anyone try/test and got the gnuradio version to work.

Greetings,
Martin
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-01-20 07:38
(Received via mailing list)
On Mon, Jan 19, 2009 at 2:22 PM, Martin DvH
<gnuradiomail@olifantasia.com> wrote:

> The first bug prevents the OpenBTS tranceiver from starting with the
> error "make failed on Rx"
>
> The check on line 173 in USRPDevice should be for !m_uRx in stead of !
> m_uTx

Thanks for catching this, this was a bug I introduced when changing
the code to work with the new daughterboard API.

I've checked it in.

> patch2 should be changed to use configure stuff to check for byteswap.h.
> But for people wanting a quick-and-dirty hack it can be used.

Let me know if you do a configure update for this, but I'd like to
look at it before it is committed.

-Johnathan
3719f4fea703e38bcbf8de6fe6bcdf55?d=identicon&s=25 Martin DvH (Guest)
on 2009-01-21 00:01
(Received via mailing list)
On Mon, 2009-01-19 at 22:37 -0800, Johnathan Corgan wrote:
> the code to work with the new daughterboard API.
>
I get it.
I checked the new daughterboard API changes and it looks good to me.
So in theory it should be possible to setup an OpenBts system with the
current code.

I am at the moment still struggling to get the IMSI code out of my
phone/SIM.

I have several old nokia phones (5110, 6150, 3410) , but so far I
haven't been able to get one of them to into field mode. Using either
keycode (*3001#12345#) or serial data-cable + gnokii.


> I've checked it in.
>
> > patch2 should be changed to use configure stuff to check for byteswap.h.
> > But for people wanting a quick-and-dirty hack it can be used.
>
> Let me know if you do a configure update for this, but I'd like to
> look at it before it is committed.
I will have a look at it.
Further development/testing from me on this will stall for a short time
until my new stock of RFX1800 USRP daughterboards arrive.
(I am totally sold-out on these)

Martin
This topic is locked and can not be replied to.