i remember the gr-fsk4 demodulator uses the message queue to send frequency correction info to a pre-demod freq-xlating filter. Check out the code here maybe it will help http://7120804464424340617-a-1802744773732722657-s-sites.googlegroups.com/site/radiorausch/GnuradioFourLevelFSK.html
Sent from my iPhone On Apr 30, 2010, at 3:35 AM, Martin Braun <martin.br...@kit.edu> wrote: Thanks Matt, and Michael, for your input. To clarify: I was thinking about a frequency offset detection at a later stage in the demodulation process, which feeds back the frequency offset to an initial xlating FIR filter (I do realise feeding back individual samples is kind of ridiculous from a scheduling POV). Another question: will the message interface be able to send messages "backwards" in the flow graph? Thanks MB On Thu, Apr 29, 2010 at 09:07:27AM -0700, Matt Ettus wrote: y(n) = x(n) + x(n-2) This is easy and already supported in GNU Radio, since it is not feedback. Perhaps you meant: y(n) = x(n) + y(n-1) Which would be feedback, and is not currently supported. You can, of course, do it *within* a block, like our IIR filter blocks. My question is: can GNU Radio be modified to accept this? It's a perfectly valid flow graph (similar to ones you find in DSP textbooks), and thanks to the history of the delays, one that should work. I'd be very interested to hear some comments on this. Cheers MB Assuming you meant the feedback version I mentioned above, the current GNU Radio scheduler does not allow this. The changes to support it would be significant, but not impossible. Eric would be better positioned to explain it, but here is my take on it. First, you would need to be able to communicate the amount of delay to the scheduler, so it could insert leading zeros for time when it does not have feedback values. This is because the adder would not have its own previous output in order to produce its first input. Second, you would need to check for deadlock. If you were to put variable rate blocks in the loop, you could end up with deadlock. Third, blocks in GNU Radio usually take large blocks of input and produce large blocks of output. If you were to do your block like above, you could only produce 1 output per call, which would result in very high overhead and poor performance. -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-3790 Fax: +49 721 608-6071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio