Problem with cascading two buffers in Simulink

8 views (last 30 days)
Hello,
I have 1512 data points and i am using a buffer with length 42112. I would like to go back to my 1512 data points. I am using a cascading buffer of length 1512 but the output starts from the 224th point. I understand that the problem arises due to the fact that the first buffer (42112 length) is not divisible by a whole number with the initial input data length of 1512.
I then thought of using a buffer which its size would be divisible by both numbers. Therefore now my setup is: Data (length 1512) --> Buffer (length 42112) --> Buffer (length 1137024). This second buffer is divisible by a whole number with both: 1137024/1512 = 752 1137024/42112 = 27. I am still getting an output on the second buffer starting with the 224th point. I am a bit baffled as to why this is happening as it looks like the buffers are not operating as i would expect them to do.
SimCascBuff.JPG
Why is this happening in both cases?
I am not very sure if the use of another buffer after the first one (lenght 42112) is the solution to going back to 1512 data points. Moreover, i know that what i am doing looks very bizarre. The data from workspace and first buffer (length 42112) are part of a transmit signal that i cannot alter their length in any way. The data after the buffer undergoes further processing before needing to go back to 1512 data points. The simulink model that i am working on and attaching is just a simplification of a bigger model.
Is there any other way of going back to the initial 1512 data points? I am sure that i am missing something that i haven't thought.
Thank you in advance,
Alex

Answers (1)

Chidvi Modala
Chidvi Modala on 20 Jan 2020
Hi,
From my understanding you are trying to get the 1512 datapoints starting from zero by using the buffer of length 42112.
When you use the buffer length 42112, In the first iteration there will be 255 datapoints left (because remainder of 42112 and 1512 is 1288. Out of 1512 datapoints these 1288 datapoints are sent and the remaining data is carry forwarded to the next iteration). In the second iteration the transmission starts with the left out datapoints and thus this is continued in the further iterations. After 27 iterations the transmission starts from the first datapoint. So, you can make use of ifblock and implement the algorithm such that data is extracted after 27*n time steps (n = 1,2,3…) or you can set the Simulation Stop Time accordingly (Ex: 118200s).
When you use another buffer (length 1137024) after the first one (length 42112). The second buffer takes the values after first iteration from the first buffer as input. After first iteration the first buffer will have values starting from 255 and the data length provided here is 42112 which can be properly assigned for a buffer of length 1137024, No values are carry forwarded for the next iteration. Thus, the second buffer is displaying those values forever.
For more information you can refer to https://in.mathworks.com/help/dsp/ref/buffer.html
  2 Comments
Alexios Costouri
Alexios Costouri on 20 Jan 2020
Hi Chidvi,
The 1512 data points from the workspace and first buffer(length 42112) are part of transmission chain. In my receiver chain i am receiving 42112 data points in which i need to cut them up in 1512 data chunks.
I am still very confused as to why when buffer 1 fills up does not release the data to the next stage (in this case another buffer). Furthermore, i do not understand on how to implement a counter with an if statement and how this would help since it seems data are not released.
For me it seems like these buffers do not act as i would expect them to do.
Sorry i am still quite confused on how to move forward. Thank you for looking into my query.
Best,
Alex
Chidvi Modala
Chidvi Modala on 21 Jan 2020
I think you are assuming that a buffer block processes the input data at each time step, but that is not how buffer block functions. Buffer block buffers the input sequence to smaller or larger frame size. It always performs frame-based processing. When an input is given to the buffer, it keeps on buffering the provided input data at t=0. In your Simulink model the first buffer length is 42112 and the provided data length is 1512. 42112 is not perfectly divisible by 1512. It keeps on carry forwarding the left-out values in the next step (You can observe this by step-forwarding instead of running the model). That is the reason why the first buffer initial value keeps on changing. Where as when you use the second buffer of length 1137024, the initial input will be the output of the first buffer (length 42112) in the previous time step i.e.; which starts from 224. So, the second buffer keeps on buffering this data. Unlike the first buffer where buffer length is not divisible by data length and the left-out data chunks are getting forwarded to the next step, the second buffer length is divisible by data length so the buffering is completed and it keeps on buffering the same data(which starts from 224).
In order to get the first 1512 data chunks (0-1511) you can access block data when the time reaches 1182000s (because after every 27 time steps the data inside buffer starts from zero). You can refer to https://in.mathworks.com/help/simulink/ug/accessing-block-data-during-simulation.html to access block output data at a particular time

Sign in to comment.

Categories

Find more on Event Functions in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!