June 2012 - OvmsDev - Open Vehicles

Re: [Ovmsdev] Cool down
by Bennett Leeds 11 Sep '12

11 Sep '12

I've been doing 220volt 15 amp charging to cool the battery. Like Tom, I manually stop it when the battery temp reaches 80F. Like Mark, I found that low amp charges didn't cool the battery as much - I'll speculate that Tesla probably sees the low amperage and figures that it can't waste as much juice cooling the battery, and that a slow charge won't really heat it up much. Have you thought about parameters for the CoolDown function? - Desired End Temperature - Amperage to Use - Maximum length of time to run Also, have you considered an "Auto" feature, where when OVMS sees the car is plugged-in but not charging and that the battery temp is high, automatically kicks on to cool it? The max run time parameter is kind of a safety feature to avoid running too long at high prices. - Bennett

2 1

Fwd: OVMS at Laguna Seca on Sunday
by Mark Webb-Johnson 29 Jun '12

29 Jun '12

Saw this on TMC as well. I love the idea, and really hope you get some takers. Regards, Mark. Begin forwarded message: > From: Bennett Leeds > Subject: OVMS at Laguna Seca on Sunday > Using OVMS Social Group "REFUEL" > If you're running at Laguna Seca on Sunday and have OVMS, why not add the Social Group REFUEL? That way people can watch us race virtually, either via theOVMS app, or by going to maps.google.com and entering the following into the search box: http://tmc.openvehicles.com:6868/group?id=REFUEL > > I'll also be running under the REFUEL42 Social Group, in case you want to see how I'm doing (I'm car #42). I'll also have GPS streaming on, so you should get reasonable updates. > > - Bennett

1 0

Volt/Ampera CAN Logs
by R. Scott Perry 28 Jun '12

28 Jun '12

Hi everyone, I'm the RScott from gm-volt.com, and I wrote the page at evtools.info about the Volt and OBD2 data (which I haven't updated in quite some time). I've read the recent posts to the list about the Volt, and thought I would provide information here in response. First, if it would be helpful, I have written a program for Windows to record data from an OBD2 scanner. It is designed to work with scanners that use the ELM327 chip (or are compatible). It saves the timestamp, and saves the data in the format "11:48:45.829: 206 639600". It is run from a command prompt, and not very user friendly. For the SOC, the "206 3 69 C3 00" capture indicates CAN ID 206, with 3 bytes of data. The SOC data only uses the first two bytes, so this would be 0x69C3, or 27075d. Dividing by 4,000 gets 6.769kWh in the battery, or about 42% of the total battery capacity, which should be 4 bars on the display. http://gm-volt.com/forum/showthread.php?5328-Volt-Diagnostic-Tool&p=91868#p… correlates the SOC number here with the bars displayed. The VIN can be constructed by taking the number "1" and converting the CAN IDs 4E9 and 514 to ASCII. So with "4E1 4255313032363839" and "514 4731524436453436", you would end up with 42 55 31 30 32 36 38 39 47 31 52 44 36 45 34 36, where 42 is ASCII for B, 55 is U, etc. The latitude/longitude conversion is almost the same as what you have for the Tesla, with two exceptions -- changing the 2048 to 1000, as noted, and the accounting for negative numbers is different. It seems that the number the Volt supplies is a 31-bit signed integer. The easiest way to handle that, I think, would be to add "latlon = latlon << 1;" before checking for <0, and then "latlon = latlon >> 1;" afterwards. Running the code you have with those two changes seems to work fine. The bad news is that I have checked all my log files (I have been logging almost all the time I have driven for about 8 months now), and the CAN ID 32A (latitude/longitude) has never shown all zeroes. If the GPS data is unobtainable, I believe the car reports the most recent reading. The GPS data comes from the OnStar system, so I am thinking it may only provide the data if the OnStar service has been activated, which could be a problem for owners outside of U.S/Canada. For charging, all I have found so far are some numbers that appear to show electricity flow to/from the battery. If they are positive, electricity is going to the battery; if negative, electricity is leaving the battery. But this will also be positive if the gas engine is on and charging the battery, as well as if the car is going downhill and the regenerative braking is being used. -Scott

5 22

Cool down
by Mark Webb-Johnson 28 Jun '12

28 Jun '12

I've been experimenting with cool down, but can't get it to work as I expect. For example, here are the results for a recent charge: 7:15pm - Ambient: 30ºC, PEM: 37ºC, MOTOR: 54ºC, BATTERY: 39ºC, SOC: 74%, IDEAL: 230km. Arrived home and plugged in (timer delayed charge, so nothing happens). 7:28pm - Ambient: 30ºC, PEM: 38ºC, MOTOR: 53ºC, BATTERY: 39ºC, SOC: 74%, IDEAL: 230km. Action: Force charge at 220V 10A. 7:33pm - Ambient: 30ºC, PEM: 45ºC, MOTOR: 51ºC, BATTERY: 39ºC, SOC: 74%, IDEAL: 230km. Still charging 220V 10A. 7:42pm - Ambient: 30ºC, PEM: 45ºC, MOTOR: 47ºC, BATTERY: 39ºC, SOC: 75%, IDEAL: 232km. Still charging 220V 10A. 7:58pm - Ambient: 30ºC, PEM: 45ºC, MOTOR: 43ºC, BATTERY: 39ºC, SOC: 75%, IDEAL: 235km. Still charging 220V 10A. 7:59pm - Ambient: 30ºC, PEM: 45ºC, MOTOR: 43ºC, BATTERY: 39ºC, SOC: 75%, IDEAL: 235km. Action: Increase charge current to 220V 24A. 8:48pm - Ambient: 34ºC, PEM: 47ºC, MOTOR: 39ºC, BATTERY: 34ºC, SOC: 82%, IDEAL: 256km. Still charging 220V 24A. 8:49pm - Ambient: 34ºC, PEM: 47ºC, MOTOR: 39ºC, BATTERY: 34ºC, SOC: 82%, IDEAL: 256km. Action: Increase charge current to 220V 48A. 9:03pm - Ambient: 34ºC, PEM: 53ºC, MOTOR: 39ºC, BATTERY: 33ºC, SOC: 86%, IDEAL: 267km. Still charging 220V 48A. 9:18pm - Ambient: 33ºC, PEM: 53ºC, MOTOR: 39ºC, BATTERY: 33ºC, SOC: 90%, IDEAL: 283km. Still charging 220V 48A. 10:19pm - Ambient: 30ºC, PEM: 41ºC, MOTOR: 38ºC, BATTERY: 33ºC, SOC: 95%, IDEAL: 299km. Charge had completed (some minutes early) and car was sleeping. Some comments: There was no appreciable change to the battery temperature (@39ºC) when slow-charging at 220V 10A. Increasing charge rate to 220V 24A did seem to bring down battery temperature (@34ºC). Increase in ambient temperature when charging @24A is most likely due to the car being in the garage, and aircon dumping charging heat raising ambient temperature in the garage. Between 7:28pm and 7:59pm, charging @10A, the charger put 5pm ideal miles into the car, +7ºC on the ESS, but zero change to battery temperature. Is the battery @39ºC not hot enough for cool down to matter? Anyone know the default thresholds for Tattler, or anyone doing this manually and seen any affect? Regards, Mark. P.S. I'll try to drive a little more spirited, with the aircon off and performance mode engaged, on the drive home tonight, to see if I can bring up the temperatures to make the affect more pronounced. Forecast is for 33ºC ambient, and it'll be hotter than that in the city.

3 5

Issue #61
by Mark Webb-Johnson 26 Jun '12

26 Jun '12

I've made a small revision to the firmware for upcoming 1.3.1. https://github.com/markwj/Open-Vehicle-Monitoring-System/issues/61 For the MODULE, SERVER and GPRS SMS commands, rather than just replying "Parameters set...", reply with the detailed setting (MODULE?, SERVER?, GPRS?). It seems to work nicely and gives you a good confirmation of the setting that you just changed. This is instead of the old "Parameters set..." message. Regards, Mark. P.S. Bennett: Not sure if the manual needs to be updated to reflect this - can you check? Or, is this a bad idea?

2 1

Re: [Ovmsdev] Android development
by Mark Webb-Johnson 26 Jun '12

26 Jun '12

Since I called out, three prospective parents have come forward. I'm arranging this, but need to be able to build the releases myself for Android marketplace. Getting familiar with Android builds, but trying to finish off the current projects (1.3.1 firmware, ampera framework) first. I think Android will be fine. Just will take time to transition. Regards, Mark On 24 Jun, 2012, at 3:51 AM, "Pierre Uhl" <pi.uhl(a)bluewin.ch> wrote: > I think since Sunny is busy with his project, the android branch is orphaned. > > Pierre > > Von: ovmsdev-bounces(a)lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von William Petefish > Gesendet: Samstag, 23. Juni 2012 17:16 > An: OVMS Developers > Betreff: [Ovmsdev] Android development > > Is anyone currently working on the android branch? > > William > > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

2 5

Android development
by William Petefish 24 Jun '12

24 Jun '12

Is anyone currently working on the android branch? William

2 1

Roadster charge interrupted - new substate code
by Mark Webb-Johnson 13 Jun '12

13 Jun '12

