Re: Proposal draft

2024-03-16 Thread Sebastian Koslowski
Hi Ruben,

thanks for the proposal and your interest in the project.

Some quick feedback:
* GRC files no longer use XML. Checkout the examples in the main repo, e.g.
https://github.com/gnuradio/gnuradio/blob/main/gr-channels/examples/demo_ofdm.grc
* There is a feature to auto-generate "not-embedded" flow graphs, which you
could study. Maybe mention how it relates to the proposal,
https://github.com/gnuradio/gnuradio/blob/0ecc1127df9c665e669e6b6711d15741b7e6fec9/grc/core/FlowGraph.py#L435
* Embedded flowgraphs could be instantiated multiple times, possibly even
within another embedded flowgraph. I suggest to add a discussion on how
this would work and look like. (list of graphs, create,copy,unlink blocks
that represent subflowgraphs)

-Sebastian

(von unterwegs gesendet)

On Fri, Mar 15, 2024, 07:08 Ruben Arciba  wrote:

> Sorry, forgot to attach my proposal to the previous email.
>
> On Fri, Mar 15, 2024 at 12:06 AM Ruben Arciba 
> wrote:
>
>> Hello,
>>
>> My name is Ruben, I have created a draft of my proposal for the project
>> "GRC: Build-in Sub flowgraphs". I would appreciate your input on how I can
>> improve my proposal. Hope to hear from you soon.
>>
>> Thank you,
>> Ruben Arciba.
>>
>


Re: GRC: is it possible to show grid

2022-03-07 Thread Sebastian Koslowski
There is no option for that AFAIK.

To implement it, you'll want to start here:
https://github.com/gnuradio/gnuradio/blob/main/grc/gui/DrawingArea.py#L213
The grid size is defined in
https://github.com/gnuradio/gnuradio/blob/main/grc/gui/Constants.py#L50
Best add a color in
https://github.com/gnuradio/gnuradio/blob/main/grc/gui/canvas/colors.py
To make it optional grep for some action like TOGGLE_SNAP_TO_GRID and add
your own in the same manner.

Sebastian

On Mon, Mar 7, 2022 at 6:32 PM Prof. M.B. Patil 
wrote:

>
> Dear All,
>
> Is there a way to display the grid (to which
> blocks get locked) on the canvas? If not, any
> tips on how to implement it?
>
> Thanks.
> M.Patil
>
>
>
>
>


Re: GSoC'21 - View Only Mode

2021-06-19 Thread Sebastian Koslowski
Thanks for you feedback and questions.


> The user might want to disable saving of evaluated params for size,
> security, etc. Would saving be optional?
>

Interesting idea. Shouldn't be too hard to implement - however I'd this
low-priority optional extension of the project.



> Some evaluated expressions could be huge, filter taps for instance, and
> can be readily regenerated. Should some things never be saved? Should some
> expressions be recognized as safe? Do we need to change the way we specify
> some params, e.g., don't use a Python expression in some places?
>

For non-primitive values only the repr used by the GUI will be stored.

We'll not try to be clever just to save a few of bytes. Read-only really
means no eval.

No changes to how flowgraphs are designed will be required.


> Many grc files, new and old, will not contain saved values. What will it
> look like when one of these files is opened?
>

Forward and backwards compatibility will be ensured. Users will be notified
if opening a flowgraph read-only is not possible



> Can expressions that are not evaluated be shown as a hover, the same way
> IDEs show references. Or some other way?
>

I read-only mode all expressions will use a cached value loaded from file.
Both the parameter dialog and optionallly blocks on the canvas can already
show expressions.


Sebastian



> On Fri, Jun 18, 2021 at 10:42 Oscar Ekholm  wrote:
>
>> Hello,
>>
>> A new Friday means a new *GSoC - View Only Mode* blog update! This time
>> it focuses on using the stored parameter values (from last week) instead of
>> evaluating the expressions. Read more about it on my blog:
>>
>> https://oscekh.github.io/
>>
>> Best regards,
>> Oscar Ekholm
>> <https://oscekh.github.io/>
>>
>> On Fri, Jun 11, 2021 at 5:24 PM Oscar Ekholm  wrote:
>>
>>> Hello everyone!
>>> I have now published the first blog post for my GSoC work on the GRC
>>> View-Only Mode. This week I have mainly worked at saving evaluated values
>>> of parameters in the grc-file. You can read about it here:
>>>
>>> https://oscekh.github.io/
>>>
>>> I will be posting an update on the blog each Friday, with a
>>> corresponding announcement on this list.
>>>
>>> Best regards,
>>> Oscar Ekholm
>>>
>>> On Mon, May 24, 2021 at 11:19 AM Oscar Ekholm  wrote:
>>>
>>>> Hello,
>>>>
>>>> I've been accepted to work with GnuRadio for this year's Google Summer
>>>> of Code. I will be working on implementing a GRC View-Only Mode, which is a
>>>> security feature disabling execution of block parameters in untrusted
>>>> flowgraphs.
>>>>
>>>> I will be posting weekly progress updates on my blog:
>>>> https://oscekh.github.io/
>>>>
>>>> If you are interested in reading more about the View-Only mode it is
>>>> described further in my project proposal:
>>>>
>>>> https://docs.google.com/document/d/1dL6PziJSopcY3O7gJ6CXiedTSdbhrHVFhR-UJRTmsng/edit?usp=sharing
>>>>
>>>> Please reach out if you have any questions, advice or thoughts you want
>>>> to share.
>>>>
>>>> Best regards,
>>>> Oscar Ekholm
>>>>
>>>


Re: Embedded Python Block Tutorial Param ID Error

2021-05-08 Thread Sebastian Koslowski
Hi,

that looks like a bug introduced by
https://github.com/gnuradio/gnuradio/pull/4522
We forgot to special-case / adapt epy blocks...

Sebastian

(von unterwegs gesendet)

On Sat, May 8, 2021, 06:23 Solomon Tan  wrote:

> Dear all,
>
> I was following the GNURadio Embedded Python Block Tutorial. After adding
> a
> Python block, I got the following error.
>
> ```
>
> Param - Id(id):
>
> ID "epy_block_0" is blacklisted.
>
> ```
>
> The parameter ID of the Python block is marked in red. Why and how? The
> weirdest thing is that the Python block worked initially at first. I could
> run the
> flowgraph, but after stopping it, I couldnt rerun it again. I was given
> that Param
> ID error. My code was almost equivalent to the template, so it cant be my
> fault
> , right?
> ```
> """
> Embedded Python Blocks:
> """
> import numpy as np
> from gnuradio import gr
>
> class blk(gr.sync_block):
> """Embedded Python Block example - a simple multiply const"""
>
>
> def __init__(self, example_param=1.0):  # only default arguments here
> """arguments to this function show up as parameters in GRC"""
> gr.sync_block.__init__(
> self,
> name='EPB Multiply by Const',   # will show up in GRC
> in_sig=[np.float32],
> out_sig=[np.float32]
> )
> # if an attribute with the same name as a parameter is found,
> # a callback is registered (properties work, too).
> self.example_param = example_param
>
>
> def work(self, input_items, output_items):
> """example: multiply with constant"""
> output_items[0][:] = input_items[0] *2 * self.example_param
> return len(output_items[0])
> ```
>
> I could not find any other mail in the archive about this parameter ID
> error.
>
> Thank you.
> Cheers,
> Sol
>
>


Re: GSoC21: View-Only Mode Proposal Draft

2021-04-02 Thread Sebastian Koslowski
Hi Oscar,

I am happy to hear your interested in doing GSoC with GNU Radio.
Your proposal looks really good already! I will get back to you with some
comments in the next few days

Sebastian

On Thu, Apr 1, 2021 at 3:02 PM Oscar Ekholm  wrote:

> Hello everyone in the GNU Radio community!
>
> I am a master's level computer science student at KTH (Stockholm, Sweden)
> applying for the Google Summer of Code project regarding a View-Only Mode
> in the GRC. Which would disable the automatic execution of expressions for
> untrusted flowgraphs for security purposes.
>
> I would appreciate if you could take a look at my proposal draft and give
> me some feedback.
>
> The draft is available on Google Docs:
>
> https://docs.google.com/document/d/1dL6PziJSopcY3O7gJ6CXiedTSdbhrHVFhR-UJRTmsng/edit#heading=h.fvlcy1uzcesk
>
> Best regards,
> Oscar Ekholm
>


Re: Radar Project - BladeRF2.0

2020-06-24 Thread 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

2020-06-04 Thread 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

2020-06-03 Thread 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

2020-05-31 Thread 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: USRP LO stabilization time ?

2020-04-14 Thread Sebastian Sahlin
Hi,

I believe the following paper may be of interest:
https://pubs.gnuradio.org/index.php/grcon/article/view/2

It is indicated that the B210 needs around 3.3 milliseconds minimum to
settle and it is, as you say, due to the hardware frontend. What is causing
the extra delay I can only guess but perhaps communication overhead is the
culprit.

Regards,
Sebastian




Den tis 14 apr. 2020 kl 13:40 skrev jean-michel.fri...@femto-st.fr <
jean-michel.fri...@femto-st.fr>:

> I am considering frequency sweeping a PlutoSDR and a B210, both fitted with
> AD936x RF frontends.
> As I was writing the application and reading the libuhd documentation, I
> read
> at https://files.ettus.com/manual/page_general.html
> "After tuning, the RF front-end will need time to settle into a usable
> state.
>  Typically, this means that the local oscillators must be given time to
> lock
>  before streaming begins. Lock time is not consistent; it varies depending
> upon
>  the device and requested settings. After tuning and before streaming, the
> user
>  should wait for the lo_locked sensor to become true or sleep for a
> conservative
>  amount of time (perhaps a second)."
> ... and surely enough, I can see that if I wait less than a second after
> programming
> the LO, I get inconsistent results because my LO has not stabilized. That
> is also
> true with the USRP GNU Radio source block.
> Unfortunately I want to sweep a few hundred frequencies (in several 100
> MHz range,
> so no option of playing with the I/Qs while keeping the same LO setting),
> meaning
> that the current measurement takes forever (up to 5 min) only waiting for
> the time to
> settle since data communication delay is at the moment negligible.
>
> 1/ What is the cause of this settling delay ? is it libuhd communication
> (in my
> case over USB with a B210) or the Analog Devices frontend hardware ?
> 2/ is there some "setting rule" that might lower the settling time (e.g.
> programming
> a multiple of some magic frequency that might take less time to settle) ?
> Currently
> I sweep with 1 MHz steps, ie a fraction of the sampling frequency, for
> spectra to overlap,
> but that frequency step was selected randomly and could be any better
> value if that
> could help LO stabilize "quickly".
>
> Thanks, JM
>
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
>
>


Re: Filter Design Tool Enhancements for Marcus Leech

2020-03-26 Thread Sebastian Koslowski
I'll have a look tomorrow. Maybe you'd like to share it here, too.

Sebastian

On Thu, Mar 26, 2020 at 7:11 PM zepeng bu  wrote:

> Hello mentors,
>
> I recently submitted a draft proposal, in it I have tried to include
> detailed explanation of Filter Design Tool Enhancements in GNU Radio.
>
> As I have seen in the ideas section of GSOC GNU Radio, Marcus Leech is the
> potential mentor for the idea Filter Design Tool Enhancements.
>
> I wanted to know if the draft proposal fits the idea.
>
> Could really use some suggestions in the same :) .
>
> Yours sincerely
> buzepeng
>


