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.

PGA280 input bias current when saturated

Other Parts Discussed in Thread: PGA280

Can someone tell me how much the input bias current changes when the input voltage exceeds a valid range and saturates the gain stage?

I am using the PGA280 in a multi-channel system (8 input channels; 4 PGA280s, each with two input channels, driving four ADC inputs) with input ranges from +/-10V to +/-50mV, using the PGA280 gain to normalize the input voltages for the subsequent ADC.  With this sort of system it is easy to saturate an input; for instance, configure an input for +/-50mV and connect it to a 9V signal.  In this configuration, the PGA280 appears to draw considerable current on the INP2 pin, much more than INN2, INP1 or INN1 (I have run both inputs overvoltage, one at a time, and channel 2 seems much more impacted than channel 1.)  I have 5K resistors in series with the inputs so there is no chance of exceeding the PGA280 input current limit but in some fault conditions I get more than 2 Volts DC across the resistor on the INP2 pin when driving with an isoloated signal source (9V battery.)  The INP2 input pulls the isolated signal source to the positive supply rail.

This may not be a problem at the application level but it shows up when all inputs are tied together and driven with 8 to 10 Volts DC, configuring one input with relatively high gain and the others with a gain of 1/8 - in this case the amplitude measured on all of the channels is reduced, apparently because they all are pulled to the positive rail (this is an isolated system so excessive input bias current can pull the signal source away from ground.)

