Re: [Discuss-gnuradio] updated packet format on USRP inband signaling

[Greg Troxel]

Eric Blossom <address@hidden> writes:

> Sure.  It's a common operation now.  We often run an fft in one
> process and some kind of transmitter in another.  Somebody's got to
> handle the dumuxing of command replies.  Using your UDP example, we'd
> have the source port of the request to route the reply.  That still
> leaves the flags such as Overrun, Underrun, etc., which I was thinking
> were only going to get reported once, and then cleared.  (I didn't see
> a good reason for forcing the host to explicitly clear the flag.)

I envision some number of data streams to/from the USRP, each with
it's own destination on the host.  They then could each have
over/underrun flags.

If it's mainly about tx vs rx, or separate data streams, then that's
something that could be muxed on udp port.

This likely requires a lot more thought.

> On Tue, Feb 27, 2007 at 11:28:26AM -0500, Greg Troxel wrote:
>
>> It may make sense to define a TCP or SCTP method, but then again it
>> may not - this is perhipheral attachment.
>
> I'd hate to try to stuff either of those in an inexpensive FPGA.  Of
> course if somebody wanted those, they could stick some kind of single
> board computer next to the USRPng and have it run TCP or SCTP or
> whatever.

Sure - I was thinking the same thing.  The requirements document
probably should say "local bus attachment".