[Ovmsdev] i-Miev/C-Zero/iOn

[Thomas Bergo]

Hi,

So far the following CAN messages is discovered by Priusfan published on
myimiev forum:

SOC
RPM
Range
Battery current
Battery voltage
Speed
Odo
Battery cell voltage
Battery cell temperature

So we still have to find Car On/Off and the charging status.

Those messages are available as Mitsubishi has made a CAN Gateway where
those data is provided.
http://www.pref.nagasaki.jp/ev/ev&its/120614/navi/gateway_gaiyou.pdf


Regarding the two-character abbreviation I think Brand-Model (MI) as TR and
RT is most intuitive. So my vote goes to MI.

I'm interested in using the OVMS v1 HW for logging of CAN messages. How to
pay for postage?

Regards, Thomas


mandag 29. april 2013 skrev Mark Webb-Johnson følgende:

> Thomas,
>
> Earlier this year, Matt Beard mentioned he was interested in doing i-Miev
> support, but I'm not sure of his status. He is on this list, so should see
> this. There are also several OVMS users who have that car in their stable,
> so the requirement is definitely there.
>
> It is probably worth firstly doing a quick feasibility check, to see what
> level of OVMS support is possible:
>
> Firstly, What are the specs for the CAN bus? What baud rate is it, and
> what is the connector? There are  just three messages that are key to
> feasibility:
>
>
>    1. SOC - battery state of charge - *car_SOC*
>       2. Car On/Off (ignition switch, or Park/Drive gear lever) - *car_doors1
>       [bit7]*
>       3. Car Charging (true or false) - *car_doors1 [bit 4]*
>
>
> If those three are available, and readable by the OVMS hardware, then the
> project is most likely feasible. There are lots of other parameters (range,
> temperature, odometer, speed, vin, tpms, etc) that are nice to have, but
> are either optional (nice-to-have) or can generally be derived from these
> three key messages - so long as they can be found. For example, on the
> Volt/Ampera we don't know the detailed charge messages, but do know whether
> the car is charging or not - we can assume charge interrupted if the charge
> finishes before 95% complete. Similarly, if the range of the car is XXkm,
> we can estimate the current range based on XX * SOC%. If the car has no GPS
> details on the CAN bus, then we can use the GPS in the OVMS module itself.
>
>
> What vehicle two-character abbreviation do you think is suitable: IM or
> MI? Examples are RT (Renault Twizy), VA (Volt/Ampera), TR (Tesla Roadster).
>
> If you can let me have the can bus specs and information on the above 3
> messages, I will create you a stub vehicle implementation.
>
> Regards, Mark.
>
> P.S. With reference to the development guide (
> https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/docs/OVMS_Development.pdf),
> these are the current set of parameters that OVMS supports.
>
> Vehicle Module Development Checklists 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.
>
> *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****
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130429/f409e6ba/attachment.htm>