Interestingly, I just got an alert that charging was interrupted on my roadster, just a few minutes into its scheduled (timer-delayed-charge) 9pm charge. Before the charge, I got Sub-State: 0x02 (scheduled start) State: 0x0E (wait schedule) After interruption, I got Sub-State: 0x0D (previously unknown) State: 0x0C (previously unknown) Error on the car VDS was "External Charger Problem" ID:1084, and charge port was flashing red. The HPC charger on the wall had a ground-fault protection red light on. I cleared the HPC fault, and restarted charging. All seems ok, and can bus is now showing: Sub-State: 0x05 (timer wait) State: 0x01 (charging) Looks like we've found a new set of fault codes. Regards, Mark.

1 0

OVMS Hardware v2.0
by Mark Webb-Johnson 12 Jun '12

12 Jun '12

Apologies for the length of this eMail, but lots to go through... We've come to the end of our initial batch of boards, and there are significant minimum-order-quantities for things like circuit boards, so we are taking the opportunity to switch to hardware v2.0. The roadster owners who wanted something like this presumably already have it, or are waiting for Tesla's solution. So, we're trying to think mostly of the _other_ cars out there. Things like the Volt/Ampera, Leaf and my wife's ICE Nissan children ferry. The problems we've had with the current hardware include: Production reliability issues with the factory Quality issues (particularly soldering) with the factory Too fiddly to produce and too many components Too hard to diagnose problems QC and Logistics is just a hassle for Sonny and myself - not fun ;-) Once we add in using this in other cars, we also get: Concerns over 12V battery load Lack of GPS in some cars Things got better as the existing hardware went from 1.0 (initial prototype with RJ11s) to 1.1 (kludgy developer prototypes with glued-on adaptor cables) to the current 1.2 (little white 4pin and 2pin connectors), but still just too much work to get these made. Accordingly, what we are trying to do is come up with a v2.0 hardware design. As what we have works so well, there seems little point in making any dramatic shifts - we've considered switching to a 32bit processor, built-in touch-screen display, etc - as that would be something completely different. We just want to incrementally improve the points that are 'hurting' now. Keep it a very low cost module that does what it does well. Here are the changes we have come up with: Change to a single-board approach, made by a single factory. The board will contain the controller and SIMCOM GSM/GPRS system in one. The board external connectors will be exposed through the box. We'll use a standard DB9 (male), then adaptor cables from that to each car's requirements. Pins are #2 CAN-L, #3 GND, #7 CAN-H and #9 +12V. The existing diag DB9 (female) is unchanged, but should be externally accessible. IPC pins to also be externally accessible, so firmware can be updated without opening the case. Upgrade the processor from 2680 to 2685. Gives us more flash (useful for cars other than roadster), but otherwise completely compatible. Connection of 12V line to microprocessor ADC. This will allow us to measure supply voltage and take appropriate actions. Upgrade SIM900 to SIM908, to give us optional GPS for cars that don't have it - this can be powered up/down by AT commands. LEDs go to the bottom of the board, to be closer to the holes and hence more visible. QC and logistics done in china - a partnership with a website there to handle order processing and logistics from stock. I really want to make something very very clear - this is not intended as an 'upgrade' for existing v1.x modules for roadster owners. The Tesla Roadster is covered, and work really well with v1.x hardware. New roadster owners will be able to use v2.x hardware as well, but there is no point in 'upgrading' from v1.x to v2.x hardware, for Roadster owners. The new v2.x hardware is primarily intended to make it easier so support other types of cars. As I mentioned at the top of this email, we're down to the last few v1.x modules - there was a recent unexpected rush of orders. So, today, we've taken down the hardware offering at www.openvehicles.com, until the v2.x hardware arrives. If someone _really_ needs a v1.x module, we still have some and can let you have it, but we really want to keep as many of the modules we have left as repair spares for existing owners. For those working with us on OVMS in other cars (Michael on Volt/Ampera, etc) don't worry - we'll look after you and swap you v2.x hardware if necessary. We're just now entering prototype stage with the factory, so if anyone has any comments/suggestions please send them in. I'm working hard on this. So long as the prototypes are ok, we should have production ready in 4-to-6 weeks. Regards, Mark.

7 26

Tattler Hardware
by Bennett Leeds 11 Jun '12

11 Jun '12

This is what Scott originally posted on TMC (at http://www.teslamotorsclub.com/showthread.php/5055-New-cell-phone-app-Tesla… ): V4 (this version) runs on "off the shelf" ARM9 hardware. Linux ARM processor w/CAN controller, 2GB SD card, +12 pwr supply. GPRS GSM modem. - Bennett PS: Scott Byer (SByer on TMC) has a Tattler he hasn't installed. Might be worth a PM to him to see if he'll open it up and report back what he sees.

1 0