Specifications and Design Tolerances

[bdunham7]

Therein lies the flaw.  There is no reason to think the LF353 circuit would behave the same as a +12V source with a 1 kohm resistor. 

Of course there is, it's called looking at the design.  This isn't like using a 1N4007 diode for 1200V because they will usually work fine that way, until someone sells you 1N4007s that pop at 1100V.  This is using a characteristic of the design that is not reflected in the datasheet, maybe like using the 1N4007 as a temperature sensor.  Process variations shouldn't change the design and if they do change the design, then I suppose maybe the circuit won't work--although I'll bet that's unlikely.  I've explained all that once already so I won't do it again if you haven't read it carefully. 

That's not actually correct.  The open circuit voltage must be distinguishable from the 9V level.

Yes, but why wouldn't it be?  What I meant by the 12V being 'accessible', I meant as a low-impedance node.  Obviously for an open or very high impedance circuit, ~200R plus a saturated transistor isn't going to change that voltage much, so it is accessible enough to anything in the EVSE circuit that needs to see it.  Put another way, it doesn't have to supply any appreciable current at +/- 12V.  You've been saying something about 11.4V, where do you get that?  I'd bet that if I'm right about how it works, you'll see more like 11.8V with a 12V rail and very high impedance load.  But I don't have any LF353 floating around unless maybe I go digging in some old circuit boards or something.

[gnuarm]

CatalinaWOW,

I can make this very simple.  You seem to think that to discuss the issue at hand, we need to discuss the entire design process and address every possible problem, or none at all.  Whether or not there are unaddressed problems does not make any problem being addressed, pedantic. 

So you have drawn a false conclusion. 

[gnuarm]

Therein lies the flaw.  There is no reason to think the LF353 circuit would behave the same as a +12V source with a 1 kohm resistor. 

Of course there is, it's called looking at the design.  This isn't like using a 1N4007 diode for 1200V because they will usually work fine that way, until someone sells you 1N4007s that pop at 1100V.  This is using a characteristic of the design that is not reflected in the datasheet, maybe like using the 1N4007 as a temperature sensor.  Process variations shouldn't change the design and if they do change the design, then I suppose maybe the circuit won't work--although I'll bet that's unlikely.  I've explained all that once already so I won't do it again if you haven't read it carefully. 

You have explained your false analogy.  I've provided the data from the data sheet that clearly shows the part is being used outside of its defined performance specification. 

If I were trying to get a space capsule back from the moon, I would be willing to accept all manner of such seat of the pants engineering.  This is a product that will be sold in the thousands, containing what is not just a potentially faulty design feature, but is an inappropriate design feature.  It is very easy to design this part of the circuit with fewer parts, that is assured to work correctly, under all conditions according to the spec sheet. 

There is absolutely no reason to misuse a part in this way.

That's not actually correct.  The open circuit voltage must be distinguishable from the 9V level.

Yes, but why wouldn't it be?

 

I've already explained that the data sheet indicates the output of the op amp from ±12V supplies, may be as low as ±9V. 

What I meant by the 12V being 'accessible', I meant as a low-impedance node.  Obviously for an open or very high impedance circuit, ~200R plus a saturated transistor isn't going to change that voltage much, so it is accessible enough to anything in the EVSE circuit that needs to see it.  Put another way, it doesn't have to supply any appreciable current at +/- 12V.  You've been saying something about 11.4V, where do you get that?  I'd bet that if I'm right about how it works, you'll see more like 11.8V with a 12V rail and very high impedance load.  But I don't have any LF353 floating around unless maybe I go digging in some old circuit boards or something.

11.4V is the required voltage at the pin for that state (A I think they call it) according to the EVSE spec.  Even if state A (no load) the op amp output was correct enough, what happens when the interface pin is loaded to produce 9V?  According to the LF353 data sheet, the output can be as low as ±9V.  How low do you need to reduce the 1 kohm resistor to maintain an appropriate voltage at the interface pin?  There is the ~1 kohm resistor between the op amp and the pin, then a diode and a 2.74 kohm resistor to ground.  So about a quarter of the voltage will be dropped across the 1 kohm resistor.  The value of this resistor would need to be lowered a lot to raise the voltage at the interface pin to an acceptable level. 

Then look at achieving 6V with 882 ohms and the diode to ground.  So 9V at the op amp, subtract the 0.7V for the diode to give 8.3V.  Assume 820 ohms instead of 1 kohm (what the EVSE device is actually using).  This gives 4.3V on the 882 ohm resistor, plus the diode voltage gives 5V.  Rather lower than 6V. 

If the threshold is 4.5V... I think you will find the noise margin is greatly reduced.  Interestingly, the EVSE spec does not set actual voltages for either the states or the thresholds between the states.  So I suppose you might be able to make this work better by not assuming the 6V state C is anywhere near 6V.  Heck, you could even calibrate each unit for the particular op amp.

Or... you can design an even simpler circuit that just works!  Replace the op amp and two resistors with... an analog switch mux. 

Your comment about not having an LF353 on hand shows exactly the faulty thinking I'm talking about. 

Whatever.  We are clearly never going to reach any agreement on this.  I think it's time to throw in the towel.

[T3sl4co1l]

I don't get it.

"You can't test process", yet, there is precisely one output characteristic in play here, that corresponds to one real function, which can be sampled (characterized, measured at points), and which is continuous to the extent that such sampling is representative of the full continuous function.

We can measure the V(I) characteristic of the chip, over temperature if we like, and guarantee, through testing, it will always meet our requirements.

And in this case, we might only ever bother to sample a couple of operating points -- corresponding to the load in question -- at the two voltage states.

If as few as two points fully describe the relevant characteristic, and measuring those say at assembly test gives 100% test coverage, then what's the fucking problem?

Indeed, numerous off-label users, with high certainty demands, have employed such testing to maintain the quality of their products.

Apparently they are wrong to do so?  Wrong how?  You must now give an economic justification for their wrongness, given that their customers demand a degree of quality corresponding to the practices you believe in.

Now, whether the party in question is doing a batch / receiving test, or statistical sampling, or anything like that -- that's another matter.  It seems, informally at least, they have a sampling method of a sort.

Indeed we can flesh out the entire quality system here.  Let's see:

