Hi Marcus, thanks for the answer! Though to be honest I'm not really happy with that solution. This simple "FM demod" thing is getting real complicated here. We would need 4 blocks just for demodulating FM in your proposed scenario:
(msg->[some resamp rate calc block]->[frac resampler]->[WBFM receive]->[Audio Sink]). My mentors and me had a hangout today and decided to create an instance of the fractional resampler block within the Extractor block of my toolbox. My block will then emulate the scheduler. This way, when extracting a signal out of the combined messages of the Separator, one can set a fixed sample rate for each processing chain (which is really nice I think). Also, it can become handy to generally have the possibility of a fixed sample rate in the toolbox standard blocks. Anyway thanks for your ideas! Cheers, Sebastian 2016-08-03 19:44 GMT+02:00 Marcus Müller <[email protected]>: > Ok, so the point is that you want to make run-time changes to an existing > block. > The classical solution I'd go for is to put the block (here: resampler) > into a hier block, and add something that receives, translates messages, or > tags. > > On the other hand, really, the fractional_resampler_ff *should* have a > message handler that changes the resampling ratio. The fact that there's a > method that can just change the ratio while general_work() might be doing > its job in a different thread is a multithreading disaster happening right > before our eyes. So, if I might be as brazen: please make sure no-one > already did this on next, and then just add a message port handler that > sets the resampling ration (and one for the $\mu$, if possible), using the > "canonical" pmt_dict format (i.e. {"resampling_ratio": pmt_double} or so). > > Since you're writing an OOT that you probably want people to use even if > they're not using bleeding-edge GR, I'd personally say: copy&paste the > resampler block you need from gr-filter to gr-inspector, modify it to your > needs and upstream your changes, and also add a remark to your Readme that > starting with GR version 3.X.Y, you don't need that block anymore; more > responsible upstream developers than I am might have a different view, > however. > > Cheers, > Marcus > > > On 08/03/2016 05:29 PM, Sebastian Müller wrote: > > Hi list, > > I have stumbled upon a problem and I'm not sure what's the best way to > deal with it. > > My target is to have a FM demodulator for my gr-inspector toolbox. For > this, I generally would use a WBFM receive -> Audio sink chain. Now, the > quadrature rate and audio decimation are unknown before runtime, but > calculated by my other blocks while running. For this purpose, I would like > to implement a block, that resamples any given signal to a fixed output > sample rate (in this example a bit more than the audio rate). I have > messages available that contain the sample rate of my input signal as well > as the input signal itself. > > My first thought was to use an existing resample block, but I'm not sure > how to include it into my own block. Inheriting from the public header > yields a compiling error since the methods are not implemented (they are in > the ***_impl.h class, which is not public). Is there another way to "remote > control" other blocks within my block? Or generally a better solution for > my problem? > > Thanks for all answers > Cheers > Sebastian > > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
