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 (ideal
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 opti
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 unsig
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
Ah cool! Thanks for clarifying :) This sounds to be a rather nice setup,
analog-wise!
Yeah, then just dumping the raw 32bit unsigned to SD Card is probably easiest.
(by the way, this is << 1Mb/s, so just dumping the raw data over a UART or SPI interface
to some serial-to-USB converter might wo
Noise is always an issue. I could do a serial port over USB, or TTL USART,
but I thought that the SD card would be the most quiet, not requiring any
electrical connection to the PC.
It also means that I automatically have my recordings available for
regression testing.
On Fri, Mar 18, 2022 at 12
On 2022-03-18 14:48, david vanhorn wrote:
Noise is always an issue. I could do a serial port over USB, or TTL
USART, but I thought that the SD card would be the most quiet, not
requiring any electrical connection to the PC.
It also means that I automatically have my recordings available for
re
Yeah, I have one. The distal end still makes noise. Better at galvanic
isolation. It does prevent the PC noise from propagating down the cable.
I did think about using Toslink but that just seemed like another
can-o-worms.
On Fri, Mar 18, 2022 at 12:54 PM Marcus D. Leech
wrote:
> On 2022-03-1
On 2022-03-18 15:23, david vanhorn wrote:
Yeah, I have one. The distal end still makes noise. Better at
galvanic isolation. It does prevent the PC noise from propagating
down the cable.
I did think about using Toslink but that just seemed like another
can-o-worms.
Not at all surprising. Gett
Like the reproducibility aspect of going for storage, but it means no live signal
observation :)
Just for future hardware ideas: with these bitrates, you should be well in range of what
the cheaper TOLSLINK optical transmitter modules [1] and receivers [2] could do.
[1]
https://www.digikey.c
As I develop my software, I'll implement in the ARM, and it will be able to
work live.
On Fri, Mar 18, 2022 at 2:25 PM Marcus Müller wrote:
> Like the reproducibility aspect of going for storage, but it means no live
> signal
> observation :)
>
> Just for future hardware ideas: with these bitrat
Gotta say, yours sounds like a cool project. In case you (or really, anyone) want to write
up something fun for the blog on gnuradio.org, do let us know.
Since this is for a ham band: we did use to have monthly ham meeting group[1], where aside
from a strong community/social aspect, we also had
On Fri, Mar 18, 2022 at 07:12:37PM +0100, Marcus Müller wrote:
> 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
> t
13 matches
Mail list logo
