OPA333A-EP: Output unstability during the temperatures

Kavindu,

Before I can analyze the issue, I need to understand what am I looking at.  It is not clear to me whether your diagram shows Output or IB instability - see below.  Please advise what is the timing of horizontal axis (how fast the temperature changes) and how does the customer actually control (changes) the temperature?  Do they use a thermal stream, temperature oven, or something else?  Also, if they use temperature oven, do they utilize nitrogen purging as the means of removing moisture at cold temperature?

Hi Marek,

Thank you for the response. The graph is actually the output of our sensor converted to the engineering units which is proportional to the 4-20 mA current loop output of XTR116. But I have made it clear as below by converting back to the actual current output. The time axis is also made clear. This is basically done inside an environmental chamber which can heat up and cool down. There's no nitrogen purge but I can assure at this stage the PCB is enclosed in the sensor housing which is fully potted, hence this effect is not due to moisture condensation.

Please let me know if you need further details. 

Best regards,

Kavindu 

Are you saying the graph is the output of the XTR116 in the configuration as shown below?

or it is the output of XTR116 converted to voltage that feeds into OPA333 based instrumentation amplifier as shown below?

In either case, it seems that the problem may be caused by Radio Frequency Interference (RFI), which does not appear to be considered in the report: 

There is a section in XTR116 datasheet that specifically warns against long wires in current loops that may cause RF pickup, which then gets rectified by the input circuitry of XTR116 or preceding stage leading to unstable output current - see below. The RF itself could be generated by the burst of cold or hot air being blown inside the oven. 

Hi Marek,

Ok.. But before going any further please let me know if you could find the attachment of the schematic in Section 7 (Appendix) of the report?

There the amplifires are feeding the XTR116 and the graph is the XTR116 output. 

Best Regards,

Kavindu

Hi Marek,

In fact we did the initial diagnosis by monitoring the various points and narrowed down the issue to U2 and/or U8. Once U2/U8 are replaced this issue could be resolved as mentioned in the report.

The PDF is herewith attached 

PCBSCH008564-Amp.pdf

Best Regards,

Kavindu

Could you share the scope image of Vin (a differential voltage between REF and TP6) that shows instability?  

At this point, I can share the tp6(tp5, tp8 also) logged data of a similar case which was captured during the diagnosis, yet not the scope image.

mabs test point-14MAR23.xlsx

Things simply don't seem to make sense that at 90C and -55C there is no issue but at 70C become unstable.  Actually, considering we look at 200 min/div scale, it is not instability but simply DC variation. Thus, we really need to scope the TP6 during 70 deg C interval to see if there is any actual oscillation.

If there is no oscillation at TP6 during the time period shown above in the blue oval, your customer needs to measure the inputs, T3 and T4, during said time interval for any variation.  If they show variation, they need to measure the inputs to U2 and U8 - see below. In other words, they need to figure out what causes TP6 to vary during said time period.

Hi Kavindu,

Adding to Marek's comments. 

It is not clear what "REF" reference is. In XTR116 2-wire current transmitter, the Iref or pin3 or REF node should be floating. I believe that it is floating as is shown, though it is not clear. 

2nd observations are: you have REF in quite few places, which are shared with multiple components. The Io current at pin4 should be < 3.6mA under no input condition (Vin at XTR116 in the schematic below should contain no input signal, and Io < 3.6mA). 

The current budget for XTR116's (Vreg + Vref) should not exceed 3.6mA under no input condition. Since REF references are all over the schematic, I am questioning if this requirements has been exceeded. In other words, XTR116 is unable to drive so many components under no load conditions. It XTR116's pin8 and pin1's current are overloaded, then the 2-wire transmitter is not going to operate properly and support V-I conversion from the input to 4-20mA.  

If you have other questions, please let us know. 

Best,

Raymond

Hi Marek,

I understand it's complex. As I mentioned before with probing the test points and trial and error, we could narrow down the issue to U2/U8. Could you please 

make a comment on that

Best Regards,

Kavindu

Hi Raymond,

Thank you for additional comments.

The Iret is separated from the 4 - 20 mA loop ground.

On the current consumption, we have calculated the load on Vref & Vreg to be less that 3.6 mA considering the worst case scenarios during the initial design phase.

Regards,

Kavindu

Are you saying the inputs (see arrows below) are completely clean when probed with a scope but the output, TP3, is unstable?  

Also, is REF connected to ground or is it the Vref pin 1 of XTR116 that drives it?  If the latter is the case, you should connect all bypass caps to system ground and NOT Vref of XTR116 as this may create multiple signal loops with unpredictable results like the one you see.

The REF is connected to the ground not to Vref.

Regarding the input, we can say it's clean because if it's not whenever the U2/U8 is replaced the output should be the same (unstable).

Thanks Marek. This is something that we didn't consider during the investigation. Will update you if we find something noteworthy. 

Hi Marek,

We conducted a set of comprehensive tests to check if the flux residues on the PCB can lead to this kind of behaviour. But even with several cycles of cleaning could not cure the problem with faulty boards. On the other hand, intentional flux left on board with the replaced U2/U8 could resolve the issue. This makes me wonder if there's something to do with the intrinsics of the OPA. Is there a possibility to send a batch of screened components to your labs and do an investigation?

BR,

Kavindu

Sorry for late reply - we had a re-org and moved to different support forum.  Since you imply that the intentional flux left on board in fact shows similar problem you face but may be cured by U2/U8 replacement, this seems to point to the flux related issue despite the fact that you are unable to cure the faulty boards by using your cleaning methods  - perhaps actual residue left on the faulty boards does not get removed by your cleaning methods.

I do not believe sending the parts to us will show the problem because all we can do here is to re-run the same high-speed final test (1sec in duration) that we use for mass production whereas the problem you describe is a slow variation in the output voltage (measured in hours).