Re: [Discuss-gnuradio] Meta file time stamp

[Daniel Marlow]

On Sep 9, 2015, at 12:46 PM, Tom Rondeau wrote:

On Wed, Sep 2, 2015 at 3:51 PM, Daniel Marlow <address@hidden> wrote:

Dear All,

  We are experiencing unexpected behavior with the time stamps in the meta file headers.   It
appears that in cases where the flowgraph experiences data drops, the timestamp is properly
updated.   However, in cases, where the flowgraph hits the maximum segment size (4 MB in our case),
the calculation of timestamp is done in such a way that appears to neglect a decimation factor
in one of our  blocks (keep_1_in_n).     Details can be found below.   Any suggestions as to what's
going on or what to do about it would be most appreciated.

Sincerely,
Dan Marlow

Details:

   OS: Ubuntu 15.04 (GNU/Linux 3.19.0-26-generic x86_64)

   H/W:  Ettus B210 with GPSDO,
             Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz 8GB memory USB3

gnuradio:  3.7.8

Flowgraph:   This is provided to give an idea of what we are doing.  It is close to what we
                     are using, but not exact, since we edited the output generated by GRC.




The actual top_block we are running is attached below.




Results:  gr_read_file_metadata test09.dat > headers.txt

Yeah, I think I can see this as a problem. It's getting the sample rate from the UHD device as a tag, but that doesn't know that the sample rate has been changed through the flowgraph.

Can you open an issue on the gnuradio.org issue tracker to remind me about this?

Tom

Hi Tom,

   Thanks for getting back to me.   I had attempted to post an update to this, but something went wrong

with my mail client and it didn't go out.   

   Anyway, we figured out the problem.     In a nutshell, we did not understand the meaning of 

the "relative rate change parameter" in the calling sequence for the meta file sink block.   That

is (obviously in hindsight) the way in which the system learns about decimation factors that

come in between the UHD and the file sink.   In particular, if there is a stage that decimates by N, 

the relative rate change parameter should be set to 1/N.

Sincerely,

Dan Marlow