Re: [Discuss-gnuradio] Meta file time stamp

2015-09-09 Thread Daniel Marlow




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

> On Wed, Sep 2, 2015 at 3:51 PM, Daniel Marlow  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


Re: [Discuss-gnuradio] Meta file time stamp

2015-09-09 Thread Tom Rondeau
On Wed, Sep 2, 2015 at 3:51 PM, Daniel Marlow  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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Meta file time stamp

2015-09-02 Thread Daniel Marlow
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.



B210_2ch_filewriter.grc
Description: Binary data


The actual top_block we are running is attached below.

#!/usr/bin/env python2
##
# GNU Radio Python Flow Graph
# Title: Top Block
# Generated: Thu Jul 23 11:29:50 2015
##

from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import fft
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.fft import window
from gnuradio.filter import firdes
from optparse import OptionParser
import specest
import time

import pmt
from DAQ import rxcntl

class top_block(gr.top_block):
def __init__(self, fname1='raw1.dat', fname2='raw2.dat'):
gr.top_block.__init__(self, "Top Block")

##
# Extra Variables
##
self.fname1 = fname1
self.fname2 = fname2
self.nChannels = nChannels = 1
print "Entering top_block: fname1={0:s} fname2={1:s}".format(self.fname1,self.fname2)  

##
# Variables
##
self.freq1 = freq1 = 142000
self.freq2 = freq2 = 142000
self.samp_rate = samp_rate = 1/4.
self.gain = gain = 60
self.N_average = N_average = 512
self.FFT_size = FFT_size = 32 
self.BW = BW = 2000
self.BW = BW = 2500

##
# Blocks
##
self.uhd_usrp_source_0 = uhd.usrp_source(
	",".join(("ser=F61177", "")),
	uhd.stream_args(
		cpu_format="fc32",
		channels=range(self.nChannels),
	),
)
self.uhd_usrp_source_0.set_subdev_spec("A:A A:B", 0)
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_center_freq(self.freq1, 0)
self.uhd_usrp_source_0.set_gain(gain, 0)
self.uhd_usrp_source_0.set_bandwidth(BW, 0)
#sensorNames = self.uhd_usrp_source_0.get_mboard_sensor_names(0) 
#print "Sensor names=" + str(sensorNames) 
GPStime = self.uhd_usrp_source_0.get_mboard_sensor("gps_time")
GPS_locked = self.uhd_usrp_source_0.get_mboard_sensor("gps_locked")
print "GPS Info:  {0:s}; {1:s}".format(str(GPS_locked),str(GPStime))
self.uhd_usrp_source_0.set_time_now(uhd.time_spec(time.time()), uhd.ALL_MBOARDS)
if self.nChannels == 2 :
self.uhd_usrp_source_0.set_center_freq(self.freq2, 1)
self.uhd_usrp_source_0.set_gain(gain, 1)
self.uhd_usrp_source_0.set_bandwidth(BW, 1)


self.specest_moving_average_vff_0 = specest.moving_average_vff(N_average, FFT_size, 1, 4096)
self.fft_vxx_0 = fft.fft_vcc(FFT_size, True, (window.blackmanharris(FFT_size)), True, 1)
self.blocks_vector_to_stream_0 = blocks.vector_to_stream(gr.sizeof_float*1, FFT_size)
self.blocks_stream_to_vector_0 = blocks.stream_to_vector(gr.sizeof_gr_complex*1, FFT_size)
self.blocks_keep_one_in_n_0_0 = blocks.keep_one_in_n(gr.sizeof_float*FFT_size, N_average)
self.blocks_complex_to_mag_squared_0 = blocks.complex_to_mag_squared(FFT_size)
self.blocks_file_meta_sink_0 = blocks.file_meta_sink(gr.sizeof_float*1, self.fname1, self.samp_rate, \
1, blocks.GR_FILE_FLOAT, False, 100, self._extras(), False)
self.blocks_file_meta_sink_0.set_unbuffered(False)

if self.nChannels == 2 :
self.specest_moving_average_vff_1 = specest.moving_average_vff(N_average, FFT_size, 1, 4096)
self.fft_vxx_0_0 = fft.fft_vcc(FFT_size, True, (window.blackmanharris(FFT_size)), True, 1)
self.blocks_vector_to_stream_0_0 = blocks.vector_to_stream(gr.sizeof_float*1, FF