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 <ian.holl...@rlmgroup.com.au>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:smartyma...@gmail.com] > *Sent:* Wednesday, 3 February 2010 10:54 AM > *To:* Ian Holland > *Cc:* j...@ettus.com; discuss-gnuradio@gnu.org > > *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 <ian.holl...@rlmgroup.com.au> > 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 > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
