ADS1292: Data reading method (parallel connection)

Hi,

I will try to get back to you around 5/3.

Thanks

Hi Cafain,

Apology for the delay.

--------------------------------------

For "parallel connection", could you clarify? Is it like datasheet page 30? or something else?

For "Unexpected data is read when reading data at 500sps."  Is the issue occurring only for data rate is 500sps? have you tried 125SPS or higher?

For "Figure 34"  Ok, now I see it; cascaded. Do you make sure /CS come from different pins from the master/host? and do not pull both low at the same time?

-----------------

Before proceed,

What is your SCLK frequency or period?

have you tested with each ADS1292 individually and independently with

1. read and write and read back registers settings properly?

2. the internal test signals? 

If not, could you do above and make sure each individual one works independently first in the data rates desired?

-------------------------

"Dveice0 CLK setting CLKSEL PIN = High, CONFIG2.CLK_EN BIT = 1" ok, user internal CLK and output the internal CLK to the CLK pin.

"Set Dveice1 CLK setting to CLKSEL PIN = Low, CONFIG2.CLK_EN BIT = x" ok, use external CLK from Device0 and don't care CLK output.

------------------------

SCLK requirement is shown in page 11 section 6.6 which depends on the DVDD supplied. Could be from 15.015MHz(66.6ns) to 20MHz(50ns) depending on the DVDD. And, also note the "tSDECODE Command decode time 4 tCLKs"

Which portion of page 49 don't you understand? 8.5.2.10 Sending Multi-Byte Commands basically, the device needs some wait time(4* tCLK) between bytes - "when sending multi-byte commands, a 4 tCLK period must separate the end of one byte (or opcode) and the next."

"

When SCLK is 16 MHz(FAST), one byte can be transferred in 500 ns. This byte-transfer time does not meet the tSDECODE specification; therefore, a delay must be inserted so the end of the second byte arrives 7.3125 µs later.

If SCLK is 1 MHz(SLOW and not support), one byte is transferred in 8 µs. Because this transfer time exceeds the tSDECODE specification, the processor can send subsequent bytes without delay.

"

That's why in Figure 54 and Figure 55, on the SCLK line, you can see there are always some gaps between OPCODE 1 and OPCODE 2 and REG DATA and REG DATA + 1. 

Anyway, the idea is to let SCLK wait at least 4 tclk before rising again after each byte.

-------------------

I don't think there is a problem to setup the CLK in this way. One way you could check is to use a high speed scope to probe&monitor the both CLK pins to make sure the CLK signal are relative consistent in frequency(period) and the magnitude.

---------------------------

Once you connect the START and CLK pins the way shown in the Figure 34, both /DRDY are synchronized, so only use 1 /DRDY pin from one of the device is sufficient as an indicator/interrupt for data ready of both devices. Note, in this fashion, /CS cannot be pull low at the same time; thus, DOUT from both devices should not come out at the same time.  Cascaded, not parallel. 

----------------------------------

I don't understand the Q4 and expression. Could you explain a bit more?

------------------------------------

/CS for each device should be independent from master/host to each device.  

/CSs cannot be pulled low at the same time; only one at a time, no overlapping; thus, DOUT from both devices should not come out at the same time.  Cascaded, not parallel. 

 --------------------

Thanks