[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work we

From: Greg Troxel
Subject: Re: [Discuss-gnuradio] proposed change to ugen to enable USRP to work well on NetBSD
Date: Sun, 07 May 2006 12:06:31 -0400
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (berkeley-unix)

LRK <address@hidden> 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 this but it looks to me like ugen just
> responds with a code saying it will take a device if no other driver
> wants it. A copy of ugen named usrp could respond only to being
> offered a USRP but the USRP should have a unique number assigned
> rather than the general one used now. If there was a driver unique
> to the USRP, it would not need to work with other USB devices, thus
> my suggesting that direction.

True, but then there's more forked code to maintain, which is a big

> It also seems that the USRP tx and rx paths normally use the same
> block size after each open. If that is right, the driver could
> simply use that block size until the stream is closed, reading ahead
> on rx and providing flow control on tx.

That'a s good point: write transactions need to be some speed,
controllable by the user.

> 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 overruns in the
on-USRP buffer because USB transactions don't happen fast enough).
But nothing else bad happens.

> Changing the 'read' in libusb to just return as though it had
> finished results in the 'test_usrp_standard_rx' giving similar
> results at all speeds including the pattern of overrun errors.

You mean if you change the code to just skip the reads?  I don't see
what you are trying to find out from this experiment.

>  The transfer rate calculated is very fast so the overrun error
> count seems to be a function of the USRP code rather than actual
> overruns.

I don't see how this follows.

        Greg Troxel <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]