I am just trying to better understand the behavior and mechanism here so I can determine if this will be a problem for the system that needs to be addressed or if we can ignore it, allowing an overvoltage channel to saturate but still have the other channel produce valid data.

  • Hi Mike,

    Several cases of input overload are possible.  It sounds like that in your case the inputs remain within the high voltage supply range and within the valid common mode input range but your input signal magnitude is exceeding the valid range for your gain setting.  In this case the current through the gain resistor string is limited internally and an internal protection clamp turns on to prevent the inputs of the internal amplifiers (A1 and A2) from overvoltage conditions.  This clamp can be seen on Figure 49 on Page 24 of the PDS. 

    In addition to the 5K resistor that you have series with the inputs there is another ~1K internal resistance so the current that will flow can be estimated by the voltage minus the clamp voltage (~2V) and the series impedance.  This would say that the current levels that you are seeing (~400uA with 9V overload) are possible.

    The clamp voltage is dependent on the direction of the overvoltage which could explain why you see different results on the INP side than on the INN side.  However, I am not sure why you would see differences between the INP1 and INP2 inputs.  Maybe you can provide more information about the magnitude of the difference that you are seeing, details of the input switch configuration and supply voltage configuration.  I am also not sure why your isolated input source would be pulled to the positive supply.  Can you please send more information on the input configuration?

    Best regards,

    Viola Schaffer

  • Hi Viola,

    Yes, I agree that the case I describe has the signal inputs within the VSP/VSN supply rails (with headroom to spare) but well outside the valid range for the gain setting - what one might call a "soft fault" condition and clearly overrange.  Thank you for clarifying the relevant clamping mechanism in this case - it is helpful to know those details.

    After further testing I have determined that what I described about the two inputs being different was an artifact of my test; with a better test configuration the two input pairs (IN1 and IN2) behave the same.  Sorry for the miscue on that.

    In my latest/simplest test, I have an isolated DC source connected to one PGA280 input with a 5K resistor between each PGA280 pin and the signal source.  The other PGA280 input has no signal source connected.  Both PGA280 inputs have a 10M pullup to 3.3V and a 10M pulldown to ground, both on the signal source side of the 5K resistors.  With the PGA280 gain set to 32 and driving the input with a variable supply, the input pins start to be pulled away from where they should be when the input is a little under 2 Volts and by the time the input voltage reaches about 4.7 Volts the + pin of the signal source is at +15 Volts.  With the signal source set at 10 Volts, it's + pin is at 17.8 Volts and it's - pin is at 7.8 Volts.  If the polarity of the signal source is reversed the behavior is about the same except with a -10V input the + pin is at -16.8 Volts and the - pin is at -6.8 Volts.

    We are not doing anything special with the switch configuration; the INN/INP pins are connected to the gain stage with switches A1/B1 and A2/B2 - we are not using the buffer feature.  We also are not using the 100uA burnout current source/sink.

    Best regards,

    Mike McFeters

  • Hi Mike,

    Thanks for the clarification on the input pairs and the additional information.  Your input is being pulled to the positive supply due to the architecture of the clamps at the inputs of A1 and A2.  When the clamp turns on it overrides your weak input common mode setting and pulls the input to the rail. 

    Where I am not sure is if you could run into the possibility that one pga input will be pulled to the positive supply in the overload condition while another would try to pull down to the negative supply.  Based on schematic review it seems unlikely but if that is a serious concern in your application then we would have to look deeper into that to confirm.  Have you tried several parts in your configuration?  Do they all behave the same?


    Best regards

    VIola Schaffer

     

  • Hello Viola,

    Sure, that makes sense (that the clamps are somehow pulling to the power rail; not enough detail in the datasheet to see the mechanism for that but it is not too surprising and clearly is what I am seeing.

    Yes, I have tried several parts (and several different assemblies; each assembly has four PGA280s on it so it is easy to run through a fair number of chips.)  Give or take some subtle/insignificant differences, all of the parts do the same thing.

    It seems unlikely there is an easy work-around to this.  I am hoping we can get away with opening the switches except when we are sampling a channel; that way an overrange channel can not effect any other channels but this will increase the time required to switch between samples, increase processor overhead and will reduce the maximum sample rate when multiple channels are being sampled.  Otherwise it looks like we probably need a different architecture or at least drastically reduce the resistance from the inverting input to ground. Do you have any other or better ideas?

    Best regards,

    Mike McFeters

  • Hi Mike,

    Yes, you are right.  The PDS does not provide enough information to predict the clamping behavior. 

    Another possible solution to your overload problem would be to switch the current buffers (PDS Page 20-22) into the signal path for the PGAs that are not the sampling.  There are several options to trigger these buffers described on Page 22.  Depending on your system level timing using those could provide a faster sampling solution.   

    Best regards,

    Viola Schaffer

  • Hi Viola,

    Thank you for the response and suggestion.  I had considered using the current buffers but I determined the timer can bet set long enough to solve this issue in all cases; sometimes we sample very slowly, with a fair number register writes (many SCLK pulses) between samples. 

    In reading further I see on page 37 of the datasheet that apparently the buffer can be controlled with the GPIO4 pin, implying that the buffers can be left on indefinitely.  Is that a correct interpretation?  Does that work only with GPIO4 configured as an input or can it also be made to work with GPIO set as an output?  On my existing hardware GPIO4 does not have a suitable connection to be used to control the current buffer if configured as an input so we can use this mechanism only if it works with GPIO4 set as an output, with the PGA280 controlling the state of GPIO4.  Even if that does work I do not think this would save us any time overall compared to opening switches when not sampling because we would need to reconfigure the buffer control state on unused inputs (or suffer the increased error from the buffer which I believe would be excessive for our application.)

    Best regards,

    Mike McFeters

  • Hi Mike,

    Yes, the buffer can be switched in as long as desired using the GPIO4 pin.  However, the GPIO4 pin will not act as an output any more when the special pin function is selected.  Would using another GPIO pin to drive GPIO4 be a suitable option? Of course all of this is communication intensive so you might not save much time compared to opening the switches.

    Best regards,

    Viola Schaffer

  • Hi Viola,

    With the existing circuit board design I can not use another GPIO pin to drive GPIO4; I could with a board spin but I also could just terminate GPIO4 high and use the configuration registers to set the buffer mode.  Either way there is extra communication overhead to change the configuration when selecting which input will be sampled but it looks like our communication overhead is low enough that we should have time for the extra register writes when switching between channels.  For now we plan to open the Ax/Bx switches to isolate the inputs that are not being sampled from the input connector - that should work fine.  In some applications, where speed and/or communication overhead is critical, that would not work but for this design it looks like a suitable solution.

    Thank you for the help with this.

    Best regards,

    Mike McFeters