|
From: | Marcus Müller |
Subject: | Re: [Discuss-gnuradio] Saving data |
Date: | Fri, 16 Oct 2015 15:01:11 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
Hi Pedro, that's what the file sink is for -- "sinking" data into files. It's not producing a text file, because text files are pretty much a bad format for floating point values, usually, because you'd either be wasting enormous amounts of storage space to save each number in a textual format that tries as good as possible to represent the floating point value, or you'd lose accuracy. Either way, converting the in-memory binary floats to text is CPU-intense and therefore usually not done, unless you really know that you need it. Even then, it's pretty reasonable to argue that, yes, although 1.148842E-3+j1.888888E-1 1.488875E-4+j1.000000E-3 is human-readable, having a million of these lines (and that's how I read "a lot of samples" that you mention) makes the data de-facto unreadable, not even mentioning navigatable, without graphical aids. Most people just import there samples later on e.g. into matlab -- but you wouldn't want to have textual numbers then, either (Matlab and Octave, as much as Python/numpy, and GNUplot can read binaries like the files produces by file sink directly). That being said, you can actually pretty simply convert the binary files produced by file sink to text using python. For example, save the following as a text file and run it as "python <name_of_scriptfile> <input_samples.dat> <output_samples.txt>" (untested, since written for this mail only): import numpy as np from sys import argv #complex64: 32bit float real, 32bit float imag #float32: as name suggests #int16: short int format = np.complex64 data = "" dtype=format) data.tofile(argv[2], sep='\n') On 10/15/2015 08:54 PM, Pedro Gabriel Adami wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |