Monitoring temperature

[Jean-Michel Olivier]

Here is an extract of my source code for temperature monitoring with the ATmega328P's internal temperature sensor.

You must calibrate gain and offset. For this purpose, I use a DS18B20 1-wire temperature sensor.

This function costs around 300 bytes of flash memory.

/** Temperature alarming
    ATMega internal temperature sensor.
    Two-point calibration needed: high and low temperature measures. \n
    Points can be obtained with OneWire and debug logging enabled.
    */
#define HIGH_CRITICAL_TEMP           75 ///< High threshold temperature alarm, °C
#define LOW_CRITICAL_TEMP           -30 ///< Low threshold temperature alarm, °C
#define TEMP_UPDATE_DELAY          5000 ///< Temperature update delay, ms
#define TEMP_READING_DELAY            6 ///< Delay for voltage to become stable enough for temperature reading, ms
#define TEMP_GAIN                1.1099 ///< (THigh Real - TLow Real) / (THigh Arduino - TLow Arduino) | 0 to disable alarming
#define TEMP_OFFSET              393.21 ///< TArduino * TEMP_GAIN - TReal                              | 0 to disable alarming


/** Update EVSE temperature */
void UpdateTemperature()
{
  double TempArduino;
  unsigned int wADC;
 #ifdef ONEWIRE
  double TempDallas;
 #endif // ONEWIRE

  if (((unsigned long)(millis() - g_TempUpdateDelayMS) >= TEMP_UPDATE_DELAY)) {
    // Read temperature from ATMega internal sensor
    // Set the internal reference and mux.
    ADMUX = _BV(REFS1) | _BV(REFS0) | _BV(MUX3);
    ADCSRA = _BV(ADEN)  |    // ADC Enable
             _BV(ADIF)  |    // ADC Interrupt Flag
             _BV(ADPS2) |    // ADC Prescaler Select Bits /128 = 125kHz clock
             _BV(ADPS1) |    //  |
             _BV(ADPS0) |    //  |
             _BV(ADPS0);     //  |
 
    delay(TEMP_READING_DELAY);   // Wait for voltage to become stable.
 
    ADCSRA |= _BV(ADSC);         // Start the ADC
 
    // Detect end-of-conversion
    while (bit_is_set(ADCSRA, ADSC));
    wADC = ADC;
 
    // The returned temperature is in degrees Celcius.
    TempArduino = (wADC * TEMP_GAIN) - TEMP_OFFSET;
    g_EVSETemperature = (int8_t)TempArduino;
 
    if ((g_EVSETemperature > HIGH_CRITICAL_TEMP) || (g_EVSETemperature < LOW_CRITICAL_TEMP)) g_EvseController.SetFault(TEMP_FAULT);

   #ifdef ONEWIRE
    sensors.requestTemperatures();
    TempDallas = sensors.getTempC(ThermometerAddress);
   #endif // ONEWIRE

   #ifdef LOGGING
    #ifndef ONEWIRE
    sprintf(g_sMsg, "%5dc°C", (int)(TempArduino * 100));
    #else  // ONEWIRE
    sprintf(g_sMsg, "%5d - D: %5d c°C", (int)(TempArduino * 100), (int)(TempDallas * 100));
    #endif // ONEWIRE
    LogMessage(DEBUG, g_psCTRL, PSTR("T: "), g_sMsg);
   #endif // LOGGING

    g_TempUpdateDelayMS = millis();
  }
}

[Craig Kirkpatrick]

Very nice! How do you connect the DS18B20 to the OpenEVSE controller board? Is it connected to the FTDI serial interface? What is the address - is it the same address for every DS18B20? I read just a little bit so far about about One-Wire and realize how nifty it is, and even every DS18B20 has a unique serial number, wow that is nifty.

Thanks in advance for any tips about interfacing the DS18B20. I have one of them but have not yet attempted to add it to my OpenEVSE build. I like that it is insulated so that I can attach it to the fuses which is something I'm reluctant to try with my little I2C temperature breakout board. And using it as a reference for calibration is going to be nicer than the IR contactless approach I was planning.

[Jean-Michel Olivier]

I use an old, V4.2 modified, DIY OpenEVSE board.

But I think you can do the same with any board.
To use OneWire, you need :
- around 3KB of flash available.
- a digital pin available. You can disable some other feature to get flash memory and a digital pin.

Here's the code :
#define ONEWIRE              ///< OneWire - MAXIM-Dallas temperature sensor DS18B20 - Calibration of ATMega internal temperature sensor - 2970 bytes
                             //   Temperature calibration - Need to disable other features (e.g. LCD) to free enough memory.
#include <OneWire.h>                   ///< To get OneWire sensors...
#include <DallasTemperature.h>         ///< ...and especially DS18B20 temperature sensor to calibrate ATMega internal sensor

// ONEWIRE
#ifdef ONEWIRE
 #define ONEWIRE_PIN                  3 ///< Digital pin
 DeviceAddress ThermometerAddress;
#endif // ONEWIRE

#ifdef ONEWIRE
OneWire oneWire(ONEWIRE_PIN);          ///< Setup one-wire on digital input pin
DallasTemperature sensors(&oneWire);   ///< Pass the oneWire reference to Dallas Temperature.
#endif // ONEWIRE

void setup()
{
  ...
 #ifdef ONEWIRE
  sensors.begin();
  // search for device on the bus and assign based on an index
  // set lowest (0.5°C) resolution to fasten temperature conversion
  if (sensors.getAddress(ThermometerAddress, 0)) sensors.setResolution(ThermometerAddress, TEMP_9_BIT);
 #endif // ONEWIRE

 // Init temperature - Forced update in first loop
  g_TempUpdateDelayMS = (unsigned long)(millis() - TEMP_UPDATE_DELAY);
  ...
}

void loop()
{
  ...
  // Temperature alarm management
  UpdateTemperature();
  ...
}

[Craig Kirkpatrick]

Very good.  Thanks for the pointers.  I just read the datasheet for the component part and it is amazing what money can buy http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Temp/DS18B20.pdf

The DS18B20 assembly is only $9.95 on this site that I use a lot https://www.sparkfun.com/products/11050

Now I'll see if I can rob a pin from the OpenEVSE V3 board's FTDI header, or else I have to play with soldering to an unused MPU pin which I'm reluctant to do with my not-so-fine-tipped soldering iron. The MPU is a TQFP on the V3 board with 0.8mm pitch pins.

Already I commented out the #define DELAYTIMER which gives me over 5K of ROM free even after some of the additions I made to the 3.2.2 baseline that I'm playing with.  I'll have some fun adding the sensor.

[chris1howell .]

If you are not using Serial CLI or RAPI you have 2 digital pins on the FTDI header. But for scalability and compatibility with RAPI it may make since to do the same function with an i2c sensor.

[Craig Kirkpatrick]

I ordered an I2C temperature sensor with 3.6V limit on its VCC instead of 5V.  I played with a voltage divider to supply the thing since it supposedly only draws less than 1mA. But then adding it to the I2C bus on the LCD backpack broke communications to the LCD.  I just need to figure that out.  I tried adding some 330 Ohm series resistors on SDA and SCL wires to the temperature sensor but that still didn't make the bus happy talking to the LCD.  Additionally I removed the pullup resistors on SDA and SCL on the LCD backpack and that still didn't help.  After yanking out the I2C temperature sensor the LCD was happy again even with the pullups removed.  I'm really a noob with I2C but happy to keep learning new things.

This is the one I'm trying to add  https://www.sparkfun.com/products/11931

And I have this coming to help with the voltage issue https://www.sparkfun.com/products/12009

Likely I'll work more on the I2C temp sensor next weekend, with a busy week of real work ahead of me after the nice holiday break.

I'll play with the DS18B20 today for fun and as a good calibration reference for the internal temperature monitoring.  And I have to agree that leaving RAPI in place on the FTDI header is where the project is heading and I'm not going to derail that.  I still want to leverage Bryan's work adding the GL.iNet to my OpenEVSE later down the road and that depends on RAPI.

[Jean-Michel Olivier]

One digital pin is only needed for the DS18B20 sensor during the calibration process of the ATMega internal sensor.

After that, you need to set up gain and offset and to reflash the firmware with ONEWIRE disabled.

[Craig Kirkpatrick]

JM, thanks for your help and guidance today. I really appreciate it.
Best wishes,
Craig

[Craig Kirkpatrick]

Folks, just an update from me as to what I have working and my thoughts so far.

In the 30A systems built with the fuse block the little power supply gets about as hot as the fuses.  I confirmed that with my IR camera too.  This assumes you set the L2 current limit to 24A like you are supposed to do.

Here are a couple of pictures of what I've been playing with. On the top line of the 2X16 display I abbreviated the status to Chrg so I could use that space to give the calibrated temperature reading from a digital sensor that I zip-tied to one of the fuses in the 30A build.  See my Ford Focus EV which would like to draw 28.2 amps being obedient to the pilot signal and keeping things about 1/2 amp under the L2 24A for the 30A build.  The second line shows the increase in temperature of the MPU from the ambient temperature stored into eeprom when the OpenEVSE was flashed with firmware and rebooted and initialized just once the eeprom ambient temperature value.  Using the eeprom this way means that anybody could take an OpenEVSE controller at room temperature and when it is flashed with this firmware the baseline ambient temperature is stored for life (or until the next firmware flash).  This approach resolves a really big part of the +/-10C accuracy error published for the ATmega328P internal temperature sensor.  Then the only remaining temperature calibration error is gain, meaning if the sensor sees a 10C increase is it really 10C or could it really be 12C for example.  I think the gain is stable from component part to component part but very likely the offset error is the reason for the poor +/-10C accuracy specification from Atmel.  My trick of using the eeprom to store a baseline ambient temperature removes the offset error.

Below you see I put a temperature threshold in the open_evse.h file set to 25C over the ambient temperature value stored in the eeprom.  In practice that threshold should be about 40C meaning really about 60C absolute.  So far my only action on any over-temperature alarm is to alternate the display during charging from Red to the normal Teal background every second.  Blinking Red catches the eye.  If this sort of temperature monitoring gets adopted in the firmware then I think two thresholds could exist, one that blinks Red like this and a higher threshold that either shuts off the relays and stays in an error state or heck it would even be possible to just reduce the amperage to the EV by altering the pilot signal duty-cycle - say some reduction of 33% of whatever current limit is being advertised to the car through the pilot signal.  Let me know if you have any nifty ideas for the handling of the over temperature condition.

In the picture below my car was just done charging and the current was ramping back down to zero.  You also see this charge cycle cost me $0.19 integrating the kWh over the duration of the charge and multiplying by my utility rate.  If the OpenEVSE enclosure looks odd to you, it is the fairly new polycarbonate enclosure now available on the OpenEVSE store as 30A kits or just the enclosure.  I don't know if Chris is working on a 50A kit in this enclosure since a new mounting plate would be needed and I'm not sure of the vertical clearance of the 50A contactor in this enclosure.  The polycarbonate enclosure is sexy if I do say so myself.

[Craig Kirkpatrick]

I forgot to mention that I put the same firmware in my 50A build with the AC-actuated contactor and the internal temperature of the OpenEVSE controller runs about 9C cooler since the temperature increase is mostly due to the power supply.  Not needing to drive a few Watts of extra power to keep the relays actuated helps keep the controller and the supply cooler.  I didn't put a digital probe into the 50A system yet, but from my standing-on-a-plastic-bucket-with-one-hand-in-the-back-pocket approach to temperature monitoring I want to keep an eye on the contactor screw terminals to the pairs of smaller gauge wires to the flexible 40A J1772 cable.  What else could get hot in the 50A system?  Nothing I can imagine.

[Bryan Mayland]

Oddly the thing that gets the hottest are the small parts in my 50A system. I don't know what all of the parts are but I think that's one of the relays and one of those DIP chips, whatever those are. There are a couple other pictures in my Google+ album

https://plus.google.com/photos/+BryanMayland/albums/6094644056604891585

[chris1howell .]

Not too odd, with no fuses and a beefy contactor the 50A runs pretty cool even under heavy load. On the OpenEVSE boards the hottest spot is the 1W flameproof resistor(s) used for the ground verification, then relay driver (on the v3) and next is the DC/DC converter and then the AC/DC power supply

--
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.
For more options, visit https://groups.google.com/d/optout.

[Chris]

Level shifting on i2c is a bit more tricky than standard serial. The level shifter has to be bidirectional so the standard voltage divider or voltage drop techniques will not work.

I am looking at adding a chip to the LCD module to get enclosure ambient temp. This adafruit board would work great as an add-on, I will likely use the same IC on the LCD module. It is ultra-precise, addressable up to 8 per i2c bus, works at 5v and is inexpensive (<$5 for the adafruit board).

https://learn.adafruit.com/adafruit-mcp9808-precision-i2c-temperature-sensor-guide

[Craig Kirkpatrick]

Ah, good find Chris!
I have bi-directional level shifters coming this week for the ambient sensor I picked out. But your part is cheaper and just adding it to the LCD module is a perfect plan moving forward. The power supply wants to stay under 50C ambient so putting an ambient sensor on the LCD PCB is a good design. Above 50C ambient heading to 60C the supply performance just ramps off to nil according to the manufacturer's specifications.

I ordered an IR non-contact sensor that is 5V compatible https://www.sparkfun.com/products/11859. My thought is to put it close to the fuses in the 30A system but keep logic wiring to the sensor safely out of contact with high voltage. Right now my DS18B20 sensor is zip-tied to a fuse but that is not practical for the masses and not too safe either, but it was entertaining to learn how to use OneWire serial sensors.

What I'm finding with the temperature sensors is that in order to get better than 0.5C resolution in the reading takes close to one second or more. The DS18B20 can give a <0.1C resolution given 750ms to measure. The trick I put in my code is only attempting to read it once per second and also reversing the logical sequence of commands, meaning I first read the temperature result and then tell the sensor to make a new measurement without delay. That way it is up to me to manage the delay and using the timer I only read temperature (and also WattSeconds) at one-second intervals. If I didn't do it this way I'd risk having the MPU just spin its wheels doing nothing for 750ms and possibly trip the watchdog timer too. Even if published accuracy for the digital sensors is about +/- 0.5C it is still fun to watch 0.1C resolution measurements ramp up or down smoothly in these nice digital sensors.

I'll pick up the Adafruit sensor too and play with this more next weekend.

[Nick Sayer]

Level shifting i2c shouldn't really be necessary. Just pull up both lines to 3.3 volts rather than 5. Most 5 volt i2c parts will work with the bus pulled up to only 3.3 volts and the 3.3 volt sensitive parts will (obviously) work that way. Since i2c is an open collector architecture, no i2c part should be slamming 5 volts onto the bus.

On Monday, January 5, 2015 10:26:04 AM UTC-8, Chris wrote:

Level shifting on i2c is a bit more tricky than standard serial. The level shifter has to be bidirectional so the standard voltage divider or voltage drop techniques will not work.

I am looking at adding a chip to the LCD module to get enclosure ambient temp. This adafruit board would work great as an add-on, I will likely use the same IC on the LCD module. It is ultra-precise, addressable up to 8 per i2c bus, works at 5v and is inexpensive (<$5 for the adafruit board).

https://learn.adafruit.com/adafruit-mcp9808-precision-i2c-temperature-sensor-guide

On Saturday, January 3, 2015 11:23:21 AM UTC-8, Craig Kirkpatrick wrote:

[chris1howell .]

Easier said than done. OpenEVSE boards only have 12v and 5v. The LCD has pull-ups to 5v. Adding 3.3v regulators for an i2c pull-up and changing the LCD architecture is not practical. using a 5v part instead of a 3.3v part is easy and backward compatible.

--

[Nick Sayer]

Just remove the pullups from the LCD and put them and the 3.3 volt regulator on the device that requires 3.3 volt power. That’s not too bad.

You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/82ADFO4RznY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[Craig Kirkpatrick]

Nick, Chris found a cost effective solution that is just simpler and cheaper than dealing with a 3.3V component. Take a look https://www.adafruit.com/products/1782

I have this coming before the weekend to experiment with. Ultimately adding the sensor component in the design of the LCD backpack board would add little cost to the existing LCD product from the OpenEVSE store.

[Craig Kirkpatrick]

