# Question on implementing a state machine

**URL:** <https://www.ruby-forum.com/t/question-on-implementing-a-state-machine/242247>\
**Category:** GNU Radio\
**Created:** [June 9, 2015, 4:19am UTC](https://www.ruby-forum.com/t/question-on-implementing-a-state-machine/242247 "2015-06-09T04:19:52Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\
**Post date:** [June 9, 2015, 4:19am UTC](https://www.ruby-forum.com/t/question-on-implementing-a-state-machine/242247/1 "2015-06-09T04:19:52Z")

</div>

Hi

Please forgive me if the questions are silly/basic. I’ve learnt a lot  
from  
replies on this forum and I’m making steps in the right direction, if  
only  
baby ones.

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.

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)?

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?

Thank you  
Anil

---

<div class="post-metadata">

**Author:** ![anil\_y](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/22d042/32.png) [@anil\_y](https://www.ruby-forum.com/u/anil_y)\
**Post date:** [June 9, 2015, 6:23am UTC](https://www.ruby-forum.com/t/question-on-implementing-a-state-machine/242247/2 "2015-06-09T06:23:43Z")

</div>

On 06/08/2015 07:16 PM, Anil K. Yerrapragada wrote:

> 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.

> 1. 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

---

<div class="post-metadata">

**Author:** ![anil\_y](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/22d042/32.png) [@anil\_y](https://www.ruby-forum.com/u/anil_y)\
**Post date:** [June 9, 2015, 2:56pm UTC](https://www.ruby-forum.com/t/question-on-implementing-a-state-machine/242247/3 "2015-06-09T14:56:03Z")

</div>

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](https://github.com/jmalsbury/gr-tnc/blob/master/lib/hdlc_deframer_impl.cc)