Re: Radar Project - BladeRF2.0

[Sebastian Müller]

  
Hi Dionisio,
  
  
probably gr-radar [1] is a good starting point for that. Based on Ettus USRP 
though.
  
  
[1]  https://github.com/kit-cel/gr-radar
  
  

  
Mit freundlichen Grüßen/Kind regards
  
Sebastian Müller
  
  
  
On Jun 24 2020, at 3:03 pm, Dionísio de Carvalho
wrote:
  
>   
>   
> hi everybody
>   
> This is my fisrt message here. I am pretty new in the SDR world.
>   
>   
> I am intended to develop a Radar with BladeRF2.0 from Nuand.
>   
> Is anybody in this boat?
>   
>   
> I have some start questions that I will be grateful for any help:
>   
>   
> - How can I sweep theFrequency at osmocom-sink?any idea?
>   
> - How can I figure out the TX power?I am trying to measure an antenna S21 
> parameter!
>   
>   
> thanks for any help
>   
>   
> Att
>   
>   
> Dionisio Carvalho
>   
> Sao Paulo University - Brazil
>   
>   
 

Re: Help with GR-Inspector

[Sebastian Müller]

  
Hi Pierre,
  
  
I guess whenever you say "Gt" you mean "Qt", right? ;-)
  
Concerning your answers:
  
  
1. `git clone` is not an installation method for GNU Radio. If you cloned the 
repository, you still need to build and install it. If you built with gr-qtgui, 
it should already have worked with Qt4. Please make sure that cmake is not just 
finding the wrong Qt installation and you really don't have Qt4 installed. This 
implicates that you don't have GNU Radio with Qt widgets.
  
  
2. / 3. So for this issue, I recommend to "use the right tool for the job". If 
you want to use GNU Radio 3.7 with gr-inspector, then probably Pentoo Linux 
5.0.8 is not the right environment for that endevour. The straightforward 
advice I can provide is: Use an operating system that supports your 
constraints, instead of making your life hard.
  
That being said, if that is no option for you for some reason, I can point you 
to the maint-3.8 branch of gr-inspector. There, Qt5 is being used. It should be 
not that difficult to extract the changes concerning the switch from Qt4 to Qt5 
and apply them locally on your machine (on top of maint-3.7 branch). That way, 
you will create a gr-inspector version that supports Qt4 and GNU Radio 3.7.
  
  

  
Mit freundlichen Grüßen/Kind regards
  
Sebastian Müller
  
  
  
On Jun 3 2020, at 10:48 pm, pierregal...@mailo.com wrote:
  
>   
> Hello Sebastian,
>   
>
>   
> Thanks for you prompt reply.
>   
>
>   
> I am using Pentoo Linux version 5.0.8 which has Gt5 preinstalled.
>   
>
>   
> 1. I have installed Gnu radio 3.7 via git clone without pybombs
>   
>
>   
> 2. I cannot find the command to install Gt4 for gentoo linux. As per [1], Gt4 
> has been depreciated for Gentoo distribution. So apparently, I have to stick 
> to GT5.
>   
>
>   
> 3. As per same forum: " Qt4 is deprecated and was removed from the main 
> Portage tree. You could try to resurrect it from the attic, but you will be 
> in unsupported territory." , "All Qt4 packages were moved to kde-sunset 
> overlay more than a year ago, but keep in mind that this overlay is 
> completely unmaintained and essentially an ebuild graveyard."
>   
>
>   
>   
> I am not a computer science person.
>   
>   
>
>   
>   
> [1]  https://forums.gentoo.org/viewtopic-t-1098804-start-0.html
>   
>   
>
>   
>   
> Pierre
>   
>   
>   
>   
> >   
> > De : Sebastian Müller  
> >   
> > À : discuss-gnuradio@gnu.org  
> >   
> > Sujet : Re: Help with GR-Inspector
> >   
> > Date : 03/06/2020 20:54:44 Europe/Paris
> >   
> >   
> > Hello Pierre,
> >   
> >   
> > you already got everything right:
> >   
> > - gr-inspector for GNU Radio 3.7 requires Qt4
> >   
> > - gr-inspector for GNU Radio 3.8 requires Qt5
> >   
> >   
> > So there should be no problem in using Qt4 for your case. In particular, 
> > gr-qtgui for GNU Radio 3.7  is  using Qt4, not Qt5 [1].
> >   
> >   
> > Can you tell me the following:
> >   
> >   
> >   
> > How did you install GNU Radio 3.7?
> >   
> >   
> >   
> > Why can't you install Qt4 and Qt5 libs simultaneously?
> >   
> >   
> >   
> > Why do you consider "downgrading" (I guess you mean removing Qt5 
> > completely) dangerous for you?
> >   
> >   
> >   
> >   
> > [1]   
> > https://github.com/gnuradio/gnuradio/blob/maint-3.7/gr-qtgui/CMakeLists.txt#L25
> >   
> >   
> >
> >   
> > Mit freundlichen Grüßen/Kind regards
> >   
> > Sebastian Müller
> >   
> >   
> >   
> > On Jun 3 2020, at 8:25 pm, pierregal...@mailo.com wrote:
> >   
> > >
> > >   
> > > Hello,
> > >   
> > >
> > >   
> > >   
> > > I need your help. I want to install GR-inspector for Gnuradio 3.7 on 
> > > Pentoo linux (Gentoo distribution). However, when installing 
> > > GR-inspector, I have the following error:
> > >   
> > >   
> > >
> > >   
> > >   
> > >   Found unsuitable Qt version "5.11.3" from /usr/bin/qmake, this code
> > >   
> > >requires Qt 4.x
> > >   
> > >   
> > >
> > >   
> > >   
> > > I have already search on the internet, the only possible way (if I do an 
> > > analogy with someone having the same issue) would be to port the make 
> > > file of GR-inspector for Gnuradio 3.7 to Qt5.
> > >   
> > >   
> > >
> > >   
> > > I cannot downgrade from GT5 to GT4 (as it is apparently 
> > > impossible/dangerous) and I have to use Gnuradio 3.7 because I want to 
> > > use GR-inspector with blocks that are only compatible using Gnuradio 3.7.
> > >   
> > >
> > >   
> > >   
> > > Can anyone help me ? I would not know how to write a patch to port 
> > > GR-inspector for Gnuradio 3.7 on GT5.
> > >   
> > >   
> > >
> > >   
> > > Kind regards,
> > >   
> > >
> > >   
> > >   
> > > Pierre Galant
> > >   
> > >   
> >   
>   
 

Re: Help with GR-Inspector

[Sebastian Müller]

  
Hello Pierre,
  
  
you already got everything right:
  
- gr-inspector for GNU Radio 3.7 requires Qt4
  
- gr-inspector for GNU Radio 3.8 requires Qt5
  
  
So there should be no problem in using Qt4 for your case. In particular, 
gr-qtgui for GNU Radio 3.7  is  using Qt4, not Qt5 [1].
  
  
Can you tell me the following:
  
  
  
How did you install GNU Radio 3.7?
  
  
  
Why can't you install Qt4 and Qt5 libs simultaneously?
  
  
  
Why do you consider "downgrading" (I guess you mean removing Qt5 completely) 
dangerous for you?
  
  
  
  
[1]   
https://github.com/gnuradio/gnuradio/blob/maint-3.7/gr-qtgui/CMakeLists.txt#L25
  
  

  
Mit freundlichen Grüßen/Kind regards
  
Sebastian Müller
  
  
  
On Jun 3 2020, at 8:25 pm, pierregal...@mailo.com wrote:
  
>
>   
> Hello,
>   
>
>   
>   
> I need your help. I want to install GR-inspector for Gnuradio 3.7 on Pentoo 
> linux (Gentoo distribution). However, when installing GR-inspector, I have 
> the following error:
>   
>   
>
>   
>   
>   Found unsuitable Qt version "5.11.3" from /usr/bin/qmake, this code
>   
>requires Qt 4.x
>   
>   
>
>   
>   
> I have already search on the internet, the only possible way (if I do an 
> analogy with someone having the same issue) would be to port the make file of 
> GR-inspector for Gnuradio 3.7 to Qt5.
>   
>   
>
>   
> I cannot downgrade from GT5 to GT4 (as it is apparently impossible/dangerous) 
> and I have to use Gnuradio 3.7 because I want to use GR-inspector with blocks 
> that are only compatible using Gnuradio 3.7.
>   
>
>   
>   
> Can anyone help me ? I would not know how to write a patch to port 
> GR-inspector for Gnuradio 3.7 on GT5.
>   
>   
>
>   
> Kind regards,
>   
>
>   
>   
> Pierre Galant
>   
>   
 

Re: gnuradio 3.8 on macos

[Sebastian Müller]

  
Hi Kai,
  
  
I'm using [1] pretty successfully. However, I guess the macports port for GR 
3.8 should still be addressed. Can somebody provide information on the current 
status of the port?
  
  
[1]  https://github.com/ktemkin/gnuradio-for-mac-without-macports
  
  

  
Mit freundlichen Grüßen/Kind regards
  
Sebastian Müller
  
  
  
On May 31 2020, at 6:07 pm, Kai Garrelswrote:
  
>   
> Hi,
>   
>  I am trying to move to gnuradio 3.8 using macports, but I fail:
>  - gnuradio installs 3.7.something
>  - gnuradio-devel dos not install
>  - gnuradio-next installs 3.9, which conflicts when apps look for 3.8
>   
>  What I want to achieve: gnuradio3.8 + gr-osmosdr….any suggestions?
>  Should I use something else than macports?
>   
>  Thanks for your help!
>  kai
>

Re: Finding GNU Radio 3.8 Compatible Versions Of OOT Modules

[Sebastian Müller]

Hi,

I “reverse engineered” this this feature.
You should place a “gr_supported_version” key in your MANIFEST. The value is 
just a string AFAIK, eg “v3.7, v3.8”.

Sebastian Müller

> On 6. Feb 2020, at 20:26, Sylvain Munaut <246...@gmail.com> wrote:
> 
> Hi,
> 
>> Regarding that column, how does it work? I've seen that only gr-fosphor
>> and gr-iqbal have that column filled out currently, but I don't know how
>> tnt has accomplished that. I don't see anything special in the
>> MANIFEST.md nor in the .lwr recipe.
> 
> I accomplished that by not being on github ... and so CGRAN doesn't
> actually even look at my manifest file and the data for fosphor and
> iqbal is literally hard-coded inside of CGRAN's codebase.
> 
> Cheers,
> 
>   Sylvain
> 

Slack alternatives

[Sebastian Müller]

Hi all,

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

[1] https://mattermost.com/

Sebastian Müller
gse...@gmail.com  
PGP ID DC2AA3EE



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: Status of gr-inspector

[Sebastian Müller]

Hi all,

today I finally merged the GR 3.8 development branch of gr-inspector into 
master, bumping the project to version 2.0.0.
This means gr-inspector supports GNU Radio 3.8 and adapts the proposed OOT 
branching model of maint branches next to the master branch.

You’ll find the updated code here: https://github.com/gnuradio/gr-inspector.

Please note that some blocks that dealt with AMC and depended on tensorflow and 
qwtplot3d are not included in this version yet.

Kind regards,

Sebastian Müller
gse...@gmail.com  
PGP ID DC2AA3EE

Am 4. Dezember 2019 um 20:55:53, Sebastian Müller (gse...@gmail.com) schrieb:
> Hi all,
>  
> I’ve received many requests in the last months asking for GNU Radio 3.8 
> support in gr-inspector.  
> Firstly, be assured there is progress on this topic.
>  
> That being said, please also understand that I have reoriented professionally 
> and am  
> no longer an everyday GNU Radio and Linux user, so I have to invest a lot of 
> time to work into  
> those topics again. Nevertheless, I’m happy to do so whenever I find the time.
>  
> There is a `dev_3.8` branch [1] in the repo where the current progress is 
> pushed regularly.  
> So far cmakeing and building works, tests are ported, however no 
> functionality is tested  
> yet. I will announce when the porting is finished on this list as well. Until 
> then, stay  
> tuned!
>  
> [1] https://github.com/gnuradio/gr-inspector/tree/dev_3.8
>  
> Best regards,
>  
> Sebastian Müller
> gse...@gmail.com
> PGP ID DC2AA3EE
>  
>  



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Status of gr-inspector

[Sebastian Müller]

Hi all,

I’ve received many requests in the last months asking for GNU Radio 3.8 support 
in gr-inspector.
Firstly, be assured there is progress on this topic.

That being said, please also understand that I have reoriented professionally 
and am no longer an everyday GNU Radio and Linux user, so I have to invest a 
lot of time to work into those topics again. Nevertheless, I’m happy to do so 
whenever I find the time.

There is a `dev_3.8` branch [1] in the repo where the current progress is 
pushed regularly. So far cmakeing and building works, tests are ported, however 
no functionality is tested yet. I will announce when the porting is finished on 
this list as well. Until then, stay tuned!

[1] https://github.com/gnuradio/gr-inspector/tree/dev_3.8

Best regards,

Sebastian Müller
gse...@gmail.com  
PGP ID DC2AA3EE



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: [Discuss-gnuradio] problem with tensorflow in gr-inspector

[Sebastian Müller]

Hi,

gr-inspector requires Tensorflow 0.12, other versions’ compatibility
can’t be guaranteed.
That being said, please note that there are plans to update
gr-inspector to all the fancy new dependencies available [1].

[1] https://github.com/gnuradio/gr-inspector/issues/31

Best,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE

Am 19. September 2019 um 13:53:57, j...@id-inc.us (j...@id-inc.us) schrieb:
> I am trying to resurrect this too. I gave up on 18.04 and am trying 16.04.
>
>
>
> We need to uplift the whole thing to newer versions.
>
>
>
> Best regards,
>
> Jeff
>
>
>
> From: Discuss-gnuradio On
> Behalf Of Ali G. Dezfuli
> Sent: Thursday, September 19, 2019 10:30 AM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] problem with tensorflow in gr-inspector
>
>
>
> Dear friends,
>
> I have a problem installing gr-inspector.
>
> I am using ubuntu 18.04
>
> having gnuradio v3.7.9.3 installed (removing all the updates and installed 
> just this)
>
> pip version is :
>
> $ pip --version
>
> "pip 19.2.3 from /usr/local/lib/python2.7/dist-packages/pip (python 2.7)"
>
>
>
> >>> tf.__version__
> '1.14.0'
> >>>
>
> the error report in grc when running for example "amc_cnn.grc" is this:
>
>
>
> Loading: "/home/masoud/opt/gr-inspector/examples/amc_cnn.grc"
> >>> Done
>
> Showing: "/home/masoud/opt/gr-inspector/examples/amc_cnn.grc"
>
> Generating: '/home/masoud/opt/gr-inspector/examples/top_block.py'
>
> Executing: /usr/bin/python2 -u 
> /home/masoud/opt/gr-inspector/examples/top_block.py
>
> WARNING:tensorflow:From 
> /usr/local/lib/python2.7/dist-packages/inspector/tfmodel_vcf.py:80:
> load_session_bundle_from_path (from 
> tensorflow.contrib.session_bundle.session_bundle)
> is deprecated and will be removed after 2017-06-30.
> Instructions for updating:
> No longer supported. Switch to SavedModel immediately.
> Traceback (most recent call last):
> File "/home/masoud/opt/gr-inspector/examples/top_block.py", line 138, in
> main()
> File "/home/masoud/opt/gr-inspector/examples/top_block.py", line 126, in main
> tb = top_block_cls()
> File "/home/masoud/opt/gr-inspector/examples/top_block.py", line 73, in 
> __init__
> self.inspector_tfmodel_vcf_0 = 
> inspector.tfmodel_vcf("complex64",128,"/tmp/cnn/0001",(),0)
> File "/usr/local/lib/python2.7/dist-packages/inspector/tfmodel_vcf.py", line
> 64, in __init__
> sess, inp, out,classes = self.load_graph(graphfile)
> File "/usr/local/lib/python2.7/dist-packages/inspector/tfmodel_vcf.py", line
> 80, in load_graph
> output_graph_path)
> File 
> "/usr/local/lib/python2.7/dist-packages/tensorflow/python/util/deprecation.py",
> line 324, in new_func
> return func(*args, **kwargs)
> File 
> "/usr/local/lib/python2.7/dist-packages/tensorflow/contrib/session_bundle/session_bundle.py",
> line 87, in load_session_bundle_from_path
> meta_graph_filename)
> RuntimeError: Expected meta graph file missing /tmp/cnn/0001/export.meta
>
>
>
> would be grateful if you could possibly help me with this.
>
> regards
>
> Ali
>
> ___
> 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] Generate Zadoff sequence

[Sebastian Müller]

Hi Sneha,

we used a ZC sequence in our DySpan Spectrum Challenge code from 2017:
https://github.com/kit-cel/gr-fbmc
However, I’m not sure about the nature of the question. I think it’s
much too general for anyone to provide an answer to this. If you’re
completely uncertain how to start, I’d recommend the GNU Radio
tutorials: https://wiki.gnuradio.org/index.php/Tutorials. There is
explained how to „do SDR with GNU Radio“. Implementing the ZC sequence
is then up to you.

Regards,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE

Am 28. Juni 2019 um 15:27:14, Michael Dickens
(michael.dick...@ettus.com) schrieb:
> Hi Sneha Vasan - That all sounds very interesting and so forth. I'd recommend 
> for the best
> chances of getting a reply from anyone regarding your specific topic, that 
> you include
> links to describe the work you're referencing for the "Zadoff chu seq", 
> whatever that
> is. Maybe there are some folks on the list who know what this is without 
> referring to literature,
> but for the rest of us it's at least a few steps to do an internet search & 
> parse through the
> results & then download a paper to help you here ... fewer steps will 
> increase the chances
> of anyone here helping! Hope this is useful! - MLD
>
> ps> Please "reply all" so that the whole list can see your links & possibly 
> help. More eyes
> reading your query increases the chances of someone helping!
>
> On Fri, Jun 28, 2019, at 5:58 AM, Sneha vasan wrote:
> > Hi,
> >
> > I would like to transmit and receive Zadoff chu seq from USRP and correlate 
> > this two signals.
> >
> > Any suggestions how we can do this?
> >
> > Regards
> > ___
> > 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] Live fm detection gr-inspector

[Sebastian Müller]

Daniel,

please take some time to get familiar with the documentation. Instead
of copy settings from other users, this is much more
beneficial for you since you understand what impact all parameters
have and makes your debugging life much easier.

The signal detector block for instance takes an argument „min_bw“,
ignoring all bandwidths that are smaller than that value:
https://gnuradio.github.io/gr-inspector/classgr_1_1inspector_1_1signal__detector__cvf.html

In your attached picture I would set the threshold to something like
-65. -78 looks too deep into the noise floor.

Best,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE

Am 15. Juni 2019 um 07:55:43, Müller, Marcus (CEL) (muel...@kit.edu) schrieb:
> So, let's really look at what you receive there. What's your antenna?
>
> When you connect a QT GUI time sink, what's (roundabout) your maximum
> amplitude coming out of the USRP Source?
>
> Best regards,
> Marcus
> On Fri, 2019-06-14 at 23:25 -0500, Daniel Andres Palacios wrote:
> > Hello Kyeong,
> > About gain level, it was a desperate measure, in my eagerness to get
> > signals. If someone has used managed to detect FM signals and can
> > give me the parameters used,
> > I would appreciate it.
> >
> > Thanks
> >
> >
> >
> >
> > On Thu, Jun 13, 2019 at 10:45 PM Kyeong Su Shin > > > wrote:
> > > Hello Daniel,
> > >
> > > A few things to note:
> > >
> > > -Gain level of USRP B200 does not go up to 120 dB. Sure, GNU Radio
> > > or UHD won't complain about this, but it maxes out at around 70 dB
> > > (I do not remember the exact number).
> > >
> > > -My eyes are untrained (I did study sigint before, but it's been a
> > > few years since then), so I cannot tell which peaks are spurious
> > > and which peaks are true WBFM signals by simply looking a
> > > periodogram. However, it seems like the signal detector block is
> > > not detecting some serious (~-40 to -20 dBFS) peaks in the
> > > spectrum. If those peaks are FM signals, then the detector block is
> > > either misconfigured or is not suitable for the task. If those
> > > peaks are not FM signals (are spurious signals or unwanted
> > > interferences) and if you are not seeing actual FM signals on your
> > > periodogram, then you will need to move your receiver to elsewhere
> > > or get a better antenna (and may have to decrease the gain of the
> > > receiver).
> > >
> > > -gr-inspector's signal detector uses energy detection to detect
> > > signals, which works on most types of signals but is also
> > > suboptimal (in terms of the detection accuracy). You may want to
> > > come up with your own detector block that exploits the
> > > characteristics of the FM signal if you want to maximize the
> > > detection accuracy (in terms of P_d and P_fa).
> > >
> > > Regards,
> > > Kyeong Su Shin
> > >
> > > 보낸 사람: Daniel Andres Palacios 대신 Discuss-
> > > gnuradio
> > > 보낸 날짜: 2019년 6월 14일 금요일 오전 6:14:07
> > > 받는 사람: Sebastian Müller
> > > 참조: discuss-gnuradio@gnu.org
> > > 제목: Re: [Discuss-gnuradio] Live fm detection gr-inspector
> > >
> > > OK, my bad.
> > >
> > > Here is my actual configuration. But again, signals appear and
> > > disappear.
> > > Even when I try to cath a fm station, if the GUI Inspector is not
> > > set to manual, a get the same behavior
> > >
> > > Thank you.
> > >
> > >
> > >
> > > On Thu, Jun 13, 2019 at 2:11 PM Sebastian Müller
> > > wrote:
> > > > I just noticed something else:
> > > > The USRP sample rate is set to 500kHz, not 20MHz. So you are only
> > > > looking at 2.5 % of the target spectrum! It is also possible,
> > > > that
> > > > there are just no signals in that particular section.
> > > >
> > > > Best,
> > > >
> > > > Sebastian Müller
> > > > gse...@gmail.com
> > > > PGP ID DC2AA3EE
> > > >
> > > > Am 13. Juni 2019 um 20:20:24, Sebastian Müller (gse...@gmail.com)
> > > > schrieb:
> > > > > Hi Daniel,
> > > > >
> > > > > from what you tell us, I conclude this is not an issue with gr-
> > > > inspector but rather with
> > > > > generally receiving signals.
> > > > > If you use the QT GUI Sink for instance instead, you will see
> > > > the same (empty) spectrum.
> > > > > I would recommend to

Re: [Discuss-gnuradio] Live fm detection gr-inspector

[Sebastian Müller]

I just noticed something else:
The USRP sample rate is set to 500kHz, not 20MHz. So you are only
looking at 2.5 % of the target spectrum! It is also possible, that
there are just no signals in that particular section.

Best,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE

