Re: [Discuss-gnuradio] question on implementing a state machine

[Vanush Vaswani]

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 <address@hidden> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio