Re: [Discuss-gnuradio] Re: About EEPROM and FX2(68013a) USB interface in USRP

[Marcus D. Leech]

On 04/13/2010 07:09 PM, Jason Uher 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(tm).


These are exciting times in the SDR world, I believe.


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