can.c has the logic. This is related to two messages B1=0x96 (doors) and B1=0x95 (charging mode) handed on can id#100 (in can_poll0 function). The logic was originally inherited from scott451 via RCM, and there doesn't seem to be a 100% match between what is documented and what we are seeing on the bus.

The logic we are aiming for is to alert whenever charging is stopped. Done is ok, but stopped (however) should be alerted.

Two global variables are used:

extern unsigned char car_charging; // 1=yes/0=no
extern unsigned char car_stopped; // 1=yes,0=no

The car_charging variable is set depending on bit #4 of B2 of message B1=0x96 (the doors message) and is designed to purely reflect whether the car is currently being charged or not. The car_stopped variable is set when charging stops (ie; a transition from charging -> not charging), and cleared after any necessary alert has been issued. This is also done on B1=0x96 (the doors message):

if ((car_charging) && !(can_databuffer[1] & 0x10)) // Already Charging? Stopped?
{
car_stopped = 1; // Yes Roadster stopped charging, set flag.

}

car_charging = (can_databuffer[1] >> 4) & 0x01; //Charging status

That seems a bit messy, and maybe better implemented by as:

// Suggested improvement:

if ((car_charging) && !(can_databuffer[1] & 0x10)) // Already Charging? Stopped?
{
car_stopped = 1; // Yes Roadster stopped charging, set flag.

}

car_charging = (can_databuffer[1] & 0x10); //Charging status

The alert itself is raised in the processing of id#100 message B1=0x95 (the charge status message):

if ((car_chargestate >= 0x15)&&(car_stopped)) // Stopped charging?

{

car_stopped = 0;

net_notify_status();

}

The car_chargestate is B2 from the same message (id#100 B1=0x95 charge status). The data we have on that byte is:

0x01=charging

0x02=top off

0x04=done

0x0d=preparing to charge

0x0f=heating

0x15-0x19=stopped charging

I can see one issue, that when the charge stops of car_chargestate is <0x15, the car_stopped can never get cleared. Perhaps we need to change that code to:

// Suggested improvement:
if (car_stopped) // Stopped charging?
{
car_stopped = 0;
if (car_chargestate >= 0x15)
{
net_notify_status();
}
}

But, I still can't see why that would raise an alert, as it can't unless car_chargestate >= 0x15 (which should never happen according to what we know, unless the charge is stopped somehow).

Theory: Perhaps there is some momentary status change, when you plugin or when the charge starts, to a 0x95 B2 charge state > 0x15 that we don't know of. We won't see it in the net_notify_status() because that happens a second or so later (the net_notify_status just sets a flag for the status to be notified in the next ticker of the event loop about a second later). I checked my can bus dumps, but can only find the following values for B2 of B1=0x95 id#100:

0x01
0x04
0x0D
0x0E
0x17

and none of those were momentary.

Regards, Mark.

On 13 Feb, 2012, at 3:51 PM, Jack West wrote:

Mark, Michael and others,

I flashed the 1.2.0 rc3 and installed in our 2.5 non sport US car. I plugged in the car which was cold (<0C) after being left outside all day. This is what I saw:

VDS = "Preparing to charge, battery heating, 0% complete" (the car was heating the battery with 8amps/240V)
SMS STATUS = "charging, heating"
IOS app= standard 'non charging' screen. no "preparing" or "heating". car icon shows charge port door open

slide pilot switch off

did not get SMS alert that charging stopped
SMS STATUS = "preparing"
IOS app = no change, no alerts or msg. does correctly see doors open and close (server connected)

cycle charge port door
connect cable
slide pilot on

VDS = "Preparing to charge, battery heating, 16% complete"
SMS STATUS= "charging, heating"
IOS app = no change, standard non charging screen

Push "stop" on VDS
IOS app = "charging stopped"
I did not get a SMS msg or a net alert

I started to look at the code to see whats up but I'm out of time tonight. Will get back to it tomorrow night.

Jack

On Feb 12, 2012, at 5:34 PM, Mark Webb-Johnson wrote:

Guys,

A few developers have asked me how they can best help out.

Here is what we have at the moment (in no particular order, and apologies if I've missed anything):

Mark W-J (me): iOS App and finalising the 1.2 car firmware
Michael S, Jack W: car firmware (particularly the can bus area)
Sonny C: Android App, simulator, car firmware (particularly modem work)
Felix B: Graphics
Pierre U, Piotr P: Debugging sub-zero temperature issues
Udo W: Offered to help with Android
Manuel M: Drupal module (Web App) for car registration
Oliver W: hardware module design
Andrew B: Use of OVMS as a data logger for other projects
Several: Helping users get this deployed, and debugging hardware issues ;-)

Weak points that I see are (a) server, (b) high-level functions (charging options, trip and charging logs, etc), (c) server (drupal) web apps, and (d) applicability to other EVs (eg; Leaf). But, there is so much that can be done, please feel free to jump in wherever - please just let us know what you are doing.

The most important thing at the moment is testing, and acting as regional support for an end-user release (helping with installation and support for your part of the world). Please update to the 1.2.0 release candidate firmware, and try out the new functions. Let us know what doesn't work (and probably just as importantly, what works for you).

If anyone has access to older (v2.0, v1.5) cars, or non-metric cars (USA?), please try the module in those cars and let us know the result.

Regards, and thanks,
Mark.

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev