Hi! I'm trying to interface some radio hardware I built to GnuRadio by way of data captured to SD cards. I have two channels (I and Q) of 32 bit unsigned data internally, and I originally assumed CSV would be the easy path, but now I see it's not. Coming in through the PC sound card is not an option for me, I'm using a particular codec selected for the application, and my goal is to develop signal processing algorithms to then be implemented back on my processor in C or ASM.
I suppose it would be easiest if I rework my hardware to log data as if it were the "Signal Source" block with complex output. Where can I see what that looks like at the level of raw data? On Fri, Mar 18, 2022 at 4:59 AM Marcus Müller <mmuel...@gnuradio.org> wrote: > 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 > > -- K1FZY (WA4TPW) SK 9/29/37-4/13/15