On Sep 9, 2015, at 12:46 PM, Tom Rondeau wrote:
> On Wed, Sep 2, 2015 at 3:51 PM, Daniel Marlow <mar...@princeton.edu> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
