Johnathan C.-2 wrote:
functions of your blocks will run in the same thread. (Currently they
to get the flag value, then call a method on the other block to set it.
There are variations of the above but we’d need to know more about what
you’re trying to accomplish.
I am also interested in an answer to this question. I do not fully
understand the flow graph thread/process dispatching/scheduling process
gnuradio for streams of data. From Jonathan’s statements, It seems as
though ‘chunks’ of data are processed using the user-defined-in-python
of software routines.
There is little/no user-code control of the chunk size or frequency with
which those chunks get passed between routines. Is this correct? Also,
seems like flow graph scheduling is only done in Python, not C++, right?
I want to do what Shyamnath is trying to do, at a fairly high refresh
(e.g. the feedback flag is asserted for each received packet; with
granularity???). Perhaps the ‘custom thread’ approach suggested by
would work this fast - I’ll try it out - although it seems a bit
(e.g. polling instead of interrupting). Are there ‘tags’/timestamps on
samples that I can use? Has someone else implemented something similar
I have seen discussions in the forum about timestamping/tagging of data
samples for the USB interface. However, I need these tags to make it
through ‘Block 1’ and on through ‘Block 2’ to ‘Block 3’. The objective
to be able to use the feedback signal to ‘note’ the specific upstream
samples that are associated with a particular detected downstream valid
packet. I searched but didn’t see anything like this in the gnuradio
code, but maybe someone can point me towards something similar that I
System time in Block 1 and Block 3 could be used for time-stamping, but
sounds as though this won’t really help me (‘no guarantee’ on the
times for the different blocks by the flow graph scheduler). I could
implement a parallel tagging path too. Based on the comments above, it
seems like the flow graph scheduler will not ‘guarantee’ that this
path is handled consistently/synchronously with the data samples path
either. Which is the better approach?
I don’t care about absolute real-time delay or jitter in the processing
samples, but I don’t want to incorrectly map a set of raw samples to the
wrong decoded packet-level data. I also need to be able to handle
of received packets that occur ‘close together’ in time. Not detecting
packet is preferred to losing track of this ‘identity’ correspondence
because of gnuradio flow-graph scheduler-related asynchronous operation.
Unfortunately, I am definitely interested in data that occurs at or
the same time; this is so I can try and dial out some of the RF channel
time-variant fading effects in my analysis. Therefore, losing packets
this way should be a rare event. Given this, what is the best approach?
In other news, I’d also really like to know the correspondence between
samples and the exact time that they occurred (this is pretty well
timestamping, straight up). Maybe there is a Rx-clock based counter in
FPGA that can be read… synchronously with data… Does anyone know
FPGA load which has this functionality?
Any suggestions/guidance would be appreciated.
/ David K.
View this message in context:
Sent from the GnuRadio mailing list archive at Nabble.com.