Re: Taylor detector

[david vanhorn]

Because in GR I can generate impaired signals approximating real world
conditions, with fine control and repeatability.
I can then run that through the Tayloe while experimenting with it's
variables, again with fine control and repeatability.
Finally I can work with DSP on the output of the Tayloe, observing the
total system response.



On Sat, Aug 13, 2022 at 4:38 AM Steve Hubbard 
wrote:

> Hi,
>
> It's not clear to me why you would want to do this. As far as I can see,
> the purpose of a Tayloe detector is to mix a real-valued RF signal with
> a complex-valued local oscillator to arrive at an intermediate frequency
> at or near zero frequency that can be sampled using a sound card. If
> you're using GR the implication is that the signal has already been
> sampled.
>
> An ideal hardware IQ mixer would be a pair of analogue multipliers with
> sine local oscillators. However, this is not practical if good linearity
> is required (linearity is desirable to avoid intermodulation distortion
> and other nasty things). This is why switches are used. The switches
> used to be diodes, and still are at higher frequencies, but at HF CMOS
> analogue switches work better. With a switch based mixer you are
> effectively multiplying by a square wave, which comes with the
> disadvantage that odd harmonics of the square local oscillator also
> convert signals and noise into the IF. This necessitates a filter in
> front of the mixer to suppress these spurious responses. When IQ mixing
> is required there are the added challenges of phase and amplitude
> balance. Sometimes things ain't pretty in the analogue world.
>
> As has already been pointed out, in GR a complex multiplier is the usual
> way to go. An accurate multiplier can be fed with near perfect
> numerically generated sine waves with perfect amplitude and phase
> balance. Besides, even if you wanted to simulate a square wave local
> oscillator in DSP you'd have to approximate by only including the
> harmonics up to the Nyquist frequency.
>
> On 13/8/22 03:08, david vanhorn wrote:
> > Ive been wrestling with this for a while, and im not even seeing how
> > to get started implementing a Taylor detector in gr.
> >
> > Is it even possible?
>
>

-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15

Re: Taylor detector

[david vanhorn]

Well, I'm sitting here recovering from open heart surgery for the next two
months, and I've always wanted to tackle this little problem.
Seems a bit scary though with all the moving parts.


On Fri, Aug 12, 2022 at 2:21 PM Nick Foster  wrote:

> David,
>
> OK, I see what you're after now. Gnuradio isn't a SPICE simulator, so
> getting it to fully represent your Tayloe mixer isn't really feasible.
> Maybe the easiest way to accomplish what you're looking to do would be to
> quantify the performance of your LTSpice simulation in a model of a
> quadrature mixer that incorporates error parameters corresponding to your
> mixer's simulated performance. In other words, make a Gnuradio block which
> performs the job of the mixer, while adding the noise and nonlinearities
> observed in your model -- conversion loss, thermal noise, and IQ imbalance,
> for example. What you'd be missing is the end-to-end loop closure that lets
> you make changes to the SPICE model and evaluate them easily.
>
> You could also use GR to construct a synthetic transmission, like you
> suggest, write it to disk, and convert it to a time series format that
> LTSpice can ingest. I know that LTSpice's RAW data format is documented,
> and it looks like there are a couple of Python packages which read and
> write it. Because you can run LTSpice in batch mode, it's conceivable that
> you could automate the whole process in Python -- generate a test signal,
> write it to RAW, run it through LTSpice in batch mode, convert the
> resulting RAW to a complex floating-point IQ signal Gnuradio can read, and
> process it to extract performance parameters in Gnuradio again. Supposedly
> there's also a Python LTSpice integration
> <https://acidbourbon.wordpress.com/2019/11/26/seamless-integration-of-ltspice-in-python-numpy-signal-processing/>
> that lets you do everything in Python, in which case you could make a
> Python GR block that would just execute LTSpice from within the block
> itself, in which case you could get really funky with parameter sweeps and
> such.
>
> Sounds like a fun project! If you do write such an integration, please
> consider releasing it to the community as well.
>
> Nick
>
> On Fri, Aug 12, 2022 at 12:14 PM david vanhorn  wrote:
>
>> I have built the detector in ltspice, but i was hoping to use gr to do a
>> "soup to nuts" sim with multiple transmitters and various noise sources,
>> feed that into the Tayloe, and then see what I could do downline from there
>> to recover my signals.
>>
>> On Fri, Aug 12, 2022, 12:43 PM Marcus D. Leech 
>> wrote:
>>
>>> On 2022-08-12 13:38, david vanhorn wrote:
>>> > Ive been wrestling with this for a while, and im not even seeing how
>>> > to get started implementing a Taylor detector in gr.
>>> >
>>> > Is it even possible?
>>> You mean a *Tayloe* Quadrature Sampling Detector?
>>>
>>> This is ordinarily a *hardware component* of certain types of HF
>>> direct-conversion receivers.
>>>
>>> Gnu Radio isn't, primarily, a hardware simulation environment, although
>>> it is the case that many DSP transforms
>>>have hardware analogues, it's not really a hardware simulator.
>>>
>>> It's probably best to tell us what you actually want to achieve, because
>>> unless it's really "simulate a Tayloe QSD",
>>>it's unlikely that building a Tayloe QSD in Gnu Radio is really going
>>> to be that useful...
>>>
>>>
>>>
>>>

-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15

Re: Taylor detector

[david vanhorn]

I have built the detector in ltspice, but i was hoping to use gr to do a
"soup to nuts" sim with multiple transmitters and various noise sources,
feed that into the Tayloe, and then see what I could do downline from there
to recover my signals.

On Fri, Aug 12, 2022, 12:43 PM Marcus D. Leech 
wrote:

> On 2022-08-12 13:38, david vanhorn wrote:
> > Ive been wrestling with this for a while, and im not even seeing how
> > to get started implementing a Taylor detector in gr.
> >
> > Is it even possible?
> You mean a *Tayloe* Quadrature Sampling Detector?
>
> This is ordinarily a *hardware component* of certain types of HF
> direct-conversion receivers.
>
> Gnu Radio isn't, primarily, a hardware simulation environment, although
> it is the case that many DSP transforms
>have hardware analogues, it's not really a hardware simulator.
>
> It's probably best to tell us what you actually want to achieve, because
> unless it's really "simulate a Tayloe QSD",
>it's unlikely that building a Tayloe QSD in Gnu Radio is really going
> to be that useful...
>
>
>
>

Taylor detector

[david vanhorn]

Ive been wrestling with this for a while, and im not even seeing how to get
started implementing a Taylor detector in gr.

Is it even possible?

Re: CSV file as input

[david vanhorn]

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 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.com/en/products/detail/everlight-electronics-co-ltd/PLT237-T10WH/14641724
> ,
> https://www.tme.eu/en/details/fcr6842031t/optical-connectors/cliff/otj-1-fcr6842031t/
> [2]
> https://www.tme.eu/en/details/fcr6842032r/optical-connectors/cliff/orj-3-fcr6842032r/
>
> On 18.03.22 19:53, Marcus D. Leech wrote:
> > 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
> regression testing.
> >>
> > Yeah, I thought that your architecture was probably driven by noise
> concerns--630M would
> > not be a "forgiving" band in this regard.  I will point out, just as an
> FYI,
> >that USB-over-fiber extenders do exist, but because they're rather
> "niche", they're not
> > cheap at all
> >
> >
> >>
> >> On Fri, Mar 18, 2022 at 12:32 PM Marcus Müller 
> wrote:
> >>
> >> 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 work as well to get the data
> into your PC. If
> >> your
> >> ARM does have USB2 built-in, then that would also be a rather cool
> thing, but
> >> knowing the
> >> varying quality of chip vendor USB hardware abstractions, that
> might or might not be
> >> easy
> >> to implement :) In both cases, UART/SPI serial output converted to
> USB, or native USB,
> >> you'd probably have to afterwards write a schmall C/C++ driver, so
> that SoapySDR or GNU
> >> Radio directly can talk to it.)
> >>
> >> Cheers,
> >> Marcus
> >>
> >> On 18.03.22 19:26, david vanhorn wrote:
> >> > 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
> >> > <mailto: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

Re: CSV file as input

[david vanhorn]

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-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
> regression testing.
>
> Yeah, I thought that your architecture was probably driven by noise
> concerns--630M would not be a "forgiving" band in this regard.  I will
> point out, just as an FYI,
>   that USB-over-fiber extenders do exist, but because they're rather
> "niche", they're not cheap at all
>
>
>
> On Fri, Mar 18, 2022 at 12:32 PM Marcus Müller 
> wrote:
>
>> 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 work as well to get the data into
>> your PC. If your
>> ARM does have USB2 built-in, then that would also be a rather cool thing,
>> but knowing the
>> varying quality of chip vendor USB hardware abstractions, that might or
>> might not be easy
>> to implement :) In both cases, UART/SPI serial output converted to USB,
>> or native USB,
>> you'd probably have to afterwards write a schmall C/C++ driver, so that
>> SoapySDR or GNU
>> Radio directly can talk to it.)
>>
>> Cheers,
>> Marcus
>>
>> On 18.03.22 19:26, david vanhorn wrote:
>> > 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 > > <mailto: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.
>

Re: CSV file as input

[david vanhorn]

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:32 PM Marcus Müller 
wrote:

> 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 work as well to get the data into
> your PC. If your
> ARM does have USB2 built-in, then that would also be a rather cool thing,
> but knowing the
> varying quality of chip vendor USB hardware abstractions, that might or
> might not be easy
> to implement :) In both cases, UART/SPI serial output converted to USB, or
> native USB,
> you'd probably have to afterwards write a schmall C/C++ driver, so that
> SoapySDR or GNU
> Radio directly can talk to it.)
>
> Cheers,
> Marcus
>
> On 18.03.22 19:26, david vanhorn wrote:
> > 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  > <mailto: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>
> >  > <mailto: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 (embed

Re: CSV file as input

[david vanhorn]

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 
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  > <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 poi

Re: CSV file as input

[david vanhorn]

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  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

CSV file as input

[david vanhorn]

 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

Re: explaining i/q

[david vanhorn]

"Twice the bandwidth" but that doesn't account for the 0 Hz "hole" where
the incoming signal is exactly at the sampling rate.
Or am I missing something?

On Wed, Nov 4, 2020 at 3:28 PM Fons Adriaensen  wrote:

> On Wed, Nov 04, 2020 at 05:14:00PM +0100, Kristoff wrote:
>
> > For us, "even if we would be able to look at a rotating object up-front
> and
> > from a 90 degrees angle at the same time, if the object would be frozen
> in
> > time we would still not be able to determine if the doll rotates left of
> > right".
>
> The way complex samples are treated in theory means that the I and Q
> parts refer to the same time, They are considered to be a single
> sample having a complex value.
>
> But you can never detect rotation (or a frequency in DSP terms) from
> a single sample, be it real or complex. You always need a sequence.
>
> A sequence of real valued samples (either I or Q separately) allows
> you to detect the rotation, but the sense remains ambiguous. Having
> both the I and Q sequences resolves that ambiguity.
>
> You could object that using complex samples requires twice the
> memory for the same sample rate, since every sample consists of
> two numerical values. But since you can now separate positive
> and negative frequencies, you get twice the bandwidth as well.
> So there is no penalty for using complex signals.
>
> --
> FA
>
>
>

-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15

Re: explaining i/q

[david vanhorn]

You can lead a horse to water...

Then there's hams like this: https://g3rbj.co.uk/


On Wed, Nov 4, 2020 at 12:04 PM Kristoff  wrote:

> Don,
>
>
> A small (slightly) remark about this video, and about hams.
>
> When I gave my first video-presentation for the Belgian SDR Meetup (in
> September), I have a presentation on GR (an example of an RTTY decoder).
> But, to keep the presentation on topic, I first posted a "list of
> interesting things to view so you can better understand the
> presentation" (the video you mentioned, three of the videos by Michael
> Ossmann, ...).
>
> When I asked the audience during the presentation who had taken the time
> to actually do this, I did not get any positive answers.
>
> You know,, ...last time when we did a workshop in a hackerspace on a
> certain topic and asked the people to do some preparation, I think that
> more then 3/4 did do that.
> The same when I organise a workshop at work.
>
>
> Yeah ... Hams .. (sigh) :-(
>
>
>
> 73
> kristoff - ON1ARF
>
>
> On 4/11/2020 15:22, Don Wade wrote:
> > Here’s a YouTube video that’s got a bit of pencil math (so it doesn’t
> > drone on) and oscilloscopes (for the ham guys), so it’s got a bit for
> > everyone .
> >
> >
> https://m.youtube.com/watch?list=PLvOgjCaG0WzDAF1Um894vv95mrcyortOB=h_7d-m1ehoY
> >
> >> On Nov 4, 2020, at 7:52 AM, Kristoff  wrote:
> >>
> >> Jef,
> >>
> >>
> >> Concerning the term "slope". Well, I also have my doubts about it. I
> >> think that for a lot of people, this would create the assumption that
> >> the signal then goes from the 'i' value to the 'q' value in a
> >> straight line, which is -as we know- not the case.
> >>
> >> Sometimes it helps to -at first- give a very basic mental image of
> >> something, and -at the end, when people understand the topic-
> >> "correct" that image with a more correct one, or just point them to
> >> some youtube video that explains the topic in more detail.
> >>
> >>
> >> Anycase,this is indeed all an interesting exercise in braking down
> >> concepts into very small steps.
> >>
> >> The amateur-radio community is a bit strange as most people do have a
> >> technical background, but for a large number of hams, that is mainly
> >> based on assumptions or "that's what they said in the ham-radio
> >> courses", without understanding the full technical details,
> >> especially topics that are highly based on math.
> >> For most hams, "SDR" is just "that piece of software you install on
> >> your computer to look at  waterfall graphs".
> >>
> >> So we have a very long way to go. :-)
> >>
> >>
> >> 73
> >> kristoff - ON1ARF
> >>
> >>
> >>
> >> On 4/11/2020 02:21, Jeff Long wrote:
> >>> It's more important to give people some mental picture than to make
> >>> sure it's completely correct. But, I would not use the "slope"
> >>> terminology. The important things are, as you've said, (1) with the
> >>> complex type, you can have a signal at baseband that is not
> >>> symmetric, and (2) the price for this is doubling the amount of data
> >>> needed. The signal you deal with at baseband is the same signal that
> >>> is seen centered on the RF carrier.
> >>>
> >>> I don't see a great way to talk about "phase" without going into the
> >>> math. It is important to get into "phase" when you talk about any
> >>> modulation fancier than slow FSK.
> >>>
> >>> Good luck. Hope you find the right balance between useful,
> >>> digestible, and correct.
> >>>
> >>> On Tue, Nov 3, 2020 at 7:20 PM David Hagood  >>> > wrote:
> >>>
> >>>I am sorrowful that you have decided you are going to stick with an
> >>>explanation that is fundamentally incorrect. I know how direct
> >>>conversion systems work - I design the software for them for a
> >>>living.
> >>>What you are basing your mental model on is an optimization for
> >>>the case
> >>>where the system is both sub-sampling the signal and going digital
> in
> >>>the same operation. However, in many extremely high sample rate
> >>>systems,
> >>>the signal is brought down to baseband by mixing it with analog
> >>>quadrature signals - that's the place where I and Q come from - and
> I
> >>>assure you the only "delay by 90 degrees" is in the creation of the
> >>>quadrature LO signals, not in the sampling of the actual data. But
> >>>I've
> >>>been around the Sun enough times to know that since you have decided
> >>>upon this course and don't seem to want to change, there's no
> >>>point in
> >>>continuing to try to help.
> >>>
> >>>
> >>
> >>
>
>

-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15

Re: [Discuss-gnuradio] Moving my antenna

[david vanhorn]

It would be very helpful to know the main frequency of interest.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Sdrplay rsp2pro on Windows 10

[david vanhorn]

I have seen a lot of links and tried a lot of downloads. My hw works but
sofar osmocom does not see the device. I assume that means I have not found
the real driver I need.   Does anyone have this working on Windows, and can
I get a pointer to the working driver?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving average

[david vanhorn]

So how would you represent this expression so that it evaluates as floating
point:
As the "Delay" variable in a delay block:  Phase * (SampleRate/360)


On Tue, Jan 22, 2019 at 5:59 AM david vanhorn  wrote:

> Nope.
>
> 1/Averaging evaluates to zero.
> 1/Averaging. (trailing period) does not evaluate, either in the Moving
> Average parameters, or as a separate variable.
>
>
> On Mon, Jan 21, 2019 at 11:00 PM Cinaed Simson 
> wrote:
>
>> 1/5 is zero using integer division in python.
>>
>> Try using float division
>>
>>  1/4000.
>>  1/5.
>>
>> -- Cinaed
>>
>>
>> On 1/21/19 4:41 PM, david vanhorn wrote:
>> > The docs say that I need to set Scale to the inverse of the Length.
>> > Ok, I interpret that as Length = 4000 and Scale = 1/4000
>> > The docs here:
>> >
>> https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1moving__average__ff.html
>> > says that Scale is a float.
>> >
>> > The discussion here clearly shows Scale working for values <1 and >0
>> >
>> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00084.html
>> >
>> > If I enter a scale value by hand, like 0.2, then I see 200m which is
>> > what I expect.
>> > If I enter a scale value as (1/5) then I see 0.
>> > If I set a variable called "Scale" = (1/) and enter "Scale" in the Scale
>> > field of the moving average, it evaluates to 0.
>> >
>> >
>> > When I enter the values in the block, it looks like scale is an int,
>> > which makes 1/4000 or indeed 1/(>1) problematic in that it always
>> > evaluates to zero, which kinda breaks things.
>> > When I enter 1/2 I get "0"
>> >
>> > When I hover over the field to enter Scale, I get Type Real.
>> >
>> > I have the input and output of my integrator connected to a QT GUI Time
>> > Sink, and while the input waveform is what I expect, if I have any <1
>> > Scale parameter, the output is 0.
>> >
>> >
>> > Is something broken here, or is it me?
>> > I've not had any problems using simple math in any of the other fields
>> > where appropriate.
>> >
>> >
>> > --
>> > K1FZY (WA4TPW) SK  9/29/37-4/13/15
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> --
> K1FZY (WA4TPW) SK  9/29/37-4/13/15
>


-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Moving average

[david vanhorn]

Nope.

1/Averaging evaluates to zero.
1/Averaging. (trailing period) does not evaluate, either in the Moving
Average parameters, or as a separate variable.


On Mon, Jan 21, 2019 at 11:00 PM Cinaed Simson 
wrote:

> 1/5 is zero using integer division in python.
>
> Try using float division
>
>  1/4000.
>  1/5.
>
> -- Cinaed
>
>
> On 1/21/19 4:41 PM, david vanhorn wrote:
> > The docs say that I need to set Scale to the inverse of the Length.
> > Ok, I interpret that as Length = 4000 and Scale = 1/4000
> > The docs here:
> >
> https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1moving__average__ff.html
> > says that Scale is a float.
> >
> > The discussion here clearly shows Scale working for values <1 and >0
> >
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00084.html
> >
> > If I enter a scale value by hand, like 0.2, then I see 200m which is
> > what I expect.
> > If I enter a scale value as (1/5) then I see 0.
> > If I set a variable called "Scale" = (1/) and enter "Scale" in the Scale
> > field of the moving average, it evaluates to 0.
> >
> >
> > When I enter the values in the block, it looks like scale is an int,
> > which makes 1/4000 or indeed 1/(>1) problematic in that it always
> > evaluates to zero, which kinda breaks things.
> > When I enter 1/2 I get "0"
> >
> > When I hover over the field to enter Scale, I get Type Real.
> >
> > I have the input and output of my integrator connected to a QT GUI Time
> > Sink, and while the input waveform is what I expect, if I have any <1
> > Scale parameter, the output is 0.
> >
> >
> > Is something broken here, or is it me?
> > I've not had any problems using simple math in any of the other fields
> > where appropriate.
> >
> >
> > --
> > K1FZY (WA4TPW) SK  9/29/37-4/13/15
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Moving average

[david vanhorn]

The docs say that I need to set Scale to the inverse of the Length.
Ok, I interpret that as Length = 4000 and Scale = 1/4000
The docs here:
https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1moving__average__ff.html
says that Scale is a float.

The discussion here clearly shows Scale working for values <1 and >0
https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00084.html

If I enter a scale value by hand, like 0.2, then I see 200m which is what I
expect.
If I enter a scale value as (1/5) then I see 0.
If I set a variable called "Scale" = (1/) and enter "Scale" in the Scale
field of the moving average, it evaluates to 0.


When I enter the values in the block, it looks like scale is an int, which
makes 1/4000 or indeed 1/(>1) problematic in that it always evaluates to
zero, which kinda breaks things.
When I enter 1/2 I get "0"

When I hover over the field to enter Scale, I get Type Real.

I have the input and output of my integrator connected to a QT GUI Time
Sink, and while the input waveform is what I expect, if I have any <1 Scale
parameter, the output is 0.


Is something broken here, or is it me?
I've not had any problems using simple math in any of the other fields
where appropriate.


-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Removing obsolete Heir blocks from my list

[david vanhorn]

THANK YOU!

Not only did that get rid of my obsolete heir blocks, but I took a chance
and deleted the code for the other heir blocks and re-generated them, and
now my seemingly bizarre errors are gone and things are working as well as
expected at this point.  I will keep this in mind, it looks from my limited
perspective, like the heir blocks don't necessarily get completely rebuilt
when a change is made.
I have the old heir block code preserved in case that's interesting.

On Mon, Jan 21, 2019 at 1:41 PM Michael Dickens 
wrote:

> Do you mean the "compiled" Python and GRC scripts? Look in
> "~/.grc_gnuradio/" and find the correct .py and .xml or .yml files & "rm"
> them. Not sure what else you might mean, so hopefully this helps! - MLD
>
> On Mon, Jan 21, 2019, at 3:14 PM, david vanhorn wrote:
>
> I've created some heir blocks, and now I have some that I'd like to remove
> from my list as they are obsolete.
>
> How do I remove them?
>
> --
> K1FZY (WA4TPW) SK  9/29/37-4/13/15
> *___*
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Removing obsolete Heir blocks from my list

[david vanhorn]

I've created some heir blocks, and now I have some that I'd like to remove
from my list as they are obsolete.

How do I remove them?

-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Output port problem?

[david vanhorn]

Error message "destination port 0 out of range for QSD Summing Amplifier(7)"

This heir has a pad source with four float streams and a pad sink with one
complex stream.
Everything is float, and everything is connected.
I assume the error above is talking about the pad sink.

ID pad_sink_0
Label out
Input type complex
Vec length 1
Num streams 1
Optional required

There's not all that much to configure here, what am I doing wrong?



-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tracking down error messages

[david vanhorn]

I have created some heir blocks from the blocks that come with the program.
Nothing in C.

I tracked it down to my clock heir, which has only a signal source, three
delays, and a four terminal output pad sink.
I do notice what when I place the output pad sink the 0 terminal is white
even though I have set the block to float. After a couple of runs, the 0
terminal changes to the correct color.


On Sun, Jan 20, 2019 at 5:40 AM Michael Dickens 
wrote:

> Are any of your hier blocks written in c++? If so, are you trying to
> intermix in any of these such blocks both a flowgraph as well as ‘work’ of
> any kind? Although one shouldn’t be able to create such a hier block —
> their intent is just to encapsulate a flowgraph — the GR API allows one to
> program this dual use block. The c++ will compile, but it will fail runtime
> execution . I don’t recall the exact error message, but it’s something like
> what you reported , hence my wondering. We should really get this fixed in
> some forthcoming GR release. Hope this is useful! - MLD
>
> On Sat, Jan 19, 2019, at 11:43 PM, david vanhorn wrote:
>
> I am only a couple days into this, with a project that has several heir
> blocks.
> I just started getting a message "port number 0 exceeds max of (none)"
>
> I've looked through my files, and I don't see any unconnected ports.
> I don't see anything that indicates even which file or heir block is
> causing the problem.
> How can I track this down?
>
> --
> K1FZY (WA4TPW) SK  9/29/37-4/13/15
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Tracking down error messages

[david vanhorn]

I am only a couple days into this, with a project that has several heir
blocks.
I just started getting a message "port number 0 exceeds max of (none)"

I've looked through my files, and I don't see any unconnected ports.
I don't see anything that indicates even which file or heir block is
causing the problem.
How can I track this down?

-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio