You'll have to rebuild them. All the block names have changed from
dvbt2_xxx to dtv_dvb_xxx (for blocks that are common to both DVB-T2 and
DVB-S2) or dtv_dvbt2_xxx.
However, there are new versions of vv003-cr23.grc, vv009-4kfft.grc and
vv018-miso.grc in gnuradio/gr-dtv/examples that you can
Hi,
Maybe a dumb question, but up to now I was using gr-dvbt2 downloaded as
source, compiled and installed. Now gnuradio brings this stuff by default.
So I wonder what may happen when I remove the duplicate blocks from the
gr-dvbt2 package with a make uninstall. Will my grc files still be
OK, tnx, no big deal, just good to know beforehand :)
Ralph.
-Original Message-
From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Ron Economos
Sent: Monday, May 11, 2015 10:44 AM
To:
On Tue, Apr 28, 2015 at 8:50 AM, ruben.m...@swisscom.com wrote:
Hello,
I've been looking into the design details of the control-loop block. I
stumbled upon the blog post of Tom (
http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html with
the derivation
On 09.05.2015 15:47, Michal Vaclík wrote:
Doesn't seem so - by connecting scope to DETECT port on SC block I can
see only randomly timed peeks as opposed to running with channel model
where the peeks happen at fixed time periods.
Detection seems to get better with higher sample rates.
This
On Mon, May 11, 2015 at 12:00 PM, Richard Bell richard.be...@gmail.com
wrote:
From what I remember, there shouldn't be a functional difference. The
difference is the amount of feedback delay in the loop. You always need to
make sure one delay exists in any feedback path you can take, to avoid
Date: Sun, 10 May 2015 17:18:58 -0400
From: Marcus D. Leech mle...@ripnet.com
You could try a simple experiment that tests your disk subsystem write
performance without SDR stuff at all. Something like:
time dd if=/dev/zero of=some-file-on-your-disk bs=200 count=15000
This should write a 30GB
But if you get hackrf libs through Ubuntu's package manager, do so
before building anything related to HackRF (i.e. before running pybombs,
especially before installing gr-osmosdr); The problem is that a program
links against a specific ABI of a library -- in general, against
*exactly* the same
You can also get hackrf libs through Ubuntu's package manager.
Whatever install method you choose it is best to avoid deleting installed
libraries unless you really know what you are doing.
-Nathan
On Mon, May 11, 2015 at 12:37 PM, Martin Braun martin.br...@ettus.com
wrote:
Safest for GNU
From what I remember, there shouldn't be a functional difference. The
difference is the amount of feedback delay in the loop. You always need to make
sure one delay exists in any feedback path you can take, to avoid race
conditions. After that, you want to minimize the loop delay. The one
Hi all,
I couldn't solve my problems so I decided to reinstall Ubuntu 14.04 LTS from
the beginning on my hp elitebook 8460p. What is the safest (highest probability
of working) way of installing gnuradio (and hackrf tools)?
I just need a simple installation. Pybombs, build script, package
Safest for GNU Radio is package manager. Can't speak for HackRF, but you
can always use PyBOMBS. If you install GNU Radio through apt-get, and
then HackRF through PyBOMBS, you might need to set GNU Radio as already
installed in PyBOMBS.
Cheers,
Martin
On 11.05.2015 10:35, Carl Olsson wrote:
Hi
12 matches
Mail list logo
