- OvmsDev - Open Vehicles

1.2.0 Release Candidate
by OVMS Developers 14 Feb '12

14 Feb '12

Dear Developers, We finally have a feature complete release candidate for the OVMS software. At this stage, we would like to get this deployed to as many cars as possible to work out any final bugs. This release candidate is version 1.2.0-rc3, and you can find it on github in the master branch. To upgrade your car to this version, just flash the firmware as normal (remember to set the flags to preserve EEPROM or you'll have to reset the parameters - the experimental config has these flags set correctly for upgrades). There are two changes that might impact you: This version has support for the GSM-only/GPRS-enable switch on the PIC board, so please take care with this. You will need the switch OFF in order to get GPRS connectivity. If you see the usual red-green alternating LED sequence then a solid green without any red light blinking, the switch is probably in the wrong position (you should try it in the other position, then reset the module). This version re-works the old compile-time #define statements to be run-time FEATURE settings. The only one important is the WRITE enabled can bus, which is feature #15. To enable this feature, send a SMS to the car (from your registered phone) "FEATURE 15 1", and then reboot the module. Compared to the v1.0 firmware, there are a huge number of enhancements in v1.2. The biggest of these are: FEATURES (write-enabled CAN bus, location streaming, minimum SOC alerts, etc). Optional digital speedometer experimental code Improvements in miles->km conversions Improvements in modem initialisation and control Fixes for support of sub-zero temperatures and battery pre-heating before charging Watchdog timer support App->Server->Car command support, including: Start/Stop Charge Set charge mode Set charge current Activate/Deactivate Valet Mode Lock/Unlock Car (doors only - alarm and immobiliser cannot be deactivated where fitted [non-US cars]) Feature list and set Parameter list and set Wake up car GPRS utilisation Social group subscription Ambient temperature monitoring Many more vehicle parameters sent to server (including speed, direction, altitude, charge states, doors, etc) The Android App (in the market) already has experimental support for most of these new features, and the iPhone App is currently being extended (and we should have an experimental testflight release this week). We will most likely have a few more release candidate releases before final end-user firmware is cut, but we would like to get the current 1.2.0-rc3 installed in as many cars as possible, in the next few days - and would be grateful if you could assist. Any questions / problems should be addressed to this developers mailing list. Regards, Mark.

3 2

Re: [Ovmsdev] trying new firmware
by Mark Webb-Johnson 13 Feb '12

13 Feb '12

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(a)lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >

1 0

How to help
by Mark Webb-Johnson 13 Feb '12

13 Feb '12

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.

1 0