ADS1220: periodic corrupt data reading (multiple SPI?)

Hi Marc,

Welcome to the forum!  There are a couple of possibilities as to procedure issues.  One is I would make sure I brought CS high for the ADS1220 before setting CS low for the SD card reader (and vice versa).  Another possible issue may relate to how the data is assigned to the variable.  The output of the ADS1220 is 24-bit binary 2's complement.  When assigning this variable to a signed 32-bit integer, it is often overlooked that the MSB is handled properly.

I suspect that at some point in your assignment that the variable may not be cleared to a zero value at the beginning of the data read from the ADS1220 and the MSB holds erroneous data. 

You must also make sure that the SPI RX buffer is cleared prior to reading the data from the ADS1220.

As a troubleshooting tool, I would verify that my communication is as you expect by using an oscilloscope or logic analyzer on the SPI communication lines.

Best regards,

Bob B

Hi Bob,

Thanks for your suggestions,

I have changed the order in which I set CS for SD and ADS to high or low. It doesn't make a difference, but it's more logical.

I've also changed the program so the variable is cleared before each data read from the ADS, but here also no difference.

I find it very strange that the MSB gets set to 1 every other second or so, but only if I write to the SD card.

(I write every measurement to SD (+- 10hz), but only 1 measurement per second is wrong)

As an experiment, I switched the wiring so the measured voltage is negative, and here the MSB is not switched. (all data readings are negative and look ok)

I don't have a logic analyzer, but I'm going to replace the ADS and the SD reader as first steps.

Maybe some other things I could check?

Thanks,

Hi Marc,

It does appear to be something related to clock edge timing.  From the data the MSB is moving from 0B to 8B.  You need to make sure that the timing for SPI communication is not violated.  In particular the falling edge of CS to first rising edge of SCLK.

What is the SCLK frequency you are using? As the reading alternates at specific intervals, is there any other particular action taking place aside from the SD card?  Maybe something timer interrupt driven that might interfere with communication?

Best regards,

Bob B

Hi Bob,

I got a logic analyzer from a colleague, and took some pictures.

Usually the wave form looks like this;

But sometimes like this. (I'm not 100% sure, but I tink this one is wrong.)

The SPI settings for this were speed: 40.000, MSB first, mode_1. I don't know what 40.000 exactly means, but the pictures have 32 microseconds / div.

The speed was previously higher, but I lowered it to get a better picture.

I also tried something else;

When I "really" write to the SD card (as opposed to the softwarebuffer), I always see the following wave form. All The readings also look good.

Maybe the periodic thing I initially saw is somehow related to the buffer filling up.

Fyi, bit2 = DREADY, bit4 = CS, bit5 = DOUT/DREADY, bit6 = DIN, bit7 = SCLK

Do these pictures help to see what's wrong? I don't have any experience with it.

Thanks in andvance,

Best regards,

Marc

Hi Marc,

The pictures show something very interesting.  For the ADS1220, the SCLK rising edge changes the data and should hold on the falling edge for the data to be latched on the falling edge by the micro.  Note on bit 5 (DOUT/DRDY) that the msb clock (first clock) is transitioning on the falling edge when the data is incorrect.  Logic analyzers do not show the exact voltage value, but rather a logic value so we don't know if something is changing on the clock edge or if there is some other possible interference.

My next questions relate to whether you have a pullup on the DOUT/DRDY line?  And when does CS go high for the SD card?  Also, if you can send me your schematic and ADS1220 device configuration that would be helpful as well.  

Best regards,

Bob B

Hi Bob,

Thanks for your fast reply,

I wanted to report you already that I think I made some progres; I had an idea the SD library is somehow wrong and I changed it.

The result looks quite promising at first sight, there are no more wrong readings.

Especially the second picture here looks interesting because it shows bit5 low at the beginning, in my previous post, bit5 was always high.

I don't know if I have a pull up / I only know I didn't add it. Do you think it's bether?

I will do some testing tomorrow, but I think this might be it. I will also check your other suggestions.

Have a nice day,

Best regards,

Marc

Hi Marc,

Most likely there was some specific issues related to communication contention between the two devices.  I wouldn't make any hardware changes at this time as most likely this is something related to timing or code sequence.

You stated you suspected something was wrong with the SD library, can you share what your suspicions were and what changes you made?

Thanks,

Bob B

Hi Bob,

I had the program with the new SD library running over night, and the "MSB switch" didn't happen.

The "bad" library in question is the standard Arduino SD library. I replaced it with "SdFat" from Greiman.

If we can assume the 2 wave forms from my last post are correct, the second and third from my first post are wrong. By some coincidence only the second gives wrong readings. I think the second waveform happens when the software buffer is full, and the third when you "flush" the buffer by hand. Of course this is just speculation from my side, and also a bit useless since Greiman has already solved this a long time ago.

Actually, I would expect the third waveform also to give bad results, but somehow it doesn't. Is the data transmitted somewhere after the falling edge and before the rising of the next clock? I suppose I could check the datasheet for this, but I got the feeling you know this by heart :)

Best regards,

Marc

Hi Marc,

For the ADS1220, the data in the output buffer is latched on the rising edge and is fully valid on the falling edge of SCLK.  In your error condition there appears to be some contention of the DOUT line as the result does not follow what is expected.  Apparently your new driver code eliminates this contention.

Best regards,

Bob B