USRP2 and DBSRX compatibility (?)

Hi,

did anybody manage to get this combination working together?
Some say on this list, you need an USRP1 for programming the DBSRX
and that programming on the USRP2 would not work.
The instructions on the website tell us, the USRP2 needs the special
burning firmware to make this upgrade. Really confusing.
We made already the hardware modifications, according to the
instructions.
We also tried before with the original shipped hardware, without
success.
But following the comments, it should be normal that it’s not compatible
without
the hardware modifications.

How can we test that the DBSRX is really working?

The usrp2_fft.py shows some noise, accepts frequency changes without
error, but on the watterfall I see no effect of frequency changes and no
signal
where it should be, just noise. After burning, we installed the current
firmware on the SD.
u2_rev3-20100603.bin and txrx_raw_eth_20100608.bin
with the OK message after burning and verifying. We are using the
current
trunk gnuradio code.

Or do we have to write special applications for the DBSRX to work?
Or does it only work with the UHD driver/firmware?

We spend a lot of money for this hardware, but it’s quite useless for us
without the DBSRX.
Other daughterboards are working fine. So I assume the firmware, the
mainboard
and our software installation is correct.

Moeller

On Aug 3, 2010, at 4:15 PM, Moeller wrote:

did anybody manage to get this combination working together?

Yes, after updating the EEPROM (using the USRP2 firmware) and moving the
resister, this combination is working fine for us.

OS: Ubuntu 10.04
GNU Radio: 3.0.3
FPGA: u2_rev3-20100603.bin
Firmware: txrx_raw_eth_20100608.bin
DBSRX EEPROM: burn_dbsrx_eeprom.bin dated July 14, 2010

-Marc

On Wed, Aug 04, 2010 at 02:05:18PM +0200, Moeller wrote:

Btw, the current git sources of gnuradio are defective too
with the current gcc 4.5.0 compiler. I had to change the sources.
I will provide a patch for that later.

Moeller

Looking forward to your patch. Basing it on the maint branch would be
most helpful to us. There may also be some changes in master and next
that will need attention, but we like to try to fix bugs in maint then
roll them forward into master and next.

Thanks!
Eric

On 03.08.2010 23:39, Marc E. wrote:

did anybody manage to get this combination working together?
Yes, after updating the EEPROM (using the USRP2 firmware) and moving the resister, this combination is working fine for us.

OS: Ubuntu 10.04
GNU Radio: 3.0.3
FPGA: u2_rev3-20100603.bin
Firmware: txrx_raw_eth_20100608.bin
DBSRX EEPROM: burn_dbsrx_eeprom.bin dated July 14, 2010

-Marc

Thanks for the motivation to try it again.
So I recompiled all with the current gnuradio git sources
(the 3.0.3 is not compatible with current gcc 4.5.0 compilers)
and did the burning again (with the same current fpga& burning
firmware).
And … wow, this time I get a result and the DBSRX is working.
I don’t know what was the reason for the previous failure.
The dboard-id changed from 2 to 13 (I don’t know what’s normal)
and now I receive all signals. Maybe the burning time was not long
enough?

Btw, the instructions are a bit incomplete. How long does it need for
programming?
Are there any indicators for success/completion?
My LED went all on, except E. But no change. It should be possible
to use an LED to indicate when the programming is finished.
And what dboard ID do I have to expect before and after burning?
So many unanswered questions. Is it so difficult to write a short
and complete documentation about this issue?
We didn’t receive the board for free, but paid real money for this.

And you should realize that the comments on this discuss-gnuradio-list
concerning the DBSRX are incorrect.
They say, the programming has to be done on an old USRP 1 and that
it does not work on an USRP 2. This is not correct. Maybe it was
for an old revision of the burning software.

Of course, the marketing brochure should be updated, too.
It took quite some time for me to realize, that the hardware was
not compatible without modification (because the other boards
were working fine). This is really frustrating for a gnuradio-beginner.
And it’s not easy to do this soldering work on a microscopic resistor.
You always have to fear to damage the board or that the microscopic
SMD resistor element is flying away (in fact it did, but I found it
again …).
I don’t understand, why this board is not sold in a compatible variant.

Btw, the current git sources of gnuradio are defective too
with the current gcc 4.5.0 compiler. I had to change the sources.
I will provide a patch for that later.

Moeller