Incorrect pilot voltage

[Ludo multicult]

Hello, I'm trying to build a charger based on OpenEVSE. I'm using 2 power supply of 12V for generating the -12V/+12V. However, I never reach +12V (rather 10.6V). When I start the pwm the Vpp is 7.6 only (instead of 9V).

I'm using the LF353.

For the capacitors C5/C6, I used polarized ones because I didn't had 1uF value with not-polarized.

The pilot resistor R1 I've is 1k.

Does someone got similar behavior with the OPENEVSE circuit?

[Sreehari G]

Find another power supply from google that can get 12 v and -12 v . If you can't get it, try it using a variable power source or from a 12-volt battery source

--
You received this message because you are subscribed to the Google Groups "OpenEVSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openevse+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/2684865c-1134-49d0-a730-d738852089e1n%40googlegroups.com.

[gnuarm.del...@gmail.com]

Have you disconnected your power supplies from the loads and measured the output voltages?  It is likely the supply is overloaded. 

When I search on LF353, it appears to be an opamp.  What is this part?

You can only use a polarized capacitor if the voltage never goes to the opposite polarity.   Operating a polarized capacitor with reverse polarity will cause damage.  You need to use the correct value and type of parts as called for in the design.  This can be *very* important for safety.

Rick

[chris1howell]

Reduce the resistance of R1 - 1k to compensate for the internal resistance of the LF353 Opamp.  Aim to hit the 9v of State B and 6v of State C.

--

You received this message because you are subscribed to the Google Groups "OpenEVSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openevse+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/14f7b219-f31d-47f5-99c5-618d259bfc7an%40googlegroups.com.

[gnuarm.del...@gmail.com]

It is very unlikely that an opamp would have significant output resistance for this circuit.  If it does, it is defective.  The LF353 output can not drive to the rail.  The OP needs to choose another opamp that can drive to within a few tenths of a volt of the + rail.  This is important because the 1kohm output resistor is part of a divider circuit the car uses to control the charging operation and indicate state.  If the driven voltage is not very close to +12V, the divided voltage may not be close enough and result in an operational error.

Rick

[chris1howell]

A LF353 plus a 820ohm R1 resistor results in a perfect 9V state B and 6V State C. Who cares if unplugged state A is at the low end of the range? Nothing is connected to know. You could use a rail to rail to main 12v but again nothing is connected so it does not matter.

To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/1e6a0f4a-4c1d-4663-b29d-493a9337c8c2n%40googlegroups.com.

[gnuarm.del...@gmail.com]

I don't like to use unspecified behavior of parts.  You can't rely on that to work with every part you buy or the same part from different makers. 

This is why they have data sheets.  So you can know how to use the right part for the right application.  The LM353 is not the right part. 

Also, when the cable is not plugged into the car, the +12V state tells the EVSE it is not connected to a car.  So that threshold is very important.  Of course, if you are designing a custom EVSE, intended only to be used with your own design for a BEV, then you are free to do whatever you wish.

Rick

[chris1howell]

The LM353 with 820 ohm resistor is within spec for all states even State A. The LF353 also has a high slew rate so it meets spec for rise and fall. It has passed certification with UL in the US (Wattzilla) and CE in Europe (EmonEVSE and Faradice).

Here are the nominal voltages and the SAE J1772 Standard:

State A - 11.69v

State B - 9.04v

State C - 6.18

If you notice there is a bunch of grey area between states. 9.56 - 11.40v 6.49v - 8.36... For greatest compatibility and noise rejection OpenEVSE splits the full range. Even if State A were out of spec (which it isn't) OpenEVSE would handle it fine as long as it is not below 10.5v.

Anything above 10.5 is State A

7.5v to 10.49v is State B

4.5 to 7.49 is State C

4.49 and below is State D

So why is the LF353 not the right part if all parameters are within US and Europeen specifications...?

To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/34beedf1-9c7a-443f-b63b-fdc92127b07cn%40googlegroups.com.

[gnuarm.del...@gmail.com]

The behavior of the LF353 you are counting on, is not specified for the part.  By misusing the part this way, you will likely have problems in a production run if you change suppliers of the part, or simply get parts from different batches. 

This is not how engineers design products.  They use the right parts, in ways that are specified.  Another part that is specified to drive close to the ±V rails will give your an output voltage to meet the EVSE spec, reliably.  Why use a poor part rather than an appropriate part?

BTW, you are misusing the term "nominal".  If you understand that, you might understand the problem. 

> Here are the nominal voltages and the SAE J1772 Standard:

> State A - 11.69v

> State B - 9.04v

> State C - 6.18

If you build 100 of these units, will all 100 have an output for state A of 11.69V?   What will the output for state C be if the resistor in the car has a tolerance of ±2%, ±5%, ±10%?

This is wrong, as indicated in the graphic you provide from the standard.

> Anything above 10.5 is State A

> 7.5v to 10.49v is State B

> 4.5 to 7.49 is State C

> 4.49 and below is State D

What you fail to understand is the nature of tolerances.  The standard provides the ranges as indicated to allow for the threshold in the EVSE to be other than "dead on perfect" (unobtainable in any device), and for noise tolerance.  It's not like it is very easy to have anything connected to the power line without some ground noise.

The max and min values in the spec allow for component tolerance.  The margin between the max of a lower voltage (like state C) and the minimum of a higher voltage (like state B1), provides the tolerance for setting the detection threshold in the EVSE and noise on the line.

Finally, I would point out that you don't know that UL and CE standards have nothing to do with functionality.  I could design a pet rock and sell it to be used as an EVSE, yet it would pass all requirements for UL and CE certification. 

So please don't ignore a specification, especially when you don't understand the basic principles of sound electronic design.  Please don't think you know more than professional engineers.

I don't think you are going to understand what I am talking about.  So I'm not going to reply further.  I am simply giving a warning to others, who wish to build reliable equipment, to not use the LF353, but to pick another device that is rated to output a voltage closer to the rail, to assure that it works properly.

--

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209

[chris1howell]

Um Rick... I am the engineer that designed OpenEVSE and personally worked with each company and UL. A pet rock would not pass UL 2231, UL 991 or UL 1998. 

OpenEVSE has shipped over 20,000 units with the LF353 using chips from TI, On Semi and Fairchild all batches perform within the defined SAE J1772 spec.

By nominal I mean the median of the the values for the random units we tested, the numbers are right from our internal testing.

You still have not explained how we are misusing the part. We do not need rail-to-rail output, we just need to be + or - 0.6v. We are using the LF353 exactly is it is intended. We had a tolerance in the spec and designed a circuit that will meet those specs.

If you have a better part that has a high slew rate and low cost please make a recommendation. Insulting our design and intelligence is not going to help anyone.

To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/12ba3aea-5da2-49a4-a53a-799e943062ccn%40googlegroups.com.

[gnuarm.del...@gmail.com]

Chris,

I have explained it very clearly.  You are depending on the opamp internal voltage drop on the output, which is not typically linear, to be a part of the specified 1 kohm series resistor in this circuit.  There is no specification on the LF353 part as to this internal drop. 

I have seen very simple parts abruptly fail in production, because the same part number was bought from a different vendor.  The design engineer used the part in a circuit that depended on functionality that was not specified.  When bought from a different vendor, the part did not work the same in this unspecified manner and production defects went through the roof.  A similar issue happened when a manufacturer changed their process, maintaining all the specifications in the data sheet, but with a change in an unspecified parameter. 

Tell me this.  An opamp is normally operated in a way that the output is defined in a simple way from the inputs and the feedback elements.  The high gain of the opamp provides a very, very small error from the ideal case.  Why on earth, would you want to change that concept and use an opamp in a way that the output is clearly not providing the output intended?  Why would you not use an opamp that has a rail to rail output, or use a 15V supply and a circuit that generates a ±12V output from the op amp? 

For that matter, is an opamp even the right part for this circuit?  The function is of a level shifter, to convert the 0V to 5V CMOS logic signal to a ±12V level.  The way the LF353 is being used seems more like a comparator.  I would never even think of using an opamp in this way. 

I believe a simple 2:1 analog mux would do the job quite well, since it only needs to switch between +12V and -12V with the EVSE controlling the pulse width.  It seems to me the opamp is not even the right component to use. The conceptual diagram often shown for this design typically shows a 1 kHz generator with a ±12V output, along with a relay switching over to a direct +12V connection.  In reality, both the 1 kHz generator and the "relay" can be implemented with the analog switch.  It simply needs to be able to drive 12 mA into a 1 kohm load.  That's not a hard requirement for an analog switch to meet. 

And the best part, is that the switch can do the job without relying on any unspecified behaviors!  Win-win!

https://www.digikey.com/en/products/filter/interface/analog-switches-multiplexers-demultiplexers/747?s=N4IgjCBcoCwMxyqAxlAZgQwDYGcCmANCAPZQDaIATHABwBsArAAwhGXuU0OvgCcMAdhosiYBrzG8eNATC49KDMHSZS2dAWCYQ2c3rxFUmNGAZ5g4dC9wC6RAA4AXKCADKjgE4BLAHYBzEABfUV4GASQQVEhMXEIScnAGDQUTcPUGGgVGbjZaQ2oBNSo4IQUSnKpTHSpOAUp8uCY08Dg5BlsHZ0g3T18A4L4rCKiY-CJSSAoLAXbqujhxOh54GEZEOxAnF3dvfyCQmiloSPRsMfjJkBYbAfr%2BYdPY8YTqyhANre6ASR9HPD88B59iAALRvY5RTwAVziEwoFSkNyIIMQEKg0NhL2ugQGS2OXgAJi4QVpqp8QDxHABPex4FwYHCoHFAA

I've already winnowed down the parts to look at.  I didn't know if you wanted a single or a double channel device, so both are included.  Sorted on price the second an third in the list offer series resistances of under 10 ohms.  21,000 in stock.

> If you have a better part that has a high slew rate and low cost please make a recommendation. Insulting our design and intelligence is not going to help anyone.

I have not insulted anyone's intelligence.  I'm simply pointing out facts about the design and seemingly erroneous habits in design.   These are objective statements.  You could call them criticisms, but that's not a negative connotation.  It was long ago that software developers learned that they needed egoless programming, allowing others to inspect and critique your code.  Pointing out design problems is not the same as insulting a design. 

This error is not a matter of intelligence as many people make the same mistake.  The flaw in this design, simply has not risen it's head in practice yet.  With the current semiconductor shortage, part substitutions are very common.  This is an example where a seemingly safe substitution can bite you in the rear, possibly not showing it's head until units are shipped.  Or you may get lucky and never see a problem.  I prefer to design out such issues to assure I never see such problems.

If you want to throw out credentials, I've been an engineer for over 45 years, working on systems that range from large, powerful computers with ECL circuits (similar to the Cray) to tiny designs that are optimized for space and power.  My current product has sold 20,000 units and we are respinning it for another 20,000 units because of EOL parts.  Looks like this design is going to make it to a 22 year run!  At least, according to my customer, a major networking equipment supplier.

Rick

[gnuarm.del...@gmail.com]

I can't find this table of voltages in the J1772 spec.  In fact, it does not look like anything in the spec, in terms of formatting.  Is this table from your documentation?  I assume you calculated it from the tolerance on the open circuit voltage and the various resistors? 

As I've said before, the flaw in your design is depending on every LF353 behaving like the chip in your test circuit.  The data sheet specifies the output voltage to be at least ±12V when powered by ±15V.  There is no reason to think the LF353 can be relied on to work correctly in your circuit over PVT (Process, Voltage, and Temperature).  You can test for Voltage and Temperature, but not Process.

Rick

On Tuesday, November 22, 2022 at 5:19:33 PM UTC-4 Chris wrote:

[chris1howell]

There is no flaw in the design, possibly a still within specification accuracy improvement at State A while unplugged. 

The LF353 is used as a comparator as you mention, this is a standard building block for an OpAmp. The LF353 does have a specification for "Input Offset Voltage" typical 5mv Max 10mv which has a predictible affect on a pilot/vehicle voltage divider circuit. Sure a +-15v supply regulated to +-12 with a switcher may be more precise, however it would add additional components, complexity and very expensive recertification with UL, Intertek and retesting for CE.

The table "Control pilot state voltage range from mated charge coupler interface"  is from SAE. Here are locations of the table in the versions of the SAE specs OpenEVSE has:

SAEJ1772 2017-10 - Table 2 Page 14 and Table 3 Page 15 (latest version)

SAEJ1772 2012-10 - Table 4.2 Page 12

SAEJ1772 2010-01 -  Table 4 Page 14

SAE3068 2018-04 - Table 7 Page 30 (latest)

SAEJ1772 2017-10 Table 2B Page 14 has an expanded range for "Control Pilot state recommended boundary voltage range ... for the EVSE" This still leaves some undefined space between 7.01v - 7.99v and 4.01v and 4.99v. OpenEVSE took the recomendation a little further and used 4.5v and 7.5v as the line without an undefined block in the default OpenEVSE firmware. 

There is more detailed information on both pilot voltage and state detection in the latest version SAE J1772 2017-10 on Page 105/106.

To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/b526e967-2c02-42f8-bd1e-8115bc70bc3dn%40googlegroups.com.

[gnuarm.del...@gmail.com]

On Monday, November 28, 2022 at 12:25:07 PM UTC-4 Chris wrote:

There is no flaw in the design, possibly a still within specification accuracy improvement at State A while unplugged. 

There is no flaw in the design that has shown up in operation.  Maybe I did not explain this clearly.  The LF353 from TI is not specified for exactly ±12V power rails.  The closest they provide is ±15V rails.  Then the output is rated to reach ±12V into a 10 kohm load.  That's 3V short of the power rails.  So on ±12V, the output of the op amp could be as low as ±9V.  That's from the data sheet for the LF353 op amp.  Your design is counting on the "typical" behavior which is not as severe.  However, typical is exactly that, and not guaranteed by the manufacturer. 

That is the design flaw.  This is not a failure that you can test.  It may not happen for years.  Then something changes in the process, and the output drive still meets the data sheet spec, so they ship the product, but it no longer works reliably in your design. 

 

The LF353 is used as a comparator as you mention, this is a standard building block for an OpAmp. The LF353 does have a specification for "Input Offset Voltage" typical 5mv Max 10mv which has a predictible affect on a pilot/vehicle voltage divider circuit. Sure a +-15v supply regulated to +-12 with a switcher may be more precise, however it would add additional components, complexity and very expensive recertification with UL, Intertek and retesting for CE.

I have no idea what, "this is a standard building block for an OpAmp" means.  They make comparators for a reason.  While you can use an op amp that way, it is less than optimal.  In this case, it doesn't cause any problems.  The real issue is that the design requirements do not call for either a comparator or an op amp.  The design requirement is for a level shifter, from 5V CMOS to ±12V.  An analog switch mux is a much better implementation with none of the issues of using an op amp and eliminating the two resistors.

The table "Control pilot state voltage range from mated charge coupler interface"  is from SAE. Here are locations of the table in the versions of the SAE specs OpenEVSE has:

SAEJ1772 2017-10 - Table 2 Page 14 and Table 3 Page 15 (latest version)

SAEJ1772 2012-10 - Table 4.2 Page 12

SAEJ1772 2010-01 -  Table 4 Page 14

SAE3068 2018-04 - Table 7 Page 30 (latest)

SAEJ1772 2017-10 Table 2B Page 14 has an expanded range for "Control Pilot state recommended boundary voltage range ... for the EVSE" This still leaves some undefined space between 7.01v - 7.99v and 4.01v and 4.99v. OpenEVSE took the recomendation a little further and used 4.5v and 7.5v as the line without an undefined block in the default OpenEVSE firmware. 

I don't have the more recent spec.  The JAN2010 version only specifies the State A voltage, table 4, page 14.  So the specification of these voltages is even more restrictive on implementation. 

 

There is more detailed information on both pilot voltage and state detection in the latest version SAE J1772 2017-10 on Page 105/106.

This is all interesting information, but not terribly relevant, especially since it is no longer part of the spec.  What is important to understand, is the purpose of the "invalid" region, is this provides the noise margin to prevent false detection of a wrong state. 

Still, that is not relevant to the potential problem of using the LF353 in the manner it is used in the OpenEVSE design.

If you don't believe me, contact TI support and ask them if you can rely on the output drive to be 11.69V open circuit or any of the required voltages, when loaded per the J1772 spec.  I'll bet whatever you want, that they will not support any voltage that is not in the data sheet.

Rick

[Mitchell Wolrich]

Tens of thousands of OpenEVSE's have been built since 2012, when it was first designed.  No one has reported any issues with the Pilot signal/voltage.

Have a nice day

Mitch

--

You received this message because you are subscribed to the Google Groups "OpenEVSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openevse+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/c5bfdf30-f1f4-4612-8052-042e97331eacn%40googlegroups.com.

[chris1howell]

I like the switcher idea and plan to test it. Thank you for the suggestion.

The 2010 version of J1772  has the same charts in the appendix with the same voltages. (Page 32 and 33). I have never found anything in any version of J1772 that recommends what to do in the Invalid areas. This may be why they took it out and added language to implement the ranges at the EVSE manufactures discreretion. Generating an error at 10.01v would be silly and provide no utility, we chose to expand and split each segment providing no invalid area.

OpenEVSE does not count on 11.69v. Anything over 10.5v would work as intended.

On Mon, Nov 28, 2022 at 1:20 PM gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "OpenEVSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openevse+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/c5bfdf30-f1f4-4612-8052-042e97331eacn%40googlegroups.com.

[chris1howell]

@Mitch

You are correct, the number is a bit north of 20,000 (that we know about). It is likely far higher as anyone can use the open design.

To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/CAMG-TWaD6SLK9zp2TwVb%2B7YNYSUY127am4d1qytjarHTGXgGkQ%40mail.gmail.com.

[gnuarm.del...@gmail.com]

I'm having a hard time adjusting to the top posting, but that's what people do here, so when in Rome...

By "switcher", I assume you mean using a switch instead of an op amp?  That would be a good way to go.  But the op amp can be replaced with one that is specified to run to near the rails.  There are tons of them.  I don't know what other specs this op amp needs to meet, but I'm sure there are many replacements that will work in your circuit without changes.

I don't follow what you are saying about 11.69V.  You are counting on the op amp to output a voltage that is not assured in the data sheet.   Pick a number.  Anything above 9V is not specified that I can see.

The "invalid" region is noise margin.  The state is guaranteed within the specified region.  After considering the addition of noise, anything in the "invalid"' region can cause errors in the field.  Much like your op amp, a value in the "invalid" region would probably work, many, many times, before anyone saw a problem, but under the right (or wrong) conditions, it will fail.  RS-232 is specified the same way.  Above 3V is a high, below -3V is a low.  Anything between the two is "invalid", meaning a problem with the driver or a connection or a partial short somewhere, that makes the channel more susceptible to noise.

BTW, you can't actually say your design is working in the field.  All you can say is no one has returned a unit as failing because of this.  This could result in flaky operation where the car starts charging, then stops, because the EVSE detected a change in state that wasn't there.  This would likely self correct at some point and resume charging.  This issue would result in less noise immunity which might only show up when the furnace kicks in, etc.  The fact that no one has actually returned a unit is great!  But it doesn't mean the design is sound. 

If you choose to ignore this issue, because you think the impact is not enough to worry with, fine.  But I think it is a mistake to think there can not be a problem, or even that there is no problem.  You just haven't seen it yet.  Many products have flaws that are essentially in the noise, and even when discovered are not fixed, because of the cost.  This one can be fixed by substituting a part, probably at no cost other than a bit of your time.

Rick

[chris1howell]

Let's try in graphical format. 

Blue is the J1772 spec for Pilot output voltage.

Red is J1772 Appendix historical spec for Pilot Read voltage. J1772 states to be implemented at EVSE Manufacturer's discretion. 

Light Blue is J1772 Appendix historical sped for "Invalid"

Green is the tested range of OpenEVSE controllers with LF353 and 820 ohm resistor Minimum, Maximum and Median

Black is the Analog read point in OpenEVSE firmware. OpenEVSE did not implement historical "Invalid"

So what would you do if the EVSE reads a pilot of 7.01v (historical "Invalid") at some point during a charge session? Stop the charge session? A 7.01v pilot reading does not represent a safety issue, maybe ther is a car lift nearby and every time it is moved there is a ton of noise. J1772 also never specified a behavior for "invalid"... OpenEVSE keeps on charging.

Real world, OpenEVSE worked with a major manufacturer moving from gasoline vehicle to EV. Their vehicle was unreliable charging on many various stations. They strictly policed the pilot voltage and stopped charging if a single reading was out of the Blue pilot output range. This provided zero margin for noise and unnecessarily stopped charging for something that is not a safety issue. In addition monitoring pilot voltage is the job of the EVSE not the vehicle. All the vehicle needs to know is DC HIGH = EVSE not ready - 1000hz = EVSE ready to provide power - DC LOW = EVSE ERROR. 

I am not sure I can agree with your interpretation of the TI datasheet 3v drop for this application. The 10k load chart in the datasheet shows a much lower drop at 10v and even lower at 5v. The voltage OpenEVSE picked is 10.5v as seen on the chart anything above will read as State A. None of our samples have tested lower than 11.53, but if one happened to output a lower voltage there quite a bit of margin. With nothing connected in State A there would be no compatibility issue as long as State B and C are Okay.

To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/432282ba-e1bf-4257-82ff-02b20f697f6an%40googlegroups.com.

[z0ner]

Hi Chris,

I've been happily using OpenEVSE for several make/models of EVs starting in 2012.  240V/30A going strong, not a single failure.  IN TEN YEARS.

I understand the need for engineers to debate and have civil discourse, but good ol' Rick here is simply posturing for the sake of posturing, making himself look like an ass in the process.  There will always be those types of people that have to bellow in order to make up for their inadequacy.  When Rick can practice what he preaches by designing an economical, yet safe and effective EVSE, bring it to market, and support it - I may actually read his wall-o-text diatribe instead of skipping over it.

Now to shut down this entire thread because I am an 8 year old child, I'm done with this conversation.  You are free to do as you wish.

Well thanks to Rick for giving us permission to do as we wish.

Happy Trails,

Jeff

On Tue, Nov 29, 2022 at 12:21 PM Mitchell Wolrich <mwol...@gmail.com> wrote:

Rick,

It’s charging an EV, specifically controling/interpreting the pilot signal.

It’s not Rocket Science, worst case scenario someone will be late because their car failed to charge, but this hasn’t occured or been reported as an actual issue.

Chris’s circuit may not pass your “design review”, but in over 10 years of real world deployment & usage, with thousands of devices in use, built by multiple people, sourcing parts from numerous sources, no serious issues have surfaced, no one has been injured, no EV’s have been damaged.

Do not be concerned about issues that do not exist, there are plenty of real world problems to solve.

Mitch

Sent from my iPad

On Nov 29, 2022, at 2:44 PM, gnuarm.del...@gmail.com <gnuarm.del...@gmail.com> wrote:



"Tested range" is why you can not understand what I'm saying.  Let me try it a bit louder... YOU CAN'T TEST THE MANUFACTURER'S PROCESS!

I didn't read past that. 

I don't understand why you can't grasp this fundamental issue.  Relying on the device to continue to operate in exactly the same way from batch to batch is only practical if you test the parts to this parameter, when you receive them. 

At first, I thought this was a simple oversight, a mistake that is commonly made, even by experienced engineers.  But the fact that you continue to double down on the idea that you can mitigate process variation, or more accurately, ignore the issue of process variation, is saying a lot more about your engineering philosophy.

I am basing my claim on Table 6.5 Electric Characteristics, item 6 (my number), at ±15V power. 

VOM  Maximum peak output voltage swing RL = 10 kΩ  ±12  ±13.5  V

 

±12 V is the min, the worst case.  ±13.5 V is the typical. 

The typical value should coincide with the graph you are using, that is also typical.   But even 13.5V is outside the range for State A, when adjusted for ±12V power.  With ±12V power, I would expect to see ±9V output worse case.  

The graph, Figure 2, in the TI data sheet shows with a 4 kohm load (state B), the typical output is more than 2V from the rails.  With 12V power supplies, and a ±5% derating giving 11.4V, the resulting output of the op amp could be as low as 9.4V.  A bit lower even since the actual load resistance is a bit less than 4 kohm. 

You seem to be relying on fudging your thresholds to account for the poor part choice. 

There is no justification for relying on "typical" values rather than worse case.  That is a mistake made by many, but only as a mistake.  Few will rely on such characterizations, because of the problems that can result.

I thought you were starting to understand the nature of the problem, but you seem to have retreated back into defensive mode. 

Until you understand that data sheets are to be respected, there is nothing further for us to discuss.  None of your testing is at all relevant in this issue.  Not relevant at all.  Either change the design to resolve the conflict with the data sheet, or at least stop embarrassing yourself.  I'll say it again, all you need to do is use an op amp that is specified to drive close to the rails.  Yeah, it's that simple.  Pick a part that is qualified for the task in which you are using it.  Not only is your approach invalid, it is very wasteful of engineering resources.  Using a correct part will not only work, but never require justification.  If your circuit fails in any way that results in damage to property or harm to a person, this actually crosses the line to a criminal act, since you are in FULL KNOWLEDGE of what you've done.  It's' not much different from the Pinto gas tank.  As soon as you replaced the 1 kohm resistor with the 820 ohm resistor, you showed that you knew of the problem and chose to design a work around that was not in compliance with the data sheet.

I'm done with this conversation.  You are free to do as you wish. 

Rick

To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/0882051a-9454-4c42-8830-c552a194b43cn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "OpenEVSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openevse+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openevse/050296B3-A275-40D7-B676-0A1C31729E07%40gmail.com.

[袁波]

What are the main test contents of UL991 and UL1998? Does OpenEVSE have reports on these?

z0ner 在 2022年11月30日 星期三上午9:48:09 [UTC+8] 的信中寫道：