Re: Draft Proposal: GRC view only mode (Secure)

2020-03-17 Thread Sebastian Koslowski
Hi Arpit

read through your draft. Looks pretty good already. Here are some comments:

- I am not 100% sure there is need for a caching library. Maybe it would
make sense to highlight the benefits (and time-saving aspects). Also note
that Cachier would be a new dependency (which raises the bar for adding it)
- Maybe add something on the how and where of storage of cached values
(inside the GRC-files)
- I would prioritize Goal 3 over Goal 2 as it has great impact on the
usability of Goal 1.

Sebastian

On Sat, Mar 14, 2020 at 11:24 AM Arpit Gupta 
wrote:

> Hello everyone
>
> I am Arpit Gupta, an undergraduate from the Indian Institute of Technology
> Roorkee, India. I wish to contribute to the project idea: *GRC: View Only
> Mode (Secure)*. This link <https://aru31.github.io/gsoc-proposal20.pdf> is
> the draft of my proposal. Kindly review it and give your valuable
> suggestions.
> This is a draft proposal and I will keep making the changes. I gave my
> best to incorporate all the suggestions provided to me during the
> discussion of this project.
> If there's something that I am missing out, please do inform me.
> Thank you
>
> Regards,
> Arpit Gupta
> Indian Institute of Technology, Roorkee
>
>


Re:

2020-03-13 Thread Sebastian Koslowski
Hi Vandit,

glad to hear you want to contribute to GNU Radio and especially to GRC.
Since you haven't explicitly mentioned it, I am assuming that you are
interested in a GSoC participation with GNU Radio.
If this is the case, please check-out our wiki [1], maybe
introduce yourself a little more and get to know the project (we have nice
tutorials).
If you have specific questions regarding the project idea, feel free to
contact me.

Sebastian

[1] https://wiki.gnuradio.org/index.php/GSoC

On Fri, Mar 13, 2020 at 5:51 AM Vandit Khurana 
wrote:

> Hi
>
> I'm Vandit, second year undergraduate from Chitkara University, India. I
> would love to contribute to the project "GRC: Build-in sub flowgraphs".
> Please guide me to work on it. A quick response will be highly appreciated.
>
> Yours sincerely
>
> Vandit
>


Re: GSoC for Filter Design Tool Enhancements

2020-03-12 Thread Sebastian Koslowski
Hi Siddhartha,

thanks for your interest in GNU Radio. I sounds like you have just the
right skill-set to really have fun here.

To answer your questions 1 and 2 I'd like to refer you to our wiki [1].
Check-out the page GSoCStudentInfo. Contact me if you have any further
questions.
For Qt I personally don't have any specific recommendations (it's been a
while since I learned it). But there is tones of stuff on the internet -
even for using it from Python (PyQt5 is what we're using).

Sebastian

[1] https://wiki.gnuradio.org/index.php/GSoC


On Tue, Mar 10, 2020 at 7:51 PM Siddhartha Kapoor <
siddharthakapo...@gmail.com> wrote:

> Hey everyone
> I am Siddharth, a senior undergraduate at National Institute of Technology
> Karnataka, India pursuing Electronics and Communication Engineering. My
> interests areas include Digital Signal Processing, Deep Learning and
> Computer Vision. I have completed courses such as DSP, Advanced DSP (which
> was about filter banks, polyphase decomposition, wavelet transforms, etc.),
> Filter Design which led me to the project Filter Design Tool Enhancements.
> I have experience in Python and C/C++. I am looking to work on this project
> as a part of GSoC, any help would be greatly appreciated. I do have a
> few questions -
>
> 1. Are there any exercises to be completed before the proposal stage?
> 2. Is there any specific format for the proposal?
> 3. I don't know much about Qt, what it is and what it does, any links
> would be helpful.
>
> Regards
> Siddharth Kapoor
> Senior Undergraduate
> Dept. of ECE
> NITK
>


Re: GSOC 2020

2020-02-25 Thread Sebastian Koslowski
Hi Narayanan,

welcome here and thanks for your interest in GNU Radio and gr-radar. To get
started with Python I'd use one the countless resources you find on the
web. After that you would probably want to study the code of gr-radar
itself (the tests usually use Python). For a general introduction to
gr-radar there is also this blog https://grradar.wordpress.com/ and a bunch
of videos on YouTube.

For a GSoC project that you'll be working on full-time for three months,
I'd select some radar algorithm/method that really interests you and that
you are confident you can implement in that time frame. Also, consider,
that it is usually required to have access to suitable RF hardware for the
duration of the summer (maybe at your school).

Sebastian


On Mon, Feb 24, 2020 at 7:12 PM Narayanan Vinod <
narayananvinod2...@gmail.com> wrote:

> Hi , My name is Narayanan and I am a second year ECE student at REC
> ,Chennai , India . I am interested in doing this project named "Extending
> and Updating gr-radar" through GSOC 2020 Program. As per the skills
> required I have basic knowledge in signal processing and radars. Also i am
> familiar with c++,python which i could code better with some guidance . I
> would like to know how to start working for this project .Can there be a
> guidance for me?
>
>
>
>
> Sincerely ,
>
>
> Narayanan Vinod
>


Re: GSoC 2020 Introduction

2020-02-14 Thread Sebastian Koslowski
Hi Akhil,

welcome, good to hear that GNU Radio peaked your interest!

You are absolutely right, C++, Python and Qt are among the most used
technologies inside GNU Radio. And there is always lots to do outside of
the actual DSP and theory thereof.
QtGUI related work is always much appreciated.
Regarding GSoC, Google hasn't announced which organisations have been
accepted yet. So, we're kind of waiting until that happens (see their
timeline [1])  before taking further action.
However, that doesn't mean for you to wait. You head over to GitHub, get
familiar with the code, maybe consider working on some smaller related
issues, get used to the workflow.

Sebastian

[1] https://developers.google.com/open-source/gsoc/timeline

On Fri, Feb 14, 2020 at 7:41 AM Akhil Nair  wrote:

> Hi everyone! I'm Akhil, a second year undergrad in computer engineering at
> AIT Pune, India.I wish to participate in GSoC this year under your
> organization.
>
> I'm afraid I'm completely new to GNU Radio however reading your wiki I
> feel that this community is pretty welcoming and it seems like an
> organization I would enjoy working with this year.
>
> As I mentioned I have no experience with GNU Radio however I'm going
> through the tutorials in the wiki now and am quite willing to learn
> whatever I need to help contribute.
>
> I'm familiar with programming in C++ as well as Python and have worked a
> little on Qt so the Qt5 GUI Integrations idea seems like a good fit for me.
> I'd appreciate it if the mentors could guide me in any way to any
> code/information related to the project. Working on anything related to the
> project or even a partial implementation of the idea would help me grasp
> what is required for the project and what I'm expected to implement.
>
> Last of all, this being a Qt related project I'm assuming there's not much
> theory I should be familiar with, however if there is I'd be glad if you
> could tell me what to learn.
>
> Thanks and Regards,
> Akhil Nair
>


Re: Finding GNU Radio 3.8 Compatible Versions Of OOT Modules

2020-02-06 Thread 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

2020-02-04 Thread 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

2020-01-25 Thread 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


Re: GSOC 2020

2020-01-11 Thread Sebastian Koslowski
Hey Samesh,

Welcome to the GNU Radio community. I am especially happy that your
interested in improving and extending GRC.

>From the project ideas you listed, only the bus ports have been
implemented. The other two have good chances to be list for GSoC 2020. I
personally would prioritize the sub-flowgraphs. Please note though, that
its quite a while until GSoC starts (orgs application hasn't even started
yet).

Currently there is an effort to move a away from the GTK bases GUI to a qt
based one. Maybe you'd like to contribute in porting stuff over.

Sebastian


(von unterwegs gesendet)

On Sat, Jan 11, 2020, 14:21 Samesh Lakhotia 
wrote:

> Hello everyone,
> I am Samesh Lakhotia, a second year Electronics and Communication
> undergraduate from BITS Pilani, India.
>
> I started using GRC and it felt like a great tool. I would like to
> contribute to the GRC project. I looked into some features which could be
> implemented in GRC with the help of the GSOC  2019 ideas list here
> https://wiki.gnuradio.org/index.php/GSoCIdeas.
>
> I saw some ideas which have not yet been completed and I would love to
> work on them on GRC.
> The ideas include "GRC: Bus-Ports reimplementation", "GRC: View-Only Mode
> (Secure)" and GRC: Build-in sub flowgraphs".
>
> I wanted to know the current status of these ideas and would like to start
> contributing to them ASAP. Could you all please tell me if one of these
> ideas has a higher priority than the other so I could start working on the
> appropriate idea.
>
> Thank you,
> Samesh Lakhotia
>


Status of gr-inspector

2019-12-04 Thread 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

2019-09-24 Thread 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

2019-06-29 Thread 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] extract value of signal

2019-06-17 Thread Sebastian Sahlin
Hi Jafar,

You need to be more specific. What type of value are you talking about,
frequency, phase, magnitude..?

Regards

Den mån 17 juni 2019 kl 12:11 skrev jafar jafari :

> hi
> how can i extract value of signal in gnuradio companion and use them in my
> python code
>
> ___
> 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

2019-06-15 Thread 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

2019-06-13 Thread 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

2019-06-13 Thread 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


[Discuss-gnuradio] USRP dsp_freq request using stream tags [Python]

2019-06-07 Thread Sebastian Sahlin
Hi,

I am unsure whether this question fits in this mailing list or the USRP
mailing list but it concerns stream tags so here goes..

I'd like to tune the USRP using a DSP offset without touching the LO
frequency. I'd like to do this using stream tags since it's important that
the re-tune is synchronous with the sample stream. Judging by [1] this
appears to be possible using the following structure:

tag.key = pmt.intern('tx_command')
command = pmt.make_dict()
command = pmt.dict_add(command, pmt.intern('dsp_freq'),
pmt.from_double(the_offset))
tag.value = command
// add tag to stream etc

It turns out that this does nothing unless the LO freq is also supplied:

command = pmt.dict_add(command, pmt.intern('lo_freq'),
pmt.from_double(some_center_freq))

But this causes the (relatively slow) LO to be retuned rendering the speedy
DSP retune worthless.. I've seen hints about setting the tune request
policy but this appears to not be supported by the USRP sink as a tag.. is
it necessary to create a custom USRP sink block to properly use DSP
retuning?


[1] https://www.gnuradio.org/doc/doxygen/page_uhd.html
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] AttributeError: No constructor defined for tagged_stream_block (Python)

2019-05-28 Thread Sebastian Sahlin
Hmm ok, I feel like perhaps I've misunderstood some fundamental mechanic of
GNURadio.. is it within my power to define the exact number of samples that
should be available on the next call to the work function of e.g. a sync
block?

Den tis 28 maj 2019 kl 16:28 skrev Müller, Marcus (CEL) :

