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-tf41... Sent from the GnuRadio mailing list archive at Nabble.com.
on 2007-07-29 04:54
on 2007-07-29 17:48
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 Corgan Enterprises LLC http://corganenterprises.com
on 2010-03-31 05:26
Johnathan Corgan-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 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-tp11... Sent from the GnuRadio mailing list archive at Nabble.com.