Eric Blossom <[EMAIL PROTECTED]> 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". _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
