2020-10-12 10:29 AM
I currently have the LSM6DS3 setup for FTH of 0xFFF, no decimation, 1.66kHz, continuous mode with FTH interrupt on interrupt 1. It seems like it is working ok - I see the FTH interrupt fire after about 400ms, which is right on time. When I read starting (SPI 4 wire) at FIFO_STATUS1, I see 0x00, 0xE0, 0x02, 0x00, then FIFO_OUT data (see scope screens). Now the FIFO is obviously full, both by the interrupt and by FIFO_STATUS2 = 0xE0, but the FIFO_STATUS1 = 0x00 means there is no data to read? Why would this be the case?
I also don't understand what the FIFO_PATTERN is supposed to be telling me. I see only that FIFO_PATTERN1 = 1 and everything else 0. I expected to see six values in here, although even if I did, I don't understand how to interpret that register even after reading the datasheet and application note. I don't get how binary values can point to multiple possibilities (XL_X, XL_Y, G_Z, etc.) Or is it just telling me what the next two bytes of data are? If so, I don't see a map from FIFO_PATTERN to 6-axes+external?
In the scope screens, green is the INT1 line, yellow is CLK, magenta is MOSI, cyan is MISO, and CS is omitted but working as expected. The first screen is to show the working INT1, the next has each byte as one horizontal division and the third has each nibble as a division.
Solved! Go to Solution.
2020-10-22 09:56 AM
I think one last clarification on this topic for anyone else who might happen on this thread: the reason that this register is necessary (since the data apparently have a default ordering) is that you might not read an entire FIFO. If, for example, an interrupt were to cause you to stop reading the FIFO buffer at some point, and the data weren't persistent, you might not know where you were in the ordering when you resumed your read. The FIFO_PATTERN register will tell you that you are on the kth read of the N different possibilities (depending on your setup), so that you can know that now the next read will be k+1, and so on up to N-1, then start over again.
2020-10-12 07:48 PM
So I figured out that if I reduce the FTH size (to, say, 2048), then I get the correct behavior for FIFO_STATUS1 & 2. I'm guessing that is because if you put the FTH too close to the buffer size, then it might overrun before you get a chance to read and that puts the counter in the two status registers to 0?
And now I get all zeros in the FIFO pattern registers - so I'm really lost there.
2020-10-13 08:02 AM
Hi @jw56 ,
Let's see if I can help you.
>> Now the FIFO is obviously full, both by the interrupt and by FIFO_STATUS2 = 0xE0, but the FIFO_STATUS1 = 0x00 means there is no data to read? Why would this be the case?
Being the b6 =1, it means that FIFO_OVER_RUN is set high because the FIFO is completely filled and at least one sample has already been overwritten to store the new data. Did you configure the device in FIFO mode (i.e. stops collecting data when FIFO is full), or in Continuous mode (i.e. If the FIFO is full, the new sample overwrites the older one? (see FIFO_MODE [2:0] bits of FIFO_CTRL5 (0Ah) register).
So, your sentence "it might overrun before you get a chance to read and that puts the counter in the two status registers to 0?" is right.
>> I also don't understand what the FIFO_PATTERN is supposed to be telling me. [...] Or is it just telling me what the next two bytes of data are?
As reported in the AN4650 application note p.115 and sgg:
"To understand which couple of data and which FIFO data set is going to be read, it is necessary to check the content of the FIFO_PATTERN_[9:0] bits in the FIFO_STATUS3 and FIFO_STATUS4 registers".
Here is described the minimum data pattern including all the sensors with different ODR (and, of course, the overall data pattern will repeat every ODR min) that repeats in the FIFO. You can find an example with an external sensor (magnetometer) in AN4650 p.107.
-Eleon
2020-10-13 03:27 PM
@Eleon BORLINI Thanks for your help. Yes, I had everything set up fine, but I had the FTH set to its maximum which ends up being the same as overrun. It's clear to me now that you simply need to leave FTH with enough space if you are in continuous mode so that it doesn't overflow if you want to get a count of the records in the FIFO buffer.
I keep looking through AN4650, but I still don't get it. I see this sentence "Data are written to the FIFO with a specific pattern (for example GyroX, GyroY, GyroZ, AccX, AccY, AccZ)." So this says "for example," but what does that mean? The phrase "for example" typically means, in the English I know, that it doesn't have to be this pattern even if the same conditions are met. If I only use the internal sensors, no decimation (so only the first two FIFO data sets are populated), will that always be the pattern? If not, then I guess I will see a "1" in FIFO_PATTERN_0 to 5, but nothing else. How do I know if that first "1" corresponds to G_X instead of XL_Y or whatever?
2020-10-15 07:13 AM
Hi @jw56 ,
The standard pattern is GyroX, GyroY, GyroZ followed by AccX, AccY, AccZ followed by external sensor X, Y, Z.
This is true if you have both Gyro and Acc activated, and you are acquiring all the sensors with the same ODR.
This pattern changes if you for example deactivate the Gyro sensor (no more Gyro tags), or you don't have an external sensor connected or you are acquiring the different sensors at different ODRs.
So, changing the sensor configuration, the data pattern will change accordingly.
The FIFO_PATTERN_[9:0] register content helps you to interpret the FIFO_DATA_OUT_L and FIFO_DATA_OUT_H registers content, depending on the data pattern you configured (e.g. Gx, Gy, Gz, Ax, Ay, Ag, no external sensor, Gyro ODR = Acc ODR). Since this pattern will repeat every N samples, you will get N-1 different values in the FIFO_PATTERN bits.
-Eleon
2020-10-22 07:46 AM
Hi @jw56 ,
do you need some other help or the information shared are enough for your purpose?
-Eleon
2020-10-22 08:34 AM
Hmm, I think we are good now, although since we have no decimation or external data, and the ODRs for our sensors are the same as FIFO, it doesn't really matter for us. I think the answer for us is that the FIFO_PATTERN only tells you where you are in the pattern, not which sensor or which axis you are on. Instead, that is standardized as Gyro first, then XL, then external - although I'm not sure I see anywhere in the app note or the data sheet that makes me 100% comfortable that this is true.
2020-10-22 09:56 AM
I think one last clarification on this topic for anyone else who might happen on this thread: the reason that this register is necessary (since the data apparently have a default ordering) is that you might not read an entire FIFO. If, for example, an interrupt were to cause you to stop reading the FIFO buffer at some point, and the data weren't persistent, you might not know where you were in the ordering when you resumed your read. The FIFO_PATTERN register will tell you that you are on the kth read of the N different possibilities (depending on your setup), so that you can know that now the next read will be k+1, and so on up to N-1, then start over again.