Re: Can't set center frequency of USRP2 w/DBSRX

The system is kind of working, but usrp2_fft.py reports Failed (or Invalid if there’s a typo) for every frequency we enter regardless

Hello!

we have a similar problem with the USRP2 and DBSRX.
The modifications are already done, from the instructions at
http://gnuradio.org/redmine/wiki/gnuradio/USRP2DBSRXModification
http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries

The SMD-resistor was moved (contacts and value were checked).
The Burn DBSRX EEPROM was programmed, togethers with the “Raw Ethernet”
FPGA image (rel-20100603). This all went fine, no error messages.
Later, the “Raw Ethernet, No WBX or XCVR” firmware was played back to
the SD card.

Now, we can communicate with the USRP2, in usrp2_fft.py we see a
spectrum,
with some lines. But changing the frequency has no effect on the
spectrum.
There is no “failed” warning in the bands at 800 MHz. It seems to
communicate.
But we receive no signal in the expected frequency. Just always the same
noise
with some fixed lines, regardless of the frequency setting.

Any idea what could be wrong?

All other daughter-boards work fine, except the DBSRX.

Moeller

p.s.
why do they sell USRP2-daughter-board-combinations at Ettus that are not
compatible?
There was no warning, that hardware-modifications were necessary.
The marketing brochure says, that the DBSRX is USRP2-compatible.

Hello,

I am having a similar problem as mentioned by Moeller in his message. I
have
made the required modifications to be USRP2 + DBSRX. All I see is a
noise
floor when I try usrp2_fft.py. I am inputting 2.165 GHz signal through
RF
In. Is there something that I am doing wrong? Do I need external Ref
clock?
How can I do the basic test of receiving the carrier signal and
displaying
it ?

Any help to this issue will be highly appreciated.

Thank you in advance.
Amee

Moeller wrote:

The system is kind of working, but usrp2_fft.py reports Failed (or Invalid
if there’s a typo) for every frequency we enter regardless
FPGA image (rel-20100603). This all went fine, no error messages.

The marketing brochure says, that the DBSRX is USRP2-compatible.


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://old.nabble.com/Can't-set-center-frequency-of-USRP2-w-DBSRX-tp29268093p29408488.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Call “usrp2_probe” to check if the board ID is 13 now. If it is still 2, the burning had no effect.
I tried two times without success (didn’t know that the ID would have to change).
After another 3rd attempt later, I was successful.
Very strange. Every time I followed the instructions exactly the same.

In Linux, I/O to “disk-like devices” uses write-behind caching. Which
means that although your application has sent the data to the
kernel, and it has been accepted, it may not actually get written out
to disk. This improves performance in many types of
interactive applications, but it has a side-effect that if you write
data to “disk-like” device, and then pull that hardware, the data
may not have been flushed out.

Using the “sync” command generally arranges for all pending writes to
disk-like devices to get flushed to the hardware, so I generally
do a “sync” before pulling the SD card. The script that does the
flashing should probably issue a “sync” when it’s done.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

On 11.08.2010 15:49, spaceyaeon wrote:

Hello,

I am having a similar problem as mentioned by Moeller in his message. I have
made the required modifications to be USRP2 + DBSRX. All I see is a noise
floor when I try usrp2_fft.py. I am inputting 2.165 GHz signal through RF
In. Is there something that I am doing wrong? Do I need external Ref clock?
How can I do the basic test of receiving the carrier signal and displaying
it ?

I completed the instructions on the Wiki.
There was no hint how to verify if the burning was correct or if the
hardware was destroyed
after modifying the board. I was very irritated by this.

Call “usrp2_probe” to check if the board ID is 13 now. If it is still 2,
the burning had no effect.
I tried two times without success (didn’t know that the ID would have to
change).
After another 3rd attempt later, I was successful.
Very strange. Every time I followed the instructions exactly the same.

On Wed, Aug 11, 2010 at 11:37 AM, Moeller [email protected] wrote:

Call “usrp2_probe” to check if the board ID is 13 now. If it is still 2, the burning had no effect.

Moeller has a very good tip here, we use different daughterboard id’s
to let the software know if the resistor modification has been
performed. So here is a list of things to try:

If you are using the raw-ethernet host code included with gnuradio 3.3
or earlier:

Testing the id number of your DBSRX on USRP2:

  1. Insert an SD Card which has been programmed with the raw ethernet
    (Raw Ethernet, No WBX or XCVR) txrx.bin and u2_rev3.bin firmwares.
    You can get the latest here:
    http://ettus-apps.sourcerepo.com/redmine/ettus/projects/public/wiki/U2binaries

  2. Apply power and you should see the “D” and “F” leds light up
    if not, your SD Card is incorrectly programmed, try 1 again

  3. Use the “find_usrps” command to ensure your USRP2 can be discovered.
    If you get permissions errors, make sure you are the root user or
    set the suid bit on
    usrp2_socket_opener as described here:
    http://gnuradio.org/redmine/wiki/1/USRP2UserFAQ#Can-the-USRP2-be-used-by-a-non-root-user

  4. Run the “usrp2_probe” command to list daughterboard information,
    for DBSRX these are the ids you care about:
    2 (0x02) = DBSRXs for USRP1, R193 populated, R194 unpopulated
    (factory default)
    13 (0x0D) = DBSRXs for USRP2, R193 unpopulated, R194 populated

If the ID you find is incorrect, you can change it using the following
procedure:

On USRP2, changing to ID 13 (0xD)

  1. Program an SD card with burn_dbsrx_eeprom.bin firmware and the raw
    ethernet fpga (u2_rev3.bin) and insert it in your USRP2

  2. Apply power and you should see all LEDs except “E” light up
    if not, your SD Card is incorrectly programmed, try 1 again

  3. Power-off and use the steps above to check that the id is now 13
    (0x0D)

On USRP1, changing the ID can be handled by installing the DBSRX on
Side A and using the following command:
/usrp/host/apps/burn-db-eeprom -f -A -t [dbsrx|dbsrx_clkmod]
Choose dbsrx for ID = 2 USRP1, choose dbsrx_clkmod for ID = 13
(0x0D) for USRP2

You can check the daughterboard IDs on a USRP1 using the usrp_probe
command

The good news is, the UHD works with USRP2 more like a USRP1 in this
regard, so daughterboard IDs can be changed via the host, no need for
changing SD cards. You can find out how to do the DBSRX modification
for USRP2 with UHD here:
http://www.ettus.com/uhd_docs/manual/html/dboards.html#daughterboard-modifications

And UHD offers the uhd_usrp_probe command to see what daughterboards
are installed and their ids.

Amee,

I know you have worked on this for a while now, I hope that helps
clear things up for you and please do let me know if you get it
working or which step above fails for you.

Thanks
Jason

On 12.08.2010 00:10, Jason A. wrote:

Testing the id number of your DBSRX on USRP2:
Thanks Jason, your diagnosis instructions are very clear now.
I thought it was more than just changing an ID number.
Can you add this to the official mod.-instructions on the gnuradio Wiki?
It would help people a lot, if their DBSRX is not working (like ours
before).

  1. Apply power and you should see all LEDs except “E” light up
    if not, your SD Card is incorrectly programmed, try 1 again
    This is new to me. I was wondering what LED pattern was normal during
    burning.

On 11.08.2010 23:11, Marcus D. Leech wrote:

In Linux, I/O to “disk-like devices” uses write-behind caching. Which
means that although your application has sent the data to the
kernel, and it has been accepted, it may not actually get written out
to disk. This improves performance in many types of
I was aware of this problem, but …
Using the “sync” command generally arranges for all pending writes to
disk-like devices to get flushed to the hardware, so I generally
do a “sync” before pulling the SD card. The script that does the
flashing should probably issue a “sync” when it’s done.
the SD-usrp2_card_burner had a 2-stage process: first writing the image,
second verifying if the SD-card was correctly written.
In usrp2_card_burner.py you fill find this line:
if platform.system() == ‘Linux’: command(‘sync’)
So, it should have been in sync after burning.
But it’s too late now, I can’t reconstruct all exactly any more.
At least the DBSRX is working now.
Moeller

Thanks a lot Jason, Marcus and Moeller for your support and guidance. My
USRP2 with the DBSRX daughter board is up and running :slight_smile:

Cheers,
Amee

Moeller wrote:

if not, your SD Card is incorrectly programmed, try 1 again

This is new to me. I was wondering what LED pattern was normal during
burning.


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://old.nabble.com/Can't-set-center-frequency-of-USRP2-w-DBSRX-tp29268093p29415491.html
Sent from the GnuRadio mailing list archive at Nabble.com.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs