I believe this is a very common pattern for decoding simple protocols (once you have the bits)
Here's an example https://github.com/jmalsbury/gr-tnc/blob/master/lib/hdlc_deframer_impl.cc On Tue, Jun 9, 2015 at 2:22 PM, Martin Braun <[email protected]> wrote: > On 06/08/2015 07:16 PM, Anil Kumar Yerrapragada wrote: >> I am trying to implement a state machine based synchronization >> algorithm. The 2 states being "search for synch sequence" and "pass data >> through". >> >> As far as I can see, the ideal way to do this is to have the work >> function check what state it is in before proceeding. If it is in search >> state, the work function will search for the synch sequence and once >> found, switch to "pass data" and get out. >> >> Next time work is called (use forecast to make sure that the number of >> input items available matches the amount I have data I have after the >> synch sequence), it will pass data through. Switch state back to >> "search" and so on. > > FYI, the header/payload demux block does just that. It's pretty generic, > so it'll catch more cases than you need, but have a look at its source code. >> >> My questions are these: >> >> 1. Before each work call, does GNURadio automatically know the state >> that I left it in in the previous call? (Am I allowed to make work >> return anything else apart from len(output_items)? > > No, but class attribute will persist between work calls. > >> >> 2. Is it better/possible to implement a separate block for the state >> machine that can somehow make the system aware of what state it is in? > > Just make the state a class variable / attribute. > > Have fun and good luck, > > M > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
