Difference between revisions of "User:Dvw/Spider slow jitter/Lag slow data fix"

From MCEWiki
 
Line 7: Line 7:
  
 
We also have to detect instances where (1) is never true during a slow frame and add data to keep slow and fast data aligned (see the fourth slow frame below).  '''This solution can result in discarded data''', if (1) is true multiple times in a single slow frame. As before, green cells are fake data; red cells are repeated data.
 
We also have to detect instances where (1) is never true during a slow frame and add data to keep slow and fast data aligned (see the fourth slow frame below).  '''This solution can result in discarded data''', if (1) is true multiple times in a single slow frame. As before, green cells are fake data; red cells are repeated data.
 +
 +
The benefit of this solution is that, whenever possible, all slow data that were in the same slow frame in the original framefile (all the slow data  <tt>slow<sub>MX=''m''</sub>[''i'']</tt>with the same index <tt>''i''</tt>) end up in the same slow frame in the output dirfile.  The trade off is that the slow data is no longer aligned with the fast data (a lag of at most one slow frame may occur).
 +
 
{| class="wikitable"
 
{| class="wikitable"
 
|+ Lag slow data fix.
 
|+ Lag slow data fix.

Latest revision as of 15:27, 29 May 2015

NB: The following has fast data with 10 samples-per-frame (=FAST_PER_SLOW) rather than the actual number of 20 just to make the table smaller.

This is a solution to Spider slow jitter which happens by only writing slow data when the input concludes a slow frame. i.e. whenever 

MX % FAST_PER_SLOW = FAST_PER_SLOW - 1                      (1)

is true, write the latest slow data that you have.

We also have to detect instances where (1) is never true during a slow frame and add data to keep slow and fast data aligned (see the fourth slow frame below). This solution can result in discarded data, if (1) is true multiple times in a single slow frame. As before, green cells are fake data; red cells are repeated data.

The benefit of this solution is that, whenever possible, all slow data that were in the same slow frame in the original framefile (all the slow data slowMX=m[i]with the same index i) end up in the same slow frame in the output dirfile. The trade off is that the slow data is no longer aligned with the fast data (a lag of at most one slow frame may occur).

Lag slow data fix.
SLOW FRAME BOUNDARY
fast[ 0] slowMX=0[0] slowMX=1[0] slowMX=2[0] slowMX=3[0] slowMX=4[0] slowMX=5[0] slowMX=6[0] slowMX=7[0] slowMX=8[0] slowMX=9[0]
fast[ 1]
fast[ 2]
fast[ 3]
fast[ 4]
fast[ 5]
fast[ 6]
fast[ 7]
fast[ 8]
fast[ 9]
SLOW FRAME BOUNDARY
fast[10] slowMX=0[1] slowMX=1[1] slowMX=2[1] slowMX=3[1] slowMX=4[1] slowMX=5[1] slowMX=6[1] slowMX=7[1] slowMX=8[1] slowMX=9[1]
fast[11]
fast[12]
fast[13]
fast[14]
fast[15]
fast[16]
fast[17]
fast[18]
fast[19]
SLOW FRAME BOUNDARY
fast[20] slowMX=0[2] slowMX=1[2] slowMX=2[2] slowMX=3[2] slowMX=4[2] slowMX=5[2] slowMX=6[2] slowMX=7[2] slowMX=8[2] slowMX=9[2]
fast[21]
fast[22]
fast[23]
fast[24]
fast[25]
fast[26]
fast[27]
fast[28]
fast[29]
SLOW FRAME BOUNDARY
fast[30] slowMX=0[3] slowMX=1[3] slowMX=2[3] slowMX=3[3] slowMX=4[3] slowMX=5[3] slowMX=6[3] slowMX=7[2] slowMX=8[2] slowMX=9[2]
fast[31]
fast[32]
fast[33]
fast[34]
fast[35]
fast[36]
fast[37]
fast[38]
fast[39]
SLOW FRAME BOUNDARY
fast[40]                    
fast[41]
fast[42] slowMX=0[3] slowMX=1[3] slowMX=2[3] slowMX=3[3] slowMX=4[3] slowMX=5[3] slowMX=6[3] slowMX=7[3] slowMX=8[3] slowMX=9[3]
fast[43]
fast[44]
fast[45]
fast[46]
fast[47]
fast[48]
fast[49]
SLOW FRAME BOUNDARY
fast[50]                    
fast[51]
fast[52] slowMX=0[4] slowMX=1[4] slowMX=2[4] slowMX=3[4] slowMX=4[4] slowMX=5[4] slowMX=6[4] slowMX=7[4] slowMX=8[4] slowMX=9[4]
fast[53]
fast[54]
fast[55]
fast[56]
fast[57]
fast[58]
fast[59]
[&c.]
Retrieved from "https://e-mode.phas.ubc.ca/mcewiki/index.php?title=User:Dvw/Spider_slow_jitter/Lag_slow_data_fix&oldid=6047"