Johnathan Corgan-2 wrote:
>
> Shyamnath wrote:
>
>> I am trying to incorporate a few modifications to the DBPSK
>> implementation in gnuradio for which I need to implement feedback
>> between the different signal. So my question, is there a clean way to
>> implement feedback between the different signal processing blocks.
>> More specifically if my flow graph is BLOCK1 --> BLOCK2 -> BLOCK3 and
>> I want to have a feedback from block3 to block1 is it possible? I am
>> interested in feedback of a flag bit.
>
> There are a few ways you can do this, depending on how frequently you
> need to update the value of this flag.
>
> As you mentioned, you can create a shared variable and pass a reference
> to this to your blocks. You'll need to write your own blocks, however,
> in order to add the code in the 'work' function that acts on the flag
> value.
>
> You'll need to protect your shared data with a mutex or other
> synchronization primitive, as there is no guarantee that the work
> functions of your blocks will run in the same thread. (Currently they
> do; this will definitely change in the future.)
>
> But there is still no guarantee how frequently the work functions will
> get called by the flow graph scheduler, so there could be an arbitrary
> delay between setting the flag in one block and the opportunity for
> another block to act upon the changed value.
>
> If you only need to update the value infrequently, you can instead do it
> from a custom thread from within Python. For example, from a custom
> thread, you can wake up once a second, call a read method on one block
> 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.
> --
> Johnathan Corgan
>
>
I am also interested in an answer to this question. I do not fully
understand the flow graph thread/process dispatching/scheduling process in
gnuradio for streams of data. From Jonathan's statements, It seems as
though 'chunks' of data are processed using the user-defined-in-python chain
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, it
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 rate
(e.g. the feedback flag is asserted for *each* received packet; with ~1ms
granularity???). Perhaps the 'custom thread' approach suggested by Jonathan
would work this fast - I'll try it out - although it seems a bit inefficient
(e.g. polling instead of interrupting). Are there 'tags'/timestamps on data
samples that I can use? Has someone else implemented something similar
already?
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 right
through 'Block 1' and on through 'Block 2' to 'Block 3'. The objective is
to be able to use the feedback signal to 'note' the specific upstream raw
samples that are associated with a particular detected downstream valid
packet. I searched but didn't see anything like this in the gnuradio source
code, but maybe someone can point me towards something similar that I might
have overlooked.
System time in Block 1 and Block 3 could be used for time-stamping, but it
sounds as though this won't really help me ('no guarantee' on the execution
times for the different blocks by the flow graph scheduler). I could also
implement a parallel tagging path too. Based on the comments above, it
seems like the flow graph scheduler will not 'guarantee' that this parallel
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 of
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 sequences
of received packets that occur 'close together' in time. Not detecting a
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 near
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 in
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 ADC
samples and the exact time that they occurred (this is pretty well
timestamping, straight up). Maybe there is a Rx-clock based counter in the
FPGA that can be read... synchronously with data.... Does anyone know of an
FPGA load which has this functionality?
Any suggestions/guidance would be appreciated.
/ David Knox
--
View this message in context:
http://old.nabble.com/Feedback-between-Blocks-tp11848376p28091096.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
