• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 1671 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS1258 spikes

Galbas Portes
Intellectual 270 points
Other Parts Discussed in Thread: ADS1258

Hello!

I am using the ADS1258 single end channel. The channel 1 shows me the values bellow:

32700

32701

32700

32830

32700

32701

32303

Note: I put the channel 0 direct with ground signal.

Could you send me a code example?  I am using port I/O from a PIC32 microcontroller. I choose the scan option, but for test I am using just channel 0.

My code is:

void le_ads1258(void)
{
byte c;
byte sts;
unsigned long leit_conv;

contador_aux[0] = 0;
contador_aux[1] = 0;
contador_aux[2] = 0;
contador_aux[3] = 0;

while(1)
{
sts = 0;
leit_conv = 0;

write_ads1258(0x30);//00110000

// Le byte de status
for (c=1;c<9;c++)
{
SCLK_AD = 1; // SCLK = 1
sts *= 2;
if (DOUT_AD == 1) sts += 1;
SCLK_AD = 0; // SCLK = 0
}

// Le os 3 bytes de dados
for (c=1;c<25;c++)
{
SCLK_AD = 1; // SCLK = 1
leit_conv *= 2;
if (DOUT_AD == 1)
leit_conv += 1;
SCLK_AD = 0; // SCLK = 0
}

leit_conv = (leit_conv ^ 0x800000)/256;

if ((sts & 128) == 128)
{
switch (sts & 0x1f)
{
case 8:
if (contador_aux[0]<media)
{
somatoria[0] += leit_conv;
contador_aux[0]++;
}
break;
case 9:
if (contador_aux[1]<media)
{
somatoria[1] += leit_conv;
contador_aux[1]++;
}
break;
case 10:
if (contador_aux[2]<media)
{
somatoria[2] += leit_conv;
contador_aux[2]++;
}
break;
case 11:
if (contador_aux[3]<media)
{
somatoria[3] += leit_conv;
contador_aux[3]++;
}
break;
}

}
if ((canais_ativos & 2)==0) contador_aux[1] = contador_aux[0];
if ((canais_ativos & 4)==0) contador_aux[2] = contador_aux[0];
if ((canais_ativos & 8)==0) contador_aux[3] = contador_aux[0];

if ((contador_aux[0] == media) && (contador_aux[1] == media) && (contador_aux[2] == media) && (contador_aux[3] == media)) break;
}
for (c=0;c<4;c++)
{
leit_ad[c] = somatoria[c]/media;
somatoria[c] = 0;
}
}

Thanks,

Mr. Galbas

  • 0
    TI__Mastermind 44550 points

    Hi Mr. Galbas,

    Would you be able to share a circuit schematic and some oscilloscope screenshots of your SPI communication?

    The ADS1258 defaults to auto-scan mode, so each conversion result will correspond to a different channel. I'm not sure which channels correspond to the above data. Are you programing the ADS1258 into manual mode and selecting the input channel?

    Additionally from the code, it looks like the SPI communication is implemented with a "bit-banging" approach, however, there are no timing delays shown. I think it is very likely the the SPI communication is not working. I could check this with some oscilloscope screenshots.

    Unfortunately, I do not have any example code specifically for the ADS1258. Do you have an SPI peripheral available on your PIC32 microcontroller? You should be able to search the web for PIC32 SPI example code. I can help if you have any questions about the ADS1258 SPI command sequence.

    Best Regards,
    Chris

  • 0 in reply to Christopher Hall
    Intellectual 270 points

    Hi Chris!

    I am using only AIN0 (Auto Scan)  and you are right, is a bit-banging. I believe be a simple problem, because the PCB is ready and I have only one board working. Anyway I have tem board with the same problem, spikes during the measuring.

    It's not possible I change the used pins in PIC32. I think the problem is not time because the instruction time is 100ns. 

    Thanks

     

    00ns

  • 0 in reply to Galbas Portes
    TI__Mastermind 44550 points

    Hi Mr. Galbas,

    Thanks for sharing the schematic!

    I have two observations I want to point out:

    1. The crystal oscillator is referenced to AGND, it should be referenced to AVSS. Presently, this doesn't seem to be causing a problem if you're able to communicate with the ADS1258.
    2. I see any input buffers; therefore, if your input signal has high output impedance you might see gain errors or other noise present on the input signal. What is the input source on AIN0?

    After configuring the ADS1258 registers, are you able to read the back to verify that they are configured properly? Please tell me the register settings you're using.

    Best Regards,
    Chris

  • 0 in reply to Christopher Hall
    Intellectual 270 points

    Hi Chris!

    I referenced the crytal to AVSS but it doesn't work.  I have a operational amplifier on AIN0, and yes I have checked registers settings after write to them.

    It follows my registers below:

    canal = 1;

     write_ads1258(0x60); // CONFIG0: CONFIGURATION REGISTER 0 (Address = 00h)
     write_ads1258(0x02); // Auto scan de desliga clock de saida para diminuir ruído e consumo

     write_ads1258(0x61); // CONFIG1: CONFIGURATION REGISTER 1 (Address = 01h)
     write_ads1258(0x0);  // 1831Hz ou 0x01 - 6168Hz

     write_ads1258(0x62); // MUXSCH: MULTIPLEXER FIXED-CHANNEL REGISTER (Address = 02h)
     write_ads1258(0x0);  // Scan

     write_ads1258(0x63); // MUXDIF: MULTIPLEXER DIFFERENTIAL INPUT SELECT REGISTER (Address = 03h)
     write_ads1258(0x0);  //

     write_ads1258(0x64); // MUXSG0: MULTIPLEXER SINGLE-ENDED INPUT SELECT REGISTER 0 (Address = 04h)
     write_ads1258(canal);// Single ended (CHANNEL 0 a 7)

     write_ads1258(0x65); // MUXSG1: MULTIPLEXER SINGLE-ENDED INPUT SELECT REGISTER 1 (Address = 05h)
     write_ads1258(canal>>16);//Single ended (CHANNEL 8 a 12)

     write_ads1258(0x66); // SYSRED: SYSTEM READING SELECT REGISTER (Address = 06h)
     write_ads1258(0x0);

    START_AD = 1;

    Thanks,

    Galbas

  • 0 in reply to Galbas Portes
    TI__Mastermind 44550 points

    Hi Mr. Gulbas,

    Here are the possible causes I'm currently concerned about:

    • You're original data is around code "32700" or ~10mV. This is rather high for a shorted input. Hence, I wasn't sure if you were actually measuring AIN0. If you are measuring 10mV with AIN0 shorted to ground, then your ground is very noisy! Do you know where this 10mV signal is coming from?

    • The reference voltage is implemented with a resistor divider. With this configuration, any supply ripple or noise will also be present on the reference voltage!! This could easily cause the 400 code spike or ~127uVpp. The bulk decoupling capacitors on the output will not provide much noise filtering, and could be making the reference buffer unstable. Have you probed your reference voltage to check that it is clean and stable? 

      (With a 0V input you won't see much of the reference noise effect; however, when you apply a larger signal you may find larger spikes. A good reference voltage is critical for good performance with a 24-bit delta sigma ADC!)

    • I'd still question the SPI communication...If you are able to read back the values you're writing to the device registers, than that is a good sign. I would still want to probe the SPI signals to see if the communication is clean. One question regarding your code, what value are you writing to MUXSG1 when you send "(canal>>16)"?

    Best Regards,
    Chris

  • 0 in reply to Christopher Hall
    Intellectual 270 points

    Hi Chris,

    The spikes not depend on signal in AIN0 input. The problem happen from random way.

    I am using a load cell referenced with the same source used in A/D reference, therefore the reading is ratiometric. After many tests, I gave up and I change the A/D converter. For my surprise it works perfectly. Anyway I am lost because many boards show me this problem.

    I look the printed mark on A/D and it not shows me the traditional TI logo. Could you send me how the mark is printed?

    I am using only 16bits, so 32767 would be the middle (zero) and range is 0 up to 65535.

    MSGSG1 = 0;

    Thanks,

    Galbas

  • 0 in reply to Galbas Portes
    TI__Mastermind 44550 points

    Hi Mr. Galbas,

    You can use the following two websites to look up the part marking:

    • http://www.ti.com/general/docs/partmarking/partmarkinghome.jsp

    • http://focus.ti.com/quality/docs/gencontent.tsp?templateId=5909&navigationId=12626&contentId=153966&keyMatch=part%20markings&tisearch=Search-EN#stdfirstline 

    Ok, so code 32767 makes more sense now. However, if these spikes are still showing up on the grounded input, then it's an indication that either your ground is noisy or something is wrong with the SPI communication.

    Regards,
    Chris

  • 0 in reply to Christopher Hall
    Intellectual 270 points

    Hi Chris!

    I am so sorry for reply so late, anyway the problem still the same. I have checked the mark part and it seems ok.

    The problem is random because I used another chip and it woks perfectly.

    Thanks,

    Galbas.

  • 0 in reply to Galbas Portes
    TI__Mastermind 44550 points

    Hi Mr. Galbas,

    Have you tried a few devices and/or a few PCBs? It would be good to know if the problem was just a single occurrence or if there is some underlying cause.

    We have seen issues before where the PCB may not have been properly cleaned after soldering and remaining flux residue was creating parasitic conductive paths. (Blog Reference: Why should I give a flux?)

    Best Regards,
    Chris