discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] TVRX2+USRP (serial > 500) 'invalid EEPROM content


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] TVRX2+USRP (serial > 500) 'invalid EEPROM contents' problem
Date: Mon, 12 Sep 2011 23:36:37 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

On 12/09/11 11:28 PM, Dmitry Shatskiy wrote:
> > Hi,
> >
> > We're using two older USRP boards:
> > 1) Rev. 4.5, Ser. #3542,
> > 2) Rev. 3, Ser. #290 with a clocking scheme modified according to the
> > http://gnuradio.org/redmine/projects/gnuradio/wiki/USRPSerialBelow500 .
> >
> > We're also using a BasicRX daughterboard with both of these
> motherboards and
> > have no problems receiving 150 MHz signals using our code.
> >
> > We were planning to use the newer TVRX2 receivers for the 400 MHz
> signals
> > so we purchased a couple of TVRX2 Rev. 1.1 daughterboards. No
> changes were
> > made to them. After plugging any of the two TVRX2 daughterboards -
> either in
> > addition to BasicRX or separately in any of the receiver slots of
> any of the
> > two USRPs - and trying to execute our code (or any other basic code like
> > usrp_benchmark_usb.py) we get a standard error message:
> >
> > *> Warning: Treating daughterboard with invalid EEPROM contents as if it
> > were a "Basic Rx."
> >> Warning: This is almost certainly wrong... Use appropriate
> burn-*-eeprom
> > utility.*
> >
> ************************************************************************************
>
> It looks like UHD is recognizing you daughterboard just fine, hence the
> string "Name: TVRX2 (0x0046)" in the probe output.
>
> I think you are trying to use the old libusrp1-gnuradio driver, when you
> should be using the gr-uhd source and sink blocks:
> http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Gnuradio-UHD
>
> ************************************************************************************
>
> Thanks for your reply Josh,
>
> So the instructions are:
> (1) Use the script
> OR
> (2) - run "git clone http://gnuradio.org/git/gnuradio.git";,
>     - Follow the Gnuradio build guide:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide,  
>     - check the dependencies and make sure that gr-uhd is enabled in
> the Gnuradio source tree.
>
> I'm positive I did (1) on one of our systems and (2) on another one.
> To the letter. Neither of them work.
>
> I believe the libusrp1-gnuradio driver was installed along with the
> gr-uhd one.
> Is there a way to figure out which library is being used by UHD?
> Is there a way to specifically tell UHD which source and sink blocks
> should be used?
>
> Thank you,
> Dmitry Shatskiy.
>
You're not understanding.  If you use the "classic" API, rather than
UHD, you won't be able to
  correctly deal with a TVRX2, since that card is supported *ONLY* with
the UHD API.  Many of
  the example programs, such as usrp_usb_benchmark.py, use the so-called
"classic" API.  They
  haven't been updated.  It doesn't matter how up-to-date your UHD
installation is, the "classic APIed"
  programs have no knowledge at all of UHD or any of the post-UHD
hardware that's out there.

If you want to check gross functionality of your TVRX2 card, you can use
"uhd_fft.py" to grab an
  FFT spectrum off the card, and make sure that it's working.

If you want to produce your own flow-graphs, you'll have to use the "UHD
source" within GRC.
  The "classic" USRP1 source won't work with the TVRX2 card, because
that card was released
  *after* the classic API was deprecated and no longer being updated.

If you have an up-to-date Ubuntu system, then the 'build-gnuradio'
script should take care of installing
  and building everything you need to make UHD-api "stuff" just work. 
Including within
  gnuradio-companion, "uhd_fft.py", etc.  But none of the "classic" API
examples will work with
  TVRX2, or indeed many of the other post-UHD cards out there.  Since
you're a new user, you have
  no massive reams of code that need to maintain compatibility with the
"old ways", so start learning
  and using UHD.


-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]