I'll gather more data this weekend on a little experiment I played with last night. I put a tiny 12V fan 25x25x10mm in size into my 50A OpenEVSE on my bench with the MPU temperature monitoring firmware I'm playing with. With the enclosure shut completely and no airflow the MPU gets about 14C hotter than putting the fan in the enclosure just to stir the air inside of the enclosure in any direction. My thought is that convection cooling must be better with a even a slight amount of airflow and so far I'm seeing that is true. Even just leaving the lid off of the enclosure makes a significant difference to temperatures and that gave me the idea for playing with the tiny 12V fan.

What I really want to do this weekend is put the tiny fan in my 30A system while charging the Ford Focus EV at 24A and compare MPU and fuse temperatures with and without the fan inside to stir the air slightly. I've got the digital OneWire sensor tied to a fuse in that 30A system. The tiny fan is the "GDT Mini Cooler". Supposedly it only draws 80mA but I need to confirm that by measurement. I tied it to the relay actuation in my 50A OpenEVSE which is no problem. I can imagine it may be a problem in the 30A system that needs just about all of the available current at 12V to actuate the pair of relays. The nice thing is the fan only turns on during charging tied to that relay actuation block. It will be interesting to see what I observe while goofing around with it.

And if I'm raising concerns about temperature inside the OpenEVSE you need to realize it is just me having fun. Already the OpenEVSE has been put through the ambient-temperature-torture-test for a couple of years of daily use near a barren dry lake in the Mojave Desert where nary a human can survive in the summer temperatures reaching up to 114F. Right Chris? ;-).

I once worked summers at Edwards Airforce Base over thirty years ago and I can attest to the fact that temperatures there sometimes max out about 114F, maybe more now than so many years ago.

[Craig Kirkpatrick]

Today I added the MCP9808 I2C Temperature Sensor Breakout Board to my 50A system which is on my bench while my newest 30A systems keeps my Ford Focus EV tended and charged. It was pretty quick and simple to add the I2C temperature sensor to the I2C bus extension on the OpenEVSE kit's lcd since holes are there on the LCD backpack to extend the I2C bus by just soldering in a header for the connection. The library for the MCP9808 was bone-simple to use.

Previously I did enjoy the challenge of getting the OneWire temperature sensor working a few weeks ago, but looking back on that, nothing was simple to get it working, not hardware and not firmware. And in the long run for OpenEVSE OneWire sensors would require a change to the existing v3 or v2.5 boards in order to not conflict with the remote API work being done. Adding an I2C sensor is easily done within the existing OpenEVSE system kits from the OpenEVSE Store. And maybe in the future the component part MCP9808 may be added to the LCD backpack board itself. Who knows? Time will tell.

Tomorrow I want to improve my code so it automatically detects whether the MCP9808 is present or not so things can be handled cleany in both cases with one firmware.

Also tomorrow I want to fool around with the tiny fan to see how much it helps keep temperatures lower by stirring the air in the enclosure a little bit. I really want to test if the 80mA drawn by the fan will work well with the 12V actuated relays in the 30A kit. I'm not worried about the fan working fine in the 50A kit with no other big burden on the 12V supply voltage.

[Nick Sayer]

To facilitate additions like this, I've managed to shoehorn in an i2c header onto what will be the final version of the OpenEVSE II logic/display board. It's got the same +5/GND/SCL/SDA pin arrangement.

[chris1howell .]

Great work, I have already added the 9808 to the LCD logic board. I will order and test a few prototype boards, then run 250...

[Nick Sayer]

Much as I'd like to follow suit, I think the board would have to get bigger, which I don't really want to do, and in any event if you wanted the temperature there you could just use the controller's built-in sensor (in your case the controller and display are in different places, so it makes more sense).

I'm really of two minds on the temp sensor thing. The spots where sensing the temperature would be the most interesting are also the places that are the most dangerous in terms of HV presence. And as everyone knows I really have a bug up my ass about logic and HV being in close proximity. But I can see, for example, an i2c temp sensor module that's potted to keep it well insulated and then hot-glued next to the contactor.

Sent from my iPhone

On Jan 11, 2015, at 7:30 AM, chris1howell . <chris1h...@gmail.com> wrote:

Great work, I have already added the 9808 to the LCD logic board. I will order and test a few prototype boards, then run 250...

--

[Nick Sayer]

One really interesting idea I had once was an i2c Menekes lock driver made from an Attiny45.  It would use two lines for the motor drive, one for the sense line and two for i2c. You could send it lock and unlock commands or read the lock/unlock status of the sensor. The two motor lines would control two sides of an H bridge. The only hard part would be having to find 12 volts to power it along with the +5 for the controller. 

Sent from my iPhone

[chris1howell .]

Adafruit also has a contactless IR 5v i2c sensor that could be added to the enclosure lid. I plan to pick up a few to test looking down on the relay and fuses in addition to an ambient enclosure sensor.

It is likely that a single ambient sensor will be enough to detect a thermal event as the additional heat will have nowhere to go.

I am not too excited about the CPU temperature as it is pretty inaccurate, and will change based on CPU load as well as ambient temperature. I think it is a good secondary source though.

[MikeEV]

I would definitely be interested in this - I had a small fire with my unit this week.  Fortunately it was confined to the fuse block and the fuse eventually blew.  Needless to say I will be rewiring the unit and replacing some parts before it goes back into service, but having a temperature monitor to shut the system off before it gets to this state would give me a little more piece of mind.

[Nick Sayer]

Keep in mind that there's nothing in the OpenEVSE code that will put the controller into a reduced power state. So it's certainly true that the CPU sensor will get a heat contribution from its own core, it should be fairly constant, as the controller's power usage shouldn't change. It'd be different if we were putting it to sleep, but we're not. 

The big attraction to me of the controller's sensor as an alarm is that it's free, and always present. The issue is whether the alarm trigger point can be set low enough to be beneficial and effective without being a nuisance. 

I'm inclined to try a 70 degree trigger on the Hydras at work since they're in very, very harsh service outside daily. If they don't see false alarms, then no one will. 70 degrees should be well below any damage threshold, and should be comfortably inside the operating range of the controller. I just hope that if something were to go bad - like the melted fuse pic posted earlier - that the CPU sensor would "feel" it before damage was done. 

Sent from my iPhone

--

[chris1howell .]

Today there is nothing in the code to reduce charging current but it is coming very soon it is a very easy thing to add. The added safety is worth the effort.

To add a very precise i2c sensor to the LCD logic board is $0.70, well worth the expense. External add on boards are already available for less than $5.

The internal CPU sensor has to be individually calibrated, the easiest way is with another sensor. Sure you can add a sensor, calibrate and remove but for $0.70 you might as well leave it in.

[Craig Kirkpatrick]

I always thought temperature monitoring was a good idea.  Six months ago I was standing on a plastic bucket and poking a finger at everything to gain confidence that it was only getting slightly warm.  But I did read a few folks who had aluminum enclosures getting hot to the touch, or even one person thinking his fuses were poor quality.  When Chris mentioned a customer seeking UL certification I got really interested in contributing to thermal safety even if it is not in the J1772 standard.

So far what I have prototyped is code that stores the MPU temperature into eeprom right after the flash of the firmware.  The idea is to store a room temperature ambient value.  And I read that internal chip sensor once per second and display a delta like +21C.  The MPU is good to 85C but really the thing that heats up the MPU in the OpenEVSE is the little power supply and the two transistors that turn on the 12V relay actuation.  The limiting factor in the OpenEVSE controller seems to be the power supply itself which really wants to stay under 50C ambient temperature.  Measuring the MPU temperature does not give the ambient value.

Adding the MCP9808 sensor to the I2C bus on the LCD backpack gives a nice ambient temperature in the upper part of the enclosure near the OpenEVSE controller.  What is super nice is it is a fully calibrated temperature sensor so with great confidence we can know the ambient temperature inside the enclosure.  Currently I'm playing with ideas of what to do with temperatures reaching limits.  I blink the display Red and Teal during charging if temperatures are getting close to some shutdown threshold.  And I have not yet done it, but reaching some extreme temperature in need of action I can envision two approaches. One approach is just go to shutdown and display an error.  Another approach I wonder if it makes sense is to publish a new current ceiling on the pilot signal basically asking the car to draw something like 40% less.  My idea of ratcheting back the current drawn by the car is that folks like Chris who live in the desert and outdoor daytime temperatures in July can reach 114F still should be able to get some use from the OpenEVSE.  I'd like input on what ideas folks have for over-temperature shutdown actions.

One of my 30A systems now uses a digital OneWire sensor zip-tied to one of the fuses.  Probably that is not too smart for the masses since a fuse can blow in one second and the sensor would not be able to react fast enough to do anything useful and it adds risk that high voltage AC gets conducted to the controller board.

I've given thought to an IR sensor located near the fuses like Chris mentioned.  Already I have in hand a part from SparkFun, the Texas Instruments TMP006.  Browsing Adafruit I see TI has a new improved TMP007 which I have on order.  I can get started with the TMP006 until I get the TMP007.  It seems the big difference between the two is how much heavy-lifting the firmware needs to do with the older part vs the newer part.  The TMP007 processes the data into a simple degree C reading.  Both TI parts have a 90 degree cone of vision looking out at whatever you point the sensor.  Chris has a good idea to mount it to the lid looking down on the pair of fuses.  And I think the potential hot spot in the 50A system with the contactor is the screw-lugs on the output side of the contactor and I base this on my poking around with a finger temperature monitoring.

I'm finishing an experiment of adding a super tiny 12V fan to stir the air in the enclosure.  The spec for the fan was it was supposed to draw 80mA but I measured 106mA.  I haven't tried adding it to the 30A system where the +12V needs to energize the relays and I fear the extra 106mA drawn by the fan will goof things up in the 30A system.  Last night I measured the elevated ambient and elevated MPU temperatures during charge in my 50A enclosure.  Adding the fan keeps the internal MPU sensor 8C cooler but counter to what I expected the ambient temperature is about the same with the little fan running during charge.

The picture below has the ambient temperature from the I2C sensor displayed on the top line.  On the bottom line it shows the MPU increase in temperature since the firmware was flashed at ambient temperature.  Still this is the code I'm playing with keeping track of dollars and cents per charge.  And you can see there is limited space to display everything.

[Nick Sayer]

I'm really inclined to try a KISS approach. Since the CPU is rated to 85 C, I'm just going to check to see if it's sensor reads north of 70 and if so, just stop everything, display an error and lock up.

I don't think there's any need to calibrate the CPU sensor when it's being used in this manner (as a fail-safe). It shouldn't really see temps north of 60 C, much less 70.

Sent from my iPhone

[Nick Sayer]

Oh, one other thing I just realized. 

You're seeing a 29 C rise from programming ambient... But you're using Chris' board, so the controller is *right* on the other side from the power supply. You're programming it (I assume) with the AC power off. I'd have to assume that a fair amount of that temperature rise is conducted heat, not controller heat. 

OpenEVSE II and the Hydra have their 12 volt supplies separated by quite a bit of air, so the temperature rise should be substantially less. How much less still is TBD.

Sent from my iPhone

[Craig Kirkpatrick]

Nick, Do you like my idea of self-calibrating the 21C ambient baseline at time of firmware flash (assuming you flash the part at 21C or about room temperature)?  That is a simple calibration step that removes a big part of the +-10C slop in the internal sensor.  Then it is just a matter of gain, meaning does +10C really equate to +11C instead.  Then setting a +45C alarm level really means the internal temp sensor is seeing close to 66C = 151F which is plenty hot to decide shutdown time has arrived.  All of this can be done without adding anything.

I do like the additional ambient sensor on I2C to keep the ambient in the enclosure within the 50C power supply ceiling for the kits from the OpenEVSE store.  50C is not very high for ambient = 122F and according to the power supply spec the supply just tails off its output current to zero when heading from 50C to 60C.  So actually the supply is a built-in temperature watchdog of sorts where the relays would de-energize if the little power supply overheats.

What we really do not know is how fast any thermal event occurs like the one Mike posted today.  Does this happen gradually enough that adding only ambient temperature monitoring smarts will help?  Or does it happen like in three seconds where no ambient sensor would react fast enough?  Hopefully the IR sensor pointed at the fuses can react within a second.  I need to research that to see what we can expect of the IR sensor step response.

Some fun,

Craig

[Craig Kirkpatrick]

Nick,

Yes.  My approach is to let the EVSE stabilize at room temperature and then flashing it with the USB cable FTDI does not really warm anything.  At the end of the firmware flash the controller boots and stores the ambient offset value.  And I've played around and stored elevated temperatures  by not letting the board/power-supply cool down to ambient first and that is very noticeable.

Yes the OpenEVSE controllers that I get from Chris the major heater is the power-supply while sitting in State A or B, but going to State C charging turns on the 12V current draw with relays and simply switches the transistors also that actuate the relays.  That brings the temperature up about +16C when transitioning to the charging state.  And I find that stirring the air in the enclosure brings that to only about +8C in charging state.  I still need to really test this with my 30A system with my car drawing 24A for an hour or so.  Most experiments have been on the bench with no car as a load really drawing serious kW.

Having fun,

Craig

[Nick Sayer]

I've seen high temperature damage on previous iterations of the Hydra, and in my experience so far, it takes a long time. I've watched 3 "generations" of QD terminals slowly change color and then the wires start to change and so on. If it weren't for clear lids, I'd have perhaps inspected one after a few months and said, "what the hell?!" Instead, I've had plenty of warning that things were degrading.  

I think when things are used within their design limits, you don't see stuff degrade quickly. 

I'm also not quite as concerned about the power supply temp in my case because the ones I'm using are rated for 70 deg C (albeit derated to 80% output - which is still more than I'm actually using).

Sent from my iPhone

[Craig Kirkpatrick]

Nick,

This is really valuable to hear your first hand account of experience with the Quick Disconnect terminals degrading slowly rather than some quick avalanche we cannot respond to quickly enough.  This give me even more motivation to get moving on adding the IR sensor staring down at the fuse block or wherever the biggest concern lies.

In Mike's photo today of his meltdown I wondered why he use the QD terminal spades at the fuse block instead of just putting copper wiring under the screw terminals.  Actually I think the fuse block even says it is expecting copper wires under the screw terminal.  Eliminating any mechanical interfaces in the high current AC path to the car is most desirable and the crimp of the QD terminals is a potential weak spot.  I use a Klein Tools crimping pliers for all of my crimps.  I think using anything but a high quality crimping tool leads to problems.  

Crimping the little solid core wires leading to low power AC consumers or test points is a bit problematic - and I fold the solid core wire over on itself so there are two-strands basically going into the smaller crimp connectors.  Otherwise with a single solid core wire strand the mechanics of crimping don't really work well.  My 2 cents on crimping.

[Nick Sayer]

I have always used high quality QD terminals for the high current path and a ratcheting crimping tool. It just wasn't enough. Even the Hydra that was used with the 24A derated Blinks at work still wound up failing. I no longer have faith in QD north of 20A for heavy duty service. I'm still going to offer a QD terminal relay HV board for OpenEVSE II, and I have an EVSE built that way, but it's only used with our Volt on road trips to my parents' house, where it's either used at L1 or with a "quick-220," which I'm only willing to use at 12A.

That said, our Hydra at home hasn't yet been rebuilt and still has the old QD terminal relays. It hasn't failed. That's likely because it's mounted in a garage, so it's ambient temperature never contributes to the thermal load.

For the low current paths, I use 22 gauge stranded wire and the "pink" 20-22 gauge crimp on terminals. Those have never given me any issues at all. 

Sent from my iPhone

[dra...@wb6pwj.com]

I have a variety of crimping tools including the ratcheting Harbor Freight ones. I always crimp and solder my heavy wires. I have never had one overheat yet.

For small wires I prefer my T&B crimpers. At work for the rear battery wires on police cars we had a 4 point crimper that looked like an overgrown bolt cutter. It was wire and terminal specific but it did a superb job. It also cost several hundred dollars. I do not trust any home non 4 point crimp.

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.

[Nick Sayer]

I know we've had this conversation before, but my understanding is that soldering is not recommended for high current connections because solder is not as good a conductor as copper. 

It's entirely possible that the service conditions for the Hydras at work are severe enough to demand a derate for the crimp QD terminals, and that's why they keep failing. But I have every confidence that the box-screw terminals on the contactors now aren't going to have any trouble at all.  And Craig's clued me into a source for 50A contactors that are cheaper than DigiKeys price for the relays I originally was using.

Sent from my iPhone

[Craig Kirkpatrick]

My belief about crimping and soldering heavy wires is that your are being a "jet fighter test pilot" testing something that is not proven or documented anywhere.  I look in household wiring or wiring for a dryer or and electric range and I see no solder anywhere, only screw terminals or the QD spade connectors.  Your experience is good with your approach so it will be hard to persuade you.

I am most confident in my 50A build that uses the contactor and nothing carrying up to 10kW relies on the QD connectors but instead heavy lug screw terminals.

We end up with the QD connectors since the choice of the relays in the 30A kits.  Most of the use of my 30A kit is to charge my Ford Fusion Energi that only draws 14A at 240.  I am using a second 30A Kit for the past two weeks charging my Ford Focus EV at 24A and all is well.

I worked for a probing company for a few years and we had a boatload of engineering data on contact resistance of metal to metal contact.  For this application the QD terminals that are dipped in silver are best since silver oxide is equally conductive to shiny silver.  I'm sure NEMA has a thousand page document with advice for crimp connections and these quick disconnect terminals.  More to study...

Best wishes,

Craig 

[dra...@wb6pwj.com]

Yellow connectors are rated for 25A. Sometimes I use flag terminals soldered to both the relay and the wire. You do as you please and only crimp. I will continue to crimp and solder. Whatever works for you. If I had access to military 4 point crimpers I would never solder. The harbor freight crimpers are just OK on 10 gauge and a total joke on 12 gauge. Every 12 gauge crimp has pulled out easily.

-------- Original Message --------
Subject: Re: Monitoring temperature
From: "'Nick Sayer' via OpenEVSE" <open...@googlegroups.com>
Date: Sun, January 11, 2015 3:19 pm
To: "open...@googlegroups.com" <open...@googlegroups.com>

I know we've had this conversation before, but my understanding is that soldering is not recommended for high current connections because solder is not as good a conductor as copper. 

It's entirely possible that the service conditions for the Hydras at work are severe enough to demand a derate for the crimp QD terminals, and that's why they keep failing. But I have every confidence that the box-screw terminals on the contactors now aren't going to have any trouble at all.  And Craig's clued me into a source for 50A contactors that are cheaper than DigiKeys price for the relays I originally was using.

Sent from my iPhone

On Jan 11, 2015, at 3:00 PM, <dra...@wb6pwj.com> <dra...@wb6pwj.com> wrote:

I have a variety of crimping tools including the ratcheting Harbor Freight ones. I always crimp and solder my heavy wires. I have never had one overheat yet.

For small wires I prefer my T&B crimpers. At work for the rear battery wires on police cars we had a 4 point crimper that looked like an overgrown bolt cutter. It was wire and terminal specific but it did a superb job. It also cost several hundred dollars. I do not trust any home non 4 point crimp.

-------- Original Message --------

Subject: Re: Monitoring temperature
From: "'Nick Sayer' via OpenEVSE" <open...@googlegroups.com>
Date: Sun, January 11, 2015 2:15 pm
To: "open...@googlegroups.com" <open...@googlegroups.com>

I have always used high quality QD terminals for the high current path and a ratcheting crimping tool. It just wasn't enough. Even the Hydra that was used with the 24A derated Blinks at work still wound up failing. I no longer have faith in QD north of 20A for heavy duty service. I'm still going to offer a QD terminal relay HV board for OpenEVSE II, and I have an EVSE built that way, but it's only used with our Volt on road trips to my parents' house, where it's either used at L1 or with a "quick-220," which I'm only willing to use at 12A.

That said, our Hydra at home hasn't yet been rebuilt and still has the old QD terminal relays. It hasn't failed. That's likely because it's mounted in a garage, so it's ambient temperature never contributes to the thermal load.

For the low current paths, I use 22 gauge stranded wire and the "pink" 20-22 gauge crimp on terminals. Those have never given me any issues at all. 

Sent from my iPhone

On Jan 11, 2015, at 1:57 PM, Craig Kirkpatrick <crai...@comcast.net> wrote:

Nick,

This is really valuable to hear your first hand account of experience with the Quick Disconnect terminals degrading slowly rather than some quick avalanche we cannot respond to quickly enough.  This give me even more motivation to get moving on adding the IR sensor staring down at the fuse block or wherever the biggest concern lies.

In Mike's photo today of his meltdown I wondered why he use the QD terminal spades at the fuse block instead of just putting copper wiring under the screw terminals.  Actually I think the fuse block even says it is expecting copper wires under the screw terminal.  Eliminating any mechanical interfaces in the high current AC path to the car is most desirable and the crimp of the QD terminals is a potential weak spot.  I use a Klein Tools crimping pliers for all of my crimps.  I think using anything but a high quality crimping tool leads to problems.  

Crimping the little solid core wires leading to low power AC consumers or test points is a bit problematic - and I fold the solid core wire over on itself so there are two-strands basically going into the smaller crimp connectors.  Otherwise with a single solid core wire strand the mechanics of crimping don't really work well.  My 2 cents on crimping.

On Sunday, January 11, 2015 at 1:37:25 PM UTC-8, Nick Sayer wrote:

I've seen high temperature damage on previous iterations of the Hydra, and in my experience so far, it takes a long time. I've watched 3 "generations" of QD terminals slowly change color and then the wires start to change and so on. If it weren't for clear lids, I'd have perhaps inspected one after a few months and said, "what the hell?!" Instead, I've had plenty of warning that things were degrading.  

I think when things are used within their design limits, you don't see stuff degrade quickly. 

I'm also not quite as concerned about the power supply temp in my case because the ones I'm using are rated for 70 deg C (albeit derated to 80% output - which is still more than I'm actually using).

Sent from my iPhone

On Jan 11, 2015, at 1:25 PM, Craig Kirkpatrick <crai...@comcast.net> wrote:

Nick, Do you like my idea of self-calibrating the 21C ambient baseline at time of firmware flash (assuming you flash the part at 21C or about room temperature)?  That is a simple calibration step that removes a big part of the +-10C slop in the internal sensor.  Then it is just a matter of gain, meaning does +10C really equate to +11C instead.  Then setting a +45C alarm level really means the internal temp sensor is seeing close to 66C = 151F which is plenty hot to decide shutdown time has arrived.  All of this can be done without adding anything.

I do like the additional ambient sensor on I2C to keep the ambient in the enclosure within the 50C power supply ceiling for the kits from the OpenEVSE store.  50C is not very high for ambient = 122F and according to the power supply spec the supply just tails off its output current to zero when heading from 50C to 60C.  So actually the supply is a built-in temperature watchdog of sorts where the relays would de-energize if the little power supply overheats.

What we really do not know is how fast any thermal event occurs like the one Mike posted today.  Does this happen gradually enough that adding only ambient temperature monitoring smarts will help?  Or does it happen like in three seconds where no ambient sensor would react fast enough?  Hopefully the IR sensor pointed at the fuses can react within a second.  I need to research that to see what we can expect of the IR sensor step response.

Some fun,

Craig

[Craig Kirkpatrick]

I have the TMP006 IR Temperature sensor working now.  I pulled the MPC9808 from the I2C header so I could drop in the TMP006 in that spot.  I guess in the long run we'll have both sensors on the I2C bus.

I'm overwhelmingly pleased with the IR sensor!  The sensor pointing at my pile of hand-tools on the bench reads a believable 21.5C.  Then I put the palm of my hand in front of the sensor and the reading leaps to about 33C within a second.  How nifty is that!  This means it has great promise to monitor the hot spots like the fuse block in the 30A kit and give an excellent reaction time to thermal runaway events.

Reading the Texas Instruments documents about the TMP006 that I'm playing with and the TMP007 I have arriving Wednesday, I'm looking forward to swapping out the TMP006 for the TMP007.  The TMP007 is sixteen times faster than the TMP006.  Any of these temperature sensors trade speed for noise performance.  With the TMP006 reading once per second I'm in the middle of the noise performance.  With the TMP007 I can make the lowest noise measurements in a quarter of the time I'm letting the TMP006 settle right now.  This all translates into a more stable reading giving more confidence in the accuracy of the measurement.  There are a great number of advancements moving from the TMP006 to the TMP007.  Like I mentioned before more processing occurs in the sensor and less is needed in the firmware to get the calibrated degree C when using the TMP007 and keeping the firmware light is important so we do not have to compromise on the features already in the firmware, needing to keep within 32KBytes.

It is truly amazing what we can do in that 32K, and keeping things lean is just good programming too.

Watch this little YouTube video I uploaded a moment ago.  It shows the performance of the TMP006 on my bench experiments.  It is 90 seconds long.

http://youtu.be/M67aU5yhays

Have fun,

Craig

[Craig Kirkpatrick]

Late yesterday I monitored the fuses while letting my Ford Focus EV draw 25A intentionally pushing an amp beyond the 24A safe limit for the 30A kit. I won't be repeating that experiment. I watched the fuse temperature steadily climb to 56C in the two hours my car was charging. That seems too hot. And this was with the OpenEVSE outdoors with about 45F air temperature.

Still experimenting with the IR sensor I can easily add the IR sensor to that 30A kit I have that has the OneWire sensor zip-tied to a fuse. That way I can see how well the two sensors agree with each other about the fuse temperature. My hope is that the IR sensor agrees well with the OneWire sensor so we can be confident in the contactless IR sensor approach to monitoring the fuses.

I think I'll receive the fancier TMP007 sensors on Wednesday. Re-reading the specifications for the TMP007 I have to retract what I said earlier about it being sixteen times faster than the TMP006. The other advantages I mentioned are true, basically more local processing within the sensor itself meaning lighter weight firmware for our development.

[Nick Sayer]

The one downside of the OpenEVSE II design is that I haven't found a way to fit the fuseblock in with the HV/relay board. I don't bother with fuses on the contactor variants (or with Hydras), but I can see the case for fuses for the QD relay variants. I wish the fuse block (or an alternative one) was more square than rectangular. Maybe with side-mount terminals rather than end-mount. Centering such an arrangement in the bottom half of the chassis with the HV board in the top half would be ideal.

[dra...@wb6pwj.com]

Fuses in general run hot near the max ratings. They have to "fuse" or melt. A rule of thumb is to fuse at 1.5 to 2 times the max expected current. That is a problem when the max fuse size is 30A in 3AG and 5AG style holders in high voltage slow blow fuses.

-------- Original Message --------
Subject: Re: Monitoring temperature
From: "'Nick Sayer' via OpenEVSE" <open...@googlegroups.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.

[Chris]

I feel kinda dumb... As pointed out in another thread the RTC chip used in the OpenEVSE LCD already has a good temperature sensor that would be perfect for ambient readings...

Looks pretty easy to access... 

http://kevinrye.net/files/reading_the_temp_ds3231_and_ds18b20.php

[Craig Kirkpatrick]

I never would have guessed that the RTC component had a usable ambient temperature sensor. That's nifty. I'll take a look at its performance specifications tonight. I'm away from home and away from my OpenEVSE hardware until February 2nd. So I won't get a chance to test new code using that in place of the mcp8909 for a bit more than a week. But looking at the page you linked to it looks super simple to get some reading. I've been getting great resolution of 0.1C so far with the mcp8909.

[Cory Clemmer]

I bet it is what makes it a temperature compensated RTC.
I hope it is able to be used for ambient temp sensing with just a simple firmware update.

On Jan 23, 2015 8:56 PM, "Craig Kirkpatrick" <crai...@comcast.net> wrote:

I never would have guessed that the RTC component had a usable ambient temperature sensor. That's nifty. I'll take a look at its performance specifications tonight. I'm away from home and away from my OpenEVSE hardware until February 2nd. So I won't get a chance to test new code using that in place of the mcp8909 for a bit more than a week. But looking at the page you linked to it looks super simple to get some reading. I've been getting great resolution of 0.1C so far with the mcp8909.

[Craig Kirkpatrick]

Specifications for the DS3231 internal temperature monitoring is typical accuracy of +-3C with resolution of 0.25C
Specifications for the MCP8909 digital temperature sensor is typical accuracy of +-0.25C with resolution of 0.0625C

I like the idea of changing my existing code that I'm developing to add support of the DS3231 if it is present. One of my OpenEVSE kits has the basic lcd without the RTC so I'll test that case of no-DS3231 to handle it well. When I get home in February I can add support for the DS3231 and also gracefully handle if it is missing like on the basic lcd with no RTC.

The code will default to taking the ambient from the more accurate MCP8909 if it is present and fall back to the less accurate DS3231 if it is present and quietly ignore anything about ambient temperature if no ambient sensor is found.

I still admire the accuracy of the MCP8909 and I am able to get 0.1C resolution displayed while letting it actually convert at the best resolution of 0.0625 and my code does not pay any measurement time penalty for the high resolution the way that I wrote it.

With the MCP8909 being 12x more accurate than the DS3231 I still favor adding that 70 cent MCP8909 component to the LCD in the future. And it will also be nice to support the installed base of OpenEVSE with the DS3231 RTC option already out there with just a new firmware update.

[chris1howell .]

Sounds like a good plan...

[Jean-Michel Olivier]

Some data collected with my firmware :
- Reading temperature with DS3231 costs 216 bytes of flash memory more than reading with ATMega internal sensor.
- Keeping both reading methods costs 84 bytes of flash memory more than reading with DS3231 only.

I have simply added the function below to the library RTClib.
// Only valid for DS3231 chip
float RTC_DS1307::getTemp()
{
  byte tMSB, tLSB;
  float temp3231;

  // Temperature registers (11h-12h) updated automatically every 64s
  WIRE.beginTransmission(DS1307_ADDRESS);
  WIRE.write(0x11);
  WIRE.endTransmission();
  WIRE.requestFrom(DS1307_ADDRESS, 2);
 
  if (WIRE.available()) {
    tMSB = WIRE.read();
    tLSB = WIRE.read();
   
    temp3231 = (tMSB & B01111111);    // MSB
    temp3231 += ((tLSB >> 6) * 0.25); // and bits 7 & 8 of LSB
    return temp3231;
  }
   
  return -30.0;
}

[Nick Sayer]

We really should avoid floating point code at all costs. Adding the emulation support costs around 1K of flash. Fixed-point decimal (for instance, returning units like milliwatts or tents-of-a-degree) is a much better way to go. 

Sent from my iPhone

[Craig Kirkpatrick]

I got home from travels yesterday and added the DS3231 ambient sensor to my temperature monitoring code. I'm following my intuition that is equivalent to Nick's advice to treat 24.5C as an integer of 245 instead of suffering some bloated floating point library. I was already treating all of the temperature sensors that way knowing we can't waste 1k of code space to some unnecessary library.

Maxim specified the DS3231 conservatively as +/-3C accuracy. I witnessed very good correlation to my MCP9808 with ambient temperatures usually within 1C agreement. OK it was a sample of one, but still it looked very good. That bodes well for adding ambient temperature monitoring to the existing OpenEVSE kits that already use the DS3231 realtime clock by merely updating firmware in the future. I still need to see if my writing of DS3231 control registers goofs up time-keeping in any way. I tried reading the control register and then just flipping the one bit I wanted to write for temperature monitoring but that did not work for me - it is time for me to study Maxim's document more carefully.

While traveling to California last week I met Nick Sayer for dinner and got some valuable advice about correctly handing the over temperature error state so that it completely follows the J1772 standard. What I need to do in the error state is to set the pilot to steady high voltage (doing that already) and then when the EV returns the EVSE to state B I need to open the relays and then set the pilot to a steady low voltage to indicate the error condition properly to the EV. If the EV fails to release the EVSE to state B then after X seconds the code should open the EVSE relays assuming that the car is malfunctioning. How many seconds is X seconds?

[chris1howell .]

I am not sure we want to go into a full error state, the vehicle may refuse to charge again. Going to state B with high pilot indicates EVSE is not ready to provide charge, just like waiting for a timer. If we intend to auto resume we should go to State B not an error state.

--

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.

[Nick Sayer]

X is 5 seconds, per spec.

I think I saw some code for reading the 3232 temp a while ago that I thought was yours and it looked correct to me.

You write a single byte register offset to the DS address, then read the two temp bytes. That should be all there is.

Sent from my iPhone

[Nick Sayer]

I can go either way.  Going to solid -12 may get the car to report the error wirelessly to the owner if the EVSE doesn't have its own connectivity. The spec allows either as an error response to my reading, but with a more "dire" indication from -12. 

Sent from my iPhone

You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/82ADFO4RznY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[Craig Kirkpatrick]

Chris, ok I get what you are thinking. I already have a temperature threshold where I throttle back the EV to 16A in state C. I see what you suggest is to treat an even higher temperature threshold as a hold condition in state B with the pilot signal held high and expecting temperatures to subside since normally no current will flow. In this case we expect the EV returns to state B and the EVSE opens relays as it normally should and later when temperatures subside the EVSE can resume sending a pilot signal and resume state C normally.

Do you think it makes sense to have a temperature panic threshold even higher in temperature where we assume the EV being disobedient to the pilot signal and is stuck in state C even with the pilot held high? And in that very high temperature threshold we open relays and set the pilot to steady low voltage? This is the sort of thing Nick and I spoke about over dinner last week. Think of it has handling the case of a rogue EV.

[Nick Sayer]

> On Feb 2, 2015, at 2:16 PM, Craig Kirkpatrick <crai...@comcast.net> wrote:
>
> Chris, ok I get what you are thinking. I already have a temperature threshold where I throttle back the EV to 16A in state C. I see what you suggest is to treat an even higher temperature threshold as a hold condition in state B with the pilot signal held high and expecting temperatures to subside since normally no current will flow. In this case we expect the EV returns to state B and the EVSE opens relays as it normally should and later when temperatures subside the EVSE can resume sending a pilot signal and resume state C normally.
>
> Do you think it makes sense to have a temperature panic threshold even higher in temperature where we assume the EV being disobedient to the pilot signal and is stuck in state C even with the pilot held high?

The 5 second timeout will handle that. 5 seconds after withdrawing the pilot for *any* reason, the relays should be opened regardless of whether the vehicle has returned to state B or not.

As you say, not obeying a pilot withdrawal might be a good reason to hit them with a steady -12.

The only thing about -12 is that as long as you hold the pilot there, you’ll be completely insensitive to what the car might or might not do - including a human completely disconnecting the cable. If you pin at -12, then it implies that there would need to be an out-of-band reset (even if it’s power-cycling the EVSE).

> And in that very high temperature threshold we open relays and set the pilot to steady low voltage? This is the sort of thing Nick and I spoke about over dinner last week. Think of it has handling the case of a rogue EV.
>

> --
> You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/82ADFO4RznY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[chris1howell .]

Maybe not a temperature but a time and/or number of events... This allows an gradual escalation.

- Threshold temp 1 - Throttling

- Threshold temp 2 - cutoff to State B pilot steady High

if temperature stays above threshold B for x number seconds (maybe 60...120) or the temperature has reached threshold 3 times during the charging session

- Shutdown to State D

- Actively disconnect relay after 5 seconds after State D

- Stay in Error State

On Mon, Feb 2, 2015 at 2:16 PM, Craig Kirkpatrick <crai...@comcast.net> wrote:

Chris, ok I get what you are thinking. I already have a temperature threshold where I throttle back the EV to 16A in state C.  I see what you suggest is to treat an even higher temperature threshold as a hold condition in state B with the pilot signal held high and expecting temperatures to subside since normally no current will flow.  In this case we expect the EV returns to state B and the EVSE opens relays as it normally should and later when temperatures subside the EVSE can resume sending a pilot signal and resume state C normally.

Do you think it makes sense to have a temperature panic threshold even higher in temperature where we assume the EV being disobedient to the pilot signal and is stuck in state C even with the pilot held high?  And in that very high temperature threshold we open relays and set the pilot to steady low voltage?  This is the sort of thing Nick and I spoke about over dinner last week. Think of it has handling the case of a rogue EV.

[Craig Kirkpatrick]

Chris, the gradual escalation makes a lot of sense. Thanks. That approach makes for a product that is easy to support and ultimately safe also.

[Craig Kirkpatrick]

In line with this discussion thread, I have cleaned up my code and merged it with Lincomatic's development branch.  I learned how to use GitHub and I sent a pull request to Sam.

You can download and evaluate the code https://github.com/craigk46/open_evse/tree/craigk46-temperature-monitoring

Look in the open_evse.h file for the section TEMPERATURE_MONITORING to set whatever temperature thresholds you deem necessary.  I put what I think are reasonable limits based upon components used in the kits from the OpenEV store.  For testing purposes and just to play with the sensors and see how everything works I have put in some pretty low temperature values that will be easy to reach even with a warm finger touching the sensor or hand held in front of the infrared sensor.

It does pretty much what we spoke about in this thread:

If the RGB LCD with RTC is in your build, then the code will watch the ambient temperature monitored there internal to the RTC chip.

Additionally if the very precise and accurate MCP8908 is found on the I2C bus then it is also monitored for ambient temperature.

For extra fun add an infrared sensor to look at fuses or look at the contactor temperature; it is the TMP007 on the I2C bus. 

I buy a nice TMP007 breakout from Adafruit.com https://www.adafruit.com/search?q=tmp007&b=1    for only $12.50.

The code gracefully handles whatever mix of sensors you have among the three I just listed.

When a lower threshold is reached, the OpenEVSE forces the pilot to 16A, at L2 this is still 2X the power delivery of an L1 EVSE.

Also the temperatures that are available from sensors are displayed at this time on the bottom line of the LCD,  MCP8908 then RTC's ambient then TMP007 and the space is left blank if the sensor is not present.

When a higher threshold is reached, the OpenEVSE forces the pilot to 6A which is the J1772 minimum (note I want to change this to pilot held high in the future which sets 0 amps).

Whan an even higher temperature is reached after very little (in the future zero current) current is flowing then we go to state D like Chris described earlier in this thread.

The temperature monitoring has some nice hysteresis coded into it - think of it like de-bouncing the changes across temperature thresholds so we don't flip the pilot signal wildly back and forth.

The RGB LCD will show a red blinking backlight when temperatures reach thresholds of concern.  And the default action is to blink red and teal. The blinking can be shut off with one line in the main code that is presently commented out.

When Over Temperature state D is reached the OpenEVSE stays there with a red backlight and the user has to take some action like resetting circuit breakers or it is possible to restart the OpenEVSE from the button menus.  Reaching this state will also have most EVs complaining to the driver to check the EVSE for a fault.

This is a good start.  I have a few enhancement ideas brewing.  And now that you can get your hands on it to play with it I hope more great ideas bubble to the surface.

Best Wishes,

Craig

[Craig Kirkpatrick]

Anyone considering to download and evaluate this should use Lincomatic's development branch that has pulled in the temperature monitoring now.

https://github.com/lincomatic/open_evse/tree/development

Lincomatic made significant cleanup of my code and I've test it and it works perfectly.  I'll make a minor enhancement later this week so that the second temperature threshold pauses all flow of current to the EV, right now it is setting the current to minimum of 6A but it is best for that second threshold to have the charging pause.  If you want to evaluate it you will want to go into the open_evse.h file to turn it on, look for the line that is commented out #define TEMPERATURE_MONITORING and also look for the temperature thresholds to make some choices there.

[Nick Sayer]

I’ll just throw out there that the OpenEVSE II production logic/display boards will come with an MCP9808. The standard deviation of the temperature reading across multiple ATMega328Ps was just way, way to high to be used even for a temperature alarm without some sort of software calibration procedure for which I have no patience. :)

> --
> You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/82ADFO4RznY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[Craig Kirkpatrick]

Nick, I abandoned using the sensor within the ATMega328P for the very same reasons.  My code uses the internal sensor in the DS3231 RTC chip on the LCD backpack if it is present.  And I use the MCP9808 if it is present.  Chris is also planning to add the MCP9808 to the LCD backpack in the future.  It is simple to add the Adafruit breakout board for the MCP9808 to an existing LCD by soldering in a four-pin right-angle header on the available extension of the I2C on the LCD backpack.  Also it is simple to add additionally the Adafruit TMP007 breakout on that same I2C bus extension.  In practice I find that the DS3231 ambient sensor reads pretty close to the MCP9808 ambient sensor.  The MCP9808 has superior accuracy specifications relative to the DS3231.  Having the temperature monitoring code use the DS3231 enables any existing RGB LCD with RTC to enjoy some temperature monitoring without adding any hardware, just flashing new firmware, so that was the motivation for using the DS3231 in addition to the MCP9808.

The TMP007 infrared sensor is pretty nice.  Place it looking at any potential hotspot where it would not be safe to have a sensor in contact because of high voltage.  I use it to watch fuses in the 30A kit and use it watching the J1772 output wires from the contactor in the 50A kit.

[Danny ter Haar]

On Monday, February 2, 2015 at 2:50:15 PM UTC-8, Chris wrote:

Maybe not a temperature but a time and/or number of events... This allows an gradual escalation.

- Threshold temp 1 - Throttling

- Threshold temp 2 - cutoff to State B pilot steady High

if temperature stays above threshold B for x number seconds (maybe 60...120) or the temperature has reached threshold 3 times during the charging session

- Shutdown to State D

- Actively disconnect relay after 5 seconds after State D

- Stay in Error State

I would be interested of the temperature rise based on the heat build up in a closed box by the openevse & relay coil.

The 240V ac contactor dissipates about 6 watts of power from what I could find vs < 3 watt for the 80 amp 12 volt JQX-62F chinese relay.

Would be interesting to hook it up to a ev simulator without actually pulling power and see how the openevse warms up to things   

[Nick Sayer]

Keep in mind that the DC power supply will likely equal the relay in terms of dissipated power. I don't know the specs for the original one, but the CUI module I use has an output capacity of either 3 or 10 watts, depending on the HV board, and is around 85% or so efficient. Not all of its capacity is used, though, but even so, I'd expect the 10W variant to be sucking around 10 watts while the car is charging, and dissipating around 3.

The contactor variant, with the 3W supply will dissipate quite a bit less, as the DC load of the contactor is the equivalent of an LED (in the optoisolated driver triac).

So in short, the DC supply will likely make up for the power dissipation savings of the DC relay. 

Sent from my iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "OpenEVSE" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openevse/82ADFO4RznY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openevse+u...@googlegroups.com.

[Danny ter Haar]

On Wednesday, March 4, 2015 at 11:51:01 AM UTC-8, Nick Sayer wrote:

the CUI module I use [SNIP] is around 85% or so efficient.

So in short, the DC supply will likely make up for the power dissipation savings of the DC relay. 

 

If the DC relay is 85% efficient, aren't we loosing  15% in heath of the 3 Watt of usage of the DC coil ?

That would be 0.5 watt, plus the 3 watt of the coil would be 3.5 watt of heat buildup, less than the 6 Watt of the AC contactor.

Or am I looking at this wrong ?

[Nick Sayer]

> On Mar 4, 2015, at 12:23 PM, Danny ter Haar <from...@gmail.com> wrote:
>
>
>
> On Wednesday, March 4, 2015 at 11:51:01 AM UTC-8, Nick Sayer wrote:
> the CUI module I use [SNIP] is around 85% or so efficient.
> So in short, the DC supply will likely make up for the power dissipation savings of the DC relay.
>
> If the DC relay is 85% efficient, aren't we loosing 15% in heath of the 3 Watt of usage of the DC coil ?

No, no, it’s the power supply that’s 85% efficient, not the relay. The relay is the consumer of power. It’s, effectively, either 100% “efficient” or 0%, depending on your perspective. :D

Think of it this way: The relay may require less power to turn it on, but that power is “expensive” because it had to be made by the AC/DC converter module. By contrast, the power for the contactor is “free” since it just comes in from the plug and is switched by a triac (yes, Chris uses an SSR, but that’s just a triac in disguise).

>
> That would be 0.5 watt, plus the 3 watt of the coil would be 3.5 watt of heat buildup, less than the 6 Watt of the AC contactor.
> Or am I looking at this wrong ?
>
>

[Craig Kirkpatrick]

Danny, If you are comfortable downloading the source code and compiling it and flashing it yourself you can go ahead and find the development branch of code on Lincomatic's Github.  At this moment in time it will work fine if you have the RGB LCD+RTC display instead of the monochrome LCD.  I found a problem where if you have the monochrome one it will immediately think it has gone into over-temperature panic.  I'm working on cleaning up a little fix for that gremlin in a day or two from now.

I suppose I could make a .hex for you pretty quickly that would show you the ambient temperatures on the RGB LCD.  Is that what you wish to see?  Just let me know.

[Danny ter Haar]

On Wednesday, March 4, 2015 at 12:33:31 PM UTC-8, Nick Sayer wrote:

No, no, it’s the power supply that’s 85% efficient, not the relay. The relay is the consumer of power. It’s, effectively, either 100% “efficient” or 0%, depending on your perspective. :D

I never talked about efficiency of the relay ???

The little power supply that converts ac -> dc is 85% efficient.

To get 3 watt dc out (for the relay) you will need to put 115% of the 3 watt =3.52 watt in.

isn't that what it means ?

 

Think of it this way: The relay may require less power to turn it on, but that power is “expensive” because it had to be made by the AC/DC converter module. By contrast, the power for the contactor is “free” since it just comes in from the plug and is switched by a triac (yes, Chris uses an SSR, but that’s just a triac in disguise).

6 watt of AC heat warming up the inside of the Openevse casing  

vs 

3.5 watt of the DC relay plus power unit still gives less heat buildup imho.

[Danny ter Haar]

On Wednesday, March 4, 2015 at 12:43:45 PM UTC-8, Craig Kirkpatrick wrote:

Danny, If you are comfortable downloading the source code and compiling it and flashing it yourself you can go ahead and find the development branch of code on Lincomatic's Github.  At this moment in time it will work fine if you have the RGB LCD+RTC display instead of the monochrome LCD.  I found a problem where if you have the monochrome one it will immediately think it has gone into over-temperature panic.  I'm working on cleaning up a little fix for that gremlin in a day or two from now.

I suppose I could make a .hex for you pretty quickly that would show you the ambient temperatures on the RGB LCD.  Is that what you wish to see?  Just let me know.

I just ordered some RGB displays and casings with Chris yesterday evening.

Going to mount all my openevse's in the original cases, with display (many of them just have a colored led at the moment ;-) )

I better wait till I received all my goodies, built 2 openevse's.

one with 2.5 with 12 volt relay, and a 3 with contactor. That is when I can do a test with both setups .

Will contact you when I got my stuff together ;-) 

[Craig Kirkpatrick]

Danny, that seems best.  And I can more thoroughly test it before you spend time evaluating it.

[Nick Sayer]

I’m not sure you can call out just the heat generated from the AC/DC module just for the purpose of driving the relay. Maybe you can. And maybe you’re right that it’s still better. My own back-of-the-envelope thinking about it suggested the two cases were closer than that, though.

But I haven’t really thought too much about it. At high power, I believe the heat generated by both is dwarfed by the heat generated by the high current path overall - either through the contactor points or the combination of the relay points and fuses.

[Danny ter Haar]

On Wednesday, March 4, 2015 at 1:04:19 PM UTC-8, Nick Sayer wrote:

I’m not sure you can call out just the heat generated from the AC/DC module just for the purpose of driving the relay. Maybe you can. And maybe you’re right that it’s still better. My own back-of-the-envelope thinking about it suggested the two cases were closer than that, though.

But I haven’t really thought too much about it. At high power, I believe the heat generated by both is dwarfed by the heat generated by the high current path overall - either through the contactor points or the combination of the relay points and fuses.

Will test when I have 2 units available.

And I agree, the resistance of the contacts probably adds more than electronics itself.

Will measure, find out and report ;-)

Thanks for the feedback. 

[Danny ter Haar]

Just measured power of a couple of 12 volt relays I happen to have with my programmable power supply on my bench

the "80 amp" relay from china:

JQX-62F 12V coil   12.5 volt 0.212 amp = 2.65 watt

The relay that Tesla uses in their http://my.teslamotors.com/roadster/charging/universal-mobile-connector that is supplied with a car:

T92S7D22-12 12 volt coil

12.5 volt x 0.146 amp = 1.83 Watt

I haven't looked at the actual voltage that the ac-dc converter supplies but should be about the same I assume.

[Alan]

Need to ask a noob question as I'm not really familiar with I2C. I have the old diy LCD backpack that doesn't have a second I2C port. I just got an MCP 9808 board I'd like to add on. Can I just splice into the same cable I'm using to run the board? Also, what address should I be using for the MCP 9808?

Thanks,
Alan.

[Glenn Drayer]

The I2C lines are designed for multiple devices. There should be no termination resistors on your display if the MCP board provides termination. Termination should be on the last device but in practice multiple terminations usually works fine. Just do not exceed 2K.

In the past I have soldered another cable to the back of the pins.

--

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.