ADS1292: PGA noise impeding pacing pulse detection

The original question was truncated...

My application uses a design very similar to the TIDA-010005 reference design (www.ti.com/.../TIDA-010005) to detect pacing pulses within an ECG being sampled by an ADS1292. The problem is that when using the START pin on the ADS1292 to trigger a single conversion, there is sometimes (not always) a sharp spike in the signal across the PGA capacitor we are taking pacing pulse signal from. Obviously, this sharp spike is difficult to distinguish from the true pacing pulse. When the conversion is triggered via SPI command with START held high, this spike is not observed. Due to sampling time constraints in our design, it is not feasible to use the continuous sampling mode, or the SPI command to trigger the sampling. We must use the START pin. Please help!

Hello Jonathan, 

Thank you for your post.

Could you post some oscilloscope captures showing the pulse on the PGA output capacitors? It sounds like this is directly coupling from the START pin signal.

Regards,

Here is an example, showing START noise spikes across the PGA capacitor with a "true" pacing pulse as well for scale. The START spikes do not occur at every START command, rather at seemingly at random multiples.

Further experiments using the SPI command for START (0x08) shows that single shot sampling can be accomplished without the noise spikes caused by using the ADS_START pin. However, ADS_DRDY does not function in this mode. ADS_DRDY is constantly LOW regardless of CS, SPI_CLK, or otherwise. SPI RDATA (0x12) commands are correctly interpreted and valid data is clocked out regardless. Is this by design? Please advise. 

The above shows the ADS_START spikes at ADS_IN along with a trace for ADS_START. The "true" pacing pulse is near the middle of the ADS_IN line. Spikes are not visible for every ADS_START command which is quite confounding.

Hi Jonathan,

Thanks for the update and the screen capture. 

1. When using single-shot mode, the /DRDY pin will be masked while the digital SINC3 filter settles. This settling time is listed in Table 13.
2. When switching from continuous mode to single-shot mode, it is recommended to stop conversions first. If the START pin was taken high, you must return it low. If you've previously sent the START SPI command and you see /DRDY pulsing, send the STOP command first before changing the conversion mode.

I understand that using the START opcode is not a solution for you, so we still need to find a way to isolate the transients from coupling onto the analog input from the START pin. This may only be improved via layout. Is START being driven directly by a GPIO? Do you have a pull-up resistor on the line?

Regards,

Using the START opcode is acceptable if we are able to issue the START opcode to two ADS chips at once. We have tried several methods summarized below:

A) Send START opcode to each ADS chip in sequence with START pins held low. ADS chips sample and collect data, DRDY functional. However, samples from both ADS chips are not simultaneous.

B) Send START opcode to both ADS chips simultaneously by setting both CS pins low. START pins held low. ADS chips do not sample and collect data. Respond with 0xC00000000 when issued RDATA command sequentially. DRDY is always high.

C) Send START opcode to both ADS chips simultaneously by setting both CS pins low. START pins held high. ADS chips sample and collect data. DRDY is always low.

Regarding the START pins, they are directly connected to the uProcessor GPIO, no pull ups or down. Adding a series resistor does not eliminate spikes due to START pin transition.

Hello Jonathan,

B) is the correct way to use the START command. In order to synchronize the conversions with the START command, both devices must use the same master CLK signal and receive the START opcode at the same time. Are you sharing one CLK source? Either both devices will need to connect to the same external CLK, or the internal CLK of one device must be output to the second device. To use the START opcode, both devices would share DIN and both START pins remain low. 

You mentioned the data coming from the device with the RDATA command starts with 0xC00000. This is expected. The first 24 bits are the STATUS word, which precede any channel data. Remember to send SDATAC before using the RDATA command.

Understood about the START pin connections. It really sounds like there is some significant noise coupling onto the ground plane. If it cannot be mitigated with any R-C filtering, I suggest sticking with the SPI command.

After following the initial power-on-reset startup sequence, the order of operations to get your system set up would be:

1. Hold START pins low
2. Send SDATAC (11h) to both devices
3. (if necessary) Reconfigure CLK pin of Device 1 to output the internal clock signal and connect it Device 2 (CONFIG2[3] = 1). Device 1 must use CLKSEL=1 to select the internal clock, while Device 2 must use CLKSEL=0 to use the external clock.
4. Change mode to Single-Shot (CONFIG1[7] = 1) for both devices
5. Send START (08h) to both devices
6. Monitor /DRDY falling edge (either device)
7. Send RDATA (12h) to read the data. You'll need to deselect one device while you read from the other if they're sharing the same DOUT connection to the host.

Regards,

Both devices share DIN and DOUT, but are using internal clocks independently. Why is shared clock necessary? It would seem that as long as we were OK with having simultaneous sampling within the error between the two clocks we would be fine. Clocking in the START opcode (08h) via shared SPI_CLK with both CS pins low would seem to work. But it doesn't.

To clarify, my intention is to repeat steps 5,6 and 7 at a fixed rate to effectively control the system sample rate. While holding START low. Is that correct?

I've configured the chips as advised, including setting ADS1 to output CLK to ADS2. The behavior is unchanged. Both chips respond with 0xC00000000 when RDATA is issued and DRDY is high for both chips at all times.

If instead of pulling CS low for both ADS chips we only pull CS low for ADS1 when issuing the START opcode, then ADS1 will send 0xC00000000 when issued RDATA, but ADS2, which has not been issued any START command will respond with seemingly random data when issued RDATA in turn. Additionally, neither of the chips asserts DRDY. Any suggestions?

For reference, here are logic analyzer traces for sending START commands individually, where DRDY are asserted and RDATA collects true readings.

And here is a logic analyzer trace with pulling both CS pins low. No DRDY assertion, all RDATA commands return 0xC00000000.

Hi Jonathan,

Firstly, sharing the two clocks is absolutely necessary in order to synchronize conversions. The data rates will be the same if both devices are using clocks with the same frequencies and if the two devices have the same register settings to configure the delta-sigma modulator and digital filter OSR. Then you are correct - the only differences in data rates will come from the clock frequency tolerance. However, this is not what we mean by synchronized devices. Synchronized devices will complete their conversions (i.e. @ 500 SPS) at precisely the same moment.

The modulator samples the inputs at a rate of fMOD = fCLK / 4. The data rate is calculated as fDR = fMOD / OSR.  If you use the OSR of 512, for example, there will be 512 x 4 = 2048 clock periods per sample. Assuming the clock frequency is the default 2.048 MHz, the two devices' samples could potentially be 1 ms apart. The purpose of the START pin or command is to synchronize the two devices' conversions to the same clock edge. Hence, both devices must receive the command or pin signal at the same time.

I need you to please confirm that you are following the startup suggestions I provided earlier. We must validate that at power up, the device is in a proper default state. You can send the SDATAC command and read back the register map from each device to verify this. Figure 44 shows an example routine. If you can start up both devices, pull their START pins high, and observe /DRDY on both devices, we know that they are still functioning. Then you may proceed with stopping conversions, changing the mode to single-shot, and testing a single conversion by sending the START command and waiting for /DRDY to follow. Remember to wait the required tSETTLE after the command before expecting to see a /DRDY falling edge.

I also do not understand why you are only reading 36 bits instead of the full 72. Each device outputs 24 bits of STATUS, 24 bits of CH1 and 24 bits of CH2.

Regards,

Hi Jonathan,

I hope you had safe and enjoyable 4th of July weekend.

I'm very happy to hear that you were able to resolve the issue! As far as the possible 1-ms delay is concerned, I think I was operating under the assumption that both devices' CLK and START signals would be separate (i.e. CLK1 and START1 vs. CLK2 and START2). Which I realize was a silly mistake as your entire endeavor as involved a common START pulse or command. Given that START is received at the same time, the only difference in delay should come from when each device recognizes the START pulse/command, which should be no more than one CLK period at worst.

