- OvmsDev - Open Vehicles

Vehicle Support Checklist
by Mark Webb-Johnson 29 Jan '13

29 Jan '13

I've updated the development document with some vehicle module development checklists. You can use these checklists to know what vehicle parameters the OVMS system supports, and how you can map a specific vehicle to these. The Tesla Roadster supports 100% of these (obviously). It would be good to use these ongoing for other vehicles, both as a target list to get to 100% support, and as a worksheet for both CAN bus information and progress. I hope you find them useful. Regards, Mark. Parameter Purpose Vehicle Support Notes Vehicle Identification car_type Vehicle type identified car_vin Vehicle VIN Parameter Purpose Vehicle Support Notes GPS Status Vehicle GPS Does the vehicle have a built-in GPS? If so, complete the following. car_gpslock Set to record GPS lock car_stale_gps Denotes GPS data staleness car_latitude Latitude of the vehicle car_longitude Longitude of the vehicle car_direction Direction of the vehicle car_altitude Altitude of the vehicle Parameter Purpose Vehicle Support Notes Tire Pressure Monitoring System TPMS Does the vehicle have a TPMS? If so, complete the following. car_stale_tpms Denotes TPMS data staleness car_tpms_t The temperatures of each wheel car_tpms_p The pressures of each wheel Parameter Purpose Vehicle Support Notes Driving Status car_doors1 [bit7] Set if the car ignition is ON car_speed The speed of the vehicle car_trip The vehicle trip counter car_odometer The vehicle odometer Parameter Purpose Vehicle Support Notes Vehicle Environment car_stale_ambient Ambient temperature staleness car_ambient_temp Ambient temperature car_stale_temps Other Temperature staleness car_tpem Temperature of the PEM car_tmotor Temperature of the MOTOR car_tbattery Temperature of the BATTERY car_doors1 [bit 0] Set if front left door OPEN car_doors1 [bit 1] Set if front right door OPEN car_doors2 [bit 6] Set if bonnet is OPEN car_doors2 [bit 7] Set if trunk is OPEN car_doors1 [bit 2] Set if charge port is OPEN car_doors1 [bit 6] Set if handbrake is ON car_doors2 [bit 5] Set if headlights ON car_doors3 [bit 1] Set if vehicle is AWAKE (or if not supported just follow ignition) car_doors2 [bit 4] Set if valet mode is ENABLED car_doors2 [bit 3] Set if vehicle is LOCKED car_lockstate 4=locked, 5=unlocked (deprecated) car_doors4 [bit 2] Set if alarm SOUNDING car_time Time (in seconds) car_parktime Time (seconds) vehicle parked Parameter Purpose Vehicle Support Notes Battery Status car_SOC State of charge percentage car_idealrange Ideal range car_estrange Estimated range Parameter Purpose Vehicle Support Notes Charging Status car_doors1 [bit 3] Set if pilot signal ON car_doors1 [bit 4] Set if vehicle CHARGING car_linevoltage Line voltage while charging car_chargecurrent Line current while charging car_chargemode Vehicle Mode car_chargestate Charging state car_chargesubstate Charging sub-state car_chargelimit Charge current limit car_chargeduration Charge duration (minutes) car_chargekwh Charge kWh put into battery car_stale_timer Charge timer staleness car_timermode Charge timer mode car_timerstart Charge timer schedule

1 0

[OVMSDEV] Compiler Probs
by Michael Jochum 23 Jan '13

23 Jan '13

Hi, a few people gere from the Ampera Forum have trouble with the precompiled hex in the git. It don't work. I send them the version i compiled and this works perfect. Whats wrong there? Bye Michael

1 0

Merging in Twizy and Volt/Ampera work
by Mark Webb-Johnson 20 Jan '13

20 Jan '13

