Hello all,
I just measured the time the execution of uhd_rx_cfile.py
takes all together.
I used N=2, samp-rate=1M and the rest was left to the
default values.
In theory the taking of the samples should take T=N/B=20ms
but I had to discover that the whole process is taking
about 2s.
On 14/12/11 03:21 AM, Sebastian Döring wrote:
Hello all,
I just measured the time the execution of uhd_rx_cfile.py takes all
together.
I used N=2, samp-rate=1M and the rest was left to the default values.
In theory the taking of the samples should take T=N/B=20ms but I had
to discover
On Wed, 14 Dec 2011 07:36:38 -0500
Marcus D. Leech mle...@ripnet.com wrote:
On 14/12/11 03:21 AM, Sebastian Döring wrote:
Hello all,
I just measured the time the execution of
uhd_rx_cfile.py takes all
together.
I used N=2, samp-rate=1M and the rest was left to
the default values.
In
On 14/12/11 08:05 AM, Sebastian Döring wrote:
Thanks a lot. Code really looks like what I am looking for.
Concerning the machine+Python version combinations that cause seg
faults: Is there a known combination that works?
Seems like mine doesn't.
-Sebastian
Could you expand on that a bit,
Hi guys!
I have problems with writing a processing block in python. I looked at the
examples here
http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython but
when I try to create a new class that inherits gr.sync_block (or any other
from the example) I get this output:
Traceback
On 12/14/2011 08:07 AM, Urban Kuhar wrote:
Hi guys!
I have problems with writing a processing block in python. I looked at the
examples here
http://gnuradio.org/redmine/projects/gnuradio/wiki/WriteBlocksInPython but
when I try to create a new class that inherits gr.sync_block (or any
I have been looking more at the performance of the udh_cal_* routines to try
and understand the operation of my N210 and the SBX card. I found the cal
files that I had previously generated and moved them into a separate
directory to prevent the UHD driver from finding them. From the
Hi there,
I made some decent progress but refining the parameters for the
benchmark_tx.py and benchmark_rx.py without no errors. However, I can only
transmit but I could not receive anything at the receiver side. Could
somebody suggest what might be the problem? I tried to work it but still
could
On 12/14/2011 01:55 PM, Evan Merewether wrote:
I have been looking more at the performance of the udh_cal_* routines to try
and understand the operation of my N210 and the SBX card. I found the cal
files that I had previously generated and moved them into a separate
directory to prevent the
Hi there,
I made some decent progress but refining the parameters for the
benchmark_tx.py and benchmark_rx.py without no errors. However, I can
only transmit but I could not receive anything at the receiver side.
Could somebody suggest what might be the problem? I tried to work it
but still
On Wed, Dec 14, 2011 at 7:24 PM, Marcus D. Leech mle...@ripnet.com wrote:
Hi there,
I made some decent progress but refining the parameters for the
benchmark_tx.py and benchmark_rx.py without no errors. However, I can only
transmit but I could not receive anything at the receiver side.
On 14/12/11 09:41 PM, Tom Rondeau wrote:
Can someone put this in the FAQ page on gnuradio.org
http://gnuradio.org? It probably deserves a more detailed
explanation than a FAQ-level answer, but it'd be a start.
Tom
The fabled someone must have anticipated you:
We will be having our monthly call tomorrow. Same time and details as usual.
http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopersCalls
I'll try to post an agenda, but I don't have much right now. Mostly, we are
looking to planning what features we're looking for in the 3.6 release.
Hi,
Anyone here implemented freq/phase correction and symbol timing correction in
USRP's FPGA?
Recently I implemented Costas loop and Muller Mueller algorithm in RTL by
referring the gnuradio code. Now I'm testing it on FPGA. I can get correct
demodulated data(DQPSK) at initial few thousand
14 matches
Mail list logo