Receiving: a statistical sample was done at least once (initial design testing).  We can interpret this as a frequency.  Therefore they are doing some frequency of testing.  (Whether or not they intend to ever do more sampling, is another matter.  This observed testing frequency may simply forever decrease...  And, the number of units tested, might be as little as one, not a statistical sampling, but we'll conveniently ignore that for now.)

Production test: perhaps an assembly test is done to verify the operating point within tolerance.

Customer receiving test: if it works, it works.

Remediation: if a customer's unit malfunctions, send out a replacement.  The customer serves as production test, if nothing else.

Thus, that testing gets done one way or another, but it might not be done under a range of conditions until some time later, or at all (those units used in Florida, or indoors, will never experience the same temperature swings that an outdoor unit in Montana will, thus test coverage over temperature is spotty at best).

Recall: if a mass of customers report malfunctions, maybe take a look at what parts went into them and check if there was a process change.  Switch to an alternate part, and restart from the top.

That spans basically all the steps of quality control, so there's something there, in a fashion.  The main downside is it puts much of the burden of testing on the customer.  And, granted, they might not be smart enough to do that last step in an orderly fashion, and some amount of testing earlier in the process can avoid the troublesome mass-replacement scenario.  But also, they might get lucky and simply never have that happen.  Who knows.

Is it cheap insurance to test more often, or use a better designed circuit?  Maybe you overestimate how much profit margin the product has, or underestimate how expensive engineering or testing time is.

Tim

[Wolfram]

Is this from the OpenEVSE CP line driver? I know that one used a similar scheme, and I always thought it was dodgy.

It's pretty clear to me in this case, if the output voltage levels and rise time fall outside of the tolerance band given by the standard, then it is a bad design. If there was a clear benefit in terms of cost and complexity to do it in this way, it might be justified, but in this case they are using the wrong component for the job. When solving a similar problem, I used a simple circuit based around four discrete transistors and got output voltage levels within a few tens of millivolts of the rails.

The op-amp solution still likely works well because of the wide margins on the receiver side, but at the cost of reducing the robustness of the link. The fact that they power the op-amp with an unregulated DC/DC also helps, since these provide nominal voltage at full load current, and significantly more at the light loading seen in this circuit. If this design by chance manages to fit within the limits of the standard, and that is verified over all the expected operating conditions then it can be argued that it's acceptable. But then it seems easier to just do it with a more suitable circuit topology in the first place.

[jonpaul]

bonjour à Gunarm, et tous....

Just seeing this long topic, very fine discussion.

A moment please......

Is the application commercial, consumer, industrial, avionics, medical ?
What is the concequence of a failure in the field?
Different in a bad $50 consumer game, vs  a $10k broadcast processor, or a medical electronic in a surgery suite...

In decades of consulting and manufacturing, I used worst case design as a philosophy, and fail- safe in mission critical applications, eg military, avionics, medical.

Relying on typical specs was risky.  So, a commercial IC has worse  tolerance and specifications, better in industrial -25-+85C or best in mil spec -40(?)...125 C.

Just the ramblings of an old retired EE (68')

bon courage et bon chance

Jon

[gnuarm]

Is this from the OpenEVSE CP line driver? I know that one used a similar scheme, and I always thought it was dodgy.

It's pretty clear to me in this case, if the output voltage levels and rise time fall outside of the tolerance band given by the standard, then it is a bad design. If there was a clear benefit in terms of cost and complexity to do it in this way, it might be justified, but in this case they are using the wrong component for the job. When solving a similar problem, I used a simple circuit based around four discrete transistors and got output voltage levels within a few tens of millivolts of the rails.

The op-amp solution still likely works well because of the wide margins on the receiver side, but at the cost of reducing the robustness of the link. The fact that they power the op-amp with an unregulated DC/DC also helps, since these provide nominal voltage at full load current, and significantly more at the light loading seen in this circuit. If this design by chance manages to fit within the limits of the standard, and that is verified over all the expected operating conditions then it can be argued that it's acceptable. But then it seems easier to just do it with a more suitable circuit topology in the first place.

This is the conversation I always have with people regarding design verification.  The golden rule is that you can't prove a design works, by testing it.  I've said it before, and I'll say it again.  You can test over temperature.  You can test over voltage.  You can test over voltage and temperature together.  But you can't test over process, because you can't control process.

I worked on a design once where the FPGA tools were not analyzing timing properly.  It would tell us the design timing was good, but it would fail on the bench.  We could make it work by cooling.  We had a few chips where the design would work on some of the randomly seeded layouts.  They could be made to fail by heating.  Clearly a timing issue. 

We had no way of testing over process other than the handful of chips we had.  We could buy and test chips until the cows came home, and we would still have no idea how much of the process range we had covered.  We ended up spending days and weeks randomly generating FPGA layouts, and testing them using a chip heater.  What a PITA! 

That's why we use data sheets.  The manufacturer tests to the data sheet and guarantees those data.  Designing to that data assures your design will not fail because you didn't fit the right part into the right socket.  In this case, the spec of the LF353 shows far too much range of the output voltage drop to be suitable for this circuit. 

It's a bad design.  The person who designed it should feel bad.  No, just kidding.  That's what Zoidburg would say.  But the person who designed it should learn, rather than waving his arms wildly and claiming it's fine, since he measured a device and it's all good.

[bdunham7]

Is the application commercial, consumer, industrial, avionics, medical ?
What is the concequence of a failure in the field?

It is the pilot signal for a J1772-spec EVSE (EV charging station).  If it malfunctions, the vehicle will not charge.

Relying on typical specs was risky. 

Perhaps, but many remarkable things have been built with 'select' part, not only relying on 'typical' specs but on best-case specs.  However, IMO this is not a case of typical vs worst-case or safety margins, it is about a design characteristic not specified in the datasheet--specifically an op-amp that saturates when open loop and has a resulting large differential voltage on the inputs. 

[uer166]

It is the pilot signal for a J1772-spec EVSE (EV charging station).  If it malfunctions, the vehicle will not charge.

There's no excuse to comply with J1772, which specify the 1k resistance tolerance, and the oscillator voltage ranges, with recommendation to make it tighter to ease up tolerance stackups and improve inter-operability. It's a simple circuit with simple requirements, and with a zillion non-compliant EVs on the market with their own set of edge cases, so it's definitely imprudent to rely on average cases.

[uer166]

Looks like this is the circuit. Apart from being shit-tastic for no good reason, there are schematic mistakes (e.g. it wouldn't work with that TVS diode, unless it was bidirectional; sure enough, the part is bidirectional which doesn't match schematic). None of this could possibly be UL2231-1 compliant either.

[bdunham7]

Whatever.  We are clearly never going to reach any agreement on this.  I think it's time to throw in the towel.

OK, but can we agree on what we disagree about?  Ironically, I understand and typically would agree with your main thesis about not relying on typical specs or special parts, but I just don't think it applies to this case the way you think and since you've come here to publicly pillory some hapless EVSE designer who isn't here to defend himself, I thought I'd take up his cause.

Your comment about not having an LF353 on hand shows exactly the faulty thinking I'm talking about.

So one thing we disagree about is what the data sheet tells us and my comment supports that, not the other way around.  You claim that 'according to the data sheet' the output of the op-amp could be "as low as +/-9V".  As mentioned, I don't have an LF353 handy to test, so relying solely on the information contained in the data sheet along with basic knowledge of op amps in general, I am saying that the op-amp will reliably put out ~11.8V +/- 0.1V with +/-12.0V supply rails and a 0-5V 1kHz square wave + input and 2.5V on the - input, which I'm assuming is how the EVSE in question is set up.  I'll go a bit further and say that I would expect that to apply to any LF353 from any reliable manufacturer and additionally, if the EVSE designer has used a 750R resistor on the output, the J1772 requirements will be met well within tolerances.  Did I guess right on the resistor or did he put an 820R in there?  Now you're waving the data sheet at me and saying "No!  It says here you can't rely on it to be more then 9V!".  I've explained why I think this is true in detail above and don't think it will help to do it again. Just note that I am not depending in any way on testing or on a typical spec.  And there we disagree, plain and simple.  Fair enough?

Another thing we disagree on is the requirement to only use components in ways anticipated and specified by the data sheet.  In this case, the data sheet doesn't contemplate operation with the output transistors saturated because that's not really an op-amp thing to do.  In theory, they could implement a change that incorporates output saturation protection or something and those parts might not work in this application.  However, that's more than a 'process' change and IMO manufacturers are extremely unlikely to do that because their customers will probably not like it.  So as long as there is sufficient information to draw a reasonable (and yes, testable) conclusion about the component's internal design, any characteristic that is pretty much assured by that design is probably one you can rely on.  In this case, I'm assuming this relatively generic-except-for-the-J-FET-inputs op amp will saturate the outputs under the conditions of the specific circuit in question.  If I'm wrong about that, well then the EVSE won't work.  But I hear that they do, so...

[uer166]

if the EVSE designer has used a 750R resistor on the output, the J1772 requirements will be met well within tolerances.

J1772 specifies some of the stuff, e.g. in table 3:

• Generator voltage high between 11.4V and 12.6V
• Generator voltage low between -11.4V and -12.6V
• Source resistance between 970 and 1030 Ohms

Ergo, the design is not compliant for some of these, as well as other more subtle stuff like slew rate. E.g.: "This [generator] circuitry shall have rise/fall times faster than 2usec". The opamp seems to barely meet that, so it's at the very least marginal.

Honestly to do it right is less effort than trying to prove that something weird like this is standards-compliant, so I have no issue calling out the designer of this in saying that it's not great.

If they called it something like "Magic OpenEVSE standard compliant charger", I have no problem with it, but the J1772 label is right there on the schematic..

[bdunham7]

[Source resistance between 970 and 1030 Ohms

This [generator] circuitry shall have rise/fall times faster than 2usec

Hmm, OK those are going to be difficult to achieve with this setup, so scratch the part about meeting J1772.  I have no idea why J1772 would require 2us rise times.

[T3sl4co1l]

OK, but can we agree on what we disagree about?  Ironically, I understand and typically would agree with your main thesis about not relying on typical specs or special parts, but I just don't think it applies to this case the way you think and since you've come here to publicly pillory some hapless EVSE designer who isn't here to defend himself, I thought I'd take up his cause.

Right?  Like, you can't compare an op-amp to an FPGA... the FPGA is exponentially more complex.  Obviously you're going to have problems testing an FPGA, you can't test every path under every voltage and temperature, in every single unit, under every possible combination of inputs and internal states.

The op-amp has exactly one [continuum] internal state*.

They aren't the same damn thing!

A more direct comparison would be a single gate, or gate path or LUT/LE/block in an FPGA.  Maybe a couple inverters (74HC3G04 let's say?) to be more concrete.  Can you characterize the delay of one specific path?  YES.  Can you do it over voltage, temperature, etc.?  YES.  Do you want to in production?  Probably not.  Can you do it statistically?  Probably not (e.g. sampling parts from a lot/batch, or even just sampling random LEs among the fabric -- there will be some distribution over the die itself), but it depends how much margin is required by the application.  I mean, in any case, it reduces to a statistics problem, and if you're looking for a 99th percentile say, that's easily enough done by sampling; but if you need the 20th percentile lucky hotrods, good luck and have fun grinding out all that testing.  But notice these latter questions are all practical ones.  Which can have different answers for different circumstances.  Discarding these possibilities out of hand would be silly.

It sounds like OP is just very familiar with the high-complexity side of things, where it is practical to discount such possibilities out of hand, but forgets when they can again be reasonable to consider.

*The dominant pole; well, several if you include the higher order poles above fT but they are also largely irrelevant in practice, or beyond just the lowest few.

Mind, I don't have any complaints at all, in principle.  I wholeheartedly support, understand, and use, such principles in my own work.  But apparently some would think I'm some horned devil because I allow practical exceptions to those same principles...

Or--maybe I've grossly misinterpreted or misunderstood the intent here, or the concepts at work.  I haven't worked with, say, Six Sigma in a very long time (and that occasion was pretty superficial, heh).  I'm sure my statistics are rusty.  I may be grossly mis-understanding/representing the complexity or cost of these controls or inspection or testing procedures.

But if no one steps up to critique my points, I'm left to assume I have asserted them correctly and rightly, that most people here generally agree with them...or at least don't disagree strongly enough to complain about it.  I would love for my arrogance to be knocked down a peg, as it needs to from time to time, but, y'know, I'm only going to do so much research on my own here.  Someone, please, be the change you want to see! ( ?? )

Tim

[T3sl4co1l]

if the EVSE designer has used a 750R resistor on the output, the J1772 requirements will be met well within tolerances.

J1772 specifies some of the stuff, e.g. in table 3:

• Generator voltage high between 11.4V and 12.6V
• Generator voltage low between -11.4V and -12.6V
• Source resistance between 970 and 1030 Ohms

Ergo, the design is not compliant for some of these, as well as other more subtle stuff like slew rate. E.g.: "This [generator] circuitry shall have rise/fall times faster than 2usec". The opamp seems to barely meet that, so it's at the very least marginal.

Honestly to do it right is less effort than trying to prove that something weird like this is standards-compliant, so I have no issue calling out the designer of this in saying that it's not great.

If they called it something like "Magic OpenEVSE standard compliant charger", I have no problem with it, but the J1772 label is right there on the schematic..

As for explaining why it apparently works anyway -- I wonder how strict most (all?) receivers are?  What's the penalty for violating the above specs?  Does every receiver just fail outright?  Do they in fact specify a much looser/narrower threshold, ala RS-232 for example, making the extraordinarily tight transmitter threshold absurd and useless?  Do they even measure source resistance (perhaps with a dithering load current or resistance -- and if so, at what frequency, waveform, pattern, etc.?)?  How can they tell between a slightly lower Thevenin Vth and Rth, versus a higher (of both)?

Framing it in terms of design by contract: there are always three aspects to a contract.  There's what the client party thinks they should be getting; there's what the supplier party thinks they should be making; and there's verification -- each party being able to prove to each other that the steps and clauses of that contract have been met, to mutually agreed satisfaction.  Clauses without verification are as good as struck, and clauses that are overly specific for their testing methods are only as good as the test itself.  It comes down to design-for-test (in analogy to "teach to the test" schooling).  That doesn't have to be a bad thing (as that analogy often connotates), but it means we have a responsibility to design our contracts, or standards, or whatever, to a high level.  And if we fail to do so, it is our own fault, whether through lack of foresight, laziness, or lack of responsibility/wherewithal to update the standard at a later date to correct those shortcomings (which, yes, can have many issues about it, but it almost always comes down to "political will", being able to convince enough people of the value of the change, and then to push that change to all stakeholders).

Tim

[gnuarm]

Is the application commercial, consumer, industrial, avionics, medical ?
What is the concequence of a failure in the field?

It is the pilot signal for a J1772-spec EVSE (EV charging station).  If it malfunctions, the vehicle will not charge.

Depending on how it malfunctions, it can connect the power line to the car when it should not. 

Relying on typical specs was risky. 

Perhaps, but many remarkable things have been built with 'select' part, not only relying on 'typical' specs but on best-case specs.  However, IMO this is not a case of typical vs worst-case or safety margins, it is about a design characteristic not specified in the datasheet--specifically an op-amp that saturates when open loop and has a resulting large differential voltage on the inputs.

I worked on the test floor of a company who designed a super computer (second to the Cray) using sloppy design methods.  Timing is not a place where you want to use anything other than max numbers.  We had a FIFO chip we would automatically replace when we had a certain failure.  Turns out it wasn't the chip, the designer was using logic gates to define a pulse width to operate the FIFO! 

That was where I learned about Level-Sensitive Scan Design.  That is old hat now, but there were many things like this which were just coming into wide adoption.  I guess design based on maximum timing specs was one of them.

Oh yeah, that company is not in business anymore.

[gnuarm]

Looks like this is the circuit. Apart from being shit-tastic for no good reason, there are schematic mistakes (e.g. it wouldn't work with that TVS diode, unless it was bidirectional; sure enough, the part is bidirectional which doesn't match schematic). None of this could possibly be UL2231-1 compliant either.

I think that is an old version.  I never found a current one.  The author claims his design has UL and other certs. 

I only noticed this because someone was asking why his output voltage was low.  The author (unknown to me at the time) responded about lowering the 1 kohm resistor to 820 ohms.  That's when I smelled a rat. 

[gnuarm]

Whatever.  We are clearly never going to reach any agreement on this.  I think it's time to throw in the towel.

OK, but can we agree on what we disagree about?  Ironically, I understand and typically would agree with your main thesis about not relying on typical specs or special parts, but I just don't think it applies to this case the way you think and since you've come here to publicly pillory some hapless EVSE designer who isn't here to defend himself, I thought I'd take up his cause.

No one is being "pilloried".   I wanted to discuss the issues.  We've done that.  I never even mentioned the guy's name and the project was only sussed out after some mentions of details.  In fact, I tried to not discuss the details since most of it is not relevant to the real discussion.

Your comment about not having an LF353 on hand shows exactly the faulty thinking I'm talking about.

So one thing we disagree about is what the data sheet tells us and my comment supports that, not the other way around.  You claim that 'according to the data sheet' the output of the op-amp could be "as low as +/-9V".  As mentioned, I don't have an LF353 handy to test, so relying solely on the information contained in the data sheet along with basic knowledge of op amps in general, I am saying that the op-amp will reliably put out ~11.8V +/- 0.1V with +/-12.0V supply rails and a 0-5V 1kHz square wave + input and 2.5V on the - input, which I'm assuming is how the EVSE in question is set up.  I'll go a bit further and say that I would expect that to apply to any LF353 from any reliable manufacturer and additionally, if the EVSE designer has used a 750R resistor on the output, the J1772 requirements will be met well within tolerances.  Did I guess right on the resistor or did he put an 820R in there?  Now you're waving the data sheet at me and saying "No!  It says here you can't rely on it to be more then 9V!".  I've explained why I think this is true in detail above and don't think it will help to do it again. Just note that I am not depending in any way on testing or on a typical spec.  And there we disagree, plain and simple.  Fair enough?

Your assertion has always been clear.  The basis for it is not.  I reject the idea that you can analyze the circuit as if you had the actual circuit and could make measurements or run the simulation.  This is exactly the sort of stuff that is outside of what I consider to be design practice.  I've never worked at a company where someone in the design review would not just say, "So why don't you just change out the damn part?"  Typically a boss who is tired of everyone beating the dead horse.

Actually, the designer has said he is going to consider my switch approach, if I understood him correctly. 

Another thing we disagree on is the requirement to only use components in ways anticipated and specified by the data sheet.  In this case, the data sheet doesn't contemplate operation with the output transistors saturated because that's not really an op-amp thing to do.

What's your point??? 

In theory, they could implement a change that incorporates output saturation protection or something and those parts might not work in this application.  However, that's more than a 'process' change and IMO manufacturers are extremely unlikely to do that because their customers will probably not like it.  So as long as there is sufficient information to draw a reasonable (and yes, testable) conclusion about the component's internal design, any characteristic that is pretty much assured by that design is probably one you can rely on.  In this case, I'm assuming this relatively generic-except-for-the-J-FET-inputs op amp will saturate the outputs under the conditions of the specific circuit in question.  If I'm wrong about that, well then the EVSE won't work.  But I hear that they do, so...

Except that there's absolutely NO reason to use the part, when many alternatives are available.  Why cobble something together from the junk yard across town, when you would pass five autoparts stores, each of which carry just the part you need.

Feel free to respond.  i no longer feel a need to discuss this with you.  We are just covering the same ground and it's getting very... muddy. 

[uer166]

As for explaining why it apparently works anyway -- I wonder how strict most (all?) receivers are?  What's the penalty for violating the above specs?  Does every receiver just fail outright?  Do they in fact specify a much looser/narrower threshold

It's very much EV-dependent. Some are very loose and some are a bit stricter, but generally as a EVSE provider you are trying to design it as tight as possible such that the EVs get the most of the tolerance stack allocation. In testing for example you can have GM cars charge fine and dandy, but a Model 3 error out. The single-ended, high impedance pilot is also well coupled to the mains and the OBC input, so any noise on that can easily swamp out the entire tolerance allocation and kick it out of state C. That is especially true on high duty cycle pilot 80A chargers, where you don't have much time to even look at the "high-going" edges of the waveform.

I know UL measures states A1 and A2 (i.e. the +-12V output unloaded), so if that's not within that region they'd likely fail it.

[uer166]

I have no idea why J1772 would require 2us rise times.

It's really important in high duty (read:80A) chargers that output 96% duty. That's only 40us to see and measure the high-side of the pilot, and you want the cable capacitance and the 1k to dominate and account for the entire rise/fall times. Otherwise you'd be robbing maximum cable length off of the spec for no good reason. This reason is explained in J1772 standard

[gnuarm]

if the EVSE designer has used a 750R resistor on the output, the J1772 requirements will be met well within tolerances.

J1772 specifies some of the stuff, e.g. in table 3:

• Generator voltage high between 11.4V and 12.6V
• Generator voltage low between -11.4V and -12.6V
• Source resistance between 970 and 1030 Ohms

Ergo, the design is not compliant for some of these, as well as other more subtle stuff like slew rate. E.g.: "This [generator] circuitry shall have rise/fall times faster than 2usec". The opamp seems to barely meet that, so it's at the very least marginal.

I'd have to read the spec again, but I think those voltages are not on the op amp, since that is an internal thing and not part of the spec.  Those are voltages at the interface, after the 1 kohm resistor.   I would say that could be a perfectly valid approach, if the voltage at the op amp output was specified in the data sheet.  It's not, at least not very well.

Honestly to do it right is less effort than trying to prove that something weird like this is standards-compliant, so I have no issue calling out the designer of this in saying that it's not great.

If they called it something like "Magic OpenEVSE standard compliant charger", I have no problem with it, but the J1772 label is right there on the schematic..

It's a simple fix, just replace the op amp with a part that is specified to drive near the rails.  Or if he wants to change the PCB, use an analog switch mux. 

[uer166]

I'd have to read the spec again, but I think those voltages are not on the op amp, since that is an internal thing and not part of the spec.  Those are voltages at the interface, after the 1 kohm resistor.

I don't think that's right, they do specify the internal generator voltages, whichever way the generator is implemented. It may be descriptive instead of prescriptive however, the devil is in the details.

[gnuarm]

[Source resistance between 970 and 1030 Ohms

This [generator] circuitry shall have rise/fall times faster than 2usec

Hmm, OK those are going to be difficult to achieve with this setup, so scratch the part about meeting J1772.  I have no idea why J1772 would require 2us rise times.

In states other than A, the signal is a PWM with the duty cycle specifying the available current.  So the edge timing is important.  1 kHz, but they slice the duty cycle more finely at the high end.  I think the higher charge rates were an add on, but just guessing.

I find it an interesting interface actually.  They get a lot done with just two wires.  One to tell the car the cable is attached and control the lock/shut down charging, and another to tell the EVSE the car is attached and negotiate the actual charging details.

If they had a section of the spec that simply said this, the whole thing would become a bit easier to read and understand.  Instead you are thrown into the details of voltages and duty cycles without really understanding of what is happening. 

I think there's also some aspect of the proximity detection pin, for the cable being connected to the EVSE.  Seems they've allowed for that too.  I think it's the same pin on the other end of the cable, but not connected to the vehicle end, i.e. separate circuits.  Not even a wire in the cable.

[gnuarm]

OK, but can we agree on what we disagree about?  Ironically, I understand and typically would agree with your main thesis about not relying on typical specs or special parts, but I just don't think it applies to this case the way you think and since you've come here to publicly pillory some hapless EVSE designer who isn't here to defend himself, I thought I'd take up his cause.

Right?  Like, you can't compare an op-amp to an FPGA... the FPGA is exponentially more complex.  Obviously you're going to have problems testing an FPGA, you can't test every path under every voltage and temperature, in every single unit, under every possible combination of inputs and internal states.

The op-amp has exactly one [continuum] internal state*.

They aren't the same damn thing!

A more direct comparison would be a single gate, or gate path or LUT/LE/block in an FPGA.  Maybe a couple inverters (74HC3G04 let's say?) to be more concrete.  Can you characterize the delay of one specific path?  YES.  Can you do it over voltage, temperature, etc.?  YES. 

NO.  "ect" is process (the only thing left) and can't be adjusted for your testing. 

Do you want to in production?  Probably not.  Can you do it statistically?  Probably not (e.g. sampling parts from a lot/batch, or even just sampling random LEs among the fabric -- there will be some distribution over the die itself), but it depends how much margin is required by the application.  I mean, in any case, it reduces to a statistics problem, and if you're looking for a 99th percentile say, that's easily enough done by sampling; but if you need the 20th percentile lucky hotrods, good luck and have fun grinding out all that testing.  But notice these latter questions are all practical ones.  Which can have different answers for different circumstances.  Discarding these possibilities out of hand would be silly.

It sounds like OP is just very familiar with the high-complexity side of things, where it is practical to discount such possibilities out of hand, but forgets when they can again be reasonable to consider.

*The dominant pole; well, several if you include the higher order poles above fT but they are also largely irrelevant in practice, or beyond just the lowest few.

Mind, I don't have any complaints at all, in principle.  I wholeheartedly support, understand, and use, such principles in my own work.  But apparently some would think I'm some horned devil because I allow practical exceptions to those same principles...

Or--maybe I've grossly misinterpreted or misunderstood the intent here, or the concepts at work.  I haven't worked with, say, Six Sigma in a very long time (and that occasion was pretty superficial, heh).  I'm sure my statistics are rusty.  I may be grossly mis-understanding/representing the complexity or cost of these controls or inspection or testing procedures.

But if no one steps up to critique my points, I'm left to assume I have asserted them correctly and rightly, that most people here generally agree with them...or at least don't disagree strongly enough to complain about it. 

Or not.  I found it a bit long and have not read all the detail.  In general, comparing an FPGA to an op amp or even a logic gate to an op amp is not very valid in most considerations.  They are very different things.  Digital is designed so you can *mostly* ignore the analog aspects.  The op amp very much an analog device and the real problem here is that it is being used as a digital device.  It's really a 0-5V to ±12V level shifter.  That's the problem.  There's no reason at all to be testing anything about the op amp's drive.  Pick an op amp that is quantified, or use a different, and better, appropriate even, device!

I would love for my arrogance to be knocked down a peg, as it needs to from time to time, but, y'know, I'm only going to do so much research on my own here.  Someone, please, be the change you want to see! ( ?? )

Tim

Ok, consider it knocked down.  But I will return and finish reading later.  Not sure how much later...   

[bdunham7]

As for explaining why it apparently works anyway -- I wonder how strict most (all?) receivers are?  What's the penalty for violating the above specs?  Does every receiver just fail outright?  Do they in fact specify a much looser/narrower threshold, ala RS-232 for example, making the extraordinarily tight transmitter threshold absurd and useless?  Do they even measure source resistance (perhaps with a dithering load current or resistance -- and if so, at what frequency, waveform, pattern, etc.?)?  How can they tell between a slightly lower Thevenin Vth and Rth, versus a higher (of both)?

Well, that's what got me started in the first place--realizing that this was J1772.  This is a very old, crude 'signaling' setup intended to be capable of implementation with very simple electronics.  Essentially a +/-12V 1kHz square wave with a duty cycle that indicates the EVSE capacity is sent to the car and the car responds by loading the + side of the square wave with one of three resistances to indicate that 1) it is there 2) it is ready to charge 3) it needs ventilation.  The last one is pretty obsolete, it came from the days when EVs used lead-acid batteries. 

The car only has to detect that it is plugged in and then determine the duty cycle of the square wave, in addition to switching in the appropriate resistor when it is ready to charge.  The EVSE has to read the pilot signal to make sure that the -12V signal is not attenuated and then from the + signal determine which of the 3 modes it might be in (corresponding to about 9V, 6V or in the now obsolete ventilation mode, 3V)  So as you can imagine, you don't need a great deal of precision to accomplish this--which is appropriate given the conditions (electrical noise, weather, etc) that it operates in.