-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've asked a similar question before, so please try and bear with me :).
Is there a way to calculate the delay of all blocks after yours in a chain? It might be as easy as summing up the histories of all of the blocks... As an illustration of why we need this, consider that the filter blocks often set_history equal to the number of taps. This means that as soon as a single sample gets sent through, they can begin emitting data. However, the data that they emit isn't useful -- not until the filter block is full of samples. If we're streaming, this is fine, a minor delay. However, packet-based applications send a message and then switch back to RX mode. The upshot of this is that the ends of packets will get stuck in the filters and not get pushed out until the next data packet comes through. This (not end-of-packet-ISI) is why we have to append at least one nonsense byte to the end of a packet in order to make the CRCs match, and why that end-of-packet error is deterministic rather than random. A fix seems to be to appending a number of additional samples (maybe zero samples) equal to the total pipeline delay to a message in a message_source. Do we have the facility to do this? Other suggestions? Comments? - -Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjUNoy9GYuuMoUJ4RAkRhAJ4+duozGplcFxHmiz+qNP7N7m/0CACdGGQ7 Zz8uuwOFeA57mKvf+fy4on8= =irgt -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio