- OvmsDev - Open Vehicles

Fwd: Open Vehicle 1.2.9 (20120606) is now available
by Mark Webb-Johnson 06 Jun '12

06 Jun '12

This one may be buggy, so take care. It has homelink support (which needs testing, please). It also has some bug fixes and provisional support for the temperate, speed and distance units conversion (see settings in Settings App). Note that settings also has a new privacy setting "Share Vehicle Colour". If enabled, it will share you vehicle colour to any groups you subscribe to (so other users subscribing to the same group can see your car in the correct base colour). Regards, Mark. > > Open Vehicle 1.2.9 (20120606) > Team: Open Vehicles > What's New: > Bug fixes and enhancements: > - Issue #52: iOS App: Homelink support > - Issue #55: iOS App: Cars EDIT mode looks strange > - iOS: Show actionsheets in window, to fix cancel-button obscured by tab bar > - Temperature, Distance and Speed Preferences. Callout labels on Location. > - Fix problem handling groups with spaces > - Work-around crash for features and parameters HUD view with no view > > Released: June 6, 2012 > Expires In: 5 months, 3 weeks > Size: 7.6 MB >

1 0

Rafael - Around the world in 80 electric days
by Mark Webb-Johnson 05 Jun '12

05 Jun '12

He had his doubters, but hats off to Rafael for the progress he's made. He left spain on 11th May, drove up to Germany, then DHLed the car to New York, arriving on the 21st. Now, a week later, he's reached Colorado - about 2/3rds the way across the USA. What's the connection to OVMS? Well, he's one of our early OVMS adopters and has OVMS in his car (using a global roaming SIM), uploading status to the servers and his website. He's also using the smartphone app to get alerted to charge interruptions (and he's got a lot of charge stops along the way). The Google Maps tracking data (KML) comes directly from the OVMS status updates. He's also demonstrating and promoting OVMS every opportunity he gets (leaving a wake of impressed Tesla store staff along the way). You can follow his progress at: http://www.1e-race.com/ Unfortunately, he can't get permission to drive through Hong Kong, so I won't get to directly support him, but he's heading to the west coast of USA now, so perhaps you guys in his path could meet up and help him out. Perhaps a convoy? Mark.

1 1

Tesla Roadster - CAN reverse engineer - id#100 B1=05
by Mark Webb-Johnson 04 Jun '12

04 Jun '12

Working on my can-re-tool, I tried parsing some old logs, and this one popped out as obvious when viewing it as ASCII (doh, why didn't I think of that before?): id#100 B1=05 My sample data: 100 05 44 01 00 48 4B 00 00 .D..HK.. Michael Stegen has: 100 05 44 01 00 4E 4C 00 00 .D..NL.. It also seems that rather than the usual B1 uniqueness for this message, B2 also matters. ID#100 B1=05 B2=44 seems to have the country of the car. I'm also seeing B2=12, B2=14 and B2=46. Data for those is: 100 05 12 01 00 03 06 04 00 100 05 14 01 00 28 00 00 00 100 05 46 01 00 15 F5 17 00 Could these be the elusive car firmware version messages? In particular, '100 05 12' looks suspiciously like my previous firmware version 4.6.3, and '100 05 14' shows B5=28 which is the HW Pkg 40 (decimal) of the old firmware version as well. These don't appear in all logs (which is probably why we didn't see them before), but in the log I get the most of these, I see a prior ID#102 transmission from the VDS: 1320743357.560 R11 102 04 12 1320743357.584 R11 102 04 14 1320743357.607 R11 102 04 44 1320743357.708 R11 100 05 12 01 00 03 06 04 00 1320743357.709 R11 100 05 14 01 00 28 00 00 00 1320743357.709 R11 100 05 44 01 00 48 4B 00 00 1320743357.828 R11 102 04 12 1320743357.831 R11 100 05 12 01 00 03 06 04 00 1320743357.851 R11 102 04 14 1320743357.856 R11 100 05 14 01 00 28 00 00 00 1320743358.009 R11 102 04 12 1320743358.011 R11 100 05 12 01 00 03 06 04 00 1320743358.031 R11 102 04 14 1320743358.034 R11 100 05 14 01 00 28 00 00 00 Time to take my laptop to the car and see what else I can coax out from there.... My car firmware has since been upgraded to 4.6.5, so this should be simple to confirm. Regards, Mark.

1 0

f erienabwesenheit: Re: Volt/Ampera CAN Logs - ferienabwesenheit
by mm＠raumgleiter.com 02 Jun '12

02 Jun '12

1 0

Hi everyone
by David Peilow 02 Jun '12

02 Jun '12

Hi, I've just signed up here so it will probably take me a while to get up to speed on the work done so far. First off, can you advise me on what cable I need to obtain to pull logs (I saw RScott's program link) and also where to buy one? Thanks, David

4 4

Re: [Ovmsdev] Volt/Ampera CAN Logs
by mm＠raumgleiter.com 01 Jun '12

01 Jun '12

1 0

Re: [Ovmsdev] Volt/Ampera CAN Logs
by Michael Jochum 31 May '12

31 May '12

Hi mark, > > Probably best to continue the discussion on the ovmsdev mailing list, as others there are interested in progress (especially dpeillow and Marcus). Yes. answer to the list. > > What you have below is a 'cyclic' log. Good for identifying unique messages (by ID) seen on the bus. Can you see if canhack has a normal logging mode to just log all messages with a time stamp? i will do my best. > > What type of PC do you use? Linux, Mac or Windows? For this first i use a PC with XP. > > From what RScott has written, the can bus you are on looks to have what we want. I understand everything stops when car is turned off. But, can you try recording while charging and see if it still stops? Yes, it stops too when it is charging. > > I think that as a starting point we should target a limited amount of information, to just try to get something working and see how feasible this is. Specifically, I suggest: > > SOC% (CAN ID #206) > GPS Latitude and Longitude (CAN ID #32A) > Vehicle Speed (CAN ID #3E9) > VIN (unknown CAN ID, but supposedly there) > > From the document at: > > http://www.EVtools.info/ChevyVoltOBD2CAN.html > > these should be: > > CAN ID Location Data Units Notes > > > > > 206 Bytes 1-2 Battery SOC .250kWh Units possibly .244kWh > 32A Bytes 1-4 GPS Latitude Milliarcseconds > 32A Bytes 5-8 GPS Longitude Milliarcseconds > 3E9 Bytes 1-2 Speed 1/100 MPH 55MPH would be 5500 (0x157c) > > Looking at your capture, you have: > > 206 3 69 C3 00 at this time the battery was charging. i think ist was between 30 and 40 %. you must know that the lowest usable Battery power is at 30% an full is at 90%. i will got the next log when the battery is full > 32A 8 00 00 00 00 00 00 00 00 > 3E9 8 00 00 00 00 00 00 00 00 > > Probably your car was stationary or in the garage without GPS signal? it was stationary in front of my house with clear view to the sky. > > RScott's sample data is: > > 11:48:49.885: 206 628600 > 11:48:54.955: 206 5FCA00 > 11:48:49.636: 3E9 0BAC01AC0B3C019E [Speed 29.88MPH] > 11:48:49.870: 3E9 0C3B01C20BED01B4 [Speed 31.31MPH] > > Can you try to capture: > > The SOC% in your car, as displayed by the car itself, and matching capture of ID #206. is coming > Drive down a stretch of road at a constant speed, while logging. Then, get the approximate latitude and longitude of your position and speed you were at, and matching capture of ID #32A and ID #3E9. i only have two hands. :-) > Put the car in the open air, so it has a good GPS signal. Then, get the exact latitude and longitude of your location, and matching capture of ID#32 > The VIN number of your car. > > Based on that, we should be able to setup OVMS to capture this and transmit it on to the OVMS server/apps. yes > > Do you want me to create the framework for this in can_voltampera.c? Maybe easier for me to create the first few messages, and then for you to adjust and fix, as I know the code so well. ok, so it looks good. > > This is looking really promising. Your 104 captured IDs seem to match RScott's 105 almost exactly, and most of what we need has already been discovered. Good. Bye michael > > Regards, Mark. > > On 29 May, 2012, at 6:03 AM, Michael Jochum wrote: > >> Hi Mark, >> >> i did the first try to get a CAN Log from my Volt. It works. I got a first small output. Didi it with CANHACK. Unfortunately the Log is not so formated that a Program can read it. A human can. Still waiting for your script. >> But, ... we have a problem! 10 seconds after the car is shut down the is no more traffic on this CAN bus. 12V are still there. >> But there are three (3) more CAN Buses in this car. Really! >> Two at the OBD2 Connector driver side and two at the OBD2 Connector Passenger side. >> I will made me some adapter to get access to this Signals. Hope they still alive after shutdown the car. >> >> Here is the small Log: (i think this is NOT a time based log. it seems that this is a log from all seen messages) >> >> >> Bye >> Michael >> >

4 7

Fwd: Homelink
by Mark Webb-Johnson 31 May '12

31 May '12

Hey, not bad for an amateur :-) Mark

1 0

Volt/Ampera CAN bus - what is known
by Mark Webb-Johnson 29 May '12

29 May '12

Best reference I could find for CAN messages on the Volt/Ampera: http://www.EVtools.info/ChevyVoltOBD2CAN.html from: http://gm-volt.com/forum/showthread.php?9386-30-OBD2-CAN-tool/ Original reference link was from dpeillow. Thanks. I've written to the guy (RScott) to see if he can help out. From what's written in this document, we can get easily SOC, speed, and gps position. And, that is a fantastic start. Michael (in Germany) has started work on this, and his Ampera logs look good. Michael: can we discuss here, on the ovmsdev mailing list, so others know what is going on? Regards, Mark. EVtools.info - Chevy Volt OBD2 CAN Data Summary The Chevy Volt produces an amazing amount of information, that can be obtained with an inexpensive (~$30) OBD2 connector. While OBD2 is typically used to troubleshoot problems by requesting data from the car, the Volt produces a constant stream of data. This includes speed, battery charge, accelerator/brake position, shifter (PRNDL), and latitude/longitude. About OBD2/CAN OBD2 is a protocol that most cars built since 1996 include. It provides a way for tools to find out why the 'Check Engine' light is on, as well as a way of requesting data for troubleshooting. In some cars, like the Volt, it acts like a local area network, where parts of the car communicate with each other. CAN is simply one of many formats that can be used for transferring data. OBD2 usage in the Volt The Volt has 2 connectors (the standard one on the drivers' side, and an extra auxillary one on the passengers' side), with a total of 5 buses: OBD2 Location Pins OBD2 Protocol Data Protocol Speed CAN ID length Use Primary Data Link Connector 1 SAE J2411 (SWCAN) Low Speed GMLAN 33.3kbps ??? Body Electrical Services Primary Data Link Connector 6, 14 Standard CAN (ISO 15765-4, J2284-3) High Speed GMLAN 500kbps 11 bits Primary Powertrain Bus Primary Data Link Connector 12, 13 ??? High Speed GMLAN 500kbps ??? Chassis Expansion Bus Auxillary Data Connector 3, 11 ??? High Speed GMLAN 500kbps ??? High Volt Energy Management Auxillary Data Connector 12, 13 ??? High Speed GMLAN 500kbps ??? High Volt Powertrain Expansion Bus The Primary Powertrain Bus is easily accessible via inexpensive tools. It has been said that all data is gatewayed to the primary DLC, and that the right-hand side was is really only useful for service programming of specific modules. What Tools Can I Use? There are many different OBD2 tools that you can use, depending on what you are looking to do. Just about any should be able to read trouble codes (if the 'check engine' light comes on). If you are looking to get data from the car, there are several known options: DashDaq - The DashDaq is one of the best ways to display Volt data in real-time, where it is visible while driving. The drawback is that it is pricy, with an MSRP of $790 with the Volt license. It can record data onto memory card, but it is unclear if it has a 'Monitor All' mode that can record all data from the Volt, rather than just what is requested. ElmScan 5 - A cable that connects a laptop to the OBD2 port. It includes software, or custom software can be written for it. To use the 'Monitor All' mode, software needs to send a special command to the ELM327 chipset. MSRP is $39.95. Generic ELM327 Cables - The ELM327 chip is commonly used for cables like the ElmScan 5. Most OBD2 software should be able to work with any cable using the ELM327 chip, except that the 'Monitor All' mode requires the ability to switch to 500kbps. As a warning, there are known counterfeits out there, that do not use the real ELM chips. ScanGauge - This has an LCD display (2 lines of 10 characters each) that can display information. Very useful to see data in real-time, but it does not look like it can record data (or take advantage of 'Monitor All'). Prices start at $99.95. MDI, GM-TIS, GDS - MDI (Multiple Diagnostic Interface), GDS (GM's Global Diagnostic System software), GM-TIS. These are various names/components for the official GM tools for accessing the data. It falls into the "If you have to ask, you cannot afford it" pricing category (one source quotes $1,500/year just for the service information). There are likely other products that would work, but the above are known to work with the Chevy Volt. Primary Powertrain Bus - List of CAN IDs The Primary Powertrain Bus -- the one that is easily accessible using many OBD2 tools -- uses CAN 11-bit IDs (which can, in theory, range from 0x000 to 0x7FF, or 0 to 2047). In reality, it appears that there are 105 of them: 096 097 098 0AA 0B1 0B9 0BA 0BB 0BC 0BD 0C1 0C5 0C7 0C9 0D1 0D3 0F1 120 12A 130 135 137 139 140 148 160 17D 182 185 186 1A1 1A3 1C3 1C4 1C5 1C6 1DF 1E1 1E5 1E9 1EB 1ED 1EF 1F1 1F3 1F4 1F5 1FB 200 202 204 206 214 222 224 226 228 230 236 238 287 2C3 2C7 2F1 2F9 32A 348 34A 3C1 3C9 3CB 3D1 3DC 3DD 3E3 3E9 3ED 3F1 3F9 3FB 3FC 451 4C1 4C5 4C7 4C9 4CB 4D1 4D7 4D9 4E1 4E9 4F1 500 514 52A 530 589 770 772 773 778 77D 77F 787 Primary Powertrain Bus - Known Data CAN ID Location Data Units Notes 0C9 Byte 5 Accelerator 0 (0%) to 254 (100%) 0F1 Byte 2 Brake 0 (0%) to Unknown (254?) Typical pressure on brake pedal generates about 30. 135 Byte 1 Drive Position 0=Park, 1=Neutral, 2=Drive/L, 3=Reverse 1A1 Byte 8 Accelerator 0 (0%) to 254 (100%) 1C3 Byte 8 Accelerator 0 (0%) to 254 (100%) 1EF Bytes 3-4 Gas Engine RPM RPM 1F5 Byte 4 Shift Position PRNDL 1=Park, 2=Reverse, N=Neutral, D=Drive, L=Low 206 Bytes 1-2 Battery SOC .250kWh Units possibly .244kWh 32A Bytes 1-4 GPS Latitude Milliarcseconds 32A Bytes 5-8 GPS Longitude Milliarcseconds 3E9 Bytes 1-2 Speed 1/100 MPH 55MPH would be 5500 (0x157c) Data Analysis: Chevy Volt 0 to 60 MPH in 8.53 seconds One of the numbers that people look at for performance cars is the "0 to 60MPH" number (or the closely related "0 to 100KPH" number). I was able to accelerate from 0 to 60MPH (although not in perfect conditions, as I started at a slight angle), taking 8.53 seconds. That was in Sports mode and L. The 0 to 30MPH time was 3.45s (which perhaps was a bit high due to the slight angle I started at). The calculation assumes several things, such as the data I have actually being 1/100MPH units (but it could be offset a bit from reality, as I believe the Volt speedometer reads a couple percent above the true speed). I started the time from the last 0.00MPH reading (which, interestingly, occurs after the accelerator reaches 100%), and end when I hit 60.19MPH (the previous reading was 59.07). It was .468s from the last 0% reading on the accelerator until the car showed >0.0MPH, which would make the 0-60 time 9.0 seconds, if you calculated that way. This was done by an amateur, on the open road, giving safety priority, and wasn't under ideal conditions (specifically, starting at a slight angle, and not perfectly flat). However, it proves that the 8.5s figure that is sometimes quoted seems quite accurate. And when Edmunds tested it at 9.2s, and Consumer Reports at 9.4s, it is likely that they were not using the Sports mode. See below for the analysis of the cost of a jackrabbit start. For the curious, here is most/all of the data that I used (from a file with 188,606 lines in it, as this was part of a longer trip): 11:48:45.829: 206 639600 11:48:45.954: 1A1 00004100000000 11:48:46.110: 1A1 00004100000008 [Accelerator at ~3%] 11:48:46.313: 1A1 000041000000FE [Accelerator at 100%] 11:48:46.422: 3E9 000000FF004E00FB 11:48:46.516: 3E9 00A30100004000FB 11:48:49.636: 3E9 0BAC01AC0B3C019E [Speed 29.88MPH] 11:48:49.870: 3E9 0C3B01C20BED01B4 [Speed 31.31MPH] 11:48:49.885: 206 628600 11:48:54.955: 206 5FCA00 11:48:54.955: 3E9 1783051017350509 [Speed 60.19MPH] The information on the right side are my notes. The CAN ID 206 is the battery SOC, the last 2 numbers of CAN ID 1A1 are the accelerator position, and the first 4 numbers in the CAN ID 3E9 are the speed in 1/100 MPH. Data Analysis: Cost of a Jackrabbit Start Since this is the Volt, I should address energy efficiency of the 0 to 60MPH test, which is the ultimate in jackrabbit starts. For 0-30MPH, it used 0.068kWh of electricity, and for 0-60MPH it used .243kWh of electricity. So it takes 2.5x as much energy to get from 30-60MPH as it does from 0-30MPH. Again, there could be unknown factors here -- it could be, for example, that there is a lag between the time the energy is removed and it is recorded (e.g. if the car reports a number now that is 100ms old). As a comparison, on a similar drive at that location, 0 to 51.5MPH was achieved (at slower acceleration, with the accelerator down an average of less than 20%, versus 100% for the 0 to 60 number) using .254kWh, driving about 1/2 mile. The 0 to 52.5MPH time during the 0-60MPH test was done with just .182kWh, but only going about 200 feet. Adding in the EPA's 37kWh/100 miles, that would be an extra 0.185kWh added to the jackrabbit start, or 0.367kWh to go 1/2 mile versus .254, or a waste of about .1kWh. For those wondering why I had to add those extra .185kWh, it's because with the jackrabbit start you hit the top speed after traveling less distance. So to properly compare the slow start with the fast start, you need to add in the energy that would be used to travel that extra distance. (C) Copyright 2011 EVtools.info

1 0

Car firmware v1.2.7
by Mark Webb-Johnson 29 May '12

29 May '12

Inching towards the v1.3.0 release, I've just committed to github v1.2.7 of the car firmware for OVMS. Changelog since v1.2.2 is: 2012-05-27 1.2.7 Preliminary firmware 1.2.7 Bug fix for off-by-one-can-byte bug in roadster id from VIN Add homelink and charge timer support, plus misc fixes Only send non-empty params to PARAMS? sms command Remove need to RESET after can write change Only NETINIT (not SOFTRESET) after a parameter change Re-label parameters internally to match new user-friendly names Re-work of sms command handlers to be table driven - saving 6% of flash Use the 6% of flash we saved to implement a bunch of SMS commands REGISTER? Report on registered phone REGISTER <modulepass> Register caller phone PASS? Report on module password PASS <modulepass> Set new module password GPS?/GPS [<modulepass>] Report GPS location STAT?/STAT [<modulepass>] Report status PARAMS? [<modulepass>] Report on parameters PARAMS <param2> <param3> .. <paramN> Set parameters MODULE? [<modulepass>] Report on module parameters MODULE <vehicleid> <units> <notifies> Set module parameters GPRS? [<modulepass>] Report on GPRS parameters and status GPRS <gprsapn> <gprsuser> <gprspass> Set GPRS parameters SERVER? [<modulepass>] Report on server parameters SERVER <serverip> <serverpass> <paranoid> Set server parameters DIAG?/DIAG [<modulepass>] Technical diagnostics FEATURES? [<modulepass>] Report on features configured FEATURE <feature> <value> Set specified feature value HOMELINK <button> Activate homelink 0, 1 or 2 LOCK <pin> Lock car (with specified pin) UNLOCK <pin> Unlock car (with specified pin) VALET <pin> Activate valet mode (with specified pin) UNVALET <pin> Deactivate valet mode (with specified pin) CHARGEMODE <mode> <current> Set charge mode (sta, sto, ran, per) and current CHARGESTART [<modulepass>] Start charge immediately CHARGESTOP [<modulepass>] Stop charge immediately VERSION [<modulepass>] Report module firmware version RESET [<modulepass>] Reset module 2012-05-11 1.2.5 Preliminary firmware 1.2.5 LED re-work Support multiple vehicle configurations - TeslaRoadster and VoltAmpera NET driver tidy-ups Auto-support Tesla Roadster v1.5 cars Issue #38 - Prevent user from locking car if car is ON Issue #39 - Alert (SMS/PUSH) if trunk is opened while in valet mode I've managed to do this with very little impact to firmware size. Major user-visible extensions in this firmware include: A huge number of new SMS commands. Support for simplified setup steps (working on with Bennett). New status and error LED arrangement. New diagnostic SMS commands. Various minor bug-fixes and improvements. Homelink support (firmware both SMS and app protocol support - app support will follow). Charge timer support (firmware and app protocol support - app and sms support will follow). This is a major re-work of the SMS sub-system. We now have 27 commands and similar functionality to the GPRS smartphone apps. In particular, charge start/stop and mode setting is now available. I've also added in the homelink commands (courtesy of Fuzzylogic's CAN decoding skills). I've tested this on the bench, and it seems to work. I've also put it in my car 10 minutes ago, and got a network connection. That is pretty much the extent of my testing, so consider this pre-beta and definitely NOT for end-users. I haven't completely tested the setup of a module from scratch with these new REGISTER, PASS, MODULE, SERVER, GPRS commands - I hope Bennett, or someone else, will help with that. I haven't tested homelink support. I hope someone will try that (using SMS "HOMELINK 0" command) and let me know if it works. This is now pretty feature complete for the v1.3.0 firmware. I need to do the CHARGETIMER SMS commands, and want to re-work the social group messages to allow streaming of group location messages (if enabled). So, please test this as you can, and let me know any problems you find. Again, please don't put this on end-user cars yet. There has been a lot go into this and I need a week or so of inevitable bug fixing before it is ready for wider testing. There hasn't been much changes to the net subsystem since 1.2.5, and that seem stable, so I think it is fine to put in developer's cars. Regards, Mark.

3 5