I am writing and out off tree block that outputs data at different rates on either of its two output ports. To let the scheduler know about that, i am using produce(<port>,<number of items produced>). But there is a problem when using it in combination with set_history(<number of past items>). The history tells the scheduler to provide me with a certain amount of old data that I still need access to for a Filter for example. In my case the combination if those two features causes the scheduler to mess up the input stream it provides to my block. I have written a minimal example of a block that only copies the data from the input to the output and does some internal logging as well. This is the logging part:
std::ostringstream ss;
ss << "call_to_work: " << call_to_work <<"\n";
ss << "Input Signal: \n";
for(int i=0; i<noutput_items+history(); i++){
ss << sig_in[i] <<" "<< i << "\n" ;
}
call_to_work++;
.
.
.
GR_LOG_DEBUG(this->d_debug_logger, ss.str());st
it should actually be history()-1 since history is always at least 1 but it is really only important to show that the corrupted data is already in the array that the scheduler provides to my block.
All the Signal processing that i do happens here:
for(int i=0; i<noutput_items; i++){
sig_out[i]=sig_in[i+history()-1];
}
The important part here is that I output current data by adding history()-1 and do not add a delay to the signal by always outputting historic data. If i do that the problems disappear. But know finally to the actual problems that i am seeing. this is my setup around the test block I write both the data from the previous block and the data after my test block to a file and look at it graphically. this is what I see. The blue graph is my input data and the red graph is the output. As you can see on the blue graph a signal at regular intervals is the input but the output is missing some of that data, even though it should be exactly the same. This is how it looks from the logging file from within my block:
(0,0) 30
(0,0) 31
(1,-1.74846e-07) 32
(-0.0980173,-0.995185) 33
(-0.923879,0.382684) 34
(0.773011,0.634393) 35
(-3.57746e-08,-1) 36
(-0.634394,0.77301) 37
(0.92388,-0.382683) 38
(-0.995185,0.0980168) 39
(1,-6.99382e-07) 40
(-0.995185,0.0980175) 41
(0.923879,-0.382684) 42
(-0.634392,0.773011) 43
(-7.35157e-07,-1) 44
(0.773011,0.634393) 45
(-0.923879,0.382685) 46
(-0.0980157,-0.995185) 47
(1,-1.43099e-07) 48
(0.0980157,0.995185) 49
(-0.923881,0.382681) 50
(-0.773009,-0.634396) 51
5425 :DEBUG: test0 - call_to_work: 19
Input Signal:
(0,0) 0
(0,0) 1
(0,0) 2
(0,0) 3
(0,0) 4
(0,0) 5
The Signal that is produced by the previous block produces a 32 element long complex signal with 200 zeroes in between. Call to work 18 only provides the first 20 elements so call to work 19 should re provide those 20 elements because of the history and also the missing 12. Instead there are only zeroes in the data.
I suspect that my forecast function is not quite up to the task ninput_items_required[0] = noutput_items;
or that I am using the produce() function in a wrong way. I do return WORK_CALLED_PRODUCE.
Or is this an issue with gnuradio itself?
