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