On Sun, May 07, 2006 at 05:50:48PM -0500, LRK wrote:
> On Sun, May 07, 2006 at 12:06:31PM -0400, Greg Troxel wrote:
> >
> > > It appears the attempts to read the USRP at more than 4 MB/s just
> > > lock and transfer no data.
> >
> > What system? Could you be more precise? On NetBSD one gets mis
On Monday 08 May 2006 01:18, LRK wrote:
> > A kernel driver could issue the multiple reads but it is a fair amount of
> > work to write one, and a bit of a waste if ugen could be extended instead
> > (hence benefiting other applications)
>
> Obviously it would be neat to extend ugen if the fixes we
On Sun, May 07, 2006 at 12:06:31PM -0400, Greg Troxel wrote:
>
> > It appears the attempts to read the USRP at more than 4 MB/s just
> > lock and transfer no data.
>
> What system? Could you be more precise? On NetBSD one gets missing
> data according to the test program (presumably due to over
LRK <[EMAIL PROTECTED]> writes:
> Obviously it would be neat to extend ugen if the fixes were generic
> but if there need to be USRP-specific fixes they would best be done
> in a different module.
Agreed in genearl, but not that any USRP-specific changes are needed.
> Maybe I'm not understanding
On Sun, May 07, 2006 at 12:29:15PM +0930, Daniel O'Connor wrote:
> On Saturday 06 May 2006 23:35, LRK wrote:
> > I would like to run GR under FreeBSD so I am looking forward to your
> > progress on this.
> >
> >
> > Under FreeBSD (and probably NetBSD) the ugen(4) device is generic and gets
> > assi
On Saturday 06 May 2006 23:35, LRK wrote:
> I would like to run GR under FreeBSD so I am looking forward to your
> progress on this.
>
>
> Under FreeBSD (and probably NetBSD) the ugen(4) device is generic and gets
> assigned to any unknown device. I would suggest you look into getting a
> number as
On Wed, May 03, 2006 at 02:00:23PM -0400, Greg Troxel wrote:
>
> At BBN we are working on a project involving teams of
> cognitively-controlled software radios, funded by the US government.
> As part of this, we will be using GNU Radio on NetBSD. Due to the
> current implementation of ugen(4) (gen
On Saturday 06 May 2006 03:19, Greg Troxel wrote:
> > I don't know how widely supported it is - in FreeBSD it's optional (via a
> > kernel option or KLD).
>
> This seems to be a POSIX 1003.2 feature. It doesn't exist in NetBSD.
OK, a pity.
> This is essentially what the Linux USB driver does, bu
"Daniel O'Connor" <[EMAIL PROTECTED]> writes:
> On Thursday 04 May 2006 11:58, Daniel O'Connor wrote:
>> It would be nice if you could do a readv() and then
>> poll/kqueue/select/signal to see when an iovec has been filled, however I
>> suspect that would require severe modification of the kernel
On Thursday 04 May 2006 11:58, Daniel O'Connor wrote:
> It would be nice if you could do a readv() and then
> poll/kqueue/select/signal to see when an iovec has been filled, however I
> suspect that would require severe modification of the kernel internals.
Ah now I think about it, this is called
On Thursday 04 May 2006 03:30, Greg Troxel wrote:
> Joanne has written a proposal to modify NetBSD's ugen(4) to get good
> performance for the USRP. We'd like feedback about the technical
> approach. (Once we have it working, the changes will be commited to
> NetBSD-current.)
>
> http://acert.ir.
At BBN we are working on a project involving teams of
cognitively-controlled software radios, funded by the US government.
As part of this, we will be using GNU Radio on NetBSD. Due to the
current implementation of ugen(4) (generic USB devices), reads from
the USRP are not pipelined and transfer r
12 matches
Mail list logo
