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
dtyp
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
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-casi
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 alr
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
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 p
ombs
>
> 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,
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.
Sebasti
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 you
Your PYTHONPATH looks fine to me. In one of those paths should be a
"gnuradio/grc/main.py". Looks like that didn't get installed for some
reason. Maybe you could double check whats actually in there.
Admittedly, the error message could/should be a bit friendlier. I will
fix that.
Sebastian
On 08
Thanks for reporting this. My commit is indeed responsible for this.
Fixed one bug, but added a new one...
The expression splitting code seems to be very fragile =)
Please check out this branch that contains an updated fix
https://github.com/skoslowski/gnuradio-wg-grc/tree/callback_fix_doover
Let
I needed that a while back, too. Here is the patch I used:
https://github.com/skoslowski/gnuradio/commit/453a13a6a74cee5c0ca3973d08770940daef87eb
With that applied you can do:
from gnuradio import uhd
uhd.register_msg_handler(uhd.null_msg_handler)
Should disable all output from (gr-)
April 28, 2016, of course.
On 04/25/2016 04:52 PM, Sebastian Koslowski wrote:
> Hey,
>
> we plan to have a GRC Development Meeting on Thursday April 25, 2016 at
> 7pm CEST.
> Anyone, how whats to work on GRC is welcome to join. We'll review the
> latest changes briefly and then move on to future d
On 03/30/2016 10:54 PM, Richard Bell wrote:
> I've asked this question a few times now on the mailing list, and each
> time I hope a different answer comes through. Each time though it's
> the answer Ron gave, which never works for me. I can't figure it out.
> So I've always resorted to the xml tag
Thanks for the report. Here is a fix:
https://github.com/gnuradio/gnuradio-wg-grc/pull/48
Sebastian
On 01/21/2016 08:29 PM, Richard Bell wrote:
> I just setup a simple debug test that reproduces the issue. Screen
> captures attached. You see what I see before and after the message and
> the error
On 08/13/2015 08:38 AM, bob wole wrote:
> I am using gnruadio 3.7.8. I have a module (python) which is working
> well for version 3.6.3. In made necessary changes so that it can work
> with gnuradio 3.7.8. However I am getting following error
>
> File
> "/usr/local/lib/python2.7/dist-packages/gnu
On 07/27/2015 09:18 PM, Jason Matusiak wrote:
> Sadly would have never thought to look there. That did the trick,
> thanks.
In the upcoming release there will also be the option to set a default
size in "~/.gnuradio/config.conf" (along with the canvas font size).
Sebastian
On 07/17/2015 03:08 PM, Jason Matusiak wrote:
> OK, sound like that could be very useful, thank you. In the meantime, > is
> there a way to open gnuradio without it reopening all the >
previously opened scripts (I am wondering if that is my problem)? >
Maybe something like a safemode?
Unfortunate
On 07/17/2015 03:22 PM, Jason Matusiak wrote:
> No dice. I tried gnuradio-companion "" as well as gnuradio-companion
> test.grc (which does not exist), and I still seg fault.
>
> I went into gr-cdma/build and did a make clean && sudo make uninstall,
> but it still isn't working
>
> ___
On 07/17/2015 02:27 PM, Jason Matusiak wrote:
> Hello,
>
> I had a nicely working GRC on an Ubuntu 14.04 VM. I then installed the
> GR-CDMA module via PyBombs. I was going through the steps to build the
> different packages and GRC started acting weird. I closed it down and
> then when I reopene
On 07/15/2015 01:47 PM, Albin Stigö wrote:
> The idea was to make the instrumentation blocks work well and native
> on mac... I was also looking into hacking the gnuradio-companion to
> work better on mac (it doesn't work well on retina displays).
Try this branch:
https://github.com/skoslowski/gnu
On 07/06/2015 07:25 PM, Jared Dulmage wrote:
> @Sebastion "Even if ' uhd::msg::register_handler' would be exposed to python,
> you
> still can't drop-in your own null-handler. Swig doesn't support
> callbacks in the target language (python)."
>
> This seems precisely what I have observed working
On 07/01/2015 10:19 AM, Piotr Krysik wrote:
> Hi all,
>
> UHD host library generates prints on the stdout. For example on each
> retune I get something like:
>
> -- Tune Request: 959.00 MHz
> -- The RF LO does not support the requested frequency:
> -- Requested LO Frequency: 959.00 MH
On 06/19/2015 03:36 PM, alok ranjan wrote:
> Hello List,
>
> I have updated my gnu radio from 3.7.2.1 to *3.7.7.1*.
>
> After the update when i am typing the "gnuradio-companion" it is
> getting open but the propriety icon is missing. I tried to make the
> new flow graph and i am successfully ab
Hey,
so, I timed the flowgrah update steps rewrite, validate, create labels,
create shapes and it turns out most time is actually spent in validate.
However, for some reason the validate step currently performs the
evaluation of the params and this is also where it spends almost all of
its time. S
I had a similar problem recently. My solution was to subclass the
flowgraph adding the required functionality. Check out the
_top_block_waiter class in top_block.py. You can reimplement that logic
to e.g. add a time-out the the wait() call on the event or have a
callback executed.
Sebastian
On 0
On 03/23/2015 05:43 PM, Richard Bell wrote:
> The second was a 'comment through' option. This comments out the block
> and passes data through it to the next block. Saves having to mess
> with wires between blocks that are commented out.
Martin's quite right, there is way more to be done, than th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/19/2015 04:26 PM, Tom Rondeau wrote:
> In the meantime, perhaps using parameters to define other parameters isn't
> really the right thing to
do, anyways. You are setting the default value based on the default
value of another parameter. When
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Problem found. I pushed a fix to the maint_grc branch on the grcwg repo:
https://github.com/gnuradio/gnuradio-wg-grc/commit/b57a4cbe8229635a1a2c87ff70f7842f74def72a
Let me know if that works for you.
Sebastian
-BEGIN PGP SIGNATURE-
Versio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/20/2015 10:01 AM, Murray Thomson wrote:
> Hi,
>
> I'm want to use grcc from an ssh session but I get the error importing
the module Colors.py.
> I've seen this thread
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00361.html
abo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/12/2015 09:19 AM, Murray Thomson wrote:
> But my grc companion 3.7.6.1 keeps compiling the blocks to > ~/.grc_gnuradio
> Can you think of
anything else I could try? I've > tried with Ubuntu 12.04 and Ubuntu 14.04.
I created an issue [1] for
On 01/09/2015 03:36 PM, PIGUET Damien wrote:
> Here is my block XML:
>
>
>
>My QPSK Demodulator
>tutorial_my_qpsk_demod_cb
>Tutorial
>import tutorial
>tutorial.my_qpsk_demod_cb($Gray_code)
>
> Gray Code
> gray_code
> ...
>
GRC uses whatever you put in to crea
On 01/09/2015 02:31 PM, PIGUET Damien wrote:
> self.tutorial_my_qpsk_demod_cb_0 = >
> cannot find 'Gray_code': tutorial.my_qpsk_demod_cb($Gray_code)
> <
Looks like your block XML should read
"tutorial.my_qpsk_demod_cb($gray_code)" in the make tag.
(Notice the lowe
On 12/15/2014 05:13 PM, Ludwig Stephan (CR/AEH4) wrote:
> Thanks Martin for your immediate answer. Because I fear ignoring some blocks,
> which might become imminently useful, I meanwhile assembled a list of blocks,
> which have no category.
Of course, there is always the option of adding a (sen
On 11/06/2014 04:39 PM, Marcus D. Leech wrote:
> I have a flow-graph:
>
> https://www.cgran.org/svn/projects/simple_ra
>
> It comes with a makefile, which sets up PYTHONPATH, and calls grcc -d
>
> That grcc -d consistently fails ("Error during compilation")
>
> Yet, when I bring the graph into int
On 10/16/2014 12:41 PM, David Halls wrote:
> Is there any way to get a pointer to a UHD sink block from another
> block in a flow graph, such that I can read from the time registers of
> a USRP?
Depends how you're building your flow-graph: In Python, simply pass a
reference to your UHD block obje
On 05/14/2014 12:29 PM, Activecat wrote:
> I have then tested few combinations, it seems that a source block cannot
> have a message sink port.
> Is there such a restriction ..?
Not that I know of...
Test
message_sink_complex_source_test
Custom
None
in
message
True
Same here. Thanks for reporting. I pushed a fix to the GRCWG repo,
should make it into the mainline soon.
Sebastian
On 04/11/2014 04:27 AM, Dan CaJacob wrote:
> I think this change might be breaking a few things. If anyone else can
> check, please let me know if I'm nuts:
>
> I am running v3.7.
I opened an issue on gnuradio.org for this.
http://gnuradio.org/redmine/issues/653
You can pull a fix from:
https://github.com/gnuradio/gnuradio-wg-grc/tree/grc_pygtk_backw_compat_fixes
Let me know if that works for you.
Sebastian
--
Karlsruhe Institute of Technology (KIT)
Communications Eng
Hi,
looks like a version issue. Try updating to PyGTK 2.22 or above.
Sebastian
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Sebastian Koslowski
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe, Germany
Phone: +49 721 608-46275
Fa
I can reproduce the issue and also confirm your work-around. I pushed a
fix to the grcwg repo. See if that works for you guys.
Sebastian
On 01/31/2014 12:53 AM, Achilleas Anastasopoulos wrote:
> SUCCESS!!
>
> after renaming the output message pad as zzz_something, the right order
> is restored!
On 01/29/2014 06:20 PM, Achilleas Anastasopoulos wrote:
> 1) the colour of the pad connection is not exactly the same as the
> message connection (maybe this implies something...)
Like the color difference between "Message Queue" and "Async Message"
ports (see Help-->Types)?
> When I compile the
Hi Jeroen,
On 01/21/2014 01:57 PM, jer...@boschma.com wrote:
> * I changed the XML file to reflect the additional parameter
>
> ...
>
> It boils down to top_block.py, where I see a call to my block with
> only 3 parameters while in all files I can see, 4 parameters are
> defined.
Sounds like yo
I created a patch to fix the issue of missing message connections. If
you want to help testing, see
https://github.com/gnuradio/gnuradio-wg-grc/tree/grc_fg_load_fix
Let me know, if this works for you. Also, the hier/ example in gr-blocks
had a minor bug. See:
https://github.com/gnuradio/gnuradio
Was offline this week...
I looked at the example in gr-blocks and this is not an issue with the
way connections are displayed. Sean, you should see some error messages
in the console detailing which connections (including their blocks and
ports) could not be made. That should help to reconstruct t
On 12/06/2013 09:06 AM, Marcus Müller wrote:
> Ok, let's say the whole file minus prologue - there is a timestamp in
> there ;)
...
> Thinking about that, I realize what could be useful would be a
> screenshot of the flowgraph, displayed when using a certain command
> line flag on the python fil
Hi,
I just completed a rewrite of the search function in GRC (on master).
The block tree is now filted (instead of showing search results in a
separete category). Also, this fixes the long-standing bug where GRC
would crash if the search was open and the window was scrolled to the end.
To search,
Sylvain is right, you can use the pre-build binaries. I've worked with
the rtl-sdr library on windows before [0], although not with gnuradio.
If you can to compile the source block, it should work fine.
For the driver installation I tried a tool called Zadig (it failed). So
I downloaded the WinUSB
48 matches
Mail list logo