I've placed the order for what I hope will be the final versions of the OpenEVSE II and Hydra boards. I'm taking a bit of a chance in ordering them both at once, since I had planned to use one to validate the design of the other. But I've done enough testing with the OpenEVSE II prototype (0.3) boards that I'm fairly confident at this point.
New for the Hydra 4.0 design is ground impedance monitoring and relay testing. This brings the Hydra if not into full UL compliance, then at least asymptotically close. Originally, I had intended to leave the GMI system out of the "splitter" variant, but in adding a 1 mA current limit to the ground monitor circuit, I'm fairly confident that the test can be present and still not trip the GFI in the host EVSE - even if it's the ultra sensitive 5 mA type. If it turns out to be problematic, it can always be a "no-stuff" option on the AC board. Unlike OpenEVSE II, there won't be a voltmeter in the Hydra. There simply aren't any remaining analog pins on the controller. Even if that weren't true, there isn't enough room on the AC board for more HV components with sufficient creepage space around them.
OpenEVSE II is a reimagining of OpenEVSE. It changes completely the ADVPWR functionality. Automatic L1/L2 selection is done with an isolated analog voltmeter. The ground monitoring and relay testing systems can be done continuously rather than in isolation, as in the OpenEVSE base design.
Recent work has been done to add temperature monitoring to OpenEVSE. There isn't enough room on the logic/display board for an added sensor, but I did hedge my bets by adding an i2c header to the logic/display board. That can be used to add a remote i2c temperature sensor that can be placed in an interesting spot. But the ATMega controller chip has a built-in thermometer. It isn't tremendously accurate, and it can be affected by the controller's own activity. This has been particularly noted in testing with OpenEVSE, but in that case, the controller is mounted on the opposite side of the board from the main AC/DC power supply, which likely is responsible for quite a bit of conductive heating. OpenEVSE II's controller is well isolated from other nearby heat sources, so it should do much better. In any event, the temperature sensor is supposed to be a safety limiter rather than a critical measure of temperature (such as for a thermostat or the like), so its absolute accuracy is relatively unimportant. The real purpose is to attempt to shut down charging before the ambient temperature causes the controller to fail.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.