Specifications and Design Tolerances

[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.

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)?

It works "anyway", because the parts he has used, appear as a voltage source within the required spec and a series resistance of about 200 ohms.  He changes the series resistor in the circuit from 1 kohms to 820 ohms to compensate.  The problem is, this characterization of the part is not assured, since it's not in the data sheet.  Tomorrow, the next batch of parts may only drive to 11.0V or 10.5V or even 9V which is all you can assure from the data sheet! 

No, not at all likely, but the room for error here is not terribly large, compared to what the data sheet indicates.

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

Are you a lawyer... being paid by the word?  Can you say this part in 20 words or less?

[bdunham7]

Except that there's absolutely NO reason to use the part, when many alternatives are available.

Now there I cannot possibly disagree, a J-FET op-amp would be the last thing I'd think of.  My guess would be that the design uses them elsewhere and there was a spare one in a dual or quad package available.  Thrifting  a design is an art unto itself and I've gained some respect for those that do it.

[bdunham7]

It's really important in high duty (read:80A) chargers that output 96% duty.

OK, that makes sense, especially if you don't know exactly how the vehicle is going to read the duty cycle.  Do you know if the standard specifies what section of the signal the vehicle is required to use to read the duty cycle?

[gnuarm]

It's really important in high duty (read:80A) chargers that output 96% duty.

OK, that makes sense, especially if you don't know exactly how the vehicle is going to read the duty cycle.  Do you know if the standard specifies what section of the signal the vehicle is required to use to read the duty cycle?

Is this a multiple choice question?  What are the options?   

The signal amplitude varies with the state.  The PWM is enabled in state B, after the car has pulled the +12V to +9V.  The next state, PWM +9V/-12V, is the when the car drops the +9V to +6V (state C) to say it is ready for power. 

I suppose the car could measure the pulse width in State B or C, either one.  Since it is up to the car to draw the power, it's in no hurry to take the reading.  I don't know if the car is supposed to continue to measure the PWM for changes.  Ok, I see in the spec they say the car has 5 seconds to modify the current draw when the pilot PWM changes.

[T3sl4co1l]

It works "anyway", because the parts he has used, appear as a voltage source within the required spec and a series resistance of about 200 ohms.  He changes the series resistor in the circuit from 1 kohms to 820 ohms to compensate.  The problem is, this characterization of the part is not assured, since it's not in the data sheet.  Tomorrow, the next batch of parts may only drive to 11.0V or 10.5V or even 9V which is all you can assure from the data sheet!

Ok... but those variances can be tested.  They are observable.  A sampling will show them.  I don't know what's so mysterious about your as-yet unexplained "process" that's so untestable here?  Surely you must be using a different meaning of "process" than what is coming to my mind?

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).

Are you a lawyer... being paid by the word?  Can you say this part in 20 words or less?

Beats me.  You're insisting upon "standards" and "process"... If you're that committed to standards, I'd have thought the verbosity would be appreciated?  Are you not actually, then..?

Tim

[gnuarm]

It works "anyway", because the parts he has used, appear as a voltage source within the required spec and a series resistance of about 200 ohms.  He changes the series resistor in the circuit from 1 kohms to 820 ohms to compensate.  The problem is, this characterization of the part is not assured, since it's not in the data sheet.  Tomorrow, the next batch of parts may only drive to 11.0V or 10.5V or even 9V which is all you can assure from the data sheet!

Ok... but those variances can be tested.  They are observable.  A sampling will show them.  I don't know what's so mysterious about your as-yet unexplained "process" that's so untestable here?  Surely you must be using a different meaning of "process" than what is coming to my mind?

Why would I want to test parts before I use them?  There's incoming inspection, but who actually mounts their parts in a chip tester to repeat the testing that was done at the factory?  For many devices, such as op amps, the testing is the lion's share of the costs. 

This is what I'm talking about.  People are coming up with all manner of excuses for this design, instead of just fixing it!

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).

Are you a lawyer... being paid by the word?  Can you say this part in 20 words or less?

Beats me.  You're insisting upon "standards" and "process"... If you're that committed to standards, I'd have thought the verbosity would be appreciated?  Are you not actually, then..?

Tim

I believe I've referred to the J1772 standard, which is the reason for this design existing.  I've referred to the specification of the LF353, which is the document that should guide the part's use.  The "process" I'm referring to is the semiconductor "recipe" used to make the parts, that can not be perfectly controlled and results in variations, or is intentionally modified for some reason, which results in changes in the device, which are not reported as long as the device continues to meet the data sheet.  Your assertion about verbosity is absurd.  Clearly, you have nothing further to contribute to this conversation.