Feedback between Blocks

GNU Radio
1

Hi all,

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.

The way I was thinking of conceptually implementing this is to have a
shared
variable between the two modules and tell then communicate through this
shared variable. However, I am afraid that the overhead is too much for
processing the samples from the USRP on the fly. Is there any cleaner
way to
do this?

Thanks
Shyam

View this message in context:
http://www.nabble.com/Feedback-between-Blocks-tf4164277.html#a11848376
Sent from the GnuRadio mailing list archive at Nabble.com.

2

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 C.
Corgan Enterprises LLC
http://corganenterprises.com

3

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.

Johnathan C.

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 K.

–
View this message in context:
http://old.nabble.com/Feedback-between-Blocks-tp11848376p28091096.html
Sent from the GnuRadio mailing list archive at Nabble.com.