LIS2DH12 sensor - strange 1.6 second long sawtooth pattern in reading times

[Tim9]

I am using an LIS2DH12 sensor with an esp8266 via I2C. It is the only sensor on I2C. I have a process loop that repeats every 200ms. During this loop, it is recording some other pin inputs and analog inputs, and sending the data to another esp8266 via serial.

With the LIS sensor commented out, the maximum loop time is 5ms.

With the LIS sensor reading active, and reading it every 200ms, the maximum loop time including the LIS reading varies from 10ms-45ms. So the LIS reading is taking between 5-40ms.

My question: There is a strange pattern over the span of 1.6 seconds. Consistently the loop time progresses 45-41-36-31-26-21-16-11ms, only to repeat again 45-41-36-31-26-21-16-11ms.

What is causing this pattern? Is the sensor itself doing something in this 1.6 second time period?

Thanks!

[Tim9]

I've been playing around with the ODR speed and FIFO.  regardless if the FIFO mode, it does not seem to be using the data in the registers.  I am using the sparkfun library.
On 1 out of 8 loops, i am lucky and right after i call the getaccel function, the ODR comes with a new dataset to send. on the other loops i have to wait for the new dataset.  Worst case 1000/ODR rate milliseconds.  it does this regardless of setting bypass or FIFO or stream.
Setting ODR to 200Hz solves my problem, as the worst case wait is only an extra 5ms, but it seems like a very crude way to fix it, as it is wasting 39 measurements every loop just to be ready with 1 for me to call right away...

[Tim9]

The issues seems a mis-match in the sparkfun library:  

the library file has functions getX, getY, etc. to get the data.  they include a check if the data is fresh or not, and this does not seem to be working properly.

float SPARKFUN_LIS2DH12::getX()
{
if (xIsFresh == false)
{
waitForNewData(); //Blocking wait until available
parseAccelData();
}
xIsFresh = false;
return (accelX);
}

I read at intervals of 200ms, and with the ODR at 10hz, there should always be a fresh data available. But it doesn't recognize it, and waits 1-100ms for a new one.

The same when i set the ODR to 25Hz, though of course the wait time is reduced to 1-40ms...
The synchronization and sawtooth pattern is somehow still linked with the fifo register somehow, even in bypass mode,  giving the saw toothpattern in a period of 32/(ODR rate-sample read rate) seconds.

I deleted the check in the library file, and then it worked fine, giving new data right away even at just 10Hz ODR.