> But you're free to do that in any block you desire, so you can write a
> normal sync block and just always consume all input :)
> On Tue, 2019-05-28 at 16:26 +0200, Sebastian Sahlin wrote:
> > Hi,
> >
> > I suppose not - I just figured that using a tagged stream block would be
> useful since then I'd be able to iterate over the entire packet in one work
> function call.
> >
> > Den tis 28 maj 2019 kl 16:22 skrev Müller, Marcus (CEL)  >:
> > > But that block doesn't have to be a Tagged Stream Block itself, right?
> > > On Tue, 2019-05-28 at 16:14 +0200, Sebastian Sahlin wrote:
> > > > Hi Marcus,
> > > >
> > > > Aha, that explains it.. bummer! Perhaps you could advise me on an
> alternative solution to my problem. What I am trying to achieve with the
> tagged stream block is to apply tags at an interval on a packet; the values
> are taken from an array that I want to iterate over. However, since the
> work function has no "memory" I am unsure how to solve iterating over the
> array.
> > > >
> > > > Den tis 28 maj 2019 kl 16:04 skrev Müller, Marcus (CEL) <
> muel...@kit.edu>:
> > > > > Hi Sebastian,
> > > > >
> > > > > I must admit that I don't remember whether the TSB block base was
> > > > > correctly wrapped for Python (darn it, first I write something, and
> > > > > then you find a glaring counterexample); in fact, there's not a
> single
> > > > > test case for that in the main GNU Radio tree, which probably means
> > > > > "no".
> > > > >
> > > > > Best regards,
> > > > > Marcus
> > > > >
> > > > > On Tue, 2019-05-28 at 14:41 +0200, Sebastian Sahlin wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I'm attempting to create a tagged stream block in Python using
> the following constructor:
> > > > > >
> > > > > > class test_tagged_stream(gr.tagged_stream_block):
> > > > > > def __init__(self, test_param):
> > > > > > gr.tagged_stream_block.__init__(self,
> > > > > > name="test_tagged_stream",
> > > > > > in_sig=[numpy.complex64],
> > > > > > out_sig=[numpy.complex64],
> > > > > > length_tag_key="test_tag")
> > > > > >
> > > > > > However Python is throwing "AttributeError: No constructor
> defined" at me. Is there some glaringly obvious error in the above code? I
> am using the input argument list as defined at
> https://www.gnuradio.org/doc/doxygen/classgr_1_1tagged__stream__block.html#a601cd4073e9c3e6317b5ecc5e2e5871b
> > > > > >
> > > > > > 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] AttributeError: No constructor defined for tagged_stream_block (Python)

2019-05-28 Thread Sebastian Sahlin
Hi,

I suppose not - I just figured that using a tagged stream block would be
useful since then I'd be able to iterate over the entire packet in one work
function call.

Den tis 28 maj 2019 kl 16:22 skrev Müller, Marcus (CEL) :

> But that block doesn't have to be a Tagged Stream Block itself, right?
> On Tue, 2019-05-28 at 16:14 +0200, Sebastian Sahlin wrote:
> > Hi Marcus,
> >
> > Aha, that explains it.. bummer! Perhaps you could advise me on an
> alternative solution to my problem. What I am trying to achieve with the
> tagged stream block is to apply tags at an interval on a packet; the values
> are taken from an array that I want to iterate over. However, since the
> work function has no "memory" I am unsure how to solve iterating over the
> array.
> >
> > Den tis 28 maj 2019 kl 16:04 skrev Müller, Marcus (CEL)  >:
> > > Hi Sebastian,
> > >
> > > I must admit that I don't remember whether the TSB block base was
> > > correctly wrapped for Python (darn it, first I write something, and
> > > then you find a glaring counterexample); in fact, there's not a single
> > > test case for that in the main GNU Radio tree, which probably means
> > > "no".
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Tue, 2019-05-28 at 14:41 +0200, Sebastian Sahlin wrote:
> > > > Hi,
> > > >
> > > > I'm attempting to create a tagged stream block in Python using the
> following constructor:
> > > >
> > > > class test_tagged_stream(gr.tagged_stream_block):
> > > > def __init__(self, test_param):
> > > > gr.tagged_stream_block.__init__(self,
> > > > name="test_tagged_stream",
> > > > in_sig=[numpy.complex64],
> > > > out_sig=[numpy.complex64],
> > > > length_tag_key="test_tag")
> > > >
> > > > However Python is throwing "AttributeError: No constructor defined"
> at me. Is there some glaringly obvious error in the above code? I am using
> the input argument list as defined at
> https://www.gnuradio.org/doc/doxygen/classgr_1_1tagged__stream__block.html#a601cd4073e9c3e6317b5ecc5e2e5871b
> > > >
> > > > 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] AttributeError: No constructor defined for tagged_stream_block (Python)

2019-05-28 Thread Sebastian Sahlin
Hi Marcus,

Aha, that explains it.. bummer! Perhaps you could advise me on an
alternative solution to my problem. What I am trying to achieve with the
tagged stream block is to apply tags at an interval on a packet; the values
are taken from an array that I want to iterate over. However, since the
work function has no "memory" I am unsure how to solve iterating over the
array.

Den tis 28 maj 2019 kl 16:04 skrev Müller, Marcus (CEL) :

> Hi Sebastian,
>
> I must admit that I don't remember whether the TSB block base was
> correctly wrapped for Python (darn it, first I write something, and
> then you find a glaring counterexample); in fact, there's not a single
> test case for that in the main GNU Radio tree, which probably means
> "no".
>
> Best regards,
> Marcus
>
> On Tue, 2019-05-28 at 14:41 +0200, Sebastian Sahlin wrote:
> > Hi,
> >
> > I'm attempting to create a tagged stream block in Python using the
> following constructor:
> >
> > class test_tagged_stream(gr.tagged_stream_block):
> > def __init__(self, test_param):
> > gr.tagged_stream_block.__init__(self,
> > name="test_tagged_stream",
> > in_sig=[numpy.complex64],
> > out_sig=[numpy.complex64],
> > length_tag_key="test_tag")
> >
> > However Python is throwing "AttributeError: No constructor defined" at
> me. Is there some glaringly obvious error in the above code? I am using the
> input argument list as defined at
> https://www.gnuradio.org/doc/doxygen/classgr_1_1tagged__stream__block.html#a601cd4073e9c3e6317b5ecc5e2e5871b
> >
> > 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] AttributeError: No constructor defined for tagged_stream_block (Python)

2019-05-28 Thread Sebastian Sahlin
Hi,

I'm attempting to create a tagged stream block in Python using the
following constructor:

class test_tagged_stream(gr.tagged_stream_block):

def __init__(self, test_param):
gr.tagged_stream_block.__init__(self,
name="test_tagged_stream",
in_sig=[numpy.complex64],
out_sig=[numpy.complex64],
length_tag_key="test_tag")

However Python is throwing "AttributeError: No constructor defined" at me.
Is there some glaringly obvious error in the above code? I am using the
input argument list as defined at
https://www.gnuradio.org/doc/doxygen/classgr_1_1tagged__stream__block.html#a601cd4073e9c3e6317b5ecc5e2e5871b

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


Re: [Discuss-gnuradio] Issue with the Message API in Python

2019-05-26 Thread Sebastian Sahlin
Hi again,

Thanks for the info and for being patient Marcus. I suppose as a general
rule you need to be able to interpret C++ documentation if you're going the
Python route in GR?

Regards

Den fre 24 maj 2019 kl 17:50 skrev Müller, Marcus (CEL) :

> Oh, I nearly forgot you asked for documentation:
>
>
>
> https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a7f58745d1374b30a7b866406dc97850f
>
> Best regards,
> Marcus
> On Fri, 2019-05-24 at 15:53 +0200, Sebastian Sahlin wrote:
> > Okay, this appears to work:
> >
> > def start(self):
> > threading.Thread(target=self.send_message('Hello World')).start()
> > return true
> >
> > However I am unsure why the return value is necessary (figured it out
> through an error message). Is there somewhere in the documentation you can
> point me to find more info about this?
> >
> > Regards
> >
> >
> > Den fre 24 maj 2019 kl 14:45 skrev Sebastian Sahlin <
> seb.sah...@gmail.com>:
> > > Hi Marcus,
> > >
> > > Aha! I saw hints of this in the documentation but couldn't fully
> connect the dots.
> > >
> > > Would this be the start() function of top_block, or the block in
> question? How would the syntax look like then?
> > >
> > > Regards
> > >
> > > Den tors 23 maj 2019 kl 18:32 skrev Müller, Marcus (CEL) <
> muel...@kit.edu>:
> > > > Hi Sebastian,
> > > >
> > > > classic one!
> > > >
> > > > You send the messages in the block's constructor in an endless loop.
> > > >
> > > > So, that constructor never finishes.
> > > >
> > > > Thus, the block never can get message-connected. Thus, your messages
> > > > disappear.
> > > >
> > > > You can't publish message in a constructor. Spawn off a thread in the
> > > > `start()` method to do that.
> > > >
> > > > Best regards,
> > > > Marcus
> > > >
> > > > On Thu, 2019-05-23 at 17:42 +0200, Sebastian Sahlin wrote:
> > > > > Hi,
> > > > >
> > > > > For learning purposes I'm trying to replicate the functionality of
> the Message Strobe block in Python, however I'm stumped by what should be a
> very basic function. I'm simply attempting to publish a message every x
> seconds:
> > > > >
> > > > > def __init__(self, period):
> > > > > gr.basic_block.__init__(self,
> > > > > name="msg_strobe",
> > > > > in_sig=None,
> > > > > out_sig=None)
> > > > >
> > > > > self.message_port_register_out(pmt.intern('msg_out'))
> > > > >
> > > > > while(True):
> > > > > self.send_message('Hello World')
> > > > > time.sleep(period)
> > > > >
> > > > > def send_message(self, string):
> > > > > self.message_port_pub(pmt.intern('msg_out'),
> pmt.intern(string))
> > > > >
> > > > > However there is no message published to the Message Debug block.
> > > > >
> > > > > ___
> > > > > 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] Issue with the Message API in Python

2019-05-24 Thread Sebastian Sahlin
Okay, this appears to work:

def start(self):
threading.Thread(target=self.send_message('Hello World')).start()
return true

However I am unsure why the return value is necessary (figured it out
through an error message). Is there somewhere in the documentation you can
point me to find more info about this?

Regards


Den fre 24 maj 2019 kl 14:45 skrev Sebastian Sahlin :

> Hi Marcus,
>
> Aha! I saw hints of this in the documentation but couldn't fully connect
> the dots.
>
> Would this be the start() function of top_block, or the block in question?
> How would the syntax look like then?
>
> Regards
>
> Den tors 23 maj 2019 kl 18:32 skrev Müller, Marcus (CEL)  >:
>
>> Hi Sebastian,
>>
>> classic one!
>>
>> You send the messages in the block's constructor in an endless loop.
>>
>> So, that constructor never finishes.
>>
>> Thus, the block never can get message-connected. Thus, your messages
>> disappear.
>>
>> You can't publish message in a constructor. Spawn off a thread in the
>> `start()` method to do that.
>>
>> Best regards,
>> Marcus
>>
>> On Thu, 2019-05-23 at 17:42 +0200, Sebastian Sahlin wrote:
>> > Hi,
>> >
>> > For learning purposes I'm trying to replicate the functionality of the
>> Message Strobe block in Python, however I'm stumped by what should be a
>> very basic function. I'm simply attempting to publish a message every x
>> seconds:
>> >
>> > def __init__(self, period):
>> > gr.basic_block.__init__(self,
>> > name="msg_strobe",
>> > in_sig=None,
>> > out_sig=None)
>> >
>> > self.message_port_register_out(pmt.intern('msg_out'))
>> >
>> > while(True):
>> > self.send_message('Hello World')
>> > time.sleep(period)
>> >
>> > def send_message(self, string):
>> > self.message_port_pub(pmt.intern('msg_out'), pmt.intern(string))
>> >
>> > However there is no message published to the Message Debug block.
>> >
>> > ___
>> > 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] Issue with the Message API in Python

