January 2013 - OvmsDev - Open Vehicles

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