Hello all,
Yes Sir,
I am using now GNURadio version 3.7.13.4 and is working fine.
Just for the record, with Pybombs is very important when you create code
or new OOT modules to specify the path in the cmake comand, for example:
cmake ../ -DCMAKE_INSTALL_PREFIX=/home/user/prefix/
I just
Hi Luis - Thank you for the feedback. Just to be clear: PyBOMBS worked
& you now have some usable version of GNU Radio installed? - MLD
On Tue, Oct 9, 2018, at 10:05 AM, Luis Felipe Albarracin Sanchez wrote:> Hello
all,
>
> I have tried to install GNuRadio, the way Michael explaines to me with
Hi,
> Yes, 3.8 is not exactly all that usable at the moment.
...
> We're in the 3.8 early days (no 3.8 release yet AFAIK) and now that it's in
> master, people need to test, report issues, submit patches, port their OOT to
> 3.8,
OK, this is great to know, so I do not need to worry and
Hello all,
I have tried to install GNuRadio, the way Michael explaines to me with the
"v3.7.14.3" in the command, and it did not work also.
I have tried to install it the way Neel told me, and also it said that some
packages were missing, and it did not work.
The only way i could install it
Yes, 3.8 is not exactly all that usable at the moment.
UHD block are not properly/entirely built and won't work in GRC.
Osmocom source simply hasn't been ported to 3.8 yet AFAIK.
We're in the 3.8 early days (no 3.8 release yet AFAIK) and now that
it's in master, people need to test, report
Hi,
I am using gnuradio on Kubuntu 18.04, built from source, also uhd,
osmocom-sdr-stuff, limesdr etc. is built from sources.
Up to gnuradio 3.7 this was all fine, no problems, but with the update to
3.8 the problems began. First issue is that many projects simply do not
recognize 3.8 as valid
I'm starting to wonder if having different precision version of the
kernels wouldn't make sense ...
TBH most of the time I don't care that much about precision because my
input data is noisy and the 0.1 dB difference doesn't matter, I much
prefer to be _fast_.
Especially for something like log2
Another kernel with a lot of variying precision is the log2
implementation since it's currently a polynomial approximation with a
6-th degree polynomial.
The glibc implementation uses a 14-th degree polynomial to approximate
log2 which turns out to have a maximum error of 2**-58.45.
Probably the
