Re: [Discuss-gnuradio] Issue Installing GNU Radio From Source - Ubuntu 16.04
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 wanted to place this in the forum, because i did not like to install through Pybombs because of the addtional work of working with prefixes, and maybe this would help others. Kind regards. On Tue, Oct 9, 2018 at 12:24 PM Michael Dickens wrote: > 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 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 was through PyBombs. > > I appreciate all the help everyone has given me. > > Kind regards to all of you. > > > -- Eng. Luis Felipe Albarracin Msc. Telematics / MBA PMP CCNA/CCDA/CCNP/CCDP/CCIP ITIL v3 Foundation "Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt" ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issue Installing GNU Radio From Source - Ubuntu 16.04
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 > 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 was through PyBombs. > > I appreciate all the help everyone has given me. > > Kind regards to all of you. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] no uhd/osmocom blocks with 3.8?
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 just stay for now with 3.7 :) Thanks a lot, and with best regards Ralph. > Cheers, > > Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issue Installing GNU Radio From Source - Ubuntu 16.04
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 was through PyBombs. I appreciate all the help everyone has given me. Kind regards to all of you. On Mon, Oct 8, 2018 at 1:28 PM Michael Dickens wrote: > Hi Luis - The tag is probably "v3.7.14.3" (with the extra 'v' in front); > that's the way it looks like its listed on GitHub: < > https://github.com/gnuradio/gnuradio/tree/v3.7.13.4 >. Either way, this > script is outdated & PyBOMBS is a modern, kept-up-to-date way that's the > better alternative for Linux-y OSs if you want to install from source. - MLD > > On Mon, Oct 8, 2018, at 12:53 PM, Luis Felipe Albarracin Sanchez wrote: > > > Hello All, > > I tried the command: > > > $ wget http://www.sbrac.org/files/build-gnuradio && chmod a+x build-gnuradio > && ./build-gnuradio - gt 3.7.14.4 > > > But the following message apṕear: > > Ruta de submódulo «volk»: se extrajo > «3f3c91ee3ce51a31d8c23398124df74d3aa42955» > Mvolk > Branch maint set up to track remote branch maint from origin. > Switched to a new branch 'maint' > Could not fetch Gnu Radio tagged 3.7.14.4 from GIT > > I will try the procedure Neel wrote about and i will get back to you. > > Kind regards. > > > -- Eng. Luis Felipe Albarracin Msc. Telematics / MBA PMP CCNA/CCDA/CCNP/CCDP/CCIP ITIL v3 Foundation "Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt" ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] no uhd/osmocom blocks with 3.8?
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 issues, submit patches, port their OOT to 3.8, Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] no uhd/osmocom blocks with 3.8?
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 dependency - in those cases it is a matter of the project maintainers, and those who work on this need to consider the latest gnuradio release. Most of them are not important to me and just were installed for playing around -> no big deal, maybe time will heal this. However gnuradio 3.8 offers me no source/sink blocks to my SDR hardware anymore. I completely emptied /usr/locale/, reloaded the repositories and built and installed it all from scratch, with no remarkable errors, but still gnuradio-companion offers me no SDR source/sink blocks at all. Checking out maint-3.7 fixes this, all build and installs and becomes usable as before. I am not a coding guy, but this leaves me back somehow baffled, as in all the years I compile this stuff from sources I never had such issues. Cmake output of all those packages is normal, gnuradio builds all parts, none is left out, the SDR stuff builds the blocks normally, and the uhd and limesdr probe/test utils detect their SDRs just fine, so at this point I am done with my limited knowledge. Any ideas out there? Thanks a lot, and with best regards Ralph, dk5ras. -- Ralph A. Schmid Mondstr. 10 90762 Fürth +49-171-3631223 +49-911-21650056 ra...@schmid.xxx http://www.bclog.de/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio
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 that would be used to plot an FFT for instance. My display windows is only 1000 px high, so as long as the error is < 1e-3 in the end, I wouldn't even see the difference. And I recognize that for some other applications, it might matter, but I always found that when dealing with real time, real world signals, I often prefer fast over precise. (within reason obviously). Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio
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 log2 approx. should be improved to a point where the maximum normalized error is always less than 0.15. The current implementation produces large normalized errors for input values close to 1. ``` offset 98458 in1: -1.70264e-05 in2: -2.47955e-05 measured error was: 0.456301 tolerance was: 0.15 ``` Cheers Andrej On Mon, Oct 08, 2018 at 06:37:50PM +0200, Andrej Rode wrote: > Hi all, > > I just created an issue for that in the volk GitHub repository: > https://github.com/gnuradio/volk/issues/202 > > The normalized error seemed to be in the ~1e-8 range (errors in volk are > normalized to the amplitude of the result in question) > Thus it passes the default error threshold of 1e-6. > > Marcus pointed out offline that some of the intrinsics might even have a > better precision compared to the generic implementation. > > Cheers > Andrej > > On Wed, Oct 03, 2018 at 04:57:32PM -0700, Ron Economos wrote: > > It depends on which box I look at. > > > > 1) volk_32fc_x2_divide_32fc a_avx u_sse3 > > > > 2) volk_32fc_x2_divide_32fc a_avx u_avx > > > > Ron > > > > On 10/03/2018 08:05 AM, Müller, Marcus (CEL) wrote: > > > Well, I'd be willing to call that a bug, all in all: > > > > > > Though I totally get the "machine accuracy" argument, I'd at least > > > expect the same results when running the same program twice, on the > > > same machine. > > > > > > Now, I'm an author of one of the 32fc_x2_divide_32fc implementations; > > > I'd like to know what I can do to fix this. Ron, what was the machine > > > that volk_profile picked for you? > > > > > > By the way, just as for the float/char (and other ints) conversion > > > kernels, it's not inherently obvious who's right or wrong, the > > > optimized or the generic impl. So, we should be analyzing which values > > > led to the differing result. > > > > > > Best regards, > > > Marcus > > > > > > On Wed, 2018-10-03 at 06:52 -0700, Ron Economos wrote: > > >> That's the problem. If a set_output_multiple(4) in added to the > > >> constructor in divide_cc_impl.cc, it solves the issue. > > >> > > >> Ron > > >> > > >> On 10/03/2018 06:42 AM, Ron Economos wrote: > > >>> Well, I guess it's not really a bug. Most likely it has to do with the > > >>> accuracy difference between the x86 intrinsics and the C library. If > > >>> you look at the code in volk_32fc_x2_divide_32fc.h, the remaining > > >>> points that are not a multiple of four are calculated with the C > > >>> library. If the points from one run that are calculated with the C > > >>> library line up with points calculated with intrinsics in the next > > >>> run, there can be a mismatch. > > >>> > > >>> Ron > > >>> > > >>> On 10/03/2018 06:27 AM, Ron Economos wrote: > > It's a VOLK bug. Go into ~/.volk/volk_profile and change the > > volk_32fc_x2_divide_32fc line to generic. That fixes the issue here. > > > > Ron > > > > > > On 10/03/2018 05:46 AM, Piotr Krysik wrote: > > > Hi all, > > > > > > I simplified the flowgraph a bit and prepared a script that runs it > > > twice and compares the results. > > > > > > https://imgur.com/a/CSjOeLc > > > > > > In short something is wrong indeed. > > > Almost after every run of the script I get results with differences. > > > > > > I tested it on GNU Radio 3.7.12.0, I'm compiling the most fresh > > > version > > > now. > > > > > > Best Regards, > > > Piotr Krysik > > > > > > W dniu 03.10.2018 o 06:55, Reiichiro Nakano pisze: > > >> Here's an updated flowgraph where you don't need a separate file > > >> source. Just run the flowgraph twice for a few seconds each. You'll > > >> likely get different file sizes but `cmp` doesn't care, it'll still > > >> show the first differing byte which should still prove the bug > > >> exists. > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- > Andrej Rode > GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Andrej Rode GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA signature.asc Description: Digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
