I'm using the file_meta_sink to record time-stamped data, and I have a
question about the implementation of this block.  I currently call it in
Python as follows:

self.blocks_file_meta_sink_0 = blocks.file_meta_sink(gr.sizeof_short*2,
self.dat_filename, samp_rate, 1, blocks.GR_FILE_SHORT, False,
2*int(samp_rate), "", False)

If I understand the parameters right, I have configured this block so as
to not include extra header information.

If I also understand correctly, there are (by default, if no extras)
eight fields provided in the header.

However, when I run my Python flowgraph and read the header information
from the created file using gr_read_file_metadata.py, I get the
following:

HEADER 0
Version Number: 0
Sample Rate: 10000000.00 sps
Seconds: 1381406414.235846
Item size: 4
Data Type: short (1)
Complex? False
Header Length: 171 bytes
Extra Length:  22
Extra Header?  True
Size of Data: 80000000 bytes
              20000000 items

Extra Header:
rx_freq:
8.99e+08

As you can see, a ninth field is returned as an extra header, rx_freq.
As far as I can tell in my flowgraph, I'm not doing anything myself that
would cause this field to be added.  I'd like to know where this field
is added since I'd like to add more.  Specifically I'd like to add a GPS
string or two to tag location and velocity.  I'm using a USRP N210 with
GPSDO and querying the GPGGA, GPRMC, and XYZSP strings to get this
information.  I can currently parse these strings and write what I want
from them to another file, but if I can contain it all in one file it
would be easier for me to deal with off-line.

Thanks,
Scott Bennett
JHU/APL

On Thu, Oct 10, 2013 at 9:39 AM, Bennett, David S. (Scott)
<Scott.Bennett@jhuapl.edu> wrote:
>
>
>
> Extra Length:  22
>
> two to tag location and velocity.  Im using a USRP N210 with GPSDO and
>
> JHU/APL


The extra_dict argument to the constructor is just a way to add more
data to the extra part of the header; any more data you want to add
that wouldn't be in there normally.

The extra part of the header collects any tags observed, so the USRP
will generate tags like rx_freq that will go into the header.

The metadata section of the manual has a pretty good explanation of
how it works:

http://gnuradio.org/doc/doxygen/page_metadata.html

Tom

>
> http://gnuradio.org/doc/doxygen/page_metadata.html
>
> Tom

Tom,

Thanks for the note.  As a kind of "hack" programmer, stuff like that
isn't always clear to me on the first (or second, or third, or etc.)
time through reading it - usually it's because I don't know exactly what
I'm looking for.  But I was able this morning to add the additional tags
(at least a test of them with the same data types) to the
usrp_source_impl.cc source code, and it looks like, when I read the
metadata with the gr_read_file_metadata.py script, I can read out what I
wrote in.  So that's progress.  I guess the extra tags as sourced from
the USRP are handled by the parser because the expected header length is
different from where the actual data starts (from the 'strt' tag), and
the script interprets that additional information as extra header.

I appreciate your help.

Thanks,
Scott