Re: [Discuss-gnuradio] Building GNU Radio on Fedora 30 with pybomb to get a 3.8 installation
> On 1 Sep 2019, at 19:20, jean-michel.fri...@femto-st.fr wrote: > >> pybombs prefix init ~/gnuradio -R gnuradio-default > > gnuradio-default.lwr recipe is 3.7. Edit the recipe in > .pybombs/recipes/gr-recipes > and replace gnuradio with (in order to call gnuradio38.lwr) > depends: >- gnuradio38 > > and in gnuradio38.lwr > gitbranch: master -> gitrev: v3.8.0.0 > (since master is now 3.9) I made the changes above to .pybombs/recipes/gr-recipes/gnuradio38.lwr at line 47: source: git+https://github.com/gnuradio/gnuradio.git gitrev: v3.8.0.0 gitargs: --recursive I now get this error: $ pybombs prefix init ~/gnuradio -R gnuradio-default PyBOMBS.ConfigManager - INFO - Prefix Python version is: 3.7.4 PyBOMBS - INFO - PyBOMBS Version 2.3.3 PyBOMBS.prefix - WARNING - There already is a prefix in `/home/barry/gnuradio'. Continue using this path Y/[N]? y PyBOMBS.ConfigManager - INFO - Prefix Python version is: 3.7.4 PyBOMBS.ConfigManager - INFO - Prefix Python version is: 3.7.4 PyBOMBS.prefix - INFO - Installing default packages for prefix... PyBOMBS.prefix - INFO - - gnuradio38 PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and installing binary packages: Install tree: | \- gnuradio38 PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source packages to prefix: PyBOMBS.install_manager - INFO - Installing package: gnuradio38 fatal: No such remote or remote group: gnuradio38 PyBOMBS.Fetcher - ERROR - Unexpected error while fetching git+https://github.com/gnuradio/gnuradio.git. PyBOMBS.Fetcher - ERROR - Command '['git', 'remote', 'update', 'gnuradio38']' returned non-zero exit status 1. PyBOMBS.Packager.source - ERROR - Problem occurred while building package gnuradio38: Unable to fetch recipe gnuradio38 PyBOMBS.install_manager - ERROR - Error installing package gnuradio38. Aborting. Here are all the git repos I have in $HOME. $ find . -name '.git' ./.pybombs/recipes/gr-etcetera/.git ./.pybombs/recipes/gr-recipes/.git ./gnuradio/src/uhd/.git I do not see the git repo for gnuradio itself. On another machine I checked that the URL was correct. Also tried without the git+, same result. Is there a full log that has the exact commands issued and the complete output of those commands to review available? Barry > > JM > >> >> I am seeing failures. It seems that the build wants to use python2 packages >> which it did not install. I have been making progress by installing the >> missing packages. >> >> dnf install python2-lxml python2-numpy >> pip2 install --user mako >> pip3 install --user mako >> >> After that The build completed. But its a 3.7.13.5 build not the 3.8 I was >> hoping for. >> >> What is the recommended way to build gnu radio 3.8 in Fedora? >> (I see that its not package for Fedora yet, even in rawhide). >> >> Barry >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi Kevin, Thanks for the explanation, I think my flawed understading was due to the fact of having a file source with a throttle block, and seeing samples being dropped from buffers that did not match ASCII bytes lost at the file source but somewhere along the way. Is it correct to presume that in this case it is the throttle block that will be dropping the samples? Thanks, Adrian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi Adrian - If you use a file source with a throttle, then that section of your flowgraph will not drop samples. Using what Kevin wrote: The file source will "work" as fast as possible, so its output buffer will fill up quickly and any time samples are removed from it & so long as there is file data available the file source will keep the output buffer full -- and hence the throttle's input buffer will basically always be full. The throttle will pass every single sample through eventually, but at an average rate the matches its configuration. When presented with data in this fashion, the throttle will do a very good job of keeping the output sample rate close to that requested. Hence any dropped samples are happening downstream from the throttle. Hope this is useful! - MLD On Mon, Sep 2, 2019 at 6:10 AM Adrian Musceac wrote: > Hi Kevin, > > Thanks for the explanation, I think my flawed understading was due to > the fact of having a file source with a throttle block, and seeing > samples being dropped from buffers that did not match ASCII bytes lost > at the file source but somewhere along the way. Is it correct to > presume that in this case it is the throttle block that will be > dropping the samples? > > Thanks, > Adrian > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Michael Dickens, Mac OS X Programmer Ettus Research Technical Support Email: supp...@ettus.com Web: http://www.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ffast-math
Hi Albin, one of my students reported a little oddity about `-ffast-math`. Assume you want to set a float to -0, i.e. set the sign bit only. In this case `-ffast-math` seems to remove the sign bit. In VOLK this might be an issue with `_mm256_conjugate_ps` in `include/volk/volk_avx_intrinsics.h`. I didn't check for other potential error sources. Cheers Johannes Am 01.09.19 um 16:10 schrieb Albin Stigö: > Anyone has experience with the real world impact of using gcc > -ffast-math with SDR in general, and GNURadio/Volk in particular? > > > --Albin SM6WJM > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ffast-math
ffast-math disables signed zero by design I think... I'm particularly interested in problems of numeric stability and loss of dynamic range. --Albin On Mon, Sep 2, 2019, 15:27 Johannes Demel wrote: > Hi Albin, > > one of my students reported a little oddity about `-ffast-math`. Assume > you want to set a float to -0, i.e. set the sign bit only. In this case > `-ffast-math` seems to remove the sign bit. > > In VOLK this might be an issue with `_mm256_conjugate_ps` in > `include/volk/volk_avx_intrinsics.h`. I didn't check for other potential > error sources. > > Cheers > Johannes > > Am 01.09.19 um 16:10 schrieb Albin Stigö: > > Anyone has experience with the real world impact of using gcc > > -ffast-math with SDR in general, and GNURadio/Volk in particular? > > > > > > --Albin SM6WJM > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ffast-math
-ffast-math is allowed to reorder calculations, e.g. it can do a*f + b*f + c*f as (a+b+c)*f (or vice versa) which of course isn't necessarily the same result, and can lead to numerical instability. The problem is really that for some kernels, things like zero-signage and NaN / Inf handling / rounding / saturation are negligible, for others not. We've had plenty of fun with kernels where the SIMD implementation actually did the right thing, but the plain C implementation misbehaved, for example, because it didn't use the same FPU flags; I'd be kind of hesitant to add more "might or might not act as expected" code... Best regards, Marcus On Mon, 2019-09-02 at 16:52 +0200, Albin Stigö wrote: > ffast-math disables signed zero by design I think... > > I'm particularly interested in problems of numeric stability and loss of > dynamic range. > > > --Albin > > On Mon, Sep 2, 2019, 15:27 Johannes Demel wrote: > > Hi Albin, > > > > one of my students reported a little oddity about `-ffast-math`. Assume > > you want to set a float to -0, i.e. set the sign bit only. In this case > > `-ffast-math` seems to remove the sign bit. > > > > In VOLK this might be an issue with `_mm256_conjugate_ps` in > > `include/volk/volk_avx_intrinsics.h`. I didn't check for other potential > > error sources. > > > > Cheers > > Johannes > > > > Am 01.09.19 um 16:10 schrieb Albin Stigö: > > > Anyone has experience with the real world impact of using gcc > > > -ffast-math with SDR in general, and GNURadio/Volk in particular? > > > > > > > > > --Albin SM6WJM > > > > > > ___ > > > Discuss-gnuradio mailing list > > > Discuss-gnuradio@gnu.org > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
I second what Michael wrote, but I'd like to be more general: GNU Radio does NOT drop samples, anywhere. SDR or audio or similar analog/digital hardware might do that when buffers run over. There's a long-standing, and seemingly unfixable bug in the packet_encoder/decoder Python hier blocks that hence have been deprecated on 3.7 for as long as I remember and have been removed, that led to samples being dropped. If something like that happens anywhere but in sampling hardware, there's a fundamental bug and we'd like to know where exactly! Best regards, Marcus On Mon, 2019-09-02 at 13:09 +0300, Adrian Musceac wrote: > Hi Kevin, > > Thanks for the explanation, I think my flawed understading was due to > the fact of having a file source with a throttle block, and seeing > samples being dropped from buffers that did not match ASCII bytes lost > at the file source but somewhere along the way. Is it correct to > presume that in this case it is the throttle block that will be > dropping the samples? > > Thanks, > Adrian > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Thank you all for your comments. Marcus, I'd just like to say that I have been using the packet encoder/decoder for a long time (3-4 years) and could not see any issues that could be attributed to it. Regarding the dropped samples, is it the case that the buffers are continuously grown as the samples accumulate if a block cannot finish processing in time? My apparent dropped samples could have actually been a clock synchronization issue, I can try to reproduce it again to confirm. It is not a terribly important issue though. The FIR filter is too long for 1024 bits Gold codes and can't handle high sample rates. I hope that I will find a solution, currently investigating the core code of FFT filters to determine if a replacement can help. Thanks, Adrian On September 2, 2019 3:30:48 PM UTC, "Müller, Marcus (CEL)" wrote: >I second what Michael wrote, but I'd like to be more general: > >GNU Radio does NOT drop samples, anywhere. SDR or audio or similar >analog/digital hardware might do that when buffers run over. > >There's a long-standing, and seemingly unfixable bug in the >packet_encoder/decoder Python hier blocks that hence have been >deprecated on 3.7 for as long as I remember and have been removed, that >led to samples being dropped. If something like that happens anywhere >but in sampling hardware, there's a fundamental bug and we'd like to >know where exactly! > >Best regards, >Marcus > >On Mon, 2019-09-02 at 13:09 +0300, Adrian Musceac wrote: >> Hi Kevin, >> >> Thanks for the explanation, I think my flawed understading was due to >> the fact of having a file source with a throttle block, and seeing >> samples being dropped from buffers that did not match ASCII bytes >lost >> at the file source but somewhere along the way. Is it correct to >> presume that in this case it is the throttle block that will be >> dropping the samples? >> >> Thanks, >> Adrian >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building GNU Radio on Fedora 30 with pybomb to get a 3.8 installation
Hi Barry, On 02/09/2019 12.12, Barry Scott wrote: > > >> On 1 Sep 2019, at 19:20, jean-michel.fri...@femto-st.fr wrote: >> >>> pybombs prefix init ~/gnuradio -R gnuradio-default >> >> gnuradio-default.lwr recipe is 3.7. Edit the recipe in >> .pybombs/recipes/gr-recipes >> and replace gnuradio with (in order to call gnuradio38.lwr) >> depends: >>- gnuradio38 >> >> and in gnuradio38.lwr >> gitbranch: master -> gitrev: v3.8.0.0 >> (since master is now 3.9) > > I made the changes above to .pybombs/recipes/gr-recipes/gnuradio38.lwr at > line 47: > > source: git+https://github.com/gnuradio/gnuradio.git > gitrev: v3.8.0.0 The above line is incorrect, it should be "gitbranch: maint-3.8" https://github.com/gnuradio/gr-recipes/pull/155/files https://github.com/sbmueller/gr-recipes/commit/78158dcdbd5d609e884354ebc0ea54391f3e8fd1 Regards, Vasil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Examples of Python code using 'current_tags' function for Tag Debug block
The subject pretty-much says it all. I'm looking for a Python example of code that uses the 'current_tags' function for the Tag Debug block, and picks apart the resulting tag(s). In Python land are the tags just a tuple/list or a dictionary? I've snarfled through the generated SWIG code, and can't seem to decipher it. I'd expect perhaps a tuple: (offset, tag, value, srcid) With "tag", "value" and "srcid" all being PMTs. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