2019-05-24 Thread Sebastian Sahlin
Hi Marcus,

Aha! I saw hints of this in the documentation but couldn't fully connect
the dots.

Would this be the start() function of top_block, or the block in question?
How would the syntax look like then?

Regards

Den tors 23 maj 2019 kl 18:32 skrev Müller, Marcus (CEL) :

> Hi Sebastian,
>
> classic one!
>
> You send the messages in the block's constructor in an endless loop.
>
> So, that constructor never finishes.
>
> Thus, the block never can get message-connected. Thus, your messages
> disappear.
>
> You can't publish message in a constructor. Spawn off a thread in the
> `start()` method to do that.
>
> Best regards,
> Marcus
>
> On Thu, 2019-05-23 at 17:42 +0200, Sebastian Sahlin wrote:
> > Hi,
> >
> > For learning purposes I'm trying to replicate the functionality of the
> Message Strobe block in Python, however I'm stumped by what should be a
> very basic function. I'm simply attempting to publish a message every x
> seconds:
> >
> > def __init__(self, period):
> > gr.basic_block.__init__(self,
> > name="msg_strobe",
> > in_sig=None,
> > out_sig=None)
> >
> > self.message_port_register_out(pmt.intern('msg_out'))
> >
> > while(True):
> > self.send_message('Hello World')
> > time.sleep(period)
> >
> > def send_message(self, string):
> > self.message_port_pub(pmt.intern('msg_out'), pmt.intern(string))
> >
> > However there is no message published to the Message Debug block.
> >
> > ___
> > 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] Issue with the Message API in Python

2019-05-23 Thread Sebastian Sahlin
Hi,

For learning purposes I'm trying to replicate the functionality of the
Message Strobe block in Python, however I'm stumped by what should be a
very basic function. I'm simply attempting to publish a message every x
seconds:

def __init__(self, period):
gr.basic_block.__init__(self,
name="msg_strobe",
in_sig=None,
out_sig=None)

self.message_port_register_out(pmt.intern('msg_out'))

while(True):
self.send_message('Hello World')
time.sleep(period)

def send_message(self, string):
self.message_port_pub(pmt.intern('msg_out'), pmt.intern(string))

However there is no message published to the Message Debug block.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] GR inspector Velue Error

2019-05-21 Thread 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] gr_modtool error when attempting to create Python tagged_stream block

2019-05-20 Thread Sebastian Sahlin
Hi,

Sorry, the "Answer all" button slipped my mind :)

I've submitted a new issue and indicated that it's for GR 3.7.

Regards

Den fre 17 maj 2019 kl 17:19 skrev Müller, Marcus (CEL) :

> Hi Sebastian,
> in the future, could you please emails to the mailing list instead of
> only to me? Others will be interested, too :)
> Thank you!
>
> Yeah, no, PyBOMBS was an attempt to solve the issue that we basically
> had no recent packaging on any platform. We've luckily been able to
> change that, or rather, good things happened to us. PyBOMBS is still a
> cool tool, if you need to work with a prefix for embedded development.
>
> No, that issue being raised for 3.8 is not sufficient, because there's
> significant difference between the templates for these versions.
>
> Cheers,
> Marcus
>
> On Fri, 2019-05-17 at 17:16 +0200, Sebastian Sahlin wrote:
> > Hi,
> >
> > 1. The issue has already been raised, albeit for 3.8, perhaps that is
> sufficient? https://github.com/gnuradio/gnuradio/issues/2489
> > 2. I was under the impression that using PyBombs was to be preferred in
> order to get the latest stable releases :P
> >
> > By the way: using apt to install GR on Ubuntu 18.04.2 got me 3.7.11, and
> I receive the same error with gr_modtool trying to create a tagged_stream
> block.
> >
> > Regards
> >
> > Den fre 17 maj 2019 kl 16:58 skrev Müller, Marcus (CEL)  >:
> > > Ah, nice, so that's the latest maint-3.7 version (i.e. the latest
> > > released version).
> > >
> > > Two realizations set in:
> > >
> > > 1. Unlike 3.8-tech-preview, where we still expect a bit of breakage,
> > > this is surprising. You should definitely be able to do this. We'll
> > > look into this. If you want, you can set up an issue on Github yourself
> > > (advantage: you get notified when we have a solution), or we do that.
> > > What would you prefer?
> > > 2. If you're not after developing GNU Radio itself, but really only
> > > using it, I'd really recommend using your Linux distro's package
> > > manager (looking at your file paths, that's likely "apt") to install
> > > GNU Radio next time (assuming you've got Ubuntu>18.10 or current
> > > debian). Less hassle than building it from source using PyBOMBS, same
> > > result.
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Fri, 2019-05-17 at 14:44 +, Müller, Marcus (CEL) wrote:
> > > >  Forwarded Message 
> > > > > Hi Marcus,
> > > > >
> > > > > The output from gnuradio-config-info --version is the follwing:
> 3.7.13.5
> > > > >
> > > > > Regards
> > > > >
> > > > >
> > > > > Den fre 17 maj 2019 kl 16:15 skrev Müller, Marcus (CEL) <
> muel...@kit.edu>:
> > > > > > Hi Sebastian,
> > > > > >
> > > > > > I know this sounds a bit silly, but could you actually tell us
> the
> > > > > > version that `gnuradio-config-info --version` reports? We're
> kind of in
> > > > > > the process of getting new versions out, and I'm not quite sure
> what
> > > > > > different people get when they use PyBOMBS.
> > > > > > (also, almost certain you shouldn't have to use PyBOMBS if you
> just
> > > > > > want to install a non-development version of GNU Radio; if you
> just
> > > > > > want to install GNU Radio, use a recent Linux distro or OS X,
> you get a
> > > > > > modern GNU Radio that works through the usual apt,dnf,pac,…
> > > > > > installation method.)
> > > > > >
> > > > > > Thank you,
> > > > > > Marcus
> > > > > > On Fri, 2019-05-17 at 16:00 +0200, Sebastian Sahlin wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I get the following output when trying to create a tagged
> stream block with the modtool using Python as the language:
> https://pastebin.com/D6gKJ2aS
> > > > > > >
> > > > > > > GNURadio and gr_modtool version is the latest as installed
> with pybombs.
> > > > > > >
> > > > > > > Regards,
> > > > > > > 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


[Discuss-gnuradio] gr_modtool error when attempting to create Python tagged_stream block

2019-05-17 Thread Sebastian Sahlin
Hi,

I get the following output when trying to create a tagged stream block with
the modtool using Python as the language: https://pastebin.com/D6gKJ2aS

GNURadio and gr_modtool version is the latest as installed with pybombs.

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


Re: [Discuss-gnuradio] Installation of gr-radar

2019-03-10 Thread 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


[Discuss-gnuradio] OFDM TX original example - output broken

2019-01-31 Thread Sebastian Peters

Hey All!

I'm fighting a problem with the original GNU Radio OFDM TX example from
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/examples/ofdm/tx_ofdm.grc

Nothing is changed, except adding two File Sinks writing the data to two 
text files.
One File Sink is added at the random source and one at the OFDM Receiver 
output (parallel to Tag Debug).


Letting it run for a short while, gives me two output files: send.txt 
and received.txt

Then, I'm comparing the outputs in hex:
hexdump -C send.txt > send.txt.hex
hexdump -C received.txt > received.txt.hex
meld send.txt.hex received.txt.hex

(meld is a nicer diff tool)

Every time I do this, the received file is broken at some point. Six 
lines in hexdump (i.e. 6*16=96 bytes) are missing.
It occurs at random places, sometimes multiple times, and as the pattern 
is repeating but not always broken at the same point, you can see that 
it is not a special magic string that is causing it.

My expectation is an error-free transmission.

Can someone explain this behaviour? Am I missing some basic aspect?
I have noticed, that the packet length is 96bytes.

Sebastian

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


Re: [Discuss-gnuradio] gnuradio on High Sierra

2018-05-17 Thread 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()

2018-05-17 Thread 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

2018-05-13 Thread 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

2018-04-27 Thread 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

2018-04-18 Thread 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

2018-04-16 Thread 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

2018-04-14 Thread 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

2018-04-11 Thread 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

2018-04-10 Thread 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

2018-04-09 Thread 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

2018-04-05 Thread 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

2018-03-22 Thread 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

2018-02-08 Thread 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

2017-10-30 Thread 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

2017-10-21 Thread 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/

Re: [Discuss-gnuradio] Python Block module file location

2017-10-19 Thread Sebastian Koslowski
The source code of these Python blocks is saved inside a GRC file. The file
in tmp is only for editing, changes are pulled back into GRC on write. Once
you close your editor the file should be considered invalid.

Sebastian

On Wed, Oct 18, 2017, 17:15 Jason Matusiak <ja...@gardettoengineering.com>
wrote:

> I have been experimenting with the Python Block (in core>misc) for
> something I was trying to gen up quickly.  I have it working, but it seems
> to like creating random file names for the "block" and storing them in /tmp.
>
> Is there anyway to point to a different file in a different location and
> have the block open *that* in its editor?
> ___
> 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] Integrate Mac in CI

2017-10-17 Thread 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

2017-10-10 Thread 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] Using Correlate Estimation with hardware

2017-09-06 Thread Sebastian

Hi Bob,

i am sorry for answering that late (was on holidays wiht very limited Internet 
access).

Changing frequency solved my problem. But I am not sure why. I use a wbx v3 
daugtherboard (range 68,75 – 2200 MHz ). 
uhd_usrp_probe-file is attached.

Thanks for  your help.

Sebastian
Von: Robert McGwier
Gesendet: Montag, 28. August 2017 17:11
An: Sebastian
Cc: discuss-gnuradio@gnu.org
Betreff: Re: [Discuss-gnuradio] Using Correlate Estimation with hardware

Sebastian

What center frequency did you use?
What RF cards are you using?
Are you using coaxial cable,to connect transmit to receive or are you 
transmitting and receiving through an antenna?

If you are using antennas please describe them. 

Cheers
Bob


Bob


On Aug 26, 2017 12:12 PM, "Sebastian" <sebastian_be...@online.de> wrote:
 
 
Hi all,
 
i run into trouble using the correlate estimation block. 
 
As far as i understand this blocks is used to search for a praeamble which is 
modulated and filtered with match filter.
To achieve this i used modulate vector. I used this block like it`s done in the 
corr_est exapmles provided in  /gnuradio/gr-digital/examples/.
 
Using no UHD but a channel modell everything works fine having clear 
correlation peak. 
Using it with hardware device it doesn`t work anymore, having more peaks 
avaiable.
 
My flowgraph is very simple:
 
Vector_source (using prae+data as vector tagged with tx_sob and tx_eob) -> 
constellation Modulator(default-QPSK-object) -> stream mux with null_source for 
break -> uhd sink(sync = PC_clock)
 
