On Tue, Jan 3, 2012 at 17:02, Marcus D. Leech wrote:
> Wrt: wxPython--don't forget that the FFT display is *heavily* decimated in
> the typical case, arranging for the FFT to be called only as often
> as is required the maintain the desired display rate (a few Hz,
> typically). But maybe that'
On Mon, Jan 2, 2012 at 10:45 PM, Tom Rondeau wrote:
> On Mon, Jan 2, 2012 at 10:20 PM, Shalabh Jain wrote:
>
>> On Mon, Jan 2, 2012 at 7:41 PM, Tom Rondeau
>> wrote:
>>
>>> On Mon, Jan 2, 2012 at 7:34 PM, Shalabh Jain
>>> wrote:
>>>
Hello,
I am having a weird problem during the
On Tue, Jan 3, 2012 at 8:02 PM, Marcus D. Leech wrote:
>
>>
>> The uhd_fft.py uses the wxPython GUI interface, which does most of its
>> work in Python. Can you separate the symbols to see more specifically where
>> the processing is happening?
>>
>> Tom
>>
>> I asked for symbols when I did the
The uhd_fft.py uses the wxPython GUI interface, which does most of its
work in Python. Can you separate the symbols to see more specifically
where the processing is happening?
Tom
I asked for symbols when I did the opreport, but for libpython, it
didn't produce a by-symbol breakdown, which
On Tue, Jan 3, 2012 at 7:41 PM, Marcus D. Leech wrote:
> Decided this evening to grab some quick profile data for a uhd_fft.py,
> running at 50Msps from a USRP2.
>
> The kernel was occupied 41% of the time--no great surprise. Handling
> interrupts, doing the network stack "stuff".
>
> The next l
Decided this evening to grab some quick profile data for a uhd_fft.py,
running at 50Msps from a USRP2.
The kernel was occupied 41% of the time--no great surprise. Handling
interrupts, doing the network stack "stuff".
The next largest chunk was libc (memcpy_sse) 12.5%
Then uhd (convert_sc
Some of you at least.
There's been an expressed desire for better control over the latency of a
GNU Radio flowgraph. I've just checked in an update to the master (and
next) branch that gives you a bit of control over this. Now, when you call
tb.start() or tb.run(), these functions take a parameter
On Tue, Jan 03, 2012 at 01:34:43PM -0500, mle...@ripnet.com wrote:
>
> My experience with USB + VMware, through a Windows host system into
> a Ubuntu VM, is that USB behaviour is bizarre and unreliable during
> enumeration/reconnect.
>
> I have to deal with this every day as an
> Android devel
On Tue, 3 Jan 2012 11:15:14 -0700, Matt Mills wrote:
> On Tue,
Jan 3, 2012 at 10:36 AM, Ben Hilburn wrote:
>
>> But you should not
have to 'try it twice', unless something about your USB driver or OS is
broken.
>
> FYI I was seeing the "try it twice" behaviour consistently
with VMware; prob
On Tue, Jan 3, 2012 at 10:36 AM, Ben Hilburn wrote:
> But you should not have to 'try it twice', unless something about your USB
> driver or OS is broken.
>
FYI I was seeing the "try it twice" behaviour consistently with VMware;
probably because it has to reconnect the device to the VM.
>
> First, you need to always try it twice. If the code loads my USRP1 with
> firmware, it does not get found.
uhd_find_devices loads the firmware onto your device, at which point the
device re-enumerates and identifies. If the USB driver installed on your
system, or the OS itself, handles re-en
On Fri, Dec 23, 2011 at 5:17 PM, Marcus D. Leech wrote:
>>
>> Please do not get me wrong. I believe that the work from Ettus and the
>> contributors to GNU-Radio are revolutionary! The equipment with the
>> interface to GNU-Radio is not only priced at a level that is affordable to
>> many amateur
12 matches
Mail list logo
