Dbid from usrp2

Hi list,

I’ve come across a strange bug: while the usrp correctly returns
dbid() == -1 when no dboard is connected to the side you chose, the
usrp2 returns dbid() == 1 (which is the id of BasicRX) when no dboard
is connected. I’ve checked that it correctly reports the dbid when
other types of daughterboards are connected.

I suspect that the reason is line 1082 in usrp2/host/lib/usrp2_impl.cc:
dst->dbid = ntohl(src->dbid);
which returns an unsigned long in the host byte order…

As a side note, another strange thing I noticed is that the frequency
range returned is always different (smaller) than the one in the spec
sheet. Why is that?

Thank you in advance

Dimitris S.
“If you think you’re too small to make a difference, try sleeping with
a mosquito!” - Amnesty International

Regarding the second question, I just found out that the freq_min and
freq_max values are hard-coded in the usrp/host/lib/legacy/db_xyz.cc
files, with wrong values, of course (the BasicRX reports a ±90 GHz
frequency range)… What’s up with that?

Dimitris S.
“If you think you’re too small to make a difference, try sleeping with
a mosquito!” - Amnesty International

On Tue, Aug 18, 2009 at 04:52:13PM +0200, Dimitris S. wrote:

Hi list,

I’ve come across a strange bug: while the usrp correctly returns
dbid() == -1 when no dboard is connected to the side you chose, the
usrp2 returns dbid() == 1 (which is the id of BasicRX) when no dboard
is connected. I’ve checked that it correctly reports the dbid when
other types of daughterboards are connected.

We really need a dbid that indicates “no board”.
Using 0xffff would probably make sense, but it was assigned years ago
to “Experimental”. I don’t think anybody’s using it, so we might be
able to assign “Experimental” a new value.

Eric

Ok, and what about the frequency ranges for the daughterboards?

Dimitris S.
“If you think you’re too small to make a difference, try sleeping with
a mosquito!” - Amnesty International

Regarding the frequency ranges, I have created ticket #405 and
attached a patch file that corrects these values. Could you please
review and tell me if it’s ok or if you want me to correct something?
Thank you

Dimitris S.
“If you think you’re too small to make a difference, try sleeping with
a mosquito!” - Amnesty International

As a side note, another strange thing I noticed is that the frequency
range returned is always different (smaller) than the one in the spec
sheet. Why is that?

An oversight. I’ll fix it.

Matt