Re: Proposal draft
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
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
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
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
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
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
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
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
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 ?
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
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)
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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)
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)
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)
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)
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
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
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
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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))
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)
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
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
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?
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
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
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
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
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
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
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!
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
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
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
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
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
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
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
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
> > /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
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?
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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