[Discuss-gnuradio] AMD HSA and digital signal processing
Hi all, Lately I came across something called HSA (Heterogeneous System Architecture) that is used in new AMD APU's (CPU's with integrated graphics processor). In general it enables CPU and GPU cores to share the same memory space. Exchange of data between them is therefore a matter of sending a pointer. Many times I've heard that bottleneck of data transfer between CPU and GPU is main obstacle for application of massive GPU's processing power for signal processing. HSA seems to be the solution. The idea is great but what surprises me is that although AMD processors with HSA are present for over two years I haven't heard of anyone using it. GNU Radio could potentially benefit from HSA. But have anyone on the list used it? If yes - what was your experience? P.S. I've sent the same e-mail few hours earlier but as of now it hasn't appeared on the list. I'm sorry in advance if the post is doubled. -- Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles
Hi all, I want to announce new GNU Radio related project prepared by me - Multi-rtl: https://github.com/ptrkrysik/multi-rtl It is a Gnu Radio block that combines multiple RTL-SDR receivers into one multi-channel receiver. Only hardware modification to RTL-SDR dongles required is connecting them to a common clock source (i.e. one of the dongles' oscillator as Juha Verinen showed once). Each channel can work on a different central frequency. Everyone who wants to know how it was achieved is invited to read my github page: https://ptrkrysik.github.io Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles
Hi Juha, It wouldn't be as simple as it was for me as a developer and as it (hopefully) is for the end user without your hardware mod. Can you say something more about the residual center frequency difference? Where might it come from? I prepared little test of coherency between the receivers (multi-rtl/examples/test_multirtl.m). Among all the figures that it shows there is a plot of relative phase offset of signals coming from the receivers. In fact I have seen linear phase change on that plot - that corresponds to some central frequency offset. If I know what is the source of this offset maybe I will be able to find some way to fix it in software. -- Piotr W dniu 25.05.2016 o 08:24, Juha Vierinen pisze: > This is awesome! I'll definitely try this out soon. I use one off > python scripts to find the sample offset and the small residual center > frequency difference. This simplifies the process significantly. > > This should make it much easier to implement a passive radar block, or > an interferometry block. > > juha > > On Tue, May 24, 2016 at 4:03 PM, Piotr Krysik <mailto:per...@o2.pl>> wrote: > > Hi all, > > I want to announce new GNU Radio related project prepared by me - > Multi-rtl: > https://github.com/ptrkrysik/multi-rtl > > It is a Gnu Radio block that combines multiple RTL-SDR receivers into > one multi-channel receiver. > > Only hardware modification to RTL-SDR dongles required is connecting > them to a common clock source (i.e. one of the dongles' oscillator as > Juha Verinen showed once). Each channel can work on a different > central > frequency. > > Everyone who wants to know how it was achieved is invited to read my > github page: > > https://ptrkrysik.github.io > > Best Regards, > Piotr Krysik > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto: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] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles
Hi Marcus, I don't know much about AirSpy. Does it use the same demodulator chip as current RTL-SDR dongles? And does it mean that change to low level part of rtlsdr driver might help to get rid of that frequency offset? -- Piotr W dniu 25.05.2016 o 16:35, mle...@ripnet.com pisze: > > There are a couple of issues with the rtlsdr driver used by gr-osmocom > in this regard: > > > > (A) The charge-pump loop current is too constrained for the higher > frequencies > > (B) The "dither" option appears to have a bias that causes a (small) > frequency offset. > > > > The driver that AirSpy uses fixes both of these, although without > "dither", the tuning granularity is worse. Not sure this matters. > > > > > > > > On 2016-05-25 09:28, Marcus Müller wrote: > >> That, or simply, the output clock VCO changes its reaction to the >> control voltage under certain circumstances (temperature, frequency) so >> much that the control loop loses the ability to reach stationary >> exactness (e.g. due to natural limits on the magnitude of the VCO >> voltage). These devices definitely were made with cost in mind – not >> with maximum reliability, and hence I can believe that for example with >> the Elonics E4000 tuner, the charge pump used to generate the VCO >> voltage simply might deteriorate with temperature. >> >> Cheers, >> Marcus >> >> On 25.05.2016 14:25, Sylvain Munaut wrote: >>> Hi, >>> of the drift remains a mistery (probably due to the implementation of the PLL, but I cannot understand why Phase Locked Loops would drift in Phase !). >>> If the phase comparator is digital ( i.e. a XOR ) and the input clock >>> is somewhat analog, the gate thresholds might vary depending on >>> temperature, thus shifting the cycle a bit. >>> >>> Just a thought. >>> >>> Cheers, >>> >>> Sylvain >>> >>> ___ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles
Juha, What type of demodulator did you have in the dongles used for the test? -- Piotr W dniu 25.05.2016 o 14:46, Juha Vierinen pisze: > In my testing, this phase rate difference seemed constant and I could > simply calibrate it out by looking at the phase rate term estimated > from the phase of the cross-correlated noise. The samples stay aligned > for hours, so the issue is caused by the tuner or the DDC. One theory > that I had was that the multi-rtl driver somehow sets up the dongles > differently, but I never got around to looking at the code. > > I think this was the script I used to figure out what the phase drift was: > https://github.com/jvierine/chirpsounder/blob/master/apps/passive_radar/rnoise.py > > Here's the IQ plot to prove that the cross correlated phase is stable > over 6000 seconds: > > http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html > > juha > > On Wed, May 25, 2016 at 12:14 PM, <mailto:jean-michel.fri...@femto-st.fr>> wrote: > > From our own experience with dual-dongle measurements, the phase drift > seems to be strongly related to R820T(2) temperature. We reduced > significantly > the phase drift by gluing a large heat sink common to both chips > on both > dongles, without completely removing this effect (we aim at > measurements lasting > multiple hours). At the moment the only option we could think of > (mail to this > mailing list dated 28 May 2015) is switching to a reference clock > to calibrate > for the phase difference between the local oscillators, but the > actual cause > of the drift remains a mistery (probably due to the implementation > of the PLL, > but I cannot understand why Phase Locked Loops would drift in > Phase !). > > JM > > > It wouldn't be as simple as it was for me as a developer and as it > > (hopefully) is for the end user without your hardware mod. > > > > Can you say something more about the residual center frequency > > difference? Where might it come from? I prepared little test of > > coherency between the receivers > (multi-rtl/examples/test_multirtl.m). > > Among all the figures that it shows there is a plot of relative > phase > > offset of signals coming from the receivers. In fact I have seen > linear > > phase change on that plot - that corresponds to some central > frequency > > offset. If I know what is the source of this offset maybe I will > be able > > to find some way to fix it in software. > > > > -- > > Piotr > > > > W dniu 25.05.2016 o 08:24, Juha Vierinen pisze: > > > This is awesome! I'll definitely try this out soon. I use one off > > > python scripts to find the sample offset and the small > residual center > > > frequency difference. This simplifies the process significantly. > > > > > > This should make it much easier to implement a passive radar > block, or > > > an interferometry block. > > > > > > juha > > > > > > On Tue, May 24, 2016 at 4:03 PM, Piotr Krysik <mailto:per...@o2.pl> > > > <mailto:per...@o2.pl <mailto:per...@o2.pl>>> wrote: > > > > > > Hi all, > > > > > > I want to announce new GNU Radio related project prepared > by me - > > > Multi-rtl: > > > https://github.com/ptrkrysik/multi-rtl > > > > > > It is a Gnu Radio block that combines multiple RTL-SDR > receivers into > > > one multi-channel receiver. > > > > > > Only hardware modification to RTL-SDR dongles required is > connecting > > > them to a common clock source (i.e. one of the dongles' > oscillator as > > > Juha Verinen showed once). Each channel can work on a > different > > > central > > > frequency. > > > > > > Everyone who wants to know how it was achieved is invited > to read my > > > github page: > > > > > > https://ptrkrysik.github.io > > > > > > Best Regards, > > > Piotr Krysik > > > > > > ___ > > > Discuss-gnuradio mailing list > > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > <mailto:Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > -- > JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de > l'Epitaphe, 25000 Besancon, France > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles
Is there some good candidate that can be asked to do that? When I search for rtlsdr driver the first page with actual source code is osmocom's site: sdr.osmocom.org/trac/wiki/rtl-sdr Maybe they have the maintainer who feels responsible for how this code works? I can try to correct this offset in software (especially if it doesn't change too often) but it doesn't seem as the optimal solution. Frequency offset estimation might not be perfect either. -- Piotr W dniu 25.05.2016 o 21:36, mle...@ripnet.com pisze: > > The AirSpy uses the R820T2 chip for the tuner, but a different > sampling/DSP "engine". > > Yes, making the charge-pump and "dither" mods will help with > phase-coherence. > > Somebody needs to "own" the rtlsdr driver, and merge in the last > couple of years of field experience and branching that has gone on > with it. > > > > > > > > On 2016-05-25 15:04, Piotr Krysik wrote: > >> Hi Marcus, >> >> I don't know much about AirSpy. >> >> Does it use the same demodulator chip as current RTL-SDR dongles? >> And does it mean that change to low level part of rtlsdr driver might >> help to get rid of that frequency offset? >> >> -- >> Piotr >> >> W dniu 25.05.2016 o 16:35, mle...@ripnet.com >> <mailto:mle...@ripnet.com> pisze: >>> >>> There are a couple of issues with the rtlsdr driver used by gr-osmocom >>> in this regard: >>> >>> >>> >>> (A) The charge-pump loop current is too constrained for the higher >>> frequencies >>> >>> (B) The "dither" option appears to have a bias that causes a (small) >>> frequency offset. >>> >>> >>> >>> The driver that AirSpy uses fixes both of these, although without >>> "dither", the tuning granularity is worse. Not sure this matters. >>> >>> >>> >>> >>> >>> >>> >>> On 2016-05-25 09:28, Marcus Müller wrote: >>> >>>> That, or simply, the output clock VCO changes its reaction to the >>>> control voltage under certain circumstances (temperature, frequency) so >>>> much that the control loop loses the ability to reach stationary >>>> exactness (e.g. due to natural limits on the magnitude of the VCO >>>> voltage). These devices definitely were made with cost in mind – not >>>> with maximum reliability, and hence I can believe that for example with >>>> the Elonics E4000 tuner, the charge pump used to generate the VCO >>>> voltage simply might deteriorate with temperature. >>>> >>>> Cheers, >>>> Marcus >>>> >>>> On 25.05.2016 14:25, Sylvain Munaut wrote: >>>>> Hi, >>>>> >>>>>> of the drift remains a mistery (probably due to the implementation >>>>>> of the PLL, >>>>>> but I cannot understand why Phase Locked Loops would drift in >>>>>> Phase !). >>>>> If the phase comparator is digital ( i.e. a XOR ) and the input clock >>>>> is somewhat analog, the gate thresholds might vary depending on >>>>> temperature, thus shifting the cycle a bit. >>>>> >>>>> Just a thought. >>>>> >>>>> Cheers, >>>>> >>>>> Sylvain >>>>> >>>>> ___ >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Extending a GNU Radio block with use of inheritance
Hi all, I want to extend a little general_work function of one of the blocks (fractional_resampler) in order to add processing of stream tags that will change parameters of the block instance (i.e. call function set_mu) at a moment marked by a stream tag. Probably the optimal solution in terms of code reuse would be to extend the block with use of inheritance. In this case general_work function of the base class would be called by general_work function of the derived class. However, I don't know how to do it. Inheriting from the class available in the installed header (fractional_resampler_cc.h) is not a good solution as it is an abstract class, so I would have to re-implement (copy) all of the blocks' functions. Is it possible to do what I want with use of inheritance? If yes - how to do it so I wouldn't have to copy the code? (Extending fractional_resampler_cc is just an example - there are more blocks that I would like to modify without having to copy all of the code). Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Extending a GNU Radio block with use of inheritance
W dniu 02.06.2016 o 10:46, Andrej Rode pisze: > Hello Piotr, > > > > Is it possible to do what I want with use of inheritance? If yes - > > how to do it so I wouldn't have to copy the code? > > If your extension of the block is a general enhancement someone else > could make use of. It is best to directly modify the general_work > function of the block and contribute back your results. > > If your extension is specialized for your use case take a look at > $(class)_impl. It should be possible to inherit from > fractional_resampler_impl and then reimplement or modify the functions > you want to extend. > > Maybe there is some other, even better way of achieving your goal I > don't know yet. > > Best Regards, > Andrej Hi Andrej, There are cases when my modifications could benefit others (on a side note: in my opinion what would benefit everyone would be ability to access setters of all of the blocks with use of stream tags and messages), but there are also cases when I want to add some modifications specific to my project and it doesn't make sense to even try to make these changes included in the GNU Radio. If I can inherit from *_impl classes - are you able to present how to do it? *_impl.h headers are not installed together with GNU Radio so I'm not able include them. And this is just a start - then I don't know how prepare CMake files so derived class is linked correctly, and how to prepare SWIG input file. If you are able to spare some time to describe it I would greatly appreciate that. Best Regards, Piotr ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Extending a GNU Radio block with use of inheritance
W dniu 02.06.2016 o 11:28, Andrej Rode pisze: > Hello Piotr, > >> If I can inherit from *_impl classes - are you able to present how to do >> it? *_impl.h headers are not installed together with GNU Radio so I'm >> not able include them. > If you want to modify basic blocks shipped with GNU Radio you should > install GNU radio sources. Depending on your distribution you could use > PyBOMBS to get reproducible GNU Radio builds with your modifications. > > And this is just a start - then I don't know how >> prepare CMake files so derived class is linked correctly, and how to >> prepare SWIG input file. If you are able to spare some time to describe >> it I would greatly appreciate that. > I don't know of your current experience with GNU Radio but it sounds > like you did not play around a lot with GNU Radio already. > For projects not relevant for the main GNU Radio tree there exists the > concept of Out-Of-Tree modules (OOT-Modules). With the tool gr_modtool > it is quite easy to get started with your own module/blocks. > > I myself did not modify/create inherited blocks from already existing > blocks in GNU Radio. The $(class)_impl method was just a suggestion to > get a hand on the general_work function of the class. Maybe someone else > will also comment on this issue on the mailing lists. As GNU Radio is > Free Software you can and should take a look at the sources yourself :). > > If you are new to GNU Radio best take a look at the Tutorials [0]. For > creating own modules especially the OOT-Guide is very useful [1]. > > Best Regards, > Andrej > > [0] http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials > [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules > > > Hi Andrej and all, I have some experience with OOT modules - I've developed two OOT projects (gr-gsm and Multi-RTL). And this is part of the problem - I've played a bit with GNU Radio, I'm familiar with portions of GNU Radio's source code, but I still don't know how to use inheritance to extend existing blocks (something that in a lot of cases would make perfect sense). I can modify GNU Radio source - but this way I will create a new version of GNU Radio (specific for needs of my project) that users of my projects will have to install. In comparison with that copying the signal processing block's code to my project in order to add few lines is a lot better option (in terms of amount of code that need to be maintained, distributed and installed). And the point is to make things easier not harder for everyone. If a GNU Radio's gurus tell me that copying the source code is the best option in this situation and I that shouldn't try to do that with use of inheritance, I'll be able to live with that answer :). P.S. please respond also to the mailing-list so others can benefit from your responses. Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Extending a GNU Radio block with use of inheritance
W dniu 02.06.2016 o 12:12, Sylvain Munaut pisze: > Hi, > >> but I still don't know how to use inheritance to extend >> existing blocks (something that in a lot of cases would make perfect sense). > You can't. > > The whole _impl coding pattern is specifically designed to hide the > internals to outsiders and as such, you just can't extend it from an > outside project. > > > Cheers, > > Sylvain > Thanks Sylvain, You saved me from going into this dead end and loosing time in the process. Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fractional resampler eats stream tags on changes on the "ratio" input
W dniu 01.10.2015 o 14:46, Piotr Krysik pisze: > W dniu 25.09.2015 o 23:23, Tom Rondeau pisze: > > > > Looking at the block, I was hoping it was as easy as putting a > set_relative_rate call in the set_resamp_rate to adjust how the tags > are being propagated. But it's not that simple. See Issue #846 > (http://gnuradio.org/redmine/issues/846) for details on the problem. > > Tom > > Hi, I'm writing to let everyone know that resampling blocks after changing the resampling rate in the run-time is still eating stream tags. This makes some designs impossible to implement currently. For example - it would be great if it was possible to implement a clock offset frequency correction like I have drawn on the attached image: -there are two blocks that do the correction: resampler and frequency shifting block, -they change their parameters (resamp_rate, frequency_shift) on stream tags, -there is a block that does clock frequency offset measurements that is connected at the end (putting it in different place is not practical in many circumstances), -these measurements are sent to frequency offset control block which turns them into control messages addressed for both resampler and frequency shifter, -msg to tag blocks adds a tag containing a control message to a stream, -the information about changes of settings of the resampler and rotator are interpreted also by the measurement block, that adjusts measurements based on this information. But currently it not possible to do this due to the issue with the resampling blocks. Did you Tom or anyone found the source of the problem? Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles
W dniu 25.06.2016 o 01:56, Marcus D. Leech pisze: > On 05/26/2016 04:09 AM, Piotr Krysik wrote: >> Is there some good candidate that can be asked to do that? When I search >> for rtlsdr driver the first page with actual source code is osmocom's >> site: >> >> sdr.osmocom.org/trac/wiki/rtl-sdr >> >> Maybe they have the maintainer who feels responsible for how this code >> works? >> I can try to correct this offset in software (especially if it doesn't >> change too often) but it doesn't seem as the optimal solution. Frequency >> offset estimation might not be perfect either. >> >> -- >> Piotr > Peter East has been playing with stuff as well, although his website > has been suffering from the "Slashdot Effect(tm)" since RTL-SDR blog > pointed to his paper a couple of days ago. Now, he does all his > stuff post-facto, rather than in real-time, but i don't see why there > couldn't be two stages of 'sync' state in your code--one to do time > synchronization, the other to do frequency-offset estimation based on > the phase of the cross-correlation after time sync.The residual > frequency offset (which shows up as a phase walk) is, according to > Peter, always some small multiple of about 0.072Hz--he measures the > slope of the cross-correlation a few thousand samples apart, and > uses that to estimate the frequency offset. That works well. > > Ideally, yes, you just want the hardware to behave correctly--and for > the standard drivers to take care of this. But doing this in your > multi-rtl block isn't a lot of extra work, and it means you get no > residual phase-walk whether dither is turned on or off. > Hi Marcus, If it is possible to do estimate this frequency offset correctly (better than one would expect from normal measurement thanks to some a-priori knowledge like ~0.072Hz granularity that as you said might be there) - I can live with additional step. What might be possibly harder for me to swallow is if the estimated value of frequency offset has some error that may be avoided if one patches rtl-sdr driver to include the changes mentioned by you before. Thanks for pointing to Peter's East work - I will try to experiment with it. Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles
W dniu 28.06.2016 o 03:31, Marcus D. Leech pisze: > On 06/25/2016 04:25 PM, Piotr Krysik wrote: >> W dniu 25.06.2016 o 01:56, Marcus D. Leech pisze: >>> On 05/26/2016 04:09 AM, Piotr Krysik wrote: >>>> Is there some good candidate that can be asked to do that? When I >>>> search >>>> for rtlsdr driver the first page with actual source code is osmocom's >>>> site: >>>> >>>> sdr.osmocom.org/trac/wiki/rtl-sdr >>>> >>>> Maybe they have the maintainer who feels responsible for how this code >>>> works? >>>> I can try to correct this offset in software (especially if it doesn't >>>> change too often) but it doesn't seem as the optimal solution. >>>> Frequency >>>> offset estimation might not be perfect either. >>>> >>>> -- >>>> Piotr >>> Peter East has been playing with stuff as well, although his website >>> has been suffering from the "Slashdot Effect(tm)" since RTL-SDR blog >>>pointed to his paper a couple of days ago. Now, he does all his >>> stuff post-facto, rather than in real-time, but i don't see why there >>>couldn't be two stages of 'sync' state in your code--one to do time >>> synchronization, the other to do frequency-offset estimation based on >>>the phase of the cross-correlation after time sync.The residual >>> frequency offset (which shows up as a phase walk) is, according to >>>Peter, always some small multiple of about 0.072Hz--he measures the >>> slope of the cross-correlation a few thousand samples apart, and >>>uses that to estimate the frequency offset. That works well. >>> >>> Ideally, yes, you just want the hardware to behave correctly--and for >>> the standard drivers to take care of this. But doing this in your >>>multi-rtl block isn't a lot of extra work, and it means you get no >>> residual phase-walk whether dither is turned on or off. >>> >> Hi Marcus, >> >> If it is possible to do estimate this frequency offset correctly (better >> than one would expect from normal measurement thanks to some a-priori >> knowledge like ~0.072Hz granularity that as you said might be there) - I >> can live with additional step. What might be possibly harder for me to >> swallow is if the estimated value of frequency offset has some error >> that may be avoided if one patches rtl-sdr driver to include the changes >> mentioned by you before. >> >> Thanks for pointing to Peter's East work - I will try to experiment >> with it. >> >> Best Regards, >> Piotr Krysik >> > OK, now I've got people excited about building phased arrays. > > I suspect that the existing block will get awkward to use after about > 8 inputs. I wonder if there's a re-org of the input parameters that > could make it less awkward? Like having the device args all in one > line, having a "General" and "RF Parameters" tab, etc. > > Hi Marcus, It's great to hear that there is interest in using the block. I can change how parameters are displayed but I don't have clear idea how to do this so the user experience with for a systems with 8+ inputs will be improved. I can separate RF options to another tab but it won't improve much - you will still have a very long list of parameters that you will have to scroll. I can do this - it is not any problem for me (actually I already did this after your post: https://github.com/ptrkrysik/multi-rtl/commit/dfda15b5332cafb7da9288707fc9c58be91370b6). But in my opinion if you want to have more than 8 inputs you can consider coding the flowgraph in Python. GRC might be cumbersome in itself when you have blocks with so many ports. Regarding the coherent operation - I have to play with the driver prepared by you. If it works fine - it is the way to go in my opinion. Some people might still need dithering (i.e. because they don't care about coherency but want to set the frequency more precisely). One solution for this might be some additional option in the gr-osmosdr block that turns on/off dithering. Or if frequencies for which dithering is used can be easily listed/computed - then dithering can be just not used when the user sets frequency that doesn't require it. Best Regards, Piotr ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles
W dniu 28.06.2016 o 12:25, Piotr Krysik pisze: > W dniu 28.06.2016 o 03:31, Marcus D. Leech pisze: >> On 06/25/2016 04:25 PM, Piotr Krysik wrote: >>> W dniu 25.06.2016 o 01:56, Marcus D. Leech pisze: >>>> On 05/26/2016 04:09 AM, Piotr Krysik wrote: >>>>> Is there some good candidate that can be asked to do that? When I >>>>> search >>>>> for rtlsdr driver the first page with actual source code is osmocom's >>>>> site: >>>>> >>>>> sdr.osmocom.org/trac/wiki/rtl-sdr >>>>> >>>>> Maybe they have the maintainer who feels responsible for how this code >>>>> works? >>>>> I can try to correct this offset in software (especially if it doesn't >>>>> change too often) but it doesn't seem as the optimal solution. >>>>> Frequency >>>>> offset estimation might not be perfect either. >>>>> >>>>> -- >>>>> Piotr >>>> Peter East has been playing with stuff as well, although his website >>>> has been suffering from the "Slashdot Effect(tm)" since RTL-SDR blog >>>>pointed to his paper a couple of days ago. Now, he does all his >>>> stuff post-facto, rather than in real-time, but i don't see why there >>>>couldn't be two stages of 'sync' state in your code--one to do time >>>> synchronization, the other to do frequency-offset estimation based on >>>>the phase of the cross-correlation after time sync.The residual >>>> frequency offset (which shows up as a phase walk) is, according to >>>>Peter, always some small multiple of about 0.072Hz--he measures the >>>> slope of the cross-correlation a few thousand samples apart, and >>>>uses that to estimate the frequency offset. That works well. >>>> >>>> Ideally, yes, you just want the hardware to behave correctly--and for >>>> the standard drivers to take care of this. But doing this in your >>>>multi-rtl block isn't a lot of extra work, and it means you get no >>>> residual phase-walk whether dither is turned on or off. >>>> >>> Hi Marcus, >>> >>> If it is possible to do estimate this frequency offset correctly (better >>> than one would expect from normal measurement thanks to some a-priori >>> knowledge like ~0.072Hz granularity that as you said might be there) - I >>> can live with additional step. What might be possibly harder for me to >>> swallow is if the estimated value of frequency offset has some error >>> that may be avoided if one patches rtl-sdr driver to include the changes >>> mentioned by you before. >>> >>> Thanks for pointing to Peter's East work - I will try to experiment >>> with it. >>> >>> Best Regards, >>> Piotr Krysik >>> >> OK, now I've got people excited about building phased arrays. >> >> I suspect that the existing block will get awkward to use after about >> 8 inputs. I wonder if there's a re-org of the input parameters that >> could make it less awkward? Like having the device args all in one >> line, having a "General" and "RF Parameters" tab, etc. >> >> > Hi Marcus, > > It's great to hear that there is interest in using the block. I can > change how parameters are displayed but I don't have clear idea how to > do this so the user experience with for a systems with 8+ inputs will be > improved. I can separate RF options to another tab but it won't improve > much - you will still have a very long list of parameters that you will > have to scroll. > > I can do this - it is not any problem for me (actually I already did > this after your post: > https://github.com/ptrkrysik/multi-rtl/commit/dfda15b5332cafb7da9288707fc9c58be91370b6). > But in my opinion if you want to have more than 8 inputs you can > consider coding the flowgraph in Python. GRC might be cumbersome in > itself when you have blocks with > so many ports. > > Regarding the coherent operation - I have to play with the driver > prepared by you. If it works fine - it is the way to go in my opinion. > Some people might still need dithering (i.e. because they don't care > about coherency but want to set the frequency more precisely). One > solution for this might be some additional option in the gr-osmosdr > block that turns on/off dithering. Or if frequencies for which dithering > is used can be easily listed/computed - then dithering can be just not > used when the user sets frequency that doesn't require it. > > Best Regards, > Piotr > By the way... do you have the driver source with added patches in some publicly accessible repository? Best Regards, Piotr ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fractional resampler eats stream tags on changes on the "ratio" input
W dniu 07.06.2016 o 13:30, Piotr Krysik pisze:
> W dniu 01.10.2015 o 14:46, Piotr Krysik pisze:
>> W dniu 25.09.2015 o 23:23, Tom Rondeau pisze:
>>
>>
>>
>> Looking at the block, I was hoping it was as easy as putting a
>> set_relative_rate call in the set_resamp_rate to adjust how the tags
>> are being propagated. But it's not that simple. See Issue #846
>> (http://gnuradio.org/redmine/issues/846) for details on the problem.
>>
>> Tom
>>
>>
> Hi,
>
> I'm writing to let everyone know that resampling blocks after changing
> the resampling rate in the run-time is still eating stream tags. This
> makes some designs impossible to implement currently.
>
> For example - it would be great if it was possible to implement a clock
> offset frequency correction like I have drawn on the attached image:
> -there are two blocks that do the correction: resampler and frequency
> shifting block,
> -they change their parameters (resamp_rate, frequency_shift) on stream tags,
> -there is a block that does clock frequency offset measurements that is
> connected at the end (putting it in different place is not practical in
> many circumstances),
> -these measurements are sent to frequency offset control block which
> turns them into control messages addressed for both resampler and
> frequency shifter,
> -msg to tag blocks adds a tag containing a control message to a stream,
> -the information about changes of settings of the resampler and rotator
> are interpreted also by the measurement block, that adjusts measurements
> based on this information.
>
> But currently it not possible to do this due to the issue with the
> resampling blocks.
>
> Did you Tom or anyone found the source of the problem?
>
>
Hi Tom and others,
I implemented fractional resampling block that can have resampling rate
changed.
When doing this I learned what is the source of the issue #846. The
mistake is following:
transformation of tag offset by resampling block that changes its
resample rate is not a linear function, so in this case you can't use
such simple linear conversion, like it is done in GNU Radio's runtime:
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/block_executor.cc#L143
However, transformation is linear from one resample rate change to
another. So if you know input and output sample number for which
resample rate was the same as for the moment when a tag came - you can
use this as reference point to compute the tag's offset at the output of
the resampling block.
My proposed solution: modification of tags offsets processing in
gnuradio runtime so it includes case when you have resampling blocks
with dynamically changing resample rate doesn't seem resonable. If would
complicate things too much because the runtime would have to track
resample rate changes inside of every block that can do that. Resampling
blocks that can have resample rate changed dynamically should implement
tags propagation themselves.
Current fractional resampler block doesn't do that and it is incorrect.
The input for dynamic resample rate control should be removed as it can
cause problems to the users OR users should be warned that if they use
this input they shouldn't expect tags to work correctly.
The block implemented by me is available here:
https://github.com/ptrkrysik/gr-gsm/blob/master/lib/misc_utils/controlled_fractional_resampler_cc_impl.cc
It uses a pmt pair ("set_resamp_ratio",value) tag to set resample ratio
precisely at the moment of tag occurrence.
It wasn't tested in all possible conditions yet, so I'm still a bit
cautious regarding it. But it presents how such a block can be
implemented and in tests performed by me it worked (it is also now used
to correct sample frequency offset in gr-gsm).
Best Regards,
Piotr Krysik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduler enhancement?
Hi all, It's a little bit off-topic but if someone will change the gr-osmosdr, it would be great to have other stream tags that we are used to see at the output UHD source. For example if the source prints on the output that there is some problem with transmission it would be great to add a stream tag at that moment. In Multi-RTL (https://github.com/ptrkrysik/multi-rtl/) currently any such event means that synchronization of channels is lost until user manually calls resynchronization. Because there is no way to detect samples loss resynchronization can't be called automatically. On the wish-list I have a MSG input for controlling the osmocom source, but this is off-topic even more. Best Regards, Piotr W dniu 20.07.2016 o 23:25, Marcus Müller pisze: > So, my takeaway from this is: > > * Tagging by the scheduler /before/ work is called doesn't make overly > much sense, because of the blocking wait that might happen before the > first sample is received > * Tagging by the block is kind of prone to inconsistencies in tag format > (though gr-uhd probably established a standard for this), and of course > would need modifcation of a lot of blocks > * If you need the precision, you must go for a device with hardware > timestamping, anyway > * Tagging by the scheduler /after/ the first work call returned means > that one could "count backwards" to the first sample, based on sampling > rate, but will of course be pretty rough, too > > All in all, I think having host-clock time stamping as part of the > hardware source block seems to more sensible way – there's already Ettus > Hardware handling (libusrp-era USRPs, IIRC) that does that for older > devices that don't have hardware timestamping. > > Actually, thinking about this: abusing ctrlport's callbacks, couldn't we > just let an "external" observer get notified when a work function > returns? That observer would ideally be the software cross-correlator > that syncs up your different hardware. > > Cheers, > > Marcus > > > On 19.07.2016 23:23, Marcus D. Leech wrote: >> On 07/19/2016 05:13 PM, Marcus Müller wrote: >>> Question arising: would you want the tag to contain the time when >>> general_work() was called, or rather the time of the first sample? Note >>> that sources should usually be designed to be blocking until there's >>> data available! That way, between entering general_work() and actually >>> having the first sample, a lot of time could pass. It might make a lot >>> more sense to let the block that knows the hardware handle tagging >>> itself, here. >>> >>> Cheers, >>> >>> Marcus >> The idea is to tag when the first samples come off the hardware. >> >> Indeed, if one had an N-channel "tag these when the samples show up" >> block, it would likely be useless, since the scheduler will have >> nicely arranged for all of the those channels to have something >> useful to do the first time it calls work(). >> >> >>> >>> On 19.07.2016 23:00, Marcus D. Leech wrote: On 07/19/2016 04:53 PM, Sylvain Munaut wrote: > I don't see why this has to be done by the scheduler, I'd do that in > the source, or even as a separate OOT that just inserts that tag. Doing it in the source means modifying each source to insert, but, maybe that's the right thing to do. > Cheers, > > Sylvain > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduler enhancement?
W dniu 22.07.2016 o 09:34, Sylvain Munaut pisze: > Hi, > >> It's a little bit off-topic but if someone will change the gr-osmosdr, >> it would be great to have other stream tags that we are used to see at >> the output UHD source. For example if the source prints on the output >> that there is some problem with transmission it would be great to add a >> stream tag at that moment. In Multi-RTL >> (https://github.com/ptrkrysik/multi-rtl/) currently any such event means >> that synchronization of channels is lost until user manually calls >> resynchronization. Because there is no way to detect samples loss >> resynchronization can't be called automatically. > rtl-sdr can't detect sample loss ... > > With USRP, the hw reports overflows to the host, but the rtl-sdr has > no such thing, it will drop sample silently if its internal buffers > overflow. > Here is some form of detection of overflows: http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc#n305 What you are saying means it doesn't detect 100% of overflows? Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduler enhancement?
Hi Marcus, Ok, it is therefore indication of problem with an overflow happening in rtl-sdr source block on the side of PC (there is no more free buffers to store incoming sample). I'm aware that with RTL-SDR's it is not possible (as far as anyone knows) to read how many samples were lost. But any communication error (on side of the device or on side of a PC) will cause synchronization loss in multiple RTL-SDR's that were synchronized beforehand. Knowing at least some communication errors will enable recovering from them - that means calling a function that will make RTL-SDR receivers to be synchronized again. Of course information that something went wrong with transmission on the side of the device would be much more valuable (overflows on the side of PC can be tackled by increasing number of buffers and speeding up processing). Best Regards, Piotr Krysik W dniu 22.07.2016 o 12:01, Marcus Müller pisze: > Hi Piotr, > > As far as I grok the gr-osmosdr rtl_souce, this is an overflow > indication purely based on the fact that in the rtl_source itself, the > number of the last used buffer is compared with the maximum number of > buffers that should be – and if that happens, that is an indication that > the software side noticed things ran over how much buffer there's > available. > > That's pretty different from the USRP approach: It is indeed a kind of > overflow indication, but it gives no chance whatsoever to recover, since > the rtl dongle isn't aware of it, and also has no means to actually time > stamp data. If things get really bad, and USB buffers get lost before > they even reach userland, librtl can't even notice, I think (the USB > bulk transfer packets are pretty much samples only, as far as I read > librtlsdr's librtlsdr.c in combination with rtl_source_c.cc), so there's > no timing/"original sample count" info available. USRPs actually keep > track of ACKs coming from the PC. > > Best regards, > Marcus > > On 22.07.2016 10:45, Piotr Krysik wrote: >> W dniu 22.07.2016 o 09:34, Sylvain Munaut pisze: >>> Hi, >>> >>>> It's a little bit off-topic but if someone will change the gr-osmosdr, >>>> it would be great to have other stream tags that we are used to see at >>>> the output UHD source. For example if the source prints on the output >>>> that there is some problem with transmission it would be great to add a >>>> stream tag at that moment. In Multi-RTL >>>> (https://github.com/ptrkrysik/multi-rtl/) currently any such event means >>>> that synchronization of channels is lost until user manually calls >>>> resynchronization. Because there is no way to detect samples loss >>>> resynchronization can't be called automatically. >>> rtl-sdr can't detect sample loss ... >>> >>> With USRP, the hw reports overflows to the host, but the rtl-sdr has >>> no such thing, it will drop sample silently if its internal buffers >>> overflow. >>> >> Here is some form of detection of overflows: >> >> http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc#n305 >> >> >> What you are saying means it doesn't detect 100% of overflows? >> >> >> Best Regards, >> >> Piotr Krysik >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About closing flowgraph automatically
Hi Simone and all, Can you provide your GRC flow-graph? I think that source of the problem might be somewhere in this part "PMT MESSAGE TO FILE SOURCE" as there is message to samples stream conversion involved here. But it's not clear for me what it actually is as you described it. I have problems with automatic closing of a flow-graph that uses a block that converts messages to samples. In my case it is PDU to Tagged Stream block that caused problems with automatic exiting of the flow-graph. The constant problems with exiting of flow-graphs lead me to think if these problems can be solved once for all with some change in gnuradio's internals. Maybe it can be some "exit" tag that would be propagated to all blocks in a flowgraph. This tag would be processed by all blocks and would cause them to be marked as ready for the program exit. Blocks that have stream inputs and message outputs would convert the tag to an "exit" message, which would be propagated through the outputs. Blocks with message inputs ans stream outputs would convert "exit" message to an "exit" tag. When all blocks would be marked as ready for closing the program would end. In this concept there is problem how to propagate the information to blocks upstream, that might not have information about ending of a flow-graph. So the method I described might be used as an addition to current method of ending flowgraphs. What do you think? Best Regards, Piotr Krysik W dniu 22.07.2016 o 18:40, Martin Braun pisze: > Simone, > > a file source *will* terminate the flow graph once its read the file > (unless you specify 'repeat'). > > M > > On 07/21/2016 12:32 AM, Simone Ciccia S210664 wrote: >> Goodmorning, >> I would like to Know some methods to Close flowgraph automatically when >> it has finished. Some example, stop when USRP has no more samples to >> transmits, or a file source has read until EOF. >> The Run of completion option works when (for instance) you have a file >> source connected to other non-PMT Message block and a sink (USRP or null >> sink...). However, when the file source output is converted to pmt >> Message, then the flowgraph does not stop anymore when rhe file source >> has finished. Probably because the PMT Message block continue to waits >> for messages. In this case, How I can stop automatically the flowgraph? >> I would like to Close the flowgraph when EOF or USRP has no more sample >> to transmit, for example, in a situation like the following: >> >> FILE SOURCE -> STREAM TO PMT MESSAGE -> PROCESSING BLOCKS -> PMT MESSAGE >> TO FILE SOURCE -> USRP SINK >> >> Thank for yours support and for the great utility of the list 😊 >> simone >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About closing flowgraph automatically
Hi Marcus,
>Debugging your flowgraphs on a C++ and threat level when they ought to
>be exiting would be pretty interesting!
An example of my flowgraph where I used PDU to tagged stream convertion
is this:
https://github.com/ptrkrysik/examples/blob/master/voice_decoding_in_grc/tch_f_reception.grc
Messages with GSM coded voice frames are turned into stream so they can
be decoded with GSM full-rate audio decoder and played in gnuradio audio
sink.
This might be too big flow-graph for the purpose of debugging, so I
prepared minimal working example presenting the problem. The flowgraph
and its input file are attached to this post. If you want to run it in
GRC you will have to correct the File option of the file meta source to
absolute path to the tagged_stream file. I don't know how to do relative
paths in GRC yet.
Best Regards,
Piotr
W dniu 23.07.2016 o 11:55, Marcus Müller pisze:
> Hi Piotr,
>
>> Maybe it can be some "exit" tag that would be propagated to all blocks
>> in a flowgraph.
> In fact, GR does have something like that: It's a built-in message
> handler for a message port called "system"; see block.cc:60:
>
> 60 message_port_register_in(pmt::mp("system"));
> 61 set_msg_handler(pmt::mp("system"),
> boost::bind(&block::system_handler, this, _1));
>
> You can send a "done" message there, and the block will set it's
> internal state to being done, ie work won't be called any more, the
> stream and message neighbours of that block will be informed to be done,
> too.
>
> By the way, the information you're looking for mainly resides in
> block.cc, block_executor.cc's "run_one_iteration" method, and
> tpb_thread_body.cc
>
> It's exactly the mechanism that happens when a block notifies its
> message neighbours to be done; for example, let ==> be a stream
> connection and --> a message connection
>
> msg_burster ---> some_kind_of_msg_to_stream ==> multiply_const ==> head
> ==> file_sink
>
> at some point, head's work method will tell the scheduler it's done. The
> scheduler will then inform head's stream neighbours (because head
> doesn't have any message neighbours) that they should be done, too.
>
> So file sink closes its file, mutliply_const is told to stop, and
> multiply_const then notifies its stream neighbours itself, and thus,
> some_kind_of_msg_to_stream is told to stop doing its thing, too.
>
> However, if these neigbours (which, remember, are all independently
> running threads!) are currently in their work() methods, then the
> scheduler won't (can't) interrupt that work call. That's all fine for
> things like multiply_const, where the work() will be done as soon as it
> has gone through the chunk of samples it's currently processing.
>
> For stream sources such as some_kind_of_msg_to_stream, the problem is a
> little more complex:
>
> Stream sources are usually designed to be blocking in the work() method;
> if that blocking doesn't have some timeout, then there's no way for that
> block's work() to ever stop blocking, and hence, the flow graph won't
> shut down, because the "system" message handler never gets called. In
> the some_kind_of_msg_to_stream source, the programmer must take care not
> to block in work() if there's nothing to produce, but just return 0 -
> meaning the source didn't produce anything. In the olden,
> pre-message-passing days, that would've been a great mistake, because a
> source producing nothing although there was the whole output buffer in
> space was declared finished, but nowadays, the scheduler can "revive" a
> source block not only when the free space in the output changes, but
> also if there's new messages to be handled. HOWEVER: this might still
> have bugs, and it might be that this is what you're encountering.
> Debugging your flowgraphs on a C++ and threat level when they ought to
> be exiting would be pretty interesting!
>
> Best regards,
>
> Marcus
>
> On 23.07.2016 08:43, Piotr Krysik wrote:
>> Hi Simone and all,
>>
>> Can you provide your GRC flow-graph? I think that source of the problem
>> might be somewhere in this part
>> "PMT MESSAGE TO FILE SOURCE" as there is message to samples stream
>> conversion involved here. But it's not clear for me what it actually is
>> as you described it.
>>
>> I have problems with automatic closing of a flow-graph that uses a block
>> that converts messages to samples. In my case it is PDU to Tagged Stream
>> block that caused problems with automatic exiting of the flow-graph.
>>
>> The co
Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles
W dniu 28.06.2016 o 15:50, mle...@ripnet.com pisze: > > I just forked Keenerd's repo, which actually has support for turning > dither on/off in the API, but of course, gr-osmosdr has no support for it. > > My fork is: > > https://github.com/patchvonbraun/rtl-sdr > > Hi Marcus and all, I've tried driver from the repository and it seems to be working. When comparing phase between two channels it looks that frequency offset was removed. Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [RFNoC] Massive merge to rfnoc-devel (from rfnoc-radio-redo)
W dniu 03.08.2016 o 20:42, Martin Braun pisze: > - Radio no longer includes DSP chains > - DDC, DUC are separate blocks Hi Martin, Many thanks for the hard work by the Ettus' team. Regarding this particular change - is it possible now to process signals completely inside FPGA without streaming them to PC? The simplest example of what I'm talking about is retransmission of what enters RX port to the TX port. -- Best Regards, Piotr ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Questions regarding hierarchical polyphase channelizer
Hi all, Recently I did simple benchmark of hierarchical polyphase channelizer block (written by Ben Reynwar according to git blame) vs regular polyphase channelizer block. It seems that hierarchical version is 2-3 times faster. The documentation of the hierachical polyphase channelizer seems to be a bit too brief though (at least for me). This topic has been touched on this list before, but produced no more info about the block (in the "hierarchical polyphase channelizer vs polyphase channelizer blocks in GRC" thread). A bit more info is needed about the block's parameters and how it capabilities relate to normal polyphase channelizer block. Especially: -what n_filterbanks parameter is for? -is it possible to do oversampling of the signal at the output channels with this block the way it is possible with normal polyphase channelizer block? -- Thanks and regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions regarding hierarchical polyphase channelizer
Thanks Ben for the answer. Regarding the last question, I want to clarify a bit what I meant. Regular polyphase channelizer have oversample_rate option that lets you set oversampling so you can get output sample rates: input_samp_rate/number_of_channels * oversample_rate where oversample_rate = number_of_channels/i and where i is an integer number from 1 to number_of_channels. This is very usable in instances (like GSM or Tetra) when channel spacing (200e3 Hz for GSM) is different than symbol rate (13e6/48 Hz for GSM). If you have sample rate at the input of the channelizer that is common multiply of channel spacing and symbol rate, with this option you are able to get signal at the output of the channelizer at exactly symbol rate (or even its integer multiply in some cases). For example for 13e6 GSM band I can extract all channels by setting Channels parameter of the channelizer to 65 (13e6/0.2e6). Then I can get output signal that is sampled with 4*gsm_symbol_rate by setting oversampling to 65/12. It would be great to have something like this in your block because it is more efficient than the regular one. I can look into this if I will find some time. Best Regards, Piotr Krysik W dniu 28.10.2016 o 23:14, Ben Reynwar pisze: > The algorithm should be identical in the hierarchical case. The only > difference is that because the hierarchical implementation splits the > logic over several signal processing blocks, GNURadio is able to > easily parallelize the implementation. The n_filterbanks parameter is > just the number of filterbank blocks that are used for the filtering. > More filterbank blocks means more parallelizable, but also more > overhead. I'd have to spend some time reacquainting myself with the > code to answer your last question properly, but it should be possible > to do everything with the hierarchical implementation that you can > with the single-block implementation. > > On Mon, Oct 24, 2016 at 6:30 AM, Piotr Krysik wrote: >> Hi all, >> >> Recently I did simple benchmark of hierarchical polyphase channelizer >> block (written by Ben Reynwar according to git blame) vs regular >> polyphase channelizer block. It seems that hierarchical version is 2-3 >> times faster. >> >> The documentation of the hierachical polyphase channelizer seems to be a >> bit too brief though (at least for me). This topic has been touched on >> this list before, but produced no more info about the block (in the >> "hierarchical polyphase channelizer vs polyphase channelizer blocks in >> GRC" thread). >> >> A bit more info is needed about the block's parameters and how it >> capabilities relate to normal polyphase channelizer block. Especially: >> >> -what n_filterbanks parameter is for? >> >> -is it possible to do oversampling of the signal at the output channels >> with this block the way it is possible with normal polyphase channelizer >> block? >> >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions regarding hierarchical polyphase channelizer
Thanks Ben for the answer. Regarding the last question, I want to clarify a bit what I meant. Regular polyphase channelizer have oversample_rate option that lets you set oversampling so you can get output sample rates: input_samp_rate/number_of_channels * oversample_rate where oversample_rate = number_of_channels/i and where i is an integer number from 1 to number_of_channels. This is very usable in instances (like GSM or Tetra) when channel spacing (200e3 Hz for GSM) is different than symbol rate (13e6/48 Hz for GSM). If you have sample rate at the input of the channelizer that is common multiply of channel spacing and symbol rate, with this option you are able to get signal at the output of the channelizer at exactly symbol rate (or even its integer multiply in some cases). For example for 13e6 GSM band I can extract all channels by setting Channels parameter of the channelizer to 65 (13e6/0.2e6). Then I can get output signal that is sampled with 4*gsm_symbol_rate by setting oversampling to 65/12. It would be great to have something like this in your block because it is more efficient than the regular one. I can look into this if I will find some time. Best Regards, Piotr Krysik W dniu 28.10.2016 o 23:14, Ben Reynwar pisze: > The algorithm should be identical in the hierarchical case. The only > difference is that because the hierarchical implementation splits the > logic over several signal processing blocks, GNURadio is able to > easily parallelize the implementation. The n_filterbanks parameter is > just the number of filterbank blocks that are used for the filtering. > More filterbank blocks means more parallelizable, but also more > overhead. I'd have to spend some time reacquainting myself with the > code to answer your last question properly, but it should be possible > to do everything with the hierarchical implementation that you can > with the single-block implementation. > > On Mon, Oct 24, 2016 at 6:30 AM, Piotr Krysik wrote: >> Hi all, >> >> Recently I did simple benchmark of hierarchical polyphase channelizer >> block (written by Ben Reynwar according to git blame) vs regular >> polyphase channelizer block. It seems that hierarchical version is 2-3 >> times faster. >> >> The documentation of the hierachical polyphase channelizer seems to be a >> bit too brief though (at least for me). This topic has been touched on >> this list before, but produced no more info about the block (in the >> "hierarchical polyphase channelizer vs polyphase channelizer blocks in >> GRC" thread). >> >> A bit more info is needed about the block's parameters and how it >> capabilities relate to normal polyphase channelizer block. Especially: >> >> -what n_filterbanks parameter is for? >> >> -is it possible to do oversampling of the signal at the output channels >> with this block the way it is possible with normal polyphase channelizer >> block? >> >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR-UHD features incoming
Hi Martin, I'm trying to make use of the new message interface. I'm able to set center frequency and other parameters with use of it which is great as now I'm able to make for example a application that scans spectrum without stopping the flowgraph. However I expected that after USRP switch frequency because it received a command a new stream tag would be added to the signal at the moment of switching (like it happens when for example central frequency is switched with use of gui widgets). No tag is added though. Is this intended behaviour? Best Regards, Piotr Krysik W dniu 06.05.2015 o 19:35, Martin Braun pisze: > The big change for the moment is the enhanced message interface. With > more blocks using messages for commands (not just data), we're trying to > standardize how blocks receive messages. If you build the manual > yourself, you'll see the changes added in > https://github.com/mbr0wn/gnuradio/commit/72e0c237e06e5214eb2706bd4ac732cef068161c > to document how we'd like these command interfaces to look like. > > UHD already had it's own, home-grown message command interface. With > this change, it has been adapted to comply with how command messages > should look like. > At the same time, a lot of new commands were added. You can now change > gain, antenna, DSP frequency, LO offset, command times, analog bandwidth > (where applicable) and sampling rate through messages. > > This offers tons of cool new options. Imagine you have a blind OFDM > receiver, which first estimates the OFDM parameters (center frequency, > bandwidth, sampling rate) before attempting to blind-demodulate. You can > have a downstream block change all of these parameters[1] in a kind of > control loop[2] until they match, then demodulate -- all from the same > flow graph, just using GNU Radio blocks. > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR-UHD features incoming
Hi all,
After reading the code of usrp_source_impl I've found out that there are
separate methods for tune requests invoked from gui and by message
interface.
For gui:
::uhd::tune_result_t
usrp_source_impl::set_center_freq(const ::uhd::tune_request_t
tune_request,
size_t chan)
{
...
_tag_now = true;
...
}
For messages:
SET_CENTER_FREQ_FROM_INTERNALS(usrp_source_impl, set_rx_freq);
The second one doesn't set _tag_now - therefore no tags are added.
Everything suggests that this behaviour is intentional.
But what is the rationale? Without this tag I'll have to keep track of
frequency changes that are made and add tags myself as they are needed
to trigger events downstream.
Would it be possible to leave for the user to decide if he wants to
receive tags or not?
Best Regards,
Piotr Krysik
W dniu 24.06.2015 o 12:01, Piotr Krysik pisze:
> Hi Martin,
>
> I'm trying to make use of the new message interface. I'm able to set
> center frequency and other parameters with use of it which is great as
> now I'm able to make for example a application that scans spectrum
> without stopping the flowgraph.
>
> However I expected that after USRP switch frequency because it received
> a command a new stream tag would be added to the signal at the moment of
> switching (like it happens when for example central frequency is
> switched with use of gui widgets). No tag is added though. Is this
> intended behaviour?
>
> Best Regards,
> Piotr Krysik
>
> W dniu 06.05.2015 o 19:35, Martin Braun pisze:
>> The big change for the moment is the enhanced message interface. With
>> more blocks using messages for commands (not just data), we're trying to
>> standardize how blocks receive messages. If you build the manual
>> yourself, you'll see the changes added in
>> https://github.com/mbr0wn/gnuradio/commit/72e0c237e06e5214eb2706bd4ac732cef068161c
>> to document how we'd like these command interfaces to look like.
>>
>> UHD already had it's own, home-grown message command interface. With
>> this change, it has been adapted to comply with how command messages
>> should look like.
>> At the same time, a lot of new commands were added. You can now change
>> gain, antenna, DSP frequency, LO offset, command times, analog bandwidth
>> (where applicable) and sampling rate through messages.
>>
>> This offers tons of cool new options. Imagine you have a blind OFDM
>> receiver, which first estimates the OFDM parameters (center frequency,
>> bandwidth, sampling rate) before attempting to blind-demodulate. You can
>> have a downstream block change all of these parameters[1] in a kind of
>> control loop[2] until they match, then demodulate -- all from the same
>> flow graph, just using GNU Radio blocks.
>>
>>
>
> ___
> 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] GR-UHD features incoming
Hi Martin,
When the command carried by message is executed immediately after
reception by USRP the situation seems to be similar to tune request
invoked by the user through gui. Or is there something that I overlooked?
Things get more complicated when command has "time" in the future at
which it should be executed. I don't see easy way to identify uhd
metadata that is result of execution of given command so it could be
turned into a stream tag.
Best Regards,
Piotr
W dniu 24.06.2015 o 18:14, Martin Braun pisze:
> Piotr,
>
> not intentional -- this was indeed an oversight. I'll add an issue.
> However, it's not trivial to change; when doing message-based retuning,
> there's no clear way of knowing which sample to tag.
>
> M
>
> On 24.06.2015 04:33, Piotr Krysik wrote:
>> Hi all,
>>
>> After reading the code of usrp_source_impl I've found out that there are
>> separate methods for tune requests invoked from gui and by message
>> interface.
>>
>> For gui:
>> ::uhd::tune_result_t
>> usrp_source_impl::set_center_freq(const ::uhd::tune_request_t
>> tune_request,
>> size_t chan)
>> {
>> ...
>> _tag_now = true;
>> ...
>> }
>>
>> For messages:
>> SET_CENTER_FREQ_FROM_INTERNALS(usrp_source_impl, set_rx_freq);
>>
>> The second one doesn't set _tag_now - therefore no tags are added.
>> Everything suggests that this behaviour is intentional.
>> But what is the rationale? Without this tag I'll have to keep track of
>> frequency changes that are made and add tags myself as they are needed
>> to trigger events downstream.
>>
>> Would it be possible to leave for the user to decide if he wants to
>> receive tags or not?
>>
>> Best Regards,
>> Piotr Krysik
>>
>>
>> W dniu 24.06.2015 o 12:01, Piotr Krysik pisze:
>>> Hi Martin,
>>>
>>> I'm trying to make use of the new message interface. I'm able to set
>>> center frequency and other parameters with use of it which is great as
>>> now I'm able to make for example a application that scans spectrum
>>> without stopping the flowgraph.
>>>
>>> However I expected that after USRP switch frequency because it received
>>> a command a new stream tag would be added to the signal at the moment of
>>> switching (like it happens when for example central frequency is
>>> switched with use of gui widgets). No tag is added though. Is this
>>> intended behaviour?
>>>
>>> Best Regards,
>>> Piotr Krysik
>>>
>>> W dniu 06.05.2015 o 19:35, Martin Braun pisze:
>>>> The big change for the moment is the enhanced message interface. With
>>>> more blocks using messages for commands (not just data), we're trying to
>>>> standardize how blocks receive messages. If you build the manual
>>>> yourself, you'll see the changes added in
>>>> https://github.com/mbr0wn/gnuradio/commit/72e0c237e06e5214eb2706bd4ac732cef068161c
>>>> to document how we'd like these command interfaces to look like.
>>>>
>>>> UHD already had it's own, home-grown message command interface. With
>>>> this change, it has been adapted to comply with how command messages
>>>> should look like.
>>>> At the same time, a lot of new commands were added. You can now change
>>>> gain, antenna, DSP frequency, LO offset, command times, analog bandwidth
>>>> (where applicable) and sampling rate through messages.
>>>>
>>>> This offers tons of cool new options. Imagine you have a blind OFDM
>>>> receiver, which first estimates the OFDM parameters (center frequency,
>>>> bandwidth, sampling rate) before attempting to blind-demodulate. You can
>>>> have a downstream block change all of these parameters[1] in a kind of
>>>> control loop[2] until they match, then demodulate -- all from the same
>>>> flow graph, just using GNU Radio blocks.
>>>>
>>>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR-UHD features incoming
Hi Martin,
I'm thinking of some solution to make stream tags more usable in
combination with message interface. My first thought is that maybe
stream tag should be added to the stream whenever something (other than
timestamp) changes in _metadata received from uhd device?
--
Piotr
W dniu 24.06.2015 o 19:50, Piotr Krysik pisze:
> Hi Martin,
>
> When the command carried by message is executed immediately after
> reception by USRP the situation seems to be similar to tune request
> invoked by the user through gui. Or is there something that I overlooked?
>
> Things get more complicated when command has "time" in the future at
> which it should be executed. I don't see easy way to identify uhd
> metadata that is result of execution of given command so it could be
> turned into a stream tag.
>
> Best Regards,
> Piotr
>
> W dniu 24.06.2015 o 18:14, Martin Braun pisze:
>> Piotr,
>>
>> not intentional -- this was indeed an oversight. I'll add an issue.
>> However, it's not trivial to change; when doing message-based retuning,
>> there's no clear way of knowing which sample to tag.
>>
>> M
>>
>> On 24.06.2015 04:33, Piotr Krysik wrote:
>>> Hi all,
>>>
>>> After reading the code of usrp_source_impl I've found out that there are
>>> separate methods for tune requests invoked from gui and by message
>>> interface.
>>>
>>> For gui:
>>> ::uhd::tune_result_t
>>> usrp_source_impl::set_center_freq(const ::uhd::tune_request_t
>>> tune_request,
>>> size_t chan)
>>> {
>>> ...
>>> _tag_now = true;
>>> ...
>>> }
>>>
>>> For messages:
>>> SET_CENTER_FREQ_FROM_INTERNALS(usrp_source_impl, set_rx_freq);
>>>
>>> The second one doesn't set _tag_now - therefore no tags are added.
>>> Everything suggests that this behaviour is intentional.
>>> But what is the rationale? Without this tag I'll have to keep track of
>>> frequency changes that are made and add tags myself as they are needed
>>> to trigger events downstream.
>>>
>>> Would it be possible to leave for the user to decide if he wants to
>>> receive tags or not?
>>>
>>> Best Regards,
>>> Piotr Krysik
>>>
>>>
>>> W dniu 24.06.2015 o 12:01, Piotr Krysik pisze:
>>>> Hi Martin,
>>>>
>>>> I'm trying to make use of the new message interface. I'm able to set
>>>> center frequency and other parameters with use of it which is great as
>>>> now I'm able to make for example a application that scans spectrum
>>>> without stopping the flowgraph.
>>>>
>>>> However I expected that after USRP switch frequency because it received
>>>> a command a new stream tag would be added to the signal at the moment of
>>>> switching (like it happens when for example central frequency is
>>>> switched with use of gui widgets). No tag is added though. Is this
>>>> intended behaviour?
>>>>
>>>> Best Regards,
>>>> Piotr Krysik
>>>>
>>>> W dniu 06.05.2015 o 19:35, Martin Braun pisze:
>>>>> The big change for the moment is the enhanced message interface. With
>>>>> more blocks using messages for commands (not just data), we're trying to
>>>>> standardize how blocks receive messages. If you build the manual
>>>>> yourself, you'll see the changes added in
>>>>> https://github.com/mbr0wn/gnuradio/commit/72e0c237e06e5214eb2706bd4ac732cef068161c
>>>>> to document how we'd like these command interfaces to look like.
>>>>>
>>>>> UHD already had it's own, home-grown message command interface. With
>>>>> this change, it has been adapted to comply with how command messages
>>>>> should look like.
>>>>> At the same time, a lot of new commands were added. You can now change
>>>>> gain, antenna, DSP frequency, LO offset, command times, analog bandwidth
>>>>> (where applicable) and sampling rate through messages.
>>>>>
>>>>> This offers tons of cool new options. Imagine you have a blind OFDM
>>>>> receiver, which first estimates the OFDM parameters (center frequency,
>>>>> bandwidth, sampling rate) before attempting to blind-demodulate. You can
>>>>> have a downstream block change all of these parameters[1] in a kind of
>>>>> control loop[2] until they match, then demodulate -- all from the same
>>>>> flow graph, just using GNU Radio blocks.
>>>>>
>>>>>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR-UHD features incoming
Haha, Another genius plan ruined by hard reality. I forgot what is inside uhd metadata and assumed that current frequency is taken from there. The good thing is that learned that it will be easier to generate the tags myself in some block than to require from usrp source to do the magic. Regarding the code contribution - if I figure out how to do generate tags resulting from execution of a command I will send the code for review. Best Regards, Piotr Krysik W dniu 24.06.2015 o 21:41, Martin Braun pisze: > On 24.06.2015 11:55, Piotr Krysik wrote: >> Hi Martin, >> >> I'm thinking of some solution to make stream tags more usable in >> combination with message interface. My first thought is that maybe >> stream tag should be added to the stream whenever something (other than >> timestamp) changes in _metadata received from uhd device? > The RX metadata only includes timestamp and EOB (apart from error > codes), so I'm not sure what exactly you would want to make a tag. > > That said, I'm all for making tags more useful and adding more > information. And I'm even more happy about code contributions than I am > about suggestions :) > > M > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Suppressing UHD prints
Hi all,
UHD host library generates prints on the stdout. For example on each
retune I get something like:
-- Tune Request: 959.00 MHz
-- The RF LO does not support the requested frequency:
-- Requested LO Frequency: 959.00 MHz
-- RF LO Result: 958.998779 MHz
-- Attempted to use the DSP to reach the requested frequency:
-- Desired DSP Frequency: -0.001221 MHz
-- DSP Result: -0.001221 MHz
-- Successfully tuned to 959.00 MHz
--
These prints are sometimes cluttering the console - especially when
someone wants to use console to print other useful information.
There is possibility to disable them in UHD from the level of C++:
http://files.ettus.com/manual/page_general.html
("Disabling or redirecting prints to stdout")
Is it possible to disable the prints from GNU Radio?
Best Regards,
Piotr Krysik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Pybombs recipes submodule pointer update policy
Hi all, I have question for pybombs developers/maintainers: Is there policy for updating recipes submodule pointer in the pybombs repository? Currently recipes submodule pointer is 29 days behind the head. -- Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pybombs recipes submodule pointer update policy
W dniu 05.09.2015 o 20:01, Piotr Krysik pisze: > Hi all, > > I have question for pybombs developers/maintainers: > Is there policy for updating recipes submodule pointer in the pybombs > repository? > > Currently recipes submodule pointer is 29 days behind the head. > > -- > Best Regards, > Piotr Krysik > > Hi, In case of misunderstanding - I'm not trying to complain about your work. Pybombs is great tool that simplifies a lot installation of GNU Radio related projects. I need information as a developer of one of such projects what are requirements for me in order to make fixes in recipes related to my project appear faster in the main pybombs repository. Best Regards, Piotr ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fractional resampler eats stream tags on changes on the "ratio" input
Hi all, Fractional resampler has additional "rate" signal input for supplying resampling ratio for each input signal sample. Changes of the signal on the "ratio" input might result in loss of tags that are close in time to these changes. I observed the problem when I was implementing frequency offset corrector (attached flowgraph screenshot). Short description what is going on there: -when message comes to ppm_in port of the block "Controlled const source" changes value of constant at the output, -when Controlled rotator observe this change on its input, it emits stream tag, -for changes of about +/-50ppm (and above) on the 'ratio' input of the Fractional Resampler, tags coming from the Controlled rotator are not going through. Just by looking at the Fractional Resampler implementation (https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fractional_resampler_cc_impl.cc#L104) I'm not able to locate source of the problem. I can implement minimal working example if needed. Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fractional resampler eats stream tags on changes on the "ratio" input
W dniu 25.09.2015 o 23:23, Tom Rondeau pisze: > On Wed, Sep 23, 2015 at 4:06 PM, Piotr Krysik <mailto:per...@o2.pl>> wrote: > > Hi all, > > Fractional resampler has additional "rate" signal input for supplying > resampling ratio for each input signal sample. > Changes of the signal on the "ratio" input might result in loss of > tags > that are close in time to these changes. > > I observed the problem when I was implementing frequency offset > corrector (attached flowgraph screenshot). > Short description what is going on there: > -when message comes to ppm_in port of the block "Controlled const > source" changes value of constant at the output, > -when Controlled rotator observe this change on its input, it emits > stream tag, > -for changes of about +/-50ppm (and above) on the 'ratio' input of the > Fractional Resampler, tags coming from the Controlled rotator are not > going through. > > Just by looking at the Fractional Resampler implementation > > (https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fractional_resampler_cc_impl.cc#L104) > I'm not able to locate source of the problem. > > I can implement minimal working example if needed. > > Best Regards, > Piotr Krysik > > > Piotr, > > Looking at the block, I was hoping it was as easy as putting a > set_relative_rate call in the set_resamp_rate to adjust how the tags > are being propagated. But it's not that simple. See Issue #846 > (http://gnuradio.org/redmine/issues/846) for details on the problem. > > Tom > Hi Tom, Thank you for the response and time spent on debugging this issue. Now when I know what is going on I can try to prepare some workaround for my purposes (i.e. single C++ block for frequency offset correction). Best Regards, Piotr ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Dynamic changes of the samples flow in a flowgraph
Hi all, I'm looking for a way to modify dynamically flow of samples in a flowgraph. Making changes in between lock() and unlock() functions is not good enough - a number of samples from sources like rtl-sdr are lost during flowgraph reconfiguration. I had some hope that selector block (or some similar block based on the same concept) can be used for the purpose of reconnecting part of a flowgraph. However it uses lock() and unlock() so the effect is the same. Can something what I need (a selector or valve block but without use of lock() ) be implemented or is it incompatible with GNU Radio design? One of the projects I need this for is live synchronization multiple rtl-sdr devices inside of GNU Radio (I will make it public when it will be done). Some of samples are captured to vector sinks for the purpose of synchronization. After collecting a required number of samples these sinks should be disconnected so they don't use the entire memory. I can't do it however without loosing some sample and this way loosing also synchronization. Best Regards, Piotr ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Message inputs and hierachical block: incompatibility introduced in GNU Radio 3.7.9
Hi all,
In GNU Radio version 3.7.8 message inputs of hierarchical blocks were
created from python level with:
self.message_port_register_hier_out("msg_in")
Starting (most probably) from GNU Radio 3.7.9 message inputs are created
with:
self.message_port_register_hier_in("msg_in")
This leads to incompatibility. I can't now distribute to the users
python code of hierarchical blocks generated with GRC because for some
of them it won't work (if they don't use the same GNU Radio version as I
do). Compilation of GRC files to python with grcc during building is not
an option as it doesn't work reliably yet and it will lead to higher
level of problems.
Currently I manually added this code to my hierarchical blocks in order
to make them work on with GNU Radio earlier than 3.7.9:
from distutils.version import LooseVersion as version
if version(gr.version()) >= version('3.7.9'):
self.message_port_register_hier_in("msg_in")
else:
self.message_port_register_hier_out("msg_in")
Is it possible to fix this problem for example on the level GRC - so it
generate code that is compatible with GNU Radio versions < 3.7.9 and
>=3.7.9?
Best Regards,
Piotr Krysik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: Re: Message inputs and hierachical block: incompatibility introduced in GNU Radio 3.7.9
Hi Tim,
The new (originally intended) API is more intuitive. After thinking
again - I can live with having to add three lines to my hierarchical
blocks. It's better than complicating something more important (like
GRC) to get backward compatibility.
It's good to have confirmation that there were significant changes/fixes
in the hierarchical blocks code.
Regarding message passing in hierarchical blocks in GNU Radio 3.7.8 -
I've checked it and it works without problems. Messages carrying clock
offset measurements are reaching their destination
(clock_offset_corrector in gr-gsm). Maybe in my case the problems
doesn't occur.
--
Piotr Krysik
W dniu 02.01.2016 o 22:22, Tim O'Shea pisze:
> Hi Piotr,
>
> Hier message ports were actually not working at all prior to this fix -
> - since the logic had been changed from the originally functioning
> pub/sub based message connection data structures into the more
> traditional digraph flattening structure incorrectly
> please see: http://gnuradio.org/redmine/issues/862#change-2460
>
> This change was needed to correct the hier port flattening logic
> and was the originally intended API that got reversed somewhere along
> the way -
> GRC was updated to correspond --
> Have you tested your hier message ports actually function with 3.7.8
> successfully prior to this? I would be kind of surprised -
> Perhaps if you are writing python code, some kind of conditional check
> work around might be in order, or just dropping support for old
> versions as they did not function correctly
>
> -Tim
>
>
>
> On Sat, Jan 2, 2016 at 4:12 AM Piotr Krysik <mailto:per...@o2.pl>> wrote:
>
> Hi all,
>
> In GNU Radio version 3.7.8 message inputs of hierarchical blocks were
> created from python level with:
>self.message_port_register_hier_out("msg_in")
>
> Starting (most probably) from GNU Radio 3.7.9 message inputs are
> created
> with:
>self.message_port_register_hier_in("msg_in")
>
> This leads to incompatibility. I can't now distribute to the users
> python code of hierarchical blocks generated with GRC because for some
> of them it won't work (if they don't use the same GNU Radio
> version as I
> do). Compilation of GRC files to python with grcc during building
> is not
> an option as it doesn't work reliably yet and it will lead to higher
> level of problems.
>
> Currently I manually added this code to my hierarchical blocks in
> order
> to make them work on with GNU Radio earlier than 3.7.9:
>
> from distutils.version import LooseVersion as version
>
> if version(gr.version()) >= version('3.7.9'):
> self.message_port_register_hier_in("msg_in")
> else:
> self.message_port_register_hier_out("msg_in")
>
> Is it possible to fix this problem for example on the level GRC -
> so it
> generate code that is compatible with GNU Radio versions < 3.7.9 and
> >=3.7.9?
>
> Best Regards,
> Piotr Krysik
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto: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] Pybombs 2: how to use "--config" parameter, how to disable "forcebuild" of gnuradio
Hi all, How to use "--config" option of pybombs 2. Can someone show an working example? In pybombs 2 "forcebuild" is set to true for gnuradio by default. How to disable "focebuild" for gnuradio from commandline with the pybombs command? Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pybombs 2: how to use "--config" parameter, how to disable "forcebuild" of gnuradio
Thank you Martin! W dniu 18.03.2016 o 18:54, Martin Braun pisze: > To disable gnuradio's forcebuild from the command line, run: > > $ pybombs config --package gnuradio forcebuild False > > This will persistently disable forcebuilding for GNU Radio. > > With --config, you can only change the global config settings (i.e. the > ones in the config: section in your config.yml files). Example: > > $ pybombs --config makewidth=8 install gnuradio > > This is *non-persistent* and will override any config.yml setting for > the duration of the process. > To see what the options are that you can change with --config, simply run > > $ pybombs config > > without any other parameters. They include help texts, too. > > Note the first command includes the --package switch. If you leave it > out and just call config , it'll set a global config > option, like --config (but persistent). > > M > > > > > On 03/17/2016 02:09 PM, Piotr Krysik wrote: >> Hi all, >> >> How to use "--config" option of pybombs 2. Can someone show an working >> example? >> >> In pybombs 2 "forcebuild" is set to true for gnuradio by default. >> How to disable "focebuild" for gnuradio from commandline with the >> pybombs command? >> >> Best Regards, >> Piotr Krysik >> >> ___ >> 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] Pybombs 2: how to use "--config" parameter, how to disable "forcebuild" of gnuradio
The "--package" parameter seems to be added recently as pybombs installed with pip doesn't have this option yet. Best Regards, Piotr W dniu 19.03.2016 o 17:59, Piotr Krysik pisze: > Thank you Martin! > > > W dniu 18.03.2016 o 18:54, Martin Braun pisze: >> To disable gnuradio's forcebuild from the command line, run: >> >> $ pybombs config --package gnuradio forcebuild False >> >> This will persistently disable forcebuilding for GNU Radio. >> >> With --config, you can only change the global config settings (i.e. the >> ones in the config: section in your config.yml files). Example: >> >> $ pybombs --config makewidth=8 install gnuradio >> >> This is *non-persistent* and will override any config.yml setting for >> the duration of the process. >> To see what the options are that you can change with --config, simply run >> >> $ pybombs config >> >> without any other parameters. They include help texts, too. >> >> Note the first command includes the --package switch. If you leave it >> out and just call config , it'll set a global config >> option, like --config (but persistent). >> >> M >> >> >> >> >> On 03/17/2016 02:09 PM, Piotr Krysik wrote: >>> Hi all, >>> >>> How to use "--config" option of pybombs 2. Can someone show an working >>> example? >>> >>> In pybombs 2 "forcebuild" is set to true for gnuradio by default. >>> How to disable "focebuild" for gnuradio from commandline with the >>> pybombs command? >>> >>> Best Regards, >>> Piotr Krysik >>> >>> ___ >>> 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 > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Cmake rule to compile GRC files with GRCC
Hi all, In my third party gnuradio project - gr-gsm (https://github.com/ptrkrysik/gr-gsm) - I'm using gnuradio companion to create apps. Different versions of gnuradio companion generate python files that may be incompatible between different GNU Radio versions. Therefore if the user decides to compile gr-gsm it would be best to compile python files on his machine, for whatever version of GNU Radio he has. I'm is looking for someone who know how to do this with use of cmake. There is a file taken from GNU Radio which is in https://github.com/ptrkrysik/gr-gsm/blob/master/cmake/Modules/GrMiscUtils.cmake. It had GRCC function which was suited for GNU Radio (although it was not really used in GNU Radio). I've tried to adapt it to gr-gsm case but it caused more problems than it solved. If you know how to write a CMAKE rule compiling GRC files with grcc - please help. Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cmake rule to compile GRC files with GRCC
W dniu 07.12.2014 o 18:09, Martin Braun pisze:
> On 12/07/2014 08:57 AM, Piotr Krysik wrote:
>> I'm is looking for someone who know how to do this with use of cmake.
>> There is a file taken from GNU Radio which is in
>> https://github.com/ptrkrysik/gr-gsm/blob/master/cmake/Modules/GrMiscUtils.cmake.
>> It had GRCC function which was suited for GNU Radio (although it was not
>> really used in GNU Radio). I've tried to adapt it to gr-gsm case but it
>> caused more problems than it solved. If you know how to write a CMAKE
>> rule compiling GRC files with grcc - please help.
> I've used this in the past (grc/CMakeLists.txt):
>
>
> message("Compiling GRC hier blocks...")
> foreach(grc_file ${grc_hier_blocks})
> message("Compiling " ${grc_file})
> execute_process(
> COMMAND grcc ${grc_file}
> WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
> )
> endforeach(grc_file ${grc_hier_blocks})
>
>
>
> ...but it's not ideal as it runs during cmake, not make.
>
> M
>
>
Many thanks Martin for the answer. I will give a try your method.
--
Piotr
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "Run to completion" not working with message passing blocks
W dniu 29.04.2014 o 16:20, Tom Rondeau pisze: > On Tue, Apr 29, 2014 at 9:33 AM, Perper <mailto:per...@o2.pl>> wrote: > > Hi all, > > I want to use message passing blocks for operations where strict > synchronization is not necessary. However in flowgraphs using message > passing with "Run to completion" option turned on the program doesn't > exit on last processed sample. Is this a bug? > > I want to use message passing in my programs (mainly in > https://github.com/Jakotako/gr-gsm) but completion after processing of > all input data is also very important for me. > > -- > Piotr Krysik > > > > Yes, this is a known issue and we are working on it. > > Tom > Hi Tom, In GNU Radio 3.7.6 this is still an issue. It's quite serious because whole class of applications that would use message passing and rely on the processing in the flowgraph to end after processing of chunk of the signal (i.e. to change the flowgraph in known conditions) is not possible. I'm working on a simple gsm network monitor application based on gr-gsm (https://github.com/ptrkrysik/gr-gsm) and have quite hard time because of this issue. Is this some general problem where the source of it is that GNU Radio was meant primarily to process stream of samples? Or is it some simpler matter? I've attached vary simple flowgraph that demonstrates the problem. Best Regards, Piotr Krysik message_passing_no_exit.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Triggering USRP at given GPS time from GNU Radio
Hi all, Whenever I want to trigger USRP with at given time with use of a GPSDO I'm adding something like this at the end of a constructor of a topblock generated by gnuradio-companion: if start_time!="": self.start_time_epoch = time.mktime(time.strptime(start_time,'%d.%m.%Y %H:%M:%S')) self.uhd_usrp_source_0.set_start_time(uhd.time_spec_t(self.start_time_epoch)) where start_time is a string parameter containing the time at which the device should start reception. The snippet might be useful for others trying to do the same thing. I want to ask you if there is a way to do better than that and generate directly in gnuradio-companion a flowgraph that use GPSDO of USRP to trigger it without having to edit anything manually? Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Triggering USRP at given GPS time from GNU Radio
W dniu 24.02.2015 o 10:59, Martin pisze: > For this application it would be helpfull if you could set the > start_time from grc. > > In general it would be very helpfull if you could add your own python > code to grc without having to edit it manually after generating. > > A "codeblock" in a similar way the import block is implemented would > be very helpful. Just a block where you can add code. You should > probably be able to choose where the code is added. > > at the top of the file after all imports > at the beginning of the constructor of the flowgraph > at the end of the constructor of the flow_graph > as a seperate method of the flowgraph > at the start of main > at the end of main. > > We could make it a feature request. > Or maybe I should just implement it. Martin, The solution proposed by you would be very good to give to the user ability to do something more sophisticated than gnuradio-companion supports at any point in the future. However in my opinion ability to trigger USRP at a specified time is quite basic feature of the device. Maybe it would be better to add the start_time parameter in gnuradio-companion UHD blocks (source and sink) that would be parsed into appropriate python code. To keep it simple to implement the value given could be as a float in seconds that would be directly converted into USRP's clock value like this: uhd.time_spec_t(start_time) and it would be user task to assign proper value like: start_time:time.mktime(time.strptime(time_string,'%d.%m.%Y %H:%M:%S')) #if he uses GPSDO or start_time: self.uhd_usrp_source.get_time_now()+4 #if he just to start 4 seconds from now The examples of how to use this parameter could be documented in the description of the blocks so each user wouldn't have to find this out on his own. The other advantage of this approach - it would also give a simple way to synchronize UHD source and sink from gnuradio-companion. Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "Run to completion" not working with message passing blocks
W dniu 16.02.2015 o 17:29, Tom Rondeau pisze: > On Sat, Feb 14, 2015 at 3:34 PM, Piotr Krysik <mailto:per...@o2.pl>> wrote: > > W dniu 29.04.2014 o 16:20, Tom Rondeau pisze: > > On Tue, Apr 29, 2014 at 9:33 AM, Perper <mailto:per...@o2.pl> > > <mailto:per...@o2.pl <mailto:per...@o2.pl>>> wrote: > > > > Hi all, > > > > I want to use message passing blocks for operations where strict > > synchronization is not necessary. However in flowgraphs > using message > > passing with "Run to completion" option turned on the > program doesn't > > exit on last processed sample. Is this a bug? > > > > I want to use message passing in my programs (mainly in > > https://github.com/Jakotako/gr-gsm) but completion after > processing of > > all input data is also very important for me. > > > > -- > > Piotr Krysik > > > > > > > > Yes, this is a known issue and we are working on it. > > > > Tom > > > Hi Tom, > > In GNU Radio 3.7.6 this is still an issue. It's quite serious because > whole class of applications that would use message passing and rely on > the processing in the flowgraph to end after processing of chunk > of the > signal (i.e. to change the flowgraph in known conditions) is not > possible. > > I'm working on a simple gsm network monitor application based on > gr-gsm > (https://github.com/ptrkrysik/gr-gsm) and have quite hard time because > of this issue. > > Is this some general problem where the source of it is that GNU Radio > was meant primarily to process stream of samples? Or is it some > simpler > matter? > > I've attached vary simple flowgraph that demonstrates the problem. > > Best Regards, > Piotr Krysik > > > The fix for this was pushed a couple of weeks ago and will make it in > the 3.7.7 release. We're looking to see any side effects and might be > able to back-port it for the next 3.7.6 maint release. Commit here: > > https://github.com/gnuradio/gnuradio/commit/035b9d016dffefec890323bd0b24dbaf23aa9186 > > Tom > I've tied gnuradio compiled with and without this commit. I didn't observe difference - run to completion doesn't seem to work with message passing. I've attached the gnuradio-companion flowgraph that I've used for the test. Question to the list: does "Run to completion" feature work for you in the attached example or in any other case of a flowgraph with message passing? -- Piotr message_passing_no_exit.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "Run to completion" not working with message passing blocks
W dniu 25.03.2015 o 16:48, Tom Rondeau pisze: > On Wed, Mar 25, 2015 at 3:11 AM, Piotr Krysik <mailto:per...@o2.pl>> wrote: > > W dniu 16.02.2015 o 17:29, Tom Rondeau pisze: > > On Sat, Feb 14, 2015 at 3:34 PM, Piotr Krysik <mailto:per...@o2.pl> > > <mailto:per...@o2.pl <mailto:per...@o2.pl>>> wrote: > > > > W dniu 29.04.2014 o 16:20, Tom Rondeau pisze: > > > On Tue, Apr 29, 2014 at 9:33 AM, Perper <mailto:per...@o2.pl> <mailto:per...@o2.pl <mailto:per...@o2.pl>> > > > <mailto:per...@o2.pl <mailto:per...@o2.pl> > <mailto:per...@o2.pl <mailto:per...@o2.pl>>>> wrote: > > > > > > Hi all, > > > > > > I want to use message passing blocks for operations > where strict > > > synchronization is not necessary. However in flowgraphs > > using message > > > passing with "Run to completion" option turned on the > > program doesn't > > > exit on last processed sample. Is this a bug? > > > > > > I want to use message passing in my programs (mainly in > > > https://github.com/Jakotako/gr-gsm) but completion after > > processing of > > > all input data is also very important for me. > > > > > > -- > > > Piotr Krysik > > > > > > > > > > > > Yes, this is a known issue and we are working on it. > > > > > > Tom > > > > > Hi Tom, > > > > In GNU Radio 3.7.6 this is still an issue. It's quite > serious because > > whole class of applications that would use message passing > and rely on > > the processing in the flowgraph to end after processing of chunk > > of the > > signal (i.e. to change the flowgraph in known conditions) is not > > possible. > > > > I'm working on a simple gsm network monitor application based on > > gr-gsm > > (https://github.com/ptrkrysik/gr-gsm) and have quite hard > time because > > of this issue. > > > > Is this some general problem where the source of it is that > GNU Radio > > was meant primarily to process stream of samples? Or is it some > > simpler > > matter? > > > > I've attached vary simple flowgraph that demonstrates the > problem. > > > > Best Regards, > > Piotr Krysik > > > > > > The fix for this was pushed a couple of weeks ago and will make > it in > > the 3.7.7 release. We're looking to see any side effects and > might be > > able to back-port it for the next 3.7.6 maint release. Commit here: > > > > > > https://github.com/gnuradio/gnuradio/commit/035b9d016dffefec890323bd0b24dbaf23aa9186 > > > > Tom > > > > I've tied gnuradio compiled with and without this commit. I didn't > observe difference - run to completion doesn't seem to work with > message > passing. I've attached the gnuradio-companion flowgraph that I've used > for the test. > > Question to the list: does "Run to completion" feature work for you in > the attached example or in any other case of a flowgraph with message > passing? > > -- > Piotr > > > Ah, well there's the problem. In GRC open up "Help"->"Types". The > blocks you are using are the old Message Queue based blocks, not the > new asynchronous message passing interface. The commit that I was > talking about was specific to the async message passing, so yeah, it'd > have no bearing on this. > > This is definitely confusing since they are both "message" based even > though it's a completely different system. The old style used here > will likely be removed at some point, though it's use persists in a > few places. For your stuff, I'd avoid using this (anything with that > dark grey port) and use the new async messages (the light grey ports). > > Tom > Tom, The attached flowgraph was an example. I wanted to prepare something small that uses only GNU Radio's message blocks, to avoid situation where I messed something in C++. The blocks that I selected were not appropriate for the situation. However in https://github.com/ptrkrysik/gr-gsm/blob/master/apps/airprobe_file.grc I'm using only message passing interface, but can't get "Run to completion" to work as it should. Can you show an example of GRC flowgraph that uses message passing and exit when the input signal is over? I would greatly appreciate that as I'm a little bit stuck on this problem. -- Piotr ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "Run to completion" not working with message passing blocks
W dniu 26.03.2015 o 08:39, Piotr Krysik pisze: > W dniu 25.03.2015 o 16:48, Tom Rondeau pisze: >> On Wed, Mar 25, 2015 at 3:11 AM, Piotr Krysik > <mailto:per...@o2.pl>> wrote: >> >> W dniu 16.02.2015 o 17:29, Tom Rondeau pisze: >> > On Sat, Feb 14, 2015 at 3:34 PM, Piotr Krysik > <mailto:per...@o2.pl> >> > <mailto:per...@o2.pl <mailto:per...@o2.pl>>> wrote: >> > >> > W dniu 29.04.2014 o 16:20, Tom Rondeau pisze: >> > > On Tue, Apr 29, 2014 at 9:33 AM, Perper > <mailto:per...@o2.pl> <mailto:per...@o2.pl <mailto:per...@o2.pl>> >> > > <mailto:per...@o2.pl <mailto:per...@o2.pl> >> <mailto:per...@o2.pl <mailto:per...@o2.pl>>>> wrote: >> > > >> > > Hi all, >> > > >> > > I want to use message passing blocks for operations >> where strict >> > > synchronization is not necessary. However in flowgraphs >> > using message >> > > passing with "Run to completion" option turned on the >> > program doesn't >> > > exit on last processed sample. Is this a bug? >> > > >> > > I want to use message passing in my programs (mainly in >> > > https://github.com/Jakotako/gr-gsm) but completion after >> > processing of >> > > all input data is also very important for me. >> > > >> > > -- >> > > Piotr Krysik >> > > >> > > >> > > >> > > Yes, this is a known issue and we are working on it. >> > > >> > > Tom >> > > >> > Hi Tom, >> > >> > In GNU Radio 3.7.6 this is still an issue. It's quite >> serious because >> > whole class of applications that would use message passing >> and rely on >> > the processing in the flowgraph to end after processing of chunk >> > of the >> > signal (i.e. to change the flowgraph in known conditions) is not >> > possible. >> > >> > I'm working on a simple gsm network monitor application based on >> > gr-gsm >> > (https://github.com/ptrkrysik/gr-gsm) and have quite hard >> time because >> > of this issue. >> > >> > Is this some general problem where the source of it is that >> GNU Radio >> > was meant primarily to process stream of samples? Or is it some >> > simpler >> > matter? >> > >> > I've attached vary simple flowgraph that demonstrates the >> problem. >> > >> > Best Regards, >> > Piotr Krysik >> > >> > >> > The fix for this was pushed a couple of weeks ago and will make >> it in >> > the 3.7.7 release. We're looking to see any side effects and >> might be >> > able to back-port it for the next 3.7.6 maint release. Commit here: >> > >> > >> >> https://github.com/gnuradio/gnuradio/commit/035b9d016dffefec890323bd0b24dbaf23aa9186 >> > >> > Tom >> > >> >> I've tied gnuradio compiled with and without this commit. I didn't >> observe difference - run to completion doesn't seem to work with >> message >> passing. I've attached the gnuradio-companion flowgraph that I've used >> for the test. >> >> Question to the list: does "Run to completion" feature work for you in >> the attached example or in any other case of a flowgraph with message >> passing? >> >> -- >> Piotr >> >> >> Ah, well there's the problem. In GRC open up "Help"->"Types". The >> blocks you are using are the old Message Queue based blocks, not the >> new asynchronous message passing interface. The commit that I was >> talking about was specific to the async message passing, so yeah, it'd >> have no bearing on this. >> >> This is definitely confusing since they are both "message" based even >> though it's a completely different system. The old style u
Re: [Discuss-gnuradio] "Run to completion" not working with message passing blocks
W dniu 01.04.2015 o 12:10, Marcus Müller pisze:
> Hi Piotr,
>
> nice to hear you got a step ahead!
> so,
>> I did that and what I obtained was:
>> ---
>> 16 Thread 0x7fffbdffb700 (LWP 13462) "python"
>> pthread_cond_wait@@GLIBC_2.3.2 () at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
>> 3Thread 0x7fffe9720700 (LWP 13449) "gsm_clock_offs1"
>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>> * 1Thread 0x77fc7740 (LWP 13444) "python" 0x778e8da3 in
>> select () at ../sysdeps/unix/syscall-template.S:81
>> ---
>
> I'd have a blind guess:
> Thread 16 might be the "surviving" part of a python-spawned Timer()
> thread, which caused a message _post at another thread, which might be
> something that hangs if that block's thread no longer exists.
>
> Can you switch to that thread:
> thread 16
> and then try to get a python backtrace [1]
> py-bt
> and maybe a simple C-style backtrace
> bt
>
> that might give you some information what is actually waiting on a
> condition (which is what I guess from "pthread_cond_wait").
>
> Greetings,
> Marcus
>
> [1] for this to work, you might need to follow these instructions from
> http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB:
>
> ... make sure that the python development package is installed
> (|python-devel| on Redhatoids, |python2.7-dev| on Debianoids); for
> some systems, you should append the content of
> |/usr/share/doc/{python-devel,python2.7-dev}/gdbinit[.gz]| to your
> |~/.gdbinit|, and re-start |gdb|.
>
Marcus,
Regarding the timer - this is what I thought at first, so I removed it
from the block. It didn't help, so I removed almost everything leaving
only message input of the block. But the problem persisted.
I will try you advice with GDB and let everybody know of the result.
Best Regards,
Piotr
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "Run to completion" not working with message passing blocks
W dniu 02.04.2015 o 15:30, Piotr Krysik pisze:
> W dniu 01.04.2015 o 12:10, Marcus Müller pisze:
>> Hi Piotr,
>>
>> nice to hear you got a step ahead!
>> so,
>>> I did that and what I obtained was:
>>> ---
>>> 16 Thread 0x7fffbdffb700 (LWP 13462) "python"
>>> pthread_cond_wait@@GLIBC_2.3.2 () at
>>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
>>> 3Thread 0x7fffe9720700 (LWP 13449) "gsm_clock_offs1"
>>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>>> * 1Thread 0x77fc7740 (LWP 13444) "python" 0x778e8da3 in
>>> select () at ../sysdeps/unix/syscall-template.S:81
>>> ---
>> I'd have a blind guess:
>> Thread 16 might be the "surviving" part of a python-spawned Timer()
>> thread, which caused a message _post at another thread, which might be
>> something that hangs if that block's thread no longer exists.
>>
>> Can you switch to that thread:
>> thread 16
>> and then try to get a python backtrace [1]
>> py-bt
>> and maybe a simple C-style backtrace
>> bt
>>
>> that might give you some information what is actually waiting on a
>> condition (which is what I guess from "pthread_cond_wait").
>>
>> Greetings,
>> Marcus
>>
>> [1] for this to work, you might need to follow these instructions from
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB:
>>
>> ... make sure that the python development package is installed
>> (|python-devel| on Redhatoids, |python2.7-dev| on Debianoids); for
>> some systems, you should append the content of
>> |/usr/share/doc/{python-devel,python2.7-dev}/gdbinit[.gz]| to your
>> |~/.gdbinit|, and re-start |gdb|.
>>
> Marcus,
>
> Regarding the timer - this is what I thought at first, so I removed it
> from the block. It didn't help, so I removed almost everything leaving
> only message input of the block. But the problem persisted.
>
> I will try you advice with GDB and let everybody know of the result.
>
> Best Regards,
> Piotr
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
Marcus,
I did what you recommended but my knowledge of GDB doesn't let me
interpret what I get to find the probably cause of the problem.
Instead of sending output of GDB I'm sending simple python script so
every interested person can see what doesn't work. Inside the script
there is one message source and one message sink.
The source sends one message to the sink. At the end the program should
exit but it doesn't.
Best Regards,
Piotr Krysik
#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# Author: Piotr Krysik
#Program presenting potential problem caused by message passing done
#from Python. The program should exit after sending the message - however this doesn't happen.
from gnuradio import gr
import pmt
class test_msg_source(gr.basic_block):
def __init__(self):
gr.basic_block.__init__(self, name="test_msg_source", in_sig=[], out_sig=[])
self.message_port_register_out(pmt.intern("msgs"))
def send_msg(self):
msg_ppm = pmt.from_double(0.0)
self.message_port_pub(pmt.intern("msgs"), msg_ppm)
class test_msg_sink(gr.basic_block):
def __init__(self):
gr.basic_block.__init__(self, name="test_msg_sink", in_sig=[], out_sig=[])
self.message_port_register_in(pmt.intern("msgs"))
self.set_msg_handler(pmt.intern("msgs"), self.process_msg)
def process_msg(self, msg):
print "Received message:", msg
class test_flowgraph(gr.top_block):
def __init__(self):
gr.top_block.__init__(self, "test_flograph")
self.msg_source = test_msg_source()
self.msg_sink = test_msg_sink()
self.msg_connect((self.msg_source, 'msgs'), (self.msg_sink, 'msgs'))
def trigger_message_transmission(self):
self.msg_source.send_msg()
if __name__ == '__main__':
tb = test_flowgraph()
tb.start()
tb.trigger_message_transmission()
tb.wait()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "Run to completion" not working with message passing blocks
W dniu 03.04.2015 o 13:25, Piotr Krysik pisze:
> W dniu 02.04.2015 o 15:30, Piotr Krysik pisze:
>> W dniu 01.04.2015 o 12:10, Marcus Müller pisze:
>>> Hi Piotr,
>>>
>>> nice to hear you got a step ahead!
>>> so,
>>>> I did that and what I obtained was:
>>>> ---
>>>> 16 Thread 0x7fffbdffb700 (LWP 13462) "python"
>>>> pthread_cond_wait@@GLIBC_2.3.2 () at
>>>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
>>>> 3Thread 0x7fffe9720700 (LWP 13449) "gsm_clock_offs1"
>>>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>>>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>>>> * 1Thread 0x77fc7740 (LWP 13444) "python" 0x778e8da3 in
>>>> select () at ../sysdeps/unix/syscall-template.S:81
>>>> ---
>>> I'd have a blind guess:
>>> Thread 16 might be the "surviving" part of a python-spawned Timer()
>>> thread, which caused a message _post at another thread, which might be
>>> something that hangs if that block's thread no longer exists.
>>>
>>> Can you switch to that thread:
>>> thread 16
>>> and then try to get a python backtrace [1]
>>> py-bt
>>> and maybe a simple C-style backtrace
>>> bt
>>>
>>> that might give you some information what is actually waiting on a
>>> condition (which is what I guess from "pthread_cond_wait").
>>>
>>> Greetings,
>>> Marcus
>>>
>>> [1] for this to work, you might need to follow these instructions from
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB:
>>>
>>> ... make sure that the python development package is installed
>>> (|python-devel| on Redhatoids, |python2.7-dev| on Debianoids); for
>>> some systems, you should append the content of
>>> |/usr/share/doc/{python-devel,python2.7-dev}/gdbinit[.gz]| to your
>>> |~/.gdbinit|, and re-start |gdb|.
>>>
>> Marcus,
>>
>> Regarding the timer - this is what I thought at first, so I removed it
>> from the block. It didn't help, so I removed almost everything leaving
>> only message input of the block. But the problem persisted.
>>
>> I will try you advice with GDB and let everybody know of the result.
>>
>> Best Regards,
>> Piotr
>>
> Marcus,
>
> I did what you recommended but my knowledge of GDB doesn't let me
> interpret what I get to find the probably cause of the problem.
>
> Instead of sending output of GDB I'm sending simple python script so
> every interested person can see what doesn't work. Inside the script
> there is one message source and one message sink.
> The source sends one message to the sink. At the end the program should
> exit but it doesn't.
>
> Best Regards,
> Piotr Krysik
>
Hi all,
Reimplementing the block that uses message passing from Python to C++
did help.
The question remains - in more precisely formulated form:
***
*Why "Run to completion" doesn't work with Python blocks that use
message passing?*
***
For anyone who wants to debug this - I've attached Python code
demonstrating the problem to my previous message.
Best Regards,
Piotr Krysik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to create uhd's time_spec_t from Python
Hi All, time_spec_t is a class representing time in UHD. It uses time_t (long int) for representing full seconds and double for parts of a second. This format of time is usable to tell USRPs when to do certain tasks. It is also very usable for operations on time without loosing precision. In c++ time_spec_t can be constructed from time represented by a double (not precise if number of full seconds is large) or from time_t and double. Both constructors are exposed by SWIG in Python. When I construct time_spec from double everything is fine: >>> from gnuradio import uhd >>> uhd.time_spec(10) But when I construct from int and float I get an error: >>> uhd.time_spec(10,0.1) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 1576, in __init__ this = _uhd_swig.new_time_spec_t(*args) NotImplementedError: Wrong number or type of arguments for overloaded function 'new_time_spec_t'. Possible C/C++ prototypes are: uhd::time_spec_t::time_spec_t(double) uhd::time_spec_t::time_spec_t(time_t,double) uhd::time_spec_t::time_spec_t(time_t,long,double) Somehow Python's integer is not recognized as compatible with time_t parameter in the second constructor (uhd::time_spec_t::time_spec_t(time_t,double) ). My question: Is there a way to use time_spec_t's constructor uhd::time_spec_t::time_spec_t(time_t,double) from Python interface exposed by GNU Radio? In my opinion there should be, otherwise why to expose it through SWIG. -- Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8
W dniu 18.09.2017 o 11:10, Håkon Vågsether pisze:
> Hi all,
>
> The focus for this week has been the QT blocks. You can read more at:
>
> https://grccpp.wordpress.com
>
> Best regards,
> Håkon Vågsether
Hi Håkon,
I'm trying to compile and run according to the description but I got an
error when trying to do "from gnuradio import gr". Gnuradio-companion
also doesn't run because of this.
Below is the full error message. My OS is Ubuntu 16.04. I don't want you
to loose focus to debug this particular problem, but can you tell me
what is your setup (mainly distro), where your version of GRC works fine?
Python 3.5.2 (default, Aug 18 2017, 17:48:00)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from gnuradio import gr
Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
line 39, in
from .runtime_swig import *
File
"/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
line 28, in
_runtime_swig = swig_import_helper()
File
"/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_runtime_swig', fp, pathname, description)
File "/usr/lib/python3.5/imp.py", line 242, in load_module
return load_dynamic(name, filename, file)
File "/usr/lib/python3.5/imp.py", line 342, in load_dynamic
return _load(spec)
ImportError: dynamic module does not define module export function
(PyInit__runtime_swig)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/__init__.py",
line 43, in
from .runtime_swig import *
File
"/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
line 28, in
_runtime_swig = swig_import_helper()
File
"/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_runtime_swig', fp, pathname, description)
File "/usr/lib/python3.5/imp.py", line 242, in load_module
return load_dynamic(name, filename, file)
File "/usr/lib/python3.5/imp.py", line 342, in load_dynamic
return _load(spec)
ImportError: dynamic module does not define module export function
(PyInit__runtime_swig)
Best Regards,
Piotr Krysik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [SOCIS '17] GRC C++ Output: Week 8
Hi Håkon, Thanks for the info. I will try your code under that distro. Regarding what I've shown - I compiled everything according to your description and gnuradio-companion failed on my machine (Ubuntu 16.04) to load because it couldn't import gr from gnuradio. This is why I've shown what happens when trying to load that module. Best Regards, Piotr Krysik W dniu 25.09.2017 o 02:39, Håkon Vågsether pisze: > Hello Piotr, > > hmm, that certainly doesn't look like code I have touched, and I can't > say I have seen that error before either. I'm running Arch Linux > (Python 3.6.2), hope that helps! :) > > Python 3.5.2 (default, Aug 18 2017, 17:48:00) > [GCC 5.4.0 20160609] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> from gnuradio import gr > Traceback (most recent call last): > File > "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/__init__.py", > line 39, in > from .runtime_swig import * > File > "/usr/local/lib/python3.5/dist-packages/gnuradio/gr/runtime_swig.py", > line 28, in > _runtime_swig = swig_import_helper() > File > ... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSM receiver
W dniu 12.10.2017 o 11:29, Rensi Mathew pisze: > > I am working with the airprobe_uhd.grc file in the page > https://sourceforge.isae.fr/projects/ralf/wiki/GSM_receiver_with_gr-gsm_and_Wireshark. > > I am running the |gnuradio-companion| in Ubuntu 16.04 and my source is > USRP B200 SDR. When I am running the grc file, an error occurs. > > ImportError: libgrgsm-0.41.2.so.0.0.0: cannot open shared object > file: No such file or directory. > > the said |libgrgsm| file is available in |/usr/local/lib| and > |/home/pglab1/gr-gsm/build/lib| > How can I correct the error? Hi, Invoking: sudo ldconfig might help. Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] UHD USRP Async Msg Source
W dniu 24.02.2015 o 23:01, Martin Braun via USRP-users pisze: > On 02/02/2015 05:31 PM, Murphy, John via USRP-users wrote: >> Hello, >> In GNU Radio Companion under version 3.7.6.1 with UHD version 3.8.1 I >> see a block under the UHD blocks called "UHD: USRP Async Msg Source". >> When I connect this to a WX GUI Terminal Sink the flowgraph (which has >> a USRP Source block for my receiver front end) runs just fine but >> nothing is printed in the terminal window. >> What are some of the uses of this "Async Msg Source" and is there >> something I can do in GRC to enable it to pass text to the terminal >> block? > The short answer is, you probably don't need this block. > > The long answer: When streaming to the device (Tx), there is a return > path for for messages from the device, such as underruns. These can be > read out with this block. It then passes these messages to a legacy > message queue. > > In the future, this block will probably go away, and the message output > might get merged with the USRP sink, because both the way this block > reads the messages and the message queue are considered deprecated, but > we'll keep it around for as long as possible for backward compatibility > reasons. > Hi all, I was looking for a way to handle transmission errors for UHD Sink and someone showed me this thread from usrp-users list from over two years ago. I suppose the future described by Martin hasn't arrived yet as UHD USRP sink doesn't receive and expose information about transmission problems. If no one more skilled in extending GNU Radio project's blocks wont show up and do this, at some point I will probably need to add that support myself (as "USRP Async Msg Source" is deprecated). I want to ask you GNU Radio developers for advices how it can be done so maybe what I 'll be doing will be usable for other people, not just me. What I want to do at this moment is to add to UHD Sink a thread doing what this function osmo-trx does: https://github.com/ttsou/osmo-trx/blob/master/Transceiver52M/UHDDevice.cpp#L368 The thread would send messages with information about transmission problems to a message output. What do you think about such solution? Best Regards, Piotr Krysik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fractional resampler eats stream tags on changes on the "ratio" input
W dniu 17.07.2016 o 13:05, Piotr Krysik pisze:
> W dniu 07.06.2016 o 13:30, Piotr Krysik pisze:
>> W dniu 01.10.2015 o 14:46, Piotr Krysik pisze:
>>> W dniu 25.09.2015 o 23:23, Tom Rondeau pisze:
>>>
>>>
>>>
>>> Looking at the block, I was hoping it was as easy as putting a
>>> set_relative_rate call in the set_resamp_rate to adjust how the tags
>>> are being propagated. But it's not that simple. See Issue #846
>>> (http://gnuradio.org/redmine/issues/846) for details on the problem.
>>>
>>> Tom
>>>
>>>
>> Hi,
>>
>> I'm writing to let everyone know that resampling blocks after changing
>> the resampling rate in the run-time is still eating stream tags. This
>> makes some designs impossible to implement currently.
>>
>> For example - it would be great if it was possible to implement a clock
>> offset frequency correction like I have drawn on the attached image:
>> -there are two blocks that do the correction: resampler and frequency
>> shifting block,
>> -they change their parameters (resamp_rate, frequency_shift) on stream tags,
>> -there is a block that does clock frequency offset measurements that is
>> connected at the end (putting it in different place is not practical in
>> many circumstances),
>> -these measurements are sent to frequency offset control block which
>> turns them into control messages addressed for both resampler and
>> frequency shifter,
>> -msg to tag blocks adds a tag containing a control message to a stream,
>> -the information about changes of settings of the resampler and rotator
>> are interpreted also by the measurement block, that adjusts measurements
>> based on this information.
>>
>> But currently it not possible to do this due to the issue with the
>> resampling blocks.
>>
>> Did you Tom or anyone found the source of the problem?
>>
>>
> Hi Tom and others,
>
> I implemented fractional resampling block that can have resampling rate
> changed.
>
> When doing this I learned what is the source of the issue #846. The
> mistake is following:
>
> transformation of tag offset by resampling block that changes its
> resample rate is not a linear function, so in this case you can't use
> such simple linear conversion, like it is done in GNU Radio's runtime:
> https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/block_executor.cc#L143
>
> However, transformation is linear from one resample rate change to
> another. So if you know input and output sample number for which
> resample rate was the same as for the moment when a tag came - you can
> use this as reference point to compute the tag's offset at the output of
> the resampling block.
>
>
> My proposed solution: modification of tags offsets processing in
> gnuradio runtime so it includes case when you have resampling blocks
> with dynamically changing resample rate doesn't seem resonable. If would
> complicate things too much because the runtime would have to track
> resample rate changes inside of every block that can do that. Resampling
> blocks that can have resample rate changed dynamically should implement
> tags propagation themselves.
>
> Current fractional resampler block doesn't do that and it is incorrect.
> The input for dynamic resample rate control should be removed as it can
> cause problems to the users OR users should be warned that if they use
> this input they shouldn't expect tags to work correctly.
>
> The block implemented by me is available here:
> https://github.com/ptrkrysik/gr-gsm/blob/master/lib/misc_utils/controlled_fractional_resampler_cc_impl.cc
>
> It uses a pmt pair ("set_resamp_ratio",value) tag to set resample ratio
> precisely at the moment of tag occurrence.
> It wasn't tested in all possible conditions yet, so I'm still a bit
> cautious regarding it. But it presents how such a block can be
> implemented and in tests performed by me it worked (it is also now used
> to correct sample frequency offset in gr-gsm).
>
Hi all,
Little update in this old but still valid thread. I created two issues
regarding it:
1. what is wrong in the runtime in the context changing relative rate
and tag propagation:
https://github.com/gnuradio/gnuradio/issues/2055
2. other things regarding tag propagation that are wrong in
mmse_resampler (new name of fractional_resampler):
https://github.com/gnuradio/gnuradio/issues/2056
Best Regards,
Piotr Krysik
___
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
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. > > gen_and_compare.sh Description: application/shellscript #!/usr/bin/env python2 # -*- coding: utf-8 -*- # # SPDX-License-Identifier: GPL-3.0 # ## # GNU Radio Python Flow Graph # Title: Testindeterminate # Generated: Wed Oct 3 13:46:04 2018 # GNU Radio version: 3.7.12.0 ## from gnuradio import blocks from gnuradio import eng_notation from gnuradio import gr from gnuradio.eng_option import eng_option from gnuradio.filter import firdes from optparse import OptionParser class testindeterminate(gr.top_block): def __init__(self, number_of_samples=100, output_file="out.bin"): gr.top_block.__init__(self, "Testindeterminate") ## # Parameters ## self.number_of_samples = number_of_samples self.output_file = output_file ## # Variables ## self.samp_rate = samp_rate = 2e6 ## # Blocks ## self.blocks_vector_source_x_0_0 = blocks.vector_source_c((0.1,)*number_of_samples, False, 1, []) self.blocks_vector_source_x_0 = blocks.vector_source_c((1.0,)*number_of_samples, False, 1, []) self.blocks_file_sink_0_0 = blocks.file_sink(gr.sizeof_gr_complex*1, output_file, False) self.blocks_file_sink_0_0.set_unbuffered(False) self.blocks_divide_xx_0_0 = blocks.divide_cc(1) ## # Connections ## self.connect((self.blocks_divide_xx_0_0, 0), (self.blocks_file_sink_0_0, 0)) self.connect((self.blocks_vector_source_x_0, 0), (self.blocks_divide_xx_0_0, 0)) self.connect((self.blocks_vector_source_x_0_0, 0), (self.blocks_divide_xx_0_0, 1)) def get_number_of_samples(self): return self.number_of_samples def set_number_of_samples(self, number_of_samples): self.number_of_samples = number_of_samples self.blocks_vector_source_x_0_0.set_data((0.1,)*self.number_of_samples, []) self.blocks_vector_source_x_0.set_data((1.0,)*self.number_of_samples, []) def get_output_file(self): return self.output_file def set_output_file(self, output_file): self.output_file = output_file self.blocks_file_sink_0_0.open(self.output_file) def get_samp_rate(self): return self.samp_rate def set_samp_rate(self, samp_rate): self.samp_rate = samp_rate def argument_parser(): parser = OptionParser(usage="%prog: [options]", option_class=eng_option) parser.add_option( "-N", "--number-of-samples", dest="number_of_samples", type="intx", default=100, help="Set number_of_samples [default=%default]") parser.add_option( "-o", "--output-file", dest="output_file", type="string", default="out.bin", help="Set out.bin [default=%default]") return parser def main(top_block_cls=testindeterminate, options=None): if options is None: options, _ = argument_parser().parse_args() tb = top_block_cls(number_of_samples=options.number_of_samples, output_file=options.output_file) tb.start() tb.wait() if __name__ == '__main__': main() testindeterminate_pk.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
