Dear Miklos,
I'm glad to hear from you.
The idea of this experiment is quite similar to the core of your
honored paper The flooding time synchronization protocol. It's a
transmitter-receiver sync method using precious tx/rx timestamp to
synchronize transmitter's and receiver's local
On Fri, Oct 11, 2013 at 6:51 PM, Johnathan Corgan
johnat...@corganlabs.com wrote:
On 10/11/2013 04:23 AM, Alexandru Csete wrote:
I am probably missing something or just misunderstand the situation,
so please enlighten me :)
This is more Tom's area, but I'll comment since he's off enjoying
Hi Tim,
you're entering a minefield there...
Since you've built your flowgraph using GRC, you have a python-constructed
flowgraph. That's why things start to get confusing for the c++ developer.
First of all, destructors of python objects are called whenever the python
runtime feels like it -
Hi Harry,
First, you should always transmit from node A, but when you want to be
silent, then transmit something very close to zero complex numbers.
This will ensure, that you have a nice continuous stream of data going
out, and you can plan to do anything you want with sampling rate
precision
Dear Miklos,
Thank you for your inspiring reply.
1.I do think this method sounds like a receiver-receiver sync while
sync message's transmitter A also doing beacon node C's function (
(1)sending sync message and (2)recording receive time which would be
sended to B for sync).Is it
you're entering a minefield there...
Thanks for helping me navigate :)
First of all, destructors of python objects are called whenever the python
runtime feels like it - this often happens when you do something like
object_name = None but it doesn't necessarily has to happen right away.
Hi list,
I discovered 2 problems with GRC recently.
1. I have a custom block with a message port (with a fixed port name)
and some stream ports which include a nports.../nports definition.
The whole thing works fine as long as I have a fixed number of ports.
Each declared separately. But as soon
I'll confirm that #2 is either a bug or merely unexpected behavior. I work
around it by prototyping hier blocks as custom GRC blocks, then using that
to build an OOT module block that actually works. Being unable to enter
parameters at run time is severely limiting.
I've not experienced #1,
On 09/29/2013 09:27 PM, Mark Cottrell wrote:
I am working with gnuradio 3.7.2git-28-g639e154d and I have a
hierarchical block with a message output that I have been using as part
of a larger flowgraph. Yesterday I found that whenever I call
msg_disconnect on the top block with the hier block
Re: #1, if the block's xml is malformed then GRC will basically show
nothing (that grey flowgraph page you describe). Are you defining $ports in
the make node? Compare to a similar block to make sure everything is
defined properly.
Hi Nathan,
My guess is that the problem is a bit more tricky.
The XML block definition works fine as long as the message port is not
present. I can use nports as shown in stream_to_streams.
It also works fine as long as the nports statement is not used and a
message port is defined. This means
On 12.10.2013 10:58, Jared Clements wrote:
I'll confirm that #2 is either a bug or merely unexpected behavior. I
work around it by prototyping hier blocks as custom GRC blocks, then
using that to build an OOT module block that actually works. Being
unable to enter parameters at run time is
Check the order, there's apparently only one tag order that works. I
brought it up last week and was told it was known behavior.
Jared
On Oct 12, 2013 2:59 PM, Johannes Demel uf...@student.kit.edu wrote:
Hi Nathan,
My guess is that the problem is a bit more tricky.
The XML block definition
Hi folks,
I was wondering if I am currently able to use the latest revision of the
GR module, the one from the 3.4.2 tarball, with the 3.6.4.1 source
tarball and the UHD driver of course.
I have browsed through python code and at a first glance it shouldn't be
so difficult to update it by
The link in the git README is
http://gnuradio.org/doc/doxygen/page_build.html
to the detailed build instructions, however, the link should be:
http://gnuradio.org/doc/doxygen-3.7/build_guide.html
and this could be fixed with a redirect at the web server or a change to
the readme. I would
15 matches
Mail list logo