Am 13. Juni 2019 um 20:20:24, Sebastian Müller (gse...@gmail.com) schrieb:
> Hi Daniel,
>
> from what you tell us, I conclude this is not an issue with gr-inspector but 
> rather with
> generally receiving signals.
> If you use the QT GUI Sink for instance instead, you will see the same 
> (empty) spectrum.
> I would recommend to try and get better reception, until you can distinguish 
> signals
> visually in the spectrum manually. Are you using the correct antenna for this 
> frequency
> range? Is this antenna positioned in a beneficial location for reception? 
> Have you played
> around with the Rx gain of the USRP?
>
> Best,
>
> Sebastian Müller
> gse...@gmail.com
> PGP ID DC2AA3EE
>
> Am 13. Juni 2019 um 19:10:59, Daniel Andres Palacios (dapa...@gmail.com) 
> schrieb:
> > Thanks for your reply
> >
> > I trying to detect and classify all fm transmitted stations in my country,
> > with the gr-inspector OOT.
> > In my country (Colombia) it goes from 87,9 to 107.9 MHZ.
> > I only have an USRP B200 and think that if I set the center frequency at 98
> > MHZ and put a bandwidth of 20MHZ its posible to get my goal. But actually
> > im not getting signals detected
> > [image: Captura de pantalla de 2019-06-13 11-17-05.png]
> >
> > On Tue, Jun 11, 2019 at 12:53 PM Müller, Marcus (CEL)
> > wrote:
> >
> > > Hi Daniel,
> > >
> > > please remember to be specific when asking a question: "best way" is a
> > > bit ambiguous, and "I'm not getting a good result" definitely is
> > > insufficient for us to help you make things work better. What doesn't
> > > work sufficiently well? What happens instead?
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Tue, 2019-06-11 at 12:36 -0500, Daniel Andres Palacios wrote:
> > > > Hi to everyone.
> > > >
> > > > What is the best way to receive all fm modifications. I'm usigin an B200
> > > USRP.
> > > > I think that putting the center frequency at 98M and a bandwidth of 20M
> > > is a good way,but I'm not getting a good result.
> > > >
> > > > The idea is to detect all fm center frequencies using gr-inspector
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> >
> >
> > --
> > *Daniel Andrés Palacios Carabalí*
> > *Student of Telemathics engineering*
> > *Icesi University- Cali, Colombia*
> > *===*
> > *Estudiante de Ingeniería Telemática*
> > *Universidad Icesi. - Cali, Colombia*
> > ___
> > 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] Live fm detection gr-inspector

[Sebastian Müller]

Hi Daniel,

from what you tell us, I conclude this is not an issue with
gr-inspector but rather with generally receiving signals.
If you use the QT GUI Sink for instance instead, you will see the same
(empty) spectrum. I would recommend to try and get better reception,
until you can distinguish signals visually in the spectrum manually.
Are you using the correct antenna for this frequency range? Is this
antenna positioned in a beneficial location for reception? Have you
played around with the Rx gain of the USRP?

Best,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE

Am 13. Juni 2019 um 19:10:59, Daniel Andres Palacios
(dapa...@gmail.com) schrieb:
> Thanks for your reply
>
> I trying to detect and classify all fm transmitted stations in my country,
> with the gr-inspector OOT.
> In my country (Colombia) it goes from 87,9 to 107.9 MHZ.
> I only have an USRP B200 and think that if I set the center frequency at 98
> MHZ and put a bandwidth of 20MHZ its posible to get my goal. But actually
> im not getting signals detected
> [image: Captura de pantalla de 2019-06-13 11-17-05.png]
>
> On Tue, Jun 11, 2019 at 12:53 PM Müller, Marcus (CEL)
> wrote:
>
> > Hi Daniel,
> >
> > please remember to be specific when asking a question: "best way" is a
> > bit ambiguous, and "I'm not getting a good result" definitely is
> > insufficient for us to help you make things work better. What doesn't
> > work sufficiently well? What happens instead?
> >
> > Best regards,
> > Marcus
> >
> > On Tue, 2019-06-11 at 12:36 -0500, Daniel Andres Palacios wrote:
> > > Hi to everyone.
> > >
> > > What is the best way to receive all fm modifications. I'm usigin an B200
> > USRP.
> > > I think that putting the center frequency at 98M and a bandwidth of 20M
> > is a good way,but I'm not getting a good result.
> > >
> > > The idea is to detect all fm center frequencies using gr-inspector
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> --
> *Daniel Andrés Palacios Carabalí*
> *Student of Telemathics engineering*
> *Icesi University- Cali, Colombia*
> *===*
> *Estudiante de Ingeniería Telemática*
> *Universidad Icesi. - Cali, Colombia*
> ___
> 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] GR inspector Velue Error

[Sebastian Müller]

Hi Daniel,

gr-inspector has Tensorflow 0.12 as dependency, so you should use it
with that exact version.
If that is not an option, you might want to contact Christopher
Richardson who is the author
of the AMC functionality of gr-inspector (see REAMDE.md for contact info).

Cheers,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE

Am 21. Mai 2019 um 18:04:21, Daniel Andres Palacios (dapa...@gmail.com) schrieb:
> Hi all. I was testing the gr-inspector examples. I generated the neural
> network model and tried to execute it. I got this error. "You can not enter
> the form value (1, 1, 2, 128) for the Tensor u'reshape_1_input_1: 0 ',
> which has the form' (?, 2, 128) '". Apparently, Tensorflow has undergone
> some changes since gr-inspector was created. Anyone could help me with this
> please.
>
> Thanks
> --
> *Daniel Andrés Palacios Carabalí*
> *Student of Telemathics engineering*
> *Icesi University- Cali, Colombia*
> *===*
> *Estudiante de Ingeniería Telemática*
> *Universidad Icesi. - Cali, Colombia*
> ___
> 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] Installation of gr-radar

[Sebastian Müller]

Hello Talha,

Qt and Qwt are different softwares. Gr-radar depends on Qt4 and Qwt6.
The error has to do with Qwt. I guess you don’t have the correct
version of Qwt installed.

PS: Please avoid to send pictures to mailing lists, since this takes
up space in everyone's mailbox. Better use a service like imgur and
post the link to the picture in your mail :)

Best,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE

Am 10. März 2019 um 20:54:39, Talha Farooq (talhafaro...@gmail.com) schrieb:
> Hi
> I am installing GNU gr-radar in Ubuntu. I installed all dependencies and
> now while in step of making build of gr-radar by command 'make' I am
> getting below mentioned error Though I upgraded QT to latest version which
> is "Using Qt version 5.7.1 in /usr/lib/arm-linux-gnueabih". I read in
> Issue#16 that you should use QT6 but I am unable to find any stable version
> of QT6 or how to install that.
> Error:
> [ 1%] Building CXX object
> lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o
> In file included from /home/pi/gr-radar/build/lib/moc_scatter_plot.cxx:9:0:
> /home/pi/gr-radar/build/lib/../../lib/scatter_plot.h:24:22: fatal error:
> qwt_plot.h: No such file or directory
> #include
> ^
> compilation terminated.
> lib/CMakeFiles/gnuradio-radar.dir/build.make:77: recipe for target
> 'lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o' failed
> make[2]: *** [lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o]
> Error 1
> CMakeFiles/Makefile2:137: recipe for target
> 'lib/CMakeFiles/gnuradio-radar.dir/all' failed
> make[1]: *** [lib/CMakeFiles/gnuradio-radar.dir/all] Error 2
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2
> [image: image.png]
> Regards:
> Talha Farooq Hashmi
> ___
> 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 on High Sierra

[Sebastian Müller]

If I understood correctly, Vipin in trying to compile his own OOT.

In that case, you can just switch to C++11 independently of GNU Radio AFAIK.
You can do that by putting `set(CMAKE_CXX_STANDARD 11)` into your root
CMakeLists.txt.

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>

Am 17. Mai 2018 um 21:16:20, Michael Dickens (michael.dick...@ettus.com)
schrieb:

Hi Vipin - Easiest way is to just install gnuradio-devel:
{{{
sudo port -f deactivate gnuradio
sudo port install gnuradio-devel
}}}
Assuming that the 2nd command works, then in your OOT when you "make" for
the first time since this GR change CMake will redo configuration & you
should be good to go. Hope this is useful! - MLD

On Wed, May 16, 2018, at 9:57 PM, Vipin Sharma wrote:

Thank you. I was just trying to build a custom block in GnuRadio. GnuRadio
itself is what I got from MacPorts.

I will wait for your fix. If the work involved more than a few days is
there an alternative I can try out to bypass the issue for now?


___
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] Invalid msg port in connect() or disconnect()

[Sebastian Müller]

Hello list,

I’m posting the following issue vicarious for GitHub user „mustaphos“, who
unfortunately does not make use of the mailing list despite I directly
suggested him to do so. Since I don’t think this is a gr-inspector issue,
I’m posting this publicly for discussion.
OP reports to have found no solution on the mailing list so far.

Original issue at https://github.com/gnuradio/gr-inspector/issues/23


Hi.
When i run the program i get this error:
Traceback (most recent call last):File "live_signal_detection.py", line
136, in main()File "live_signal_detection.py", line 124, in maintb
= top_block_cls()File "live_signal_detection.py", line 90, in
__init__self.msg_connect((self.inspector_signal_detector_cvf_0, 'map_out'),
(self.inspector_qtgui_sink_vf_0, 'map_in'))File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line
59, in wrappedfunc(self, src.to_basic_block(), srcport,
dst.to_basic_block(), dstport)File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line
131, in msg_connectself.primitive_msg_connect(*args)File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
5343, in primitive_msg_connectreturn
_runtime_swig.top_block_sptr_primitive_msg_connect(self,
*args)RuntimeError: invalid msg port in connect() or disconnect()
I searched in gnuradio mail list but i could not find any solution.
I am in a hurry to publish my project report so i am posting in here.
Sorry about that.
Regards…


Cheers,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio on High Sierra

[Sebastian Müller]

Hello Vipin,

can you make sure you have installed cppunit?
CMake is looking for cppunit/TestCase.h, which in my case can be found in
/opt/local/include/cppunit/TestCase.h
Since CMake is also looking in ${CMAKE_INSTALL_PREFIX}/include, it actually
should have no problem finding it there, if you’re using the cmake provided
by MacPorts.

Regards,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>

Am 13. Mai 2018 um 07:53:02, Vipin Sharma (vipinsha...@photonpace.com)
schrieb:

Hi,

My old insulation of MacPorts and GnuRadio was working until I upgraded my
OS to High Sierra. MacPorts started complaining that I likely need to
migrate the installation to a new OS.

Instead I proceeded to download a new copy of MacPorts for High Sierra
itself. The installation went fine for both MacPorts itself and later on
for GnuRadio.

However, I seem to be getting a very weird problem while building an OOT
module. While trying to run 'cmake ../' from new build directory, it
complains about "CppUnit required to compile chEst3". I am not sure what
the problem is; what does this error mean? Googling hasn't helped yet
either.

Here is the block set up log:

mac01:gr-chEst3 emwaves$ gr_modtool add chEst

GNU Radio module name identified: chEst3

Block/code identifier: chEst

('sink', 'source', 'sync', 'decimator', 'interpolator', 'general',
'tagged_stream', 'hier', 'noblock')

Enter block type: general

Language (python/cpp): cpp

Language: C++

Please specify the copyright holder: P.

Enter valid argument list, including default arguments:

Add Python QA code? [Y/n] Y

Add C++ QA code? [y/N] Y

Adding file 'lib/chEst_impl.h'...

Adding file 'lib/chEst_impl.cc'...

Adding file 'include/chEst3/chEst.h'...

Adding file 'lib/qa_chEst.cc'...

Adding file 'lib/qa_chEst.h'...

Editing swig/chEst3_swig.i...

Adding file 'python/qa_chEst.py'...

Editing python/CMakeLists.txt...

Adding file 'grc/chEst3_chEst.xml'...

Editing grc/CMakeLists.txt...


And then, the 'cmake ../' log as well from 'build' directory:

mac01:build emwaves$ cmake ../

-- The CXX compiler identification is AppleClang 9.1.0.9020039

-- The C compiler identification is AppleClang 9.1.0.9020039

-- Check for working CXX compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++

-- Check for working CXX compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/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:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc

-- Check for working C compiler:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/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.

CMake Deprecation Warning at CMakeLists.txt:55 (cmake_policy):

  The OLD behavior for policy CMP0026 will be removed from a future version

  of CMake.


  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.



CMake Deprecation Warning at CMakeLists.txt:58 (cmake_policy):

  The OLD behavior for policy CMP0043 will be removed from a future version

  of CMake.


  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.



CMake Deprecation Warning at CMakeLists.txt:61 (cmake_policy):

  The OLD behavior for policy CMP0045 will be removed from a future version

  of CMake.


  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.



CMake Deprecation Warning at CMakeLists.txt:64 (cmake_policy):

  The OLD behavior for policy CMP0046 will be removed from a future version

  of CMake.


  The cmake-policies(7) manual explains that the OLD behaviors of all

  policies are deprecated and that a policy should be set to OLD only under

  specific short-term circumstances.  Projects should be ported to the NEW

  behavior and not rely on setting a policy to OLD.



-- Boost version: 1.66.0

-- Found the following Boost libraries:

--   filesystem

--   system

-- Found PkgConfig: /opt/local/bin/p

Re: [Discuss-gnuradio] GR-Inspector Issues

[Sebastian Müller]

Ogün,

Am 27. April 2018 um 15:27:13, ogün levent (levento...@gmail.com) schrieb:

Hello,
I also have few problems with gr-inspector. It was working without any
problem until gateware change of the limesdr now gateware issue resolved
but I see a dc offset on qt sink and also Real time scheduling is not
working.

The DC offset has nothing to do with gr-inspector. I have never used a
LimeSDR but it’s a rather affordable SDR and therefore don’t expect
superior signal quality, including a remaining DC offset. You can cancel
the offset yourself by doing signal processing.

At the initial start some signals are spitting out at the terminal and
sometimes detected signals have zero bandwidth shown inside the tuples.
Correct me if I am wrong we are supposed to see complex baseband signals
which are supposed to have bandwidth more than 0Hz?

This depends on your block settings. Since you don’t provide which
flowgraph or which blocks you are using, I can’t make a statement on if
this is intended behaviour or not.

Final problem is the even the samp rate is at its max value I still see
aliasing.

Also here, „max samp rate“ does not guarantee you don’t have aliasing. What
do you see and why do you think it is aliasing? Why do you think there
shouldn’t be aliasing? What are your parameters? I, again, assume this is
just a hardware effect with mirroring frequencies due to the affordable SDR
hardware.

On qt gui marker shows the exact values of the tuple but on the terminal we
see different values why?

Again please provide more information on the flowgraph, blocks an
parameters used. There is no way anybody can answer that question with the
information you provide.



Best.

Regards,

Sebastian



2018-04-18 8:16 GMT+03:00 Shalom Dubinsky <smdubin...@gmail.com>:

> Sebastian,
> Thanks for responding!
>
> I've been through the code, and I see what you mean now by "complex
> baseband".  However, it looks like you're assuming the carrier frequency is
> the sample rate.  Is that something I should be trying to maintain
> throughout my project?
>
> I also think I found a minor bug?  In the build_threshold method, where
> you have `i` going up to `d_fft_len` but access `i + 1`.
>
> Thanks for your help,
> Shalom
>
> On Thu, Apr 5, 2018 at 6:57 PM Sebastian Müller <gse...@gmail.com> wrote:
>
>> Hi Shalom,
>>
>> Am 5. April 2018 um 11:14:22, Shalom Dubinsky (smdubin...@gmail.com)
>> schrieb:
>>
>>
>> Hello,
>>
>> My name is Shalom Dubinsky, and I'm having some trouble with the
>> gr-inspector module.  I'm trying to use it to detect signals in the 2.4ghz
>> range, and I can't get reliable responses from it.  Information on it seems
>> scarce, so I'm asking here.
>>
>> First, I tried playing with the default example of 3 cosine waves all
>> summed with a noise source and run through the Signal Detector block.  This
>> works as expected - both the GUI Inspector sink and the message debug
>> output match. However, if I increase the sample rate too much it loses any
>> accuracy it had.  Specifically, a sample rate of 4M only picks up two
>> signals, and a sample rate of 40M only picks up one signal. The error is
>> much higher in both of them, up to several hundred hz.  Decreasing it to
>> 20k gives me two reasonably accurate signals and one garbage signal.
>>
>> I also tried building my own graph.  I ran a single cosine wave
>> broadcasting at 200M through a noise generator, the signal detector block,
>> and the GUI Inspector block.  The sample rate was consistent throughout the
>> graph, and the FFT length was set to 4096 across the board. The center
>> frequency of the inspector sink was set at 200M.  The messages reported the
>> signal to be at 800, while the graph displayed it as 208Mhz. Dropping
>> the cosine frequency to 800k allowed the signal detector to work more or
>> less correctly, but I had to change the center frequency of the inspector
>> sink to 0 for it to display the signal correctly.  The problem at 800k was
>> that the messages would alternate between ~80 and ~-10183594. This
>> isn't the only time I saw negative frequencies, either.
>>
>> I next tried attaching it to a real radio.  When I broadcast a
>> signal(from a different radio) at 2.425ghz, it detected that a signal was
>> being broadcast, meaning it only reported something when I broadcast a
>> signal,  but did not accurately detect the signal frequency. Instead, it
>> would bounce around detecting different frequencies.
>>
>> Questions:
>>
>> Generally I’d like to point to the official documentation [1].
>>
>>
>> * What is the relationship between sampling rate and signal detection
>> accuracy?
>&

Re: [Discuss-gnuradio] Issues using gr-inspector after install

[Sebastian Müller]

Sorry for the confusion, I used karel’s fixed branch for my testing.
Under 3.7.12 I get the exact same error on the gr-inspector master branch.
I will try to have a look soon but won’t be available in the next days.

Regards,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>

Am 18. April 2018 um 19:28:05, Müller, Marcus (CEL) (muel...@kit.edu)
schrieb:

Hm, it's surprising it works for Sebastian but not for you, but:

This might be a bug we've introduced in 3.7.12.0. I have a commit on
GNU Radio maint-3.7 (and I think master) that's supposed to fix that.

If someone could try whether the issue is fixed at the current head of
maint-3.7, I'd be very thankful – because if it is, I can release
3.7.12.1, with that fix included.

A bit of pointless maintainer lamentation: I was the one who let that
bug creep into a release. But I really couldn't get any code review for
that pull request. So, if someone adds a PR, or feels like he wants to
contribute to the project, but doesn't know how, please watch out for
the PR queue on github [1]: Every bit of code that anyone reviews does
help. Be critical; most people enjoy getting constructive feedback on
the code they're writing.

Best regards,
Marcus

[1]https://github.com/gnuradio/gnuradio/pulls
On Wed, 2018-04-18 at 11:54 -0500, Robert Stanford wrote:
>
> Using Fedora25 and GNU Radio 3.7.12, installing from PyBombs. Now I get a
new error in the Docker container, is this one known?
>
> Generating: '/tmp/gr-inspector/examples/live_signal_detection.py'
>
> Executing: /usr/bin/python2 -u
/tmp/gr-inspector/examples/live_signal_detection.py
>
> File "/tmp/gr-inspector/examples/live_signal_detection.py", line 90
> self.inspector_qtgui_sink_vf_0 = Template error: #set $win =
'self._%s_win'%$id
>
>
>
> On Sat, Apr 14, 2018 at 11:43 AM, Robert Stanford <rstanford8...@gmail.com>
wrote:
> > Sabastian -
> >
> > Thanks for the screenshots. I'll keep hammering at it. If I do
eventually get a Docker environment working, I'll send it your way in case
you'd like to include it.
> >
> > Thanks again
> >
> >
> > On Sat, Apr 14, 2018 at 11:19 AM, Sebastian Müller <gse...@gmail.com>
wrote:
> > > Robert,
> > >
> > > I’m sorry you’re having difficulties with gr-inspector. I have just
tried to clone, compile and install gr-inspector on Fedora 25 with GNU
Radio 3.7.12 and it worked. Please see the attached screenshot [1] from
today as proof.
> > > I have seen gr-inspector run on various setups and distros, including
Fedora, Ubuntu and Arch Linux. However, I cannot provide support for
setting up specific operating systems to meet the dependencies for
gr-inspector. I have uploaded my `cmake ..` and `make` command outputs as
reference for you [2]. Feel free to compare with your output and I’m sure
you’ll be able to track down the issue. Just from skimming I’ve noticed
that there is no line in your cmake output telling that Qt4 was found.
> > >
> > > [1] https://imgur.com/a/Tm6Ag
> > > [2] https://pastebin.com/M1hmA05a
> > >
> > > Regards,
> > >
> > > Sebastian Müller
> > > gse...@gmail.com
> > > PGP ID DC2AA3EE
> > >
> > > Am 14. April 2018 um 04:08:43, Robert Stanford (
rstanford8...@gmail.com) schrieb:
> > > > If anyone's interested or having the same issue: I've tried to run
the gr-inspector example in a Docker container (seen below) and received
the same error message. So the issue doesn't seem to be limited to Ubuntu
17.10.
> > > >
> > > > ===
> > > > FROM fedora:27
> > > >
> > > > RUN yum install -y git gnuradio gnuradio-devel qt qt-devel qwt
qwt-devel gcc gcc-c++ make cmake python python-devel python-pip
qwtplot3d-qt4 qwtplot3d-qt4-devel cppunit-devel
> > > > RUN yum install -y rtl-sdr xterm gr-osmosdr
> > > > RUN pip install tensorflow
> > > >
> > > > # gr-inspector
> > > > RUN echo "xterm_executable = /usr/bin/xterm" >>
/etc/gnuradio/conf.d/grc.conf
> > > > RUN git clone https://github.com/gnuradio/gr-inspector
/tmp/gr-inspector
> > > > RUN mkdir /tmp/gr-inspector/build; cd /tmp/gr-inspector/build;
cmake ..; make -j4; make install
> > > >
> > > > ENV PYTHONPATH $PYTHONPATH:/usr/local/lib64/python2.7/site-packages
> > > > CMD /bin/bash
> > > > ===
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Apr 11, 2018 at 1:48 PM, Robert Stanford <
rstanford8...@gmail.com> wrote:
> > > > > I've found and installed the necessary package. It still has the
same error when running the example graph. L

Re: [Discuss-gnuradio] FW: Error when executing gr-Inspector block

[Sebastian Müller]

Ravi,

this is an already reported issue [1].
Please be patient while I investigate what’s happening and how to resolve
it.
Alternatively, you can a) downgrade GNU Radio to < 3.7.12 or b) use
karel-‚s hotfix for now [2]

[1] https://github.com/gnuradio/gr-inspector/issues/20
[2] https://github.com/karel-/gr-inspector/tree/gui_hint

Regards,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>

Am 16. April 2018 um 18:18:55, ravi ranjan gautam (killerran...@gmail.com)
schrieb:



Im trying to follow this->
https://github.com/gnuradio/gr-inspector/tree/master so as to work with
gr-inspector blocks.

I have cross checked every dependency mentioned in the project.Installation
is successful without any error.

But executing any flowgraph including signal_detector block gives m the
following error->


*self.inspector_qtgui_sink_vf_0 = Template error: #set $win =
'self._%s_win'%$idSyntaxError: invalid syntax*

Attaching the flow graph im trying to execute.

Looking for quick reply :)


___
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] Issues using gr-inspector after install

[Sebastian Müller]

Robert,

I’m sorry you’re having difficulties with gr-inspector. I have just tried
to clone, compile and install gr-inspector on Fedora 25 with GNU Radio
3.7.12 and it worked. Please see the attached screenshot [1] from today as
proof.
I have seen gr-inspector run on various setups and distros, including
Fedora, Ubuntu and Arch Linux. However, I cannot provide support for
setting up specific operating systems to meet the dependencies for
gr-inspector. I have uploaded my `cmake ..` and `make` command outputs as
reference for you [2]. Feel free to compare with your output and I’m sure
you’ll be able to track down the issue. Just from skimming I’ve noticed
that there is no line in your cmake output telling that Qt4 was found.

[1] https://imgur.com/a/Tm6Ag
[2] https://pastebin.com/M1hmA05a

Regards,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>

Am 14. April 2018 um 04:08:43, Robert Stanford (rstanford8...@gmail.com)
schrieb:


 If anyone's interested or having the same issue: I've tried to run the
gr-inspector example in a Docker container (seen below) and received the
same error message.  So the issue doesn't seem to be limited to Ubuntu
17.10.

===
FROM fedora:27

RUN yum install -y git gnuradio gnuradio-devel qt qt-devel qwt qwt-devel
gcc gcc-c++ make cmake python python-devel python-pip qwtplot3d-qt4
qwtplot3d-qt4-devel cppunit-devel
RUN yum install -y rtl-sdr xterm gr-osmosdr
RUN pip install tensorflow

# gr-inspector
RUN echo "xterm_executable = /usr/bin/xterm" >>
/etc/gnuradio/conf.d/grc.conf
RUN git clone https://github.com/gnuradio/gr-inspector /tmp/gr-inspector
RUN mkdir /tmp/gr-inspector/build; cd /tmp/gr-inspector/build; cmake ..;
make -j4; make install

ENV PYTHONPATH $PYTHONPATH:/usr/local/lib64/python2.7/site-packages
CMD /bin/bash
===




On Wed, Apr 11, 2018 at 1:48 PM, Robert Stanford <rstanford8...@gmail.com>
wrote:

>
>  I've found and installed the necessary package.  It still has the same
> error when running the example graph.  Like many GNURadio things, this
> seems not entirely portable.  Has anyone been able to get gr-inspector to
> run in a certain Docker environment?
>
> On Wed, Apr 11, 2018 at 1:34 PM, Sebastian Müller <gse...@gmail.com>
> wrote:
>
>> Hello Robert,
>>
>> please use the homepage I referenced to find the packages you need. I
>> searched for you last mail but I’m sure you’ll find the packages that
>> provide the headers as well after a little time of searching. Each OS is
>> different and I cannot support users in setting up their system to meet the
>> requirements for gr-inspector.
>>
>> Thanks,
>>
>> Sebastian Müller
>> gse...@gmail.com
>> PGP ID DC2AA3EE
>> <http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>
>>
>> Am 10. April 2018 um 22:25:19, Robert Stanford (rstanford8...@gmail.com)
>> schrieb:
>>
>>
>>  Sebastian -
>>
>>  I have uninstalled qwt and qwtplot3d, and manually verified that no
>> files matching their name exists on the fs.  I have installed the two
>> packages you've included as references (libqwtplot3d-qt4-dev, libqwt-dev).
>>
>>  I have two new errors when running cmake, including a missing qwt header
>> file (though as I mentioned, I installed the -dev package).  Please see
>> https://pastebin.com/ruz43yTu
>>
>>  The header file that is missing is not included in the file list of the
>> packages you linked.
>>
>>  Thank you for your patience
>>
>>
>>
>>
>> On Tue, Apr 10, 2018 at 11:59 AM, Sebastian Müller <gse...@gmail.com>
>> wrote:
>>
>>> Hi Robert,
>>>
>>> I’m pretty sure you have a corrupt qwt installation on your machine
>>> (which is also 90% the issues users have with gr-inspector).
>>> The file libqwt-qt4.so.5 does not seem to come from qwt-6.1.0 source
>>> build, but from the debian package 'libqwt5-qt4‘.
>>> If you just use a symbolic link and trick cmake into finding this file,
>>> things might go wrong down the road since this is a qwt 5 library! I would
>>> avoid using symlinks for this purpose at all. See my other comments below.
>>>
>>> Am 9. April 2018 um 20:26:36, Robert Stanford (rstanford8...@gmail.com)
>>> schrieb:
>>>
>>>
>>>  Thanks for getting back to me.  The packages I installed were:
>>>
>>>  - libqwtplot3d-qt4-0v5, libqwtplot3d-qt4-dev from apt install
>>>  - qwt-6.1.0 (not the most recent, but what the page recommends), from
>>> source.  I'd previously tried installing the most recent from the repos
>>> (apt), but had the same error I mentioned above so u

Re: [Discuss-gnuradio] Issues using gr-inspector after install

[Sebastian Müller]

Hello Robert,

please use the homepage I referenced to find the packages you need. I
searched for you last mail but I’m sure you’ll find the packages that
provide the headers as well after a little time of searching. Each OS is
different and I cannot support users in setting up their system to meet the
requirements for gr-inspector.

Thanks,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>

Am 10. April 2018 um 22:25:19, Robert Stanford (rstanford8...@gmail.com)
schrieb:


 Sebastian -

 I have uninstalled qwt and qwtplot3d, and manually verified that no files
matching their name exists on the fs.  I have installed the two packages
you've included as references (libqwtplot3d-qt4-dev, libqwt-dev).

 I have two new errors when running cmake, including a missing qwt header
file (though as I mentioned, I installed the -dev package).  Please see
https://pastebin.com/ruz43yTu

 The header file that is missing is not included in the file list of the
packages you linked.

 Thank you for your patience




On Tue, Apr 10, 2018 at 11:59 AM, Sebastian Müller <gse...@gmail.com> wrote:

> Hi Robert,
>
> I’m pretty sure you have a corrupt qwt installation on your machine (which
> is also 90% the issues users have with gr-inspector).
> The file libqwt-qt4.so.5 does not seem to come from qwt-6.1.0 source
> build, but from the debian package 'libqwt5-qt4‘.
> If you just use a symbolic link and trick cmake into finding this file,
> things might go wrong down the road since this is a qwt 5 library! I would
> avoid using symlinks for this purpose at all. See my other comments below.
>
> Am 9. April 2018 um 20:26:36, Robert Stanford (rstanford8...@gmail.com)
> schrieb:
>
>
>  Thanks for getting back to me.  The packages I installed were:
>
>  - libqwtplot3d-qt4-0v5, libqwtplot3d-qt4-dev from apt install
>  - qwt-6.1.0 (not the most recent, but what the page recommends), from
> source.  I'd previously tried installing the most recent from the repos
> (apt), but had the same error I mentioned above so uninstalled and
> installed this recommended version from source.
>- I installed this using these instructions: http://qwt.
> sourceforge.net/qwtinstall.html
>
> Please uninstall all qwt related packages and files from your machine. As
> mentioned above, there seems to be other (broken) qwt installations. This
> is not an easy task, so please take some time to clean everything up!
>
>
>
>  gr-inspector (cmake) had errors until I did these three things:
>   - apt install gnuradio-dev
>
> This is normal if you didn’t build GNU Radio from source.
>
>
>   - ln -s /usr/include/qwt /usr/include/qwtplot3d-qt4
>
> You are symlinking a qwt directory to a qwtplot3d directory. This does not
> make sense to me and will most likely cause problems. All the files you
> need should be in /usr/include/qwtplot3d-qt4 and be provided by
> ‚libqwtplot3d-qt4-dev‘ [1]. If they are not there, something is wrong with
> your system.
>
> If the files are there, please share the output of cmake without
> symlinking beforehand.
>
>
>   - ln -s /usr/lib/libqwt-qt4.so.5 /usr/lib/libqwt-qt4.so
>
> Same thing here libqwt-qt5.so.5 is most likely no file from qwt-6.1.0. The
> library that you need is in /usr/lib/libqwt.so and is provided by
> ‚libqwt-dev‘ [2]. If not, again, something is wrong with your system.
>
>   - I found that I had to do this: export CMAKE_MODULE_PATH=/home/rs/
> devel/gr-inspector/cmake/Modules; cmake ..
>
> This should also not be necessary. What is the error if you don’t do this?
>
>
>
> So, either I am doing something wrong by this point, or there are four
> extra steps (above) that are required to get gr-inspector working on my
> system (Ubuntu 17.10, gnuradio 3.7.10)
>
> Yes, from the points I mentioned above I don’t think you’re getting a
> successful build from here on.
>
>
>
>  I've cleaned and built again to show the output.  Here is the output of
> 'cmake ..': https://pastebin.com/c3hnmNDx
>
>  Here is the output of 'make -j4': https://pastebin.com/zHUAZGn3
>
>  I load the sample graph into gnuradio-companion, and get the error again:
>  https://pastebin.com/DFGAtmGz
>
>  As for the PLL error (while tuning the rtl-sdr), that's something I
> normally experience.  It's never been a show-stopper and I think it can be
> ignored in this case.  I am not tuning to 2.4MHz but am using a 2.4MS/s
> sample rate.
>
>  Thank you again
>
>
> [1] https://packages.ubuntu.com/artful/amd64/libqwtplot3d-qt4-dev/filelist
>
> [2] https://packages.ubuntu.com/artful/amd64/libqwt-dev/filelist
>
>
> Sebastian Müller
> gse...@gmail.com
> PGP ID DC2AA3EE
> <http://pgp.mit.edu/pks/looku

Re: [Discuss-gnuradio] Issues using gr-inspector after install

[Sebastian Müller]

Hi Robert,

I’m pretty sure you have a corrupt qwt installation on your machine (which
is also 90% the issues users have with gr-inspector).
The file libqwt-qt4.so.5 does not seem to come from qwt-6.1.0 source build,
but from the debian package 'libqwt5-qt4‘.
If you just use a symbolic link and trick cmake into finding this file,
things might go wrong down the road since this is a qwt 5 library! I would
avoid using symlinks for this purpose at all. See my other comments below.

Am 9. April 2018 um 20:26:36, Robert Stanford (rstanford8...@gmail.com)
schrieb:


 Thanks for getting back to me.  The packages I installed were:

 - libqwtplot3d-qt4-0v5, libqwtplot3d-qt4-dev from apt install
 - qwt-6.1.0 (not the most recent, but what the page recommends), from
source.  I'd previously tried installing the most recent from the repos
(apt), but had the same error I mentioned above so uninstalled and
installed this recommended version from source.
   - I installed this using these instructions:
http://qwt.sourceforge.net/qwtinstall.html

Please uninstall all qwt related packages and files from your machine. As
mentioned above, there seems to be other (broken) qwt installations. This
is not an easy task, so please take some time to clean everything up!



 gr-inspector (cmake) had errors until I did these three things:
  - apt install gnuradio-dev

This is normal if you didn’t build GNU Radio from source.


  - ln -s /usr/include/qwt /usr/include/qwtplot3d-qt4

You are symlinking a qwt directory to a qwtplot3d directory. This does not
make sense to me and will most likely cause problems. All the files you
need should be in /usr/include/qwtplot3d-qt4 and be provided by
‚libqwtplot3d-qt4-dev‘ [1]. If they are not there, something is wrong with
your system.

If the files are there, please share the output of cmake without symlinking
beforehand.


  - ln -s /usr/lib/libqwt-qt4.so.5 /usr/lib/libqwt-qt4.so

Same thing here libqwt-qt5.so.5 is most likely no file from qwt-6.1.0. The
library that you need is in /usr/lib/libqwt.so and is provided by
‚libqwt-dev‘ [2]. If not, again, something is wrong with your system.

  - I found that I had to do this: export
CMAKE_MODULE_PATH=/home/rs/devel/gr-inspector/cmake/Modules; cmake ..

This should also not be necessary. What is the error if you don’t do this?



So, either I am doing something wrong by this point, or there are four
extra steps (above) that are required to get gr-inspector working on my
system (Ubuntu 17.10, gnuradio 3.7.10)

Yes, from the points I mentioned above I don’t think you’re getting a
successful build from here on.



 I've cleaned and built again to show the output.  Here is the output of
'cmake ..': https://pastebin.com/c3hnmNDx

 Here is the output of 'make -j4': https://pastebin.com/zHUAZGn3

 I load the sample graph into gnuradio-companion, and get the error again:
https://pastebin.com/DFGAtmGz

 As for the PLL error (while tuning the rtl-sdr), that's something I
normally experience.  It's never been a show-stopper and I think it can be
ignored in this case.  I am not tuning to 2.4MHz but am using a 2.4MS/s
sample rate.

 Thank you again


[1] https://packages.ubuntu.com/artful/amd64/libqwtplot3d-qt4-dev/filelist

[2] https://packages.ubuntu.com/artful/amd64/libqwt-dev/filelist


Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>




On Mon, Apr 9, 2018 at 12:40 PM, Sebastian Müller <gse...@gmail.com> wrote:

> Hi Robert,
>
> Am 9. April 2018 um 01:31:42, Robert Stanford (rstanford8...@gmail.com)
> schrieb:
>
>
>  I have cloned and installed gr-inspector using the instructions on the
> webpage.  One change (addition) necessary to get gr-inspector to install on
> my system (Ubuntu 17.10) was to run ln -s /usr/lib/libqwt-qt4.so.5
> /usr/lib/libqwt-qt4.so ; otherwise cmake failed, unable to find
> libqwt-qt4.so.
>
> Can you please provide a *complete* list of qwt packages you installed as
> well as the version?  (For instance with `dpkg -s [package]`)
>
> Also, please provide the output of cmake when before and after the `ln -s`
> command you mention.
>
> Lastly, I’d like to see the output of `make` after a successful cmake run.
> You can use pastebin or something similar since this all is a lot of output.
>
>  I have started gnuradio companion and loaded an example from gr-inspector
> (live_signal_detection.grc).  I adjust the sample rate, since I am using an
> RTL-SDR (adjust to 2.4e6).  The graph comes up, and I press 'play' (execute
> the flow graph).  I get this error:
>
> Found Rafael Micro R820T tuner
> [R82XX] PLL not locked!
> [R82XX] PLL not locked!
>
> I’m not aware of any RTL SDRs that can be tuned to 2.4 MHz (correct me if
> I’m wrong). That’s probably why you get the PLL error here.
>
>
> Traceback (most recent call last):
>   File "/home/rs/devel

Re: [Discuss-gnuradio] Issues using gr-inspector after install

[Sebastian Müller]

Hi Robert,

Am 9. April 2018 um 01:31:42, Robert Stanford (rstanford8...@gmail.com)
schrieb:


 I have cloned and installed gr-inspector using the instructions on the
webpage.  One change (addition) necessary to get gr-inspector to install on
my system (Ubuntu 17.10) was to run ln -s /usr/lib/libqwt-qt4.so.5
/usr/lib/libqwt-qt4.so ; otherwise cmake failed, unable to find
libqwt-qt4.so.

Can you please provide a *complete* list of qwt packages you installed as
well as the version?  (For instance with `dpkg -s [package]`)

Also, please provide the output of cmake when before and after the `ln -s`
command you mention.

Lastly, I’d like to see the output of `make` after a successful cmake run.
You can use pastebin or something similar since this all is a lot of output.

 I have started gnuradio companion and loaded an example from gr-inspector
(live_signal_detection.grc).  I adjust the sample rate, since I am using an
RTL-SDR (adjust to 2.4e6).  The graph comes up, and I press 'play' (execute
the flow graph).  I get this error:

Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[R82XX] PLL not locked!

I’m not aware of any RTL SDRs that can be tuned to 2.4 MHz (correct me if
I’m wrong). That’s probably why you get the PLL error here.


Traceback (most recent call last):
  File "/home/rs/devel/gr-inspector/examples/live_signal_detection.py",
line 142, in 
main()
  File "/home/rs/devel/gr-inspector/examples/live_signal_detection.py",
line 130, in main
tb = top_block_cls()
  File "/home/rs/devel/gr-inspector/examples/live_signal_detection.py",
line 85, in __init__
self.inspector_signal_detector_cvf_0 =
inspector.signal_detector_cvf(samp_rate, 4096, firdes.WIN_BLACKMAN_hARRIS,
AttributeError: 'module' object has no attribute 'signal_detector_cvf'

This just means gr-inspector was not installed correctly. To investigate,
please provide the outputs I mentioned above.



 GNUradio (3.7.10) executes other graphs fine (that is, non-gr-inspector
graphs).  Why am I getting this error with gr-inspector?

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



Cheers,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GR-Inspector Issues

[Sebastian Müller]

Hi Shalom,
Am 5. April 2018 um 11:14:22, Shalom Dubinsky (smdubin...@gmail.com) schrieb:



Hello,

My name is Shalom Dubinsky, and I'm having some trouble with the
gr-inspector module.  I'm trying to use it to detect signals
in the 2.4ghz range, and I can't get reliable responses from
it.  Information on it seems scarce, so I'm asking
here.


First, I tried playing with the default example of 3 cosine waves
all summed with a noise source and run through the Signal Detector
block.  This works as expected - both the GUI Inspector sink
and the message debug output match. However, if I increase the
sample rate too much it loses any accuracy it had. 
Specifically, a sample rate of 4M only picks up two signals, and a
sample rate of 40M only picks up one signal. The error is much
higher in both of them, up to several hundred hz.  Decreasing
it to 20k gives me two reasonably accurate signals and one garbage
signal.


I also tried building my own graph.  I ran a single cosine
wave broadcasting at 200M through a noise generator, the signal
detector block, and the GUI Inspector block.  The sample rate
was consistent throughout the graph, and the FFT length was set to
4096 across the board. The center frequency of the inspector sink
was set at 200M.  The messages reported the signal to be at
800, while the graph displayed it as 208Mhz. Dropping the
cosine frequency to 800k allowed the signal detector to work more
or less correctly, but I had to change the center frequency of the
inspector sink to 0 for it to display the signal correctly. 
The problem at 800k was that the messages would alternate between
~80 and ~-10183594. This isn't the only time I saw negative
frequencies, either.


I next tried attaching it to a real radio.  When I broadcast a
signal(from a different radio) at 2.425ghz, it detected that a
signal was being broadcast, meaning it only reported something when
I broadcast a signal,  but did not accurately detect the
signal frequency. Instead, it would bounce around detecting
different frequencies.


Questions:
Generally I’d like to point to the official documentation [1].



* What is the relationship between sampling rate and signal
detection accuracy?
As described in the docs, the bandwidth of the signal is quantized with the 
block parameter ‚Rel. quantization‘.

This avoids high message load because of noise that slightly changes the 
detection boundries.

The quantization is relative to the used sample frequency. More info can be 
found in the docs and the code.



* What is the relationship between fft length and sampling
rate?  Is it related to signal detection accuracy?
Definitely. One FFT bin covers samp_rate/fft_length Hz. This is the maximum 
resolution

you can get for estimating the signal parameters and highly affects your 
accuracy.

In other words: there is a trade-off between bandwidth and resolution.


* Why does it sometimes report signals with negative
frequencies?
The frequencies are reported in *complex baseband*. Please research what that 
means,

but in a nutshell the frequencies are relative to the carrier frequency. This 
is intended behaviour.



* Why does it sometimes seem to report a frequency
delta?
I’m not sure what you mean by that. The message format is (center_freq, 
bandwidth).



* Is there anything else I'm missing about this module?
If you’re just planning to detect signals, you might be better extending the

gr-inspector detection block or write your own. The algorithm used is very basic

and only works well for steep signal flanks. Depending on the kind of signals 
you plan

to detect you probably want to use a different algorithm. I tried to 
communicate that in

my blog [2].




I've attached the gr-inspector example signal-detection .grc as
well as the modified .grcs mentioned earlier.
Also I’ve seen you mostly use the default parameters in the flowgraphs for your

application, which most likely won’t work. You need to understand the 
parameters and

sensibly choose them if you want the software to behave like you want.




Thank you,

Shalom Dubinsky

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




[1] http://gnuradio.github.io/gr-inspector/
[2] https://grinspector.wordpress.com/2016/06/26/week-5-midterms/

Regards,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE

signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Introduction for GSoC18 participation

[Sebastian Müller]

Hi Luca,

great to hear from you again!
MIMO is definitely a topic that deserves to be tackled by GNU Radio. Your
idea seems well thought of and sensible (and of course your last year’s
work speaks for itself). If I understand correctly, your proposed approach
would only cover the MIMO-OFDM case. I would like to point out that other
modulation schemes than OFDM might be of interest as well for some users,
and therefore I think it is sensible to provide an easy extensibility of
your work. It would be great if you could cover that topic in your proposal!
As Nicolas pointed out, you should have a first draft of your proposal
online in just a few days in order to get more feedback on the mailing list
before the deadline on March 27! I’m looking forward to hear more from you
soon.

Cheers,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>

Am 22. März 2018 um 11:10:37, Nicolas Cuervo (nicolas.cue...@ettus.com)
schrieb:

Hello Luca!

Thank you for showing interest in GSoC (once again! :) )

Your idea sounds very cool and also very useful for users that want to have
a first approach to MIMO, and you did your homework checking where this
idea fits in the tree, and propose reuse of code, which is fantastic. As
you mention, the clock is ticking and, although this idea is potentially
well structured, it does not have a mentor assigned yet, and that puts a
bit of pressure. Have a look at this old mailing-list thread [1], which was
somewhat in the same position as you. If you have already contacted someone
to mentor your project, that would be great! But if not, then writing a
proposal ASAP would help us assess your expectations and probably make
easier for any of us to hop on board as the mentor, should that person feel
capable of providing a solid support. You know the drill :) so I would
recommend you to work on your draft and continue on this open discussion to
keep the conversation alive.

Keep up the good work! Looking forward to that proposal draft ;)

Cheers,
Nicolas
[1]
https://lists.gnu.org/archive/html/discuss-gnuradio/2014-02/msg00291.html

On Thu, Mar 22, 2018 at 1:19 AM, Luca Schmid <luca.moritz.sch...@gmail.com>
wrote:

