Hi Marcus the elder, wouldn't a block that adds that tag work, too?
I see that you, especially in a high-rate streaming scenario, wouldn't want to have a "memcpy" block; and I see actual need for a GR scheduler/buffer_reader enhancement that allows for blocks that are "transparent" by means that they don't have an output buffer of their own, but introduce another layer of buffer_writer that the downstream block sees, so that they can read-only react to incoming samples. Cheers, Marcus the second On 19.07.2016 22:26, Marcus D. Leech wrote: > I've been playing some lately with devices that don't provide an > inherent hardware timestamp, yet which can be run from a common clock, > and made coherent using cross-correlation estimation of timing offset. > > Something that would make this easier--in that it would establish a > starting-point for cross correlation, and thus reduce the window size > over which one needs to estimate, would be if the scheduler could > insert a time tag of some sort the FIRST time it calls a work function > either initially or after a start() stop() start() sequence. This > would be crude, since it would be based on an OS-based timer, so it could > only act as a starting point. > > That would allow one to then write a generic synchronizer block that > used a combination of rx_crude_time, and actual cross-correlation. > > Is this a dumb idea? > > > > _______________________________________________ > 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
