Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2

[Manav Seth]

Hi Matt,

Ya, I am having the second problem. But, I have the gnuradio 3.2.2 code base only. Will try to checkout again from the git repository and build.

Anyways, I did have a working card. So if this does not work, I will try to copy this card to all the other cards.

Can you please guide me how to copy a SD hard having a working image to another using a card reader. Today I tried doing this but the card was not being recognised.

Thanks,

Manav

On Wed, Feb 3, 2010 at 10:26 PM, Matt Ettus <address@hidden> wrote:

Manav,

Sorry for not being active in this thread.  Things have been very busy here.  In any case, it sounds like you are seeing something very different from Ian.  You are having one of 2 problems --

-  You received bad SD cards.  If you power up your USRP2 with the SD card in it, and you don't see 2 LEDs light up on the front panel, then this is what you are seeing, and it has nothing to do with the XCVR2450.  Go to this page and follow the directions there:

       http://www.ettus.com/flash

- If the card is not bad, then you have a flash version which does not match your GNU Radio install.  Newer flash cards come with new versions of the firmware and FPGA, but these will only work with updated GNU Radio code.  If this is the case, you either need to update GNU Radio, or put an old version of the FPGA and firmware on your card.  I recommend the first option.

Matt

On 02/02/2010 05:08 PM, Manav Seth wrote:

Ya, what I mean is that for you too the problem may be the SD card only.
Actually we had got around 20 USRP's/daughterboards from Ettus and none
of them were working with the SD cards they supplied with them (20 in
all). When I tried with an older SD card, it worked.

On Tue, Feb 2, 2010 at 5:43 PM, Ian Holland <address@hidden

<mailto:address@hidden>> wrote:

   Hi Manav

   I tried both of my daughterboards with the same SD card in the
   USRP2, so perhaps we were actually facing different problems, or at
   least I am facing an additional problem with one of my cards.

   Your problem may be resolved once you try Josh’s earlier suggestion
   of reflashing the latest FPGA and firmware images, but of course you
   will need an SD card reader to do this. You should be able to find
   them at any electronics/photography/home entertainment store, and
   they are quite cheap.

   Ian.

   ------------------------------------------------------------------------

   *From:* Manav Seth [mailto:address@hidden
   <mailto:address@hidden>]
   *Sent:* Wednesday, 3 February 2010 10:54 AM
   *To:* Ian Holland

   *Cc:* address@hidden <mailto:address@hidden>;
   address@hidden <mailto:address@hidden>

   *Subject:* Re: [Discuss-gnuradio] Unable to tune Tx or Rx with
   XCVR2450 on USRP2

   Hi,


   The problem I guess is with the SD cards only. Even I was facing the
   same problem. But today I tried with an old SD card and it worked.
   I am not able to catch hold of a card reader and the one in my
   laptop is not working.

   manav

   On Tue, Feb 2, 2010 at 5:14 PM, Ian Holland

   <address@hidden <mailto:address@hidden>>

   wrote:

   Hi Josh

   Thanks for the advice. I tried the full range of low and high band
   frequencies, in increments of 10 MHz with 2 different XCVR2450 boards.
   This was done at least 4 times after power cycling for each card. I
   noticed the following:

   - For one of the XCVR cards, it repeatedly failed for all frequencies.
   - For the other card, it intermittently failed for frequencies at the
   lower and upper end of the low band, and at the higher end of the high
   band. I tried several values of N_DIV_MIN_Q16, and expect with a really
   large value (131 << 22), which seemed to fail for almost all
   frequencies, and also seemed to cause the USRP2 to "freeze up" a few
   times, I noticed negligible difference in the behaviour of this
   daughtercard.
   - For both XCVR2450s I noticed that sometimes after power cycling the
   USRP2 either froze when I tried to run my test, or it was unable to be
   found by my host PC in some cases.
   - I tried (131 << 16) (i.e. original) value for N_DIV_MIN_Q16 and also
   (131 << 19) on the card that failed for all frequencies, and that made
   no difference.

   I am not hugely concerned about the band-edge instability for the
   working card (although of course it would be nice to get to the bottom
   of that issue), but do you have any idea what could be wrong with the
   2nd card, that fails for all frequencies?

   Best Regards

   Ian.



   >Is it failing to lock at all different frequencies? and in the high
   band
   >and low band ranges? Do you have more than one XCVR board with this
   >problem?

   >It could be possible that for this board, and the frequencies you have
   >chosen, the N divider value teeters on the border or locking/not
   >locking. You may want to modify the usrp2 firmware code and build
   custom
   >image. The file to modify is
   >http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/
   lib/

   <http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/%0Alib/>>db_xcvr2450.c

   >Add some printfs to the xcvr2450_set_freq function and try to raise the

   >value of N_DIV_MIN_Q16 and see if you can get it to lock.

   >I hope that helps,
   >-Josh

   On 02/01/2010 06:08 PM, Ian Holland wrote:
   >  Thanks Josh
   >
   >  I can now confirm that it is definitely failing to lock. I have
   noticed
   >  on some rare occasions that it actually does lock. However, as soon as
   >  the USRP2 is power-cycled it goes back to the default behaviour of
   being
   >  unable to lock.
   >
   >  What can be done to make sure that it will lock? Is this likely to be
   a
   >  hardware issue specific to our daughtercards, or is there something
   else
   >  we can do in software to get around it?
   >
   >  Thanks
   >
   >  Ian.
   >
   > > It could be failing to lock. You may want to watch the debug port on
   >  the
   > > usrp2. If the lock detect is failing, it will print out on the serial
   > > console. attach a 3.3v level serial port
   >
   >  On 01/28/2010 10:09 PM, Ian Holland wrote:
   > > Hi Josh
   > >
   > >> The xcvr has a high band and a low band, which means there is a gap
   >  in
   > >> the tunable frequency range for the xcvr. Therefore, the
   > >> "auto-calculated mid-point frequency" is an invalid frequency for
   the
   > >> xcvr. Pick a frequency in the high band or low band range:
   > >
   > >> #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9)
   > >> #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9)
   > >> #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9)
   > >> #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9)
   > >
   > > Thanks - I will keep that in mind when using usrp_siggen.py in
   future.
   > >
   > > However, I have tried 2.4G with the source code from my original post
   > > (relevant code snippet for Tx tuning just below this paragraph, for
   > > which successTx is 0 and all frequency properties in TxTuneResult are
   > > 0), and also with usrp2_fft.py -f 2.4G, after burning the latest
   >  images.
   > > I still face the same problem that neither the Tx nor the Rx will
   >  tune.
   > >
   > > /* try tuning Tx to a test frequency */
   > > double Fc = 2400000000.0;
   > > usrp2::tune_result TxTuneResult;
   > > bool successTx = device->set_tx_center_freq(Fc,&TxTuneResult);


   _______________________________________________
   Discuss-gnuradio mailing list

   address@hidden <mailto:address@hidden>

   http://lists.gnu.org/mailman/listinfo/discuss-gnuradio




_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio