Re: Taylor detector

[Albin Stigö]

It's possible to simulate a Tayloe detector in gnuradio. Probably this
would involve stream demux block, filters, negate and sum.

Ie. there's no "capacitor" block. You will need to think in terms of
functions.

On Sat, Aug 13, 2022, 20:57 david vanhorn  wrote:

> 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: Low sample rate hardware

[Albin Stigö]

For low budget modify the low pass filter of a sound card.

On Wed, Feb 9, 2022, 15:27 vitt...@pm.me  wrote:

> Good evening everybody
> I'm looking for a sampling device, GNURADIO compatible,  with low sample
> rate ( max 50 KHz ) AND frequency response down to 1 Hz, so sound cards
> aren't the choice.
> Any suggestion ???
> Tnx in advance :-)
>
> Vittorio
>
>
> fingerprint: fb5f492a54e016c632c933d3ee4b7e38203c79ca
>
> Sent with ProtonMail  Secure Email.
>
>

Re: VOLK C++ core

[Albin Stigö]

I like the idea. It will make it difficult to use volk with other
language's FFI though.

--Albin

On Tue, Dec 21, 2021, 12:27 Marcus Müller  wrote:

> Hi Johannes,
>
> I, for one, like it :) Especially since I honestly find void
> volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny bit
> clunky and would
> rather call a type-safe, overloaded function in a volk namespace called
> multiply_conjugate_add.
>
> Re: RFC: can we have something like a wiki page (maybe on the VOLK repo?)
> to collect these
> comments?
>
> You mention spans, so C++-VOLK would be >= C++20?
>
> Cheers,
> Marcus
>
> On 21.12.21 10:55, Johannes Demel wrote:
> > Hi everyone,
> >
> > today I'd like to propose an idea for the future of VOLK. Currently,
> VOLK is a C library
> > with a C++ interface and tooling that is written in C++.
> >
> > I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a
> C interface if
> > the need arises.
> >
> > This email serves as a request for comments. So go ahead.
> >
> > Benefits:
> > - sane std::complex interface.
> > - same compilation mode on all platforms.
> > - Better dynamic kernel load management.
> > - Option to use std::simd in the future
> > - Less manual memory management (think vector, ...).
> >
> > Drawbacks:
> > - It is a major effort.
> > - VOLK won't be a C project anymore.
> >
> > Why do I propose this shift?
> > VOLK segfaults on PowerPC architectures. This issue requires a breaking
> API change to be
> > fixable. I tried to update the API to fix this isse.
> > https://github.com/gnuradio/volk/pull/488
> > It works with GCC and Clang but fails on MSVC.
> > One might argue that PowerPC is an obscure architecture at this point
> but new
> > architectures might cause the same issue in the future. Also, VOLK tries
> to be portable
> > and that kind of issue is a serious roadblock.
> >
> > How did we get into this mess?
> > The current API is a workaround to make things work for a specific
> compiler: MSVC. MSVC
> > does not support C `complex.h` at all. The trick to make things work
> with MSVC is:
> > compile VOLK in C++ mode and pretend it is a C++ library anyways.
> > In turn `volk_complex.h` defines complex data types differently
> depending if VOLK is
> > included in C or C++. Finally, we just hope that the target platform
> provides the same
> > ABI for C complex and C++ complex. C complex and C++ complex are not
> compatible.
> > However, passing pointers around is.
> > Thus, the proposed change does not affect Windows/MSVC users because
> they were excluded
> > from our C API anyways. The bullet point: "same compilation mode on all
> platforms"
> > refers to this issue.
> >
> > Proposed timeline:
> > Together with our re-licensing effort, we aim for a VOLK 3.0 release.
> VOLK 3.0 is a good
> > target for breaking API changes.
> >
> > Effects:
> > I'd like to make the transition to VOLK 3.0 as easy as possible. Thus,
> I'd like to keep
> > an interface that hopefully doesn't require any code changes for VOLK
> 2.x users. A
> > re-built of your application should be sufficient. However, we'd be able
> to adopt a
> > C++-ic API as well. e.g. use vectors, spans etc.
> >
> > The current implementation to detect and load the preferred
> implementation at runtime is
> > hard to understand and easy to break. C++ should offer more accessible
> tools to make
> > this part easier.
> >
> > What about all the current kernels?
> > We'd start with a new API and hide the old kernel code behind that
> interface. We come up
> > with a new implementation structure and how to load it. Thus, we can
> progressively
> > convert to "new-style" implementations.
> >
> > Another bonus: std::simd
> > Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib
> would allow us to
> > eventually use std::simd in VOLK and thus make Comms DSP algorithms more
> optimized on
> > more platforms.
> >
> > Cheers
> > Johannes
> >
>
>

Re: Does complex conjugate invert IQ ?

[Albin Stigö]

This might be of interest.

https://www.dsprelated.com/showarticle/51.php


--Albin

On Mon, Dec 13, 2021, 16:45 Cyrille Morin 
wrote:

> Hi,
>
> You could use a "Complex to Float" to separate the I and Q components,
> followed by a "Float to Complex", inverting the re and im inputs.
>
>
> Le 13/12/2021 à 16:31, Rachida SAROUI a écrit :
>
> Thank you for responding, but what I meant by invert is swapping the I
> and Q components of the signal.
>
> Le lun. 13 déc. 2021 à 16:25, Fabian Schwartau  a
> écrit :
>
>> Complex conjugate only inverts the imaginary (Q) part of the signal.
>> If you want to invert both, just multiply with -1.
>>
>> Am 13.12.21 um 16:22 schrieb Rachida SAROUI:
>> > Hi everyone,
>> >
>> > I need to invert the I and Q of a complex signal. Does the block
>> complex
>> > conjugate do the job?
>> >
>> > Thank you
>> >
>>
>>
>>

Re: GNU Radio on Raspberry Pi 4?

[Albin Stigö]

There's no special configuration. Just install dependencies and build from
source. Put root on SSD or it will be very slow. Ubuntu 65bit is fine. In
general GNURadio is hell to build and get dependencies right, but in the
end it works well.

--Albin

On Thu, Dec 17, 2020, 16:37 Kristoff  wrote:

> Albin,
>
>
> Can you share your configuration for this? Do you need to set up
> something special?
> Can you do this on standard ubuntu 64 bit (20.04LTS or 20.10) on a pi4b
> or do you need another distro for this?
>
>
> I read somewhere opengl on the pi4 has not been released yes as it has
> the pi4 has a more recent GPU.
> Or am I completely wrong?
>
>
> 73
> kristoff - ON1ARF
>
>
> On 17/12/2020 1:22 p.m., Albin Stigö wrote:
> > I suspect a lot of the graphics could run perfectly fine if they took
> > advantage of the gpu better. A lot of the current rendering in
> > GNURadio (and GQRX) is very cpu bound.
> >
> > I had a spectrum and waterfall running easily at 60fps on a pi3 by
> > using opengl properly. Using vulkan on pi4 the sky is the limit.
> >
> > --Albin
> >
> > On Thu, Dec 17, 2020, 13:18 Marcus Müller  > <mailto:muel...@kit.edu>> wrote:
> >
> > Can't stress this enough. Running a 32 bit Linux on a RPi 4 would be
> > like running Windows 98 on a modern PC and expecting top performance
> > from the CPU. You're not making use of the CPU you have, you're only
> > making use of a legacy mode that it still supports.
> >
> > Best regards,
> > Marcus
> >
> > On 17.12.20 10:53, Albin Stigö wrote:
> > > 64bit mode is most likely better because in addition to being
> > 64bit it
> > > enables additional cpu features (certain new instructions and
> > more SIMD
> > > NEON registers)
> > >
> > > On Thu, Dec 17, 2020, 10:36 jean-michel.fri...@femto-st.fr
> > <mailto:jean-michel.fri...@femto-st.fr>
> > > <mailto:jean-michel.fri...@femto-st.fr
> > <mailto:jean-michel.fri...@femto-st.fr>>
> >  > <mailto:jean-michel.fri...@femto-st.fr>
> > > <mailto:jean-michel.fri...@femto-st.fr
> > <mailto:jean-michel.fri...@femto-st.fr>>> wrote:
> > >
> > > The benchmark on volk/64 bit kernel v.s 32 bit Raspbian is at
> > > https://pubs.gnuradio.org/index.php/grcon/article/view/73/55
> > > <https://pubs.gnuradio.org/index.php/grcon/article/view/73/55>
> > > last page. I get 3 to 7-fold improvement by volk_config on a
> > dedicated
> > > toolchain for 64-bit CPU.
> > >
> > > JM
> > >
> > > --
> > > JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe,
> > 25000
> > > Besancon, France
> > >
> > > December 17, 2020 10:28 AM, "Kristoff"  > <mailto:krist...@skypro.be>
> > > <mailto:krist...@skypro.be <mailto:krist...@skypro.be>>>
> wrote:
> > >
> > > > HI all,
> > > >
> > > > I also have a RPi4 (*).
> > > > Some follow-up question.
> > > >
> > > > What OS would be the best for this?
> > > > Would running 64 bit make a difference?
> > > >
> > > > I don't know to what degree this is related, but I did a
> > test running
> > > > WebGL (**) on that pi, and I got about 1/3 of the frames per
> > > second on
> > > > my RPi4 compared to my laptop (which only has a UHD
> > Graphics 630
> > > Mobile,
> > > > so not the  best or latest neither)
> > > > Is the GPU in the Pi4 good enough to run many GUI elements
> > in GNU
> > > Radio
> > > > at the same time?
> > > >
> > > > Kr.
> > > >
> > > > (*) RPi4B 8 GB, 120 SSD
> > > >
> > > > (*) https://webglsamples.org <https://webglsamples.org>
> > > >
> > > > On 16/12/2020 11:10 p.m., Dan Romanchik KB6NU wrote:
> > > >
> > > >> Has anyone successfully run GNU Radio on a Pi 4? I
> > recently purchased
> > > >> an RTL-SDR dongle and thought it would be fun to
> > experiment 

Re: GNU Radio on Raspberry Pi 4?

[Albin Stigö]

I suspect a lot of the graphics could run perfectly fine if they took
advantage of the gpu better. A lot of the current rendering in GNURadio
(and GQRX) is very cpu bound.

I had a spectrum and waterfall running easily at 60fps on a pi3 by using
opengl properly. Using vulkan on pi4 the sky is the limit.

--Albin

On Thu, Dec 17, 2020, 13:18 Marcus Müller  wrote:

> Can't stress this enough. Running a 32 bit Linux on a RPi 4 would be
> like running Windows 98 on a modern PC and expecting top performance
> from the CPU. You're not making use of the CPU you have, you're only
> making use of a legacy mode that it still supports.
>
> Best regards,
> Marcus
>
> On 17.12.20 10:53, Albin Stigö wrote:
> > 64bit mode is most likely better because in addition to being 64bit it
> > enables additional cpu features (certain new instructions and more SIMD
> > NEON registers)
> >
> > On Thu, Dec 17, 2020, 10:36 jean-michel.fri...@femto-st.fr
> > <mailto:jean-michel.fri...@femto-st.fr>  > <mailto:jean-michel.fri...@femto-st.fr>> wrote:
> >
> > The benchmark on volk/64 bit kernel v.s 32 bit Raspbian is at
> > https://pubs.gnuradio.org/index.php/grcon/article/view/73/55
> > <https://pubs.gnuradio.org/index.php/grcon/article/view/73/55>
> > last page. I get 3 to 7-fold improvement by volk_config on a
> dedicated
> > toolchain for 64-bit CPU.
> >
> > JM
> >
> > --
> > JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
> > Besancon, France
> >
> > December 17, 2020 10:28 AM, "Kristoff"  > <mailto:krist...@skypro.be>> wrote:
> >
> > > HI all,
> > >
> > > I also have a RPi4 (*).
> > > Some follow-up question.
> > >
> > > What OS would be the best for this?
> > > Would running 64 bit make a difference?
> > >
> > > I don't know to what degree this is related, but I did a test
> running
> > > WebGL (**) on that pi, and I got about 1/3 of the frames per
> > second on
> > > my RPi4 compared to my laptop (which only has a UHD Graphics 630
> > Mobile,
> > > so not the  best or latest neither)
> > > Is the GPU in the Pi4 good enough to run many GUI elements in GNU
> > Radio
> > > at the same time?
> > >
> > > Kr.
> > >
> > > (*) RPi4B 8 GB, 120 SSD
> > >
> > > (*) https://webglsamples.org <https://webglsamples.org>
> > >
> > > On 16/12/2020 11:10 p.m., Dan Romanchik KB6NU wrote:
> > >
> > >> Has anyone successfully run GNU Radio on a Pi 4? I recently
> purchased
> > >> an RTL-SDR dongle and thought it would be fun to experiment a
> little
> > >> with GNU Radio and learn something about SDR.
> > >>
> > >> A couple of days ago, I fired up GNU Radio, and after having some
> > >> trouble figuring out how to get the audio sink to talk to the Pi,
> I
> > >> downloaded VE6EY's FM receiver flow graph. The flow graph runs,
> but
> > >> the Pi 4 just doesn't seem to have enough horsepower to run it in
> > real
> > >> time. The audio is slow and distorted.
> > >>
> > >> Thinking that it might be the WX widgets slowing down the
> program, I
> > >> first deleted the FFT display widgets, then converted the WX
> slider
> > >> controls to QT range controls. Neither had any effect on how well
> the
> > >> flow graph ran.
> > >>
> > >> GQRX and CubicSDDR seem to work just fine. At least with both of
> > them,
> > >> I'm able to receive FM broadcast and NOAA weather station. But,
> maybe
> > >> the PI4 just doesn't have enough horsepower to run GNU Radio? If
> so,
> > >> that's kind of disappointing.
> > >>
> > >> 73! <—ham radio lingo for “best regards"
> > >>
> > >> *Dan KB6NU*
> > >> CW Geek, Ham Radio Instructor
> > >> Author of the "No Nonsense" amateur radio license study guides
> > >> Read my ham radio blog at http://www.kb6nu.com <
> http://www.kb6nu.com>
> >
>
>

Re: GNU Radio on Raspberry Pi 4?

[Albin Stigö]

64bit mode is most likely better because in addition to being 64bit it
enables additional cpu features (certain new instructions and more SIMD
NEON registers)

On Thu, Dec 17, 2020, 10:36 jean-michel.fri...@femto-st.fr <
jean-michel.fri...@femto-st.fr> wrote:

> The benchmark on volk/64 bit kernel v.s 32 bit Raspbian is at
> https://pubs.gnuradio.org/index.php/grcon/article/view/73/55
> last page. I get 3 to 7-fold improvement by volk_config on a dedicated
> toolchain for 64-bit CPU.
>
> JM
>
> --
> JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
> Besancon, France
>
> December 17, 2020 10:28 AM, "Kristoff"  wrote:
>
> > HI all,
> >
> > I also have a RPi4 (*).
> > Some follow-up question.
> >
> > What OS would be the best for this?
> > Would running 64 bit make a difference?
> >
> > I don't know to what degree this is related, but I did a test running
> > WebGL (**) on that pi, and I got about 1/3 of the frames per second on
> > my RPi4 compared to my laptop (which only has a UHD Graphics 630 Mobile,
> > so not the  best or latest neither)
> > Is the GPU in the Pi4 good enough to run many GUI elements in GNU Radio
> > at the same time?
> >
> > Kr.
> >
> > (*) RPi4B 8 GB, 120 SSD
> >
> > (*) https://webglsamples.org
> >
> > On 16/12/2020 11:10 p.m., Dan Romanchik KB6NU wrote:
> >
> >> Has anyone successfully run GNU Radio on a Pi 4? I recently purchased
> >> an RTL-SDR dongle and thought it would be fun to experiment a little
> >> with GNU Radio and learn something about SDR.
> >>
> >> A couple of days ago, I fired up GNU Radio, and after having some
> >> trouble figuring out how to get the audio sink to talk to the Pi, I
> >> downloaded VE6EY's FM receiver flow graph. The flow graph runs, but
> >> the Pi 4 just doesn't seem to have enough horsepower to run it in real
> >> time. The audio is slow and distorted.
> >>
> >> Thinking that it might be the WX widgets slowing down the program, I
> >> first deleted the FFT display widgets, then converted the WX slider
> >> controls to QT range controls. Neither had any effect on how well the
> >> flow graph ran.
> >>
> >> GQRX and CubicSDDR seem to work just fine. At least with both of them,
> >> I'm able to receive FM broadcast and NOAA weather station. But, maybe
> >> the PI4 just doesn't have enough horsepower to run GNU Radio? If so,
> >> that's kind of disappointing.
> >>
> >> 73! <—ham radio lingo for “best regards"
> >>
> >> *Dan KB6NU*
> >> CW Geek, Ham Radio Instructor
> >> Author of the "No Nonsense" amateur radio license study guides
> >> Read my ham radio blog at http://www.kb6nu.com
>
>

Re: GNU Radio on Raspberry Pi 4?

[Albin Stigö]

And remember to run volk_profile

On Thu, Dec 17, 2020, 08:03 Albin Stigö  wrote:

> Dan,
>
> I can't comment on your particular flowgraph but I can tell you that you
> will get a significant speed-up if you build volk and GNURadio from source
> (and maybe fftw) as this enables all sorts off optimizations not in the ppa
> for compatability reasons.
>
> If you decide to go down this route I recommend you keep your root
> filesystem on an ssd attached via usb3 and increase your swap file size to
> max.
>
> Albin SM6WJM
>
> On Wed, Dec 16, 2020, 23:40 Dan Romanchik KB6NU  wrote:
>
>> Has anyone successfully run GNU Radio on a Pi 4? I recently purchased an
>> RTL-SDR dongle and thought it would be fun to experiment a little with GNU
>> Radio and learn something about SDR.
>>
>> A couple of days ago, I fired up GNU Radio, and after having some trouble
>> figuring out how to get the audio sink to talk to the Pi, I downloaded
>> VE6EY's FM receiver flow graph. The flow graph runs, but the Pi 4 just
>> doesn't seem to have enough horsepower to run it in real time. The audio is
>> slow and distorted.
>>
>> Thinking that it might be the WX widgets slowing down the program, I
>> first deleted the FFT display widgets, then converted the WX slider
>> controls to QT range controls. Neither had any effect on how well the flow
>> graph ran.
>>
>> GQRX and CubicSDDR seem to work just fine. At least with both of them,
>> I'm able to receive FM broadcast and NOAA weather station. But, maybe the
>> PI4 just doesn't have enough horsepower to run GNU Radio? If so, that's
>> kind of disappointing.
>>
>> 73! <—ham radio lingo for “best regards"
>>
>> *Dan KB6NU*
>> CW Geek, Ham Radio Instructor
>> Author of the "No Nonsense" amateur radio license study guides
>> Read my ham radio blog at http://www.kb6nu.com
>>
>

