[Ovmsdev] Tips needed for reverse engineering CAN bus

[Mark Webb-Johnson]

Matt,

In general, 'commands' that are implementable in OVMS are those that either are (a) implemented in the car itself, or (b) implemented in an existing remote app / hardware. Maybe some examples will help:

The Tesla Roadster has no remote App. It does have a VDS (little touch-enabled screen) in the car itself. What we did is tap the CAN bus communications between the VDS and VMS to reverse engineer the commands. For instance, when you tap "Stop Charge" on the VDS, a CAN bus message is sent - we reverse engineered that, then tested it by injecting the message back into the car from a can-usb adapter, when that was shown to work we finally implemented it in the OVMS module firmware and enabled the function in the OVMS Apps. Working like that, we can pretty much implement remotely any command function available in the car (given enough time and energy to decode the can bus messages). We can even implement some functions that are regionally disabled in the VDS (like lock/unlock for non-USA cars), and extend what the car can do (for example, by more sophisticated charge control built on top of the basic start/stop/current-limit commands). One developer is working on a charge-time-predictor for the Tesla Roadster (which it doesn't have) that we will be able to build on to not only tell the owner how long the current charge is estimated to take, but also build more sophisticated charge control such as a complete-charge-by-time mode.

The Volt in USA is controlled by OnStar, with cellphone apps, and by a KeyFob. Volts/Amperas sold outside the USA don't have OnStar or any remote App. This is still a work-in-progress (just started), but what we are doing here is very similar to the Tesla Roadster. We're tapping the CAN bus communications while we issue remote commands (either from the Apps, via OnStar, or with the KeyFob) - and then looking for commands. We're hoping to provide OnStar style remote app functionality for the Volts/Amperas without OnStar.

The Renault Twizy has no remote app and no in-car control. When the car is switched off, the can bus goes quiet. The car quite simply has no ability to be controlled when it is switched off (to start/stop charge, etc). For this car, OVMS is used just for charge monitoring, location, etc. One developer is investigating extending OVMS by homelink/bluetooth/whatever to remotely control the wall socket to provide some capability for charge control (in particular for time-of-use metering). That said, the developers have gone much further than even the Twizy itself - displaying status of individual battery sheets for example.

I don't know much about the iMiev capabilities. Perhaps the above will help.

Regards, Mark.

On 25 Feb, 2013, at 9:34 PM, Matt Beard wrote:

> I am considering doing some work on an OVMS version for the
> iMiev/iOn/C-Zero, but am puzzled as to how the existing versions
> reverse engineered the CAN bus.
> 
> I have lots of info about reading the status from the CAN bus, and I
> think this would allow all available features, but I wouldn't know
> where to start on the write-side. How have the current versions
> reverse engineered the commands required for setting features? Without
> an ability to set features there is little gained over the existing
> support and so little point doing the work.
> 
> Matt Beard
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130226/e55b67b0/attachment.htm>