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

Mon Sep 16 06:06:54 HKT 2013

FYI - I have a C-Zero and OVMS with programmer and OBD logger.

I have done a bit of work, but am rather limited in time that I can spend
on this project, but am able to help out a bit from time to time.

I have been planning a small application to hunt through all the CAN
traffic for candidate data, but this is way behind!

Matt Beard

On 15 September 2013 22:02, Thomas Bergo <thomas.bergo at gmail.com> wrote:

> Finally got some time to work on the i-Miev implementation.
>
> But I'm facing some issues setting up the car module.
> - SMS is working and are able to send messages to the car module and get
> answers.
> - Problem getting the GPRS to work. Get "Not connected" and "Not connected
> (0x0041) when sending GPRS?
> - No connection from the iOS app to server. Only red flashing antenna.
>
> Any advise?
>
>
> Still has some debugging to do on the i-Miev code, as i'm only get "SOC:
> 0%" from STAT?
>
> Regards, Thomas
>
>
> 2013/5/1 Mark Webb-Johnson <mark at webb-johnson.net>
>
>>
>> I've created a stub file (vehicle_mitsubishi.c), and pushed to github. If
>> you pull head you'll get it. This is just a stub. You'll need to setup the
>> CAN IDs you want to receive (in the filters), and then add the decoding
>> logic to update the car_* variables.
>>
>> Regards, Mark.
>>
>> Regards, Mark.
>>
>> On 30 Apr, 2013, at 5:29 AM, Thomas Bergo <thomas.bergo at gmail.com> wrote:
>>
>> 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****
>>>
>>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>
> _______________________________________________
> 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/20130915/92444cc4/attachment.htm>