Re: [Discuss-gnuradio] usrp & ppc-linux

[kilian]

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