A while ago, Michael Balzer suggested to me that it would be best to have one firmware supporting all cars. I agreed, but at the time, flash space was tight in the v1 hardware and I was concerned we would run out of flash. So, we implemented two separate builds. Now that the v2 hardware is out, I think that is much less of an issue than it was, as the v2 hardware has 50% more flash (taking away the baseline code, that at least triples the amount of free flash we have) - there should be plenty of space to support the cars that need it for the forceable future. In the coming few months, as the Volt/Ampera and Renault Twizy code becomes usable and usable by end-users (rather than developers), it would be much easier to be providing modules pre-flashed with a single version of firmware supporting all the cars. As the work on Twizy and Volt/Ampera is now progressing so fast, I think it best to make the change now rather than later. What I suggest is: We leave the current car modules basically as they are: can_teslaroadster, can_voltampera, and can_twizy. We leave the v1 firmware build basically as it is - just using can_teslaroadster. All the v2 hardware users are Tesla Roadster users. We move the 'shared' interrupt code (can_int_service, high_isr) out of the car_* modules into a can_canbus module. We create a mechanism for car_* modules to register themselves at startup. We create an eeprom parameter to define the vehicle type, and a switch at startup to hook the module supporting the currently defined car. It might be interesting in future to create a car_autodetect module to auto-detect the vehicle type from can bus traffic, but for the moment I think a manual parameter is acceptable. The existing V2_T2, V2_VA and V2_RT build configurations would disappear and be replaced with a single V2 firmware that would include all three car_* modules. I'm not sure of the exact mechanism for [4] and [5], but it should not be too hard to do. I really want to avoid having a single list of the cars anywhere. I'd much rather just have the existence of code in the can_* modules cause the code to be included. Does this sound sensible to everyone? Any better suggestions, or comments? Regards, Mark.

5 47

Freemont, CA firmware upgrade support
by Mark Webb-Johnson 19 Jan '13

19 Jan '13

Any OVMS techies, with pickit 2 and experience upgrading firmware, willing to help out with a module firmware upgrade in Freemont, CA, area?

1 0

Plug In America Research Launches Second Landmark Battery Performance Survey: Tesla Roadster
by Mark Webb-Johnson 18 Jan '13

18 Jan '13

Attn: Tesla Roadster Owners News story: http://www.pluginamerica.org/drivers-seat/plug-america-research-launches-se… This week, Plug In America launched a survey of Tesla Roadster owners. Although absent reports of issues with battery capacity loss, the Tesla Roadster user base has significant experience with electric vehicles that have been on the road since as far back as 2008. With the Roadster survey, Plug In America plans to explore several topics: How does the Roadster battery pack hold up over time and miles? How does this compare to owner expectations as set by Tesla Motors? How well does the Roadster's active thermal management protect the battery pack against hot and cold weather? How do version 1.5, 2.0 and 2.5 Roadsters compare in battery longevity and major maintenance? Is there a difference in drivetrain maintenance between the Roadster and Roadster Sport? How common are major Roadster drivetrain component replacements? What should owners know when considering purchasing an extended warranty? You can participate by completing the form at this link: http://www.pluginamerica.org/surveys/batteries/tesla-roadster/survey.php Regards, Mark

1 0

v2.2.2
by Mark Webb-Johnson 17 Jan '13

17 Jan '13

I've released firmware v2.2.2 to the github repository. The change log is as follows: 2013-01-11 2.2.2 Firmware 2.2.2 #94 v2 firmware re-work for multiple vehicle support #95 Valet Mode - Tesla Roadster - Trunk open is working off bonnet #96 Server: Support for historical data messages #97 CAN overflow (lockups) #99 Update vehicle/Car Module/VoltAmpera/voltampera_canbusnotes.txt #72 #72 Add GPS support for cars without it ### v2.x firmware, first release Internal GPS integration Basic support for Renault Twizy Volt/Ampera work-in-progress Framework sprintf rework First draft of OVMS Development document Twizy user guide v1.0.1 The .hex files have been built for all configurations. I (and others) have tested this in hardware v2 vehicles, but so far this is pretty much untested with v1 hardware (in particular for Tesla Roadster). I would appreciate it if you guys could test it and make sure it is ok for v1 hardware in Roadsters. Once you upgrade firmware to v2, you will need to either (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set feature #14 to "TR". You will require this for the CAN bus stuff to work. I have updated the Tesla Roadster user guide to reflect this new parameter. Regards, Mark.

4 15

Privacy Policy
by Mark Webb-Johnson 16 Jan '13

16 Jan '13

Call for help: Privacy Policy We've now grown to a size where I feel we need a privacy policy for Open Vehicles. In particular because of the sensitive information (such as location) that flows through the server. Is there anyone out there who can volunteer to assist with this? I can draft the bullet point requirements, but need someone to take one of the Creative Commons policies, and adapt it for OVMS. Thanks, Mark

