Re: [Discuss-gnuradio] Scheduler enhancement?

[Marcus Müller]

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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio