Sporadic wrong readings using ADXL345

Thank you for your extended use of the ADXL345 and for posting your question, in this forum.  Unfortunately, our primary expert on this product is out of the office for another 1.5 weeks, so we might be delayed in our response. I will see what I can find, but we might need to wait for my colleague, for this one.  

PdelCorro

Thank you very much NevadaMark. Looking forward to Pablo's answer.

Hi avionics_engineer, 

using the DATA_RDY bit, from the STATUS register, to synchronize the data reads should solve this issue. I think those spikes happen when new acceleration data is being stored in the DATAX, DATAY and DATAZ registers while an SPI read is requested. 

What I would do is something like: 

...
while(DATA_RDY == False):
    do nothing

read DATAX, DATAY and DATAZ registers
wait 1ms 
...

I hope this helps, looking forward for your feedback. 

Regards, 

Pablo. 

Hi PdelCorro,

We have thoroughly seached across the datasheet, especially in the Register Map section, and could not find such 'STATUS' register or anything similar. The DATA_READY flag does not seem to be available for the user in any (documented) register and is rather intended for interrupt programming. Your explanation does not apply to this device (ADXL345), so there must be something wrong...

Even if your suggestion were possible, I see the following problems:

• In the "bypass" mode "a double-buffered output allows the read to finish first and then places the new data into the output filter" (quoted from the datasheet). That means that it should not be necessary to poll any flag to check when the new data is valid; otherwise, what would be the purpose of the double-buffered mechanism?
• Assuming that the DATA_READY flag can be consulted in some of the "reserved" registers (?), trying to poll a flag using SPI or I2C can be challenging, since it would be impossible to synchronize the "readiness" of the data with the timing of the SPI/I2C transaction itself at any given clock frequency. In addition, for our real-time application, polling status flags via SPI adds unaffordable time cost.

Looking forward to your feedback -thanks.

Hi avionics_engineer, 

My mistake, meant INT_SOURCE register (0x30) instead of STATUS register (it is name that way in another product. I mixed them in my head, sorry.). 

I was not able to find the quote you mentioned on the ADXL345 datasheet:

"a double-buffered output allows the read to finish first and then places the new data into the output filter".

 Can you please share the document where you found this quote? I have requested our design team to confirm if the part does have a double buffer and I am waiting for their reply. I will circle back when I hear from them. 

The DATA_READY bit in the INT_SOURCE register is set when new data is available and cleared when acceleration data is read (registers 0x32 to 0x37). The DATA_READY bit can be mapped to one of the ADXL345 interrupt pins, which can be use to signal the MCU to start the SPI read. This is the way that we recommend for "synchronizing" with DATA_READY interrupt. Would you be able to implement this in your application? 

Regards, 

Pablo. 

Hello PdelCorro,

Apologies from the wrong reference, the quote is not from the datasheet but from the Application Note AN-1025, which you can find linked in my first post.

I understand your suggestion of setting the DATA_READY bit in the INT_SOURCE register and getting notified by an interrupt when the data is ready; unfortunately in our design the interrupt pins are not routed so this would not solve the problem in our case.

I find that the interrupt option can be useful for knowing when there is new data available. However, even using the interrupt I could still have the same problem if the DATAX, DATAY and DATAZ values are about to change when I start the SPI transaction (race condition), hence the importance of the double buffer.

Kind regards.

Hi avionics_engineer, 

sorry to hear that you cannot use the interrupt pins in your application. I know this might not me ideal, but you can also try a software approach by "synchronizing" to the DATA_READY bit by reading the INT_SOURCE register continuously. 

3200 Hz is the fastest sample rate for the ADXL345, this is one sample every 312.5us. From your original post, I see that your SPI speed is 4MHz, 1 burst read of all 3 axis requires 56 clocks, which is equivalent to 14us. So if you read the DATA_READY flag right after is set, you will not have superposition between SPI read and registers update.

I hope this helps, 

Pablo.  

Hello PdelCorro,

You are right, the continuous read operations in the SPI bus is far from ideal and we cannot afford it in our final application because we need to collect data from other sensors attached to the same SPI bus (with different chip select lines), i.e. we should therefore not overload the SPI bus for polling the INT_SOURCE register.

Since our application needs to be very deterministic timewise, all we would need is just to perform a periodical read operation (without interrupts or polling) and collect the "freshest" acceleration sample from the ADXL345 sensor. As I stated in my first post, we do have a workaround, since we are able to detect and discard a sample which is "way" out of the expected range.

Since we spotted this problem, our senior embedded engineer has invested more than two week's time in trying to solve it and collect the evidence that we have been sharing here... So to be honest, we are kindly asking someone at Analog Devices to either let us know what might have we missed in the configuration process or confirm that this is indeed a 'bug' (e.g in the ADXL345 double buffer mechanism). The problem seems to be consistent across several boards so it is relatively easy to replicate.

You mentioned you had requested your design team about the double buffer -did you already hear back from them?

Thank you very much for your help.

Hi avionics_engineer, 

One of our design engineers just confirmed that seems to be a bug in the buffer that causes this issue. 

Sorry for the inconvenience, 

Pablo. 

Hello PdelCorro,

Thank you very much for your answer. Was this a known bug in the ADXL345 then or did you learn about it after my report? I haven't been able to find an 'Errata' document explaining this (as I have seen for other bugs affecting other sensors by Analog Devices, for instance).

As I mentioned earlier, the ADXL345 accelerometer is included in one of our products, of which we have sold thousands of units already. We are testing a new firmware version that discards accelerometer samples that are "way" out of range, as a workaround, using a random threshold value that we have set. However, in our industry sector a formal justification (such as the Errata document) is required before such a change can be delivered to a customer. In addition, the Errata document typically provides some more details about the bug that could (maybe) help us improve the "out of range" detection algorithm.

Can you please advice when the Errata was or will be published so that we can consult it? Alternatively, could you please get us in touch with your design engineer to collect some more details about this bug?

Just one final note: our device has been working apparently fine with the ADXL345 for years, however we found that this bug was the reason behind a recent incident reported by one of our customers, hence our need to release a reliable firmware upgrade.

Thanks for your cooperation.