I'm using a PCB that I designed with an ARM chip, codec, and SD card for logging, as my data capture platform. Feeding that is a QSD (Tayloe) front end that I designed, specifically for the 630m ham band, converting down to 1kHz differential I and Q signals to the codec, which has a 105dB SNR. The front end appears to have a 90dB linear dynamic range so far as I can measure with my equipment. I'll improve that if I can. Once I capture to SD, then I can pull the SD and process on the PC to develop weak signal detection.
On Fri, Mar 18, 2022 at 12:12 PM Marcus Müller <mmuel...@gnuradio.org> wrote: > 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 > -- K1FZY (WA4TPW) SK 9/29/37-4/13/15