1 0

OVMS Developers Document
by Mark Webb-Johnson 11 Jan '13

11 Jan '13

I've put together a first-draft of the OVMS developers document. Something to document, at a high-level, the OVMS code, to make it easier to extend and use it (in particular for those writing vehicle modules). You can find it on github, in the docs directory. The PDF is here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/O… The DOCX document is here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/O… Note that the code development hints and tools section comes from Michael B's Firmware-Development.odt document in the same directory. Thanks, Michael. The vehicle side of this document is mostly complete. What is missing are some conclusions, and the server and apps parts. But, it is good enough to be used for vehicle side today. I will keep working on it. If you see anything wrong, or think some parts of need expanding / removing, please let me know. Regards, Mark. P.S. Like other OVMS documents, it is in DOCX and PDF format. Not because I like it, but because I've given up ;-) It pains me every time I start Microsoft Word on my Mac. Some day, the world will be rid of Microsoft Office, just not today.

2 1

RFC: Battery status MSG protocol
by Michael Balzer 07 Jan '13

07 Jan '13

Hi Mark, this is my first draft of a battery data protocol as implemented in the Twizy module 2.0 (see vehicle_twizy_battstatus_msgp()). For each battery pack (min 1), a message of type "B" transports the current state and collected min/max values: // Output pack status: // MP-0 B,<packnr>,<nr_of_cells> // ,<volt_alertstatus>,<temp_alertstatus> // ,<soc>,<soc_min>,<soc_max> // ,<volt_act>,<volt_act_cellnom> // ,<volt_min>,<volt_min_cellnom> // ,<volt_max>,<volt_max_cellnom> // ,<temp_act>,<temp_min>,<temp_max> The units now are 1/100 % for the SOCs, 1/100 V for the voltages and 1 °C for the temperatures. Maybe floats are more readable / standard for SOC & V? Alert status are enums of... 0 = unknown 1 = nominal 2 = suspicious 3 = alert 4 = fail For each cell in each pack, a message of type "H" transports the cell details accordingly: // Output cell status: // MP-0 H,<packnr>,<cellnr> // ,<volt_alertstatus>,<temp_alertstatus>, // ,<volt_act>,<volt_min>,<volt_max>,<volt_maxdev> // ,<temp_act>,<temp_min>,<temp_max>,<temp_maxdev> Numbering of packs and cells begins at "1" to reserve "0" for an "all" selector. Alert status uses the same enum scheme as on the pack level. Voltages on the cell level are in unit mV, temperatures in °C. The maximum deviations are signed to reflect the direction of the deviation. Of course, a cell need not be a physical cell, it's just the smallest monitorable unit in a pack. Monitoring huge packs will not be possible with the current OVMS hardware, unless we consider streaming all sensor data to the server. I thought about how much could be stored in the server now and had a first look at the current server implementation. The primary key of table "ovms_carmessages" would need to be changed, as it currently is bound to just the message type character (and also case insensitive, reducing the number of possible message types). The key would need to be extended by the packnr on "B" messages and the pack + cellnr on "H" messages. So, generally speaking, we could introduce 2-3 key extension columns that can be used dynamically based on the message type. That would also enable storing of other historical records. To keep the database clean, an expire mechanism could drop all rows older than e.g. 24 hours. Please comment. Regards, Michael -- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

3 49

OVMS OBDII Cables now available
by Mark Webb-Johnson 04 Jan '13

04 Jan '13

We received the cables yesterday, and they look good. The factory seems to have done a good job. I tested 5 - all ok - and even put one in my wife's Nissan to power up an OVMS module. Now, if only her car had a can bus :-( OVMS vehicle cables for connection to can-bus equipped OBDII vehicles are now available from our FastTech logistics partner. You can find them here: OVMS OBDII Cable @FastTech This cable connects the OVMS module to the vehicle CAN bus, via the industry standard OBDII socket. It is 1 metre in length, and uses a right-angle OBDII plug (J1962-M) to help with cable management and routing. The cable is intended to be used in Renault Twizy, Chevy Volt, Opel/Vauxhall Ampera, and other cars using OBDII connectors. OVMS OBDII Cable Pinout J1962-M DB9-F Signal 4 3 Chassis/Power GND 6 7 CAN-H 14 2 CAN-L 16 9 +12V Vehicle Power

3 5