David forwarded along some code I'm working on. I'm trying to get
openbts to work with one RFX card and one other receive-only card.
I'm really hoping that someone with a working setup (two RFX900s) can
try it out to make sure their setup still works with my code.
At the very least, the code I provide should be safer than the current
code. It checks the daughterboard-ids and uses libusrp to set
parameters. (I.e., it won't hurt the hardware and the worst it will do
is just not receive RACH bursts.)
Today I modified readSamples() to take the packet data from each
received USB packet, turn it into a complex value, and then write it to
a FIFO. I wrote a quick file_fft.py so I could look at the output.
The data doesn't make much sense. At the very least it has a lot of
noise. (So I spent an hour or so making a shield for the DBSRX out of
bits of stuff I had around to see if that helped. It didn't.)
My next step is to remove the current support for "std_inband.rbf" from
readSamples() and port over the, now standard, inband support from
libusrp. While I don't think this could be causing the problems with
the data I'm receiving, I don't have any other great ideas right now.
In any case, if someone could check and make sure that two RFX900s still
work for them, it would be helpful.
Thanks!
Quoting David A. Burgess (dburgess@...):
> Joshua -
>
> I'm posting this to the list for general interest and will continue
> the discussion there.
>
> -- David
>
> Begin forwarded message:
>
> >From: Joshua Lackey <jl@...>
> >Date: March 15, 2009 5:52:09 PM PDT
> >To: "David A. Burgess" <dburgess@...>
> >Subject: Re: openbts: subscribe mailing list
> >
> >Quoting David A. Burgess (dburgess@...):
> >>
> >>On Mar 10, 2009, at 11:17 AM, Joshua Lackey wrote:
> >[...]
> >>>USRP. Which isn't particularly difficult, just that there is no
> >>>a-priori reason why a receive-only board shouldn't work with your
> >>>software.
> >>
> >>That sounds interesting. We are sticking with rx/tx boards ourselves
> >>because we want to build diversity receivers as soon as we get the
> >>crosstalk problem fixed. But still, it's interesting.
> >
> >I've been planning on getting a usrp2 and I'll get another rfx when I
> >do. Your code works fine with the rev2 usrp and I don't see any
> >reason
> >why it won't work with the usrp2.
> >
> >
> >[...]
> >>Again, Harvind knows this part of the system a lot better than I do.
> >
> >I double-checked everything. It was all straight-forward.
> >
> >>>4. An inband rbf is used, however I'm not sure what "std_inband.rbf"
> >>> does differently than, for example, "inband_1rxhb_1tx.rbf" I'd
> >>> prefer to use an rbf from the GNURadio distribution but it
> >>>would be
> >>> good to know if this is okay.
> >>
> >>We implemented some inband signaling features ourselves before they
> >>were a standard part of the release, and so we are tied to an older
> >>FPGA image until we update our code to work with the newer versions.
> >>Again, this is on the list of stuff to clean up once this injunction
> >>is lifted.
> >
> >Ah, okay. Does any code outside of the USRPDevice class depend on this
> >older version?
> >
> >
> >>>Thanks for your time! I should be able to finish this today and
> >>>perform
> >>>some tests to make sure it works. I'd be glad to drop you a quick
> >>>note
> >>>summarizing my results.
> >>
> >>Any results to report?
> >
> >The NewIberia version was much more stable and allowed me to work
> >on the
> >daughterboard code rather than trying to debug everything all at once.
> >My changes were very easy and didn't require much.
> >
> >However, I haven't received a successful RACH burst yet. My phone
> >sees
> >the BTS (it tunes to the correct ARFCN) but the receive-side never
> >demodulates the RACH burst correctly. I've been dumping the energy in
> >each potential burst and it doesn't seem to change even when I remove
> >the antenna...
> >
> >Do you mind verifying that your setup still works with my
> >USRPDevice.{cpp,h}? While I don't think that will help me figure out
> >why the DBSRX is so deaf, at least that would verify that my generic
> >tuning code is valid.
> >
> >I attach my current code. If you're using GNU Radio 3.1, use the -3.1
> >files. (I've been using the latest svn version of GNU Radio, so I
> >haven't tested the -3.1 files.)
> >
|