LIS2DS12 sampling frequency madness

[MMasu.1]

I was using an ISM303DAC as an accelerometer and everything was fine. Unfortunately, the chip was discontinued, and I had to immediately replace it with LIS2DS12 because all of the accelerometer register configurations were the same. I didn't have to rewrite the firmware this way. Everything was fine until the hardware failed in the field. None of the data made sense. Then I did a quick sanity check by measuring and comparing the data from both chips. The ISM303DAC produced consistent results and accurately measured all frequency components. The LIS2DS12 plots, which use the same firmware and analysis code, are complete nonsense, with none of the frequency components making any sense. I'm in a terrible situation. I used this chip in 100 pcbs that I shipped to another country. It is simply not an option for me to redesign and ship another batch with different sensors when the original is no longer available. Thank you in advance.

[MMasu.1]

Update: It appears that when I read data from the FIFO, the accelerometer stops collecting data. The graph below shows an example of how I read FIFO once after collecting 200 samples without issue. However, when I collect 400 samples and read 200 samples at a time, I notice a break in the signal. highlighted in red This did not happen with the ISM303DAC chip.

[Eleon BORLINI]

Hi @MMasu.1​ ,

thank you for sharing the details of your analysis.

Are the ISM303DAC and LIS2DS12 exactly the same especially in terms of ODR? And is the SPI running at the same speed?

In which FIFO mode did you configured the devices? It seems that the FIFO is stopping collecting data in the LIS2DS12 case, and then refilling the data some times later. In order not to stop collecting data, you should run the FIFO in Continuous mode and setting the FIFO threshold at 200 samples. You should start acquiring data from the FIFO before It ends filling, in order not to loose samples.

You can find some examples on how to setup LIS2DS12 FIFO on Github --> lis2ds12_multi_read_fifo.c

-Eleon

[MMasu.1]

The accelerometer parts of the ISM303DAC and LIS2DS12 are identical in every way, including the register address, acceleration range, ODR, and so on. In all cases, my FIFO threshold is 200. I've also tried other Thresholds and read the exact threshold amount. One thing I made sure of was that the FIFO did not fill up. I experimented with various threshold values ranging from 20 to 250. Because that's when I start reading from the FIFO, the FIFO update stops as soon as it reaches the threshold. The size of the FIFO has no effect on FIFO freezing. It is determined by the threshold. I used a threshold of 100 but started reading after 95 to confirm that it stops updating the FIFO when it is being read from. The disturbance will occur every 95 samples in this case, and the FIFO will have some data left over after each read. That means the FIFO will eventually fill up and completely stop updating. And the behavior I observed was exactly what I expected. In ISM303DAC, none of this occurs. The ISM303DAC FIFO performs exactly as it should. I had similar problems with LIS3DH before, but I couldn't figure out what was going on back then. But the data was skipping after every threshold value in that case too. If the watermark was set to 25, for example, I would see this behavior once every 25. For the time being, I've solved the problem in my case by overclocking my processor, switching to SPI,, and reading at a rate of 20 MHz instead of the recommended maximum of 10 MHz for the LIS2DS12. I didn't have much of a choice but to finish the reading in the time between two sample updates. When the data is being written by the accelerometer, I can't just touch the FIFO. Since the ISM303DAC has been stoked out for a long time and the LIS series has proven to be unreliable, I'm looking into other companies' sensors. At this time, all of the other new ST accelerometers are questionable in terms of availability or FIFO behavior. I'm just relieved for the time being that I was able to save the existing batch by operating outside of the datasheet limits in some way. Unfortunately, I am no longer able to continue with ST. I looked at your GitHub example and it appears to be the same. Except for those who will perform frequency analysis on the collected data, this will not apply to all users. Thank you for taking the time to respond.

[Eleon BORLINI]

Hi @MMasu.1​ ,

thank you in any case for having shared your test description and your opinion to the community.

I can say that more recent sensors such as LIS2DW12 are more accurate in terms of performances, rather than older ones such as LIS2DS12, but I catch your point.

-Eleon