Hi, On Thu, 2005-02-10 at 12:25, Eric Blossom wrote:
> > to it. After I found out that I had to upload the firmware first, using > > 'burn-usrp2-eeprom', I ran test_usrp0 and got the following output: > > First off do you have a rev0 or rev2 board? The rev0 board doesn't > have any daughterboards, just SMA connectors on the board. The rev2 > board has connectors for daughterboards and is 160 x 160 mm. > I have a rev2 board. The silk screen says Gnuradio rev3 btw. > If you used burn-usrp2-eeprom and you have a usrp0 board, you just > fried the board. In 99.9999% of the cases there is no reason to use > burn-usrp2-eeprom. Now I wonder why I did it. Right, the error message! This message talks about it: http://lists.gnu.org/archive/html/discuss-gnuradio/2005-01/msg00130.html >> TX d'board A: Invalid EEPROM contents >> TX d'board B: Invalid EEPROM contents >> >> You just need to run the script >> >> .../usrp/host/apps/burn-basic-eeprom >Correct. >> I couldn't find any documentation on what is stored in the EEPROMs? >The EEPROMs on the dboards basically store an identifier for the type of board, >and can store some DC offsets and the like. >> Also, there is a ./usrp/firmware/src/usrp2/burn-usrp2-eeprom script that >> writes to what appears to the be boot EEPROM on the USRP motherboard. >Yes, the EEPROM on the motherboard stores some USB info, and some very simple >code to put the board in a low power state when it powers up. It also blinks >one LED quickly. Once you start running anything on the USRP, a more complete >firmware (which is much bigger than the EEPROM would hold) is sent over the USB >bus. Well 'burn-usrp2-eeprom' doesn't resolve that when I run test_usrp_standard_rx, I hope I can ignore that for now though. (Can there be endianess issues? The Mac is big-endian.) When I run test_usrp_standard_tx I get # ./test_usrp_standard_tx TX d'board A: Invalid EEPROM contents TX d'board B: Invalid EEPROM contents tx_underrun ... xfered 5.37e+08 bytes in 22.5 seconds. 2.385e+07 bytes/sec. cpu time = 2.03 32768 underruns This is very nice, now I'm getting informed about underruns. The the CVS based test_usrp_standard_rx gives: # ./test_usrp_standard_rx RX d'board A: Invalid EEPROM contents RX d'board B: Invalid EEPROM contents rx_overrun ... xfered 1.34e+08 bytes in 4.44 seconds. 3.024e+07 bytes/sec. cpu time = 0.4289 noverruns = 41 I checked the Makefile: # cat ../../../usrp-0.7/Makefile |grep FUSB_TECH FUSB_TECH = linux FUSB_TECH_darwin_FALSE = FUSB_TECH_darwin_TRUE = # FUSB_TECH_generic_FALSE = FUSB_TECH_generic_TRUE = # FUSB_TECH_linux_FALSE = # FUSB_TECH_linux_TRUE = > Try test_usrp_standard_tx and test_usrp_standard_rx. > > With test_usrp_standard_tx mess around with the -I <interp> option to > control that data rate across the USB. The sample rate across the USB > on transmit is 128e6 / <interp>. The data rate in bytes/sec across > the USB is sample_rate * 4. You should see a sine wave out I & Q. > Well, not until I get a scope and/or an SMA cable. I guess I go and read up on some things until then. Regards, Kilian _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
