ADXL372 Eval board, getting 0x00 from DEVID

Hi Rusty81, 

Can you please double check if the SPI clock phase and polarity are set to 0? 

If this does not solve the problem, can you please send a scope capture of the SPI transaction? 

Thanks, 

Pablo

Thanks for you reply Pablo.

I think this part is dead, as I get random 0x00 and 0xFF from the lower addresses.

Just to avoid another fault:

1. Do I need pull ups/down on SCK, MISO, MOSI, CS lines?
2. Do I need to connect both grounds or one is enough?
3. Is there any issue if I power with 3.3V both VS and VIO (I will short these two if that's the case)

I'm referring to this evaluation board: EVAL-ADXL372Z Evaluation Board | Analog Devices

Thanks,

KR

S

Hi, 

1) you do not need to pull/down the SPI bus lines. 

2) one ground enough

3) you can power both, Vs and Vddio, with 3.3V. Make sure the transient when Vs goes high does not over 3.6V. This can damage the sensor. 

Regards, 

Pablo.  

Hi, thanks for your help.

I managed to make it work and seems ok, but the readings are kind of noisy, and increasing the bandwidth/ODR makes things worse.

My registers setup, at POR, is the following: (adis_write_byte(address, byte);

All registers are also read back to make sure the value has been written, read back is omitted here..

adis_write_byte(0x3C, 0x01); //INT2 map to DATA_READY

adis_write_byte(0x3e, 0x0A); //00001010, Low noise 800Hz BW

adis_write_byte(0x3D, 0x40); //010 000 0 0,  ODR @1600 Hz

adis_write_byte(0x3f, 0x1F); //000 1 1 111, Full bandwidth and HPF, LPF disabled, settle time 16ms

Interrupt is attached to INT2 pin on posedge, basically when I have a posedge I read the xyz axis and convert them to decimal, then wait for the next interrupt from dataready:

//Read x axis high nibble and low nibble
x_h = adis_read_byte(0x08);
x_l = adis_read_byte(0x09);

//Read y axis high nibble and low nibble
y_h = adis_read_byte(0x0a);
y_l = adis_read_byte(0x0b);

//Read z axis high nibble and low nibble
z_h = adis_read_byte(0x0c);
z_l = adis_read_byte(0x0d);

x_acc = nibbles_to_signed_int(x_h, x_l);
y_acc = nibbles_to_signed_int(y_h, y_l);
z_acc  = nibbles_to_signed_int(z_h, z_l);

The noise coming out is kind of constant, and increases with ODR/BW configurations.

This is just sitting on my desk with no movement:

200 BW, 400 ODR

400 BW, 800 ODR

800 BW, 1600 ODR

If I activate the LPF things don't change much, and oscillation is added on top of this noise.

Tried also selecting different filter settling times, nothing really changes.

I have a couple of questions:

1. What is the best setup to filter out some of this noise? 
2. I have a constant offset as you can see, X,Y,Z is not 0,0,-1, is this due to the fact that the power supply is 3.3 instead of 2.5V?
3. LSB variation of 0.2 0.3 g-force is expected as the maximum resolution I can get, but is that possible to clean up the signal a little bit?
4. Is data ready interrupt cleared automatically when I perform a read on x,y,z registers ?
5. Is the ODR considered per axis or per triplet? for example with ODR 400Hz I get x,y,z values 400 times per second or I get 400 / 3 ? 

I don't need any FIFO as I just need to read the acceleration values and store it as a datalogger, I know I could filter the data after the acquisition and cancel the offeset, but would be nice, if possible, to have cleaner data from the accelerometer directly.

Thanks a lot for your support.

S

On top of this, if it might be of interest, I have a weird MISO line coming out from the ADXL372.

Whilst I have no problem on writing and reading data through SPI (1 MHz at the moment) I see a weird MISO line, MOSI and CLK look good though).

Do I need to pull down the line with a resistor? Is it because of the 3.3V supply instead of 2.5? Both VI and VIO are at 3.3V on the ADXL.

MISO looking weird

MOSI looks fine

Any advice on this? I don't think is affecting the XYZ readings as I get very low oscillations around the expected values, most probably noise.

Thanks again,

S

I am glad you were able to solve the communication issue. 

the noise level that you describe is normal for this part. If you look at the specification table on the datasheet, the RMS noise is 3LSB (or 0.3g) for 3200Hz ODR, 1600Hz BW. This translate to ~2.3g peak to peak noise (RMS_noise x 6.6 = Noise_pp. 

It is also normal to see the noise decrease when lowering the BW. You can estimate the noise at different ODR using the RMS noise value from the spec table. Noise Density = RMS_noise/sqrt(1.57*BW). The 1.57 coefficient comes from the filter type (single pole). 

So Noise Density = 0.3g/sqrt(1.57*1600Hz) ~ 6mg/sqrt(Hz). 

Now say we change the BW setting to 400Hz: RMS_noise_400Hz ~ 150mg RMS or ~990mg peak to peak. 

To answer your questions: 

1)  Lower BW is the only option you have to lower the noise, as explained before. 

2) No, in the spec table you would also find that the 0g offset (the constant offset you see) can be up to +/-7g for this part. This is normal. You can compensate this using the offset trim registers (registers 0x20 to 0x22). You can find details in the datasheet. 

3) You can integrate multiple reading 

4) Correct

5) per triplet. When data ready bit is set, that means that all 3 axis data is updated and ready to read. 

I hope this helps, 

Pablo. 

There is no need of pull down resistor. That effect you see in the MISO line might be due to the large capacitance of your oscilloscope probe.  And I mentioned before the noise level you see in this part is expected. The part works from 1.6V to 3.3V supply. So this is not an issue either. 

 Pablo. 

Thanks a lot for the very detailed answers, Pablo, really appreciated.

Last clarification on the offset compensation, if you don't mind.

I see I can use a signed 4 bit value, so -8 to + 7 integers. So I could not compensate for , for example, +1.6g on the y axis, I can use only finite numbers.

At this point I think I will let run the accelerometer and take the average over time, then use that value to compensate the offset via software.

Thanks again, 

S

Hi Rusty81, 

that is correct, the offset trim is 4 bit register only, so you can do better with SW compensation. 

Good luck with your project! and let me know if you need anything else. 

Pablo. 

Hi Rusty81,

how did you manage to get the eval board to work, as I am having the same issue with only getting a 0x00 response when I read the devices id register?

Regards,

B