Re: [Discuss-gnuradio] recovering timing after overflow

[Juha Vierinen]

Hurray!

It worked. I like the more object oriented approach more, but I'll
wait for it to come stable first.

I finally have something that I've waited for a long time. I am now
able to keep track of time within a gnuradio block even in the
presence of overflows. This comes in handy because I am using one
computer to record and analyze several simultaneous beacon satellite
receivers, and at the same time running a chirp sounder at 25 MHz
bandwidth, which simultaneously looks at three transmitters. I am
effectively maxing out my low end intel quad core CPU, and if I do
anything heavy on the machine, I get overflows. I just accidentally
put the machine into swap halt by doing something heavy on R and got
59300 overflows on the ionosonde receiver that was running in the
background. But everything is still in sync!

In the process of figuring out how to determine the absolute time in
the most convenient way, I found out that it is handy to have a
"virtual t0". This is initially rx_time, but if I get overflows, I
shift the virtual t0 by the number of dropped samples. This way I
always get the correct time on the granularity of one work block by
just calculating vt0+nitems_read(0)/sr. I might even make a mental
note that I write a patch for this functionality. Another approach
that I came up with was to create a block that pads zeros in place of
the lost samples, but this was too tedious for me to do.

juha

On Wed, Oct 26, 2011 at 19:04, Josh Blum <address@hidden> wrote:
>
>
> On 10/26/2011 08:23 AM, Juha Vierinen wrote:
>> If I understand correctly, the sample count is:
>>
>> const uint64_t count = gr_tags::get_nitems(rx_time_tag);
>
> Correct, that will work. Just so you know, the tags API changed in
> master to be more object oriented, so if you are on master, its
> my_tag.offset. But yes, this is the same call.
>
>> This determines the index of the sample coming into work, which has a
>> new time because of overflow.
>>
>
> The "uint64_t count" is the absolute index of the tag/timestamp. The
> absolute index of a sample can be calculated as this->nitems_read(0) +
> relative_offset
>
> Where relative_offset is the offset of the sample in your input buffer
> in the current call to work.
>
> -josh
>