ADS1241 Registers

Hi Hamid,

Your code appears to be ok, but it is unclear as to what is returned from the spi.write() command.  The best way to troubleshoot this is to use an oscilloscope or logic analyzer to make sure that you are reading and writing with the correct SCLK phase/polarity and timing.

The delay time between the RREG command and the data to be transferred to the output register is 50 tosc periods minimum (t6 from Diagram 1 on page 6.)  This will depend on the clock crystal or clock input used.  If 4.9152 MHz is used, this time delay is a little over 10us.  It will scale depending on the speed of the master clock used.

Best regards,

Bob B

Hi Bob,

Thank you for your response. The  spi.write() command is meant to do the following,

1. Tell the SPI bus we are writing (or reading) to this specific register

2. Define the number of bytes - 1,  we will be writing or reading.

3. Send the  byte (or bytes) to be written, one byte at a time.

If I am reading a register, then,  I will send zeros, and read what is sent back to a variable.   MUX0REG = spi.write(0x00);

 But again, I get all zeros.  (1)  Is this how SPI work with this chip?

Hi Hamid,

Are you making sure that CS is low throughout the entire communication transaction?  Can you show me scope shots of the communication so that I can analyze?  I would like to see CS, DIN, DOUT and SCLK.

Best regards,

Bob B

Hi Hamid,

Take another look at the ADS1241 timing diagram on page 6 of the datasheet.  For POL equal to 0, the data must be stable on the falling edge of SCLK.  You need to adjust your controller clock phase for the correct clock edge (changes on rising edge and stable on falling edge.)

It also looks like the DOUT is either floating or noisy.  Double check and make sure you have solid connections.

Best regards,

Bob B

Hi Bob,

The connectivity is there as far as Dout on ADS1241 to MISO pin. Could you please elaborate on the point regarding the timing diagram. Given the period of the clock (2.034e-7 s), I can find out the right range for t12  - t15 ranges from the diagram 1.  How do I apply these values to read any register and eventually the data register?

Thank you for your response,

Hamid

Hi Hamid,

It is much easier to give the RESET command than to write the reset pattern.  But before you can issue commands you need to change the phase in which the data is sent out.  The data must remain stable on the falling edge and change state relative to the rising edge.  I believe that the ADS1241 is not responding with the correct output data because it doesn't understand what you are trying to communicate to it.

Best regards,

Bob B

Hi Bob,

It seems like you see a problem with clock phase. I did reset the chip by pulsing the reset pin and  have tried both polarities ( 0 or 1) without getting a response. Will you please let me know how do I change the clock phase?  

Regards,

Hamid  

Hi Hamid,

Mode 0 has the wrong phase, you need mode 1 for POL at 0.  I'm also confused by your clock frequency.  Did you mean the master clock input is 4.9152MHz?  If that is the case, the smallest period for SCLK is 4 tosc, which for 4.9152MHz will be 814ns.  This translates to a maximum frequency of 1.2288MHz for SCLK.  From your previous plot you were well within this frequency, so that is why I'm confused.

I think the problem is you are running mode 0 and should be running mode 1 from the micro.

Best regards,

Bob B

Hi Bob,

Thank you for your response. I changed the spi mode and freq. to 1 and 1MHz respectively. The DRDY pin(27) is always high and the chip still does not respond.

Best regards,

Hamid

Hi Hamid,

Please send me your schematic.  For the device to properly operate you must have the required supplies, you must attach a crystal or supply a clock to pin 3, and the appropriate voltages should be applied to the digital pins. Pins 5, 6 and 7 must be logic high, and the remaining digital pins connected for the desired operation.  If you don't see DRDY (pin 27) toggling most likely one of the previous conditions are not met.

I would also like to see a new scope shot of the communication to verify it is now correct.

Best regards,

Bob B

Hi Hamid,

What about your other digital pins?  Did you verify those at the pins of the ADS1241?

Best regards,

Bob B

Hi Bob,

 Yes, they are measured at the ADS1241.  Thank you for the note on the pins   PDOWN and DSYNC. They were floating before but after setting pins 5, 6 and 7  the chip comes alive. Now I have to be able to do RREG and WREG. The tosc for the 1MHz frequency I have chosen is 1uS, so the t6 = 50uS. I do put this delay between my write and read commands to see if I actually wrote what I needed to the MUX register but it does not work.  Table IV shows two bytes to be sent on SPI bus:  OP code and 2nd command byte. That's what I am doing bellow  but still can't read what I wrote to the MUX register. Is there a sample code for this chip that I can look into?

