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
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 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
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
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
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
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, of co
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.
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 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
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
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
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
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
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
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?
Unfortunately,
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 reopened it,
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:
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 with
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 MHz
--
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 able to
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.
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
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
-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-
-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 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 lower case
On 01/09/2015 03:36 PM, PIGUET Damien wrote:
Here is my block XML:
?xml version=1.0?
block
nameMy QPSK Demodulator/name
keytutorial_my_qpsk_demod_cb/key
categoryTutorial/category
importimport tutorial/import
maketutorial.my_qpsk_demod_cb($Gray_code)/make
param
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
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 interactive
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 object
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...
?xml version='1.0' encoding='ASCII'?
block
nameTest/name
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
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
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
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 block,
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 you
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:
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
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 file,
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
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
46 matches
Mail list logo
