Hi George, (Yes, I know you're waiting for me... More later on today)
On Mon, Mar 26, 2007 at 04:02:48PM -0400, George Nychis wrote: > So from what I understand, a daemon has been suggested for inband packet > encoding and decoding that is implemented as an m-block which can be > connected in a flow graph for the encoding/decoding and interfacing with > the USRP. Is this correct? Right, except for the flow graph part. There are three cases: (1) only a flow graph (the way it is today) (2) only mblocks (one of the future ways) (3) mblocks + flowgraphs (the other future way) In case (3), I'm thinking that we have a mblock class that knows how to embedded a flow graph (and all the machinery) within itself. This would include ways for mblock messages to get sent into the flow graph (similar to gr.message_source) and to convert the output of the flow graph into mblock messages (similar to gr.message_sink). The basic idea is that there is a small piece of code that knows about both abstractions and how to bridge between them. > The goal would be the only have 1 of these running, correct? That way only > one is interfacing with the USRP at a time. Yes. One daemon. > If this is true, what kind of IPC mechanism are we looking at? GNU Radio > is also compatible on Windows and if we want to keep compatibility we have > to be careful here. Probably shared memory and mutexes and/or condition variables. For systems where that doesn't work, then we serialize everything and push it through sockets. > I could start designing and laying this out. I think that's premature. I know that you are looking for something to get to work on. Please bear with me at least until tomorrow. I'm right now figuring out what needs to happen to have the mblock code be ready (at least ready enough), that we could have a real design discussion about the host side of the new USRP interface. Thanks! Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
