On Fri, Jul 23, 2010 at 1:51 AM, Craig Tong <[email protected]> wrote: > This USRP has been here since before my time but the other guys in the lab > seem to think that it was bought directly from Ettus. It has the "Ettus > Research LLC" sticker on it with the "Ser" number and test date. > > As for the lsusb. It reports: > Bus 001 Device 007: ID fffe:0002 > > similar to lsusb for the working USRP.
That means the EEPROM is being read correctly. Try running "lsusb -v" and look for the line bcdDevice under the fffe:0002 section. You should be seeing 0.04, which means unconfigured (high byte) and rev4 (low byte). Thomas > Craig Tong > Radar Remote Sensing Group > University of Cape Town > > > On 22/07/2010 20:15, Thomas Tsou wrote: >> >> On Thu, Jul 22, 2010 at 4:35 AM, Craig Tong<[email protected]> >> wrote: >> >>> >>> Hi, >>> >>> Thanks for the help, I tracked through the functions that are used to >>> load >>> up the firmware and it turns out that this USRP is reporting its revision >>> number as 0. As such the path to the firmware is always invalid. I >>> managed >>> to get my hands on another USRP just now and it returns revision 4 so my >>> code seems to work correctly. >>> >>> Is this likely to be an EPROM corruption ? >>> >> >> That is likely. At usrp power-up, the USB controller reads the eeprom >> data, which is reported to the host as various identifiers. Either the >> data is somehow corrupt or not being read. >> >> What appears when you run lsusb on the command line? >> >> Thomas >> >> >>> >>> Craig Tong >>> Radar Remote Sensing Group >>> University of Cape Town >>> >>> >>> On 21/07/2010 19:15, Thomas Tsou wrote: >>> >>>> >>>> On Wed, Jul 21, 2010 at 1:36 AM, Craig Tong<[email protected]> >>>> wrote: >>>> >>>> >>>>> >>>>> Hi, >>>>> >>>>> I'm having some trouble getting my USRP board running with just about >>>>> any >>>>> software. It always seems to die with "Can't find firmware: std.ihx". >>>>> I've >>>>> tried a whole array of applications including usrp_fft.py and similar, >>>>> usrp_probe and then also the C++ progs (test_usrp_standard_rx and the >>>>> like). >>>>> >>>>> It dies with the same complaint when running the C++ software that >>>>> we're >>>>> busy writing. It fails on the line "usrp_standard_rx::make( ... )" >>>>> where >>>>> the >>>>> firmware file is specified. It is currently blank (i.e. default) but >>>>> even >>>>> if >>>>> the file is specified explicitly, it still claims that it cannot be >>>>> found. >>>>> From what I understand from what is going on in "usrp_prims_common.cc" >>>>> if >>>>> the user specifies a path it should override the default one. Exactly >>>>> how >>>>> it >>>>> formats this path I can't really keep track of and I think something is >>>>> going wrong there. >>>>> >>>>> >>>> >>>> Under typical installations the path is constructed with >>>> "/usr/local/share/usrp" appended with rev2 or rev4 and the filename. >>>> If environment variable USRP_PATH is set, then the revision and >>>> filename are appended to that path instead. Read permissions are also >>>> checked before the path is returned. >>>> >>>> As you already suspect, the problem is most likely something minor. >>>> Try printing out the path in the find_file() call to see what you're >>>> searching for. >>>> >>>> Thomas >>>> >>>> >>>> >>>>> >>>>> I had it working on Ubuntu 9.04 x86 but it stopped working when I >>>>> updated >>>>> to >>>>> 10.04. I tried reinstalling gnuradio 3.2 several times. And also tried >>>>> the >>>>> versions from synaptic but always came down with the same error. I've >>>>> since >>>>> wiped the system and installed Ubuntu 10.04 x86_64 with new 3.3.0 >>>>> version >>>>> of >>>>> gnuradio but the problem continues. >>>>> >>>>> I do have "usr/local/share/usrp/rev4/std.ihx" and all that goes with >>>>> it. >>>>> I >>>>> can also load the firmware with usrper and then put LED1 on and off so >>>>> the >>>>> USRP seems to be working correctly. >>>>> >>>>> I do get the feeling I'm missing something very obvious here because it >>>>> seems the last instances of this sort of problem date back to 2007. >>>>> Still >>>>> I >>>>> just can't put my finger on whats wrong. >>>>> >>>>> Any advice would be greatly appreciated. >>>>> >>>>> regards >>>>> Craig >>>>> >>>>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