> Hi everyone,
>
> I am Moritz Luca Schmid, a graduate student from Karlsruhe Institute of
> Technology (KIT). Since 2016 I am in touch with GNU Radio, mainly
> developing for the Communications Engineering Lab (CEL) in Karlsruhe, where
> I am working as an assistant researcher. In 2017, I successfully
> participated in GSoC'17 with GNU Radio, building a DAB/DAB+ Transceiver
> application[1][2], now also know as DABstep ;)
> After GSoC'17, I have continued working on the DAB+ project, improving the
> code and introducing new features. As some examples, I added RTL-SDR
> devices as a possible signal source and currently I am implementing dynamic
> label and Media Object Transfer (MOT) support. I also rewrote the existing
> OFDM PHY layer and developed a more efficient and robust method for
> synchronization in my Bachelor thesis in fall 2017.
>
> I am very excited about the idea of bringing a MIMO capability to the GNU
> Radio project. I read about the suggestion of a MIMO transceiver at the
> list of old ideas for GSOC, proposing to implement an OOT module (gr-mimo)
> that includes the basic encoding and decoding algorithms and therefore
> enriching GNU Radio with another basic telecommunication feature. To do so,
> it proposes an OFDM based phsical layer and the realization of MRC decoding
> and beamforming.
>
> I like the idea of combining the proposed MIMO capability directly with
> OFDM. The combination of frequency and space diversity has shown very
> promising performance results and MIMO-OFDM is considered in a number of
> developing wireless standards. MIMO-OFDM in GR would therefore be a very
> valuable basis for all those, who are interested in these new techniques
> but don't want to build a whole communication system from scratch.
> The GNU Radio core module gr-digital already contains a solid OFDM
> implementation, including a complete transmitter and receiver with
> synchronization. (Actually I found multiple implementations (ofdm_receiver,
> ofdm_txrx, ofdm_mod/demod) including OFDM (de)modulation and
> synchronization (mainly with Schmidl & Cox but also other sync approaches).
> Some of them additionally include the digital (de)modulation/ symbol
> (de)mapping.)
> In order to reuse this existing code for the MIMO idea, I propose the
> inclusion of a (of course optional) MIMO capability in gr-digital's OFDM
> transceiver. In GRC view, I am thinking of an additional parameter for the
> hierarchical blocks of the OFDM transmitter and receiver in form of a drop
> down menu, stating SISO transmission mode as default option, but also
> listing some MIMO possibilities.
>

Re: [Discuss-gnuradio] gr-radar and FMCW radar imlementation for measuring range with high resolution

[Sebastian Müller]

Hi Tilen,

Am 8. Februar 2018 um 16:31:37, Tilen Matkovič (matkovic.ti...@gmail.com)
schrieb:

Hello everyone,

I am working on a project where I am using radars to measure distance/range
from one point to another (with relatively high range resolution - range of
centimeters or even millimeters).

Generally I’m not sure if you will achieve this with the B210 hardware you
mention later. Keep in mind the range resolution equation for radar:

dr >= c/(2*B)

For a range resolution of 1 cm you’ll need a signal bandwidth of 15 GHz
[1], while the URSP has a maximum frequency coverage of up to 6 GHz, which
means your center frequency plus half the bandwidth must be less equal 6
GHz. Common radars, for instance in automotive applications, work on a
center frequency near 100 GHz, allowing much higher bandwidths!

I found the gr-radar (https://github.com/kit-cel/gr-radar/) module for GNU
radio, which already has some implemented radar techniques, the most
promising for me would be the FMCW radar. But the github repository was not
updated in years, so I am asking you guys if some of you may know some
alternatives for GNU radio (googling radar gnuradio was not so successful)
or maybe anyone has already worked with gr-radar.


I’m not aware of any other projects, but I’ve used gr-radar myself. It
definitely works in the real world, which you can see on Stefan’s Youtube
channel [2].

Now what exactly is my problem - I managed to get the gr-radar - FMCW
working on one USRP B210 (with TX/RX and RX2 using omnidirectional
antennas). I was playing around with modifying some of the variables but I
am still not getting useful range data (mostly it is constant, even if
moving both of the antennas for a few meters or putting some obstacles in
between). Modifying the samp_rate or sweep_freq, and others (samp_cw,
samp_up, samp_down) has also not given me useful results.

The original setup for gr-radar consisted of two USRP N210, connected with
a MIMO cable. It never ran on a B10, though there were some attempts, that
seem to never have been further pursued [3].

Also, since you’re using omnidirectional antennas with FMCW, you’ll detect
a lot of static objects in *all* azimuth angles, while gr-radar was
designed for one target only IIRC. So assuming it theoretically could work
on a B210 (please let us know!!), I would propose to use beam antennas and
try to use the dual CW waveform, which only detects moving objects.
Let us know about any progress :)


Perhaps I am doing something wrong and not understanding the theoretical
principles about radars/signal processing or maybe the FMCW flowgraph is
not implemented correctly? I also have to mention here that author (on
github) only tested the FMCW flowgraph in the simulation (which works ok),
but not on the hardware.

Thanks for your help.

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




[1] http://www.radartutorial.eu/01.basics/Range%20Resolution.en.html
[2] https://www.youtube.com/channel/UCv7cqqFkkiRFJIGkNEyMu3g
[3] https://github.com/kit-cel/gr-radar/issues/19

Regards,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Random test failures when compiling GNURadio from source

[Sebastian Müller]

I’ve noticed the same on our buildbot setup (and wanted to address this for
a while). `qa_packet_format` is another candidate which seems to randomly
fail. Also compiling on buildbot seems to fail sometimes randomly because
of `M_SQRT2` or `M_LOG2E` undeclared errors.

So, Kevin, without having a deeper look I assume the tests need to be
revised. I’m also glad to have a look as soon as I find some time. Maybe we
can accumulate faulty tests within this thread and start working from there.

Best,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>

Am 30. Oktober 2017 um 21:14:15, Kevin George (ke...@intelligentrobotics.org)
schrieb:

Hello,

We have been trying to compile and run GNURadio from source and the make
tests have been failing randomly.

*Machine Details*

*Intel NUC (x86-64 machine)*
*Ubuntu 16.04.03*
*GNU Radio version 3.7.11*
*gcc version 5.4.0 20160609*

*Commands used*
*git clone --recursive https://github.com/gnuradio/gnuradio
<https://github.com/gnuradio/gnuradio>*

*git checkout v3.7.11*

*mkdir build*

*cd build*

