Re: Also bothered

[Chris Vine]

Read it again and you will see the posting was a spoof, artificially
mashed up by a random expression generator from a radio/electronics
related expression list.  Either ignore him or blacklist him from the
mailing list.

---
On Mon, 6 Feb 2023 16:00:45 +0100
Marcus Müller  wrote:
> Dear Matt,
> 
> this is just a quick reminder that this is the GNU Radio mailing list – 
> we're pretty open about the topics we discuss here, but your last three 
> emails were a bit far off.
> 
> Since (I think) you're new in this community: In case you wonder what 
> GNU Radio is exactly, there's a really nice introduction,
> https://wiki.gnuradio.org/index.php?title=What_Is_GNU_Radio
> 
> Best regards,
> Marcus
> 
> On 2/6/23 09:28, Matt Young wrote:
> > In ham radio we have twenty manufacturer all writing and producing 
> > their own LCD screens and menus. A nightmare.s Thy all started with 
> > DSP function then suddenly loads of investments into screens.
> >
> > Just add a USB port to the machines and plug in a chromebook, which 
> > costs 155.  Three hundred dollars save at the shack, money spent on 
> > pre and post analog for dealing with this chaotic atmosphere.
> >
> > The DSP is simple, we need in and out DACs at 8 mHz, 16 bit. We need 
> > ar least 80 Mflops of fixed point 32 bit signal 'taps'. Add in a 
> > separate center frequency LO on output.  Opens the market big time.  
> > Floating point does no good, if you did you Z transforms, 
> > everything should be scaled.
> > Your source code really is set of pure linear discrete inductance, 
> > capacitance and transconductance.  There are no parasitics.  We can 
> > generate assembly from Spice, then each DSP makerwrits thor own linker 
> > from Spice to DSP..
> >
> > Code never changes across bands.  The local oscillator mixes in the 
> > high precision interface to the antenna.  We really want the isolation 
> > of the digital from the horrors of atmospheric RF static.

Re: gnuradio permission problems?

[Chris Vine]

On Wed, 18 Jan 2023 13:33:08 +
Chris Vine  wrote:
> On Wed, 18 Jan 2023 13:03:53 +
> "Beckmann, Niklas"  wrote:
> > Hi everybody,
> > 
> > I have somehow a general question, and even after days of trying
> > (and also googling), I did not found a solution for my problem. So
> > maybe anyone here can help me out. Im on Ubuntu 20.04 and gnuradio
> > 3.10, python 3.8.
> > 
> > I am working with an evaluation kit antenna, which is controlled via
> > the python OOT block, that I wrote. In gnuradio, during the antenna
> > initialization process, my python block tells me, that the connection
> > to the eval-kit failed:
> > 
> >   Connecting ...
> >   MB1 device channel connection failed!
> >   Make sure the device cable is connected.
> >   Make sure you run the connection script with sudo.
> >   Make sure the MB1 has been programmed with the correct descriptor.
> >   Device initialization failed!
> > 
> > On the other hand, when I open sudo python in a terminal, give the same
> > commands as in the python block, the initialization process ends
> > sucessfully. So my guess was, that it has something to do with the
> > permissions of gnuradio (even tho I do not get an Errno13). Am I on
> > the right track? And if so, how can I give gnuradio the needed
> > permissions to connect with the eval-kit or let it run the scripts with
> > higher permissions without using sudo gnuradio?
> > 
> > Since the question is pretty general, I did not provide anything of
> > code. If certain parts of the code or something else is needed, I can
> > give it.
> 
> If your "evaluation kit antenna" comprises a hardware device which has
> a linux driver supplied for it (or uses a generic USB interface for
> which the linux kernel already supplies a driver), so that it is
> represented by a device file in the /dev directory, this looks more
> like a permissions issue concerning the device file rather than with
> gnuradio itself.  If that is the case you may need to write a udev rule
> for your hardware (http://www.reactivated.net/writing_udev_rules.html).
> 
> Having said that, if you have a linux driver for your hardware you
> would have expected it to come with an appropriate udev rules file in
> the first place.

As an addendum, note that if your device driver does already come with a
udev rules file, it may be just a matter of you making yourself a
member of a relevant group.  Examining whether you have a rules file
for your device, which may variously be installed
in /lib/udev/rules.d, /usr/lib/udev/rules.d or /etc/udev/rules.d (I
don't use Ubuntu), should tell you more.

Re: gnuradio permission problems?

[Chris Vine]

On Wed, 18 Jan 2023 13:03:53 +
"Beckmann, Niklas"  wrote:
> Hi everybody,
> 
> I have somehow a general question, and even after days of trying
> (and also googling), I did not found a solution for my problem. So
> maybe anyone here can help me out. Im on Ubuntu 20.04 and gnuradio
> 3.10, python 3.8.
> 
> I am working with an evaluation kit antenna, which is controlled via
> the python OOT block, that I wrote. In gnuradio, during the antenna
> initialization process, my python block tells me, that the connection
> to the eval-kit failed:
> 
>   Connecting ...
>   MB1 device channel connection failed!
>   Make sure the device cable is connected.
>   Make sure you run the connection script with sudo.
>   Make sure the MB1 has been programmed with the correct descriptor.
>   Device initialization failed!
> 
> On the other hand, when I open sudo python in a terminal, give the same
> commands as in the python block, the initialization process ends
> sucessfully. So my guess was, that it has something to do with the
> permissions of gnuradio (even tho I do not get an Errno13). Am I on
> the right track? And if so, how can I give gnuradio the needed
> permissions to connect with the eval-kit or let it run the scripts with
> higher permissions without using sudo gnuradio?
> 
> Since the question is pretty general, I did not provide anything of
> code. If certain parts of the code or something else is needed, I can
> give it.

If your "evaluation kit antenna" comprises a hardware device which has
a linux driver supplied for it (or uses a generic USB interface for
which the linux kernel already supplies a driver), so that it is
represented by a device file in the /dev directory, this looks more
like a permissions issue concerning the device file rather than with
gnuradio itself.  If that is the case you may need to write a udev rule
for your hardware (http://www.reactivated.net/writing_udev_rules.html).

Having said that, if you have a linux driver for your hardware you
would have expected it to come with an appropriate udev rules file in
the first place.

Re: S Meter

[Chris Vine]

On Fri, 9 Sep 2022 11:36:53 +0100
"R.P. Merrell"  wrote:
> Hi all
> 
> I am looking for a way to implement a display of the signal strength being
> received and have tried various methods using the available blocks in my GNU
> 3.10 installation to achieve without success, is their anyone out there who
> has successfully done that who could point me in the right direction,
> please.
> 
> Many thanks
> 
> Richard G4GUJ.

I have used a Qt GUI Number Sink block for this purpose although it has
the rather disconcerting property of providing textual output as well
as a sliding scale, which can't be switched off.  You obviously need to
take the block's input before your AGC block (if any) and because it
comprises a linear display use logarithmic compression and/or some other
form of compression on that input in order to get meaningful results as
a signal strength monitor.

Re: [VOLK] Release 2.5.2

[Chris Vine]

On Fri, 9 Sep 2022 11:35:26 +0200
Johannes Demel  wrote:

> Hi Chris,
> 
> The issue arises in an odd combination.
> 
> 1. you installed VOLK (and cpu_features) to your custom prefix before
> 2. your custom prefix is currently NOT sourced
> 3. you try to re-compile with `CMAKE_INSTALL_PREFIX=`
> 
> What I've learned so far:
> 1. It requires special configuration in a submodule to disable installation.
> 2. CMake tries to be smart and the linker does smth different.
> 
> A more complete analysis and a subsequent fix may be nice.
> 
> Cheers
> Johannes
> 
> On 08.09.22 23:40, Chris Vine wrote:
> > On Sun, 4 Sep 2022 18:41:18 +0200
> > Johannes Demel  wrote:
> >> Hi everyone!
> >>
> >> We have a new VOLK release! We are happy to announce VOLK v2.5.2! We
> >> want to thank all contributors. This release wouldn't have been possible
> >> without them.
> > 
> > Something seems to be amiss when compiling against the internal version
> > of cpu_features:
> > 
> >...
> >[ 88%] Built target volk_obj
> >[ 89%] Linking C shared library libvolk.so
> >/usr/bin/ld: cannot find -lcpu_features: No such file or directory
> >collect2: error: ld returned 1 exit status
> >make[2]: *** [lib/CMakeFiles/volk.dir/build.make:168: 
> > lib/libvolk.so.2.5.2] Error 1
> >make[1]: *** [CMakeFiles/Makefile2:239: lib/CMakeFiles/volk.dir/all] 
> > Error 2
> >make: *** [Makefile:146: all] Error 2

Yes I have volk (and gnuradio) installed in a custom prefix.  I think
you have identified at least part of the problem: volk-2.5.2 compiles
correctly if I uninstall the old version of volk (volk-2.5.0) _before_
compiling the new one.

The good news is that this seems to be caused by a fairly recent change
in volk's build system: volk-2.5.0 compiles fine with a previous version
installed - I have just done some test compiles and the build problem
seems to have first arisen with volk-2.5.1.

Re: [VOLK] Release 2.5.2

[Chris Vine]

On Sun, 4 Sep 2022 18:41:18 +0200
Johannes Demel  wrote:
> Hi everyone!
> 
> We have a new VOLK release! We are happy to announce VOLK v2.5.2! We 
> want to thank all contributors. This release wouldn't have been possible 
> without them.

Something seems to be amiss when compiling against the internal version
of cpu_features:

  ...
  [ 88%] Built target volk_obj
  [ 89%] Linking C shared library libvolk.so
  /usr/bin/ld: cannot find -lcpu_features: No such file or directory
  collect2: error: ld returned 1 exit status
  make[2]: *** [lib/CMakeFiles/volk.dir/build.make:168: lib/libvolk.so.2.5.2] 
Error 1
  make[1]: *** [CMakeFiles/Makefile2:239: lib/CMakeFiles/volk.dir/all] Error 2
  make: *** [Makefile:146: all] Error 2

Re: Use /dev/swradioN (v4l2 api) as source

[Chris Vine]

On Mon, 13 Jun 2022 21:26:34 +0200
Stefan Oltmanns  wrote:
> Hello,
> 
> is there any way to use devices exposed as /dev/swradioN by the v4l2
> Linux kernel API with GNURadio directly?
> 
> At the moment there are only two in-tree kernel drivers, one for the
> RTL2832U and the other for the Mirics MSi2500. For the RTL2832U
> librtlsdr seems to be the better option,b as it offers more features to
> control the device, but libmirisdr seems to unmaintained and not stable
> (at least for me), support has been removed from OsmoSDR years ago.
> I do have such a Dongle and with the kernel driver it seems to work just
> fine.
> 
> I also found an out-of-tree driver for CX2388x-based TV cards, so a V4L2
> source block could be very useful. Is there any specific reason, why
> such a source block doesn't exist yet?
> Or is it just that nobody needed it and therefore no one bothered
> writing one?

Not to answer your question about kernel drivers, but the SDRPlay
RSP1/1A devices use the Mirics MSi2500 and MSi001 chipset so it may be
worth trying out the SDRPlay-2.13.1 binary blob with SoapySDRPlay2 on
your device (or possibly the SDRPlay-3.* binary blob with
SoapySDRPlay3).  They work well for me using the gr-soapy built-in
gnuradio block, but I use SDRPlay-branded kit for which the blobs were
designed.

The gr-osmosdr block will also work with it provided you use
gr-osmosdr's soapy backend, and not the native sdrplay backend which is
completely broken.

Re: Realise a bandwidth segmentizer

[Chris Vine]

On Wed, 16 Mar 2022 08:34:55 +
e heuchamps  wrote:
[snip]
> P. S.: could you give me possible pointers to good references to
> learn the concepts quicker ? I already stumbled across the wonderful
> PySDR blog, and was wondering if there were
> other similar/complementary online ressources ?

For really basic stuff, the videos here are pretty good:
https://greatscottgadgets.com/sdr/ .  Although centred on the HackRF
One, you can follow the principles with pretty much any SDR device
(note though that many consumer-level devices have a lower maximum
sampling rate than does the HackRF One).

Re: [VOLK] Release 2.5.1

[Chris Vine]

On Sat, 12 Feb 2022 11:40:26 +0100
Johannes Demel  wrote:
> Hi everyone!
> 
> You can find the news at https://www.libvolk.org/release-v251.html as well.
> 
> We have a new VOLK release! We are happy to announce VOLK v2.5.1! We 
> want to thank all contributors. This release wouldn't have been possible 
> without them.

Hi,

Is this ABI compatible with volk-2.5.0 (or put another way, if I
upgrade from volk-2.5.0 will I need to recompile gnuradio)?

Chris

Re: Releases v3.8.4.0 and v3.9.3.0

[Chris Vine]

On Sat, 20 Nov 2021 13:54:58 -0500 (EST)
Franco VENTURI  wrote:
> Glen,
> using the 'gr-soapy' source and the latest SoapySDRPlay module 
> (https://github.com/pothosware/SoapySDRPlay3), you should be able to control 
> biasT by using this argument:
> 
>   biasT_ctrl=true
> 
> (see here for some more details here: 
> https://github.com/pothosware/SoapySDRPlay3/issues/21)

I don't have gnuradio-3.8 installed any more, but I do still have
the .grc gr-soapy YAML file for my RSP1A which I used then, and that
definitely has a properties configuration entry for the soapy block
which in my case is "sdrplay_biastee: 'False'", and (as the OP is also
interested in the MF/VHF notches), similar entries for
"sdrplay_dabnotch" and "sdrplay_rfnotch".

These are not present in the YAML file for the built-in soapy block
provided by gnuradio-3.9.1.0 and later.  To provide a RF notch with that
one I had to supply a device argument of "rfnotch_ctrl=true", along the
lines of the one you have suggested above for bias tee.

So how you do it seems to depend on which version of gnuradio and/or
soapy block you are using.

Re: Releases v3.8.4.0 and v3.9.3.0

[Chris Vine]

On Sat, 20 Nov 2021 13:12:02 -0500
Glen Langston  wrote:
> Hi Chris,> 
> Thanks for  your reply.
> 
> After countless hours of messing around, I partially have 
> SDRPlay supported on a Raspberry PI 4 with gnuradio 3.8.2
> 
> Within gnuradio and osmosdr source blocks, I have SDRPlay data streaming, but 
> I’ve not been
> able to turn the bias-tee on or make any sense of the gain settings.
> 
> With gr-soapy source
> 
> I’ve got trouble getting the stream of data to flow.
> 
> with  SoapySDRUtil —find  I do find the device with reasonable values
> 
> ##
> ## Soapy SDR -- the SDR abstraction library ##
> ##
> 
> Found device 0
>   driver = sdrplay
>   label = SDRplay Dev0 RSP1A 190316E696
>   serial = 190316E696
> 
> So, my question is:
> 
> Do you (or anyone) have examples of the values to put in
> either of the source blocks to control the bias-tee 
> gains and notch filters?

You cannot set notch filters on the RSP1A using gr-osmosdr, and as far
as I recall (I no longer have gnuradio-3.8 installed) you cannot set
bias tee either.  There is also a problem with manaul gain control in
the gr-osmosdr block with gnuradio-companion (the rf gain cannot be set
properly manually but you can control if gain manually); but curiously
manual gain controls work OK when using gr-osmosdr with gqrx, and
gnuradio-companion works OK with gr-osmosdr with gain mode set to
automatic.

That is one of the reasons why I recommended that you should use the
gr-soapy block.  With that you can set the notch filters, bias tee,
manual gain and many other things.  The gr-soapy block is much superior
to the gr-osmosdr one, and is built-in with gnuradio-3.9.  gr-osmosdr is
virtually unsupported now and should really only be used with devices
for which soapySDR is not an option, or if you have to use gqrx.  I
would also use gnuradio-3.9 rather than gnuradio-3.8, if you can.

If you want to control gain manually then SoapySDRUtil --probe will
tell you more about values.[1]

In summary, for grqx, use gr-osmosdr with the soapy backend with the
device string "soapy=0,driver=sdrplay".  Otherwise use gr-soapy, which
is much superior.

Chris

[1]  Note that the gr-soapy block with gnuradio-3.8 has separate
manual controls for rf gain and if gain.  The built-in soapy block for
gnuradio-3.9 has a single control for both.

Re: Release v3.9.4.0

[Chris Vine]

On Sun, 31 Oct 2021 10:48:27 -0400
Jeff Long  wrote:
> GNU Radio v3.9.4.0 has been released
> https://github.com/gnuradio/gnuradio/releases/tag/v3.9.4.0
> 
> This release is appearing a little early because of a couple of regressions
> in v3.9.3.0. While we were at it, we pulled in a few more helpful commits
> from the master branch.
> 
> This is an API compatible update to GNU Radio 3.9. Code written for 3.9.X
> versions should compile and link without modification. The ABI is not
> guaranteed to be compatible, so a rebuild of OOT modules may be necessary.
> 
> The next v3.8 and v3.9 releases are expected in Dec/Jan.

The release documentation for gnuradio-3.9.4.0 says that it now
supports GRC with Fedora-35, but doesn't that use python-3.10?  At
any rate, although I don't use Fedora-35, I had to apply the patch
below to get any gnuradio-companion flowchart using a range widget
to work with python-3.10.0.

There seem to be type errors in range.py which are detected by
python-3.10 but not by earlier versions.  The patch fixes it for all
my uses but I can't guarantee that it covers every possible dynamic
code path.

Chris

--- gnuradio-3.9.4.0/gr-qtgui/python/qtgui/range.py.cmakein.orig
2021-10-31 14:28:27.0 +
+++ gnuradio-3.9.4.0/gr-qtgui/python/qtgui/range.py.cmakein 2021-11-01 
12:27:00.362487046 +
@@ -131,7 +131,7 @@
 self.rangeType = rangeType
 
 # Setup the dial
-self.setRange(0, ranges.nsteps-1)
+self.setRange(0, int(ranges.nsteps-1))
 self.setSingleStep(1)
 self.setNotchesVisible(True)
 self.range = ranges
@@ -158,7 +158,7 @@
 
 # Setup the slider
 #self.setFocusPolicy(QtCore.Qt.NoFocus)
-self.setRange(0, ranges.nsteps - 1)
+self.setRange(0, int(ranges.nsteps - 1))
 self.setTickPosition(2)
 self.setSingleStep(1)
 self.range = ranges
@@ -191,7 +191,7 @@
 new = self.minimum() + ((self.maximum()-self.minimum()) * 
event.x()) / self.width()
 else:
 new = self.minimum() + ((self.maximum()-self.minimum()) * 
event.y()) / self.height()
-self.setValue(new)
+self.setValue(int(new))
 event.accept()
 # Use repaint rather than calling the super mousePressEvent.
 # Calling super causes issue where slider jumps to wrong value.
@@ -202,7 +202,7 @@
 new = self.minimum() + ((self.maximum()-self.minimum()) * 
event.x()) / self.width()
 else:
 new = self.minimum() + ((self.maximum()-self.minimum()) * 
event.y()) / self.height()
-self.setValue(new)
+self.setValue(int(new))
 event.accept()
 QtWidgets.QSlider.repaint(self)
 

Re: SoapySDR Question

[Chris Vine]

On Thu, 30 Sep 2021 22:22:38 -0400
Glen Langston  wrote:
> Hi Jeff,
> 
> Thanks for your quick reply.
> 
> I was having trouble figuring out what to put in the Soapy Source block.   
> Do you have a flow graph example?

With gnuradio-3.8 and the gr-soapy block I had this for
gnuradio-companion, but it's not going to help a great deal as a number
of the settings depend on variables.  The sample rate was 2e6/sec, and
bandwidth 600e3 Hz

- name: soapy_source_0
  id: soapy_source
  parameters:
affinity: ''
agc0: 'False'
agc1: 'False'
alias: ''
amp_gain0: '0'
ant0: RX
ant1: ''
args: ''
balance0: '0'
balance1: '0'
bw0: 600e3
bw1: '0'
center_freq0: mhz * 1e6
center_freq1: '0'
clock_rate: '0'
clock_source: ''
comment: ''
correction0: '0'
correction1: '0'
dc_offset0: '0'
dc_offset1: '0'
dc_removal0: 'True'
dc_removal1: 'True'
dev: sdrplay
devname: sdrplay
gain_mode0: Specific
gain_mode1: Overall
ifgr_gain: if_gain
lna_gain0: '0'
lna_gain1: '0'
maxoutbuf: '0'
minoutbuf: '0'
mix_gain0: '0'
nchan: '1'
nco_freq0: '0'
nco_freq1: '0'
overall_gain0: if_gain
overall_gain1: '0'
pga_gain0: '0'
pga_gain1: '0'
rfgr_gain: rf_gain
rxvga1_gain: '5'
rxvga2_gain: '0'
samp_rate: samp_rate
sdrplay_agc_setpoint: '-30'
sdrplay_biastee: 'False'
sdrplay_dabnotch: 'False'
sdrplay_if_mode: Zero-IF
sdrplay_rfnotch: 'True'
settings0: ''
settings1: ''
stream_args: ''
tia_gain0: '0'
tia_gain1: '0'
tune_args0: ''
tune_args1: ''
tuner_gain0: '0'
type: fc32
vga_gain0: '0'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [8, 136.0]
rotation: 0
state: enabled

Re: Releases v3.8.4.0 and v3.9.3.0

[Chris Vine]

On Thu, 30 Sep 2021 20:46:50 -0400
Glen Langston  wrote:
> Thanks for all everyone's efforts.   
> 
> We hope to give them a try.
> 
> I’ve got a Soapy SDR question.   Does anyone have a SDRPlay RSP1A running
> with Gnuradio 3.8.  I’ve not been able to find a running example.
> 
> Please send a link, if you’ve got a good example.

I don't have a link to offer you as my gnuradio installation is home-
compiled from a number of scripts.  However, I did have my RSP1A
working fine with gnuradio-3.8.2.0 using the out-of-tree gr-soapy block.
I have now moved on to gnuradio-3.9.2.0, which has the advantage of
providing an in-tree soapy block as part of the gnuradio distribution.

If you are using gnuradio-3.8 and can't move to gnuradio-3.9, I found
that the out-of-tree gr-soapy block, wrapping SoapySDR and SoapySDRPlay,
worked far better than trying to use the gr-osmosdr block's unfree
backend for the RSP driver directly.  gr-osmosdr's soapy backend worked
OK with the RSP driver and is what you will need if you are using gqrx,
otherwise that adds an unnecessary level of indirection: instead of
using gr-osmosdr's soapy backend you might just as well use gr-soapy
directly, and the latter enables you to configure for example the
RSP1A's MF/AM and VHF/DAB filters, which I never managed to do with
gr-osmosdr.

SoapySDRPlay seemed to work fine with both the 2.13.1 and 3.05.1
versions of the RSP driver; since the RSP1A only has a single hardware
sampler there is no advantage in using the 3.05.1 driver so I stuck with
version 2.13.1, which avoids having to start a daemon.

My main issue was in working out which gr-osmosdr and gr-soapy
repository worked with which version of gnuradio.  With gnuradio-3.9's
in-tree soapy block that is now obviated.  If you need help with
versions/repositories for gnuradio-3.8 I should be able to help.

Hope that helps.

Re: [EXTERNAL] Re: Changing the frequency of signal source at runtime

[Chris Vine]

On Wed, 14 Jul 2021 13:47:26 -0400
Jeff Long  wrote:
> With a recent GNU Radio 3.9, SoapySDR is supported, and there is a soapy
> sdrplay driver. This requires the sdrplay v3 API and service to be
> installed.

SoapySDR and SoapySDRPlay also work fine with the v2 API for the RSP1A
and gnuradio-3.9.  I use it myself (version 2.13.1) and prefer it to
the v3 API as it doesn't require a daemon process to be launched.  For
the RSP1A, the v3 API doesn't seem to offer anything that the v2 API
doesn't, as the RSP1A only offers a single hardware sampling device.

Re: GNU Radio gr-osmosdr on Ubuntu Installation Error; Kali Successfully Installs but Can’t Run

[Chris Vine]

On Fri, 7 May 2021 12:24:42 -0700
Cinaed Simson  wrote:
> Hi Chris - I'm saying, my updated git copy of gr-osmosdr usng
> 
>     git branch -a
> 
> doesn't have an enrty for 3.9 - so it suggests it has not  been ported 3.9
> 
> Acutally, I meant say "does not" have an entry for 3.9.
> 
> I've have never used gr-soapy so I don't anything about it.
> 
> On 5/7/21 2:33 AM, Chris Vine wrote:
> > On Fri, 7 May 2021 00:43:25 -0700
> > Cinaed Simson  wrote:
> >> Hi David - looking at my local git hub copy of the source for
> >> gr-osmosdr, it does appear to have been ported to 3.9 - just 3.7 and 3.8.
> >>
> >> -- CInaed
> >>
> >> On 5/5/21 4:48 AM, David Martini wrote:
> >>> In my case gr-osmosdr on ubuntu 20.04
> >>> Work just in gnuradio 3.8.1.
> >>> I'm not able to run it on ubuntu 3.9.. at least unit 10 days ago.
> >>>
> >>> David Martini
> > Did you mean to say it has not been ported to 3.9, or that something
> > else (I am not sure what) has not been ported to 3.7 and 3.8?
> >
> > If the former, that's not right: the master branch of the git repo at
> > git://git.osmocom.org/gr-osmosdr works fine with gnuradio-3.9.1.0.  You
> > must be on its gr3.8 branch by mistake if you are restricted to
> > gnuradio-3.8.
> >
> > The problematic one is gr-soapy.  The has been ported to 3.8 and the
> > forthcoming 3.10 (where it is now in gnuradio's master branch) but not
> > to 3.9.  However there is a privately maintained repo at
> > git://gitlab.com/willcode4/gr-soapy.git which has a maint-3.9 branch
> > which moves the code to pybind11 and works OK with gnuradio-3.9 (for me
> > at least).
> >
> > Chris

Hi,

To be clear, there is no branch named "3.9" in of the gr-osmosdr git
repository because the current master branch covers gnuradio-3.9.  Your
suggestion that gr-osmosdr has not been ported to gnuradio-3.9 is wrong.

Re: GNU Radio gr-osmosdr on Ubuntu Installation Error; Kali Successfully Installs but Can’t Run

[Chris Vine]

On Fri, 7 May 2021 00:43:25 -0700
Cinaed Simson  wrote:
> Hi David - looking at my local git hub copy of the source for 
> gr-osmosdr, it does appear to have been ported to 3.9 - just 3.7 and 3.8.
> 
> -- CInaed
> 
> On 5/5/21 4:48 AM, David Martini wrote:
> > In my case gr-osmosdr on ubuntu 20.04
> > Work just in gnuradio 3.8.1.
> > I'm not able to run it on ubuntu 3.9.. at least unit 10 days ago.
> >
> > David Martini

Did you mean to say it has not been ported to 3.9, or that something
else (I am not sure what) has not been ported to 3.7 and 3.8?

If the former, that's not right: the master branch of the git repo at
git://git.osmocom.org/gr-osmosdr works fine with gnuradio-3.9.1.0.  You
must be on its gr3.8 branch by mistake if you are restricted to
gnuradio-3.8.

The problematic one is gr-soapy.  The has been ported to 3.8 and the
forthcoming 3.10 (where it is now in gnuradio's master branch) but not
to 3.9.  However there is a privately maintained repo at
git://gitlab.com/willcode4/gr-soapy.git which has a maint-3.9 branch
which moves the code to pybind11 and works OK with gnuradio-3.9 (for me
at least).

Chris

Re: Stop making unneeded improvements

[Chris Vine]

On Tue, 22 Dec 2020 20:21:42 -0500
Glen Langston  wrote:
[snip]
> I like the SDRPlay device, but it can not be used in gnuradio 3.8.  According 
> to the web.
> But the web indicates it might be usable in 3.9
> So I installed 3.9 only to find that swig has been replace by pybind.  This 
> breaks all my
> existing C++ modules.   The modules worked fine, but if using ubuntu 20.40 
> the students can not
> easily install gnuradio 3.7.  The pybind instructions are puzzling.  
> gr-modtool all the
> modules copy something or other.   This is for no good reason that I’m aware 
> of.
> Either make the equivalent of pythons “2to3” or do not make the gnuradio 
> fundamental changes.

I use SDRPlay with gnuradio-3.8 with linux and it works fine.  The
gr-soapy backend works better than the gr-osmosdr one however.

In my case I use sdrplay-2.13.1, soapy-sdr (git master branch as at
2020-07-13), soapy-sdrplay (git master branch as at 2020-06-29),
gnuradio-3.8.2.0 and gr-soapy (git master branch as at 2020-06-07).

In addition, to use SDRPlay with gqrx, I use gr-iqbal (git master
branch as at 2019-12-01) and gr-osmosdr (git master branch as at
2020-08-05).  However, you should use the gr-osmosdr block's soapy
backend with soapy's sdrplay driver (pass the arguments
"soapy=0,driver=sdrplay" to the gr-osmosdr block), and not the sdrplay
backend which no longer works properly.

Re: Mpir Installation

[Chris Vine]

On Tue, 28 Apr 2020 17:57:36 +0200
"Vincenzo Mone"  wrote:
> WARNING: 'makeinfo' is missing on your system.
> 
>  You should only need it if you modified a '.texi' file, or
> 
>  any other file indirectly affecting the aspect of the manual.
> 
>  You might want to install the Texinfo package:
> 
>  
> 
>  The spurious makeinfo call might also be the consequence of
> 
>  using a buggy 'make' (AIX, DU, IRIX), in which case you might
> 
>  want to install GNU make:
> 
>  
> 
> Makefile:403: recipe for target 'mpir.info' failed
> 
> make[2]: *** [mpir.info] Error 127
> 
> make[2]: uscita dalla directory "/home/enzo/mpir/doc"
> 
> Makefile:952: recipe for target 'all-recursive' failed
> 
> make[1]: *** [all-recursive] Error 1
> 
> make[1]: uscita dalla directory "/home/enzo/mpir"
> 
> Makefile:755: recipe for target 'all' failed
> 
> make: *** [all] Error 2
> 
> Did I done something wrong?
> 
> Thanks

You are doing lots wrong.

First you are missing texinfo's makeinfo, which seems to be used by mpir
to make its documentation.  That's fine, you don't need texinfo.

Secondly, you don't need texinfo because you are pointlessly trying to
compile and install mpir.  Why?  Your distribution will already come
with gmp or mpir so it is completely unnecessary.

Thirdly, you are posting massively long posts with no regard for
snipping irrelevant content.

Fourthly, trying to install these out-of-distribution packages, when
your distribution will already provide them, is going to break your
installation.  You will end up with conflicting and incompatible
versions of different libraries installed.

I suggest deleting your current linux installation, reinstall it from
scratch, and install that distribution's version of gnuradio.  You are
way out of your depth.

Re: Qt GUI Chooser initial selection

[Chris Vine]

OK, understood.  I'm only a peripheral user, so if the gnuradio
developers can't be bothered, then I can't be bothered.


On Mon, 13 Apr 2020 17:57:30 +0200
Volker Schroer  wrote:
> Ok, then you should fill a pr or report an issue.
> Otherwise this issue won't be fixed I'm afraid.
> 
> -- Volker
> Am 12.04.20 um 22:08 schrieb Chris Vine:
> > Yes, on testing it that does work.
> >
> > But surely, as I said, this needs to go into the 3.8 branch of gnuradio
> > so that it is in the next 3.8 release?
> >
> > Chris
> >
> > 
> > On Sun, 12 Apr 2020 17:16:24 +0200
> > Volker Schroer  wrote:
> >> I think, it should be possible to take the qtgui_chooser.block.yml file
> >> from the master branch. This sould work, as there is no code affected.
> >>
> >> Volker
> >>
> >> Am 12.04.20 um 14:56 schrieb Chris Vine:
> >>> Ah, OK.  This did not find its way into gnuradio-3.8.1.0.  Presumably it
> >>> will apply OK to that version however?  (If so I suggest it is applied
> >>> to the 3.8 branch also.)
> >>>
> >>> Chris
> >>>
> >>> 
> >>> On Sun, 12 Apr 2020 11:48:56 +0200
> >>> Volker Schroer  wrote:
> >>>> Hi !
> >>>> This was fixed with #2778
> >>>>
> >>>> See also:
> >>>>
> >>>> https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a
> >>>>
> >>>>
> >>>> -- Volker
> >>>> Am 11.04.20 um 14:45 schrieb Chris Vine:
> >>>>> Hi,
> >>>>>
> >>>>> On porting a gnuradio-companion flow graph from gnuradio-3.7 to
> >>>>> gnuradio-3.8, I noticed that there no longer seems to be a way of
> >>>>> setting the initial (default) selection for the Qt GUI Chooser widget.
> >>>>> The initial selection seems now always to be the first one in the list.
> >>>>>
> >>>>> The widget is therefore no longer suitable for presenting a selection
> >>>>> of numeric values to the user in numerical order where you don't want
> >>>>> the initial default to be the highest (or lowest) value.
> >>>>>
> >>>>> Is there some way around this or some other widget that is now intended
> >>>>> to be used for this purpose?
> >>>>>
> >>>>> Chris
> >>>>>
> >>>>

Re: Qt GUI Chooser initial selection

[Chris Vine]

Yes, on testing it that does work.

But surely, as I said, this needs to go into the 3.8 branch of gnuradio
so that it is in the next 3.8 release?

Chris


On Sun, 12 Apr 2020 17:16:24 +0200
Volker Schroer  wrote:
> I think, it should be possible to take the qtgui_chooser.block.yml file
> from the master branch. This sould work, as there is no code affected.
> 
> Volker
> 
> Am 12.04.20 um 14:56 schrieb Chris Vine:
> > Ah, OK.  This did not find its way into gnuradio-3.8.1.0.  Presumably it
> > will apply OK to that version however?  (If so I suggest it is applied
> > to the 3.8 branch also.)
> >
> > Chris
> >
> > 
> > On Sun, 12 Apr 2020 11:48:56 +0200
> > Volker Schroer  wrote:
> >> Hi !
> >> This was fixed with #2778
> >>
> >> See also:
> >>
> >> https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a
> >>
> >>
> >> -- Volker
> >> Am 11.04.20 um 14:45 schrieb Chris Vine:
> >>> Hi,
> >>>
> >>> On porting a gnuradio-companion flow graph from gnuradio-3.7 to
> >>> gnuradio-3.8, I noticed that there no longer seems to be a way of
> >>> setting the initial (default) selection for the Qt GUI Chooser widget.
> >>> The initial selection seems now always to be the first one in the list.
> >>>
> >>> The widget is therefore no longer suitable for presenting a selection
> >>> of numeric values to the user in numerical order where you don't want
> >>> the initial default to be the highest (or lowest) value.
> >>>
> >>> Is there some way around this or some other widget that is now intended
> >>> to be used for this purpose?
> >>>
> >>> Chris
> >>>
> >>

Re: Qt GUI Chooser initial selection

[Chris Vine]

Ah, OK.  This did not find its way into gnuradio-3.8.1.0.  Presumably it
will apply OK to that version however?  (If so I suggest it is applied
to the 3.8 branch also.)

Chris


On Sun, 12 Apr 2020 11:48:56 +0200
Volker Schroer  wrote:
> Hi !
> This was fixed with #2778
> 
> See also:
> 
> https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a
> 
> 
> -- Volker
> Am 11.04.20 um 14:45 schrieb Chris Vine:
> > Hi,
> >
> > On porting a gnuradio-companion flow graph from gnuradio-3.7 to
> > gnuradio-3.8, I noticed that there no longer seems to be a way of
> > setting the initial (default) selection for the Qt GUI Chooser widget.
> > The initial selection seems now always to be the first one in the list.
> >
> > The widget is therefore no longer suitable for presenting a selection
> > of numeric values to the user in numerical order where you don't want
> > the initial default to be the highest (or lowest) value.
> >
> > Is there some way around this or some other widget that is now intended
> > to be used for this purpose?
> >
> > Chris
> >
> 

Qt GUI Chooser initial selection

[Chris Vine]

Hi,

On porting a gnuradio-companion flow graph from gnuradio-3.7 to
gnuradio-3.8, I noticed that there no longer seems to be a way of
setting the initial (default) selection for the Qt GUI Chooser widget.
The initial selection seems now always to be the first one in the list.

The widget is therefore no longer suitable for presenting a selection
of numeric values to the user in numerical order where you don't want
the initial default to be the highest (or lowest) value.

Is there some way around this or some other widget that is now intended
to be used for this purpose?

Chris

Re: Pi GNURadion challenge.

[Chris Vine]

On Mon, 9 Mar 2020 10:59:04 -0400
Glen Langston  wrote:
> Hi
> 
> Thanks for your summary of experience with installing Gnuradio 3.8.1 for 
> Raspberry Pi.
> 
> I’ve started the install on a fresh version on the latest Raspberry Pi OS,
> but ran into a few issues I’m still working on.
> 
> One question/request for this group:
> 
> The folks at SDRPlay have done a very nice job of porting a good working 
> version of
> gnuradio into a working image of the Raspberry OS and compressed it.
> (https://www.sdrplay.com/downloads/)
> 
> After downloading (about 2GB) and writing to the SD card, this version just 
> works fine.
> The simple-minded user can then just start enjoying Gnuradio.
> 
> However they don’t yet have Gnuradio 3.8.1 on the SD card.

As far as I can tell there is no gnuradio-3.8.1.  Where did you find it?
I can see a first release candidate as of some weeks ago, which of
course is something different.

Re: Version compatibility problem

[Chris Vine]

On Wed, 12 Feb 2020 15:04:49 -0800
Laura Arjona  wrote:
> sorry, typed it wrong
> ~$ which gnradio-config-info
> /usr/local/bin/gnuradio-config-info

In which case you have built and installed gnuradio in the /usr/local
prefix by hand, not as a package you can install and uninstall using
your distribution's package manager.

You should be able to go through /usr/local and delete anything
gnuradio related.  Then install your distribution's binary package
of gnuradio using its package manager.  Unless you are a person who
likes to do their own compiling, there shouldn't be much in /usr/local.

Chris

Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation

[Chris Vine]

On Thu, 14 Nov 2019 19:35:13 +
Chris Vine  wrote:
> The original poster can get some information from installing soapy and
> doing 'SoapySDRUtil --probe'.

I should probably have appended what the probe tells me about my RSP1A,
which may or may not apply to his:


-- Device identification

  driver=SDRplay
  hardware=RSP1A
  mir_sdr_api_version=2.13
  mir_sdr_hw_version=255
  serial=xxx


-- Peripheral summary

  Channels: 1 Rx, 0 Tx
  Timestamps: NO
  Other Settings:
 * RF Gain Select - RF Gain Select
   [key=rfgain_sel, default=4, type=string, options=(0, 1, 2, 3, 4, 5, 6, 
7, 8, 9)]
 * IF Mode - IF frequency in kHz
   [key=if_mode, default=Zero-IF, type=string, options=(Zero-IF, 450kHz, 
1620kHz, 2048kHz)]
 * IQ Correction - IQ Correction Control
   [key=iqcorr_ctrl, default=true, type=bool]
 * AGC Setpoint - AGC Setpoint (dBfs)
   [key=agc_setpoint, default=-30, type=int, range=[-60, 0]]
 * BiasT Enable - BiasT Control
   [key=biasT_ctrl, default=true, type=bool]
 * RfNotch Enable - RF Notch Filter Control
   [key=rfnotch_ctrl, default=true, type=bool]
 * DabNotch Enable - DAB Notch Filter Control
   [key=dabnotch_ctrl, default=true, type=bool]


-- RX Channel 0

  Full-duplex: NO
  Supports AGC: YES
  Stream formats: CS16, CF32
  Native format: CS16 [full-scale=32767]
  Antennas: RX
  Corrections: DC removal
  Full gain range: [0, 48] dB
IFGR gain range: [20, 59] dB
RFGR gain range: [0, 9] dB
  Full freq range: [0.01, 2000] MHz
RF freq range: [0.01, 2000] MHz
CORR freq range:  MHz
  Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps
  Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz

Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation

[Chris Vine]

On Thu, 14 Nov 2019 14:11:22 +
Müller, Marcus (CEL)  wrote:
> Hi Glen,
> 
> first of all: This email nearly eluded my attention – you replied to a
> completely different topic, and that means email clients will sort your
> mail under the "Simulated Time?" thread. Simply don't reply to emails
> if you don't mean to actually reply.
> 
> Then: The SDRPlay block isn't part of GNU Radio itself – it comes from
> somewhere else, and I must admit I don't know from where. You'll
> probably have to download the SDRPlay driver package and look inside.
> 
> Problem with the SDRPlay driver is: It's closed source, and as such,
> they can't link software against GNU Radio (which is GPL), and then
> distribute it. If someone could reverse engineer that and write a GPL-
> compatible driver (and integrate it with soapy or with gr-osmosdr),
> that'd be very cool.

The original poster can get some information from installing soapy and
doing 'SoapySDRUtil --probe'.

But I wonder what gnuradio block the original poster is using with the
proprietary driver?  I couldn't make it out from the image he posted.  I
only know of three: (i) gr-osmosdr's built-in support for sdrplay, (ii)
gr-osmosdr's built-in support for soapy and so for the soapy-sdrplay
plugin, and (iii) gr-soapy's support for soapy and so also for the
soapy-sdrplay plugin.  If there is a fourth I would be interested to
know what it is.  The first doesn't work that well for me with the
current proprietary driver whereas the last two work fine (for me on
x86/64).

In any event, with reference to the original poster's comments about
selecting the wrong band pass filter, RSP1A only supports certain
bandpass filtering widths.  These can be examined with the soapy
probe above.  Generally you want the bandwidth to be somewhat less than
the sample rate (soapy's probe will also tell you what sample rates are
available).

Re: [Discuss-gnuradio] GNURadio v3.8.0.0 Blocs .xml

[Chris Vine]

On Wed, 14 Aug 2019 08:44:31 -0400
"Michael Dickens"  wrote:
> Hi Jean Pierre & Kyeong - gr-osmosdr does not have an official port to GR3.8 
> as of yet. There are 3rd-party ports that might work, such as those from the 
> issue noted: https://osmocom.org/issues/3855 . See also:
> 
> https://github.com/igorauad/gr-osmosdr/tree/gr3.8
> https://github.com/mvaenskae/gr-osmosdr/tree/gr3.8
> https://github.com/igorauad/gr-osmosdr/tree/gr3.8
> 
> Hope this is useful! - MLD

To get the igograud's repository to link cleanly with boost-1.70.0 and
gnuradio-3.8.0.0, I had to add this patch to gr-osmosdr's cmake build
system, as gr-osmosdr links to functions in boost::chrono.  I have not
yet verified that gr-osmosdr actually works with gnuradio-3.8, but it
does at least compile and link.

There may well be a better way to do it in cmake: I neither like cmake,
nor know it especially well.



diff --git a/lib/CMakeLists.txt b/lib/CMakeLists.txt
index 2171df2..9ba4592 100644
--- a/lib/CMakeLists.txt
+++ b/lib/CMakeLists.txt
@@ -52,6 +52,7 @@ endif()
 GR_OSMOSDR_APPEND_LIBS(
 ${Boost_LIBRARIES}
 gnuradio::gnuradio-blocks
+boost_chrono
 ${GNURADIO_ALL_LIBRARIES}
 )
 

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