Uhd source (sync = PC_clock) -> low_pass -> corr_est(modulated_vector, 0.9) -> 
Pll-clock-sync -> Costas Loop -> constellation-demodulator -> float_to_char -> 
qt time sink 
 
 
Modulate vector is called with default-qpsk-object as constellation object and 
[1] as filter taps which i think is right.
The praeamble i am using is the one provided in the examples, so it should be 
ok too.
 
I dont have that much experience in this topic so I hope somebody is able to 
help me.
I am looking forward to hearing from you and thank you in advance.
 
 
Sebastian
 
PS : I am not sure where and how to provide the flowgraph itself but i´ll try 
to do it asap.
 
 
 
 

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

grc1@grc1-Precision-M6700:~$ uhd_usrp_probe
[INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_3.11.0.git-181-g8f9f4184] 
[INFO] [B100] USRP-B100 clock control: 10  r_counter: 2
  a_counter: 0
  b_counter: 20
  prescaler: 8
  vco_divider: 5
  chan_divider: 5
  vco_rate: 1600.00MHz
  chan_rate: 320.00MHz
  out_rate: 64.00MHz

  _
 /
|   Device: B-Series Device
| _
|/
|   |   Mboard: B100
|   |   serial: E4R13WBB1
|   |   name: b100
|   |   FW Version: 4.0
|   |   FPGA Version: 11.4
|   |   
|   |   Time sources:  none, external, _external_
|   |   Clock sources: internal, external, auto
|   |   Sensors: ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |   
|   |   |   Freq range: -32.000 to 32.000 MHz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: WBX v3, WBX v3 + Simple GDB (0x0057)
|   |   |   Serial: F38109
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: WBXv3 RX+GDB
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 68.750 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ad9522
|   |   |   |   Gain range pga: 0.0 to 20.0 step 1.0 dB
|   | _
|   |/
|   |   |   TX DSP: 0
|   |   |   
|   |   |   Freq range: -32.000 to 32.000 MHz
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   |   ID: WBX v3 (0x0056)
|   |   |   Serial: F38109
|   |   |   ID: WBX + Simple GDB, WBX v3 + Simple GDB, WBX v4 + Simple GDB, 
WBX-120 + Simple GDB (0x004f)
|   |   |   Serial: 0
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: 0
|   |   |   |   Name: WBXv3 TX+GDB
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 68.750 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.0 step 1.0 

Re: [Discuss-gnuradio] Using Correlate Estimation with hardware

2017-08-28 Thread Sebastian
Hi Marcus,

i attached the flowgraph to this mail. The constellation Modulator places the 
tx_eob tag too early (sps*8/ ld(QPSK.arity()) ), which is fixed by using a 
oot-module, delaying it.

Using BPSK instead of QPSK works fine, so I think the problem is located in the 
way using the correlation estimator, but i am not sure about it.

I am looking forward to hearing from you and thank you in advance.

Sebastian



Von: Sebastian
Gesendet: Montag, 28. August 2017 17:13
An: Marcus Müller
Betreff: AW: [Discuss-gnuradio] Using Correlate Estimation with hardware


Hi Marcus,

i attached the flowgraph to this mail. The constellation Modulator places the 
tx_eob tag too early (sps*8/ ld(QPSK.arity()) ), which is fixed by using a 
oot-module, delaying it.

Using BPSK instead of QPSK works fine, so I think the problem is located in the 
way using the correlation estimator, but i am not sure about it.

I am looking forward to hearing from you and thank you in advance.

Sebastian


Von: Marcus Müller
Gesendet: Samstag, 26. August 2017 18:34
An: discuss-gnuradio@gnu.org
Betreff: Re: [Discuss-gnuradio] Using Correlate Estimation with hardware

Hi Sebastian,
well, it would sound like you've discovered the multipath channel!
I don't really understand what you mean with "Modulate vector is called"; what 
/is/ "Modulate vector"?
You can actually simply attach small files to emails to the list. Such a simple 
GRC file would certainly not upset us :)
Best regards,
Marcus        
On 26.08.2017 18:10, Sebastian wrote:
 
 
Hi all,
 
i run into trouble using the correlate estimation block. 
 
As far as i understand this blocks is used to search for a praeamble which is 
modulated and filtered with match filter.
To achieve this i used modulate vector. I used this block like it`s done in the 
corr_est exapmles provided in  /gnuradio/gr-digital/examples/.
 
Using no UHD but a channel modell everything works fine having clear 
correlation peak. 
Using it with hardware device it doesn`t work anymore, having more peaks 
avaiable.
 
My flowgraph is very simple:
 
Vector_source (using prae+data as vector tagged with tx_sob and tx_eob) -> 
constellation Modulator(default-QPSK-object) -> stream mux with null_source for 
break -> uhd sink(sync = PC_clock)
 
Uhd source (sync = PC_clock) -> low_pass -> corr_est(modulated_vector, 0.9) -> 
Pll-clock-sync -> Costas Loop -> constellation-demodulator -> float_to_char -> 
qt time sink 
 
 
Modulate vector is called with default-qpsk-object as constellation object and 
[1] as filter taps which i think is right.
The praeamble i am using is the one provided in the examples, so it should be 
ok too.
 
I dont have that much experience in this topic so I hope somebody is able to 
help me.
I am looking forward to hearing from you and thank you in advance.
 
 
Sebastian
 
PS : I am not sure where and how to provide the flowgraph itself but i´ll try 
to do it asap.
 
 
 
 


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





mytest.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Using Correlate Estimation with hardware

2017-08-26 Thread Sebastian


Hi all,

i run into trouble using the correlate estimation block. 

As far as i understand this blocks is used to search for a praeamble which is 
modulated and filtered with match filter.
To achieve this i used modulate vector. I used this block like it`s done in the 
corr_est exapmles provided in  /gnuradio/gr-digital/examples/.

Using no UHD but a channel modell everything works fine having clear 
correlation peak. 
Using it with hardware device it doesn`t work anymore, having more peaks 
avaiable.

 My flowgraph is very simple:

Vector_source (using prae+data as vector tagged with tx_sob and tx_eob) -> 
constellation Modulator(default-QPSK-object) -> stream mux with null_source for 
break -> uhd sink(sync = PC_clock)

Uhd source (sync = PC_clock) -> low_pass -> corr_est(modulated_vector, 0.9) -> 
Pll-clock-sync -> Costas Loop -> constellation-demodulator -> float_to_char -> 
qt time sink 


Modulate vector is called with default-qpsk-object as constellation object and 
[1] as filter taps which i think is right.
The praeamble i am using is the one provided in the examples, so it should be 
ok too.

I dont have that much experience in this topic so I hope somebody is able to 
help me.
I am looking forward to hearing from you and thank you in advance.


Sebastian

PS : I am not sure where and how to provide the flowgraph itself but i´ll try 
to do it asap.




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


Re: [Discuss-gnuradio] "corrupted double-linked list" crash (was: (no subject))

2017-07-31 Thread Sebastian


Hi Marcus, 

thanks for your reply and i am sorry for answering late.

I guess there is only one version of runtime-lib on my system. 
I ran „sudo find -name libgnuradio-runtime*.so*“ and got this:

./usr/local/lib/libgnuradio-runtime-3.7.11.1.so
./usr/local/lib/libgnuradio-runtime-3.7.11.1.so.0
./usr/local/lib/libgnuradio-runtime-3.7.11.1.so.0.0.0  
./usr/local/lib/libgnuradio-runtime.so

./home/grc1/gnuradio/build/gnuradio-runtime/lib/ libgnuradio-runtime-3.7.11.1.so
./home/grc1/gnuradio/build/gnuradio-runtime/lib/ 
libgnuradio-runtime-3.7.11.1.so.0
./home/grc1/gnuradio/build/gnuradio-runtime/lib/ 
libgnuradio-runtime-3.7.11.1.so.0.0.0
./home/grc1/gnuradio/build/gnuradio-runtime/lib/ libgnuradio-runtime.so

So i guess it´s ok, isnt it? I edited CmakeCache to make sure that my 
OOT-Module is linked against 
./usr/local/lib/libgnuradio-runtime-3.7.11.1.so.0.0.0, like the other modules 
are.
The error is still there. 

When I seperate the hier_block constellation modulator into its subblocks and 
tested it step by step, I noticed that the error occurs within the arbitrary 
resampler. 
I reduced the number of taps and it works (meaning that no error occurs), but 
now I am unable to use a GUI-block afterwards to check the result.

Python2: malloc.c: sysmalloc: Assertion `(old_top == initial_top(av) && 
old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse 
(old_top) && ((unsigned long) old_end & pagesize – 1)) == 0)`

I hope you can give a hint what to do next because I´ve got no idea what´s 
causing this error.

Sebastian

Von: Marcus Müller
Gesendet: Mittwoch, 26. Juli 2017 21:57
An: discuss-gnuradio@gnu.org; Sebastian
Betreff: "corrupted double-linked list" crash (was: (no subject))

Hi Sebastian,
this is certainly the right place to come and ask :)
So, thank's for the error description. I'm pretty optimistic this isn't your 
code's problem – there's something else amiss. If you go down the backtrace, 
you'll notice that this happens (or at least, seems to happen) inside the 
constructor of a "Throttle" block, in fact, in the constructor of the 
gr::basic_block super-super-super-class of gr::blocks:throttle. This leads me 
to believe that the likeliest explanation, especially since your tests work, is 
that you're building and running your tests in an environment that uses a 
different set of GNU Radio binaries/libraries than your GRC.
So, things to make sure:
Is there only one libgnuradio-runtime*.so on your system?
Best regards,
Marcus

On 25.07.2017 20:00, Sebastian wrote:
 
 
Hi all,
 
I dont know whether this is the right place to ask, so please tell if i am 
wrong.
I am afraid that i am new to gnuradio, so i got a problem writing an OOT-module.
 
I used gr_modtool for the basic structure, wrote my code and did one of these 
unit tests.
My test case worked so i installed it, connecting the blocks the same way like 
I did in that test,
and it failed producing this trace back:
 
