Can anyone explain why the sample rate setting is ignored by the Redhawk FileReader component when attempting to read Blue/Platinum files? The FileReader uses a fixed 25MSps rate regardless of what was used to create the blue file.
The warning message in my console appears as follows whenever I try to change the rate setting: FileReader_i:352 - ignoring attempt to set sample rate while reading blue file
The sample rate is ignored because the sample rate is defined within the bluefile header data. The sample rate entered by the user is ignored and the sample rate defined in the file header is given preference. See the example below for details.
You did not supply the version of REDHAWK you are using or the versions of components. I am going to run the docker image axios/redhawk:2.0.4 so if you have docker installed you can reproduce. This included the REDHAWK 2.0.4 framework and version 4.0.3 filereader component.
I wrote two short scripts to help; one will create a file using rh.SigGen and rh.FileWriter in /tmp/example.tmp which will be of type BLUEFILE. It waits for the user to hit enter and then will cut the file using the default sample rate of 5000 Sps. The second script will read the file with rh.FileReader show that it takes the same amount of time to read as to write, show the content of the bluefile header and show that the rh.FileReader is using the sample rate from the header.
The first script I've called create_samplefile.py
#!/bin/env python
from ossie.utils import sb
import time
siggen = sb.launch('rh.SigGen')
filewriter = sb.launch('rh.FileWriter')
filewriter.file_format = "BLUEFILE"
filewriter.destination_uri = "file:///tmp/example.tmp"
siggen.connect(filewriter, usesPortName='dataFloat_out')
start_time = time.time()
sb.start()
time.sleep(1.0)
raw_input("Press any key to end the file creation test and cut the file: ")
siggen_sample_rate = float(siggen.sample_rate)
sb.stop()
filewriter.releaseObject()
siggen.releaseObject()
time.sleep(1.0)
print 'Sample rate of SigGen was: %s' % siggen_sample_rate
print 'Total time elapsed was %s' % (time.time() - start_time)
Then the second script I've called time_readfile.py
#!/bin/env python
from ossie.utils import sb
import time
from ossie.utils import bluefile
from pprint import pprint
hdr, data = bluefile.read('/tmp/example.tmp')
print 'Here is all the information from the blue file header: \n %s' % pprint(hdr)
sink = sb.FileSink()
filereader = sb.launch('rh.FileReader')
filereader.source_uri = "file:///tmp/example.tmp"
filereader.file_format = "BLUEFILE"
filereader.advanced_properties.packet_size = "1024"
filereader.connect(sink, usesPortName='dataFloat_out')
start_time = time.time()
sb.start()
filereader.playback_state = "PLAY"
while not sink.eos():
time.sleep(1.0)
print 'xdelta received by sink: %s' % sink.sri().xdelta
print 'Sample rate on filereader: %s' % filereader.sample_rate
print "Total time elapsed was: %s" % (time.time() - start_time)
Running them you get the following (I've removed parts that are not germane):
[redhawk@bd28992b6770 example]$ python create_samplefile.py
Press any key to end the file creation test and cut the file:
...
Sample rate of SigGen was: 5000.0
Total time elapsed was 77.7008731365
[redhawk@bd28992b6770 example]$ python time_readfile.py
Here is all the information from the blue file header:
...
'xdelta': 0.00020000000000000001,
2017-06-22 20:00:05 INFO FileReader_i:352 - Using sample rate of 2.5e+07 Sps
2017-06-22 20:00:05 INFO FileReader_i:352 - Using sample rate of 5000 Sps
xdelta received by sink: 0.0002
Sample rate on filereader: 5000
Total time elapsed was: 77.0785810947
So you see that FileReader started at 25Msps but then switched to 5000 as defined in the bluefile header via the xdelta parameter (1/0.0002 = 5000). We've printed the received xdelta from the file sink and we also have a rough confirmation since the playback time and file creation times were about the same (77 seconds). You need to make sure the packet_size parameter is small enough for this or you have a large file otherwise the entire file content will be pushed in a single push packet.