Re: [Discuss-gnuradio] Physical layer for packet-based communication

[Krzysztof Kamieniecki]

Quoting Eric Blossom <address@hidden>:
> On Fri, Feb 04, 2005 at 08:27:50PM +1030, Berndt Josef Wulf wrote:
> > On Fri, 4 Feb 2005 12:48 pm, Eric Blossom wrote:
> > > Hi Meenal,
> > >
> > > As far as I can tell there are a couple of ways we can get there.  The
> > > most straight-forward is to use the tap/tun interface to create either
> > > a pseudo IP or ethernet port from user space.  The kernel and the rest
> > > of the networking stack is on one end, GNU Radio would be on the
> > > other.
> > >
> > > Click isn't a requirement, it's more of an example of how things could
> > > be made to work.  [And a source of examples of how to get packets in
> > > and out of the kernel from users space.]
> > 
> > Can this be done in a portable way as to ascertain portability with
> platforms 
> > other than Linux, e.g. by using POSIX compliant API's ?
> > 
> > Direct kernel hacks will not be easy to port.
> > 
> > cheerio Berndt
> 
> The tap/tun interface works under Linux, Solaris and FreeBSD.
> There are no posix API's that do this kind of thing.
> 
> http://vtun.sourceforge.net/tun/
> 
> Eric
> 

I may also need some sort of method to get asynchronous "packets" out of (and
possibly into) Gnuradio for my GPS application. An N channel GPS receiver has
to do framing on N asynchronous channels. Right now my thinking is that the
framing of the data (ephemeris, etc...) portion of the GPS signal will be done
in a GR block, so each correlator channel will output a sub-frame. Plus on a
regular basis the receiver has to simultaneously sample every correlators PLL's
and DLL's loop parameters for tracking information. The data and tracking
packets will be processed by an external application.

My other thought is to internally queue up and serialize the various
asynchronous packets, and send them out through a byte stream.