[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] usrp & ppc-linux
From: |
kilian |
Subject: |
Re: [Discuss-gnuradio] usrp & ppc-linux |
Date: |
Thu, 10 Feb 2005 20:54:17 -0500 |
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