*** Error in `/usr/bin/python2': corrupted double-linked list: 
0x0293e300 
***
=== Backtrace: =
 
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7ff42dc2b7e5]
 
/lib/x86_64-linux-gnu/libc.so.6(+0x81f88)[0x7ff42dc35f88]
 
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7ff42dc375d4]
 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_Znwm+0x18)[0x7ff42ac73e78]
 
/usr/local/lib/libgnuradio-runtime-3.7.11.1.so.0.0.0(_ZN2gr11basic_block24message_port_register_inEN5boost13intrusive_ptrIN3pmt8pmt_baseEEE+0x139)[0x7ff417b690a9]
 
/usr/local/lib/libgnuradio-runtime-3.7.11.1.so.0.0.0(_ZN2gr5blockC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5boost10shared_ptrINS_12io_signatureEEESC_+0x3ae)[0x7ff417b7454e]
 
/usr/local/lib/libgnuradio-runtime-3.7.11.1.so.0.0.0(_ZN2gr10sync_blockC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5boost10shared_ptrINS_12io_signatureEEESC_+0x5e)[0x7ff417bc5dbe]
 
/usr/local/lib/libgnuradio-blocks-3.7.11.1.so.0.0.0(+0x1925c9)[0x7ff417fa45c9]
 
/usr/local/lib/libgnuradio-blocks-3.7.11.1.so.0.0.0(_ZN2gr6blocks8throttle4makeEmdb+0x49)[0x7ff417fa4b69]
 
/usr/local/lib/python2.7/dist-packages/gnuradio/blocks/_blocks_swig1.so(+0x125744)[0x7ff41666e744]
 
/usr/bin/python2(PyEval_EvalFrameEx+0x68a)[0x4c468a]
/usr/bin/python2(PyEval_EvalCodeEx+0x255)[0x4c2765]
 
/usr/bin/python2(PyEval_EvalFrameEx+0x6099)[0x4ca099]
/usr/bin/python2(PyEval_EvalCodeEx+0x255)[0x4c2765]
 
/usr/bin/python2[0x4de6fe]
/usr/bin/python2(PyObject_Call+0x43)[0x4b0cb3]
/usr/bin/python2[0x4f492e]
 
/usr/bin/python2(PyObject_Call+0x43)[0x4b0cb3]
/usr/bin/python2[0x4f46a7]
/usr/bin/python2[0x4b670c]
 
/usr/bin/python2(PyObject_Call+0x43)[0x4b0cb3]
/usr/bin/python2(PyEval_EvalFrameEx+0x5faf)[0x4c9faf]
 
/usr/bin/python2(PyEval_EvalCodeEx+0x255)[0x4c2765]
/usr/bin/python2(PyEval_EvalFrameEx+0x6099)[0x4ca099]
 
/usr/bin/python2(PyEval_EvalCodeEx+0x255)[0x4c2765]
/usr/bin/python2(PyEval_EvalCode+0x19)[0x4c2509]
 
/usr/bin/python2[0x4f1def]
/usr/bin

[Discuss-gnuradio] (no subject)

2017-07-25 Thread Sebastian


Hi all,

I dont know whether this is the right place to ask, so please tell if i am 
wrong.
I am afraid that i am new to gnuradio, so i got a problem writing an OOT-module.

I used gr_modtool for the basic structure, wrote my code and did one of these 
unit tests.
My test case worked so i installed it, connecting the blocks the same way like 
I did in that test,
and it failed producing this trace back:

 *** Error in `/usr/bin/python2': corrupted double-linked list: 
0x0293e300 
***
=== Backtrace: =

/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7ff42dc2b7e5]

/lib/x86_64-linux-gnu/libc.so.6(+0x81f88)[0x7ff42dc35f88]

/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7ff42dc375d4]

/usr/lib/x86_64-linux-gnu/libstdc++.so.6(_Znwm+0x18)[0x7ff42ac73e78]

/usr/local/lib/libgnuradio-runtime-3.7.11.1.so.0.0.0(_ZN2gr11basic_block24message_port_register_inEN5boost13intrusive_ptrIN3pmt8pmt_baseEEE+0x139)[0x7ff417b690a9]

/usr/local/lib/libgnuradio-runtime-3.7.11.1.so.0.0.0(_ZN2gr5blockC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5boost10shared_ptrINS_12io_signatureEEESC_+0x3ae)[0x7ff417b7454e]

/usr/local/lib/libgnuradio-runtime-3.7.11.1.so.0.0.0(_ZN2gr10sync_blockC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEN5boost10shared_ptrINS_12io_signatureEEESC_+0x5e)[0x7ff417bc5dbe]

/usr/local/lib/libgnuradio-blocks-3.7.11.1.so.0.0.0(+0x1925c9)[0x7ff417fa45c9]

/usr/local/lib/libgnuradio-blocks-3.7.11.1.so.0.0.0(_ZN2gr6blocks8throttle4makeEmdb+0x49)[0x7ff417fa4b69]

/usr/local/lib/python2.7/dist-packages/gnuradio/blocks/_blocks_swig1.so(+0x125744)[0x7ff41666e744]

/usr/bin/python2(PyEval_EvalFrameEx+0x68a)[0x4c468a]
/usr/bin/python2(PyEval_EvalCodeEx+0x255)[0x4c2765]

/usr/bin/python2(PyEval_EvalFrameEx+0x6099)[0x4ca099]
/usr/bin/python2(PyEval_EvalCodeEx+0x255)[0x4c2765]

/usr/bin/python2[0x4de6fe]
/usr/bin/python2(PyObject_Call+0x43)[0x4b0cb3]
/usr/bin/python2[0x4f492e]

/usr/bin/python2(PyObject_Call+0x43)[0x4b0cb3]
/usr/bin/python2[0x4f46a7]
/usr/bin/python2[0x4b670c]

/usr/bin/python2(PyObject_Call+0x43)[0x4b0cb3]
/usr/bin/python2(PyEval_EvalFrameEx+0x5faf)[0x4c9faf]

/usr/bin/python2(PyEval_EvalCodeEx+0x255)[0x4c2765]
/usr/bin/python2(PyEval_EvalFrameEx+0x6099)[0x4ca099]

/usr/bin/python2(PyEval_EvalCodeEx+0x255)[0x4c2765]
/usr/bin/python2(PyEval_EvalCode+0x19)[0x4c2509]

/usr/bin/python2[0x4f1def]
/usr/bin/python2(PyRun_FileExFlags+0x82)[0x4ec652]
/usr/bin/python2(PyRun_SimpleFileExFlags+0x191)[0x4eae31]

/usr/bin/python2(Py_Main+0x68a)[0x49e14a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ff42dbd4830]

/usr/bin/python2(_start+0x29)[0x49d9d9]

If needed, i can provide a memory map, too.

