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
>
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
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
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]
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.
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo
