I think that making the buffer larger wouldn't help much. My problem is: I have an interleaver, where i pass my data through. This interleaver is made of several shifters, of different sizes. The input goes through the shifters in an especific order (given by keying), and the output is formed by keying the shifters output in a different order. The problem is that if the buffer finishes and i lost the data inside the shifters, i'll lost data. So i need to conservate this structures among each bufferized execution of the block.
Is that possible? What i think that may be helpful is some sort of global structure where i can store this status. Best Regards, 2012/1/13 Josh Blum <j...@ettus.com> > > > On 01/13/2012 08:11 AM, André Selva wrote: > > Hi! > > > > I've been working on the development of a Digital TV transmitter on GNU > > Radio. > > The problem is that the information flow is bufferized before "entering" > > the blocks, but the information i need to process is too large to be > > bufferized. > > So, I need the data contained on some internal structures of my blocks > (for > > example, shifters) to be preserved between the executions of each > > bufferized part of the data flow. One of the alternatives is saving this > > data in files and reloading then on the initialization, but i think this > > may ruin my performance. > > I've read on this< > http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide#Saving-state > > > > tutorial, that exists the possibility to save the status between > executions > > using the methods start() ans stop() from the block, but i cannot find > more > > information about that. Is that the correct way to solve this problem? If > > so, where can i find more information about those methods? > > > > The idea behind "saving state" was to help users make their blocks > robust against the flow graph starting/stopping. This is starting and > stopping of processing as a whole, so it doesnt help your case which is > "what to do" while processing. So, if you dont have enough CPU memory to > buffer, than the only options two you mentioned. > > Or is it the case that you just need gnuradio buffers to be larger, and > everything would therefore work out better for your processing > implementation? > > -Josh > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- André F. B. Selva
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
