• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 18 subscribers
  • Views 338 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.

MPC508: MPC508AU/1K glitch issue Charge Injection

LAKSHMI PRIYA C
Prodigy 250 points
Part Number: MPC508
Other Parts Discussed in Thread: OPA2277, TMUX4051, MUX36S08, MUX508, TMUX7308F, , DAC8820

Hi,

 We are using DAC8820ICDBR part in our design that provides boipolar output(+/-10V). The connections are given as recommended in datasheet. When the voltage output of the DAC (after passing through the transimpedance amplifier OPA2277) is given to LF356MX and then to MUX MPC508AU/1K. Pls refer the img below:

 

The issue here is, we observe a glitch in MUX input which is considerably reduced when we adjust mux enable timing. Can you pls let us know why does this MUX behave like this and how to resolve them?

  • 0
    Guru 267550 points

    You have not shown an oscilloscope trace of the glitch. I suspect this might be caused by charge injection; see [FAQ] What is Charge Injection?

    The MUX36S08 mentioned in the FAQ would be a ±10 V, 8:1 switch with lower (but not zero) charge injection; also consider the MUX508 or the newer TMUX4051.

  • 0 in reply to Clemens Ladisch
    Prodigy 250 points

    Please find the scope shots below when MUX enable width was 56us:

     When we give 10V and -10V alternatively, the DAC output after OPA2277UA is 

    The same waveform when given as input to MPC508AU/1K after passing through LF356MX/NOPB is    Note : Yellow - Mux enable; Light blue - Mux input; Dark blue - MUX output(10V); Pink - MUX output(-10V)

    When the MUX enable width was adjusted to 32us:

    DAC output is 

    MUX behaviour is 

    From the snip above, we observe that the input to the MUX is proper when enable width is 32us. 

    We are unsure about how the MUX input responds to the change in MUX width. We could see that the glitch is reduced considerably. 

    Please help us on the above observation.

  • 0 in reply to LAKSHMI PRIYA C
    TI__Mastermind 26483 points

    Hey Lakshmi,

    It is interesting that a higher frequency would be better. Can you share more on the input and output of the mux? I see that the LF356MX going into the mux but the schematic doesn't show the other side.
    Additionally, this mux has a pretty high on resistance at the input. There are built in resistors on the input so the on-resistance is 1k. Was this purposefully picked? Would something like the TMUX7308F be better? It's a newer device with more built in protection features and a lower on resistance.

    Thanks,
    Rami

  • 0 in reply to Rami Mooti1
    Prodigy 250 points

    The output of MUX goes to a sample and hold circuit. Yes, this MUX part has been purposefully picked for our application. Could you please help us clear on what the issue exactly was? And what can be carried on to avoid such issue? What does the mux enable width timing has to do with mux input?

  • 0 in reply to LAKSHMI PRIYA C
    TI__Mastermind 26483 points

    Hey Lakshmi

    The pulse enable timing shouldn't impact the switch when the timing is this large. The transition time is on the order of nanoseconds while you're switching on the order of microseconds. Is this something you're observing across multiple muxes? Can you try replacing this mux with a new one? 

    Thanks
    Rami

  • 0 in reply to Rami Mooti1
    Prodigy 250 points

    We are using 4mux in the design. And all 4 are behaving like the same. We have used this mux to meet our requirement. Any other possibility to resolve this issue?

  • 0 in reply to LAKSHMI PRIYA C
    TI__Intellectual 1126 points

    Hey Lakshmi

    What supplies are you using on the MPC508? With the overvoltage protection feature on this device, I would recommend operating with some headroom, like +/-15V supplies.

    Additionally, the MPC508 is very high resistance (1k Ohm) and as a result may need a lot of settling time for the switch. See the plot below. 

     

    Like Rami mentioned, the new TMUX7308F comes in a smaller package, has higher overvoltage support(+/-60V), and <1/4 the on resistance, which should help with settling time. 

  • 0 in reply to Stephen Scheramic
    Prodigy 250 points

    Hi Stephen,

     Am using +/-15V supply for this MUX. Also, we can't replace this MUX as it is our requirement. Any idea on how the MUX enable width impacts the MUX input? Hope you were able to go through the scope shots attached in the previous chat.

  • 0 in reply to LAKSHMI PRIYA C
    TI__Intellectual 1126 points

    There is no direct impact to the MUX input from the MUX enable path as these are passive not active devices? But like I mentioned the MPC508 does have a very long settling time which may explain the behavior you are seeing. 

    What are the requirements for the multiplexer in this system? I know you mentioned this MUX is your requirement but we have many new fault protected and over voltage protected devices as well. 

  • 0 in reply to Stephen Scheramic
    Prodigy 250 points

    Let me explain the design. We have used DAC8820 as mentioned initially in this forum. The output from the DAC is given to MUX. (Here, in our case we are using as De-MUX 1:8) The output of the DAC refreshes every 64us to provide next channel output to MUX. IF it is so, please let us know the MUX enable timing (both ON time and OFF time of the MUX). 

  • 0 in reply to LAKSHMI PRIYA C
    TI__Intellectual 1126 points

    The MPC508 has a 0.5us enable time, but in the typical performance curve, you can see that the settling time can be much higher, up to 100us, depending on the source/load impedance. This is because the MPC508 has a very large on-resistance, 1500 Ohms.

    The TMUX7308F has an enable/disable time of 0.35us. But the On resistance is much lower, 180 Ohms. So the settling time should be nearly 10x better.