Re: GNU Radio on Raspberry Pi 4?

[Albin Stigö]

Dan,

I can't comment on your particular flowgraph but I can tell you that you
will get a significant speed-up if you build volk and GNURadio from source
(and maybe fftw) as this enables all sorts off optimizations not in the ppa
for compatability reasons.

If you decide to go down this route I recommend you keep your root
filesystem on an ssd attached via usb3 and increase your swap file size to
max.

Albin SM6WJM

On Wed, Dec 16, 2020, 23:40 Dan Romanchik KB6NU  wrote:

> Has anyone successfully run GNU Radio on a Pi 4? I recently purchased an
> RTL-SDR dongle and thought it would be fun to experiment a little with GNU
> Radio and learn something about SDR.
>
> A couple of days ago, I fired up GNU Radio, and after having some trouble
> figuring out how to get the audio sink to talk to the Pi, I downloaded
> VE6EY's FM receiver flow graph. The flow graph runs, but the Pi 4 just
> doesn't seem to have enough horsepower to run it in real time. The audio is
> slow and distorted.
>
> Thinking that it might be the WX widgets slowing down the program, I first
> deleted the FFT display widgets, then converted the WX slider controls to
> QT range controls. Neither had any effect on how well the flow graph ran.
>
> GQRX and CubicSDDR seem to work just fine. At least with both of them, I'm
> able to receive FM broadcast and NOAA weather station. But, maybe the PI4
> just doesn't have enough horsepower to run GNU Radio? If so, that's kind of
> disappointing.
>
> 73! <—ham radio lingo for “best regards"
>
> *Dan KB6NU*
> CW Geek, Ham Radio Instructor
> Author of the "No Nonsense" amateur radio license study guides
> Read my ham radio blog at http://www.kb6nu.com
>

Re: GPIO lines on RPi4

[Albin Stigö]

Seems like you already understand the limitations! Good luck with you
project!

--Albin

On Mon, Jun 22, 2020, 14:30 jean-michel.fri...@femto-st.fr <
jean-michel.fri...@femto-st.fr> wrote:

> The envisioned application is event driven: send a control word from a
> client,
> wait for the even to complete (e.g. move antenna to target position), start
> streaming data for a given amount of time, and when enough data is
> collected move
> to new position. Of course timing cannot be relied on with a non-real time
> multitasking
> operating system whose load is not predictable.
>
> I did use successfully Python Module to implement the server and tune the
> UHD parameters
> during the week end without editing the Python code (why the Python Module
> must be entered
> through the GRC Python editor and not externally for the updates not to be
> lost is still
> not yet understood). Will have a look at this new Python Snippet feature.
>
> Thanks, JM
>
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
>
> June 22, 2020 2:05 PM, "Albin Stigö"  wrote:
>
> > It might be difficult to control GPIO with precise timing on raspberry
> pi depending on what you
> > want to do... A few hundred khz might be ok though. libgpiod is the new
> better Linux GPIO API.
> >
> > --Albin
> >
> > On Mon, Jun 22, 2020, 13:25 Marcus Müller  wrote:
> >
> >> It gets even better:
> >>
> >> We've launched a feature in 3.8.1.0 (and on master before that, as we do
> >> with any feature that ends up in a maintenance release) that we hope
> >> doesn't come back to bite us due to enabling unclean design. But, we
> >> must build best practices so that it doesn't go unused, either, so:
> >>
> >> Assuming you're using GNU Radio 3.8.1.0 (or later, once we release
> >> something), you can make use of the "Python Snippets" in GRC.
> >>
> >> Cheers,
> >> Marcus
> >>
> >> On 18/06/2020 23.17, Marcus D. Leech wrote:
> >>> On 06/18/2020 03:54 PM, jean-michel.fri...@femto-st.fr wrote:
> >>>> My approach:
> >>>> * build your grc chart from GNU Radio Companion and generate the .py
> file
> >>>> * edit the py file and import pygpio
> >>>> * play with the RPi4 GPIO in your python script.
> >>>>
> >>>> See attached script, with a python server included in the Python
> script
> >>>> to control an RF switch from a GNU Octave TCP/IP client talking to the
> >>>> Python
> >>>> TCP/IP server.
> >>>>
> >>>> I am presenting this approach to hardware control at
> >>>> http://jmfriedt.free.fr/sdra_radar.pdf
> >>>>
> >>>> JM
> >>> If you use "Python Module" block, you can write a lot of
> >>> non-GnuRadio-esque python, import anything you want, etc, etc. No
> editing
> >>> of the output python required, necessarily.
> >>>
> >>>
> >>>>
> >>>> --
> >>>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> >>>> 25000 Besancon, France
> >>>>
> >>>> June 18, 2020 9:40 PM, "Da Fy"  wrote:
> >>>>
> >>>>> Hi All, does anyone have an example of how to control GOIO lines on
> >>>>> the RPi4 from within a GRC
> >>>>> flowgraph. I’m guessing it’s an OOT module.
> >>>>>
> >>>>> I need to generate a signal of a few 100Hz & control GPIO lines at
> >>>>> various points though the cycle.
> >>>>>
> >>>>> Alternatively, I could generate the signal & lines with external
> >>>>> hardware & read them with
> >>>>> GnuRadio.
> >>>>>
> >>>>> Tnx, Dave
> >>>
> >>>
>

Re: GPIO lines on RPi4

[Albin Stigö]

It might be difficult to control GPIO with precise timing on raspberry pi
depending on what you want to do... A few hundred khz might be ok though.
libgpiod is the new better Linux GPIO API.

--Albin

On Mon, Jun 22, 2020, 13:25 Marcus Müller  wrote:

> It gets even better:
>
> We've launched a feature in 3.8.1.0 (and on master before that, as we do
> with any feature that ends up in a maintenance release) that we hope
> doesn't come back to bite us due to enabling unclean design. But, we
> must build best practices so that it doesn't go unused, either, so:
>
> Assuming you're using GNU Radio 3.8.1.0 (or later, once we release
> something), you can make use of the "Python Snippets" in GRC.
>
> Cheers,
> Marcus
>
> On 18/06/2020 23.17, Marcus D. Leech wrote:
> > On 06/18/2020 03:54 PM, jean-michel.fri...@femto-st.fr wrote:
> >> My approach:
> >> * build your grc chart from GNU Radio Companion and generate the .py
> file
> >> * edit the py file and import pygpio
> >> * play with the RPi4 GPIO in your python script.
> >>
> >> See attached script, with a python server included in the Python script
> >> to control an RF switch from a GNU Octave TCP/IP client talking to the
> >> Python
> >> TCP/IP server.
> >>
> >> I am presenting this approach to hardware control at
> >> http://jmfriedt.free.fr/sdra_radar.pdf
> >>
> >> JM
> > If you use "Python Module" block, you can write a lot of
> > non-GnuRadio-esque python, import anything you want, etc, etc.  No
> editing
> >of the output python required, necessarily.
> >
> >
> >>
> >> --
> >> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> >> 25000 Besancon, France
> >>
> >> June 18, 2020 9:40 PM, "Da Fy"  wrote:
> >>
> >>> Hi All, does anyone have an example of how to control GOIO lines on
> >>> the RPi4 from within a GRC
> >>> flowgraph. I’m guessing it’s an OOT module.
> >>>
> >>> I need to generate a signal of a few 100Hz & control GPIO lines at
> >>> various points though the cycle.
> >>>
> >>> Alternatively, I could generate the signal & lines with external
> >>> hardware & read them with
> >>> GnuRadio.
> >>>
> >>> Tnx, Dave
> >
> >
>
>

Re: Multithreading in GR blocks

[Albin Stigö]

An alternative is to use none blocking IO and use poll or select in your
worker thread and use another fd created with pipe(2) to signal that you
are done... Or a timer fd like Sylvain suggests. Not sure if boost has some
portability wrapping for this?

--Albin

On Mon, Apr 13, 2020, 19:59 Sylvain Munaut <246...@gmail.com> wrote:

> The m_finished thing only works if you're not using any blocking calls.
>
> But you're using `accept` and `recv` etc ... all calls that can block
> forever until they get something.
> You need to use `select` on the file descriptors while waiting for
> events / data and set a timeout on that select so your code has a
> periodic opportunity to check the m_finished flag.
>
> Cheers,
>
> Sylvain
>
>

Re: Slack alternatives

[Albin Stigö]

+1

On Tue, Feb 4, 2020, 17:26 Sylvain Munaut <246...@gmail.com> wrote:

> Hi
>
> > as you might know, Slack has become a very frequently used tool for
> communication in the project.
> > Tbh, I never understood the hype around Slack (not the form of
> communication but the specific software). It deletes our old messages and
> takes up a ridiculous amount of RAM.
>
> +1
>
> > Are there any people interested on switching to an alternative, like
> Mattermost [1]? I’m not deep in the topic, but from what I’ve heard it’s
> like Slack, but self-hosted, open-source and free.
>
> I think Andre was working on an alternative.
>
> Cheers,
>
>Sylvain
>
>

Re: Generating CW-morse signals with a straight key

[Albin Stigö]

General raspberry pi advise:

GNURadio is quite slow on raspberry pi if not built from source as this
will use the best compiler flags. The apt version is backwards compatible
and hence slower. Also volk needs to be built from source. Then you need to
run volk_profile to use the best available kernels.

--Albin SM6WJM

On Wed, Jan 1, 2020, 13:11 Harald Fritzsche (DD0VS)  wrote:

> Hello Frank, all,
>
> i got Jackd2 installed on this RPI4 and GnuRadio works together with
> Jack under some circumstances (start Qjackctl first, than GRC with the
> script, a second start of the script is not anymore connecting to jack,
> i have to restart jack to run it again.).
>
> Latency is reasonable in case of my block is constructed with:
> cw_key_impl::set_max_noutput_items(48); //where cw_key_impl is the OOT
> (There is a poll thread and a keyer thread locked with
> cw_key_impl::work()!, this should synchronize polling, debouncing and
> work())
>
> But occasionally underruns appear in GR (jU).
> Increase of max_output_items to 64 or higher increases latency
> significantly.
>
> There is another sw (from N1GP) implementing an iambic keyer (including
> straight key function) with GPIO and Jack, this sw never connects to
> jackd (this is a hint for Jack). Here i am still searching for a
> solution.
>
> I think my trial and error methode scetched above isn't realy a
> sustainable solution.
>
> Regards and vy73
> Harald
> DD0VS
>
>
>
>  Am Sat, 28 Dec 2019 11:18:26 -0800
> schrieb Frank Brickle :
>
> > Is there a JACK audio sink in Gnuradio these days?
> >
> > I'm not sure where they are housed, now, but I wrote a few programs to
> > generate CW this way some years ago. They depended on having JACK
> > audio input to the application. One of them could use either a
> > straight key or would work as a decent iambic keyer. The other
> > generated CW tone from text input, either from a file or directly
> > from stdin and therefore from a keyboard.
> >
> > If there were any interest I could probably dig up the source.
> >
> > 73
> > Frank
> > AB2KT/VE7
> >
> >
> > On Sat, Dec 28, 2019 at 11:06 AM Gorkem Ozcelebi 
> > wrote:
> >
> > > If I've understood your question correctly, how about the
> > > microphone / audio input? If it's ac-coupled, you could use a
> > > simple oscillator. The presence of the tone, gated by your morse
> > > key, triggers the cw. If you don't want to build / provide an
> > > external oscillator,  how about a software oscillator fed through
> > > one of the audio output channels of the same PC, going back in thru
> > > your morse key. The other audio channel is left available for the
> > > audio output of your receiver.
> > >
> > > Gorkem
> > >
> > > On Sat, Dec 28, 2019, 7:25 PM Harald Fritzsche (DD0VS)
> > >  wrote:
> > >
> > >> Hello All,
> > >>
> > >> Hoping that amateur radio is not to far away from common use of
> > >> Gnuradio mailing list, but amateur radio is making me looking to GR
> > >> since 2001.
> > >> There is a plan to use a Gnuradio based transceiver for µ-wave
> > >> contesting, as it has been shown by W7FU or KB1VC (SoDaRadio) or
> > >> DL9SW. A needed condition is, to key HF with morse code using a
> > >> straigth or simple morse key.
> > >>
> > >> Doing this with just looking to the status of /dev/ttyUSB0-CTS pin
> > >> is not sufficient, basically some of the keyed code is somehow
> > >> swalloed. Neither with python code or with a C++ OOT module i got
> > >> it solved.
> > >>
> > >> How to get this solved? (Hardware keying or modulated cw is not a
> > >> real option).
> > >>
> > >> Regards and vy73
> > >> Harald
> > >> DD0VS
> > >>
> > >>
> >
>
>
>

Re: Generating CW-morse signals with a straight key

[Albin Stigö]

I did extensive experimentation with this and it's tricky to get the timing
good enough with GPIO.

Like Gorkem says mic/line is a good option. You can connect an oscillator
and just send a tone in, filter this and then just send it as "SSB" as a
pure tone in SSB is just a carrier. You can also key a DC bias after the AC
coupling and generate the tone on software.

Good luck 73s Albin SM6WJM

On Sat, Dec 28, 2019, 20:06 Gorkem Ozcelebi  wrote:

> If I've understood your question correctly, how about the microphone /
> audio input? If it's ac-coupled, you could use a simple oscillator. The
> presence of the tone, gated by your morse key, triggers the cw. If you
> don't want to build / provide an external oscillator,  how about a software
> oscillator fed through one of the audio output channels of the same PC,
> going back in thru your morse key. The other audio channel is left
> available for the audio output of your receiver.
>
> Gorkem
>
> On Sat, Dec 28, 2019, 7:25 PM Harald Fritzsche (DD0VS) 
> wrote:
>
>> Hello All,
>>
>> Hoping that amateur radio is not to far away from common use of
>> Gnuradio mailing list, but amateur radio is making me looking to GR
>> since 2001.
>> There is a plan to use a Gnuradio based transceiver for µ-wave
>> contesting, as it has been shown by W7FU or KB1VC (SoDaRadio) or DL9SW.
>> A needed condition is, to key HF with morse code using a straigth or
>> simple morse key.
>>
>> Doing this with just looking to the status of /dev/ttyUSB0-CTS pin is
>> not sufficient, basically some of the keyed code is somehow swalloed.
>> Neither with python code or with a C++ OOT module i got it solved.
>>
>> How to get this solved? (Hardware keying or modulated cw is not a real
>> option).
>>
>> Regards and vy73
>> Harald
>> DD0VS
>>
>>

Re: AM demodulation

[Albin Stigö]

Hi Barry,

Some thoughts:

You have a large DC spike at the center, try using the frequency xlating
fir filter to tune an offset frequency.

Why don't you decimate at the channel filter?

Try observing the signal at various points using the frequency sink.

Good luck,
Albin SM6WJM

On Sat, Oct 26, 2019, 21:02 Barry Duggan  wrote:

> Hi,
>
> I've been working on a gnuradio AM broadcast receiver, and have found
> that the tuning is very critical to obtaining clear audio. My flowgraph
> can be seen at https://wiki.gnuradio.org/index.php/File:FunCube_AM.png.
> Are there any alternate demodulation methods which are not so sensitive
> to exact tuning?
>
> Thanks,
> --
> Barry Duggan KV4FV
>
>

Re: [Discuss-gnuradio] Create a general block using a GRC 'misc Python block'

[Albin Stigö]

Nice!

I like the way you generate morse code using the repeat block!

I don't see that the keying is filtered in any way which will lead to
clicks... some kind of symbol filter would be nice!
You can use the rotator block to generate a complex tone to send morse
code with an SDR transmitter.


--Albin

On Sun, Sep 8, 2019 at 6:39 PM Barry Duggan  wrote:
>
> FYI, I have created a repository for my Morse code generator:
> https://github.com/duggabe/gr-morse-code-gen
>
> Cheers!
> --
> Barry Duggan
>
> On Fri, 23 Aug 2019 10:00:15 -0400, Barry Duggan wrote:
>
> 
> If you are interested in the finished Morse code generator, see
> https://pastebin.com/XJqDzh6K
>
> ___
> 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

Re: [Discuss-gnuradio] [GSoC19] Final results announced!

[Albin Stigö]

That's great news!

On Wed, Sep 4, 2019, 11:08 Wunsch, Felix (CEL)  wrote:

> ​Hi all,
>
>
> today, the final results for this year's Google Summer of Code were
> announced. We are happy to say that both students that worked for GNU Radio
> during the summer successfully completed GSoC! Congratulations, Arpit
> Gupta and Bowen Hu, thank you for extending GNU Radio with your work! Arpit
> created a block header parsing tool while Bowen dealt with the integration
> of the simulation of Verilog code in GNU Radio. Both will soon publish a
> blog post on gnuradio.org where they go into further detail about their
> respective projects and reflect about their personal GSoC experience.
>
>
> We really hope that both of them will stay with the community as active
> developers! Also, their work will be showcased at GRCon19 through posters,
> so don't miss them if you can make it to Huntsville!
>
>
> Last but not least, we should not forget Marcus Müller, Sebastian
> Koslowski, and Nicolas Cuervo, who supported the students through their
> mentoring and continuous feedback and surely played an integral role in the
> successful completion of the projects.
>
>
> Cheers,
> Felix (GSoC Org Admin 2019)
> ___
> 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

[Discuss-gnuradio] set_min_noutput_items has no effect?

[Albin Stigö]

Hi,

Regarding coding blocks in C++:

Like the subject says, set_min_noutput_items seems to have no effect?

set_output_multiple has the intended effect and works as a workaround though...

I'm I doing something wrong?


--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ffast-math

[Albin Stigö]

In my experience VOLK runs about 10% faster on Raspberry Pi 4 with
-ffast-math, depending on the flowgraph you might get more. Three
kernels had some minor problems with precision, but I think they can
be fixed so all will pass... The fun thing about these embedded
platforms is that the possibilities for optimizations are almost
endless!

On a side note, which fork of dump1090 should I run? There seems to be so many!


--Albin

On Tue, Sep 3, 2019 at 6:18 PM Chris Kuethe  wrote:
>
> Yep, on some processors with some workloads it really makes a huge 
> difference. As others have commented, there may be significant trade-offs 
> with regard to numerical behaviro.
>
> Some of my observations:
> dump1090 loses accuracy below the 7th digit when calculating precision, but 
> consumes 10% less power on the device under test
> rtl_433 runs about 35% faster
> and acarsdec runs over 400% faster.
>
>
> On Sun, Sep 1, 2019, 07:11 Albin Stigö  wrote:
>>
>> Anyone has experience with the real world impact of using gcc -ffast-math 
>> with SDR in general, and GNURadio/Volk in particular?
>>
>>
>> --Albin SM6WJM
>> ___
>> 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