Kind regards,

Hamid

  spib1 = spi.write(0x51);                 //  write to MUX register    

spib2 = spi.write(0x00);                // number of register to be written -1    

 spib3 = spi.write(0x44);                // read AIN4        

spib4 = spi.write(0x11);                 //  read to MUX register     wait(50e-6);    

 MUXREG = spi.write(0x00);                // number of register to be written -1    

 pc.printf("\r\n spib3 = %x spib4 = %x, MUX = %x  \r\n", spib3, spib4, MUXREG);

Hi Hamid,

The fosc frequency is the oscillator frequency of the external crystal.  Tosc is equal to 1/fosc (where osc refers to the crystal oscillator.)  The maximum SPI SCLK frequency relates to 1/(4*tosc), or 1/4 of the crystal frequency which is about 1.2MHz as you have said.

All timing in the datasheet (unless given as an exact value) relate to the tosc period which is not the same as the SCLK period. So the t6 delay is needing to be at least 50*tosc.  Your value of 50us is more than enough delay, but could be much shorter.

Best regards,

Bob B

Hi Bob,

Thank you for your response . The timing table  shows t6 = 50Tosc = 10.17uS, while what I get on the scope is 1.5uS. Please see the screen shot bellow.

I tried reading all registers first before writing to them. The RREG command in table 4 shows the OP CODE and 2nd command byte. The questions is what should be the 3rd byte?  I tried spi.write(0x00) as the 3rd byte, but that did not work. I also  looked into the zip file for an answer but they are using I2C there. In the past I have send NOP spi.write(0xFF) which worked for another chip, but that is not helping here either. Could you please let me know what does this chip expect as a 3rd byte to read register(s).

Best regards,

Hamid

Hi Hamid,

Do you have a scope picture of the read data?  What do you expect and what are you getting back as results?  Is your reassembled data matching the scope data? 

You may also want to increase your delay slightly to make sure you are within the operating tolerances of both your microcontroller timing and the crystal for the ADS1241.

Best regards,

Bob B

Hi Hamid,

I'm not quite sure what you are trying to show me with the scope shot.  You are writing 0 to the MUX register and reading back 0.  I'm more interested to see if you can read back the default values of the registers (or at least write something non-zero and read back.)

Best regards,

Bob B

Hi Hamid,

You are writing and reading correctly to the ADS1241.  Your serial protocol analyzer is reading the data on the wrong clock edge (incorrect phase.)

Best regards,

Bob B

Hi Hamid,

The timing looks correct.  Do you have a schematic that I can look at?  What value of reference voltage are you using?

You are getting 996 codes for what ever value reference you are using.  According to the MUX register setting you are shorting the inputs, so you would expect to see 0 code (+ noise and offset.)  If you have not issued a SELFOCAL, then I've seen shorted inputs as high as 2000 codes of offset, so for shorted inputs you are in the correct range.

As the ADS1241 measures one input relative to another (differential measurement) you need to select your MUX appropriately.  AINP (positive) and AINN (negative) cannot be connected to the same channel for a measurement (otherwise you have shorted inputs which is 0.) 

Let's say you want to make a single ended measurement for AIN1 and you connect the 0.7V to this input.  If you connect ground (or common for the voltage applied) to AINCOM and write 0x18 to the MUX register you should see the correct voltage output code.  0x18 selects AIN1 as the positive input and AINCOM as the negative input.  You will receive a measurement relative to the difference of the two inputs.  In this case you will get a positive result as AIN1 is more positive than AINCOM.  If you switch the MUX so that you write 0x81, then you will see a negative value returned as the positive input is less than the negative input.

Best regards,

Bob B 

Hi Hamid,

Now that we have the digital portion working we can concentrate on the analog portion.  One thing to keep in mind is the measurement is always a differential measurement no matter if it is connected as a differential input signal or a single ended signal.  What makes the two measurements differ is with respect to range.  With a differential input voltage you can have a + or - measurement swing, whereas the single ended input voltage can only have a + result.  The method used for setting up the MUX for the measurement are the same for both where the AINPOS and the AINNEG must be connected to something.  According to your schematic, you can make a measurement when AINPOS is connected to AIN0, AIN2, AIN3, AIN4, AIN5, AIN6 or AIN7.  AINNEG can be connected to either AIN1 or AINCOM.

