Re: CSV file as input

[Marcus Müller]

Hi David,

you could write a quick python block that just reads values from the CSV file and outputs 
them. That'd be a very nice, basic exercise, and I think our freshly overhauled 
tutorials[1] should bring you there very quickly!
If you want help with that, hit us up in this mailing list (ideally after reading the 
tutorials up to the point of roughly understanding how to write (embedded) Python blocks), 
and tell us more about the data in your CSV files.

Alternatively, you could also write a converter of CSV to a format that GNU Radio by 
itself already has a reader for – and the main candidate here would probably just be plain 
raw data files (as e.g. numpy's `ndarray.tofile("filename")` does) – the File Source could 
directly read that. But with our freshly rewrite Wavfile sink and source blocks, we can 
write and read most audio files, just as well.

Then your flow graph could do the signal processing you want – e.g frequency translation, 
low-pass filtering… and finally output it to any device that you have a GNU Radio 
interface to (e.g., your sound card). The hardware runs at a sample rate – GNU Radio 
itself just tries to feed it as fast as possible. So, the signal processing in GNU Radio 
itself isn't concerned with rate at all!

Hope this helps,
Marcus

[1] https://tutorials.gnuradio.org

PS: you'll often find me online, recommending not to use CSV as a sample storage format. 
I'll do the same to you here, but not because I think it's in any way invalid to have data 
in CSV files; I just want to point out it might be worth thinking about using something 
else. So take this with a "I think it's pretty cool you're doing this!".

That has the reasons that
a) unless you're more restricted than "CSV" says, you don't know how many bits are there 
per sample, as numbers might be represented in different lengths, so seeking exactly only 
works by reading and understanding the whole file up to the point you seek to,
b) conversion of floating point numbers to human-readable form incurs rounding errors, and 
that can really wreck your day if you need to rerun *exactly* the same experiment twice,
c) printing numbers as text is really inefficient, both storage-wise as well as compute 
wise (which will only matter at higher sampling rates) and sometimes, but only sometimes,
( d) people say that CSV is good because it's human-readable, but I challenge anyone to 
read a text file with only 10000 values and be happier about that than if he used a tool 
that displayed the values graphically, zoomably, and then allows for inspection of single 
values once zoomed sufficiently in.)


On 18.03.22 04:55, david vanhorn wrote:
> I've done a little with Gnuradio a couple years ago, but I'd now like to apply it to a 
> serious problem.
>
> I have a design I'm working on that will output raw data that could be interpreted as an 
> audio stream centered on 1kHz.  I'd like to work on extracting CW signals that are rather 
> slow, from a rather narrow bandwidth, and see how far down into the noise I can actually 
> extract the signals.
>
> Is there a block that can bring in CSV data from a file at a specific rate, and serve as 
> the input to my CW detection system?
>
>
> --
> K1FZY (WA4TPW) SK  9/29/37-4/13/15