Let us know if you need more help in the future. Best of luck!

Regards,

One last question. As discussed, we have DOUT for both ADS chips shared on the host processor SPI bus MISO line. The workaround we have implemented to force CS low for both ADS chips to clock in the SPI Start opcode has both devices asserting data on the MISO line via their DOUT pins at the same time, a collision. The data coming out during Start opcode appears to be somewhat random when done sequentially (each CS pin pulled low in turn) such that when both CS pins are low at the same time the ADS chips may be colliding on DOUT/MISO and trying to fight to pull MISO high or low. Will this damage DOUT? It has not in practice, and we do not care about the data on MISO during Start opcode. Suggestions? On the next board spin we have the opportunity to make hardware changes, what is the preferred solution that will not require additional control lines? A large series resistor to limit current would impact reflections/ringing perhaps, a diode would impact line voltages. If the ADS DOUT pins are able to tolerate bus collisions like this, is it acceptable to leave as is or will long term failures be anticipated? Thanks!

Hi Jonathan,

I don't believe bus contention issues will cause any damage to the device, but I cannot say for sure. This is not something we test for over extended periods of time. We do test the digital output logic levels at +/- 500 uA. If two DOUT pins were connected and momentarily in contention, there could be at least 500 uA flowing from one to the other. This does not violate the Absolute Maximum Ratings (100 mA. momentary). At some point, the output stage of the DOUT pins will be limited by the amount of current it can source/sink and the voltage will droop to a level between VOH and VOL.

The ideal solution, without adding control signals, would be to daisy-chain the output data. This would utilize only one MISO line on the controller. Both devices would be controlled by the same /CS and DIN signal at all times for sending START, writing registers, and reading data.

Best regards,

Unfortunately, our declaration of victory was premature. Due to hardware instrumentation limits, we observed clean signal across PGA capacitor prior to verifying DRDY function, and once DRDY function was correct we had yet to conduct PGA capacitor measurements, assuming that the PGA signal was still clean. Not the case.

Yes, we have forced the two ADS chips (ADS1=ADS1292, ADS2=ADS1292R) to behave as indicated on the datasheet, with each asserting DRDY correctly in response to a simultaneous START opcode over SPI by pulling both CS pins low. However, much like when we used the START pin to do the same, spikes appear across the PGA capacitor in concert with the START opcode. In fact, now that we've eliminated the code issue that restricted proper SPI communication of the opcode we have reverted to a sequential START opcode approach that also gives spikes across PGA. Several key points:

1. When CS timing is too fast when sequentially sending START opcode (ADS1, then ADS2), ADS1 will not assert DRDY correctly, but will continue to convert and send real, correct data samples via RDATA opcode. No PGA spikes observed.

2. When CS timing is adequate when sequentially sending START opcode (ADS1 then ADS2), both ADS chips will assert DRDY correctly. PGA spikes observed.

3. When CS timing is adequate when sequentially sending START opcode (ADS2 then ADS1), both ADS chips will assert DRDY correctly. MUCH worse PGA spike behavior observed.

4. When CS timing is too fast when sequentially sending START opcode (ADS2, then ADS1), ADS2 will not assert DRDY correctly, but will continue to convert and send real, correct data samples via RDATA opcode. MUCH worse PGA spike behavior observed.

4. When CS is asserted simultaneously when sending START opcode, such that both ADS chips assert DRDY correctly, PGA spikes observed.

Ideas? When the ADS is not asserting DRDY but responds with seemingly real data when the RDATA opcode (single shot, SDATAC) is issued, what is the ADS sending? Why does the order of ADS1 or ADS2 impact the noise? It almost appears as if ADS1 is the source of the noise and is perhaps bad. However, we've observed the noise spikes on other boards too so it must be a difference between ADS1292 and ADS1292R or our board design. This is a tough issue to pin down. We welcome any additional thoughts.