*cmake -DENABLE_GR_QTGUI=OFF -DCMAKE_INSTALL_PREFIX=/usr/local ../*

*make -j4*
*make test*

Out of every 4 compilations, 1/2 would fail the make test e.g
qa_constellation_receiver(attached
error with email) or
qa_ofdm_sync_sc_cfb. Our fix so far has been to *re-run the build with no
modifications and the tests pass*.

I have seen similar errors pop up in the mailing lists and the cause is
usually incorrect setting of seed.
e.g
https://lists.gnu.org/archive/html/discuss-gnuradio/2012-04/msg00318.html
Does this issue still persist? or known?


--
Regards
Kevin
___
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] Building gnuradio with Pybombs on MacOSX

[Sebastian Müller]

Hi,

I’ve had a look on this and want to share what I found out. My setup is
macOS 10.13 with MacPorts in /opt/local. I’ve used `pybombs install
gnuradio` straight away and worked my way to a successful build from there.
Please note that I have another GR installation from MacPorts, which means
some dependencies may already be installed, but would fail to build from
source in PyBombs.

First, I ran into PyBombs issue #423 (
https://github.com/gnuradio/pybombs/issues/423). While Python dependencies
are installed for 2.7, UHD then uses my default interpreter in
/opt/local/bin/python, which is 3.5. Configuring then fails because mako is
not found. This problem can be individually solved by installing the
dependencies manually for the correct python version or forcing UHD to use
2.7 by using `FIND_PACKAGE(PythonInterp 2.7 REQUIRED)` in
host/cmake/Modules/UHDPython.cmake. Still, this issue generally remains
unsolved. After these changes, I was able to build UHD on my machine.

Next, GNU Radio failed to find Qt4 correctly. This is due to a MacPorts
issue (https://trac.macports.org/ticket/49629) where no `qmake` executable
is installed into any $PATH. I’ve solved this creating a symlink from
/opt/local/libexec/qt4/bin/qmake to /opt/local/bin. After this change, Qt4
is found by cmake.

GNU Radio still failed to build because of a linking error `ld: library not
found for -lgsl`. I had to make some changes as suggested by Peter, but
found out Bastian has deleted them earlier in #1247 (
https://github.com/gnuradio/gnuradio/pull/1247). I’ve created a new PR to
further discuss this in #1490 (
https://github.com/gnuradio/gnuradio/pull/1490). After this, I managed to
build GNU Radio.

Still, GRC wouldn’t start because different python installations where used
(I’m not sure which ones). By manually defining the paths as suggested by
Brian, the build succeeds and GRC can actually be started. As a test, I ran
gr-digital/examples/ofdm/ofdm_loopback.grc, which worked fine.

The complete cmake command now was (change CMAKE_INSTALL_PREFIX to your
PyBombs prefix!):

`cmake .. -DCMAKE_INSTALL_PREFIX=[pybombs prefix] -DENABLE_GR_DTV=1
-DENABLE_GR_ATSC=1 -DPYTHON_EXECUTABLE=/opt/local/bin/python2.7
-DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Headers
-DPYTHON_LIBRARY=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python
-DSPHINX_EXECUTABLE=/opt/local/bin/rst2html-2.7.py`.

Hope this helps us to make more progress with GR on Mac :)

Best,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>

Am 25. Oktober 2016 um 18:51:14, Brian Cuthie (br...@systemix.com) schrieb:


Hi Martin,

Please see my original post under this subject title. It contained a few
other 'gotchas' I found when building for MacOSX using Pybombs.

-brian

Sent from my iPhone

> On Oct 25, 2016, at 11:41 AM, Martin Braun <martin.br...@ettus.com>
wrote:
>
> Not quite related, but I would love to see PyBOMBS become a stable means
> for installation on Mac OS X. For other distros, I've started adding
> Docker containers for testing, but Mac OS obviously doesn't let us do
that.
>
> Any specific bug report from installing on Mac is thus appreciated --
> and then of course, fixes :)
>
> Cheers,
> Martin
>
>> On 10/22/2016 03:12 PM, Brian Cuthie wrote:
>>
>> Hi Ron,
>>
>> That’s a great pointer, thanks. I hadn’t noticed that gr-fec also uses
gsl.
>>
>> Looking at the CMake config for gr-fec I can see where it adds the path
for libgsl, however, the path definition appears to be missing from the
gr-dtv and gr-atsc configs. So while the link command for gr-fec includes
"-L/opt/local/lib” to define where to find libgsl, the link commands for
gr-atsc and gr-dtv do not and the link fails.
>>
>> Here’s the link command CMake spit out for gr-dtv swig:
>>
>>
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-std=c++98 -O2 -g -DNDEBUG -bundle -Wl,-headerpad_max_install_names -o
_dtv_swig.so CMakeFiles/_dtv_swig.dir/dtv_swigPYTHON_wrap.cxx.o
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python
../lib/libgnuradio-dtv.3.7.11git.dylib
../../gr-analog/lib/libgnuradio-analog.3.7.11git.dylib
../../gr-filter/lib/libgnuradio-filter.3.7.11git.dylib
../../gr-fft/lib/libgnuradio-fft.3.7.11git.dylib
/opt/local/lib/libfftw3f.dylib /opt/local/lib/libfftw3f_threads.dylib
../../gr-fec/lib/libgnuradio-fec.3.7.11git.dylib
../../gr-blocks/lib/libgnuradio-blocks.3.7.11git.dylib
../../gnuradio-runtime/lib/libgnuradio-runtime.3.7.11git.dylib
../../gnuradio-runtime/lib/pmt/libgnuradio-pmt.3.7.11git.dylib
/opt/local/lib/libboost_date_time-mt.dylib
/opt/local/lib/libboost_program_options-mt.dylib
/opt/local/lib/libboost_filesystem-mt.dylib
/opt/local/lib/libboost_system-mt.dylib
/opt/local/lib/libboost_regex-mt.dylib
/opt/local/

[Discuss-gnuradio] Integrate Mac in CI

[Sebastian Müller]

Hi list!

I’ve had the idea on extending our CI with a Mac installation. Many problems 
remain undetected for a long time when using GNU Radio on a Mac, since we are 
not many out there :) . Andrej, do you know if this is possible/how to do this? 
I would gladly support you with this or take over the task!

Best,

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE

signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Doxygen documentation in GRC

[Sebastian Müller]

I think this has been fixed in
https://github.com/gnuradio/gnuradio/commit/ac925c426dd8dc75b6ee0bd82506e0f59cc5f207,
so 3.7.10.2 or later should have this fixed IIRC. Do you maybe have an
older installation?

Sebastian Müller
gse...@gmail.com
PGP ID DC2AA3EE
<http://pgp.mit.edu/pks/lookup?op=vindex=0x9FFBD55DDC2AA3EE>

Am 10. Oktober 2017 um 07:40:23, Dave NotTelling (dmp250...@gmail.com)
schrieb:

Anyone have input on this?  I'm trying to make my blocks more user
friendly, but all I've been able to get to show up is the description.  The
information about each parameter is lost in GRC.  Shows up fine in the HTML
report.

On Wed, Aug 10, 2016 at 6:01 AM, Sebastian Müller <gse...@gmail.com> wrote:

> Hi all,
>
> I've been trying now for some days to include the doxygen documentation
> for my OOT in the GRC blocks (in the tab Documentation). While actually
> *something* is displayed there, it is not all that I want. For instance the
> complete \details section is missing as well as a tabular constructor
> parameter description. Both seem to work in other blocks
> (tv_dvbt2_framemapper_cc or digital_ofdm_carrier_allocator_cvc as
> reference).
>
> The HTML doxygen documentation is generated perfectly. Can you point me to
> what I might be missing? I suppose it could be a SWIG issue since GRC is
> only displaying the swigged block's __doc__ property.
>
> Cheers,
> Sebastian
>
> ___
> 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] libqwt

[Sebastian Müller]

You need to build it from sources (there is plenty of docs on that) or
upgrade your OS to a more modern one (Ubuntu 16.04 would work).

Best,
Sebastian

Am 24. Juni 2017 um 06:25:33, GNUBeginner (muratc...@hotmail.com) schrieb:

> Hello Everyone,
>
> Could please anyone tell me how to upgrade libqwt from version 6.0 to 6.1
> or
> higher on Ubuntu 14.04? I would like to use gr-inspector.
>
> Thanks.
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/libqwt-tp64355.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] GR-Inspector Installation problems

[Sebastian Müller]

Hi Neil,

the error you mention originates from cmake not able to find a specific
header file, which is included in QWT 6.1 and later. So, if QWT is properly
installed on your system, it *should* work. My most likely guess is that
you have some unclean or old QWT installation besides 6.1 with which cmake
tries to build gr-inspector. Can you check that no other QWT version
remainings are present on your system?

Best,
Sebastian

Am 19. Juni 2017 um 20:26:44, Neil2017 (ndshel...@hotmail.co.uk) schrieb:

Hi all,

Following on, I am still having the same issue, I have checked the version
of QWT and have version 6.1.2-6 amd64 installed. Does anyone have any other
ideas please? Thanks. Neil.


original quote:
Hi all, I am attempting to install GR-Inspector for use with GNU Radio on
Kali O/S.
I have followed the instructions on
https://github.com/gnuradio/gr-inspector, and followed the commands:
git clone g...@github.com:gnuradio/gr-inspector.git
cd gr-inspector
mkdir build
cd build
cmake ..
make -j4
sudo make install

After doing cmake .. (in which no errors occured), i ran the "make -j4"
command, but received a few errors in the ouput below. Any help would be
much appreciated. Neil.


root@kali:~/gr-inspector/build# make -j4
/root/gr-inspector/build/lib/../../lib/signal_marker.h:28:31: fatal error:
qwt_plot_zoneitem.h: No such file or directory
#include 
^
compilation terminated.
lib/CMakeFiles/gnuradio-inspector.dir/build.make:72: recipe for target
'lib/CMakeFiles/gnuradio-inspector.dir/moc_inspector_form.cxx.o' failed
make[2]: ***
[lib/CMakeFiles/gnuradio-inspector.dir/moc_inspector_form.cxx.o] Error 1
make[2]: *** Waiting for unfinished jobs
Scanning dependencies of target _inspector_swig_swig_tag
In file included from
/root/gr-inspector/build/lib/../../lib/vis3d_vf_form.h:34:0,
from /root/gr-inspector/build/lib/moc_vis3d_vf_form.cxx:9:
/root/gr-inspector/build/lib/../../lib/signal_marker.h:28:31: fatal error:
qwt_plot_zoneitem.h: No such file or directory
#include 
^
compilation terminated.

CMakeFiles/Makefile2:137: recipe for target
'lib/CMakeFiles/gnuradio-inspector.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-inspector.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2



-- 
View this message in context:
http://gnuradio.4.n7.nabble.com/GR-Inspector-Installation-problems-tp64256p64294.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] PROBLEM IN PREAMBLE REMOVING

[Sebastian Müller]

I think the „Keep M in N“ block is what you are looking for. It
periodically discards certain samples.

Best,

Sebastian Müller
gse...@gmail.com

Am 17. Mai 2017 um 15:19:10, Huzaifa niazi (huzaifaniaz...@gmail.com)
schrieb:

Hi , i am using 16 qam mdulation transmission and reception on gnuradio , I
have to do synchronization at reciever side ,I am using correlate and sync
block i get the peak but i want to know how to remove preamble from my
frame after this block , so please help in this regard
___
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] GRC sheet size

[Sebastian Müller]

In the „Options“ Block, there is a parameter named „Canvas Size“. Enter
there WIDTH, HEIGHT, e.g. "1280, 1024“.

Regards,

Sebastian Müller
gse...@gmail.com

Am 28. April 2017 um 08:56:42, Fernando (ferna...@samara.com.es) schrieb:

Is it possible to change the "sheet size" in GRC?

I'm working on a big diagram and it does not fit well.


regards



___
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] [GSOC17 - Draft proposal] Implement SigMF functionality for GNU Radio

[Sebastian Müller]

Hi Kostis,

I wanted to add some of my thoughts to this. Hope I haven’t missed an
answer so far in this extensive discussion.

- Concerning the filtering of datafiles, I think there should be 2 ways to
do this. The first one selecting a core / capture / annotation object from
the SigMF file which results in a selection/zoom in the time/frequency
plots and display of the corresponding metadata in GUI component C. The
second could be a „free selection“ in these plots, that again creates the
corresponding metadata and enables adding fields (like comment for an
annotation object) and saving them as new object to the metadata file.

- I think a standalone tool for converting datasets to SigMF would be
sensible (e.g. put that in the „apps“ folder). Since we don’t have a
continuous stream of samples here, but a one-time action that requires some
user input. You could use the mentioned GUI for that.

- You mentioned filtering for modulation. That is a killer feature, but how
are you planning to do that?

- Concerning the GUI I have some eyecandy in mind. Like highlighting
capture / annotations objects when displaying the whole time signal.
Clicking on one object could enable the mentioned filter for it and „zoom“
into the segment while changing the metadata as well.

- I think you should be more detailed on your timeline.

Best,
Sebastian Müller
gse...@gmail.com

Am 25. März 2017 um 01:21:03, Kostis Triantafyllakis (ctri...@csd.uoc.gr)
schrieb:

Bastian, Ben, Seth, Nathan and Paul,

Thank you all for your useful feedback!
It's really exciting the fact that this project is a chance for such an
interesting discussion.
I will try to make some initial comments on your responses and I'll start
working on the updated proposal as soon as possible.

On 03/24/2017 06:01 PM, Ben Hilburn wrote:

Hi Kostis -

Great proposal! I'm really excited to see someone tackling the SigMF item
on the Ideas List.

I'll respond in-line to Bastian, and then add some of my own:

- You mention that sources and sinks will handle PDUs and Tagged
> Streams. I wonder what would be one PDU. A SigMF "capture segment" or
> some other chunk of samples. Also are you sure you want to use Tagged
> Streams? Maybe you meant normal streams with tags? With Tagged Streams,
> you would have to fit the whole capture segment in the input buffer of
> the block. That might not be possible.
>
> I was actually referring to normal streams with tags. I should fix that in
my proposal.
Furthermore, I  will examine the case of Tagged Streams in order to be able
to safely reject them.

- You mention that RapidJSON code is messy. Does it auto-generate code?
> That could even be an advantage, since SigMF might well go through some
> more iterations. Did you plan to also create wrappers for Python?
>
> Messy was a word I've chosen to describe that the produced code is not so
easy to read and understand.
Python wrappers were not in my initial intentions, but as long as the
timeline permits it I would be interested on implementing them.

- The goal of SigMF seems to be to provide a very minimal spec, and I
> think many users will have to rely on custom extension in namespaces.
> Maybe you could describe a bit how source/sinks and the GUI could deal
> with these extensions.


> - You will provide the means to filter data. Did you only plan to filter
> specific capture segments or also arbitrary samples based on
> annotations? Since you mentioned modulation, which is, AFAIK, currently
> not specified, did you plan to allow filtering on custom properties?
>

So, thinking about this a bit, if Kostis' implementation enables filtering
on fields in the `core` namespace, it shouldn't really be any additional
effort to support non-`core` namespaced fields. Since any field would be in
a capture / annotation segment, which thus would be mapped to a sample
index / number of samples, Kostis' software doesn't have to care *what*
that field is in order to "select it" in the tool.

That's how I read the proposal, anyway. Kostis, it might be good to clarify
this in the proposal.


I think Ben's answer covered the concept I had in my mind. For sure I have
to rephrase/clarify this in the proposal.

- Regarding the GUI, it seems as if you plan to develop something from
> scratch. Did you consider extending projects like "such samples" from
> Tim or Inspectrum?
>

(Seth just responded while I was writing this message, but my comments are
similar.)

I agree with Seth and Bastian, here. Generally, I'm a fan of extending
existing functionality rather than creating something from scratch. That
said, using one of the existing things will also require development.

In the "such samples" case, it's actually just itself a flowgraph (
https://github.com/osh/gr-pyqt/blob/master/apps/such_samples2.grc). In
order to integrate SigMF into it (which I don't think is a bad idea), new
blocks / code will need

Re: [Discuss-gnuradio] Module has no 'attribute'---OOT Module

[Sebastian Müller]

Hi Tellrell,

I just recently installed the gr-inspector oot module. When I tried to run
a flow-graph using one of the blocks from the module I got the following
error.

please try to keep replying to only one subject on the mailing list (you
have opened 3 threads so far, all on gr-inspector).

AttributeError: 'module' object has no attribute 'signal_detector_cvf'

Not sure what possibly went wrong. Any ideas??

This just means gr-inspector is not (properly) installed. From the
information you provided so far I cannot identify what is going wrong on
your system. Also, you should make sure python and all other dependencies
work fine (regarding your previous mail) before you try to install
gr-inspector.

Best,

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

Re: [Discuss-gnuradio] Regarding GSoC 2017

[Sebastian Müller]

Hi Sushil,

cool that you’re interested in participating in GSoC for GNU Radio.
Still, you’re very early with your proposal. You will have time until early
April to submit your final proposal. GNU Radio as organization will know
about their participation in GSoC not earlier than February 27. There will
also be guidelines published on the GNU Radio website early enough for you
to write your proposal, so I’ll advise you to postpone your application for
a few weeks.

Best,
Sebastian

Am 31. Januar 2017 um 12:33:34, sushil iyer (iyersus...@gmail.com) schrieb:

*GSoC Proposal for GNU Radio*

GNU radio has been one of the best simulation software platform for
designing almost any communication system. In particular, our research
expertise exists in the field of *software defined radio (cognitive radio)*.
The major utility of cognitive radios (CR) lies in developing a protocol
for efficient dynamic spectrum access. As of now, there are various blocks
available in the GNU radio companion which help in building different
cognitive radio specific systems but our interest is mainly focused over
the enhancement of Quality of Experience of CR users (secondary or
unlicensed users) through *Machine Learning based efficient dynamic
spectrum access (DSA)*.

In GNU radio, we intend to develop a comprehensive Learning based (*supervised
learning like Artificial Neural Networks, Support Vector Machines,
Recurrent Neural Networks, and unsupervised learning like K-means
clustering*) DSA library which would help the CR research community to
immediately design gamut of systems simply by utilizing the blocks present
in our library, viz. *spectrum prediction, spectrum modeling, spectrum
characterization* and many more.

We have already published the efficiency of applied machine learning in the
context of cognitive radio scenarios thereby providing better and enhanced
QoE of CR users and our idea is to *extend this horizon towards GNU radio
companion* so as to better appreciate and qualify the CR research with
simplicity, robustness and efficiency.

We would love to be a part of this program and contribute vitally towards
the community.

Yours Sincerely
Sushil Iyer
B.Tech Third Year
LNMIIT, Jaipur
___
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] Gr-Inspector install errors

[Sebastian Müller]

Ok, I think cmake is still finding the older Qwt version, while the new one
is installed as well. The file mentioned in the error message
(qwt_plot_zoneitem.h) is new in version 6.1.0 and should therefore be
found. Did you uninstall Qwt with apt-get before you reinstalled from
source? If not, please try that. If this does not help, can you tell me
where the files (in particular qwt_global.h) are getting installed on your
system? All file paths will be printed when running `sudo make install` at
the end of the installation process.

Cheers,
Sebastian

Am 29. Januar 2017 um 01:53:26, Tellrell White (t_whit...@yahoo.com)
schrieb:

I installed QWT 6.1.0 from the link you provided however, I'm getting the
same header file error. Not quite sure what's going on at this point. I've
installed qwtplot3d as well as qwt 6.1.0 to make sure I have the necessary
dependencies.

Tellrell


On Saturday, January 28, 2017 2:38 PM, Sebastian Müller <gse...@gmail.com>
wrote:


/home/rell320/gr-inspector/ lib/signal_marker.h:28:31: fatal error:
qwt_plot_zoneitem.h: No such file or directory
   #include 
   ^
   compilation terminated.



This is most likely because of your qwt version. Minimum required version
is 6.1.0 (see Readme), while Ubuntu 14.04 has an earlier version in it's
repos.
You should install version 6.1.0 on you system, which you can either do by
compiling it from sources [1] or upgrading your distro to a more recent
version.

Best, Sebastian

[1] http://qwt.sourceforge.net/qwtinstall.html





On Saturday, January 28, 2017 8:13 AM, Sebastian Müller <gse...@gmail.com>
wrote:


Hi Tellrell,

Looks like its a QWTPLOT3D issue, which is a dependency. I tried installing
that but I'm having some difficulty there.

What do you mean by 'I tried installing that'? Did you succeed? Or what is
the problem if not? Can you specify your OS and version?

 Could NOT find Qt4 (missing: QT_QWTPLOT3D_INCLUDE_DIR QT_QWTPLOT3D_LIBRARY)

This is basically cmake telling you QwtPlot3D cannot be found. Most likely,
you need to install this (see above) and it should work.
Cheers,
Sebastian

__ _
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/ listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>




__ _
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/ listinfo/discuss-gnuradio
<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] Gr-Inspector install errors

[Sebastian Müller]

>
> /home/rell320/gr-inspector/lib/signal_marker.h:28:31: fatal
> error: qwt_plot_zoneitem.h: No such file or directory
>#include 
>^
>compilation terminated.
>


This is most likely because of your qwt version. Minimum required version
is 6.1.0 (see Readme), while Ubuntu 14.04 has an earlier version in it's
repos.
You should install version 6.1.0 on you system, which you can either do by
compiling it from sources [1] or upgrading your distro to a more recent
version.

Best, Sebastian

[1] http://qwt.sourceforge.net/qwtinstall.html


>
>

> On Saturday, January 28, 2017 8:13 AM, Sebastian Müller <gse...@gmail.com>
> wrote:
>
>
> Hi Tellrell,
>
> Looks like its a QWTPLOT3D issue, which is a dependency. I tried
> installing that but I'm having some difficulty there.
>
> What do you mean by 'I tried installing that'? Did you succeed? Or what is
> the problem if not? Can you specify your OS and version?
>
>  Could NOT find Qt4 (missing: QT_QWTPLOT3D_INCLUDE_DIR
> QT_QWTPLOT3D_LIBRARY)
>
> This is basically cmake telling you QwtPlot3D cannot be found. Most
> likely, you need to install this (see above) and it should work.
> Cheers,
> Sebastian
>
> ___
> 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] Gr-Inspector install errors

[Sebastian Müller]

Hi Tellrell,

Looks like its a QWTPLOT3D issue, which is a dependency. I tried installing
that but I'm having some difficulty there.

What do you mean by 'I tried installing that'? Did you succeed? Or what is
the problem if not? Can you specify your OS and version?

 Could NOT find Qt4 (missing: QT_QWTPLOT3D_INCLUDE_DIR QT_QWTPLOT3D_LIBRARY)

This is basically cmake telling you QwtPlot3D cannot be found. Most likely,
you need to install this (see above) and it should work.

Cheers,

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

[Discuss-gnuradio] Constellation Blocks

[Sebastian Müller]

Hi list,

I’m a bit confused about the constellation blocks that are going to replace
the deprecated specific modulation blocks.
In previous examples, we used

[Signal]->[Packet Encoder]->[Mod Block]->[Channel]->[Demod Block]->[Packet
Decoder]->[Sink].

Now, I’ve tried to replace this chain with non-deprecated blocks. First,
I’m wondering why I can choose differential encoding in the „Constellation
Object“ block as well as in the „Constellation Modulator“ block. What
happens if I only select it in one of them? Also, there is no way to select
differential encoding in the „Constellation Decoder“, but AFAIK the
receiver must know if differential encoding is used. How is this correctly
intended?
Second, I’m wondering what is going to replace the deprecated „Packet
Encoder“. Theoretically, we need an encoding to transfer the infinite input
alphabet (float) to a finite output alphabet (int8). I’ve not found a block
that handles this task. Any ideas on how to replace the signal chain above
is appreciated!

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

Re: [Discuss-gnuradio] (no subject)

[Sebastian Müller]

Hi Idress,

not knowing this module in particular, the examples folder is always a good
spot to make first steps.
There are some demo flowgraphs that should make clear how the toolbox works.

Best,
Sebastian



Am 24. August 2016 um 13:30:55, Idress Mughal (kenshiblind...@yahoo.com)
schrieb:

hi i am new to SDR technology, it's been a month i started small
experiments on SDR. About a month ago installed gr-gsm (hatsoff to its
developer) and analysed 2G signals. now i changed my plans and thought to
know about 4G/LTE. downloaded the gr-lte . foolowed all steps as describes
in( kit-cel/gr-lte ) . ran through each
and every step without any errors. gr-lte blocks can also be seen in GRC ,
but now i don't know what to do next. I mean like how can i
analze,capture,or decode the LTE signals. i am new and don't know much
about it. please guide me on this topic.
thanks !

kit-cel/gr-lte
gr-lte - GNU Radio LTE receiver


___
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] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi all!

GSoC 2016 is coming to an end and I have written a final blog post about
gr-inspector:
https://grinspector.wordpress.com/2016/08/19/week-13-the-end/

All milestones could be reached. Also have a look if you're interested in
the promo video!

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

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi all,

it's the second last week of GSoC 2016 and I've dealt with the last (small)
issues that accumulated during the last weeks.
Read about it here:
https://grinspector.wordpress.com/2016/08/12/week-12-solving-the-small-issues/

Stay tuned next week for the pybombs and promo video release!

Cheers,
Sebastian

2016-08-05 17:08 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>:

> ach stimmt, du machst ja "live" decoding! ja, da müssen die sampleraten
> insgesamt stimmen :)
>
> On 08/05/2016 05:07 PM, Sebastian Müller wrote:
>
> Die Audio Sink will halt 48kHz und spielt das, was rein kommt, mit genau
> dieser Rate ab. Wenn ich jetzt ein Signal mit anderer Samprate reingebe,
> wird das Signal zu schnell/langsam abgespielt. Bei kleinen Differenzen gibt
> das Mickymousestimmen, aber irgendwann versteht man halt garnix mehr.
>
> Am 5. August 2016 um 16:43:36, Marcus Müller (marcus.muel...@ettus.com)
> schrieb:
>
>> Kurz ma off-list:
>>
>> sag mal, was passiert eigentlich mitm demodulierten Signal bei FM, wenn
>> du *nicht* resamplest? Steh ich da grad aufm Schlauch, oder ist die
>> Frequenzmodulation dann einfach nur mitm Faktor skaliert? Wäre es da nicht
>> einfacher, diesen Faktor nach dem Demodulieren draufzurechnen?
>>
>> Grüße
>> Marcus
>>
>> On 08/05/2016 04:40 PM, Sebastian Müller wrote:
>>
>> Hi,
>>
>> GSoC week 11 is over and I have updated my block with what I have been
>> doing this week:
>> https://grinspector.wordpress.com/2016/08/05/week-11-let-the-music-play/
>>
>> Thanks to an universal resampler in the Signal Extractor it is now
>> possible to demodulate detected FM signals.
>>
>> Cheers
>> Sebastian
>>
>> 2016-07-29 16:39 GMT+02:00 Dave NotTelling <dmp250...@gmail.com>:
>>
>>> Great work!
>>>
>>> On Fri, Jul 29, 2016 at 10:36 AM, Sebastian Müller < <gse...@gmail.com>
>>> gse...@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> week 10 of GSoC is over and I managed to implement an OFDM sync block:
>>>> https://grinspector.wordpress.com/2016/07/29/week-10-sync/
>>>>
>>>> Since I make good time, I will try to add a FM demod block to the
>>>> toolbox. Target is to have one example workflow from Ether to demod data (=
>>>> sound).
>>>>
>>>> Cheers,
>>>> Sebastian
>>>>
>>>> 2016-07-22 16:11 GMT+02:00 Sebastian Müller < <gse...@gmail.com>
>>>> gse...@gmail.com>:
>>>>
>>>>> Hi list,
>>>>>
>>>>> in week 9 of my GSoC I finally managed to implement a working OFDM
>>>>> parameter estimation block. Read here about it:
>>>>> <https://grinspector.wordpress.com/2016/07/22/week-9-ofdm-finale/>
>>>>> https://grinspector.wordpress.com/2016/07/22/week-9-ofdm-finale/
>>>>>
>>>>> Next up is a frequency and timing synchronization block.
>>>>>
>>>>> Cheers
>>>>> Sebastian
>>>>>
>>>>> 2016-07-18 9:57 GMT+02:00 Sebastian Müller < <gse...@gmail.com>
>>>>> gse...@gmail.com>:
>>>>>
>>>>>> Hi Martin,
>>>>>>
>>>>>> I have no problem with keeping the 'old' algo in the toolbox. But
>>>>>> still I'm not sure if it is usable in real-world scenarios with sampling
>>>>>> offsets. Maybe someone can improve it if interested.
>>>>>>
>>>>>> Cheers, Sebastian
>>>>>>
>>>>>> 2016-07-15 19:22 GMT+02:00 Martin Braun < <martin.br...@ettus.com>
>>>>>> martin.br...@ettus.com>:
>>>>>>
>>>>>>> To clarify, if Koslowski's algorithm (since you already coined the
>>>>>>> term...) is *as* good as your original one, but also faster, you
>>>>>>> should
>>>>>>> not have duplicates. But if you did all the work to create software
>>>>>>> that
>>>>>>> actually outperforms the fast algorithm in some other aspect,
>>>>>>> there's no
>>>>>>> harm in keeping it around.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> M
>>>>>>>
>>>>>>> On 07/15/2016 10:20 AM, Martin Braun wrote:
>>>>>>> > Sebastian,
>>>>>>> >
>>>>>>> > thanks for sharing

[Discuss-gnuradio] Doxygen documentation in GRC

[Sebastian Müller]

Hi all,

I've been trying now for some days to include the doxygen documentation for
my OOT in the GRC blocks (in the tab Documentation). While actually
*something* is displayed there, it is not all that I want. For instance the
complete \details section is missing as well as a tabular constructor
parameter description. Both seem to work in other blocks
(tv_dvbt2_framemapper_cc or digital_ofdm_carrier_allocator_cvc as
reference).

The HTML doxygen documentation is generated perfectly. Can you point me to
what I might be missing? I suppose it could be a SWIG issue since GRC is
only displaying the swigged block's __doc__ property.

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

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi,

GSoC week 11 is over and I have updated my block with what I have been
doing this week:
https://grinspector.wordpress.com/2016/08/05/week-11-let-the-music-play/

Thanks to an universal resampler in the Signal Extractor it is now possible
to demodulate detected FM signals.

Cheers
Sebastian

2016-07-29 16:39 GMT+02:00 Dave NotTelling <dmp250...@gmail.com>:

> Great work!
>
> On Fri, Jul 29, 2016 at 10:36 AM, Sebastian Müller <gse...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> week 10 of GSoC is over and I managed to implement an OFDM sync block:
>> https://grinspector.wordpress.com/2016/07/29/week-10-sync/
>>
>> Since I make good time, I will try to add a FM demod block to the
>> toolbox. Target is to have one example workflow from Ether to demod data (=
>> sound).
>>
>> Cheers,
>> Sebastian
>>
>> 2016-07-22 16:11 GMT+02:00 Sebastian Müller <gse...@gmail.com>:
>>
>>> Hi list,
>>>
>>> in week 9 of my GSoC I finally managed to implement a working OFDM
>>> parameter estimation block. Read here about it:
>>> https://grinspector.wordpress.com/2016/07/22/week-9-ofdm-finale/
>>>
>>> Next up is a frequency and timing synchronization block.
>>>
>>> Cheers
>>> Sebastian
>>>
>>> 2016-07-18 9:57 GMT+02:00 Sebastian Müller <gse...@gmail.com>:
>>>
>>>> Hi Martin,
>>>>
>>>> I have no problem with keeping the 'old' algo in the toolbox. But still
>>>> I'm not sure if it is usable in real-world scenarios with sampling offsets.
>>>> Maybe someone can improve it if interested.
>>>>
>>>> Cheers, Sebastian
>>>>
>>>> 2016-07-15 19:22 GMT+02:00 Martin Braun <martin.br...@ettus.com>:
>>>>
>>>>> To clarify, if Koslowski's algorithm (since you already coined the
>>>>> term...) is *as* good as your original one, but also faster, you should
>>>>> not have duplicates. But if you did all the work to create software
>>>>> that
>>>>> actually outperforms the fast algorithm in some other aspect, there's
>>>>> no
>>>>> harm in keeping it around.
>>>>>
>>>>> Cheers,
>>>>> M
>>>>>
>>>>> On 07/15/2016 10:20 AM, Martin Braun wrote:
>>>>> > Sebastian,
>>>>> >
>>>>> > thanks for sharing, and your awesome work! I would suggest if you
>>>>> have
>>>>> > an algorithm with great detection characteristics, you should keep
>>>>> it.
>>>>> > If you want another suboptimal but fast one, create a second block
>>>>> (or
>>>>> > whatever it is). The first algorithm did cost you time, and its
>>>>> superior
>>>>> > detection performance might be interesting to other people.
>>>>> >
>>>>> > Cheers,
>>>>> > Martin
>>>>> >
>>>>> > On 07/15/2016 08:10 AM, Sebastian Müller wrote:
>>>>> >> Hi list,
>>>>> >>
>>>>> >> week 8 of GSoC is over and the latest news on gr-inspector are
>>>>> online:
>>>>> >> https://grinspector.wordpress.com/2016/07/15/week-8-
>>>>> performance-issues/
>>>>> >>
>>>>> >> This week was a bit disappointing because the algorithm for the OFDM
>>>>> >> estimation, which did show nice estimation results, and which I
>>>>> dealt
>>>>> >> with 2 weeks now, had to be replaced because of performance issues.
>>>>> Now
>>>>> >> I'll try a more straight-forward algorithm and hope to get started
>>>>> with
>>>>> >> synchronization in two weeks.
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Sebastian
>>>>> >>
>>>>> >> Sebastian Müller <gse...@gmail.com <mailto:gse...@gmail.com>>
>>>>> schrieb am
>>>>> >> Fr., 8. Juli 2016 um 13:48 Uhr:
>>>>> >>
>>>>> >> Hi all,
>>>>> >>
>>>>> >> week 7 of GSoC is over and I have written a blog post about what
>>>>> >> I've been up to:
>>>>> >> https://grinspector.wordpress.com/2016/07/08/week-
>>>>> 7-ofdm-prototype/
>>&g

Re: [Discuss-gnuradio] Resampler with changing rate during runtime

[Sebastian Müller]

Hi Kevin,

the problem arises since my blocks detect signals in the spectrum and
estimate their bandwidth. Then, each signal gets filtered and decimated to
the needed sample rate according to Nyquist-Shannon. This sample rate is
well defined, but only known during runtime.

Regards
Sebastian

2016-08-04 17:47 GMT+02:00 Kevin Reid <kpr...@switchb.org>:

> On Wed, Aug 3, 2016 at 8:29 AM, Sebastian Müller <gse...@gmail.com> wrote:
>
>> Now, the quadrature rate and audio decimation are unknown before runtime,
>> but calculated by my other blocks while running. For this purpose, I would
>> like to implement a block, that resamples any given signal to a fixed
>> output sample rate (in this example a bit more than the audio rate). I have
>> messages available that contain the sample rate of my input signal as well
>> as the input signal itself.
>>
>
> I'd like to ask: How does this problem arise? In my experience, almost
> every element of the flowgraph has a specific sample rate (sources and
> sinks) or rate ratio (interpolators/decimators), so even if you decide you
> need a certain different rate, you're always going to be modifying the
> configuration of at least two blocks.
>
> How is it that you *come to have* a stream with a dynamic sample rate?
>
> (I suspect that you are overcomplicating your problem by requiring it to
> be solved within the flow graph rather than by external control code which
> can reconfigure the flow graph appropriately, but I don't have enough
> information about what your app is doing to be certain.)
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Resampler with changing rate during runtime

[Sebastian Müller]

Hi Marcus,

thanks for the answer! Though to be honest I'm not really happy with that
solution. This simple "FM demod" thing is getting real complicated here. We
would need 4 blocks just for demodulating FM in your proposed scenario:

(msg->[some resamp rate calc block]->[frac resampler]->[WBFM
receive]->[Audio Sink]).

My mentors and me had a hangout today and decided to create an instance of
the fractional resampler block within the Extractor block of my toolbox. My
block will then emulate the scheduler. This way, when extracting a signal
out of the combined messages of the Separator, one can set a fixed sample
rate for each processing chain (which is really nice I think). Also, it can
become handy to generally have the possibility of a fixed sample rate in
the toolbox standard blocks.

Anyway thanks for your ideas!

Cheers,
Sebastian

2016-08-03 19:44 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>:

> Ok, so the point is that you want to make run-time changes to an existing
> block.
> The classical solution I'd go for is to put the block (here: resampler)
> into a hier block, and add something that receives, translates messages, or
> tags.
>
> On the other hand, really, the fractional_resampler_ff *should* have a
> message handler that changes the resampling ratio. The fact that there's a
> method that can just change the ratio while general_work() might be doing
> its job in a different thread is a multithreading disaster happening right
> before our eyes. So, if I might be as brazen: please make sure no-one
> already did this on next, and then just add a message port handler that
> sets the resampling ration (and one for the $\mu$, if possible), using the
> "canonical" pmt_dict format (i.e. {"resampling_ratio": pmt_double} or so).
>
> Since you're writing an OOT that you probably want people to use even if
> they're not using bleeding-edge GR, I'd personally say: copy the
> resampler block you need from gr-filter to gr-inspector, modify it to your
> needs and upstream your changes, and also add a remark to your Readme that
> starting with GR version 3.X.Y, you don't need that block anymore; more
> responsible upstream developers than I am might have a different view,
> however.
>
> Cheers,
> Marcus
>
>
> On 08/03/2016 05:29 PM, Sebastian Müller wrote:
>
> Hi list,
>
> I have stumbled upon a problem and I'm not sure what's the best way to
> deal with it.
>
> My target is to have a FM demodulator for my gr-inspector toolbox. For
> this, I generally would use a WBFM receive -> Audio sink chain. Now, the
> quadrature rate and audio decimation are unknown before runtime, but
> calculated by my other blocks while running. For this purpose, I would like
> to implement a block, that resamples any given signal to a fixed output
> sample rate (in this example a bit more than the audio rate). I have
> messages available that contain the sample rate of my input signal as well
> as the input signal itself.
>
> My first thought was to use an existing resample block, but I'm not sure
> how to include it into my own block. Inheriting from the public header
> yields a compiling error since the methods are not implemented (they are in
> the ***_impl.h class, which is not public). Is there another way to "remote
> control" other blocks within my block? Or generally a better solution for
> my problem?
>
> Thanks for all answers
> Cheers
> Sebastian
>
>
> ___
> 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

[Discuss-gnuradio] Resampler with changing rate during runtime

[Sebastian Müller]

Hi list,

I have stumbled upon a problem and I'm not sure what's the best way to deal
with it.

My target is to have a FM demodulator for my gr-inspector toolbox. For
this, I generally would use a WBFM receive -> Audio sink chain. Now, the
quadrature rate and audio decimation are unknown before runtime, but
calculated by my other blocks while running. For this purpose, I would like
to implement a block, that resamples any given signal to a fixed output
sample rate (in this example a bit more than the audio rate). I have
messages available that contain the sample rate of my input signal as well
as the input signal itself.

My first thought was to use an existing resample block, but I'm not sure
how to include it into my own block. Inheriting from the public header
yields a compiling error since the methods are not implemented (they are in
the ***_impl.h class, which is not public). Is there another way to "remote
control" other blocks within my block? Or generally a better solution for
my problem?

Thanks for all answers
Cheers
Sebastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi all,

week 10 of GSoC is over and I managed to implement an OFDM sync block:
https://grinspector.wordpress.com/2016/07/29/week-10-sync/

Since I make good time, I will try to add a FM demod block to the toolbox.
Target is to have one example workflow from Ether to demod data (= sound).

Cheers,
Sebastian

2016-07-22 16:11 GMT+02:00 Sebastian Müller <gse...@gmail.com>:

> Hi list,
>
> in week 9 of my GSoC I finally managed to implement a working OFDM
> parameter estimation block. Read here about it:
> https://grinspector.wordpress.com/2016/07/22/week-9-ofdm-finale/
>
> Next up is a frequency and timing synchronization block.
>
> Cheers
> Sebastian
>
> 2016-07-18 9:57 GMT+02:00 Sebastian Müller <gse...@gmail.com>:
>
>> Hi Martin,
>>
>> I have no problem with keeping the 'old' algo in the toolbox. But still
>> I'm not sure if it is usable in real-world scenarios with sampling offsets.
>> Maybe someone can improve it if interested.
>>
>> Cheers, Sebastian
>>
>> 2016-07-15 19:22 GMT+02:00 Martin Braun <martin.br...@ettus.com>:
>>
>>> To clarify, if Koslowski's algorithm (since you already coined the
>>> term...) is *as* good as your original one, but also faster, you should
>>> not have duplicates. But if you did all the work to create software that
>>> actually outperforms the fast algorithm in some other aspect, there's no
>>> harm in keeping it around.
>>>
>>> Cheers,
>>> M
>>>
>>> On 07/15/2016 10:20 AM, Martin Braun wrote:
>>> > Sebastian,
>>> >
>>> > thanks for sharing, and your awesome work! I would suggest if you have
>>> > an algorithm with great detection characteristics, you should keep it.
>>> > If you want another suboptimal but fast one, create a second block (or
>>> > whatever it is). The first algorithm did cost you time, and its
>>> superior
>>> > detection performance might be interesting to other people.
>>> >
>>> > Cheers,
>>> > Martin
>>> >
>>> > On 07/15/2016 08:10 AM, Sebastian Müller wrote:
>>> >> Hi list,
>>> >>
>>> >> week 8 of GSoC is over and the latest news on gr-inspector are online:
>>> >>
>>> https://grinspector.wordpress.com/2016/07/15/week-8-performance-issues/
>>> >>
>>> >> This week was a bit disappointing because the algorithm for the OFDM
>>> >> estimation, which did show nice estimation results, and which I dealt
>>> >> with 2 weeks now, had to be replaced because of performance issues.
>>> Now
>>> >> I'll try a more straight-forward algorithm and hope to get started
>>> with
>>> >> synchronization in two weeks.
>>> >>
>>> >> Cheers,
>>> >> Sebastian
>>> >>
>>> >> Sebastian Müller <gse...@gmail.com <mailto:gse...@gmail.com>>
>>> schrieb am
>>> >> Fr., 8. Juli 2016 um 13:48 Uhr:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> week 7 of GSoC is over and I have written a blog post about what
>>> >> I've been up to:
>>> >>
>>> https://grinspector.wordpress.com/2016/07/08/week-7-ofdm-prototype/
>>> >>
>>> >> I started implementing an OFDM parameter estimation block in
>>> python.
>>> >> Also, I did some performance tests, which look quite good. Next, I
>>> >> will implement this algorithm in C++. Stay tuned!
>>> >>
>>> >> Cheers,
>>> >> Sebastian
>>> >>
>>> >> Am 01.07.2016 um 15:37 schrieb Sebastian Müller:
>>> >>> Hi all,
>>> >>>
>>> >>> this week's GSoC blog post is ready! Check it out here:
>>> >>> https://grinspector.wordpress.com/2016/07/01/week-6-tweaking/
>>> >>>
>>> >>> I have finished the GUI so far and improved the Signal Separator.
>>> >>> In the next time I will start with an OFDM parameter estimation,
>>> >>> so stay tuned.
>>> >>>
>>> >>> Cheers,
>>> >>> Sebastian
>>> >>>
>>> >>> 2016-06-28 16:34 GMT+02:00 Sebastian Müller <gse...@gmail.com
>>> >>> <mailto:gse...@gmail.com>>:
>>> >>>
>>> >>> Hi Ben,
>>> >&

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi list,

in week 9 of my GSoC I finally managed to implement a working OFDM
parameter estimation block. Read here about it:
https://grinspector.wordpress.com/2016/07/22/week-9-ofdm-finale/

Next up is a frequency and timing synchronization block.

Cheers
Sebastian

2016-07-18 9:57 GMT+02:00 Sebastian Müller <gse...@gmail.com>:

> Hi Martin,
>
> I have no problem with keeping the 'old' algo in the toolbox. But still
> I'm not sure if it is usable in real-world scenarios with sampling offsets.
> Maybe someone can improve it if interested.
>
> Cheers, Sebastian
>
> 2016-07-15 19:22 GMT+02:00 Martin Braun <martin.br...@ettus.com>:
>
>> To clarify, if Koslowski's algorithm (since you already coined the
>> term...) is *as* good as your original one, but also faster, you should
>> not have duplicates. But if you did all the work to create software that
>> actually outperforms the fast algorithm in some other aspect, there's no
>> harm in keeping it around.
>>
>> Cheers,
>> M
>>
>> On 07/15/2016 10:20 AM, Martin Braun wrote:
>> > Sebastian,
>> >
>> > thanks for sharing, and your awesome work! I would suggest if you have
>> > an algorithm with great detection characteristics, you should keep it.
>> > If you want another suboptimal but fast one, create a second block (or
>> > whatever it is). The first algorithm did cost you time, and its superior
>> > detection performance might be interesting to other people.
>> >
>> > Cheers,
>> > Martin
>> >
>> > On 07/15/2016 08:10 AM, Sebastian Müller wrote:
>> >> Hi list,
>> >>
>> >> week 8 of GSoC is over and the latest news on gr-inspector are online:
>> >>
>> https://grinspector.wordpress.com/2016/07/15/week-8-performance-issues/
>> >>
>> >> This week was a bit disappointing because the algorithm for the OFDM
>> >> estimation, which did show nice estimation results, and which I dealt
>> >> with 2 weeks now, had to be replaced because of performance issues. Now
>> >> I'll try a more straight-forward algorithm and hope to get started with
>> >> synchronization in two weeks.
>> >>
>> >> Cheers,
>> >> Sebastian
>> >>
>> >> Sebastian Müller <gse...@gmail.com <mailto:gse...@gmail.com>> schrieb
>> am
>> >> Fr., 8. Juli 2016 um 13:48 Uhr:
>> >>
>> >> Hi all,
>> >>
>> >> week 7 of GSoC is over and I have written a blog post about what
>> >> I've been up to:
>> >>
>> https://grinspector.wordpress.com/2016/07/08/week-7-ofdm-prototype/
>> >>
>> >> I started implementing an OFDM parameter estimation block in
>> python.
>> >> Also, I did some performance tests, which look quite good. Next, I
>> >> will implement this algorithm in C++. Stay tuned!
>> >>
>> >> Cheers,
>> >> Sebastian
>> >>
>> >> Am 01.07.2016 um 15:37 schrieb Sebastian Müller:
>> >>> Hi all,
>> >>>
>> >>> this week's GSoC blog post is ready! Check it out here:
>> >>> https://grinspector.wordpress.com/2016/07/01/week-6-tweaking/
>> >>>
>> >>> I have finished the GUI so far and improved the Signal Separator.
>> >>> In the next time I will start with an OFDM parameter estimation,
>> >>> so stay tuned.
>> >>>
>> >>> Cheers,
>> >>> Sebastian
>> >>>
>> >>> 2016-06-28 16:34 GMT+02:00 Sebastian Müller <gse...@gmail.com
>> >>> <mailto:gse...@gmail.com>>:
>> >>>
>> >>> Hi Ben,
>> >>>
>> >>> thanks for your interest. The manual signal selection is like
>> >>> the demod function in gqrx. You can move and resize an overlay
>> >>> that will determine the signal information that gets passed
>> >>> downstream. I have not dealt with AMC for now, but based on my
>> >>> own experience with manual modulation recognition I don't see
>> >>> a problem when not exactly hitting the signal edges. If your
>> >>> concern is too narrow selection, there is an oversampling
>> >>> factor parameter in the Signal Separator block, that will
>> >>> allow filtering wider than actually from the GUI s

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi Martin,

I have no problem with keeping the 'old' algo in the toolbox. But still I'm
not sure if it is usable in real-world scenarios with sampling offsets.
Maybe someone can improve it if interested.

Cheers, Sebastian

2016-07-15 19:22 GMT+02:00 Martin Braun <martin.br...@ettus.com>:

> To clarify, if Koslowski's algorithm (since you already coined the
> term...) is *as* good as your original one, but also faster, you should
> not have duplicates. But if you did all the work to create software that
> actually outperforms the fast algorithm in some other aspect, there's no
> harm in keeping it around.
>
> Cheers,
> M
>
> On 07/15/2016 10:20 AM, Martin Braun wrote:
> > Sebastian,
> >
> > thanks for sharing, and your awesome work! I would suggest if you have
> > an algorithm with great detection characteristics, you should keep it.
> > If you want another suboptimal but fast one, create a second block (or
> > whatever it is). The first algorithm did cost you time, and its superior
> > detection performance might be interesting to other people.
> >
> > Cheers,
> > Martin
> >
> > On 07/15/2016 08:10 AM, Sebastian Müller wrote:
> >> Hi list,
> >>
> >> week 8 of GSoC is over and the latest news on gr-inspector are online:
> >> https://grinspector.wordpress.com/2016/07/15/week-8-performance-issues/
> >>
> >> This week was a bit disappointing because the algorithm for the OFDM
> >> estimation, which did show nice estimation results, and which I dealt
> >> with 2 weeks now, had to be replaced because of performance issues. Now
> >> I'll try a more straight-forward algorithm and hope to get started with
> >> synchronization in two weeks.
> >>
> >> Cheers,
> >> Sebastian
> >>
> >> Sebastian Müller <gse...@gmail.com <mailto:gse...@gmail.com>> schrieb
> am
> >> Fr., 8. Juli 2016 um 13:48 Uhr:
> >>
> >> Hi all,
> >>
> >> week 7 of GSoC is over and I have written a blog post about what
> >> I've been up to:
> >> https://grinspector.wordpress.com/2016/07/08/week-7-ofdm-prototype/
> >>
> >> I started implementing an OFDM parameter estimation block in python.
> >> Also, I did some performance tests, which look quite good. Next, I
> >> will implement this algorithm in C++. Stay tuned!
> >>
> >> Cheers,
> >> Sebastian
> >>
> >> Am 01.07.2016 um 15:37 schrieb Sebastian Müller:
> >>> Hi all,
> >>>
> >>> this week's GSoC blog post is ready! Check it out here:
> >>> https://grinspector.wordpress.com/2016/07/01/week-6-tweaking/
> >>>
> >>> I have finished the GUI so far and improved the Signal Separator.
> >>> In the next time I will start with an OFDM parameter estimation,
> >>> so stay tuned.
> >>>
> >>> Cheers,
> >>> Sebastian
> >>>
> >>> 2016-06-28 16:34 GMT+02:00 Sebastian Müller <gse...@gmail.com
> >>> <mailto:gse...@gmail.com>>:
> >>>
> >>> Hi Ben,
> >>>
> >>> thanks for your interest. The manual signal selection is like
> >>> the demod function in gqrx. You can move and resize an overlay
> >>> that will determine the signal information that gets passed
> >>> downstream. I have not dealt with AMC for now, but based on my
> >>> own experience with manual modulation recognition I don't see
> >>> a problem when not exactly hitting the signal edges. If your
> >>> concern is too narrow selection, there is an oversampling
> >>> factor parameter in the Signal Separator block, that will
> >>> allow filtering wider than actually from the GUI specified, to
> >>> compensate the naturally underestimated bandwidth when using
> >>> energy detection. Also, the GUI now supports zooming so a user
> >>> can work really precise if needed :)
> >>>
> >>> Thanks again for the feedback!
> >>> Cheers,
> >>> Sebastian
> >>>
> >>> 2016-06-27 16:41 GMT+02:00 Ben Hilburn
> >>> <<mailto:bhilb...@gnuradio.org>bhilb...@gnuradio.org
> >>> <mailto:bhilb...@gnuradio.org>>:
> >>>
> >>> Hi Sebastian -
> >>>
> >>

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi list,

week 8 of GSoC is over and the latest news on gr-inspector are online:
https://grinspector.wordpress.com/2016/07/15/week-8-performance-issues/

This week was a bit disappointing because the algorithm for the OFDM
estimation, which did show nice estimation results, and which I dealt with
2 weeks now, had to be replaced because of performance issues. Now I'll try
a more straight-forward algorithm and hope to get started with
synchronization in two weeks.

Cheers,
Sebastian

Sebastian Müller <gse...@gmail.com> schrieb am Fr., 8. Juli 2016 um
13:48 Uhr:

> Hi all,
>
> week 7 of GSoC is over and I have written a blog post about what I've been
> up to:
> https://grinspector.wordpress.com/2016/07/08/week-7-ofdm-prototype/
>
> I started implementing an OFDM parameter estimation block in python. Also,
> I did some performance tests, which look quite good. Next, I will implement
> this algorithm in C++. Stay tuned!
>
> Cheers,
> Sebastian
> Am 01.07.2016 um 15:37 schrieb Sebastian Müller:
>
> Hi all,
>
> this week's GSoC blog post is ready! Check it out here:
> https://grinspector.wordpress.com/2016/07/01/week-6-tweaking/
>
> I have finished the GUI so far and improved the Signal Separator. In the
> next time I will start with an OFDM parameter estimation, so stay tuned.
>
> Cheers,
> Sebastian
>
> 2016-06-28 16:34 GMT+02:00 Sebastian Müller <gse...@gmail.com>:
>
>> Hi Ben,
>>
>> thanks for your interest. The manual signal selection is like the demod
>> function in gqrx. You can move and resize an overlay that will determine
>> the signal information that gets passed downstream. I have not dealt with
>> AMC for now, but based on my own experience with manual
>> modulation recognition I don't see a problem when not exactly hitting the
>> signal edges. If your concern is too narrow selection, there is an
>> oversampling factor parameter in the Signal Separator block, that will
>> allow filtering wider than actually from the GUI specified, to compensate
>> the naturally underestimated bandwidth when using energy detection. Also,
>> the GUI now supports zooming so a user can work really precise if needed :)
>>
>> Thanks again for the feedback!
>> Cheers,
>> Sebastian
>>
>> 2016-06-27 16:41 GMT+02:00 Ben Hilburn < <bhilb...@gnuradio.org>
>> bhilb...@gnuradio.org>:
>>
>>> Hi Sebastian -
>>>
>>> Thanks for the great update!
>>>
>>> I'm curious how the "manual selection with the mouse" will work? For
>>> some of the back-end processing that is going on, like Chris's AMC work,
>>> not selecting all of the bins of the signal seems like it could seriously
>>> impact the success of those functions. If the the FFT is, for example, 1024
>>> bins, it seems like it may be hard for a user to accurately select the bins
>>> that are important. Will there be some sort of "intelligent auto-aim", for
>>> lack of a better word, for this?
>>>
>>> Thanks for the great work so far! The GUI screenshots are looking great,
>>> by the way.
>>>
>>> Cheers,
>>> Ben
>>>
>>> On Sun, Jun 26, 2016 at 1:10 PM, Sebastian Müller <gse...@gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> it’s GSoC midterms time! For that purpose, I wrote a new blog post with
>>>> what I’ve been up to and with a review of what I’ve done so far:
>>>> <https://grinspector.wordpress.com/2016/06/26/week-5-midterms/>
>>>> https://grinspector.wordpress.com/2016/06/26/week-5-midterms/
>>>>
>>>> I have managed to accomplish all of my midterm milestones and am
>>>> looking forward for the next 8 weeks of GSoC.
>>>>
>>>> Cheers
>>>> Sebastian
>>>>
>>>>
>>>> Am 18. Juni 2016 um 15:06:11, Sebastian Müller ( <gse...@gmail.com>
>>>> gse...@gmail.com) schrieb:
>>>>
>>>> Hi all,
>>>>
>>>> my GSoC update came a bit later this week, because I was abroad. The
>>>> GUI came to life this week, read here about it:
>>>> <https://grinspector.wordpress.com/2016/06/18/week-4-gui/>
>>>> https://grinspector.wordpress.com/2016/06/18/week-4-gui/
>>>>
>>>> Cheers,
>>>> Sebastian
>>>>
>>>> Am 10. Juni 2016 um 15:14:24, Sebastian Müller ( <gse...@gmail.com>
>>>> gse...@gmail.com) schrieb:
>>>>
>>>> Hi all,
>>>>
>>>> like every week I want to give a shor

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi all,

week 7 of GSoC is over and I have written a blog post about what I've
been up to:
https://grinspector.wordpress.com/2016/07/08/week-7-ofdm-prototype/

I started implementing an OFDM parameter estimation block in python.
Also, I did some performance tests, which look quite good. Next, I will
implement this algorithm in C++. Stay tuned!

Cheers,
Sebastian

Am 01.07.2016 um 15:37 schrieb Sebastian Müller:
> Hi all,
>
> this week's GSoC blog post is ready! Check it out here:
> https://grinspector.wordpress.com/2016/07/01/week-6-tweaking/
>
> I have finished the GUI so far and improved the Signal Separator. In
> the next time I will start with an OFDM parameter estimation, so stay
> tuned.
>
> Cheers,
> Sebastian
>
> 2016-06-28 16:34 GMT+02:00 Sebastian Müller <gse...@gmail.com
> <mailto:gse...@gmail.com>>:
>
> Hi Ben,
>
> thanks for your interest. The manual signal selection is like the
> demod function in gqrx. You can move and resize an overlay that
> will determine the signal information that gets passed downstream.
> I have not dealt with AMC for now, but based on my own experience
> with manual modulation recognition I don't see a problem when not
> exactly hitting the signal edges. If your concern is too narrow
> selection, there is an oversampling factor parameter in the Signal
> Separator block, that will allow filtering wider than actually
> from the GUI specified, to compensate the naturally underestimated
> bandwidth when using energy detection. Also, the GUI now supports
> zooming so a user can work really precise if needed :)
>
> Thanks again for the feedback!
> Cheers,
> Sebastian
>
> 2016-06-27 16:41 GMT+02:00 Ben Hilburn <bhilb...@gnuradio.org
> <mailto:bhilb...@gnuradio.org>>:
>
> Hi Sebastian -
>
> Thanks for the great update!
>
> I'm curious how the "manual selection with the mouse" will
> work? For some of the back-end processing that is going on,
> like Chris's AMC work, not selecting all of the bins of the
> signal seems like it could seriously impact the success of
> those functions. If the the FFT is, for example, 1024 bins, it
> seems like it may be hard for a user to accurately select the
> bins that are important. Will there be some sort of
> "intelligent auto-aim", for lack of a better word, for this?
>
> Thanks for the great work so far! The GUI screenshots are
> looking great, by the way.
>
> Cheers,
> Ben
>
> On Sun, Jun 26, 2016 at 1:10 PM, Sebastian Müller
> <gse...@gmail.com <mailto:gse...@gmail.com>> wrote:
>
> Hi all,
>
> it’s GSoC midterms time! For that purpose, I wrote a new
> blog post with what I’ve been up to and with a review of
> what I’ve done so far:
> https://grinspector.wordpress.com/2016/06/26/week-5-midterms/
>
>     I have managed to accomplish all of my midterm milestones
> and am looking forward for the next 8 weeks of GSoC.
>
> Cheers
> Sebastian
>  
>
> Am 18. Juni 2016 um 15:06:11, Sebastian Müller
> (gse...@gmail.com <mailto:gse...@gmail.com>) schrieb:
>
>> Hi all,
>>
>>     my GSoC update came a bit later this week, because I was
>> abroad. The GUI came to life this week, read here about it:
>> https://grinspector.wordpress.com/2016/06/18/week-4-gui/
>>
>> Cheers,
>> Sebastian
>>
>> Am 10. Juni 2016 um 15:14:24, Sebastian Müller
>> (gse...@gmail.com <mailto:gse...@gmail.com>) schrieb:
>>
>>> Hi all,
>>>
>>> like every week I want to give a short update about my
>>> GSoC project. For details, check the blog post at
>>> 
>>> https://grinspector.wordpress.com/2016/06/10/week-3-separation-issues/
>>>
>>> Most of the week was used to debug the Signal Separator
>>> block, which did not pass my QA test. In consultation
>>> with my mentors I changed the structure under the hood
>>> and now the behavior is exactly like expected (same as
>>> Xlating FIR filter). Also I improved the Signal Detector
>>> with callbacks and an averaging function and started
>>> with the GUI.
>>>
>>> Cheers,
>

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi all,

this week's GSoC blog post is ready! Check it out here:
https://grinspector.wordpress.com/2016/07/01/week-6-tweaking/

I have finished the GUI so far and improved the Signal Separator. In the
next time I will start with an OFDM parameter estimation, so stay tuned.

Cheers,
Sebastian

2016-06-28 16:34 GMT+02:00 Sebastian Müller <gse...@gmail.com>:

> Hi Ben,
>
> thanks for your interest. The manual signal selection is like the demod
> function in gqrx. You can move and resize an overlay that will determine
> the signal information that gets passed downstream. I have not dealt with
> AMC for now, but based on my own experience with manual
> modulation recognition I don't see a problem when not exactly hitting the
> signal edges. If your concern is too narrow selection, there is an
> oversampling factor parameter in the Signal Separator block, that will
> allow filtering wider than actually from the GUI specified, to compensate
> the naturally underestimated bandwidth when using energy detection. Also,
> the GUI now supports zooming so a user can work really precise if needed :)
>
> Thanks again for the feedback!
> Cheers,
> Sebastian
>
> 2016-06-27 16:41 GMT+02:00 Ben Hilburn <bhilb...@gnuradio.org>:
>
>> Hi Sebastian -
>>
>> Thanks for the great update!
>>
>> I'm curious how the "manual selection with the mouse" will work? For some
>> of the back-end processing that is going on, like Chris's AMC work, not
>> selecting all of the bins of the signal seems like it could seriously
>> impact the success of those functions. If the the FFT is, for example, 1024
>> bins, it seems like it may be hard for a user to accurately select the bins
>> that are important. Will there be some sort of "intelligent auto-aim", for
>> lack of a better word, for this?
>>
>> Thanks for the great work so far! The GUI screenshots are looking great,
>> by the way.
>>
>> Cheers,
>> Ben
>>
>> On Sun, Jun 26, 2016 at 1:10 PM, Sebastian Müller <gse...@gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> it’s GSoC midterms time! For that purpose, I wrote a new blog post with
>>> what I’ve been up to and with a review of what I’ve done so far:
>>> https://grinspector.wordpress.com/2016/06/26/week-5-midterms/
>>>
>>> I have managed to accomplish all of my midterm milestones and am looking
>>> forward for the next 8 weeks of GSoC.
>>>
>>> Cheers
>>> Sebastian
>>>
>>>
>>> Am 18. Juni 2016 um 15:06:11, Sebastian Müller (gse...@gmail.com)
>>> schrieb:
>>>
>>> Hi all,
>>>
>>> my GSoC update came a bit later this week, because I was abroad. The GUI
>>> came to life this week, read here about it:
>>> https://grinspector.wordpress.com/2016/06/18/week-4-gui/
>>>
>>> Cheers,
>>> Sebastian
>>>
>>> Am 10. Juni 2016 um 15:14:24, Sebastian Müller (gse...@gmail.com)
>>> schrieb:
>>>
>>> Hi all,
>>>
>>> like every week I want to give a short update about my GSoC project. For
>>> details, check the blog post at
>>> https://grinspector.wordpress.com/2016/06/10/week-3-separation-issues/
>>>
>>> Most of the week was used to debug the Signal Separator block, which did
>>> not pass my QA test. In consultation with my mentors I changed the
>>> structure under the hood and now the behavior is exactly like expected
>>> (same as Xlating FIR filter). Also I improved the Signal Detector with
>>> callbacks and an averaging function and started with the GUI.
>>>
>>> Cheers,
>>> Sebastian
>>>
>>> 2016-06-03 18:49 GMT+02:00 Sebastian Müller <gse...@gmail.com>:
>>>
>>>> Hi All,
>>>>
>>>> the second GSoC week is over and I have updated my blog with the latest
>>>> news:
>>>> https://grinspector.wordpress.com/2016/06/03/week-2-compiling/
>>>>
>>>> Mainly I did C++ implementation of the Signal Detector and Signal
>>>> Separator blocks and started with the Signal Extractor block. Next week I
>>>> plan to improve these blocks and start with the GUI.
>>>>
>>>> Cheers,
>>>> Sebastian
>>>>
>>>> Am 28. Mai 2016 um 14:55:45, Sebastian Müller (gse...@gmail.com)
>>>> schrieb:
>>>>
>>>> Hi Jan,
>>>>
>>>> thanks for the feedback!
>>>> PFBs are a topic I discussed with my mentors and we decided to not use
>>>> them b

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi Ben,

thanks for your interest. The manual signal selection is like the demod
function in gqrx. You can move and resize an overlay that will determine
the signal information that gets passed downstream. I have not dealt with
AMC for now, but based on my own experience with manual
modulation recognition I don't see a problem when not exactly hitting the
signal edges. If your concern is too narrow selection, there is an
oversampling factor parameter in the Signal Separator block, that will
allow filtering wider than actually from the GUI specified, to compensate
the naturally underestimated bandwidth when using energy detection. Also,
the GUI now supports zooming so a user can work really precise if needed :)

Thanks again for the feedback!
Cheers,
Sebastian

2016-06-27 16:41 GMT+02:00 Ben Hilburn <bhilb...@gnuradio.org>:

> Hi Sebastian -
>
> Thanks for the great update!
>
> I'm curious how the "manual selection with the mouse" will work? For some
> of the back-end processing that is going on, like Chris's AMC work, not
> selecting all of the bins of the signal seems like it could seriously
> impact the success of those functions. If the the FFT is, for example, 1024
> bins, it seems like it may be hard for a user to accurately select the bins
> that are important. Will there be some sort of "intelligent auto-aim", for
> lack of a better word, for this?
>
> Thanks for the great work so far! The GUI screenshots are looking great,
> by the way.
>
> Cheers,
> Ben
>
> On Sun, Jun 26, 2016 at 1:10 PM, Sebastian Müller <gse...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> it’s GSoC midterms time! For that purpose, I wrote a new blog post with
>> what I’ve been up to and with a review of what I’ve done so far:
>> https://grinspector.wordpress.com/2016/06/26/week-5-midterms/
>>
>> I have managed to accomplish all of my midterm milestones and am looking
>> forward for the next 8 weeks of GSoC.
>>
>> Cheers
>> Sebastian
>>
>>
>> Am 18. Juni 2016 um 15:06:11, Sebastian Müller (gse...@gmail.com)
>> schrieb:
>>
>> Hi all,
>>
>> my GSoC update came a bit later this week, because I was abroad. The GUI
>> came to life this week, read here about it:
>> https://grinspector.wordpress.com/2016/06/18/week-4-gui/
>>
>> Cheers,
>> Sebastian
>>
>> Am 10. Juni 2016 um 15:14:24, Sebastian Müller (gse...@gmail.com)
>> schrieb:
>>
>> Hi all,
>>
>> like every week I want to give a short update about my GSoC project. For
>> details, check the blog post at
>> https://grinspector.wordpress.com/2016/06/10/week-3-separation-issues/
>>
>> Most of the week was used to debug the Signal Separator block, which did
>> not pass my QA test. In consultation with my mentors I changed the
>> structure under the hood and now the behavior is exactly like expected
>> (same as Xlating FIR filter). Also I improved the Signal Detector with
>> callbacks and an averaging function and started with the GUI.
>>
>> Cheers,
>> Sebastian
>>
>> 2016-06-03 18:49 GMT+02:00 Sebastian Müller <gse...@gmail.com>:
>>
>>> Hi All,
>>>
>>> the second GSoC week is over and I have updated my blog with the latest
>>> news:
>>> https://grinspector.wordpress.com/2016/06/03/week-2-compiling/
>>>
>>> Mainly I did C++ implementation of the Signal Detector and Signal
>>> Separator blocks and started with the Signal Extractor block. Next week I
>>> plan to improve these blocks and start with the GUI.
>>>
>>> Cheers,
>>> Sebastian
>>>
>>> Am 28. Mai 2016 um 14:55:45, Sebastian Müller (gse...@gmail.com)
>>> schrieb:
>>>
>>> Hi Jan,
>>>
>>> thanks for the feedback!
>>> PFBs are a topic I discussed with my mentors and we decided to not use
>>> them because of the following reasons. When using PFBs, there is a
>>> trade-off between band resolution and calculation effort (few filters lead
>>> to low number of possible frequency bands, many filters may have a high cpu
>>> usage). Since the band separation is not dependend on the input siganls, I
>>> think I can have a more efficient solution with „customized“ FIR filters
>>> for each signal. The second reason is the implementation effort that needs
>>> to be done (not only for the PFB but also for recombining the bands again
>>> to reconstruct the signals) is quite higher than for using FIR filters. We
>>> were afraid that time would be too short for implementing this (since all
>>> this should work until the 

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi all,

it’s GSoC midterms time! For that purpose, I wrote a new blog post with
what I’ve been up to and with a review of what I’ve done so far:
https://grinspector.wordpress.com/2016/06/26/week-5-midterms/

I have managed to accomplish all of my midterm milestones and am looking
forward for the next 8 weeks of GSoC.

Cheers
Sebastian


Am 18. Juni 2016 um 15:06:11, Sebastian Müller (gse...@gmail.com) schrieb:

Hi all,

my GSoC update came a bit later this week, because I was abroad. The GUI
came to life this week, read here about it:
https://grinspector.wordpress.com/2016/06/18/week-4-gui/

Cheers,
Sebastian

Am 10. Juni 2016 um 15:14:24, Sebastian Müller (gse...@gmail.com) schrieb:

Hi all,

like every week I want to give a short update about my GSoC project. For
details, check the blog post at
https://grinspector.wordpress.com/2016/06/10/week-3-separation-issues/

Most of the week was used to debug the Signal Separator block, which did
not pass my QA test. In consultation with my mentors I changed the
structure under the hood and now the behavior is exactly like expected
(same as Xlating FIR filter). Also I improved the Signal Detector with
callbacks and an averaging function and started with the GUI.

Cheers,
Sebastian

2016-06-03 18:49 GMT+02:00 Sebastian Müller <gse...@gmail.com>:

> Hi All,
>
> the second GSoC week is over and I have updated my blog with the latest
> news:
> https://grinspector.wordpress.com/2016/06/03/week-2-compiling/
>
> Mainly I did C++ implementation of the Signal Detector and Signal
> Separator blocks and started with the Signal Extractor block. Next week I
> plan to improve these blocks and start with the GUI.
>
> Cheers,
> Sebastian
>
> Am 28. Mai 2016 um 14:55:45, Sebastian Müller (gse...@gmail.com) schrieb:
>
> Hi Jan,
>
> thanks for the feedback!
> PFBs are a topic I discussed with my mentors and we decided to not use
> them because of the following reasons. When using PFBs, there is a
> trade-off between band resolution and calculation effort (few filters lead
> to low number of possible frequency bands, many filters may have a high cpu
> usage). Since the band separation is not dependend on the input siganls, I
> think I can have a more efficient solution with „customized“ FIR filters
> for each signal. The second reason is the implementation effort that needs
> to be done (not only for the PFB but also for recombining the bands again
> to reconstruct the signals) is quite higher than for using FIR filters. We
> were afraid that time would be too short for implementing this (since all
> this should work until the midterms in four weeks).
> We assume to have a moderate number of signals in the input spectrum
> (let’s say less than 5) and I think the FIR filter approach is more
> attractive here. But of course cpu usage is a topic which I have to deal
> with. Therefore I plan to use a lookup-table with precalculated taps for
> different bandwidths and steepnesses. Also, steepness (or something
> similiar) should be a parameter of the block, so the user can can somehow
> control the cpu usage with that.
>
> I hope that answers your question!
>
> Regards,
> Sebastian
>
> Am 28. Mai 2016 um 12:45:49, Jan Krämer (kraemer...@gmail.com) schrieb:
>
> Hey Sebastian,
>
> great work in your first week. Looking pretty good.
> One question though. At the end you propose to seperate the signals with a
> filterbank of xlating FIRs. Is there a use case or a way to do that with a
> polyphase filterbank? Cause multiple FIRs are going to become a major
> burden for the CPU if their number rises, especially if the filterorder
> gets pretty high e.g. for narrowband signals.
>
> Anyway keep up the good work.
> Cheers,
> Jan
>
>
>
> 2016-05-27 14:51 GMT+02:00 Sebastian Müller <gse...@gmail.com>:
>
>> Hi all,
>>
>> there is a new blog post concerning the gr-inspector toolbox:
>> https://grinspector.wordpress.com/2016/05/27/week-1-signal-detection/
>>
>> There I describe what I have done in my first week of GSoC. Mainly I have
>> prototyped a signal detection block and started planning the signal
>> separator block (which is used to pass the detected signals serialized).
>>
>> As always, comments are very welcome :)
>>
>> Cheers,
>> Sebastian
>>
>>
>> ___
>> 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] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi all,

my GSoC update came a bit later this week, because I was abroad. The GUI
came to life this week, read here about it:
https://grinspector.wordpress.com/2016/06/18/week-4-gui/

Cheers,
Sebastian

Am 10. Juni 2016 um 15:14:24, Sebastian Müller (gse...@gmail.com) schrieb:

Hi all,

like every week I want to give a short update about my GSoC project. For
details, check the blog post at
https://grinspector.wordpress.com/2016/06/10/week-3-separation-issues/

Most of the week was used to debug the Signal Separator block, which did
not pass my QA test. In consultation with my mentors I changed the
structure under the hood and now the behavior is exactly like expected
(same as Xlating FIR filter). Also I improved the Signal Detector with
callbacks and an averaging function and started with the GUI.

Cheers,
Sebastian

2016-06-03 18:49 GMT+02:00 Sebastian Müller <gse...@gmail.com>:

> Hi All,
>
> the second GSoC week is over and I have updated my blog with the latest
> news:
> https://grinspector.wordpress.com/2016/06/03/week-2-compiling/
>
> Mainly I did C++ implementation of the Signal Detector and Signal
> Separator blocks and started with the Signal Extractor block. Next week I
> plan to improve these blocks and start with the GUI.
>
> Cheers,
> Sebastian
>
> Am 28. Mai 2016 um 14:55:45, Sebastian Müller (gse...@gmail.com) schrieb:
>
> Hi Jan,
>
> thanks for the feedback!
> PFBs are a topic I discussed with my mentors and we decided to not use
> them because of the following reasons. When using PFBs, there is a
> trade-off between band resolution and calculation effort (few filters lead
> to low number of possible frequency bands, many filters may have a high cpu
> usage). Since the band separation is not dependend on the input siganls, I
> think I can have a more efficient solution with „customized“ FIR filters
> for each signal. The second reason is the implementation effort that needs
> to be done (not only for the PFB but also for recombining the bands again
> to reconstruct the signals) is quite higher than for using FIR filters. We
> were afraid that time would be too short for implementing this (since all
> this should work until the midterms in four weeks).
> We assume to have a moderate number of signals in the input spectrum
> (let’s say less than 5) and I think the FIR filter approach is more
> attractive here. But of course cpu usage is a topic which I have to deal
> with. Therefore I plan to use a lookup-table with precalculated taps for
> different bandwidths and steepnesses. Also, steepness (or something
> similiar) should be a parameter of the block, so the user can can somehow
> control the cpu usage with that.
>
> I hope that answers your question!
>
> Regards,
> Sebastian
>
> Am 28. Mai 2016 um 12:45:49, Jan Krämer (kraemer...@gmail.com) schrieb:
>
> Hey Sebastian,
>
> great work in your first week. Looking pretty good.
> One question though. At the end you propose to seperate the signals with a
> filterbank of xlating FIRs. Is there a use case or a way to do that with a
> polyphase filterbank? Cause multiple FIRs are going to become a major
> burden for the CPU if their number rises, especially if the filterorder
> gets pretty high e.g. for narrowband signals.
>
> Anyway keep up the good work.
> Cheers,
> Jan
>
>
>
> 2016-05-27 14:51 GMT+02:00 Sebastian Müller <gse...@gmail.com>:
>
>> Hi all,
>>
>> there is a new blog post concerning the gr-inspector toolbox:
>> https://grinspector.wordpress.com/2016/05/27/week-1-signal-detection/
>>
>> There I describe what I have done in my first week of GSoC. Mainly I have
>> prototyped a signal detection block and started planning the signal
>> separator block (which is used to pass the detected signals serialized).
>>
>> As always, comments are very welcome :)
>>
>> Cheers,
>> Sebastian
>>
>>
>> ___
>> 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] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi all,

like every week I want to give a short update about my GSoC project. For
details, check the blog post at
https://grinspector.wordpress.com/2016/06/10/week-3-separation-issues/

Most of the week was used to debug the Signal Separator block, which did
not pass my QA test. In consultation with my mentors I changed the
structure under the hood and now the behavior is exactly like expected
(same as Xlating FIR filter). Also I improved the Signal Detector with
callbacks and an averaging function and started with the GUI.

Cheers,
Sebastian

2016-06-03 18:49 GMT+02:00 Sebastian Müller <gse...@gmail.com>:

> Hi All,
>
> the second GSoC week is over and I have updated my blog with the latest
> news:
> https://grinspector.wordpress.com/2016/06/03/week-2-compiling/
>
> Mainly I did C++ implementation of the Signal Detector and Signal
> Separator blocks and started with the Signal Extractor block. Next week I
> plan to improve these blocks and start with the GUI.
>
> Cheers,
> Sebastian
>
> Am 28. Mai 2016 um 14:55:45, Sebastian Müller (gse...@gmail.com) schrieb:
>
> Hi Jan,
>
> thanks for the feedback!
> PFBs are a topic I discussed with my mentors and we decided to not use
> them because of the following reasons. When using PFBs, there is a
> trade-off between band resolution and calculation effort (few filters lead
> to low number of possible frequency bands, many filters may have a high cpu
> usage). Since the band separation is not dependend on the input siganls, I
> think I can have a more efficient solution with „customized“ FIR filters
> for each signal. The second reason is the implementation effort that needs
> to be done (not only for the PFB but also for recombining the bands again
> to reconstruct the signals) is quite higher than for using FIR filters. We
> were afraid that time would be too short for implementing this (since all
> this should work until the midterms in four weeks).
> We assume to have a moderate number of signals in the input spectrum
> (let’s say less than 5) and I think the FIR filter approach is more
> attractive here. But of course cpu usage is a topic which I have to deal
> with. Therefore I plan to use a lookup-table with precalculated taps for
> different bandwidths and steepnesses. Also, steepness (or something
> similiar) should be a parameter of the block, so the user can can somehow
> control the cpu usage with that.
>
> I hope that answers your question!
>
> Regards,
> Sebastian
>
> Am 28. Mai 2016 um 12:45:49, Jan Krämer (kraemer...@gmail.com) schrieb:
>
> Hey Sebastian,
>
> great work in your first week. Looking pretty good.
> One question though. At the end you propose to seperate the signals with a
> filterbank of xlating FIRs. Is there a use case or a way to do that with a
> polyphase filterbank? Cause multiple FIRs are going to become a major
> burden for the CPU if their number rises, especially if the filterorder
> gets pretty high e.g. for narrowband signals.
>
> Anyway keep up the good work.
> Cheers,
> Jan
>
>
>
> 2016-05-27 14:51 GMT+02:00 Sebastian Müller <gse...@gmail.com>:
>
>> Hi all,
>>
>> there is a new blog post concerning the gr-inspector toolbox:
>> https://grinspector.wordpress.com/2016/05/27/week-1-signal-detection/
>>
>> There I describe what I have done in my first week of GSoC. Mainly I have
>> prototyped a signal detection block and started planning the signal
>> separator block (which is used to pass the detected signals serialized).
>>
>> As always, comments are very welcome :)
>>
>> Cheers,
>> Sebastian
>>
>>
>> ___
>> 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] Include own GUI in existing QT windows

[Sebastian Müller]

Hi,

update on this topic: I figured out that passing the parent does not seem
to be the problem. The important lines are in the  tag of the XML
file, which result in the python flowgraph to:

> self.inspector_qtgui_sink_vf_0 = inspector.qtgui_inspector_sink_vf(4096)
> self._inspector_qtgui_sink_vf_0_win =
sip.wrapinstance(self.inspector_qtgui_sink_vf_0.pyqwidget(), Qt.QWidget)
> self.top_layout.addWidget(self._inspector_qtgui_sink_vf_0_win)

I have copied all of the code concerning pyqwidget() from gr-qtwidget (at
least I think so), but the flowgraph still fails with the error:

> self._inspector_qtgui_sink_vf_0_win =
sip.wrapinstance(self.inspector_qtgui_sink_vf_0.pyqwidget(), Qt.QWidget)
> TypeError: must be integer, not SwigPyObject

So it seems as if the PyObject* pyqwidget() is SWIGged, which is not
necessary here. Can anyone tell me how to fix this error?

Cheers,
Sebastian

2016-06-09 14:18 GMT+02:00 Sebastian Müller <gse...@gmail.com>:

> Hi list,
>
> can anyone help me with this? I'm trying to build an own QT GUI, which
> opens in an own window so far. I want to include my GUI in existing QT
> windows (like all the gr-qtgui blocks do) so that there is only one window
> with all the QT content in it.
>
> So far I have configured the  call in the GRC XML like this:
>
> #set $win = 'self._%s_win'%$id
> inspector.qtgui_inspector_sink_vf($fft_len)
> self._$(id)_win = sip.wrapinstance(self.$(id).pyqwidget(), Qt.QWidget)
> $(gui_hint()($win))
>
> qtgui_inspector_sink_vf_impl constructor looks like this:
>
> qtgui_inspector_sink_vf_impl(int fft_len, QWidget *parent);
>
> This block creates an instance of "inspector_plot" which inherits QWidget
> class:
>
> inspector_plot(int fft_len, std::vector *buffer, QWidget* parent) :
> QWidget(parent).
>
> I also created a PyObject* pyqwidget() in the public header and the impl
> header and source files (copied from gr-qtgui). When trying to start, the
> python flowgraph fails because it does not seem to find
> pyqwidget(): AttributeError: 'qtgui_inspector_sink_vf_sptr' object has no
> attribute 'pyqwidget'.
>
> Would be great if someone could help with what I'm missing.
>
> Cheers,
> Sebastian
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Testing PMT blocks

[Sebastian Müller]

Hi Dave,

if you need a block that just passes messages, try the Message Strobe. If
this is not what you want, can you please publish your block code so we can
reproduce the behaivour? From your error message, maybe you have forgotten
to put the "self" parameter in the method declaration? That is always
needed in python as first parameter of class methods.
Also, when you want to test flowgraphs with PMTs, you can't use
"self.tb.run()" but have to use a structure like this:

# connecting and block instancing
self.tb.start()
time.sleep(0.5)
self.tb.stop()
self.tb.wait()
# assertion checks

This lets the flowgraph run for 0.5 secs and stops it again.

Cheers,
Sebastian

2016-06-09 15:47 GMT+02:00 Dave NotTelling :

> I am also noticing that the unit test runs twice.  Is there a particular
> reason for that?  Also, if I call self.assertTrue() on something I know is
> false ('1 == 2' for example) before self.tb.stop() is called, the test just
> hangs.  If I call self.tb.stop() and then call the same assert statement,
> the test exits, but does not report the failure.  I am testing a source
> block that only outputs PMTs and does so forever.  I also tried calling
> myBlock.stop() in hopes that the stop() method would call the destructor
> but that didn't happen.  How does one go about stopping a PMT only test
> bench?
>
> On Tue, Jun 7, 2016 at 6:45 PM, Dave NotTelling 
> wrote:
>
>> I would like to make some unit tests for a PMT only block I created, but
>> I haven't been able to find any good examples aside from a StackOverflow
>> post (
>> http://stackoverflow.com/questions/36342285/testing-a-gnu-radio-message-accepting-block-with-post).
>> The hope was that I could simply access the message port of the block under
>> test and shove PMT messages in there.  Is that even possible?  I tried
>> making a custom block as outlined in
>> https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/python/blocks/qa_python_message_passing.py
>> with the slight tweak of having a method called 'send' in the producer that
>> would send whatever PMT object you provide as an argument out to the output
>> message port.  That fails with:
>>
>> message_gen.send(pmt.intern('asdf'))
>> TypeError: unbound method send() must be called with message_gen instance
>> as first argument (got swig_int_ptr instance instead)
>>
>>
>> Any tips to test a block like this?
>>
>> Thanks!
>>
>
>
> ___
> 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] Include own GUI in existing QT windows

[Sebastian Müller]

Hi list,

can anyone help me with this? I'm trying to build an own QT GUI, which
opens in an own window so far. I want to include my GUI in existing QT
windows (like all the gr-qtgui blocks do) so that there is only one window
with all the QT content in it.

So far I have configured the  call in the GRC XML like this:

#set $win = 'self._%s_win'%$id
inspector.qtgui_inspector_sink_vf($fft_len)
self._$(id)_win = sip.wrapinstance(self.$(id).pyqwidget(), Qt.QWidget)
$(gui_hint()($win))

qtgui_inspector_sink_vf_impl constructor looks like this:

qtgui_inspector_sink_vf_impl(int fft_len, QWidget *parent);

This block creates an instance of "inspector_plot" which inherits QWidget
class:

inspector_plot(int fft_len, std::vector *buffer, QWidget* parent) :
QWidget(parent).

I also created a PyObject* pyqwidget() in the public header and the impl
header and source files (copied from gr-qtgui). When trying to start, the
python flowgraph fails because it does not seem to find
pyqwidget(): AttributeError: 'qtgui_inspector_sink_vf_sptr' object has no
attribute 'pyqwidget'.

Would be great if someone could help with what I'm missing.

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

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi All,

the second GSoC week is over and I have updated my blog with the latest
news:
https://grinspector.wordpress.com/2016/06/03/week-2-compiling/

Mainly I did C++ implementation of the Signal Detector and Signal Separator
blocks and started with the Signal Extractor block. Next week I plan to
improve these blocks and start with the GUI.

Cheers,
Sebastian

Am 28. Mai 2016 um 14:55:45, Sebastian Müller (gse...@gmail.com) schrieb:

Hi Jan,

thanks for the feedback!
PFBs are a topic I discussed with my mentors and we decided to not use them
because of the following reasons. When using PFBs, there is a trade-off
between band resolution and calculation effort (few filters lead to low
number of possible frequency bands, many filters may have a high cpu
usage). Since the band separation is not dependend on the input siganls, I
think I can have a more efficient solution with „customized“ FIR filters
for each signal. The second reason is the implementation effort that needs
to be done (not only for the PFB but also for recombining the bands again
to reconstruct the signals) is quite higher than for using FIR filters. We
were afraid that time would be too short for implementing this (since all
this should work until the midterms in four weeks).
We assume to have a moderate number of signals in the input spectrum (let’s
say less than 5) and I think the FIR filter approach is more attractive
here. But of course cpu usage is a topic which I have to deal with.
Therefore I plan to use a lookup-table with precalculated taps for
different bandwidths and steepnesses. Also, steepness (or something
similiar) should be a parameter of the block, so the user can can somehow
control the cpu usage with that.

I hope that answers your question!

Regards,
Sebastian

Am 28. Mai 2016 um 12:45:49, Jan Krämer (kraemer...@gmail.com) schrieb:

Hey Sebastian,

great work in your first week. Looking pretty good.
One question though. At the end you propose to seperate the signals with a
filterbank of xlating FIRs. Is there a use case or a way to do that with a
polyphase filterbank? Cause multiple FIRs are going to become a major
burden for the CPU if their number rises, especially if the filterorder
gets pretty high e.g. for narrowband signals.

Anyway keep up the good work.
Cheers,
Jan



2016-05-27 14:51 GMT+02:00 Sebastian Müller <gse...@gmail.com>:

> Hi all,
>
> there is a new blog post concerning the gr-inspector toolbox:
> https://grinspector.wordpress.com/2016/05/27/week-1-signal-detection/
>
> There I describe what I have done in my first week of GSoC. Mainly I have
> prototyped a signal detection block and started planning the signal
> separator block (which is used to pass the detected signals serialized).
>
> As always, comments are very welcome :)
>
> Cheers,
> Sebastian
>
>
> ___
> 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] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi Jan,

thanks for the feedback!
PFBs are a topic I discussed with my mentors and we decided to not use them
because of the following reasons. When using PFBs, there is a trade-off
between band resolution and calculation effort (few filters lead to low
number of possible frequency bands, many filters may have a high cpu
usage). Since the band separation is not dependend on the input siganls, I
think I can have a more efficient solution with „customized“ FIR filters
for each signal. The second reason is the implementation effort that needs
to be done (not only for the PFB but also for recombining the bands again
to reconstruct the signals) is quite higher than for using FIR filters. We
were afraid that time would be too short for implementing this (since all
this should work until the midterms in four weeks).
We assume to have a moderate number of signals in the input spectrum (let’s
say less than 5) and I think the FIR filter approach is more attractive
here. But of course cpu usage is a topic which I have to deal with.
Therefore I plan to use a lookup-table with precalculated taps for
different bandwidths and steepnesses. Also, steepness (or something
similiar) should be a parameter of the block, so the user can can somehow
control the cpu usage with that.

I hope that answers your question!

Regards,
Sebastian

Am 28. Mai 2016 um 12:45:49, Jan Krämer (kraemer...@gmail.com) schrieb:

Hey Sebastian,

great work in your first week. Looking pretty good.
One question though. At the end you propose to seperate the signals with a
filterbank of xlating FIRs. Is there a use case or a way to do that with a
polyphase filterbank? Cause multiple FIRs are going to become a major
burden for the CPU if their number rises, especially if the filterorder
gets pretty high e.g. for narrowband signals.

Anyway keep up the good work.
Cheers,
Jan



2016-05-27 14:51 GMT+02:00 Sebastian Müller <gse...@gmail.com>:

> Hi all,
>
> there is a new blog post concerning the gr-inspector toolbox:
> https://grinspector.wordpress.com/2016/05/27/week-1-signal-detection/
>
> There I describe what I have done in my first week of GSoC. Mainly I have
> prototyped a signal detection block and started planning the signal
> separator block (which is used to pass the detected signals serialized).
>
> As always, comments are very welcome :)
>
> Cheers,
> Sebastian
>
>
> ___
> 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] Using Code::Blocks for editing GNU Radio modules

[Sebastian Müller]

Hi Yan,

if you are developing an out-of-tree module, this software is intended to
be used within the GNU Radio runtime, not as standalone. Code::Blocks is
expecting to get an executable after the build process, which is not the
case for OOTs, so maybe that’s because it is pretending the project has not
been built.
What you probably want to do is building it and installing it (cmake .. &&
make -j4 && sudo make install). Then you can access the implemented blocks
from gnuradio-companion or write own python flowgraphs by importing your
module there.

Maybe you follow the OOT tutorial first:
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules

For debugging, you can check
http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsDebugging

Hope that helps
Regards
Sebastian

Am 27. Mai 2016 um 15:52:58, Yan Huang (eexy...@nottingham.ac.uk) schrieb:

Hi all,

I want to use Code::Blocks to editing my GNU Radio modules following this
link:
http://gnuradio.org/redmine/projects/gnuradio/wiki/UsingCB

I have generated a Code::Blocks project with CMake, but after I build the
project, when run it, there is a pop up information:

*It seems that this project has not been built yet.Do you want to build it
now? *I can run hello_world in my Code::Blocks, So maybe its not the
problem about CB. I want to know is:

   - what's the problem about this?
   - How can I add *input_items* in the project  in *CB?*  Can I add a
   input vector from the main function in swig_doc_tag.cpp or
   swig_swig_tag.cpp?

I try this just want to now how to debug my module when I cannot get the
right result. Thanks in advance for any reply.

Kind regards,
Yan



This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

___
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] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi all,

there is a new blog post concerning the gr-inspector toolbox:
https://grinspector.wordpress.com/2016/05/27/week-1-signal-detection/

There I describe what I have done in my first week of GSoC. Mainly I have 
prototyped a signal detection block and started planning the signal separator 
block (which is used to pass the detected signals serialized).

As always, comments are very welcome :)

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

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hi Ben,

thank you for your interest and feedback!

To your first question: The desired behaviour of the signal detector would
be to recognize a multi-carrier system (like OFDM) as one signal, since all
the carriers are needed to transmit the information. If the frequency
resolution is very fine, as you mentioned, the problem occurs that
different subcarriers get interpreted as different signals since low-energy
bins occur between them.
To be honest, a software will not be able to distinguish between two close
incoherent signals and two subcarriers in a multi-carrier system, unless
additional information is provided. One way to do this is to do further
analysis of the signals and determine wether they "belong together", but
I'm afraid this is much more work than I can do during the GSoC program.
Another way would be to set a minimum absolute frequency spacing, under
which the signals get interpreted as one. But I really don't want to
hard-code any values in order to maintain maximum versatility of the
inspector.
So, to come to an actual answer, at this point the user has to find out by
himself for now. For this reason it will be possible to select the signals
manually in the GUI and select what gets mixed down and filtered for the
succeeding signal chain.

Your second question targets the waterfall ability of the toolbox. The idea
is (if time allows) to use a waterfall plot instead of a spectrum plot in
order to be able to analyze signals from the past (imagine the waterfall
plot with red rectangles where signals were detected). This can become
handy if signals are only present for a short time. In this case, an
observation will be characterized by frequency band and start/stop time,
instead of only frequency band as it is for now. If such a burst signal is
detected, it will be filtered by the Signal Separator and will be stored
until it disappears from the waterfall plot, so it will be analyzable for a
much longer time period.
Nevertheless the inspector will of course be able to work on file sources
with manually recorded signals.

I hope I could provide sufficient answers to your questions!

Also, I want to encourage the whole community to give feedback, especially
on the mentioned questions at the end of the blog post:
https://grinspector.wordpress.com/2016/05/20/let-the-coding-begin/

Stay tuned for this week's blog post (likely on friday).

Cheers,
Sebastian

2016-05-25 16:19 GMT+02:00 Ben Hilburn <bhilb...@gnuradio.org>:

> Hi Sebastian -
>
> Thanks so much for the great update! I have two questions:
>
> You mentioned in your blog post that all adjacent bins will be interpreted
> as one signal in your detection block, which then gets passed downstream to
> the analysis portion of your design. Can you comment on how this might be
> affected by multi-carrier systems, especially if the user has selected a
> bin count high enough to push apart the carriers?
>
> You also mentioned the ability to analyze past signals in a waterfall
> plot. In this workflow, would you basically be playing back a recorded file
> and doing off-line analysis?
>
> It looks like things are coming along really nicely. Great mock-ups, by
> the way!
>
> Cheers,
> Ben
>
> On Fri, May 20, 2016 at 6:31 AM, Sebastian Müller <gse...@gmail.com>
> wrote:
>
>> Hey list,
>>
>> there are some news regarding the gr-inspector toolbox, please check out
>> my blog if you’re interested:
>> https://grinspector.wordpress.com/
>>
>> The strategy for the first big task, signal detection, is nearly finished
>> thanks to the great feedback from my mentors. But still, there are some
>> questions remaining on which I would love to get feedback from the
>> community. The explicit questions are at the end of the newest blog post.
>>
>> Beginning with the coding period on monday, weekly updates will be
>> published on the blog along with a short mail on the list. Stay tuned!
>>
>> Cheers,
>> Sebastian
>>
>> ___
>> 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] [GSoC] gr-inspector update / ask for feedback

[Sebastian Müller]

Hey list,

there are some news regarding the gr-inspector toolbox, please check out my 
blog if you’re interested:
https://grinspector.wordpress.com/

The strategy for the first big task, signal detection, is nearly finished 
thanks to the great feedback from my mentors. But still, there are some 
questions remaining on which I would love to get feedback from the community. 
The explicit questions are at the end of the newest blog post.

Beginning with the coding period on monday, weekly updates will be published on 
the blog along with a short mail on the list. Stay tuned!

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

[Discuss-gnuradio] [GSoC] gr-inspector introduction

[Sebastian Müller]

Hello list!

I’m very happy to introduce myself as one of the GSoC students this year 
working for GNU Radio. Thank you for the acceptance and the feedback I received!

My task will be the gr-inspector (former gr-sigint) signal analysis toolbox. 
The project source code will be hosted at [1]. Also, I will provide public 
updates on my work beginning with the coding period on May, 23. The updates 
will be published on the blog [2] along with a short mail on this list. The 
milestones I evaluated with my mentors are also published there.

In the next weeks, I will get my hands on GNU Radio, get familiar with the 
project and work through the documentation. I already did some coding for 
PyBOMBS will try to further contribute to GNU Radio during the bonding period. 
Also, I will do some literature research on the topics I plan to work on during 
the actual coding period.

If you have any feedback or questions, feel free to contact me!

Regards
Sebastian

[1] https://github.com/gnuradio/gr-inspector
[2] https://grinspector.wordpress.com/


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

Re: [Discuss-gnuradio] Pybombs install fetch fail

[Sebastian Müller]

Hi

during PyBOMBS setup you may have added the recipe files with the command
pybombs recipes add gr-recipes git+https://github.com/gnuradio/gr-recipes.git  

The recipes will then be placed at ~/.pybombs/recipes/gr-recipes/. You can 
alter the qt4.lwr there and replace the corrupt URL by a valid one:
https://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.3.tar.gz

Greetings
Sebastian
Am 8. April 2016 bei 19:02:32, Freedomfighter099 . 
(freedomfighter.missing.l...@gmail.com) schrieb:

This may be a easy question for many but I have no idea how to replace a recipe

in which configuration file is possible to change out receipts in this instance 
wget+ftp://ftp.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.6.2.tar.gz.
 to this one  
"wget+http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz;

Thanks


2016-04-08 18:35 GMT+02:00 Kevin Hofschröer :
Actually, I often ran into the same problem myself. When you try to browse this 
link with the browser or through normal command line operation, you will have 
the same effect.
You can replace that recipe line with
"wget+http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz;
and then retry the pybombs install command.

Greetings
Kevin

___
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] RNURadio Installation on Fedora19 (USRP N200)

[Sebastian Müller]

Hi Kumar,

I installed GNU Radio 3.7.9.1 today successfully with the build-gnuradio
script form Marcus Leech on a Fedora 23 machine. Try using the steps
mentioned on
https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource#Using-the-build-gnuradio-script
.

Are there any specific problems that occur during installation? Or are you
just trying to get an overview of the installation methods?

Regards,
Sebastian

*Sebastian Müller*
*Gerwigstr. 15*
*76131 Karlsruhe*

0721 91569088
0176 55197953
gse...@gmail.com

2016-03-31 19:29 GMT+02:00 Kumar Rupesh (Rennes) <
rupesh.ku...@technicolor.com>:

> Hello Marcus,
>
> This is something I received from the GNU support but since I have
> Fedora19. So trying to find out any other way to install.
>
> There are so many different way to install which makes me more confused.
> If you suggest me some something else, right now I am using Leech’s script,
> then I would remain thankful.
>
>
>
> Thanks,
>
> Rupesh
>
>
>
>
>
> *From:* discuss-gnuradio-bounces+rupesh.kumar=technicolor@gnu.org
> [mailto:discuss-gnuradio-bounces+rupesh.kumar=technicolor@gnu.org] *On
> Behalf Of *Marcus Müller
> *Sent:* Thursday, March 31, 2016 7:23 PM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] RNURadio Installation on Fedora19 (USRP
> N200)
>
>
>
> Hi Rupesh,
>
> I'm highly confused: you say you're trying to install GNU Radio on Fedora
> 19, but then describe the process for Ubuntu 14.04.3. What is it?
>
> Best regards,
> Marcus
>
> On 31.03.2016 18:46, Marcus D. Leech wrote:
>
> On 03/31/2016 12:27 PM, Kumar Rupesh (Rennes) wrote:
>
> I want to install GNURadio on Fedora19.  I have USRP N200.
>
> Please let me know how to do this.  I am trying to build a FMCW RADAR
> receiver (USRP N200), please suggest if there is some module which I can
> use.
>
> A.  I have following steps:
>
> 1. Start with a brand-new virgin Ubuntu 14.04.3 (64-bit) installation.
> Make sure that the USRP is disconnected.
>
> 2. Once Ubuntu is installed, run the Software Updater, and download and
> install any updates. You can do this from the command line with:
> sudo apt-get update
>
> 3. Install the necessary dependencies by running:
> sudo apt-get install pv
> sudo apt-get install git
> sudo apt-get install qgit
> sudo apt-get install swig
> sudo apt-get install cmake
> sudo apt-get install cmake-gui
> sudo apt-get install tree
> sudo apt-get install htop
> sudo apt-get install doxygen
> sudo apt-get install graphviz
> sudo apt-get install libtool
> sudo apt-get install libusb-1.0-0
> sudo apt-get install libusb-1.0-0-dev
> sudo apt-get install libudev-dev
> sudo apt-get install libboost-all-dev
> sudo apt-get install libncurses5-dev
> sudo apt-get install libfftw3-bin libfftw3-dev libfftw3-doc
> sudo apt-get install libcppunit-1.13-0 libcppunit-dev libcppunit-doc
> sudo apt-get install ncurses-bin
> sudo apt-get install cpufrequtils
> sudo apt-get install build-essential
> sudo apt-get install python-opengl
> sudo apt-get install python-pyudev
> sudo apt-get install python-docutils
> sudo apt-get install python-cheetah
> sudo apt-get install python-zmq
> sudo apt-get install python-mako
> sudo apt-get install python-numpy
> sudo apt-get install python-numpy-doc
> sudo apt-get install python-numpy-dbg
> sudo apt-get install python-scipy
> sudo apt-get install python-qt4
> sudo apt-get install python-qt4-doc
> sudo apt-get install qt4-doc
> sudo apt-get install python-gtk2 python-gtk2-dbg python-gtk2-dev
> python-gtk2-doc python-gtk2-tutorial
> sudo apt-get install gsl-bin gsl-ref-html gsl-ref-psdoc gsl-doc-info
> gsl-doc-pdf libgsl0-dbg libgsl0-dev libgsl0ldbl
> sudo apt-get install python-wxgtk2.8 python-wxgtk2.8-dbg python-wxtools
> sudo apt-get install python-lxml python-lxml-dbg python-lxml-doc
> sudo apt-get install python-qt4 python-qt4-dbg python-qt4-dev
> python-qt4-doc python-qt4-sql python-qt4-sql-dbg
> sudo apt-get install libqwt5-qt4 libqwt5-qt4-dev libqwt5-doc
> python-qwt5-qt4 python-qwt5-doc python-guiqwt
> sudo apt-get install liblog4c3 liblog4c-doc liblog4c-dev
> liblog4cplus-1.0-4 liblog4cplus-dbg liblog4cplus-dev liblog4cpp5
> liblog4cpp5-dev liblog4cpp-doc
> sudo apt-get install libsdl1.2debian libsdl1.2-dev libsdl1.2-dbg
> libsdl-image1.2 libsdl-image1.2-dbg libsdl-image1.2-dev libsdl-mixer1.2
> libsdl-mixer1.2-dbg libsdl-mixer1.2-dev libsdl-net1.2 libsdl-net1.2-dbg
> libsdl-net1.2-dev libsdl-sound1.2 libsdl-sound1.2-dev
> sudo apt-get install libzmq3 libzmq3-dev libzmqpp3 libzmqpp-dev
>
> 4. Upgrade the kernel to version 3.16 by running:
> sudo apt-get install linux-generic-lts-utopic
>
> 5. Reboot 

Re: [Discuss-gnuradio] gr-radar make problem

[Sebastian Müller]

Hi Mostafa,

have you checked your BOOST version? gr-radar needs 1.60.0 or higher.
Also, see https://github.com/kit-cel/gr-radar/issues/10 for more info.

Regards,
Sebastian
Am 30. März 2016 bei 09:57:22, Mostafa Alizadeh (m.alizade...@gmail.com) 
schrieb:

Hi all, 

I tried to build gr-radar master branch but I got the error:


/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc: In member 
function ‘void gr::radar::usrp_echotimer_cc_impl::receive()’:
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:232:16: 
error: ‘class uhd::rx_streamer’ has no member named ‘issue_stream_cmd’
   d_rx_stream->issue_stream_cmd(stream_cmd);
                ^
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:84: 
error: ‘struct uhd::rx_metadata_t’ has no member named ‘strerror’
    throw std::runtime_error(str(boost::format("Receiver error %s") % 
d_metadata_rx.strerror()));
                                                                                
    ^
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94: 
error: ‘str’ was not declared in this scope
    throw std::runtime_error(str(boost::format("Receiver error %s") % 
d_metadata_rx.strerror()));
                                                                                
              ^
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94: note: 
suggested alternatives:
In file included from /usr/include/boost/format.hpp:53:0,
                 from /usr/local/include/gnuradio/logger.h:55,
                 from /usr/local/include/gnuradio/block.h:29,
                 from /usr/local/include/gnuradio/tagged_stream_block.h:27,
                 from 
/home/mostafa/RADAR/gr-radar-master/include/radar/usrp_echotimer_cc.h:25,
                 from 
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.h:24,
                 from 
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:26:
/usr/include/boost/format/free_funcs.hpp:22:38: note:   ‘boost::str’
     std::basic_string str(const basic_format& f) 
{
                                      ^
/usr/include/boost/format/free_funcs.hpp:22:38: note:   ‘boost::str’
make[2]: *** [lib/CMakeFiles/gnuradio-radar.dir/usrp_echotimer_cc_impl.cc.o] 
Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-radar.dir/all] Error 2
make: *** [all] Error 2


This is due to "boost::str" which is not declared! 

What could I do? 

Best, 
Mostafa 



***
Tehran
IRAN
Tel: +98 (919) 158-7730
Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir
Homepage: Linkedin
***
___  
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] [GSoC16] Signal intelligence proposal

[Sebastian Müller]

Sreeraj, thank you very much for your feedback! I updated my proposal on Github:

https://github.com/sbmueller/gsoc-proposal/blob/master/sigint-proposal.pdf

I have inserted a GUI draft for the frequency allocation information. Also, I 
added more detail
about the synchronization and when it is needed. I added a reference for 
modulation of unknown
signals and tried to make a new approach on the demodulation topic.
Since I won’t be home next week I can’t respond to any mails or update my 
proposal in this time.
But be ensured I will polish my proposal when I have more time in the week 
after, any further 
feedback is still welcome! Then I’m also planing to do some research on 
existing CNN 
possibilities in GR blocks.

Martin, I really like the idea of having two students working in this field. As 
I have pointed out in
my updated proposal, I have many ideas, maybe more than I can implement in 3 
months. It
would be great if another mentor volunteered and gave a second student the 
possibility to 
work on this exciting topic.

Regards,
Sebastian

Am 11. März 2016 bei 12:02:26, sreeraj r (rsree...@gmail.com) schrieb:

Hi Sebastian,

Good proposal. Really liked the radio service database idea too.
It would be nice to have a radio info tab in the GUI, which provide details 
about plausible transmission type based on the frequency allocation of the 
region (e.g [1]).

Some comments on your proposal

Block diagram (fig.2)
- In the block diagram your synchronization block comes before the AMC block. 
Are you referring to some blind synchronization schemes?. If yes can you put 
some references.
- You could also analyze whether sync is necessary for AMC.
- Some useful links [2-3].

Smart demodulation block
- Can you please add some more details about this? May be one or two references.
- For demodulation you need to do a lot more parameter estimation after AMC 
(samp/symbol, shaping filter parameters etc).

Modulation classification block
- It would be nice to add/analyze details on the existing gnuradio blocks for 
cyclo/CNN based classification
- This will help you to plan your timeline accordingly

[1] https://www.ntia.doc.gov/files/ntia/publications/2003-allochrt.pdf
[2] 
http://static1.1.sqspcdn.com/static/f/679473/25385817/1409511797677/rondeau-03-digital_demodulation.pdf?token=VLdlIIZq8xQmopwXjPf2Q5AgzkY%3D
[3] http://link.springer.com/chapter/10.1007%2F978-94-007-0107-6_20

Regards
Sreeraj Rajendran

On Thu, Mar 10, 2016 at 8:18 PM, Sebastian Müller <gse...@gmail.com> wrote:
Hi List!

My name is Sebastian Müller and I am highly interested in participating in this 
years GSoC program.

I want to take GSoC as the opportunity to begin with my participation in the 
GNU Radio project. Several of the ideas mentioned in the ideas list catched my 
attention, especially the topic on signal intelligence seems to be interesting 
for me, because I have some experience in this field. Also, improving the 
filter design tool would be a nice task for me.

I have taken some time the last few days to prepare my proposal for gr-sigint 
and evaluate approaches on this topic. Please find my proposal draft with more 
detailed information under

https://github.com/sbmueller/gsoc-proposal/blob/master/sigint-proposal.pdf

Feedback on my thoughts are very welcome!

Cheers,
Sebastian

___
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] [GSoC16] Signal intelligence proposal

[Sebastian Müller]

Hi List!

My name is Sebastian Müller and I am highly interested in participating in this 
years GSoC program.

I want to take GSoC as the opportunity to begin with my participation in the 
GNU Radio project. Several of the ideas mentioned in the ideas list catched my 
attention, especially the topic on signal intelligence seems to be interesting 
for me, because I have some experience in this field. Also, improving the 
filter design tool would be a nice task for me.

I have taken some time the last few days to prepare my proposal for gr-sigint 
and evaluate approaches on this topic. Please find my proposal draft with more 
detailed information under

https://github.com/sbmueller/gsoc-proposal/blob/master/sigint-proposal.pdf

Feedback on my thoughts are very welcome!

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