Optimal Acquisition Method and Speed

[johnsold]

Mark,

Good! You are making progress.

If you set your state machine up so that it only waits a few milliseconds in the wait state, then it can be very responsive to anything which happens. An easy way to do this is to pass a "time to do something" value in a shift register. Suppose you want to update the boolean display after 500 ms. When you start the state machine (the Initialization state) and everytime you update the display, you read the current Tick Count value (which is in milliseconds) and add 500 (or any delay value) to it and put the sum into the shift register. Then your "Wait" state compares the current Tick Count to the "time to do something" value. If it is greater or equal, then go to the state where you update the display and set a new value in the shift register.  If the comparison is less than, then wait a short time (5 or 10 ms) and return to the Wait state.  With this method you would go through the Wait state 100 or 50 times for each time you go to the Update Display state. Whenever data comes in you go to the state which handles that and then back to waiting.

One of the key concepts here is to keep the time in any state small enough that it does not delay responding to anything which requires going to another state.  For things which take long times you either break them up into little pieces like 100 short waits or put them in a parallel loop.  File writes often are put in a parallel loop because they can take unpredictably large amounts of time, especially for large or fragmented files.

Lynn

[MLVDR]

Hi,

I do understand your explanation. Nontheless I do have problems integrating the 'wait' state.

I am not really sure how to integrate a wait state still being able to correctly feedback

and receive data at the same time (or as close as possible). The way I inteprateted your explanaition 

is that there needs to be a wait state in which you either direct to the state

of receiving data (when data is present in the queue) or go to the feedback.

But when data is received the RMS calulations follow making it take a while before it would 

return to 'wait' state and check if feedback has to be done. I lack understanding of how the order

the state need to be performed to not get a visible delay between actual action and feedback.

An example:

If I do read 500 samples a time with 5000 Hz this takes 100 ms. These 500 samples are processed

and 500 RMS values are calculated from the last 1000 acquired samples.The final RMS value calculated 

is the one from the most recent 500 samples so, currently, this one is used in the feedback state to check with the boundaries.

So this gets me a very will timed feedback relative to when the data was acquired. 

In the method you describe I can't really see how this would work.  

This time I decided to include my code, and although I can imagine the look of it doesn't make you really happy

I hope you can advice on how to implement the wait state. 

A bit about the code: (EDIT: Sorry: StateMachine5 is the most recent working version)

Currently I do have  6 states:

Initialization: To initialize some counters

Receive Data: To read the data from the queue and write it in the array

Based on the switch it then contineus to either:

RMS: To calculate RMS as discussed

or

Boundaries: To calculate RMS mean and std which will be used as feedback boundaries

When RMS state is called the next state is Feedback.

Finally the Save state check if the initialized array is full and needs to be saved.

Hope you get my point. Thanks for your patience,

Mark