Re: [Discuss-gnuradio] ffast-math

[Albin Stigö]

Interesting! I'm experimenting with this right now. NEON on armv7 is
not always IEEE754 compliant by the way.

--Albin

On Mon, Sep 2, 2019 at 5:28 PM Müller, Marcus (CEL)  wrote:
>
> -ffast-math is allowed to reorder calculations, e.g. it can do
> a*f + b*f + c*f as (a+b+c)*f (or vice versa)
> which of course isn't necessarily the same result, and can lead to
> numerical instability.
>
> The problem is really that for some kernels, things like zero-signage
> and NaN / Inf handling / rounding / saturation are negligible, for
> others not. We've had plenty of fun with kernels where the SIMD
> implementation actually did the right thing, but the plain C
> implementation misbehaved, for example, because it didn't use the same
> FPU flags; I'd be kind of hesitant to add more "might or might not act
> as expected" code...
>
> Best regards,
> Marcus
>
> On Mon, 2019-09-02 at 16:52 +0200, Albin Stigö wrote:
> > ffast-math disables signed zero by design I think...
> >
> > I'm particularly interested in problems of numeric stability and loss of 
> > dynamic range.
> >
> >
> > --Albin
> >
> > On Mon, Sep 2, 2019, 15:27 Johannes Demel  wrote:
> > > Hi Albin,
> > >
> > > one of my students reported a little oddity about `-ffast-math`. Assume
> > > you want to set a float to -0, i.e. set the sign bit only. In this case
> > > `-ffast-math` seems to remove the sign bit.
> > >
> > > In VOLK this might be an issue with `_mm256_conjugate_ps` in
> > > `include/volk/volk_avx_intrinsics.h`. I didn't check for other potential
> > > error sources.
> > >
> > > Cheers
> > > Johannes
> > >
> > > Am 01.09.19 um 16:10 schrieb Albin Stigö:
> > > > Anyone has experience with the real world impact of using gcc
> > > > -ffast-math with SDR in general, and GNURadio/Volk in particular?
> > > >
> > > >
> > > > --Albin SM6WJM
> > > >
> > > > ___
> > > > 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
> >
> > ___
> > 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

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ffast-math

[Albin Stigö]

ffast-math disables signed zero by design I think...

I'm particularly interested in problems of numeric stability and loss of
dynamic range.


--Albin

On Mon, Sep 2, 2019, 15:27 Johannes Demel  wrote:

> Hi Albin,
>
> one of my students reported a little oddity about `-ffast-math`. Assume
> you want to set a float to -0, i.e. set the sign bit only. In this case
> `-ffast-math` seems to remove the sign bit.
>
> In VOLK this might be an issue with `_mm256_conjugate_ps` in
> `include/volk/volk_avx_intrinsics.h`. I didn't check for other potential
> error sources.
>
> Cheers
> Johannes
>
> Am 01.09.19 um 16:10 schrieb Albin Stigö:
> > Anyone has experience with the real world impact of using gcc
> > -ffast-math with SDR in general, and GNURadio/Volk in particular?
> >
> >
> > --Albin SM6WJM
> >
> > ___
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ffast-math

[Albin Stigö]

Anyone has experience with the real world impact of using gcc -ffast-math
with SDR in general, and GNURadio/Volk in particular?


--Albin SM6WJM
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Maximum input items consumed on each input stream

[Albin Stigö]

Laura et al,

consume_each <= ninput_items.

If you need a larger buffer than you consume you can abuse the
scheduler slightly by set_relative_rate(1, some_min_input_items), this
is done in the stream to vector blocks for example. I do this in a
visualization sink where I need to produce FFTs with a certain
overlap.

// We need at least this number of points to do our job
m_input_length = std::max(m_consume_each, m_fft_size);
// This is probably abusing the scheduler quite a bit
set_relative_rate(1, m_input_length);

Interesting to see you work in neuroengineering. I'm an
anesthesiologist and very interested these applications of gnuradio.


--Albin

