I am using the IISDWB and am trying to configure it for FIFO mode. FIFO_STATUS2 is always returning 0x6A signaling that FIFO in going into overrun. Any ideas why this is constantly happening?

[SSedi.1]

I read FIFO_STATUS 2 within main, then execute a for loop that will read all bytes stored in FIFO (as per the DIFF_FIFO_BITS : (DIFF_FIFO_BITS are always reading 0x200 as a result of this error with FIFO_STATUS2). And I make sure to read 7 bytes at a time - tag + 6 output registers. Then after the for loop I read the FIFO_STATUS2 and print its value again only for it to be 0x6A still. It never seems to change, which is a bit strange. Not sure what I'm missing or if I configured something inaccurately. Would greatly appreciate any insight with this at all.

[niccolò]

Hi @SSedi.1​ ,

did you set the STOP_ON_WTM bit in FIFO_CTRL2 (08h)?

that could lead to a FIFO smaller than you want, but the problem remains.

is the data read from fifo ok, when you read it?

you have to make sure to read everything to empty the FIFO.

Let me know if this helps

Niccolò

[SSedi.1]

Hi Niccolo,

Thanks for responding!

I did try setting up the STOP_ON_WTM register.

The data I read from the FIFO is okay when I read it. I have a for loop that iterates until the counter variable is equal to the value of the DIFF_FIFO_BITS so I do believe I'm reading everything.

So I am testing this accelerometer on a shaker table at varying frequencies and as soon as the shaker table is turned on, most of the values read from the FIFO are primarily either 0 or 4 with some other values mixed. As the shaker table is oscillating in a regular sine wave I would expect the values read from the accelerometer FIFO to reflect that sine wave pattern, but that's not what I'm seeing. It's almost as though the accelerometer is not spitting out values fast enough, even though the shaker table is currently only set to 100Hz and the accelerometer has an ODR of 26.6kHz and a bandwidth of around 6 khz. Not quite sure how to get the accelerometer to interface properly with the shaker table, but I feel like it should be able to work...

Thanks,

Steven

[SSedi.1]

Hi Niccolo,

Thanks for responding!

I did try setting up the STOP_ON_WTM register.

The data I read from the FIFO is okay when I read it. I have a for loop that iterates until the counter variable is equal to the value of the DIFF_FIFO_BITS so I do believe I'm reading everything.

So I am testing this accelerometer on a shaker table at varying frequencies and as soon as the shaker table is turned on, most of the values read from the FIFO are primarily either 0 or 4 with some other values mixed. As the shaker table is oscillating in a regular sine wave I would expect the values read from the accelerometer FIFO to reflect that sine wave pattern, but that's not what I'm seeing. It's almost as though the accelerometer is not spitting out values fast enough, even though the shaker table is currently only set to 100Hz and the accelerometer has an ODR of 26.6kHz and a bandwidth of around 6 khz. Not quite sure how to get the accelerometer to interface properly with the shaker table, but I feel like it should be able to work...

Thanks,

Steven

[niccolò]

Hi Steven @SSedi.1​ ,

sorry for the delay, can you check how much time do you use to read the FIFO?

maybe the problem lies in temporization.

Niccolò

[SSedi.1]

Hello Niccolo,

No worries! So on average it seems to take about 118.8 milliseconds to read and empty the FIFO completely. Does that seem to be about right? What exactly do you mean by temporization?

Thanks so much,

Steven

[niccolò]

Hi Steven @SSedi.1​ ,

with a 26.6kHz ODR, there are 26.6ksamples every second.

this means that in 100ms there are 2.66ksamples.

if you read the whole FIFO (3kB, or 500 samples) in the same time that 2660 samples are stored, the FIFO will always be full.

is it clear?

Niccolò

[SSedi.1]

Hi Niccolo,

Yes that makes sense - sorry for late the reply on my part! I realized that I wasn't using the rounding function for the accelerometers in my code for the SPI transaction, so it was taking much longer than necessary. With the rounding function, the buffer doesn't fill up nearly as quickly.

I actually have a few additional questions related to the IIs3dwb accelerometer, if you don't mind:

1) Firstly, my application calls for two of these accelerometers to be used and it is necessary for them to be basically precisely synchronized. With the current testing approach I'm using, there is a noticeable time drift between the two accelerometers. The ODR for each accelerometer is different and so over time one accelerometer tends to lag behind the other and this problem seems to get worse and worse as time goes on. In other words at the end of the test, the lag is considerably worse than that at the beginning of the test. Do you have any ideas on how to potentially synchronize/adjust these accelerometers, to compensate for the mismatch between ODR.

2) Secondly, when reading the data samples (packets consisting of the one tag byte and six acceleration bytes) from the FIFO, there are occasions when the fifo tag doesn't seem to increment numerically in a proper manner. More specifically, we sometimes see the tag value go from 17 to 20 and 18 to 23. There are obvious signs that the tag is does not increment properly and since the datasheet mentions that the tag is supposed to be incrementing 17, 18, 20, and 23. We see some differentiation from this pattern at times and thought this was kind of strange. Not sure if this means that we have something configured incorrectly or if you have any thoughts on why this might be occurring.

3) Finally, there are also occasions in which consecutive samples are copies of the same exact data - the data is repeated 2-6 times when we continuously read from the FIFO. This isn't always happening, but it happens often enough that it ruins the plots of our data. Like there are noticeable errors in the plots in that these consecutive samples are exactly the same so they just cause horizontal lines to occur in an otherwise analog signal. Do you have any insight on what could spontaneously cause this repitition of the data from the FIFO (it occurs very inconsistently, which is a bit strange).

Your help so far has been very much appreciated. Any further insight related to any of these points would be super helpful.

Thank you so much,

Steven