You must make certain that the value used for your calculation matches the actual reference value used.  You stated you used 2.048V but the schematic shows a REF5025 which is a 2.5V reference.

I'm not sure how low of an impedance your source voltage is, or how stable the voltage is relative to 100 ohm resistor.  The 100 ohm resistor can self heat and change value and can also have drift and be noisy.  You might see more stability if you add a cap from the input (at the pin) to ground of about 10nF.

Depending on the AVDD supply value, you may see issues if you are using the ADS1241 with the buffer enabled.  You have a restricted input range with the buffer enabled.  It will be better to have the buffer disabled when making single ended measurements.

Board layout is also critical for getting low noise and stable measurements.  See the following information about board layout:

http://e2e.ti.com/support/data_converters/precision_data_converters/w/design_notes/1302.general-pcb-layout-questions.aspx

Best regards,

Bob B

Hi Hamid,

If you short your inputs and then take a series of successive measurements and plot them you will see the amount of noise in the conversion.  If you do not get the kind of results shown in the Typical Characteristics Noise Histogram graph shown at the top of page 9, then you have some more work to do cleaning up the noise issue.

If you are able to achieve these results, then you should have a more desirable response.

Best regards,

Bob B

Hi Hamid,

There are a number of ways you can short inputs.  You can make external physical connections, or assign the mux to the same AIN channel for both + and - input channels.  In either case you need to assign the mux channels to the desired inputs.

The histogram plot is usually codes, which can be converted to volts if you want for the X scale.  In the case for the datasheet figure the plot is in parts per million for a full-scale reading.  Each code bin is 0.5ppm of FS in width.  The values collected would be added to each code bin and then graphed appropriately.

If you have not worked with histograms then it may be easier to deal with the effective resolution or noise graphs shown on page 7.

Best regards,

Bob B

Hi Hamid,

The graph discussed is normalized, so it all depends on your operating conditions with respect to reference and gain selected.  I think it will be easier to think in codes and distribute that way.  Once you have determine one sigma, you will have the RMS value and then take that number and convert to voltage or you can determine the total number of bits for the noise of one sigma and subtract that from 24 to find the effective resolution. 

For the latter case, let's say the one sigma of distribution is 48 codes.  The number of noise bits is ln(48)/ln(2) or about 5.58 bits.  You subtract this from 24 to get the effective resolution.

When using voltages, the effective resolution is equal to ln(full-scale range/RMSnoise)/ln(2), and you should get the same number of bits in either calculation.

Best regards,

Bob B

Hi Hamid,

To maximize your throughput you need to make sure your mux change happens within the t17 period.  That doesn't give you much time, and in fact doesn't work well if you are polling the DRDY status.  You should be using DRDY as an interrupt to your processor and the ADS1241 operating in RDATAC mode where the data is automatically placed to the output register. You can read the data and write the register at the same time with RDATAC mode as the SPI bus is full-duplex.

It is also possible to not use RDATAC mode, but you will have to write the register first for the mux change and then read the data results.  You still need to make sure the mux change happens in the t17 period, and the only way I know that you can safely do that is with an interrupt driven system.

Best regards,

Bob B

Hi Hamid,

I think you are missing the point on the usage of RDATAC.  RDATAC automatically posts the results to the output register.  As soon as the ADS1241 sees SCLKs it will start to send out the conversion results.  When using RDATAC, you send 3 NOPs to read the results, then you can read the data from other registers if you like.

I think it may be easiest for you to not use RDATAC, but rather:

1. Write the MUX change
2. Read the MUX as verification (if necessary)
3. Read the data

I think that might be easier to follow.

Best regards,

Bob B

Hi Hamid,

Engineering is fun, right? It is stressful trying to get things to work the way we want, but then it is a great feeling of accomplishment when it is finished.

Here is the total process:

1. Poll DRDY (better to use a controller interrupt, but we can work with polling) and wait until it goes low
2. Write the register to change the MUX to the next input
3. Wait 4 tosc periods
4. Send RDATA command
5. Wait 50 tosc periods for results to be placed in the output register
6. Read three bytes of the result data
7. Loop back to item 1

What needs to happen as soon as possible at the end of the conversion cycle is the MUX change so that the next conversion is accurate.

I hope that explains the process a little better.

Best regards,

Bob B