Hey :)
CSV might or might not be convenient, but if C or assembler is your tool: The things that
the GNU Radio file source reads or the file sink writes is exactly what you get when you
take a buffer of samples and do an `fwrite` on that :) Just a dump of the raw memory to a
file. 32 bit unsigned should be directly digestible by GNU Radio (even if there were
endianness issues – you can just read as bytes and reshuffle as needed :)).
I didn't fully get how you're currently interfacing your hardware. Care to explain in a
bit more breadth? What are the components of your system, and how does the computer
running GNU Radio relate?
Best and slightly excited regards,
Marcus
On 18.03.22 18:37, david vanhorn wrote:
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
<mailto: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 <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