My question is what does the error in line 5 mean. I dont alloc anything 
neither using a new call, so I think this causes the error.
I declared message ports within the constructor like it`s done in other library 
modules. 

This iussue vanished using a char_to_float connected to a QT GUI Time Sink as 
final step instead of constellation modulator and null sink.

I am looking forward to hearing from you and many thanks for your help. If any 
futher Information needed, i am glad to provide it.

Sebastian

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


Re: [Discuss-gnuradio] libqwt

2017-06-24 Thread 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

2017-06-19 Thread 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] Do embedded python blocks in grc allow for different output than input?

2017-06-05 Thread Sebastian Koslowski
Yes, however double is not in the list (maybe you want float32?).
Anyway, I fixed that a while a ago, but seemed to have forgotten to
upstream it:
https://github.com/skoslowski/gnuradio/commits/epy_block_port_map

Sebastian

On Mon, Jun 5, 2017 at 5:37 AM G Reina <gre...@eng.ucsd.edu> wrote:

> I see that GRC had an "embedded python" block.  I'd like to take a
> np.complex64 input, process it in Python, and return a np.float64. When I
> try to modify the python code to do this I get the error:
>
> Param - Code(_source_code):
>> Can't map dtype('float64') to GRC port type
>>
>>
> Can having a different input and output type only be done with an OOT
> module?
>
> Thanks.
> -Tony
>
> ___
> 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

2017-05-17 Thread 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

2017-04-28 Thread 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] Change mailing list email address

2017-04-24 Thread Sebastian Mueller
try this one:

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Best,
Sebastian


On 24.04.2017 14:37, David Halls wrote:
>
> Hi guys,
>
>  
>
> Sorry for the mundane question but it was so long ago that I signed up
> to the mailing list. How do I go about changing my email address?
>
>  
>
> Cheers!!
>
>
> 
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read,
> copied and used only by the intended recipient. If you are not the
> intended recipient, please destroy this message, delete any copies
> held on your system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
>
>
>
> 
> This email has been scanned for email related threats and delivered
> safely by Mimecast.
> For more information please visit http://www.mimecast.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] [GSoC] GNU Radio Companion Extensions: Output C++ Code

2017-03-31 Thread Koslowski, Sebastian (CEL)
Dear Håkon,

I am very excited to see interest in this topic! A few additional comments:

- Any new templating should be done using Mako. The new YAML format
Martin mentioned roughly looks like this:
"""
id: blocks_add_const_vxx
label: Add Const

parameters:
-   id: type
label: IO Type
dtype: enum
options: [complex, float, int, short]
option_attributes:
const_type: [complex_vector, real_vector, int_vector, int_vector]
fcn: [cc, ff, ii, ss]
hide: part
-   id: const
label: Constant
dtype: ${ type.const_type }
default: '0'
-   id: vlen
label: Vec Length
dtype: int
default: '1'
hide: ${ 'part' if vlen == 1 else 'none' }

inputs:
-   dtype: ${ type }
vlen: ${ vlen }

outputs:
-   dtype: ${ type }
vlen: ${ vlen }

templates:
imports: from gnuradio import blocks
make: blocks.add_const_v${type.fcn}(${const})
callbacks:
- set_k(${const})
"""

C++ specific templates could be added under "cpp_templates" or sth.
The main part of your work would be to implement a Generator subclass.
You maybe want to checkout my latest dev version to use as a starting
point [0]

Another issue is how to deal with parameter values:
Say, I have a variable with "np.pi" as value. Or specify some filter
coeffs using a list [1, 1, 1, 1,...]. Or so some calculation "2 ** 4 + 1".
Those usually end up in the generated code somewhere. For C++ that would
fail...
I suggest, that at least some simple expressions should be transpiled
for the C++ code generation.

The alternative, writing all parameter values in C++ code, would require
a separate eval, validation,  - basically a C++ version of GRC.
I'd rather do everything in Python and get the C++ output as a bonus on
top. This means that all blocks must still be available in Python - even
if they are just in output C++. This way we can load and instantiate
things like filter and constellation objects during design time (before
you hit generate) and do validation with those.

Sebastian

[0]
https://github.com/skoslowski/gnuradio/blob/df1e94831c05e3b8a25e5490f50ebf9e98795182/grc/core/generator/top_block.py



On 03/31/2017 02:07 PM, Håkon Vågsether wrote:
> Hi Marcus,
>
> thank you for your feedback.
>
> Also, would kind of had preferred to read "I've not used GNU Radio
> much before, but I've played around with the LiveDVD (or whatever
> you'd have done)" instead of reading "I've not used GNU Radio
> before(at all)" and seeing you use pretty dated screenshots from
> Josh's website instead of familiarizing yourself quickly, so that
> you could leave us with the certainty that hey, we don't have to
> teach you how to even start GRC ... not that I really think this
> will be any trouble for you, but the ease of getting started with
> GNU Radio, considering ready-made packages and the bootable
> liveDVD and the guided tutorials make me wonder much more why you
> didn't demonstrate you've played with GNU Radio before.
>
> Haha, I understand what you mean, and you're right! I naturally
> wouldn't post my proposal draft for this project without knowing how
> to even start GRC :) I have spent the last few weeks tinkering and
> trying to gain some familiarity with GRC and its source. I could (and
> should) have just taken a screenshot myself! I will include this in my
> next draft.
>
> Big Plus is of course that you mention Cheetah, which proves
> you've actually looked at the source code, I guess! This is
> probably not going to hurt at this stage, but as Ben said, we're
> currently replacing that with Mako (Cheetah is kinda Python2 only,
> and we're making things work with Py3).
>
> So, I hope this is not asking too much from your time right now
> (you might be busy with exams for all I know about studying), but
> I'd recommend you checkout the "next" branch of the gnuradio
> repository, and try to build it with GRC enabled, and maybe add
> some "change  to include " to
> your timeline after getting a rough idea of how code gen works there.
>
> Right! I had already built it from source, but I was on the master
> branch. I've built the next branch now, and I've noticed the addition
> of the GRCC compiler.py in the grc/ directory. I suppose the GSoC
> project might as well include adding the build options as command line
> arguments to this while I'm at it.
>
> I like your block diagram, it clarifies a few things, and
> generally, I prefer reading a concise chart instead of a wall of
> text, and I think that "writing down" the current code generation
> process in terms of who-calls-what in Python in that shape would
> be awesome, because that would allow you 

Re: [Discuss-gnuradio] [GSOC17 - Draft proposal] Implement SigMF functionality for GNU Radio

2017-03-25 Thread 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] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

2017-03-21 Thread Koslowski, Sebastian (CEL)
Hello,

good to see so much feedback to this proposal. This feature is clearly
something that we all want to see become reality!
I have discussed this idea with Kartik beforehand offline and I am glad
to see all of you have the same issues/objections.

While bokeh (and plotly) were mentioned in the proposal only because the
idea was inspired from these libraries, they maybe not the be a natural
fit for us after all - at least on the server side. Maybe, at this
point, it would be useful to specify what we actually want out this and
then look at what Bokeh and others provide us to get there. Even if that
means, that this module will not have all features after 3 months of
coding that we want long term.

My rough idea of this is
- a server that runs an event-loop to push push data to clients and
receives/handles events from them
- a single websocket connection per client which the data (for all
plots) is multiplexed using messages
- each sink block holds a number plot data buffers ("O"s may happen)
that the event loop async pulls from and sends to clients
- metadata is a separate message?

As far as I can tell this is pretty much what Bokeh does, except that we
want a more direct path from our blocks to the websocket stream.  I'm
not sure if the Bokeh server has an lower-level API that we could we.
The other thing I am unsure about is the flow of data, that Marcus
mentioned. Ideally we could have something with the event loop in Python
that allowed us to stream data stored in buffer object (build in at the
C level).

Kartik, I think you should include a more detailed description on how
you plan to control the data flow and maybe, expand on the planned
options of the placement of widgets.

Sebastian

On 03/21/2017 02:09 PM, Marcus Müller wrote:
>
> Hi Kartik,
>
> thanks for the feedback!
>
> so, I took the time and tried to read up a bit on what Bokeh does, how
> it's partitioned. I'd like to describe this here as shortly as
> possible, mostly for my own understanding and to foster more
> discussion with others that can't find the time, and would kindly ask
> you to confirm this is your understanding, too:
>
>   * Bokeh is Python library that produces plots
>   * It's plotting frontend is HTML & Javascript
>   * This enables interactive plotting (ie. you can zoom in, pan etc
> without updating the dataset visualized)
>   * The frontend Javascript is a library (BokehJS) used in a
> "standard" piece of code that you feed two things:
>   o The ID of the HTML  tag to be filled with the graph
>   o The data and plot settings to be visualized as JSON
>   * Bokeh (the python library) comes with a Python-implemented server
> that you're planning to use
>
> Now the things I'm not sure about:
>
>   * said server has a REST API, i.e. is /polled/ from the client only?
> Or can there be pushing data from server -> client? What is the
> model you'd prefer? Your proposal says "stream to the clients",
> but I can't find that in Bokeh (but then again: no experience on
> interactive Web dev on my side at all, so this might be really
> easy for you, if possible).
>   * I've no idea how to talk GR data -> bokeh-server. Maybe you could
> elaborate on how you do that?
>   * the JSON is relatively verbose, and contains basically all
> imaginable settings for a plot. However, I presume a data update
> from the bokeh-server would only consist of the model data, which,
> for a 5-point line graph would consist of (this is pretty-printed,
> Bokeh omits all the whitespace/line breaks):
> {
>"type" : "ColumnDataSource",
>"id" : "ce58de4d-0ef2-43cf-b15a-23d431781c1a",
>"attributes" : {
>   "callback" : null,
>   "column_names" : [
>  "y",
>  "x"
>   ],
>   "data" : {
>  "x" : [
> 1,
> 2,
> 3,
> 4,
> 5
>  ],
>  "y" : [
> 6,
> 7,
> 2,
> 4,
> 5
>  ]
>   }
>}
> },
>   * Hence, if performance of the python server is doubted, or
> integration into GR is complicated, you could also just write a
> C++ 

Re: [Discuss-gnuradio] How to contribute to GNU Radio in 5 mins or less per day!

2017-03-20 Thread Sebastian Mueller
Hey Martin,

I stumbled upon pages that could be deleted in my opinion (for instance
https://wiki.gnuradio.org/index.php/BuildOnCubieBoard_ZH).
I think I don't have the rights to delete pages, so should we agree on a
procedure to mark them for deletion by an user with sufficient rights?
I'm not sure what's the best way here though.

Best,
Sebastian


On 20.03.2017 07:16, Martin Braun wrote:
> On 03/19/2017 10:54 PM, Martin Braun wrote:
>> [...]
>> Now, when browsing pages, these are things to watch out for:
>>
>> - Were HTML entities translated where they shouldn't? E.g., do you see
>> code like this: d_foo-method(), which should read d_foo->method() ?
>> - Does it make sense to rename the page? Redmine used page titles as
>> IDs, whereas MediaWiki actually uses the page title as the page title.
>> - Is syntax highlighting working properly? This page, for example, took
>> a lot of manual labour to fix:
>> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_C++
>> (and everytime I go back, I find more issues...)
>> - Is the content actually accurate?
> Also, is the page in the right category? Pages can be easily categorized
> by adding a special link at the end like this:
>
> [[Category:foo]]
>
> We currently have these categories:
> - Android
> - Embedded
> - Tutorials
> - Guided Tutorials (this one's complete)
> - Installation
>
> -- M
>
>
> ___
> 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

2017-03-16 Thread Sebastian Mueller
Installing headers in your home directory is very uncommon, that's also
why cmake cannot find your installation there.
Can you try to add that path to ./cmake/Modules/FindQwtPlot3D.cmake in
line 8? Same goes for the library path in line 11, that you have to find
out, too.


On 16.03.2017 14:49, Honcho41 wrote:
> Hi again Sebastian,
>
> I followed the guide that Kyeong posted (thank you) and although it didn't
> complete fully I do now have the qwt3d_plot.h file @:
>
> /home/mcgyver/qwtplot3d-0.2.7+svn191/include
>
> Any further help you can give is appreciated.
>
> Paul
>
>
>
> -
> Studying for BEng (Hons) Telecommunications Systems Engineering
> Bournemouth University
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Gr-Inspector-install-errors-tp62687p63125.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 install errors

2017-03-16 Thread Sebastian Mueller
Hi Paul,
this message in *most* cases mean that qwtplot3d is not installed.
Please make sure that these packages are installed:

libqwtplot3d-qt4-0v5
libqwtplot3d-qt4-dev

If this is the case, cmake cannot find your qwtplot3d installation. Can
you please specify where you have installed qwtplot3d (in particular
qwt3d_plot.h)? You can specify the path when running cmake like this:
´cmake -DQT_QWTPLOT3D_INCLUDE_DIR=/your/path/to/qwt3d/headers ..´

Best,
Sebastian
> I am also trying to install gr-inspector on a RPi 3 running Ubuntu MATE
> 16.04.2
>
> I'm sure I've installed all dependancies but when I run cmake I get this:
>
> mcgyver@mcgyver-pi:~/gr-inspector/build$ cmake ..
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.58.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> -- -- Python checking for PyQt4 -- Python checking for PyQt4 - found
> CMake Error at
> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148
> (message): Could NOT find Qt4 (missing: QT_QWTPLOT3D_INCLUDE_DIR
> QT_QWTPLOT3D_LIBRARY) (found suitable version "4.8.7", minimum
> required is "4.2.0") Call Stack (most recent call first):
> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388
> (_FPHSA_FAILURE_MESSAGE)
> /usr/share/cmake-3.5/Modules/FindQt4.cmake:1333
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:152 (find_package)
> -- Configuring incomplete, errors occurred! See also
> "/home/mcgyver/gr-inspector/build/CMakeFiles/CMakeOutput.log". See
> also "/home/mcgyver/gr-inspector/build/CMakeFiles/CMakeError.log". Any
> help is much appreciated Paul



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


Re: [Discuss-gnuradio] Using Eigen C++ template library in GNURADIO

2017-03-09 Thread Sebastian Mueller
Hello Nasi,

can you please explain what you are trying to do? From the little
information that you provide I can say: The type VectorXcf is AFAIK
neither defined in Eigen nor in GNU Radio, so  how should the compiler
know what VectorXcf means? I think you might have forgotten to define
the type *before* the first usage.

Best,
Sebastian

On 08.03.2017 07:18, Nasi wrote:
> Dear members,
>
> does anyone know how to use Eigen C++ template library in GNURADIO?
>
> my OS is Ubuntu 16.04 lts.
> gnuradio version 3.7.10,
>
> I can use it separately as c++ library by adding these lines:
>
> #include 
> #include 
> #include 
>
> ...
> VectorXcf fftshiftXcf(VectorXcf x, int NFFT);
> ...
> //--
>
> however, in gnuradio project, I get the error:
>
> error: ‘VectorXcf’ does not name a type
> VectorXcf fftshiftXcf(VectorXcf x, int NFFT);
>
>
>
> -- 
> NE
>
>
> ___
> 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] Usage of GitHub

2017-02-08 Thread Sebastian Mueller
Hi Svetlana,

I get your concerns, but AFAIK it's currently very unlikely that GNU
Radio will leave GitHub. It is still the place-to-be for open source
code. If you feel uncomfortable using GitHub, we also have the repo
self-hosted at http://gnuradio.org/redmine/projects/gnuradio/repository .

Best,
Sebastian

On 06.02.2017 23:03, Svetlana Tkachenko wrote:
> Please do not use github. It runs non-free JavaScript, hosts non-free
> software discover-able by its users, and encourages poor licensing
> practices. https://www.gnu.org/software/repo-criteria-evaluation.html
> has extra information. I believe a GNU project may not refer users to
> non-free resources in this manner.
>
> I believe as an alternative, a Gogs instance provides functionality
> similar to GitHub and may be self-hosted.
>
> ___
> 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] Module has no 'attribute'---OOT Module

2017-02-03 Thread 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

2017-02-03 Thread 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

2017-01-29 Thread 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

2017-01-28 Thread 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

2017-01-28 Thread 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


Re: [Discuss-gnuradio] GRC - Always Generate Functions Probes Last?

2016-11-29 Thread Koslowski, Sebastian (CEL)
The code for figuring out dependencies (expr_utils.py) is failing here,
I believe. That has been reported before and is on the list to be
rewritten (not very high prio though). In the meantime moving all the
probes to the end sounds like a good workaround (even though I usually
dislike special-casing blocks).

So, yes, a PR would much a appreciated. Thanks

Sebastian


On 11/29/2016 04:10 AM, John Malsbury wrote:
> I often find that  GRC instantiates function_probes/threads before the
> block/object/probe that is being called by the function probe, which
> causes an exception.  It takes some trickery, like copying and
> re-pasting blocks in GRC to change the order in the generated python
> file.
>
> To fix this I've modified:
>
> grc/core/FlowGraph.py
> grc/core/generator/Generator.py
> grc/core/generator/flow_graph.tmpl
>
> so function probes are always declared after all blocks.  
>
> Is there a reason why we haven't done this before?  If not I can
> submit a PR for the simple fix.  
>
> -John
>
>
> ___
> 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] Block position with different screen resolutions

2016-11-03 Thread Koslowski, Sebastian (CEL)
On 11/01/2016 08:35 PM, Mike Thebo wrote:
> Hi Sebastian,
>
> I am not quite sure, what you mean by "running GRC from source". Do you
> mean build it from source? I am using pybombs and I think this is
> cloning the master branch. To test this, I would need the maint branch,
> correct? Or is it already merged into the master branch?
>
> Best regards,
> Mike

There is no need to (re-)install GR for this: You need to get a copy of
the modified source and execute that version of GRC directly:

git clone -b dpi_fix https://github.com/skoslowski/gnuradio
./gnuradio/grc/scripts/gnuradio-companion

Note, that this still requires an installed version of GNU Radio. Since
your using pybombs, you will probably need to activate some prefix (with
gnuradio installed) beforehand.

Sebastian

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


Re: [Discuss-gnuradio] Can't open properties window in GRC after update

2016-10-26 Thread Koslowski, Sebastian (CEL)
Can start GRC from a command line and see if any errors are thrown when
you try open a props dialog?

Sebastian

On 10/25/2016 08:10 PM, MarkO wrote:
> Hi everyone,
>
> I try to make the story as short as possible:
>
> - installed GRC 3.7.10.1 from source via script on Ubuntu 14.04. 
> - decided to update from Ubuntu 14.04 to 16.04.
> - couldn't start GRC anymore 
> - reinstallation via script -> didn't work 
> - completely removed everything of GRC I could find
> - reinstalled GRC 3.7.9 via apt -> OK, worked - used it awhile
>
> Today: 
> - updated to GRC 3.7.10.1 via script -> so far everything in GRC works,
> except opening a properties window of a block. 
> No matter if old or new grc-file or which block I want to edit. tried:
> double click, hit return as one is marked, reboot system, totally remove GRC
> and reinstalled .. nothing worked
>
> Is there any known solution for such case? 
>
> Regards,
> Markus
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Can-t-open-properties-window-in-GRC-after-update-tp61814.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] Block position with different screen resolutions

2016-10-25 Thread Koslowski, Sebastian (CEL)
Sounds like this could help: https://github.com/gnuradio/gnuradio/pull/1064

Sebastian

On 10/24/2016 10:30 PM, Mike Thebo wrote:
> Hi all,
>
> is it somehow possible to preserve the relative block position to each
> other over several screen resolutions?
>
> I attached 2 pictures, which show the problem. I work on a GRC flowgraph
> so I can see everything nice and easy to be able to change values when I
> am out in the field with the notebook.
>
> But when I open the flowgraph on my notebook screen all the blocks are
> squeezed. With larger flowgraphs it is even worse than the picture
> shows. Out in the field, when you looking for a block to change
> something, it is practically unusable. Sometimes they are even on top of
> each other, forming several layers.
>
> Of course, if I know the name, I could probably search for it. But isn't
> there a different solution?
>
> Best regards,
> Mike
>
>
> ___
> 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] Embedded python block in grc will not accept vectors

2016-10-10 Thread Sebastian Koslowski
Hello Edward,

it seems, vlen support in epy_block was missing. Try this version:

https://github.com/skoslowski/gnuradio/tree/epy_vectors

Let me know if you find any issues.

Sebastian

On 10/10/2016 07:49 PM, Edward Miles wrote:
> Hello, my name is Edward and I have a quick question about the embedded
> python block found in the Misc section of the gnuradio-companion(grc).
> When I go into the block's properties and open its code in the editor I
> want to change this line of code:
> 
> gr.sync_block.__init__(
> self,
> name='Embedded Python Block',   # will show up in GRC
> in_sig=[np.complex64],
> out_sig=[np.complex64]
> )
> 
> to this:
> 
> gr.sync_block.__init__(
> self,
> name='Embedded Python Block',   # will show up in GRC
> in_sig=[(np.complex64, 1024)],  # changed to accept a
> vector of size 1024 as its input
> out_sig=[(np.complex64, 1024)] # changed to output a
> vector of size 1024
> )
> 
> This change should allow the block to take in a vector of size 1024 as
> input and also output a vector of size 1024. I've made new modules and
> blocks in python using the gr_modtool and this line of code works fine
> but does not seem to work in the embedded python block in grc. The block
> keeps giving this error:
> 
> Param - Code(_source_code):
> Invalid conversion specification
> 
> I've tried looking into the issue to see if it is just a problem with
> this particular block or if there is a special conversion that needs to
> be done specifically and I can't seem to find anything on it. I could
> just make the block using gr_modtool but it would make life much easier
> if I could implement it with the embedded python block. So my question
> is has anyone else encountered this problem and knows how to get the
> block to accept vectors? Any input would be greatly appreciated. Thank
> you all for your time and consideration.
> 
> 
> ___
> 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 with a fresh pybombs build

2016-10-07 Thread Koslowski, Sebastian (CEL)
Looks like its clashing with you first attempt. Maybe remove that first.
Also, if you do install with --user you need to add $HOME/.local/bin to
your PATH variable.

Sebastian

On 10/07/2016 04:09 PM, Jason Matusiak wrote:
> Running pip install --user pybombs
> returns:
> Collecting pybombs
> Requirement already satisfied: PyYAML in
> /usr/local/lib/python2.7/dist-packages (from pybombs)
> Requirement already satisfied: requests in
> /usr/local/lib/python2.7/dist-packages (from pybombs)
> Requirement already satisfied: six in /usr/lib/python2.7/dist-packages
> (from pybombs)
> Requirement already satisfied: future in
> /usr/local/lib/python2.7/dist-packages (from pybombs)
> Requirement already satisfied: setuptools in
> /usr/local/lib/python2.7/dist-packages (from pybombs)
> Installing collected packages: pybombs
> Successfully installed pybombs
>
> But if I type pybombs on the command line, I get:
> bash: /usr/local/bin/pybombs: No such file or directory
>
> On 10/07/2016 09:39 AM, Koslowski, Sebastian (CEL) wrote:
>> Python usually doesn't look for packages in /usr/local/
>> That can be changed, of course.
>> However, maybe you should consider installing pybombs somewhere else.
>>
>> For example,
>>  pip install --user pybombs
>> or
>>  pip install --user PATH_TO_YOUR_PYBOMBS_CLONE_OR_TARBALL
>> should work nicely.
>>
>> Sebastian
>>
>> On 10/07/2016 03:07 PM, Jason Matusiak wrote:
>>>>> ls -lh /usr/local/bin/pybombs
>>>>> My suspicion is that pip for some reason didn't set the executable
>>> flag
>>>>> on the pybombs program file. If that's the case, you can fix that by
>>>>> sudo chmod a+x /usr/local/bin/pybombs
>>> That was indeed my first issue.  I don't know that I would blame pip
>>> for it just yet (we use a wonky version of sudo here at work).  Once i
>>> made the fix though, I get the following error:
>>> $ pybombs recipes add gr-recipes
>>> git+https://github.com/gnuradio/gr-recipes.git
>>> Traceback (most recent call last):
>>>File "/usr/local/bin/pybombs", line 11, in 
>>>  load_entry_point('PyBOMBS==2.2.0', 'console_scripts', 'pybombs')()
>>> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
>>> line 542, in load_entry_point
>>>  return get_distribution(dist).load_entry_point(group, name)
>>> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
>>> line 2568, in load_entry_point
>>>  raise ImportError("Entry point %r not found" % ((group, name),))
>>> ImportError: Entry point ('console_scripts', 'pybombs') not found
>>>
>>> That last line sort of makes me feel like it isn't aware of pybombs.
>>> Should all of this work with 16.04 (my only change from before)?
>>>
>>> ___
>>> 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 with a fresh pybombs build

2016-10-07 Thread Koslowski, Sebastian (CEL)
Python usually doesn't look for packages in /usr/local/
That can be changed, of course.
However, maybe you should consider installing pybombs somewhere else.

For example,
pip install --user pybombs
or
pip install --user PATH_TO_YOUR_PYBOMBS_CLONE_OR_TARBALL
should work nicely.

Sebastian

On 10/07/2016 03:07 PM, Jason Matusiak wrote:
> >> ls -lh /usr/local/bin/pybombs
>
> >> My suspicion is that pip for some reason didn't set the executable
> flag
> >> on the pybombs program file. If that's the case, you can fix that by
>
> >> sudo chmod a+x /usr/local/bin/pybombs
>
> That was indeed my first issue.  I don't know that I would blame pip
> for it just yet (we use a wonky version of sudo here at work).  Once i
> made the fix though, I get the following error:
> $ pybombs recipes add gr-recipes
> git+https://github.com/gnuradio/gr-recipes.git
> Traceback (most recent call last):
>   File "/usr/local/bin/pybombs", line 11, in 
> load_entry_point('PyBOMBS==2.2.0', 'console_scripts', 'pybombs')()
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 542, in load_entry_point
> return get_distribution(dist).load_entry_point(group, name)
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py",
> line 2568, in load_entry_point
> raise ImportError("Entry point %r not found" % ((group, name),))
> ImportError: Entry point ('console_scripts', 'pybombs') not found
>
> That last line sort of makes me feel like it isn't aware of pybombs. 
> Should all of this work with 16.04 (my only change from before)?
>
> ___
> 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] Constellation Blocks

2016-10-02 Thread 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)

2016-08-24 Thread 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 <https://github.com/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
<https://github.com/kit-cel/gr-lte>

___
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 GRC generated python code inside a C++ code

2016-08-19 Thread Koslowski, Sebastian (CEL)
Well, there a number of options. Given your description its hard to say
which one is best.
Aside from maintainability and flexibility of the system, it really
depends on the required interaction between the components.
You could
- re-implement the fg in C++.
- create Python bindings for your C++ client (e.g. with swig) and do
the integration/coupling in Python (outside of the fg)
- embed Python in your C++ client
(https://docs.python.org/2/extending/embedding.html)
- simply run the Python interpreter as a sub-process if the C++ client

If you choose 2, 3 or anything not the list let me know how it worked out =)

Sebastian


On 08/19/2016 10:02 AM, Pranav Padalkar wrote:
>
> Hello,
>
>
> I have a GRC generated python code. I also wrote a server-client code
> in C++. I want to implement the client-code along with the GNU python
> code. The essence is that I want to a run a client C++ code, which
> will call the python code in a thread and start the USRP to
> receive/transmit data, and continue performing it's own process in
> another thread. I am not sure how I could go about this. I also
> considered implementing the client C++ code as module in GNU radio and
> use it in the flow graph. But I think that's not how a client
> background code should run.
>
>
> Any thoughts on this matter would be helpful. Thanks in advance.
>
>
> Best Regards,
>
> Pranav Padalkar
> Fraunhofer-Institut für Eingebettete Systeme und Kommunikationstechnik ESK
>  
> Hansastraße 32 | 80686 München
> Telefon, Fax: +49 89 547088-0 | +49 89 547088-220
> E-Mail: pranav.padal...@esk.fraunhofer.de
> <mailto:pranav.padal...@esk.fraunhofer.de>
> Internet:
> http://www.esk.fraunhofer.de <http://www.esk.fraunhofer.de/>
> http://www.twitter.com/FraunhoferESK
> http://www.facebook.com/FraunhoferESK
>
>
> ___
> 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

2016-08-19 Thread 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

2016-08-12 Thread 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

2016-08-10 Thread 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

2016-08-05 Thread 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

2016-08-04 Thread 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

2016-08-04 Thread 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

2016-08-03 Thread 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


  1   2   3   >