On 04/13/2010 07:09 PM, Jason U. wrote:
This seems like it can only cause problems down the line. Wouldn’t it
be better from a development point of view to keep your device as a
separate VID/PID that is unique to you and simply abstract/link the
existing USRP functions into your source/sink pair?
A couple of comments. Yup, a separate VID/PID (although doesn’t Ettus
use
a VID assigned to the FSF, in order to avoid large fees paid to the
USB
consortium or something? ) would be a good idea.
If the device really does, more, or less, look like a USRP, then the
right thing
to do is to have a table in the USRP code (there probably already is)
that
looks for the various VID/PID that could be a USRP-type device, and
“do the right thing” (configuring itself for vendor-a whizzy feature,
etc).
What I’d like to see is cooperation on these sorts of things from the
various
vendors in the new “eco-system” that Matt has unwittingly created
here.
Creating some kind of cooperative standard for how the USB and GiGE
interfaces
work (with provision for vendor-specific-whizzy-stuff) will make
everybodies lives
easier. It will be an ecosystem, rather than a bunch of independent
bunkered
silos.
This way, at a minimum, if the USRP code were changed someway that
broke your fpga implementation, the graph would fail gracefully, as
opposed to the host just happily sending samples along while your
device does nothing. Not to mention this would give you the ability
to extend the functionality of the source/sink pair to take advantage
of anything your board happens to do better than the USRP. From your
website it seems that you support a wider bandwidth and frequency
range than the USRP, why limit your board?
I haven’t looked at the wire protocol for either the USB or 1GiGE side
of things,
but it wouldn’t surprise me if the wire protocols were fairly agnostic
about
things like bandwidth. I mean the protocols already have to support
notions
of “capabilities” with all the new daughter-cards out there.
Which brings up an interesting question. Is the “capabilities database”
on the cards,
or in the driver code, or in the FPGA code, or what? Is it rather a
mix?
I like this to other “classes” of USB devices, like USB Audio, where
there is a “base”
protocol and expected device behaviour, and custom variants for
operating outside
the base functionality.
No reason not to do something similar here, both for USB and 1GiGE, and
whatever else
comes along in the future.
Despite that fact that (full disclosure) I derive a small part of my
income through Ettus, I’m thrilled
to see a USRP{1,2}-based “ecosystem” developing out there. It’s
healthy for everybody. Not
just in the traditional “competition is good business” sense, but
because it causes better, more
mature growth. Applications can run on different hardware without
being re-written, new hardware
can instantly take advantage of existing applications. It’s just a
Good Thing™.
These are exciting times in the SDR world, I believe.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