On Fri, Aug 30, 2019 at 11:44 AM Marcus Müller  wrote:
>
> Hi Laura,
>
> the buffer sizes are determined at flow graph startup based on the
> involved block's io signature, output multiples, alignment
> requirements, minimum and maximum buffer sizes, and the page size
> (which practically everywhere is 4kB).
>
> I think you're expecting the amount of items your block is presented
> with to be deterministic: it's simply not.
>
> It's a thing that depends on  the temporal execution of the signal
> processing flowgraph at run time. Thus, your work (or general_work)
> must always make sure it works within the boundaries of how many
> samples are supplied in that specific call, and how much output space
> is available at that point.
>
> I think
>
> https://www.gnuradio.org/blog/2017-01-05-buffers/
>
> might be of interest to you.
>
> Best regards,
> Marcus
>
> On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote:
> > Thank you very much Michael.
> >
> >  What are the I/O buffer sizes?
> >
> > * My block is a general block
> > * In my forecast: ninput_items_required[0] = noutput_items;
> > * In the general_work:  const gr_complex *in = (const gr_complex *)
> > input_items[0];
> >   float *out = (float *)
> > output_items[0];
> >
> > /*
> >  * The private constructor
> >  */
> > decoder_impl::frame_decoder_impl(int sample_rate,std::vector
> > output_sizes)
> >   : gr::block("decoder",
> >   gr::io_signature::make(1, 1, sizeof(gr_complex)),
> >   gr::io_signature::makev(2, 2, output_sizes)),
> >   s_rate(sample_rate)
> > {
> >
> >
> >
> >
> > On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <
> > michael.dick...@ettus.com> wrote:
> > > Hi Laura - In the "work" or "general_work" method, there are
> > > arguments that contain the information you're looking for. These
> > > arguments are set depending on what type of block you're creating
> > > (source, sink, sync, tagged_stream, whatever), are influenced by
> > > what the "forecast()" method returns, and are constrained by the
> > > I/O buffer sizes. Sorry to be a little vague, but the answer is
> > > that the value of the variable "consumed" in your description is
> > > context dependent. Hope this is useful! - MLD
> > >
> > > On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona 
> > > wrote:
> > > > Hello GNURadio community,
> > > >
> > > > Does anyone know what is the maximum number of input items that
> > > > an Out Of Tree block can consume on each input stream?
> > > >
> > > > consume_each(consumed) --> what is the maximum value that the
> > > > variable consumed can take?
> > > >
> > > > Thank you very much.
> > > >
> > > >
> > > > --
> > > > Laura Arjona
> > > > Washington Research Foundation Innovation Postdoctoral Fellow in
> > > > Neuroengineering
> > > >
> > > > Paul G. Allen School of Computer Science & Engineering
> > > > 185 E Stevens Way NE
> > > > University of Washington
> > > > Seattle, WA 98195-2350
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > > --
> > > Michael Dickens, Mac OS X Programmer
> > >
> > > Ettus Research Technical Support
> > >
> > > Email: supp...@ettus.com
> > >
> > > Web: http://www.ettus.com
> >
> >
> > ___
> > 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

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Remotely controlling a GNURadio flowgraph via LAN

[Albin Stigö]

You could implement your flowgraph in python and then use some python
library for rpc and write a thin layer between...

You can also implement a flowgraph in C++.

I'm currently playing around with RPC over DBUS (only control, no data) for
an application I'm writing in C++.


--Albin



On Fri, Aug 9, 2019, 10:35 Müller, Marcus (CEL)  wrote:

> Hi Alex,
>
> we do have two approaches for that
>
> 1. the XMLRPC thing, which is a python-world block that basically would
> allow you to do the same you can do with e.g. a Qt GUI Range slider
> (i.e. change Python variables at runtime)
> 2. Ctrlport and the thrift backend, the latter of which is notoriously
> hard to get right.
>
> I **really** think RPC is big in GNU Radio's future; we'll work on that
> fundamentally. The problem is you're trying to solve a technical
> challenge now, not then.
>
> So, check out the XMLRPC, see if it suits you.
>
> If it doesn't: What I'd recommend is to
>
> 1. use GRC to construct your flow graph as desired, assuming you're
> doing that so far. Hint: if you use "Parameter" blocks instead of
> "Variable" blocks, you get arguments to your top block's constructor)
> 2. Take the resulting python file, and use it as a Python module
> (rather than running it as executable itself), containing a class named
> like the "id" you set in the options block (the instance of
> gr.top_block).
> 3. Write a simple application that imports that module, and modifies
> the state of the top block (see the "main" function at the end of the
> generated Python file) as dictated through RPC from your receiving end.
>
> For 3: I do like zeroMQ, it has good Python integration and for your
> application, the REQuest/REPly socket pattern would probably work very
> well. You can encode RPC commands however you like, for example simple
> JSON like {"tune", [2.4e9, 1e6]} or so.
>
> Or, you can directly use a python RPC thing. I've not personally tried
> that, but zerorpc.io looks fine for this kind of thing. Quite possible,
> all you'd need to build on the Pi would be
>
> #!/usr/bin/env python
> import zerorpc
> import myfg #replace with the generated .py
>
> server = zerorpc.Server(myfg.myfg(sensible_arguments_if_any))
> server.bind("tcp://0.0.0.0:1337") #bind to all interaces on port 1337
>
> # could be tcp://127.0.0.1:1337 instead, if you're doing e.g. port
> forwarding through `ssh -R 127.0.0.1:1337:1337!
> # There's even ZMQ brokers and stuff, but that'd lead too far.
> s.run()
>
>
> And locally, you could try
>
> import zerorpc
> client = zerorpc.Client()
> client.connect("tcp://yourPisAdddress:1337")
> client.start()
> client.set_samp_rate(4e6) #or whatever methods your top block has
>
> Best regards,
> Marcus
>
> On Thu, 2019-08-08 at 23:16 +0100, Alex Pane wrote:
> > Hi,
> >
> > I have created a simple tcp based iq stream using ZMQ blocks to use a
> HackRF remotely over an ethernet network.
> >
> > I have a linux computer (Raspberry Pi) connected to the HackRF running
> GNURadio. The HackRF source is connected to a ZMQ sink that transmits the
> packets to a receiving linux PC running GNURadio - where a ZMQ source
> connected to a QT sink for visualising the IQ signal stream.
> >
> > This works fine for a fixed frequency, sample rate and fft size etc,
> however my problem is that i want to be able to change those parameters
> from the receiving PC.
> >
> > Despite much research, i have been unable to find a way to change the
> parameters of the remote flowgraph (client) from the receiving display end
> (server).
> >
> > Is there a way to natively perform this operation within GNURadio and
> can someone provide guidance on how to setup a flowgraph to achieve this?
> Or is there some additional OOT block or custom python block i would need
> to create to do this.
> >
> > Thanks
> >
> > Alex
> > ___
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ARM optimization update

[Albin Stigö]

Hi,

ARM support is now pretty much done for libvolk. I'm just waiting to
sign the Contributor licence agreement before I start sending pull
requests. There has been some (legimite) concern that my branch is a
total mess, but don't worry, I will refactor so there will be one pull
request / kernel, probably starting with the most commonly used...

https://github.com/gnuradio/volk/issues/243


--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Request for comment: FFT optimizations

[Albin Stigö]

Hi,

There's a lot of memcpy/memmove going on in the FFT kernel which I
suspect degrades performance quite a bit... This is partly because
some platforms requires buffers to be aligned for SIMD to work and
partly because DC is not normally centered (which is normally what you
would like to see in a spektrum).

For ARM in particular the alignment requirements are less strict so
that would get rid of at least one memcpy for that platform.

For centering an FFT at DC there's a nice trick, you just rotate the
input by pi, that is multiply by 1, -1, 1, -1... I suspect that would
be quite a bit faster than two memcpy and should be available on all
platforms.

Has this been discussed on the list before?


--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

[Albin Stigö]

Yes, 32i and 16i is probably the best since it avoids a lot of
confusion regarding fixed point. It's very intuitive that a full range
int gets compressed to +-1.0.

Let's see if there's any real world performance gain though, but at
least it's nice and clean using dedicated hardware instructions and
avoids errors using an incorrect scalar.

On a side note I was blown away to see that armv8.3 has dedicated
instructions for complex arithmetic which could potentially give a
substantial performance gain... At least when arm takes over the
laptop market which I predict will happen in a few years.


--Albin

On Fri, May 31, 2019 at 11:52 AM Müller, Marcus (CEL)  wrote:
>
> Ah, I thought  (hurrhurr, a pun) in Q1.15: 15 bits of -0.252525 and
> +0.252525 are the same, just the sign bit flips. If it's really just an
> interpretation of integers: well, call it 16i
> On Fri, 2019-05-31 at 11:45 +0200, Albin Stigö wrote:
> > > two's complement being the standard way of
> > > dealing with numbers
> >
> > Signed numbers at least...
> >
> > Signed Q values are (at least in all cases I've seen) stored in two's
> > complement format. It's just like any other signed integer with an
> > implied comma.
> >
> > The Wikipedia article is fairly good:
> > https://en.wikipedia.org/wiki/Q_(number_format)
> >
> >
> > --Albin
> >
> > On Fri, May 31, 2019 at 11:40 AM Müller, Marcus (CEL)  
> > wrote:
> > >
> > > Hm, wait, realizing something:
> > > Q1.31 differs from what a x86 CPU can reasonably deal with in that it's
> > > not 2's complement for negative numbers; since I'd guess the same
> > > situation applies to ARM (two's complement being the standard way of
> > > dealing with numbers), maybe we should just have one VOLK kernel /
> > > routine to be used within VOLK kernels
> > >
> > > volk_q1.31_convert_32i
> > >
> > > to get a number format that CPU instructions can actually deal with,
> > > and then implement the rest of fixed point arithmetic with that.
> > > Is that sensible?
> > >
> > > Best regards,
> > > Marcus
> > > On Fri, 2019-05-31 at 11:34 +0200, Albin Stigö wrote:
> > > > What about naming these functions... any ideas? Here are some
> > > > suggestions of the top of my head:
> > > >
> > > > volk_32i_convert_32f
> > > > volk_q1.32_convert_32f
> > > > volk_q1_32_convert_32f
> > > >
> > > >
> > > > --Albin
> > > >
> > > > On Fri, May 31, 2019 at 10:30 AM Albin Stigö  
> > > > wrote:
> > > > >
> > > > > Thanks for the feedback Marcus!
> > > > >
> > > > > Pretty much all SDRs I've seen use either 8, 16 or 32 bit full range
> > > > > integers (or 24 bits packed in the most significant bits of a 32 bit
> > > > > int so can use same conversion as 32 bit).
> > > > >
> > > > > Yes Q1.15 means 1 sign bit and 15 fractional bits, in practice this
> > > > > just means that a full range int16_t will map to +-1.0. An N-tap FIR
> > > > > filter which has L-bit data values and M-bit coefficients requires L +
> > > > > M + log2(N) bits in the accumulator.
> > > > >
> > > > > A CIC decimator/interpolator might also be interesting, although I'm
> > > > > not sure if there's already an implementation.
> > > > >
> > > > >
> > > > > --Albin
> > > > >
> > > > > On Fri, May 31, 2019 at 10:13 AM Müller, Marcus (CEL) 
> > > > >  wrote:
> > > > > >
> > > > > > Hi Albin,
> > > > > >
> > > > > > I'd love this, especially if we end up with a kernel that we can 
> > > > > > use to
> > > > > > build decimating FIR filters that inherently convert to 
> > > > > > higher-bitwidth
> > > > > > int or floating point.
> > > > > >
> > > > > > I think this could be super useful in hardware flow graphs, where 
> > > > > > one
> > > > > > would get integer numbers from hardware anyway; in a low-SNR 
> > > > > > scenario
> > > > > > only processing gain (e.g. through filtering / correlation) would 
> > > > > > make
> > > > > > it sensible to use a larger integer or floating point's larger 
> > > > > > dynamic
> > > > &g

Re: [Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

[Albin Stigö]

> two's complement being the standard way of
> dealing with numbers

Signed numbers at least...

Signed Q values are (at least in all cases I've seen) stored in two's
complement format. It's just like any other signed integer with an
implied comma.

The Wikipedia article is fairly good:
https://en.wikipedia.org/wiki/Q_(number_format)


--Albin

On Fri, May 31, 2019 at 11:40 AM Müller, Marcus (CEL)  wrote:
>
> Hm, wait, realizing something:
> Q1.31 differs from what a x86 CPU can reasonably deal with in that it's
> not 2's complement for negative numbers; since I'd guess the same
> situation applies to ARM (two's complement being the standard way of
> dealing with numbers), maybe we should just have one VOLK kernel /
> routine to be used within VOLK kernels
>
> volk_q1.31_convert_32i
>
> to get a number format that CPU instructions can actually deal with,
> and then implement the rest of fixed point arithmetic with that.
> Is that sensible?
>
> Best regards,
> Marcus
> On Fri, 2019-05-31 at 11:34 +0200, Albin Stigö wrote:
> > What about naming these functions... any ideas? Here are some
> > suggestions of the top of my head:
> >
> > volk_32i_convert_32f
> > volk_q1.32_convert_32f
> > volk_q1_32_convert_32f
> >
> >
> > --Albin
> >
> > On Fri, May 31, 2019 at 10:30 AM Albin Stigö  wrote:
> > >
> > > Thanks for the feedback Marcus!
> > >
> > > Pretty much all SDRs I've seen use either 8, 16 or 32 bit full range
> > > integers (or 24 bits packed in the most significant bits of a 32 bit
> > > int so can use same conversion as 32 bit).
> > >
> > > Yes Q1.15 means 1 sign bit and 15 fractional bits, in practice this
> > > just means that a full range int16_t will map to +-1.0. An N-tap FIR
> > > filter which has L-bit data values and M-bit coefficients requires L +
> > > M + log2(N) bits in the accumulator.
> > >
> > > A CIC decimator/interpolator might also be interesting, although I'm
> > > not sure if there's already an implementation.
> > >
> > >
> > > --Albin
> > >
> > > On Fri, May 31, 2019 at 10:13 AM Müller, Marcus (CEL)  
> > > wrote:
> > > >
> > > > Hi Albin,
> > > >
> > > > I'd love this, especially if we end up with a kernel that we can use to
> > > > build decimating FIR filters that inherently convert to higher-bitwidth
> > > > int or floating point.
> > > >
> > > > I think this could be super useful in hardware flow graphs, where one
> > > > would get integer numbers from hardware anyway; in a low-SNR scenario
> > > > only processing gain (e.g. through filtering / correlation) would make
> > > > it sensible to use a larger integer or floating point's larger dynamic
> > > > range.
> > > >
> > > > Not quite sure how that would preferably look like, but I'd imagine
> > > > Q1.15 going in, getting weighted internally with Q1.15 (or Q1.31 with
> > > > limited amplitude) coefficients to add Q1.31 numbers to a Q1.31
> > > > accumulator. (I'm assuming Q1.15 means 15 fractional binary digits and
> > > > one sign bit.)
> > > >
> > > > (Oh, and yes, x86_64 / SIMD extensions have relatively nice conversion
> > > > instructions.)
> > > >
> > > > Best regards,
> > > > Marcus
> > > >
> > > > On Fri, 2019-05-31 at 09:50 +0200, Albin Stigö wrote:
> > > > > Hi,
> > > > >
> > > > > Volk has functions for converting between int and float by casting and
> > > > > multiplying with a scalar. I'd like to purpose functions for the
> > > > > special case where scalar is 1/INT32_MAX (and 1/INT16_MAX etc) as this
> > > > > is a very common use case and might be available to an optimization.
> > > > > Certain CPUs (armv8 in particular [1], not sure about x86? [2]) has
> > > > > hardware instructions for converting fixed point to float and back.
> > > > >
> > > > > In particular I'm interested in adding the common Q1.31 and Q1.15
> > > > > formats (full range signed int32_t and full range int16_t to
> > > > > (-1.0)-1.0 float).
> > > > >
> > > > > Would be grateful for input regarding this and in particular ideas for
> > > > > naming the functions.
> > > > >
> > > > >
> > > > > --Albin
> > > > >
> > > > > [1] 
> > > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801h/pge1427897637493.html
> > > > > [2] 
> > > > > https://software.intel.com/en-us/articles/fast-floating-point-to-integer-conversions
> > > > >
> > > > > ___
> > > > > 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

Re: [Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

[Albin Stigö]

What about naming these functions... any ideas? Here are some
suggestions of the top of my head:

volk_32i_convert_32f
volk_q1.32_convert_32f
volk_q1_32_convert_32f


--Albin

On Fri, May 31, 2019 at 10:30 AM Albin Stigö  wrote:
>
> Thanks for the feedback Marcus!
>
> Pretty much all SDRs I've seen use either 8, 16 or 32 bit full range
> integers (or 24 bits packed in the most significant bits of a 32 bit
> int so can use same conversion as 32 bit).
>
> Yes Q1.15 means 1 sign bit and 15 fractional bits, in practice this
> just means that a full range int16_t will map to +-1.0. An N-tap FIR
> filter which has L-bit data values and M-bit coefficients requires L +
> M + log2(N) bits in the accumulator.
>
> A CIC decimator/interpolator might also be interesting, although I'm
> not sure if there's already an implementation.
>
>
> --Albin
>
> On Fri, May 31, 2019 at 10:13 AM Müller, Marcus (CEL)  wrote:
> >
> > Hi Albin,
> >
> > I'd love this, especially if we end up with a kernel that we can use to
> > build decimating FIR filters that inherently convert to higher-bitwidth
> > int or floating point.
> >
> > I think this could be super useful in hardware flow graphs, where one
> > would get integer numbers from hardware anyway; in a low-SNR scenario
> > only processing gain (e.g. through filtering / correlation) would make
> > it sensible to use a larger integer or floating point's larger dynamic
> > range.
> >
> > Not quite sure how that would preferably look like, but I'd imagine
> > Q1.15 going in, getting weighted internally with Q1.15 (or Q1.31 with
> > limited amplitude) coefficients to add Q1.31 numbers to a Q1.31
> > accumulator. (I'm assuming Q1.15 means 15 fractional binary digits and
> > one sign bit.)
> >
> > (Oh, and yes, x86_64 / SIMD extensions have relatively nice conversion
> > instructions.)
> >
> > Best regards,
> > Marcus
> >
> > On Fri, 2019-05-31 at 09:50 +0200, Albin Stigö wrote:
> > > Hi,
> > >
> > > Volk has functions for converting between int and float by casting and
> > > multiplying with a scalar. I'd like to purpose functions for the
> > > special case where scalar is 1/INT32_MAX (and 1/INT16_MAX etc) as this
> > > is a very common use case and might be available to an optimization.
> > > Certain CPUs (armv8 in particular [1], not sure about x86? [2]) has
> > > hardware instructions for converting fixed point to float and back.
> > >
> > > In particular I'm interested in adding the common Q1.31 and Q1.15
> > > formats (full range signed int32_t and full range int16_t to
> > > (-1.0)-1.0 float).
> > >
> > > Would be grateful for input regarding this and in particular ideas for
> > > naming the functions.
> > >
> > >
> > > --Albin
> > >
> > > [1] 
> > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801h/pge1427897637493.html
> > > [2] 
> > > https://software.intel.com/en-us/articles/fast-floating-point-to-integer-conversions
> > >
> > > ___
> > > 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

Re: [Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

[Albin Stigö]

Thanks for the feedback Marcus!

Pretty much all SDRs I've seen use either 8, 16 or 32 bit full range
integers (or 24 bits packed in the most significant bits of a 32 bit
int so can use same conversion as 32 bit).

Yes Q1.15 means 1 sign bit and 15 fractional bits, in practice this
just means that a full range int16_t will map to +-1.0. An N-tap FIR
filter which has L-bit data values and M-bit coefficients requires L +
M + log2(N) bits in the accumulator.

A CIC decimator/interpolator might also be interesting, although I'm
not sure if there's already an implementation.


--Albin

On Fri, May 31, 2019 at 10:13 AM Müller, Marcus (CEL)  wrote:
>
> Hi Albin,
>
> I'd love this, especially if we end up with a kernel that we can use to
> build decimating FIR filters that inherently convert to higher-bitwidth
> int or floating point.
>
> I think this could be super useful in hardware flow graphs, where one
> would get integer numbers from hardware anyway; in a low-SNR scenario
> only processing gain (e.g. through filtering / correlation) would make
> it sensible to use a larger integer or floating point's larger dynamic
> range.
>
> Not quite sure how that would preferably look like, but I'd imagine
> Q1.15 going in, getting weighted internally with Q1.15 (or Q1.31 with
> limited amplitude) coefficients to add Q1.31 numbers to a Q1.31
> accumulator. (I'm assuming Q1.15 means 15 fractional binary digits and
> one sign bit.)
>
> (Oh, and yes, x86_64 / SIMD extensions have relatively nice conversion
> instructions.)
>
> Best regards,
> Marcus
>
> On Fri, 2019-05-31 at 09:50 +0200, Albin Stigö wrote:
> > Hi,
> >
> > Volk has functions for converting between int and float by casting and
> > multiplying with a scalar. I'd like to purpose functions for the
> > special case where scalar is 1/INT32_MAX (and 1/INT16_MAX etc) as this
> > is a very common use case and might be available to an optimization.
> > Certain CPUs (armv8 in particular [1], not sure about x86? [2]) has
> > hardware instructions for converting fixed point to float and back.
> >
> > In particular I'm interested in adding the common Q1.31 and Q1.15
> > formats (full range signed int32_t and full range int16_t to
> > (-1.0)-1.0 float).
> >
> > Would be grateful for input regarding this and in particular ideas for
> > naming the functions.
> >
> >
> > --Albin
> >
> > [1] 
> > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801h/pge1427897637493.html
> > [2] 
> > https://software.intel.com/en-us/articles/fast-floating-point-to-integer-conversions
> >
> > ___
> > 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

[Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

[Albin Stigö]

Hi,

Volk has functions for converting between int and float by casting and
multiplying with a scalar. I'd like to purpose functions for the
special case where scalar is 1/INT32_MAX (and 1/INT16_MAX etc) as this
is a very common use case and might be available to an optimization.
Certain CPUs (armv8 in particular [1], not sure about x86? [2]) has
hardware instructions for converting fixed point to float and back.

In particular I'm interested in adding the common Q1.31 and Q1.15
formats (full range signed int32_t and full range int16_t to
(-1.0)-1.0 float).

Would be grateful for input regarding this and in particular ideas for
naming the functions.


--Albin

[1] 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801h/pge1427897637493.html
[2] 
https://software.intel.com/en-us/articles/fast-floating-point-to-integer-conversions

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ARM optimizations update

[Albin Stigö]

Hi,

Of course, like I said in my previous emails, this is more of a scratch pad
to see what's worth it and what's working. There will obviously be one
commit per kernel per pull request.


--Albin

On Thu, May 30, 2019, 17:04 Andrej Rode  wrote:

> Hi Albin,
>
> just to throw in some snarky comments.
>
> On Thu, 30 May 2019 16:20:44 +0200
> Albin Stigö  wrote:
>
> > I've finished ARM NEON SIMD optimization for 44 kernels which means
> > only 23 kernels (not often used) are now missing a NEON
> > implementation.
>
> I've checked on your progress a couple of weeks ago and just to have
> that info beforehand: It is really beneficial to have a good
> reviewability with meaningful commits that can be merged seperately.
> Since your changeset will be quite big I think going for a commit per
> kernel might be a way to go. That will help getting reviews from other
> experts on NEON (Me not being an expert in that field).
>
> Otherwise keep up the good work!
>
> Cheers,
> Andrej
>
> ___
> 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

[Discuss-gnuradio] ARM optimizations update

[Albin Stigö]

Hi,

I've finished ARM NEON SIMD optimization for 44 kernels which means
only 23 kernels (not often used) are now missing a NEON
implementation.

All of the kernels so far are written using compiler intrinsics which
means they will compile on both arm 32 and 64 bit. I've experimented
with aarch64 assembly ("neonv8") but found that in practice it's very
difficult to get any meaningful performance gain. Gcc is pretty damn
good at generating code and scheduling instructions...

Issue with link to my branch is here:
https://github.com/gnuradio/volk/issues/243


--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Messaging Passing on a Budget

[Albin Stigö]

I like to use the socketpair(2) syscall for this, if you don't really need
a message broker.

--Albin

On Wed, May 29, 2019, 21:26 Brad Hein  wrote:

> Packaging the json string as a vector of u8 integers worked like a charm,
> thank you for the suggestion!
>
> Python code:
> https://gist.github.com/regulatre/38e7162d6f470ad0dbd77b171a69dc79
> C++ block code:
> https://gist.github.com/regulatre/f264fb4751ca3bd8d6b98abf9792e95d
>
> Memory consumption by the python flowgraph is no longer showing signs of
> memory leakage (at least in the 4 hours it's been running :)
>
>
> On Fri, Mar 1, 2019 at 1:50 PM Müller, Marcus (CEL) 
> wrote:
>
>> Hi Brad,
>>
>> so, yes, your observation is correct: PMT symbols are/were meant to be
>> used as "identifiers", not as "data carriers"; the motivation behind
>> the hash table you find in pmt.cc is that there's only one instance of
>> any given PMT symbol, and thus, a simple address comparison suffices to
>> tell whether two PMT symbols are the same.
>>
>> You'll notice that on x86 (and presumably modern ARM) string comparison
>> is pretty fast, and that you'd need to do *a lot* comparisons to offset
>> the cost of hashing a symbol once. Anyway, yes, that table grows
>> unboundedly.
>>
>> Since your string isn't actually a "symbol", I'd recommend simply
>> encoding it safely (that's probably already the case), and putting it
>> in a uniform PMT vector of 8bit integers (u8vector).
>>
>> On a different note, there's actually "unintended" (as in: I don't
>> intend GNU Radio to have an unbounded hash map, but it's at least what
>> was originally intended) memory leaks with PMTs and tag_t on the
>> Python/C++ boundary, and there's quite some broken concepts within PMT.
>>
>> Long or medium term, we'll be replacing PMT with something that is
>> actually a common serialization format for usage in external software
>> (i.e. not for usage within the same flow graph), and ideally with the
>> unserialized universal container that comes with such a format. Stay
>> tuned. However, not happening in 3.8 or anything before.
>>
>> Best regards,
>> Marcus
>>
>> On Thu, 2019-02-28 at 14:48 -0500, Brad Hein wrote:
>> >
>> > In my gnuradio test application I’m attempting to pass a JSON formatted
>> string from my C++ custom block, to my python flow graph containing the
>> block.
>> >
>> > The String message are being received by my python flow graph, but
>> there’s a memory leak. Over time, my flowgraph RSS (memory footprint) grows
>> at about 32k/s up until the application runs out of memory.
>> >
>> > The leak didn’t start until after I retrofitted my flowgraph and custom
>> block with polymorphic type (PMT) based message passing. I’m passing a 200
>> or so byte JSON string (as a symbol) from C++ block to python flow graph
>> about 60 times per second.
>> >
>> > Sleuthing through the pmt.cc code [1] I see the String (symbol) objects
>> are stored in a hash. I suspect what is happening is that since all of my
>> JSON strings are unique, they’re getting added to the hash and causing the
>> hash to grow unbounded over time.
>> >
>> > From what I can tell by reading the wiki [2], the approach I’m using is
>> the best way to get a string from my custom block and into my python
>> flowgraph.
>> >
>> > [1]
>> https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/pmt/pmt.cc
>> > [2] https://www.gnuradio.org/doc/doxygen/page_pmt.html
>> >
>> >
>> > Sample c++ block code snippet from my work function:
>> >
>> > // Calculate metrics. Occasionally (60/second) we'll get back a JSON
>> formatted string of metrics.
>> > crossingData = calculateWaveCrossingMetrics(lastSampleValue,in[i]);
>> >
>> > if (crossingData.length() > 0) {
>> >   pmt::pmt_t messageString;
>> >   messageString = pmt::string_to_symbol(crossingData.c_str());
>> >   message_port_pub(polymorphicMessageDestination, messageString);
>> >
>> >
>> > Questions:
>> >
>> > 1. Is this the best way to get a string from my C++ block into my
>> python application?
>> > 2. Is there a way to pass my messages that doesn’t result in memory
>> growing unbounded?
>> >
>> >
>> > Thank you
>> > Brad
>> >
>> > ___
>> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tutorial question

[Albin Stigö]

You can also program a flowgraph in c++ but it's not so simple.

On Fri, May 24, 2019, 14:19 Michael Dickens 
wrote:

> Hi Hans - GR Companion generates a Python script that you can run directly
> from the commandline. You can set the name in the config box (upper left)
> in the GRC flowgraph window. Guessing this is what you were looking for; if
> not, keep asking! - MLD
>
> On Fri, May 24, 2019, at 6:48 AM, Hans Kurscheidt wrote:
> > Hi,
> >
> > may be my question is too obvious or simple, but I couldn't find
> > anything in the tutorials.
> >
> > Given that I have a running flowgraph in companion w/ some real HW
> > frontend and something like tcp-sink or numerical sink at the end. Now
> > all creation and testing is finished and in the future I just want tot
> > run this thing on my raspberryPi from cmd-line.
> >
> > HowTo?
> >
> > Rgds
> >
> > hk
>
> ___
> 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

Re: [Discuss-gnuradio] VOLK, gnuradio does not compile

[Albin Stigö]

Yes! It's only complicated to keep it as an internal submodule!

On Wed, May 22, 2019 at 2:11 PM Philip Balister  wrote:
>
> Or use
>
>  -DENABLE_INTERNAL_VOLK=OFF
>
> when you run cmake.
>
> Volk living in and out of the source tree is painful. Time to toss it
> out and let it stand alone! Makes it easier for third party programs to
> actually use it.
>
> Philip
>
> On 05/22/2019 07:37 AM, Ralph A. Schmid, dk5ras wrote:
> > Hi Hans,
> >
> >
> >
> > Did you follow the recommendation from the error message, to check out and
> > enable volk? Then again cmake, make...
> >
> >
> >
> > With best regards
> >
> >
> > Ralph.
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> >
> >
> > Ralph A. Schmid
> >
> > Mondstr. 10
> >
> > 90762 Fürth
> >
> > +49-171-3631223
> >
> > +49-911-21650056
> >
> > ra...@schmid.xxx
> >
> > http://www.bclog.de/
> >
> >
> >
> >
> >
> >
> >
> > From: Discuss-gnuradio
> > [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Hans
> > Kurscheidt
> > Sent: Wednesday, May 22, 2019 1:31 PM
> > To: Discuss-gnuradio@gnu.org
> > Subject: [Discuss-gnuradio] VOLK, gnuradio does not compile
> >
> >
> >
> > Hi,
> >
> > I'm not so sure, if i'm duplicating another issue, but gnuradio does not
> > compile from source. I have
> >
> > libvolk1-bin, libvolk1-dev and libvolk1.3 installed. I also executed  > install mako>; -- no cure
> >
> > Here the log:
> >
> > hk@orangepizero:~/Downloads/gnuradio/build$ cmake ../
> > -- The CXX compiler identification is GNU 6.3.0
> > -- The C compiler identification is GNU 6.3.0
> > -- Check for working CXX compiler: /usr/bin/c++
> > -- Check for working CXX compiler: /usr/bin/c++ -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > -- Detecting CXX compile features
> > -- Detecting CXX compile features - done
> > -- Check for working C compiler: /usr/bin/cc
> > -- Check for working C compiler: /usr/bin/cc -- works
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Detecting C compile features
> > -- Detecting C compile features - done
> > -- Build type not specified: defaulting to release.
> > -- Build type set to Release.
> > -- Found Git: /usr/bin/git
> > -- Extracting version information from git describe...
> > -- Performing Test HAVE_VISIBILITY_HIDDEN
> > -- Performing Test HAVE_VISIBILITY_HIDDEN - Success
> > -- Performing Test HAVE_WARN_SIGN_COMPARE
> > -- Performing Test HAVE_WARN_SIGN_COMPARE - Success
> > -- Performing Test HAVE_WARN_ALL
> > -- Performing Test HAVE_WARN_ALL - Success
> > -- Performing Test HAVE_WARN_NO_UNINITIALIZED
> > -- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
> > -- Compiler Version: cc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
> > Copyright (C) 2016 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > -- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -fvisibility=hidden
> > -Wsign-compare -Wall -Wno-uninitialized
> > /usr/bin/c++:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall
> > -Wno-uninitialized
> > -- ADDING PERF COUNTERS
> > -- Building Static Libraries: OFF
> > -- Looking for pthread.h
> > -- Looking for pthread.h - found
> > -- Looking for pthread_create
> > -- Looking for pthread_create - not found
> > -- Looking for pthread_create in pthreads
> > -- Looking for pthread_create in pthreads - not found
> > -- Looking for pthread_create in pthread
> > -- Looking for pthread_create in pthread - found
> > -- Found Threads: TRUE
> > -- Boost version: 1.62.0
> > -- Found the following Boost libraries:
> > --   date_time
> > --   program_options
> > --   filesystem
> > --   system
> > --   thread
> > --   chrono
> > --   atomic
> > -- Found PythonLibs: /usr/lib/arm-linux-gnueabihf/libpython2.7.so (found
> > suitable version "2.7.13", minimum required is "2")
> > --
> > -- Checking for module SWIG
> > -- Found SWIG version 3.0.10.
> > -- Found SWIG: /usr/bin/swig3.0
> > --
> > -- The build system will automatically enable all components.
> > -- Use -DENABLE_DEFAULT=OFF to disable components by default.
> > --
> > -- Configuring python-support support...
> > --   Dependency PYTHONLIBS_FOUND = TRUE
> > --   Dependency SWIG_FOUND = TRUE
> > --   Dependency SWIG_VERSION_CHECK = TRUE
> > --   Enabling python-support support.
> > --   Override with -DENABLE_PYTHON=ON/OFF
> > -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29")
> > -- Checking for module 'cppunit'
> > --   Found cppunit, version 1.13.2
> > -- Found CPPUNIT: /usr/lib/arm-linux-gnueabihf/libcppunit.so;dl
> > --
> > -- Configuring testing-support support...
> > --   Dependency CPPUNIT_FOUND = TRUE
> > --   Enabling testing-support support.
> > --   Override with -DENABLE_TESTING=ON/OFF
> > --
> > -- Configuring VOLK support...
> > --   VOLK submodule is not checked out.
> > --   To check out the VOLK submodule, use:
> > -- 

Re: [Discuss-gnuradio] UART block in GNU RADIO?

[Albin Stigö]

You mean a block where you input bytes, and the block adds start bit, stop
bit and parity bit(s)?

Albin

On Mon, May 13, 2019, 23:04 mehtap özkan  wrote:

> Well, I would gladly pay for a c++ block. Anyone interested?
>
> 13 May 2019 Pzt 23:40 tarihinde Müller, Marcus (CEL) 
> şunu yazdı:
>
>> I doubt you'd find a ready-made block. However, writing that would take
>> literal minutes in Python or C++!
>>
>> https://wiki.gnuradio.org/index.php/Guided_Tutorials Chapters 2,3,4 and
>> 5 should be an easy read for you at this point.
>>
>> Best regards,
>> Marcus
>>
>> On Mon, 2019-05-13 at 23:09 +0300, mehtap özkan wrote:
>> > Dear All,
>> >  Is there an OOT block where the input is UnPacked Data and the output
>> is UART formatted UnPacked data.
>> > The UART Protocol is shown in
>> http://www.circuitbasics.com/wp-content/uploads/2016/01/Introduction-to-UART-Packet-Frame-and-Bits-2.png
>> .
>> > ___
>> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Two instances of the same custom block walk into a bar

[Albin Stigö]

I absolutely agree with you. There are also other completely unrelated
issues that keep coming up like Linux, python and x11. But I don't think
there's any great harm in ending a topic by ever-so-gently pointing people
in the right direction.

On Thu, May 9, 2019, 22:05 Marcus D. Leech  wrote:

> On 05/09/2019 02:54 PM, Albin Stigö wrote:
>
> Every instance of a block is an instance of the c++ class but like Nick
> says all your variables are static and not member variables. Those need to
> be declared in the header. Your two block instances are referring to the
> same variables and that's why things get messed up.
>
> "A tour of C++" by Bjarne Stroustrup is a good refresher on C++.
>
> --Albin
>
> I'm going to suggest, ever-so-gently, that discuss-gnuradio, and Gnu Radio
> in general aren't the places for learning C++.  There are forums
>   already for that.
>
> I'm saying this only because in the 15 years () I've been involved
> with Gnu Radio, I see an alarming number of cases where the
>   intrepid Gnu Radio developer actually doesn't have much in the way of
> programming experience in the underlying languages used,
>   and arrives here, nearly-certain that their problem is GR related,
> rather than an improper use of the underlying programming language.
>
> My guess is that other specialized-framework environments have the same
> issue.   Fortunately, most people here are helpful regardless.
>   But it shouldn't be a growing *expectation*, IMHO.
>
>
>
> On Thu, May 9, 2019, 20:46 Nick Foster  wrote:
>
>> It looks like you've declared a bunch of static variables within your
>> block's namespace. Those variables (including pointers!) will be shared
>> with every instance of your block. This is Bad News. Those variables should
>> probably all be declared in the header as class member variables.
>>
>> On Thu, May 9, 2019 at 11:43 AM Brad Hein  wrote:
>>
>>> I'm running into a strange issue with a new flow graph [1] I'm working
>>> on that uses a custom C++ block [2] that I built. The block takes input
>>> samples, performs some DSP, and outputs modified samples at the same sample
>>> rate.
>>>
>>> When the flowgraph has a single instance of my custom block enabled, it
>>> works fine. But when I enable a second instance of the block in a separate
>>> second usage, (think stereo sound, one per sink channel) it acts very
>>> unexpectedly - output samples are wildly inaccurate and distorted.
>>>
>>> My perception is that the two instances of the same block seem to be
>>> sharing some part of their memory namespace and as they modify/store
>>> variables they are doing so in some sort of shared namespace or memory
>>> segment.
>>>
>>> Is it possible for two blocks to corrupt each other's memory? I can't
>>> think of any other explanation for the two streams working fine
>>> individually, but when both are enabled at the same time the output is
>>> garbled. I've tried all sorts of things like tying them to the same source
>>> block, removing the upsampling/downsampling, adding a delay to one, etc.
>>> with no luck.
>>>
>>>
>>> [1] "Flowgraph with two parallel streams both using the custom block
>>> pq_rails":
>>> https://github.com/regulatre/gr-powerquality/blob/master/examples/streamer.grc
>>>
>>> [2] "pq_rails (Custom block) source code":
>>> https://github.com/regulatre/gr-powerquality/blob/master/lib/pq_rails_impl.cc
>>>
>>> ___
>>> 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
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> 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

Re: [Discuss-gnuradio] Two instances of the same custom block walk into a bar

[Albin Stigö]

Every instance of a block is an instance of the c++ class but like Nick
says all your variables are static and not member variables. Those need to
be declared in the header. Your two block instances are referring to the
same variables and that's why things get messed up.

"A tour of C++" by Bjarne Stroustrup is a good refresher on C++.

--Albin

On Thu, May 9, 2019, 20:46 Nick Foster  wrote:

> It looks like you've declared a bunch of static variables within your
> block's namespace. Those variables (including pointers!) will be shared
> with every instance of your block. This is Bad News. Those variables should
> probably all be declared in the header as class member variables.
>
> On Thu, May 9, 2019 at 11:43 AM Brad Hein  wrote:
>
>> I'm running into a strange issue with a new flow graph [1] I'm working on
>> that uses a custom C++ block [2] that I built. The block takes input
>> samples, performs some DSP, and outputs modified samples at the same sample
>> rate.
>>
>> When the flowgraph has a single instance of my custom block enabled, it
>> works fine. But when I enable a second instance of the block in a separate
>> second usage, (think stereo sound, one per sink channel) it acts very
>> unexpectedly - output samples are wildly inaccurate and distorted.
>>
>> My perception is that the two instances of the same block seem to be
>> sharing some part of their memory namespace and as they modify/store
>> variables they are doing so in some sort of shared namespace or memory
>> segment.
>>
>> Is it possible for two blocks to corrupt each other's memory? I can't
>> think of any other explanation for the two streams working fine
>> individually, but when both are enabled at the same time the output is
>> garbled. I've tried all sorts of things like tying them to the same source
>> block, removing the upsampling/downsampling, adding a delay to one, etc.
>> with no luck.
>>
>>
>> [1] "Flowgraph with two parallel streams both using the custom block
>> pq_rails":
>> https://github.com/regulatre/gr-powerquality/blob/master/examples/streamer.grc
>>
>> [2] "pq_rails (Custom block) source code":
>> https://github.com/regulatre/gr-powerquality/blob/master/lib/pq_rails_impl.cc
>>
>> ___
>> 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RPi Filesystem Image

[Albin Stigö]

Yeah I think raspbian is built to run on all versions of the raspberry pi
so it's 32 bit and no neon...

I'm running Ubuntu server now built for aarch64 and especially the
improvements in NEON makes it very attractive for SDR indeed..


--Albin

On Wed, May 8, 2019, 19:24 Philip Balister  wrote:

> On 05/08/2019 01:15 PM, Albin Stigö wrote:
> > An official gnuradio raspberry pi image or PPA would be really neat!
> >
> > Raspbian comes with an older version of gnuradio not properly optimized.
>
>
> My understanding Raspbina was bult for the orginal armv6 Pi. The 3 is
> aarch64 which is far more interesting for sdr.
>
> Philip
>
> >
> >
> > --Albin
> >
> > On Wed, May 8, 2019, 18:46 Philip Balister  wrote:
> >
> >> On 05/08/2019 12:09 PM, Ben Hilburn wrote:
> >>> Hi Glen -
> >>>
> >>> We’ve put our event detection on three Raspberry Pi 3B +
> >>>> for confirming events in the forward direction (not side lobes).
> >>>>
> >>>
> >>> Wow, this is really cool. Thanks so much for sharing!
> >>>
> >>>
> >>>> I have a 8 GB image .iso that I could put on line this weekend.
> >>>> Where is appropriate for such large files?  We installed everything
> >>>> on one Pi then just copied the image to the other SD cards.
> >>>>
> >>>
> >>> That would be excellent! Storage & bandwidth are indeed tough, though.
> >>
> >> 8 GB sounds a bit large, they should compress fairly well, especially if
> >> new.
> >>
> >> Ones I did a while back are like 2 GB:
> >>
> >>
> https://www.dropbox.com/sh/fokcr688h2gshxi/AACcv8PUrTaKZoxPlluFxxZPa?dl=0
> >>
> >> Philip
> >>
> >>>
> >>> We (GNU Radio) pay for storage on Google's cloud servers, and we could
> >> host
> >>> it there. Do you have a Google account? If so, and you can upload the
> >> image
> >>> to a Google Drive account and share it with me, I should be able to
> >> easily
> >>> replicate it over to GNU Radio's storage.
> >>>
> >>> Cheers,
> >>> Ben
> >>>
> >>>
> >>>
> >>> ___
> >>> 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
> >>
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RPi Filesystem Image

[Albin Stigö]

An official gnuradio raspberry pi image or PPA would be really neat!

Raspbian comes with an older version of gnuradio not properly optimized.


--Albin

On Wed, May 8, 2019, 18:46 Philip Balister  wrote:

> On 05/08/2019 12:09 PM, Ben Hilburn wrote:
> > Hi Glen -
> >
> > We’ve put our event detection on three Raspberry Pi 3B +
> >> for confirming events in the forward direction (not side lobes).
> >>
> >
> > Wow, this is really cool. Thanks so much for sharing!
> >
> >
> >> I have a 8 GB image .iso that I could put on line this weekend.
> >> Where is appropriate for such large files?  We installed everything
> >> on one Pi then just copied the image to the other SD cards.
> >>
> >
> > That would be excellent! Storage & bandwidth are indeed tough, though.
>
> 8 GB sounds a bit large, they should compress fairly well, especially if
> new.
>
> Ones I did a while back are like 2 GB:
>
> https://www.dropbox.com/sh/fokcr688h2gshxi/AACcv8PUrTaKZoxPlluFxxZPa?dl=0
>
> Philip
>
> >
> > We (GNU Radio) pay for storage on Google's cloud servers, and we could
> host
> > it there. Do you have a Google account? If so, and you can upload the
> image
> > to a Google Drive account and share it with me, I should be able to
> easily
> > replicate it over to GNU Radio's storage.
> >
> > Cheers,
> > Ben
> >
> >
> >
> > ___
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[Albin Stigö]

Thanks for the support!

Regarding your VLF experiments there's an historically interesting VLF
transmitter Grimeton SAQ sometimes active on 17.2kHz.
https://alexander.n.se/the-radio-station-saq-grimeton/saq-transmissions/?lang=en


--Albin

On Wed, May 8, 2019 at 2:34 PM Brad Hein  wrote:
>
> As an avid fan of Raspberry Pi, often putting them to use for DSP 
> applications, I just want to say thank you for your hard work keeping 
> gnuradio working and optimized on the platform!
>
> I've seen some great FET preamp circuits available on the internet, a few of 
> which I've tried out. I'll dust one off and see if I can make it work in this 
> application.
>
>
>
> On Wed, May 8, 2019 at 4:15 AM Albin Stigö  wrote:
>>
>> Hi Brad,
>>
>> Just some random ideas... What you are trying to do is very doable. Ive seen 
>> a lot of people do it for VLF reception... Usually along with some kind of 
>> FET amplifier before the mic...
>>
>> The frequency xlating FIR filter doesn't have great performance on the rbpi 
>> at the moment.
>> The frequency xlating FFT filter would be better in your case.
>>
>> I'm working on a patch that will make these blocks 14 times faster on 
>> raspberry pi so that will also improve things...
>>
>>
>>
>> --Albin
>>
>>
>>
>> On Wed, May 8, 2019, 06:06 Brad Hein  wrote:
>>>
>>>
>>>
>>>
>>> On Tue, May 7, 2019 at 4:19 PM Marcus D. Leech  
>>> wrote:
>>>>
>>>> On 05/07/2019 04:05 PM, Ben Hilburn wrote:
>>>>
>>>> Hey Brad - just checking in! This is an interesting experiment, and I 
>>>> would love to hear how it went!
>>>>
>>>> Big thanks to Kevin and JMF for providing very helpful guidance, here, too 
>>>> =)
>>>>
>>>> Cheers,
>>>> Ben
>>>>
>>>> I should perhaps have entered this discussion earlier, and pointed out one 
>>>> of my early applications using a sound-card for VLF work:
>>>>
>>>> https://github.com/patchvonbraun/SIDSuite
>>>>
>>>> It's OLD now--I don't think it was ever converted to GR 3.7
>>>>
>>>> One of the problems with mag-loop antenna is that they're very high Q, and 
>>>> thus have very small fractional bandwidths, which means that
>>>>   they're wildly inefficient at all but the resonant frequency.  I made up 
>>>> for that using a Behringer microphone pre-amp using the balanced input.
>>>>   That meant I could use a fairly "random" multi-turn mag-loop and not 
>>>> worry about efficiency very much.
>>>>
>>>
>>> Thanks Marcus - I'll see if I can get it to compile again. In the meantime 
>>> I have put together an AM receiver flowgraph using recommendations from 
>>> this thread, along with what I remembered from the gnuradio tutorials and 
>>> Mike Osman's video tutorials.
>>>
>>> https://github.com/regulatre/vlfCoilEperiment
>>>
>>> Given a 5-minute recording, which I included in the repo, I quickly found 
>>> that QRM interference will be a hurdle and as you pointed out Marcus, my 
>>> coil (an old VGA degaussing coil) seems to be resonant at undesirable 
>>> frequencies. In its current installation it's getting overwhelmed by a 
>>> steady interference source that sounds like ripples coming from a 60Hz 
>>> half-wave rectifier. There are some gaps in the noise, and as I tuned 
>>> around within the baseband using my flowgraph (in the repo above), I was 
>>> able to tune to various parts of the baseband, but in all cases I had too 
>>> much interference noise.
>>>
>>> I have a Focusrite Si2 I could use instead, which would have more gain 
>>> potential and a very low noise floor, but first I think I'll need to find a 
>>> way to get away from the noise sources.
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[Albin Stigö]

Hi Brad,

Just some random ideas... What you are trying to do is very doable. Ive
seen a lot of people do it for VLF reception... Usually along with some
kind of FET amplifier before the mic...

The frequency xlating FIR filter doesn't have great performance on the rbpi
at the moment.
The frequency xlating FFT filter would be better in your case.

I'm working on a patch that will make these blocks 14 times faster on
raspberry pi so that will also improve things...



--Albin



On Wed, May 8, 2019, 06:06 Brad Hein  wrote:

>
>
>
> On Tue, May 7, 2019 at 4:19 PM Marcus D. Leech 
> wrote:
>
>> On 05/07/2019 04:05 PM, Ben Hilburn wrote:
>>
>> Hey Brad - just checking in! This is an interesting experiment, and I
>> would love to hear how it went!
>>
>> Big thanks to Kevin and JMF for providing very helpful guidance, here,
>> too =)
>>
>> Cheers,
>> Ben
>>
>> I should perhaps have entered this discussion earlier, and pointed out
>> one of my early applications using a sound-card for VLF work:
>>
>> https://github.com/patchvonbraun/SIDSuite
>>
>> It's OLD now--I don't think it was ever converted to GR 3.7
>>
>> One of the problems with mag-loop antenna is that they're very high Q,
>> and thus have very small fractional bandwidths, which means that
>>   they're wildly inefficient at all but the resonant frequency.  I made
>> up for that using a Behringer microphone pre-amp using the balanced input.
>>   That meant I could use a fairly "random" multi-turn mag-loop and not
>> worry about efficiency very much.
>>
>>
> Thanks Marcus - I'll see if I can get it to compile again. In the meantime
> I have put together an AM receiver flowgraph using recommendations from
> this thread, along with what I remembered from the gnuradio tutorials and
> Mike Osman's video tutorials.
>
> https://github.com/regulatre/vlfCoilEperiment
>
> Given a 5-minute recording, which I included in the repo, I quickly found
> that QRM interference will be a hurdle and as you pointed out Marcus, my
> coil (an old VGA degaussing coil) seems to be resonant at undesirable
> frequencies. In its current installation it's getting overwhelmed by a
> steady interference source that sounds like ripples coming from a 60Hz
> half-wave rectifier. There are some gaps in the noise, and as I tuned
> around within the baseband using my flowgraph (in the repo above), I was
> able to tune to various parts of the baseband, but in all cases I had too
> much interference noise.
>
> I have a Focusrite Si2 I could use instead, which would have more gain
> potential and a very low noise floor, but first I think I'll need to find a
> way to get away from the noise sources.
>
>
>
>
>
> ___
> 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

[Discuss-gnuradio] libvolk NEON support progress update

[Albin Stigö]

Hi,

Just a quick progress update. I have completed NEON support for 34 out
of 74 libvolk kernels that were missing NEON implementations.

Average speedup is around 4x depending on kernel, not very surprising
since NEON SIMD vector size for float32 is 4...

Biggest surprise was volk_32fc_s32fc_x2_rotator_32fc that now is 14x
faster on Raspberry Pi 3b. This is nice because this kernel is used in
the frequently used (pun intended) Frequency Xlating FIR Filter.

https://github.com/gnuradio/volk/issues/243

So far kernels are only available in my (messy) branch but I will
gradually create pull requests into libvolk.


--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Towards NEON completeness in libvolk

[Albin Stigö]

Sorry about the twitter url, here's the link to the issue:

https://github.com/TujaSDR/volk/tree/tuja

On Wed, May 1, 2019, 19:12 Albin Stigö  wrote:

> Hi,
>
> Just a quick update. Good progress today towards NEON SIMD completeness in
> libvolk. Saw a 14x speedup in volk_32fc_s32fc_x2_rotator_32fc on
> RaspberryPi 3b.
>
> Follow my progress here https://t.co/l3SHgeWSqK
>
>
> --Albin, SM6WJM
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Towards NEON completeness in libvolk

[Albin Stigö]

Hi,

Just a quick update. Good progress today towards NEON SIMD completeness in
libvolk. Saw a 14x speedup in volk_32fc_s32fc_x2_rotator_32fc on
RaspberryPi 3b.

Follow my progress here https://t.co/l3SHgeWSqK


--Albin, SM6WJM
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Half band decimator/interpolator

[Albin Stigö]

No problem! Like Marcus says I definitely have to think hard about the
implementation and benchmark... But it's an interesting special case. Would
be neat with a special block for it that also calculates the coefficients.


--Albin

On Wed, Apr 24, 2019, 10:39 Derek Kozel  wrote:

> Oops, accidentally went direct rather than through the list.
>
> It would be a good addition to gr-filter to be able to use the CPU
> operations optimized halfband out of the box.
>
>  Previous message 
> Hi Albin,
>
> The Filter Design Tool will generate Halfband taps that can be loaded into
> the FIR filter block, no need to write one.
>
> The implementation is here:
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/python/filter/design/fir_design.py#L161
>
> What would be an excellent addition would be to move the implementation
> for half-band creation to the firdes class and then have the filter design
> tool call the function, as it does for most (all?) of the other filter
> classes.
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/include/gnuradio/filter/firdes.h#L60
>
> Regards,
> Derek
> 
>
> On 24/04/2019 09:04, Müller, Marcus (CEL) wrote:
>
> Hi Albin,
>
> Don't know what Derek suggested, but be aware that our "straight" FIR
> filter decimators are already polyphase implementations, and use SIMD
> (through VOLK) heavily (run volk_profile if you want to make maximum
> use of that advantage); it might be that on paper, the number of
> operations are unnecessarily high, but in CPU practice, some cures are
> worse than the disease.
>
> For example, I haven't tried, but it's thoroughly possible that albeit
> the classical case of "half your tap memory by only storing one half of
> your symmetrical FIR" performs worse than just working with the full
> (half redundant) tap vector, simply because doing so avoids nonlinear
> memory access patterns.
>
> Best regards,
> Marcus
>
> On Tue, 2019-04-23 at 19:06 +0200, Albin Stigö wrote:
>
> Thanks for the reply Marcus. Interesting approach for sure! Will have to 
> think about it...
>
> Derek, your solution works but it will be 4 times slower than the example I 
> linked to.
>
>
> --Albin
>
>
> On Tue, Apr 23, 2019, 18:24 Müller, Marcus (CEL)  
>  wrote:
>
> Hi Albin,
>
> I'm very very tired right now, but me and Felix came to the following
> conclusions on our *Whiteboard Of Wisdom, Smarts, Expertise,
> Rationality and Science* (WOWSERS):
>
> 1. A Nyquist-M bandpass filter, esp. a halfband, has zeros on every
> other tap – except for the one center tap, which is at the maximum of
> the sinc that you window your prototype filter with.
> 2. you'd thus implement that filter as polyphase filter with two
> different polyphase components:
>   1. one polyphase component that contains all the zeros, and the
>  single center tap that's not
>   2. one component that contains all the non-zero taps
> 3. you'd thus need to "deinterleave" your input stream into two:
>   1. Delay by half the number of taps (and multiply by the maximum
>   2. filter with all the non-zero taps
> 4. sum up the results
>
> So, for all this, we already have blocks – yay!
>
> Best regards,
> Marcus
>
> On Tue, 2019-04-23 at 17:45 +0200, Albin Stigö wrote:
>
> Just checking before I write one, is there a half band decimator/interpolator 
> in gnuradio I haven't been able to find...
>
> Optimized like this:http://liquidsdr.org/doc/resamp2/
>
> Or is there an even better option for interpolation by 2?
>
>
> --Albin
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> 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

Re: [Discuss-gnuradio] Half band decimator/interpolator

[Albin Stigö]

Thanks for the reply Marcus. Interesting approach for sure! Will have to
think about it...

Derek, your solution works but it will be 4 times slower than the example I
linked to.


--Albin


On Tue, Apr 23, 2019, 18:24 Müller, Marcus (CEL)  wrote:

> Hi Albin,
>
> I'm very very tired right now, but me and Felix came to the following
> conclusions on our *Whiteboard Of Wisdom, Smarts, Expertise,
> Rationality and Science* (WOWSERS):
>
> 1. A Nyquist-M bandpass filter, esp. a halfband, has zeros on every
> other tap – except for the one center tap, which is at the maximum of
> the sinc that you window your prototype filter with.
> 2. you'd thus implement that filter as polyphase filter with two
> different polyphase components:
>   1. one polyphase component that contains all the zeros, and the
>  single center tap that's not
>   2. one component that contains all the non-zero taps
> 3. you'd thus need to "deinterleave" your input stream into two:
>   1. Delay by half the number of taps (and multiply by the maximum
>   2. filter with all the non-zero taps
> 4. sum up the results
>
> So, for all this, we already have blocks – yay!
>
> Best regards,
> Marcus
>
> On Tue, 2019-04-23 at 17:45 +0200, Albin Stigö wrote:
> > Just checking before I write one, is there a half band
> decimator/interpolator in gnuradio I haven't been able to find...
> >
> > Optimized like this:
> > http://liquidsdr.org/doc/resamp2/
> >
> > Or is there an even better option for interpolation by 2?
> >
> >
> > --Albin
> > ___
> > 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

[Discuss-gnuradio] Half band decimator/interpolator

[Albin Stigö]

Just checking before I write one, is there a half band
decimator/interpolator in gnuradio I haven't been able to find...

Optimized like this:
http://liquidsdr.org/doc/resamp2/

Or is there an even better option for interpolation by 2?


--Albin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] forum to learn more about signal-processing and SDR ?

[Albin Stigö]

This book is a very good starting point:

http://www.dspguide.com

dsp.stackexchange.com is a good place for questions.

Good luck.

Albin SM6WJM

On Sat, Mar 16, 2019, 22:20 Kristoff  wrote:

> Hi,
>
>
> One of the reasons I am currently using GNU Radio is to learn more about
> signal-processing and SDR.
>
> As the "discuss-gnuradio" list is about gnuradio itself, what would be a
> good mailing-list, newsgroup or forum to ask more generic questions
> about signal-processing?
>
>
>
>
> Kristoff (ON1ARF)
>
>
> ___
> 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

Re: [Discuss-gnuradio] Moving my antenna

[Albin Stigö]

Loss will be proportional to the length of coax, type of coax, impedenace
match and frequency. Higher frequency, higher loss. For example at 10MHz
the loss in in 100m RG58 would be around 3.7dB, at 1000MHz 48dB, a factor
27000 difference.

It's normally best practice to put the receiver/transmitter as close to the
antenna as possible.


--Albin

On Tue, Jan 29, 2019, 21:07 Tarquin  Hi
>
>
>
> If you want to go “cheap” use coax intended for satellite TV reception. Be
> carefull about 75ohm, as the Hack RF is a 50 ohm system, you can use RG58U
> not to costly, don’t expect good performance above 1.2 GHz. Not sure what
> you want to intercept, if it VHF UHF you will be ok, else you could try
> RG213 but that ½ inch thich and you will have to adapt.
>
>
>
> The thinner coax RG179 /178 will be fairly lossy.
>
>
>
> I suggest personaly start with RG58 its cost effective and maybe an LNA
> near the antenna
>
>
>
> Regards
>
>
>
> Zr1tR
>
>
>
> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+tarquin.roode=
> gmail@gnu.org] *On Behalf Of *david vanhorn
> *Sent:* Tuesday, January 29, 2019 9:52 PM
> *To:* cliff palmer
> *Cc:* Discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Moving my antenna
>
>
>
> Coax loss can be a big issue.
>
> Given the low power levels you will suffer less loss on a long run using
> 75 ohm coax cable which is designed for low loss, even assuming you do
> nothing about the mismatch at the ends of the run.  All that is good up to
> about 1ghz where more specialized coax is needed for minimum loss.
>
>
>
> The antenna is a significant part of the equation and you are well advised
> to use an antenna suited for the frequency of interest. Broadband antennas
> like discones have very low gain, and they pull in other strong signals you
> don't want.
>
>
>
> On Tue, Jan 29, 2019, 12:40 PM cliff palmer 
> I have a HackrfOne with an Ant500 antenna connected to my workstation in
> my basement (where the internet connection lives).  I need to move the
> antenna out of the basement to improve reception, so I thought I would use
> coax to connect the antenna from upstairs to the HackrfOne.
>
> I'm too new to SDR to be confident about just moving the antenna and using
> a spare length of cable coax.  Please provide some help on selecting,
> sizing and connecting coax between the HackrfOne and the Ant500.
>
> Thanks
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> 
>  Virus-free.
> www.avg.com
> 
> <#m_-7042655357582419932_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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

Re: [Discuss-gnuradio] How's volk doing?

[Albin Stigö]

Hi Michael,

Thanks for the feedback! As per your request I have rebased into three PRs:

https://github.com/gnuradio/volk/pull/226
https://github.com/gnuradio/volk/pull/225
https://github.com/gnuradio/volk/pull/224

Hope someone will have a look at them! They are necessary for building
with clang.


--Albin

On Fri, Dec 28, 2018 at 3:38 PM Michael Dickens
 wrote:
>
> Hi Albin - Thank you for all of your work here! I haven't tested it out, but 
> reading through it (and other PRs) you're really helping Volk along for NEON.
>
> I'm not going to review this PR, just comment about PRs in general ... for 
> now.
>
> In general for GR / Volk PRs: Keep them targeted and simple; a single topic 
> is best if at all possible. You can make one PR require another one, in order 
> to keep complexity of any specific PR down.
>
> If a given PR has multiple topics, please make them different commits. A 
> single commit with multiple topics is very unlikely to be committed.
>
> Thus for this specific PR, I'd advise you to split off each topic into a 
> different PR:
>
> + Removed duplicate symbol in volk_16i_max_star_horizontal_16i.s
>
> + Fixed old syntax in volk_16i_max_star_horizontal_16i.s
>
> + Added clang to gen/archs.xml
>
> + Append CMAKE_ASM_FLAGS to ARCH_ASM_FLAGS (for cross compilation)
>
> + Added overrules avx512f avx512cd
>
> + Don't overwrite CMAKE_ASM_FLAGS
>
> In this manner, we can determine the validity of each commit / PR. You can 
> note in any specific PR that it depends on some other PR; that's totally OK & 
> we'll work with them to get things going.
>
> Anyway that's my $0.02 worth on the matter. Thanks again for heading down 
> this path! - MLD
>
> On Fri, Dec 28, 2018, at 3:25 AM, Albin Stigö wrote:
> > Maybe some of you have noticed that I've been working on getting volk
> > 1.4 and gnuradio 3.8 to compile and cross compile for ARM with clang
> > (specifically clang 7 but seems to work down to at least 3.8).
> >
> > I'm happy to say that it's working pretty well now! Volk with neon
> > support works and most of gnuradio compiles without any problems.
> >
> > I've uncovered some small bugs/quirks in the process and have
> > submitted a bunch of issues and a pull request to volk:
> > https://github.com/gnuradio/volk/pull/223
> >
> > Volk currently has 11 open pull requests, some without any response
> > from the maintainers, which leads me to my question: How's volk doing?
> > Are more maintainers/testers needed in some specific area?
> >
> > --Albin
> >
> > ___
> > 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

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How's volk doing?

[Albin Stigö]

Maybe some of you have noticed that I've been working on getting volk
1.4 and gnuradio 3.8 to compile and cross compile for ARM with clang
(specifically clang 7 but seems to work down to at least 3.8).

I'm happy to say that it's working pretty well now! Volk with neon
support works and most of gnuradio compiles without any problems.

I've uncovered some small bugs/quirks in the process and have
submitted a bunch of issues and a pull request to volk:
https://github.com/gnuradio/volk/pull/223

Volk currently has 11 open pull requests, some without any response
from the maintainers, which leads me to my question: How's volk doing?
Are more maintainers/testers needed in some specific area?


--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNURadio on ARM and rbpi3 in particular with clang7

[Albin Stigö]

Merry Christmas everyone,

In between the festivities I've been pretty busy trying to compile,
and cross compile, GNURadio and volk for ARM with clang 7. Here is a
rough guide on how to do it.

https://github.com/TujaSDR/gnuradio-rbpi3

Found some issues in the process and have submitted bug reports. This
one in particular:
https://github.com/gnuradio/volk/issues/221


Happy new year,
Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Libvolk license compatability

[Albin Stigö]

There is the MIT neon-math library which includes a lot of the functions
missing NEON versions in volk. My understanding of GPL v3 and MIT is that
it's ok to include MIT code in GPL code as long as you retain the license
text?

https://code.google.com/archive/p/math-neon/


--Albin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] libvolk development

[Albin Stigö]

Absolutely!

Here are three kernels I wrote today, more to follow.
https://github.com/TujaSDR/libtujavolk/blob/master/libtujavolk/tujavolk.c

I'd be more than happy if someone could assist me with a proper code
review and maybe even putting them into libvolk.


--Albin

On Fri, Dec 21, 2018 at 1:25 PM Philip Balister  wrote:
>
> On 12/21/2018 03:01 AM, Albin Stigö wrote:
> > Hi GNURadio/libvolk friends,
> >
> > I've started filling in the gaps in the in the libvold SIMD matrix
> > http://libvolk.org/platforms.html, for NEON.
> >
> > Just don't want to step on someone's toes, is anyone else working on
> > this, NEON specifically.
>
> If possible can you use intrinsics so the same code can run on armv7 and
> armv8?
>
> Philip
>
> >
> >
> > --Albin
> >
> > ___
> > 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

[Discuss-gnuradio] libvolk development

[Albin Stigö]

Hi GNURadio/libvolk friends,

I've started filling in the gaps in the in the libvold SIMD matrix
http://libvolk.org/platforms.html, for NEON.

Just don't want to step on someone's toes, is anyone else working on
this, NEON specifically.


--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Lock/unlock?

[Albin Stigö]

Does calling lock/unlock on a top block call the stop method on connected
blocks? And does it flush/empty buffers?


--Albin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Half duplex flowgraph

[Albin Stigö]

Hi GNURadio folks,

I'm hacking on a small half duplex (classic ptt) transceiver
application using GNUradio as backend and I'm looking for the best way
for switching between two flowgraphs?

Is it necessary to lock()-reconfigure-runlock() or is there some
clever way of having two separate flowgraphs and enable only one of
them for rx/tx.


--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP sink that respects PDU? SOCK_SEQPACKET?

[Albin Stigö]

> Great, now I'll have to check the actual state of SOCK_SEQPACKET on
> Linux on an international flight.

SCTP is the greatest thing before sliced bread that never really
happened... it works on the Internet but A LOT of consumer routers
doesn't support it.

Probably should have mentioned I wanted SOCK_SEQPACKET for local
transport. I'm writing a little web frontend for a flow graph so that
I can listen to it at work. I wrote an Opus Encoder block. Then I will
write the packets to a unix domain socket (SOCK_SEQPACKET) and stream
them over websockets. RTP would be better but WebRTC is a hot mess and
our corporate firewall is nasty. I just want something simple like
WebSDR (but with libopus in the browser, compiled as WebAssembly).


--Albin
On Mon, Oct 1, 2018 at 1:34 AM Müller, Marcus (CEL)  wrote:
>
> Great, now I'll have to check the actual state of SOCK_SEQPACKET on
> Linux on an international flight.
> On Mon, 2018-10-01 at 00:04 +0200, Sylvain Munaut wrote:
> > Hi,
> >
> > > IIRC, the SOCK_SEQPACKET packet type paradigm never had a IP-based
> > > protocol that could be used across commodity networks (unlike
> > > SOCK_DGRAM, which pretty much defaults to UDP and SOCK_STREAM,
> > > which
> > > pretty much defaults to TCP).
> >
> > Err ... what about SCTP ?
> >
> > Cheers,
> >
> > Sylvain
> >
> > ___
> > 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

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UDP sink that respects PDU? SOCK_SEQPACKET?

[Albin Stigö]

Hi GNURadio friends,

Is there a UDP sink that respects PDUs, ie that is based on tagged_stream_block?

Is there a sink that uses SOCK_SEQPACKET?


--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC18] gr-modtool overhaul: Blog updates

[Albin Stigö]

Swapnil,

This sounds really great! I'm excited to see what you come up with!


Albin

On Sat, May 12, 2018, 15:49 swapnil negi  wrote:

> Hi everyone,
> I have updated the blog  for the Week 0
> updates and the tasks for week 1. Here
>  is the link to the
> project with week 1 milestones.
>
> I am highly excited about the coding period. Please help me out with this
> issue  regarding the
> compilation error of GNU Radio.
>
>
>
> Thanks,
> Swapnil Negi
> Indian Institute of Technology Roorkee
> ___
> 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

Re: [Discuss-gnuradio] RTP block / Opus vocoder

[Albin Stigö]

Hi Adrian,

UDP and RTP adds a lot of overhead to a codec like Codec2 and doesn't
make any sense at all unless you wan't to route your packets over an
IP WAN like the internet. Then it makes a lot of sense.

I imagine the only use case for an RTP/Codec2 or RTP/Opus block is
streaming audio from a remote receiver/transceiver over an existing IP
network. If you only stream over LAN, UDP is good enough but the
Internet an stack RTP is better. All streaming software like skype,
facetime, hangouts etc use RTP.


--Albin SM6WJM

On Thu, May 10, 2018 at 10:05 PM, Adrian Musceac  wrote:
>>
>> We would like to combine Opus/CODEC2 and RTP multicast to have stereo field
>> audio. The sources of the audio appear at different points in the stereo
>> field, so that a roundtable conversation feels more like a roundtable, or
>> so that two streams from two different SDRs are distinct.
>>
>
> Hi Michelle,
>
> This is very interesting to me. I did some work with Codec2, Opus and
> GNU Radio myself.
> I'm curious though: RTP and UDP + IP encapsulation, isn't that a bit
> too much overhead for a low bitrate codec like Codec2? A 40 msec audio
> frame encoded with Codec2 1400 is only 48 bits, so the encapsulation
> overhead is quite large. How does that affect low SNR performance?
>
> Regards,
> Adrian YO8RZZ
>
> ___
> 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

Re: [Discuss-gnuradio] RTP block / Opus vocoder

[Albin Stigö]

Hi Michelle,

Well my need for RTP/Opus is because of a Raspberry Pi FPGA based
shortwave transceiver for remote ham radio I'm building together with
Daniel, sm6vfz.

Today I sat down and wrote an RTP/Opus sink block and I have to say
it's working really well. I'm using libopus and jrtplib. My original
plan was to create two blocks: an Opus vocoder and and an RTP block
but after a while I found that that didn't make a lot of sense. RTP is
not designed to be a standalone protocol and is very application
specific. So in the end I wrote a combined block. It's probably not
more than 100 lines of C++ more than the boilerplate. Of course I will
have to add a bit more to make it fully configurable. I also haven't
written the xml for grc yet.

I will of course open source my work when I'm a bit further...

Next on my list is to add clock drift compensation on the alsasink.


--Albin SM6WJM

On Thu, May 10, 2018 at 4:54 PM, Michelle Thompson
<mountain.miche...@gmail.com> wrote:
> Hi Albin,
>
> We have a similar interest in getting RTP functionality in GNU Radio.
>
> Phil Karn recently wrote and published an SDR package for Phase 4 Ground
> that includes RTP multicast functionality. We have been talking about
> getting this functionality into GNU Radio. Another person interested in
> seeing this happen is David Rowetel from FreeDV. He and Phil have started
> talking about this.
>
> Ron and Marcus are of course correct in that RTP streams are already handled
> pretty well in GNU Radio. No, we do not want to reinvent the wheel.
>
> We would like to combine Opus/CODEC2 and RTP multicast to have stereo field
> audio. The sources of the audio appear at different points in the stereo
> field, so that a roundtable conversation feels more like a roundtable, or so
> that two streams from two different SDRs are distinct.
>
> Everyone is welcome to comment and contribute. The repository with the RTP
> multicast code from Phil Karn is here:
> https://github.com/phase4ground/ka9q-sdr
>
> If it can be done without a new block, then great. If there is value in
> handling bookkeeping, or functions in RTP multicast that would be much
> easier or much more useful in flowgraphs with a new block, then that's what
> we want to do. I have advice that it would be useful to get it into blocks.
> We want to do the right thing and we want comment and critique.
>
> Phase 4 Ground will have a "block party" at GNU Radio Conference 2018. The
> overall goal of Phase 4 Ground is to get DVB-S2 and DVB-S2X receive in GNU
> Radio. We have a dedicated room/lab for the week of the conference and will
> bring as much test equipment as we can fit into a minivan. Several
> satellite/modem/DVB docents have signed up and we're working on swag! If you
> have interest or expertise in any area of DVB-S2 receiver design, then we
> enthusiastically welcome you. We have a Slack and a mailing list.
> https://lists.openresearch.institute/
>
> One of the hard parts of the receiver is the LDPC FEC decode. We have one
> working implementation from Charles Brain, written for a GPU. It needs some
> work to get adaptive coding and modulation (we want ACM) working due to the
> architectural choices. It's a big achievement and it puts success more
> within reach. There are other hard parts in this receiver, but LDPC is
> challenging work. Having an open source version is a big step forward.
>
> Aside from ACM, we want to use generic stream encapsulation or GSE, which
> replaces the MPEG transport layer with a protocol that supports, well, you
> guessed it, generic data. This makes the downlink much more useful as a
> multiple access amateur radio system, which is where we're trying to go with
> all this work. Several of us have contributed GSE work that can be found in
> Wireshark and in GNU Radio, so working with GSE streams can be easier.
>
> -Michelle W5NYV
>
> "Potestatem obscuri lateris nescis."
>
>
> On Wed, May 9, 2018 at 9:54 AM, Albin Stigö <albin.st...@gmail.com> wrote:
>>
>> I'm looking specifically to improve the audio streaming of the GQRX
>> program which is based on gnuradio so it needs to be a block. I'll
>> experiment and see if I can come up with something useful.
>>
>> Thanks for all the suggestions though!
>>
>>
>> Albin
>>
>>
>> On Wed, May 9, 2018, 18:30 Müller, Marcus (CEL) <muel...@kit.edu> wrote:
>>>
>>> Well, I think you and Ron basically recommend the same functionality,
>>> but Ron is hesitant to reinvent the wheel:
>>>
>>> For local transport, UDP between your flowgraph and VLC works just
>>> fine. Also fine would be simply using a named pipe (FIFO, as in `man
>>> mkfifo`, if you're on something vague

Re: [Discuss-gnuradio] RTP block / Opus vocoder

[Albin Stigö]

I'm looking specifically to improve the audio streaming of the GQRX program
which is based on gnuradio so it needs to be a block. I'll experiment and
see if I can come up with something useful.

Thanks for all the suggestions though!


Albin

On Wed, May 9, 2018, 18:30 Müller, Marcus (CEL) <muel...@kit.edu> wrote:

> Well, I think you and Ron basically recommend the same functionality,
> but Ron is hesitant to reinvent the wheel:
>
> For local transport, UDP between your flowgraph and VLC works just
> fine. Also fine would be simply using a named pipe (FIFO, as in `man
> mkfifo`, if you're on something vaguely resembling UNIX) and a simple
> file sink (or source).
>
> Then, use VLC to receive those UDP packets containing raw samples, and
> encode them with Opus, and encapsulate them with RTP. (In the opposite
> direction, use VLC to receive an RTP stream, decompress the audio to
> raw audio samples, and send them via UDP to your flow graph)
>
> That would alleviate the need to have all this in a block, and test it
> yourself.
>
> Best regards,
> Marcus
>
> On Wed, 2018-05-09 at 12:30 +0200, Albin Stigö wrote:
> > >  RTP is encapsulated in UDP. If you send an RTP stream to the GNU
> Radio UDP block, you will get an RTP stream.
> >
> > Exactly. But do you know if there already is a project to handle RTP
> bookkeeping..? Otherwise I will start one. RTP is very application specific
> but I'm looking to implement raw audio and opus. I'll try to make it
> modular so that others can be built on top.
> >
> > --Albin
> >
> >
> > On Wed, May 9, 2018, 10:38 Ron Economos <w...@comcast.net> wrote:
> > > RTP is encapsulated in UDP. If you send an RTP stream to the GNU Radio
> > > UDP block, you will get an RTP stream.
> > >
> > > VLC is just a suggestion. It can send RTP containing Opus.
> > >
> > > Ron
> > >
> > > On 05/09/2018 01:10 AM, Albin Stigö wrote:
> > > > Well RTP provides important functionality when streaming over the
> > > > internet. Especially time stamping and sequence numbering which
> allows
> > > > to reassemble out of order data (UDP provides no such guarantee) and
> > > > adjustment for clock drift which, among other things, allows you to
> > > > keep the receiver buffer smaller for "real time" tuning.
> > > >
> > > > RTP also provides a "telemetry" channel over RTCP for network
> statistics.
> > > >
> > > > Not sure why you assume I will use VLC?
> > > >
> > > > Of course if you are just streaming over a LAN raw UDP might be ok
> > > > since the risk of out of order packets is essentially zero.
> > > >
> > > >
> > > > --Albin
> > > >
> > > >
> > > > On Wed, May 9, 2018 at 9:35 AM, Ron Economos <w...@comcast.net>
> wrote:
> > > >> RTP runs over UDP. Why would you need a block? Just let VLC do all
> the dirty
> > > >> work.
> > > >>
> > > >> Ron
> > > >>
> > > >>
> > > >> On 05/08/2018 11:59 PM, Albin Stigö wrote:
> > > >>> Hi all,
> > > >>>
> > > >>> Is there an RTP (real time protocol) streaming block? I know about
> the
> > > >>> UDP block but I want RTP/RTCP.
> > > >>>
> > > >>> If not I will start writing one... Just don't want to start a new
> > > >>> project if there already is one.
> > > >>>
> > > >>> Also, what happened to Opus in the gr-vocoder? Thinking about
> writing
> > > >>> an opus block as well.
> > > >>>
> > > >>> The goal is streaming opus encoding audio from gnuradio from remote
> > > >>> locations.
> > > >>>
> > > >>>
> > > >>> --Albin
> > > >>>
> > > >> ___
> > > >> 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
> > >
> > >
> > > ___
> > > 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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] I miss the TCP server and client blocks!

[Albin Stigö]

You haven't looked writing an RTP block by any chance? Thinking about
writing one...

Albin

On Wed, May 9, 2018, 16:24 Michael Piscopo  wrote:

> I felt the same way so I rewrote the TCP blocks in C++/boost with thread
> offloading a while back.  The package should be in pybombs but you can get
> it here https://github.com/ghostop14/gr-grnet.  Just basic TCP
> send/receive to replace the deprecated blocks.  Hopefully it helps.
>
> Mike
>
>
> On Wed, May 9, 2018 at 12:35 AM, Dan CaJacob 
> wrote:
>
>> Yeah, use the ZeroMQ blocks.
>>
>> On Wed, May 9, 2018 at 12:01 AM Brad Hein  wrote:
>>
>>> Trying to get the socket PDU blocks to send and receive a stream of data
>>> is proving to be a significant challenge. I miss the simplicity and
>>> reliability of the TCP server and client blocks - they always "just worked"
>>> for me. I don't understand why they were deprecated only to leave us with
>>> these buggy and difficult to use socket PDU blocks.
>>>
>>> Sorry for the rant, I'm just running into one problem after another
>>> trying to get two flowgraphs to communicate using the socket PDU blocks
>>> (issue IDs 1770,1769,1763,1762).
>>>
>>> These new ZeroMQ blocks look cool. Are they a good alternative?
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>> --
>> Very Respectfully,
>>
>> Dan CaJacob
>>
>> ___
>> 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RTP block / Opus vocoder

[Albin Stigö]

>  RTP is encapsulated in UDP. If you send an RTP stream to the GNU Radio
UDP block, you will get an RTP stream.

Exactly. But do you know if there already is a project to handle RTP
bookkeeping..? Otherwise I will start one. RTP is very application specific
but I'm looking to implement raw audio and opus. I'll try to make it
modular so that others can be built on top.

--Albin


On Wed, May 9, 2018, 10:38 Ron Economos <w...@comcast.net> wrote:

> RTP is encapsulated in UDP. If you send an RTP stream to the GNU Radio
> UDP block, you will get an RTP stream.
>
> VLC is just a suggestion. It can send RTP containing Opus.
>
> Ron
>
> On 05/09/2018 01:10 AM, Albin Stigö wrote:
> > Well RTP provides important functionality when streaming over the
> > internet. Especially time stamping and sequence numbering which allows
> > to reassemble out of order data (UDP provides no such guarantee) and
> > adjustment for clock drift which, among other things, allows you to
> > keep the receiver buffer smaller for "real time" tuning.
> >
> > RTP also provides a "telemetry" channel over RTCP for network statistics.
> >
> > Not sure why you assume I will use VLC?
> >
> > Of course if you are just streaming over a LAN raw UDP might be ok
> > since the risk of out of order packets is essentially zero.
> >
> >
> > --Albin
> >
> >
> > On Wed, May 9, 2018 at 9:35 AM, Ron Economos <w...@comcast.net> wrote:
> >> RTP runs over UDP. Why would you need a block? Just let VLC do all the
> dirty
> >> work.
> >>
> >> Ron
> >>
> >>
> >> On 05/08/2018 11:59 PM, Albin Stigö wrote:
> >>> Hi all,
> >>>
> >>> Is there an RTP (real time protocol) streaming block? I know about the
> >>> UDP block but I want RTP/RTCP.
> >>>
> >>> If not I will start writing one... Just don't want to start a new
> >>> project if there already is one.
> >>>
> >>> Also, what happened to Opus in the gr-vocoder? Thinking about writing
> >>> an opus block as well.
> >>>
> >>> The goal is streaming opus encoding audio from gnuradio from remote
> >>> locations.
> >>>
> >>>
> >>> --Albin
> >>>
> >> ___
> >> 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
>
>
> ___
> 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

Re: [Discuss-gnuradio] RTP block / Opus vocoder

[Albin Stigö]

Well RTP provides important functionality when streaming over the
internet. Especially time stamping and sequence numbering which allows
to reassemble out of order data (UDP provides no such guarantee) and
adjustment for clock drift which, among other things, allows you to
keep the receiver buffer smaller for "real time" tuning.

RTP also provides a "telemetry" channel over RTCP for network statistics.

Not sure why you assume I will use VLC?

Of course if you are just streaming over a LAN raw UDP might be ok
since the risk of out of order packets is essentially zero.


--Albin


On Wed, May 9, 2018 at 9:35 AM, Ron Economos <w...@comcast.net> wrote:
> RTP runs over UDP. Why would you need a block? Just let VLC do all the dirty
> work.
>
> Ron
>
>
> On 05/08/2018 11:59 PM, Albin Stigö wrote:
>>
>> Hi all,
>>
>> Is there an RTP (real time protocol) streaming block? I know about the
>> UDP block but I want RTP/RTCP.
>>
>> If not I will start writing one... Just don't want to start a new
>> project if there already is one.
>>
>> Also, what happened to Opus in the gr-vocoder? Thinking about writing
>> an opus block as well.
>>
>> The goal is streaming opus encoding audio from gnuradio from remote
>> locations.
>>
>>
>> --Albin
>>
>
> ___
> 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

[Discuss-gnuradio] RTP block / Opus vocoder

[Albin Stigö]

Hi all,

Is there an RTP (real time protocol) streaming block? I know about the
UDP block but I want RTP/RTCP.

If not I will start writing one... Just don't want to start a new
project if there already is one.

Also, what happened to Opus in the gr-vocoder? Thinking about writing
an opus block as well.

The goal is streaming opus encoding audio from gnuradio from remote locations.


--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help decoding Bell 202

[Albin Stigö]

For anyone working with APRS Stephen (wa8lmf) has put together a
downloadable cd image with a lot of test data. Not in quadrature, but
that's maybe something Hilbert can take care of.

http://wa8lmf.net/TNCtest/

# Get it with wget.
$ wget http://www.argentdata.com/files/tnc_test_cd_ver1.0.zip

# Convert the tracks to wave format with the bchunk utility (search
your packet manager or homebrew).
$ bchunk -w TNC_Test_Ver-1.1.bin TNC_Test_Ver-1.1.cue TNC_Test_Ver-1.1.iso


--Albin

On Mon, Dec 28, 2015 at 2:07 AM, En Shih  wrote:
> Thanks, Tim. That really clarified a lot of confusion that I had!
>
> I have uploaded the files here:
> https://drive.google.com/folderview?id=0B5T4PFVUKZgmcXlTWnV0VzZFQTg=sharing
> 
> -"bell202new.grc" is the current flow graph.
> -"dump" is how the input signal I'm trying to decode looks like.
> -"decoded" is the bytes of a successfully decoded signal, which was decoded
> previously using some hardware equipment. (some parts of the data may be
> corrupted)
> -"imet.pdf" explains the data packet.
> -"tcp.py" explains the data packet.
>
> As far as I know, at the physical layer the data is modulated using Bell
> 202. The data framing is not AX.25, but conforms to UART, although I'm
> unsure about the parity and stop bits. I tried looking for the data frames
> by looking for start/stop bits, the header. I've also tried flipping the
> bits. However, it still doesn't look quite right.
>
> Correct me if I'm wrong: your FSK demod block uses tone detection to
> demodulate, which is passing the signal through two band pass filters in
> parallel, and determine which comes through (as in p.9 of
> http://edge.rit.edu/edge/P09141/public/FSK.pdf)
>
> Regards,
> En Shih
>
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Help-decoding-Bell-202-tp57483p57503.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> 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

Re: [Discuss-gnuradio] Help decoding Bell 202

[Albin Stigö]

En Shih,

> I tried looking for the data frames
> by looking for start/stop bits, the header. I've also tried flipping the
> bits. However, it still doesn't look quite right.

Packet uses NRZI (non-return to zero inverted) encoding, which means
that a 0 is encoded as a change in tone, and a 1 is encoded as no
change in tone. You are probably looking for the change in bit rather
than the actual bits, that could explain why your data is a bit off.

There's a good summary here: http://n1vg.net/packet/

--Albin

On Mon, Dec 28, 2015 at 10:54 AM, Albin Stigö <albin.st...@gmail.com> wrote:
> For anyone working with APRS Stephen (wa8lmf) has put together a
> downloadable cd image with a lot of test data. Not in quadrature, but
> that's maybe something Hilbert can take care of.
>
> http://wa8lmf.net/TNCtest/
>
> # Get it with wget.
> $ wget http://www.argentdata.com/files/tnc_test_cd_ver1.0.zip
>
> # Convert the tracks to wave format with the bchunk utility (search
> your packet manager or homebrew).
> $ bchunk -w TNC_Test_Ver-1.1.bin TNC_Test_Ver-1.1.cue TNC_Test_Ver-1.1.iso
>
>
> --Albin
>
> On Mon, Dec 28, 2015 at 2:07 AM, En Shih <seanstone5...@gmail.com> wrote:
>> Thanks, Tim. That really clarified a lot of confusion that I had!
>>
>> I have uploaded the files here:
>> https://drive.google.com/folderview?id=0B5T4PFVUKZgmcXlTWnV0VzZFQTg=sharing
>> <https://drive.google.com/folderview?id=0B5T4PFVUKZgmcXlTWnV0VzZFQTg=sharing>
>> -"bell202new.grc" is the current flow graph.
>> -"dump" is how the input signal I'm trying to decode looks like.
>> -"decoded" is the bytes of a successfully decoded signal, which was decoded
>> previously using some hardware equipment. (some parts of the data may be
>> corrupted)
>> -"imet.pdf" explains the data packet.
>> -"tcp.py" explains the data packet.
>>
>> As far as I know, at the physical layer the data is modulated using Bell
>> 202. The data framing is not AX.25, but conforms to UART, although I'm
>> unsure about the parity and stop bits. I tried looking for the data frames
>> by looking for start/stop bits, the header. I've also tried flipping the
>> bits. However, it still doesn't look quite right.
>>
>> Correct me if I'm wrong: your FSK demod block uses tone detection to
>> demodulate, which is passing the signal through two band pass filters in
>> parallel, and determine which comes through (as in p.9 of
>> http://edge.rit.edu/edge/P09141/public/FSK.pdf)
>>
>> Regards,
>> En Shih
>>
>>
>>
>>
>> --
>> View this message in context: 
>> http://gnuradio.4.n7.nabble.com/Help-decoding-Bell-202-tp57483p57503.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>> ___
>> 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

Re: [Discuss-gnuradio] VFO tuning knobs

[Albin Stigö]

Lots of people are building their own with a microcontroller and some
kind of rotary encoder. One super easy way is to use the teensy
arudino clone (or similar) since they already have libraries for USB
HID so you can make your scroll wheel act like a mouse scroll wheel.

Rotary encoders exist in many different qualities. Optical rotary
encoders are really nice, and expensive.

I've also seen people using stepper motors as encoders.

--Albin

On Mon, Dec 28, 2015 at 12:33 PM, Daniel Pocock  wrote:
>
> I realize that SDR provides more than one way to view the spectrum and
> tune to a frequency, but I can imagine some people feeling comfortable
> with a tuning knob similar to a traditional radio.  There doesn't appear
> to be any technical reason why a VFO knob could not be part of an SDR
> application.
>
> A quick Google search for USB VFO tuning knobs found these links:
>
> http://df3cb.com/ft2000rc/documentation/interfaces/flexcontrol.php
>
> http://www.eham.net/articles/21941
>
> Has anybody tried anything like this with GNU Radio?
>
> Regards,
>
> Daniel
>
> ___
> 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

[Discuss-gnuradio] gnuradio-companion development

[Albin Stigö]

Hi,

Is there a separate list for gnuradio-companion development? I'm
interested in taking part...

--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion development

[Albin Stigö]

Ok, great to know there are some other mac users... I have
reimplemented some blocks using Apples Accelerate framework..
theoretically they should perform better on apple hardware although I
havn't done any benchmarks. I will try to release those...

Also knowing there are other mac users will definitely provide some
motivation :-)

--Albin

On Thu, Jul 30, 2015 at 8:31 PM, Tom Rondeau t...@trondeau.com wrote:
 On Thu, Jul 30, 2015 at 1:21 PM, Albin Stigö albin.st...@gmail.com wrote:

 Hi Seth,

 I'm fairly new to gnuradio but I've spent the last couple of weeks
 digging through the code of the runtime and grc. GRC doesn't work that
 well on my macbook because of issues with qt and gtk2 (especially
 hidpi retina displays)...

 I suspect there are very few gnuradio users on mac but I became
 interested in writing a Cocoa port of grc, if only for learning more
 about SDR (this is a hobby for me). Cocoa is very well suited for
 writing these kinds of visual applications (unfortunately they are not
 really portable, or very limited so, using gnustep)



 Not true. Quite a few mac users.



 A QT port sounds really interesting as the model layer could be
 separated and reused in a Cocoa app.

 It would also be really neat if it was possible to test the flow graph
 directly/dynamically without using python (dynamically build it in gcc
 using the c++ api, perhaps in a separate process)... Although I
 realize this is a much larger undertaking.

 I recently found this and thought it was quite inspiring (web app):
 http://www.pjrc.com/teensy/gui/

 --Albin


 A principle of the redesign is to separate the GUI elements from the actual
 methods, so yes, hopefully this leads into an easier way to redesign to GUI
 part for more native support in, say, OS X.

 Tom




 On Thu, Jul 30, 2015 at 6:04 PM, Seth Hitefield sd...@vt.edu wrote:
  Albin,
 
  What part are you looking to work on? I think there are a few new
  features being worked on for the current version, and Hopefully we are 
  going
  to start ramping up on the qt port again soon.
 
  -- Seth
 
  Sent from my iPhone
 
  On Jul 30, 2015, at 11:11 AM, Albin Stigö albin.st...@gmail.com
  wrote:
 
  Hi,
 
  Is there a separate list for gnuradio-companion development? I'm
  interested in taking part...
 
  --Albin
 
  ___
  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



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion development

[Albin Stigö]

Hi Seth,

I'm fairly new to gnuradio but I've spent the last couple of weeks
digging through the code of the runtime and grc. GRC doesn't work that
well on my macbook because of issues with qt and gtk2 (especially
hidpi retina displays)...

I suspect there are very few gnuradio users on mac but I became
interested in writing a Cocoa port of grc, if only for learning more
about SDR (this is a hobby for me). Cocoa is very well suited for
writing these kinds of visual applications (unfortunately they are not
really portable, or very limited so, using gnustep)

A QT port sounds really interesting as the model layer could be
separated and reused in a Cocoa app.

It would also be really neat if it was possible to test the flow graph
directly/dynamically without using python (dynamically build it in gcc
using the c++ api, perhaps in a separate process)... Although I
realize this is a much larger undertaking.

I recently found this and thought it was quite inspiring (web app):
http://www.pjrc.com/teensy/gui/

--Albin

On Thu, Jul 30, 2015 at 6:04 PM, Seth Hitefield sd...@vt.edu wrote:
 Albin,

 What part are you looking to work on? I think there are a few new features 
 being worked on for the current version, and Hopefully we are going to start 
 ramping up on the qt port again soon.

 -- Seth

 Sent from my iPhone

 On Jul 30, 2015, at 11:11 AM, Albin Stigö albin.st...@gmail.com wrote:

 Hi,

 Is there a separate list for gnuradio-companion development? I'm
 interested in taking part...

 --Albin

 ___
 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

Re: [Discuss-gnuradio] gnuradio and android

[Albin Stigö]

It would definitely be a great thing is GRC was slightly more language agnostic!

On Thu, Jul 30, 2015 at 6:21 PM, Tom Rondeau t...@trondeau.com wrote:
 On Thu, Jul 23, 2015 at 4:06 PM, Volker Schroer dl1...@gmx.de wrote:

 Tom,

 thank you for your comments.

 I agree to your objection that android is java based. But I think most of
 the gnuradio users  ( not developers ) are  not willing (or not able ) to
 code in java. gnuradio is python based at least to glue blocks together.

 So my conclusion would be : either support python on android or to
 generate java code from grc.
 But I'm unsure which of the many approaches of python for android will
 win, if any.

 Nevertheless both would require gnuradio based on qt5.

 I just ported some other qt4 based projects to qt5 and it wasn't really a
 great problem.
 So I'd try contribute to migrate gnuradio to qt5.

 But some questions: Do you intend to use PyQt4 ( which should support qt5,
 too) or do you plan PyQt5 ? And which would be the best gnuradio repository
 to start from ?

 -- Volker


 We plan on moving to QT5 and therefore support PyQT5. But this is the kind
 of change that will happen only with a new API release (3.8) because it's a
 change in the dependencies. We haven't made any moves on this, yet, but the
 plan is to switch over. Having done some QT5/QT4 work recently, it looks
 like the changes are fairly minimal and mostly semantic, so moving shouldn't
 be a huge deal from that perspective.

 As for the Java/Python issue, we're working under the assumption that we
 split the design process between C++ and Java. GNU Radio in this case will
 exist in the C++ level and build using the Android NDK. The application is a
 fairly separate piece that provides the user interface such as controls and
 ways to visualize and interact with the radio.

 The benefit of this approach is that we provide two domains of expertise.
 GNU Radio on one level and App development on the other level. App
 developers will be more used to Java and all of the tools, techniques, and
 libraries out there for Android are Java based. They need to know little to
 nothing about radio, and the radio developers need to know little to nothing
 about app design and development. This just needs a defined interface
 between the two domains. Currently, my GrTemplate assumes everything is
 going through the JNI. That's what my paper and demo at SRIF will be about
 in September.

 However, we're moving to a new model to make this separation work better,
 but that's still under development. We want all command and control to go
 over ControlPort, and we'll be using ZMQ for any time we might need to
 stream data. ControlPort is great for snapshots of data and setting and
 getting of parameters in a flowgraph, but isn't designed for streaming. And
 we have some plans in mind for streamlining all of this to avoid dependency
 overload.

 I have a ControlPort client setup done in Java now for Android apps, and
 I'll be pushing that out publicly soon (hopefully next week). This will
 allow us to easily bridge between app-space and gnuradio-space. The extra
 benefit of this is decoupling those two in general, not just for Android.
 The example app that I'm working on is a Performance Monitor tool for
 Android, so you can use your Android phone/tablet to connect to a running
 flowgraph elsewhere for monitoring purposes.

 The main reason for this is to acknowledge that we're generally not the
 right people to be designing apps and user interfaces. I'd rather people who
 do that well work on that level, and so we are trying to remove for them the
 burden of having to work with GNU Radio. All they will hopefully need is the
 interfaces agreed upon between the radio designer and the app designer.

 One of the main things that I see we need to have happen here is to have GRC
 produce C++ flowgraphs that will be able to fit into the model that the NDK
 needs.

 Tom





  Am 23.07.2015 um 15:43 schrieb Tom Rondeau:

 On Wed, Jul 22, 2015 at 4:47 PM, Volker Schroer dl1...@gmx.de wrote:

 Hi!
 I watched the development of gnuradio for android. But I'm not very
 familiar with java, so I searched for a way to run gnuradio python scripts
 without or with little modifications on android.

 I detected the python_for_android project and wrote some recipes to run
 gnuradio on android.

 For those who are interested , see:
 https://github.com/dl1ksv/python-for-android

 At the moment I'm able to run things like

 dial_tone or an fm receiver using the rtl dongle.

 But there are a lot of things missing,  in particular a gui, support of
 fcd(pro+), etc.

 So my question: Where to go from here: Introducing kivy to gnuradio for
 building gui's , or migrating qt5 ( a way I'd prefer )
 Or is this only a nice finger exercise and of no special interest ?

 Comments are welcome

 -- Volker


 Volker,

 This is awesome that you're working on this and sharing your progress. Two
 things.

 First, I think the QT5 way is 

Re: [Discuss-gnuradio] Mac gui

[Albin Stigö]

Jan,

Yes you are right. I meant to say I don't have any commercial interest..

--A

On Wed, Jul 15, 2015 at 1:57 PM, Jan Krämer kraemer...@gmail.com wrote:
 Maybe OT and just for clarification,

 by putting your code on Github you essentially are distributing your work.
 So licensing should concern you in that case. Still, Sylvain's answer on the
 licensing issue should be correct.

 Cheers,
 Jan



 2015-07-15 13:47 GMT+02:00 Albin Stigö albin.st...@gmail.com:

 Hi Marcus,

 Thanks for your reply.

 This is just hacking for fun and I plan to put any code I produce on
 github so im not really concerned about licensing at the moment...

 The idea was to make the instrumentation blocks work well and native
 on mac... I was also looking into hacking the gnuradio-companion to
 work better on mac (it doesn't work well on retina displays).

 I will look into fifos! I was also thinking about some kind of shared
 memory IPC ringbuffer...

 --Albin

 On Wed, Jul 15, 2015 at 1:10 PM, Marcus Müller marcus.muel...@ettus.com
 wrote:
  Hi Albin,
 
  GUI interaction is usually a bit tricky. Generally, GNU Radio is also
  meant
  to be used as a library that your main application uses for signal
  processing, and you can get the raw samples in and out of your GNU Radio
  flowgraph from any native application, but I don't really think that's
  what
  you'd start off with.
 
  If I had a recommendation: start off with the guided tutorials and the
  Qt
  visualizations in there. As a pretty easy, and in many cases performant
  enough, solution, use sockets, named FIFOs or ZMQ sinks/sources to
  exchange
  data between your Cocoa (or whatever) application and your (headless)
  GNU
  Radio application, running as a separate process. That makes building,
  modifying and debugging your signal processing separately from your GUI
  much
  easier, imho.
 
  By the way, I think there might be some licensing issues if you link
  cocoa
  code against GPL'ed code, but that's basically only relevant if you
  start
  selling/distributing your program; if you just use a communication
  interface
  (rather than dirtectly linking against GNU Radio) you'd have two
  separate
  programs, which would inherently solve the licensing problem (you'd only
  need to guarantee your customers'/ software receivers' freedom to get,
  modify and distribute the source code for the GPL program).
 
  Best regards,
  Marcus
 
 
 
  On 15.07.2015 12:43, Albin Stigö wrote:
 
  Hi,
 
  I'm pretty new to gnuradio so please bear with me if I have missed
  something.
 
  I finally managed to get everything up and running on my macbook pro
  yesterday (with funcube dongle pro+) and experimented with building an
  out of tree block.
 
  I'm interested in writing some instrumentation blocks using native os
  x gui apis (cocoa and opengl). I was wondering if anyone has
  experimented with this..? The way cocoa works makes it a bit difficult
  to load a gui from dynamic library. I was thinking about starting
  another process from the block and then supplying it with data via
  some ipc mechanism... Has anyone done some work in this area?
 
 
 
  --Albin
 
  ___
  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

 ___
 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

Re: [Discuss-gnuradio] Mac gui

[Albin Stigö]

Hi Marcus,

Thanks for your reply.

This is just hacking for fun and I plan to put any code I produce on
github so im not really concerned about licensing at the moment...

The idea was to make the instrumentation blocks work well and native
on mac... I was also looking into hacking the gnuradio-companion to
work better on mac (it doesn't work well on retina displays).

I will look into fifos! I was also thinking about some kind of shared
memory IPC ringbuffer...

--Albin

On Wed, Jul 15, 2015 at 1:10 PM, Marcus Müller marcus.muel...@ettus.com wrote:
 Hi Albin,

 GUI interaction is usually a bit tricky. Generally, GNU Radio is also meant
 to be used as a library that your main application uses for signal
 processing, and you can get the raw samples in and out of your GNU Radio
 flowgraph from any native application, but I don't really think that's what
 you'd start off with.

 If I had a recommendation: start off with the guided tutorials and the Qt
 visualizations in there. As a pretty easy, and in many cases performant
 enough, solution, use sockets, named FIFOs or ZMQ sinks/sources to exchange
 data between your Cocoa (or whatever) application and your (headless) GNU
 Radio application, running as a separate process. That makes building,
 modifying and debugging your signal processing separately from your GUI much
 easier, imho.

 By the way, I think there might be some licensing issues if you link cocoa
 code against GPL'ed code, but that's basically only relevant if you start
 selling/distributing your program; if you just use a communication interface
 (rather than dirtectly linking against GNU Radio) you'd have two separate
 programs, which would inherently solve the licensing problem (you'd only
 need to guarantee your customers'/ software receivers' freedom to get,
 modify and distribute the source code for the GPL program).

 Best regards,
 Marcus



 On 15.07.2015 12:43, Albin Stigö wrote:

 Hi,

 I'm pretty new to gnuradio so please bear with me if I have missed
 something.

 I finally managed to get everything up and running on my macbook pro
 yesterday (with funcube dongle pro+) and experimented with building an
 out of tree block.

 I'm interested in writing some instrumentation blocks using native os
 x gui apis (cocoa and opengl). I was wondering if anyone has
 experimented with this..? The way cocoa works makes it a bit difficult
 to load a gui from dynamic library. I was thinking about starting
 another process from the block and then supplying it with data via
 some ipc mechanism... Has anyone done some work in this area?



 --Albin

 ___
 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

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Mac gui

[Albin Stigö]

Sylvain  Marcus,

I know about gqrx but at the moment I'm not looking into making a nice
polished app like that... What I'd really like is to make
gnuradio-companion work well on os x with native instrumentation...
I'm thinking about porting the companion to cocoa. Then thing is I
would need to write some blocks that call cocoa code.. And it's a bit
hard to put cocoa code in the blocks. Then I think it would be
somewhat easier to write a simple sink block that starts some cocoa
app and pushes data to it... So what I'm really looking for is what
IPC mechanism to choose I guess.

I will dig into the gnuradio runtime code as I can see I really need a
deeper understanding of it.

--A

On Wed, Jul 15, 2015 at 1:47 PM, Albin Stigö albin.st...@gmail.com wrote:
 Hi Marcus,

 Thanks for your reply.

 This is just hacking for fun and I plan to put any code I produce on
 github so im not really concerned about licensing at the moment...

 The idea was to make the instrumentation blocks work well and native
 on mac... I was also looking into hacking the gnuradio-companion to
 work better on mac (it doesn't work well on retina displays).

 I will look into fifos! I was also thinking about some kind of shared
 memory IPC ringbuffer...

 --Albin

 On Wed, Jul 15, 2015 at 1:10 PM, Marcus Müller marcus.muel...@ettus.com 
 wrote:
 Hi Albin,

 GUI interaction is usually a bit tricky. Generally, GNU Radio is also meant
 to be used as a library that your main application uses for signal
 processing, and you can get the raw samples in and out of your GNU Radio
 flowgraph from any native application, but I don't really think that's what
 you'd start off with.

 If I had a recommendation: start off with the guided tutorials and the Qt
 visualizations in there. As a pretty easy, and in many cases performant
 enough, solution, use sockets, named FIFOs or ZMQ sinks/sources to exchange
 data between your Cocoa (or whatever) application and your (headless) GNU
 Radio application, running as a separate process. That makes building,
 modifying and debugging your signal processing separately from your GUI much
 easier, imho.

 By the way, I think there might be some licensing issues if you link cocoa
 code against GPL'ed code, but that's basically only relevant if you start
 selling/distributing your program; if you just use a communication interface
 (rather than dirtectly linking against GNU Radio) you'd have two separate
 programs, which would inherently solve the licensing problem (you'd only
 need to guarantee your customers'/ software receivers' freedom to get,
 modify and distribute the source code for the GPL program).

 Best regards,
 Marcus



 On 15.07.2015 12:43, Albin Stigö wrote:

 Hi,

 I'm pretty new to gnuradio so please bear with me if I have missed
 something.

 I finally managed to get everything up and running on my macbook pro
 yesterday (with funcube dongle pro+) and experimented with building an
 out of tree block.

 I'm interested in writing some instrumentation blocks using native os
 x gui apis (cocoa and opengl). I was wondering if anyone has
 experimented with this..? The way cocoa works makes it a bit difficult
 to load a gui from dynamic library. I was thinking about starting
 another process from the block and then supplying it with data via
 some ipc mechanism... Has anyone done some work in this area?



 --Albin

 ___
 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

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Mac gui

[Albin Stigö]

Hi,

I'm pretty new to gnuradio so please bear with me if I have missed something.

I finally managed to get everything up and running on my macbook pro
yesterday (with funcube dongle pro+) and experimented with building an
out of tree block.

I'm interested in writing some instrumentation blocks using native os
x gui apis (cocoa and opengl). I was wondering if anyone has
experimented with this..? The way cocoa works makes it a bit difficult
to load a gui from dynamic library. I was thinking about starting
another process from the block and then supplying it with data via
some ipc mechanism... Has anyone done some work in this area?



--Albin

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio