[Ovmsdev] i-Miev/C-Zero/iOn

Wed Oct 23 17:02:08 HKT 2013

I have also upped the value claimed for the charge limit when AC charging
from 13A to 16A (in my local code) because I have found currents higher
than 13A being drawn at times from a charging post. I have attached an
example.

Matt

On 21 October 2013 02:03, Mark Webb-Johnson <mark at webb-johnson.net> wrote:

> Matt, Thomas,
>
> Looks good.
>
> When ready for this to be merged to mainline, please let me know.
>
> Regards, Mark.
>
> On 18 Oct, 2013, at 5:08 pm, Matt Beard <matt at beard.tv> wrote:
>
> OK, I've done a bit more testing and it looks promising.
>
> What I have found is the following:
>
> Charger Temperature
> I spotted a value in byte 3 of PID 286 that rises gradually during
> charging, then falls slowly afterwards. It seems likely this is charger
> temperature of some kind. This seems to settle at about 40 higher than the
> current outdoor temperature in Celsius. It seems odd to be having a
> different offset to the battery temperature values, but the outside air
> temperature here is 9.7C and the PID 286 value is 50 with battery sensor
> average value 65. This would mean the charger is almost exactly ambient and
> the batteries 5C higher.  I have added this as PEM temp.
>
> Motor Temperature
> I found that PID 298, which has the suspected motor RPM, has a set of 4
> values in a similar range to the possible charger temperature reading.
> These seem to rise while driving, the forth of them (byte 3) rises fastest
> and highest. I suspect that these are intimately linked to the motor,
> either a direct motor temperature, or the motor drive electronics. Again,
> they settle to about 40 above ambient in C when not in use.  I have added
> this as motor temp.
>
> I have found that the charger temperature rises a little while driving,
> and the motor temperature possibly a tad while charging (but not much).
> This could simply be because the two are physically close, or the charger
> could be involved in regenerative braking.
>
> Rapid/quick charge detection.
> During RC the bus has PID 346 messages, but the range in byte 7 is 255
> rather than a valid estimated range. I have seen logs showing 255 for a few
> samples at startup, so maybe we need to add a test for this 255 being
> stable for more than a second or two. Of course the problem now is that we
> have lost the predicted range. We have "ideal" range, but that is a bit of
> a chocolate teapot as you are never going to get that range and it is not
> correctly calculated in my opinion (due to unusable SOC at the bottom of
> the battery).
>
> I have studied some of my charging records and it seems that the predicted
> range hits 0 at about 10% SOC, and it is roughly linear to 100% from there.
> The slope of the line depends on the recent driving style. I have used this
> to code a replacement "guess-o-meter" for use during rapid charge. The way
> it works is as follows: I constantly record valid SOC and est_range until
> either of them gets too low to be reliable (20% SOC or 5 range) - this
> gives me an indication of the slope that should be used for the line.
> During RC I calculate est_range = (SOC-10%) * Slope,  where Slope =
> (Old_Range / (Old_SOC-10%)). This works, but I have only tried one RC with
> this code and the ranges it gave me were a bit higher than I expected. This
> might need some debugging.
>
> I have attached the revised code. You will see that I have also optimised
> the PID filtering a bit to try and reduce load while still capturing the
> increased number of PIDs we are now monitoring. I wonder how easy it is to
> check how close we are to running out of CPU capacity in the read code.
>
> Matt Beard
>
>
>
>
> On 17 October 2013 07:10, Matt Beard <matt at beard.tv> wrote:
>
>> I hope to be able to do so in the next day or so.
>> Matt
>>
>>
>> On Wednesday, October 16, 2013, Thomas Bergo wrote:
>>
>>> Greate work.
>>>
>>> If you share your discoveries and your code, I can also do some testing.
>>>
>>> Regards, Thomas
>>>
>>> onsdag 16. oktober 2013 skrev Matt Beard følgende:
>>>
>>> I was wrong about the bus being quiet during RC and have figured out how
>>> to detect rapid charging.
>>>
>>> Also I've found the AC charger temperature (which should probably go in
>>> PEM temperature) and I'm pretty certain I have found the motor temperature
>>> (but I need to do more testing). What I really want is the ambient
>>> temperature, but no sign yet. Any ideas?
>>>
>>> Matt Beard
>>>
>>>
>>> On Friday, September 27, 2013, Matt Beard OVMS wrote:
>>>
>>> Has anyone seen a CAN log from a rapid charge?
>>>
>>> Is the OBD port active at all during rapid charge? I found nothing gets
>>> reported during RC.
>>>
>>> Matt
>>>
>>>
>>>
>>> On 26 September 2013 10:29, Thomas Bergo <thomas.bergo at gmail.com> wrote:
>>>
>>> Ok, then you have the same issue.
>>>
>>> Will look into this later.
>>>
>>> Regards, Thomas
>>>
>>>
>>> 2013/9/26 Matt Beard OVMS <smvo at mxf.org.uk>
>>>
>>> My STAT? gives:
>>>
>>> Not charging
>>>  SOC: 100%
>>>  Ideal Range: 93 mi
>>>  Est. Range 68 mi
>>>
>>>
>>> On 26 September 2013 10:02, Thomas Bergo <thomas.bergo at gmail.com> wrote:
>>>
>>> Matt:
>>> Do you get the ODO in the "STAT?" SMS message?  I did until two days
>>> ago, did a cleanup of the code before push to GitHub. After that i haven't
>>> got ODO.  Can't see any changes to the code from the previous version ether.
>>>
>>> Regards, Thomas
>>>
>>>
>>> 2013/9/25 Matt Beard OVMS <smvo at mxf.org.uk>
>>>
>>> Having disconnected OVMS and power-cycled the car the charge seemed to
>>> be going OK, so I connected the unit back up and let it go the last 50% or
>>> so with OVMS and it was still fine. So, looks like something set a bad
>>> value! Maybe there is a "set max % charge" CAN message and it got set due
>>> to noise on the bus. Wish I knew what it was!
>>>
>>> Matt
>>>
>>>
>>>
>>> On 25 September 2013 14:35, Thomas Bergo <thomas.bergo at gmail.com> wrote:
>>>
>>> How did the rest of the charging go?
>>> Any other hick ups?
>>>
>>> Regards,Thomas
>>>
>>> onsdag 25. september 2013 skrev Matt Beard følgende:
>>>
>>> The SOC was about 25%
>>>
>>> Matt
>>>
>>>
>>> On Tuesday, 24 September 2013, Thomas Bergo wrote:
>>>
>>> Was the SOC approximately 70% ?
>>>
>>> The Car takes a pause and stops charging for some time at 70%. I belive
>>> this is to level the charge state of the cells. After some time the
>>> charging will continue.
>>>
>>> Regards, Thomas
>>>
>>> tirsdag 24. september 2013 skrev Matt Beard følgende:
>>>
>>> More strange behaviour with my C-Zero.
>>>
>>> Trying to investigate charging current today I discovered that the car
>>> would not charge for longer than a couple of minutes with the OVMS
>>> connected (with Thomas' image loaded). It would start charging, then the
>>> current would drop to zero, but the charge light stayed on. After a while
>>> it stopped even trying to charge. Disconnecting the OVMS didn't fix it
>>> until I also turned the car on and off again (with the OVMS not connected).
>>> Did can noise cause problems again?
>>>
>>> Matt
>>>
>>>
>>> On Tuesday, September 24, 2013, Thomas Bergo wrote:
>>>
>>> The first models (2011) was delivered with a 16A cable. This was changed
>>> for the later models (2012 ->) to 10A cable do to firesafty.
>>> At home i use a 16A cable for charging, but the car only draw 13A.
>>>
>>> I'm not sure what is the correct info, EVSE limit or the charger limit.
>>>
>>>
> <vehicle_mitsubishi.c>_______________________________________________
>
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20131023/0b438e48/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_1406.PNG
Type: image/png
Size: 171832 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20131023/0b438e48/attachment-0002.png>