Jack, 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