> Did you follow the suggestions for PYTHONPATH that are made at the end of the
> script output?
Yep:
cja@cja-laptop ~ $ echo $PYTHONPATH
/usr/local/lib/python2.7/dist-packages
Also:
cja@cja-laptop ~ $ echo $LD_LIBRARY_PATH
/usr/local/lib
> What happens if you:
>
> python -c "from gnuradio i
When run a python script file, as we know main function will be run first. We
send the class to a object "tb",for instance,we use tb.start or tb.run.but if
we want to stop a flawgraph and reconfiguration.we must use tb.stop with
tb.wait and then restart tb.when I use this ,the tb.wait() can not
On 23 June 2013 02:55, Josh Blum wrote:
> ...
> We have had issues with builds compling against installed headers. Try
> removing installed volk hdrs in /usr/include and /usr/local/include first.
No volk headers anywhere in /usr/include. I removed the volk
directory from /usr/local/include and r
On 06/23/2013 03:32 AM, Chris Adie wrote:
Did you follow the suggestions for PYTHONPATH that are made at the end of the
script output?
Yep:
cja@cja-laptop ~ $ echo $PYTHONPATH
/usr/local/lib/python2.7/dist-packages
Also:
cja@cja-laptop ~ $ echo $LD_LIBRARY_PATH
/usr/local/lib
What happens
Regardless of whether you use the stock FPGA design or a custom one to do raw
data capture you are going to run up against the basic limits of 1GB/s
i.e 1Gb/S = 125MB/S = 62.5M 16bit samples/S
The stock image is always going to want to send an I and Q channel, and has the
option of either 25MSa
On 06/23/2013 11:34 AM, Ian Buckley wrote:
Interesting project though, the USRP could definitely be a useful generalized
scientific data capture device.
-ian
I've used USRPs for radio astronomy for years, so, yeah :)
But I think with a customized image you could send 100Msps of
real-mode-o
At 8bits sure, no problem, 14bits and we are into real-time lossless data
compression…another somewhat hard but interesting project.
Unless the OP wants to only capture for short intervals, in which case I guess
you could capture to the 1M SRAM and read back data non-real time.
On Jun 23, 2013
On Thu, Jun 20, 2013 at 09:55:29PM -0500, Crypto.Troop wrote:
>
> I would like to stay with the latest GNURADIO simply to support my
> HackRf board, in which the HackRf gr-osmosdr library seems to only
> support the latest version. I tried with 3.6.5 and it failed to
> compile...
The gr-osmosdr re
> Regardless of whether you use the stock FPGA design or a custom one to do raw
> data capture you are going to run up against the basic limits of 1GB/s
> i.e 1Gb/S = 125MB/S = 62.5M 16bit samples/S
>
> The stock image is always going to want to send an I and Q channel, and has
> the option of
This fixed my "GUI issues" ... thanks a bunch for tracking down the
error and pushing a fix for it so quickly! I appreciate it.
On Sat, Jun 22, 2013 at 1:19 PM, Johnathan Corgan
wrote:
> On Fri, Jun 21, 2013 at 6:48 PM, Michael Dickens wrote:
>
>>
>> So fixing the init call as above with "attri
10 matches
Mail list logo