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

Wed Sep 18 20:22:54 HKT 2013

Thank you for your help.

Fixed some typos and now ODO updates in "STAT?" ODO is still wrong, but at
least i get updates. No luck with SOC so far.

Have verified that the PID and the data is correct by using a CAN interface
on my laptop.

Will do some more debugging to verify that both poll0 and poll1 is called.

Is there a simple way to print out a value to the DIAG port for debugging?

Regards, Thomas

2013/9/17 Mark Webb-Johnson <mark at webb-johnson.net>

>
> Thanks, Håkon - nice clear answer.
>
> One other suggestion is that you can put "car_idealrange++; return TRUE;"
> and "car_estrange++; return TRUE;" in the poll0 and poll1 functions, near
> the top. A few STAT commands and you can see if the poll functions are
> actually being called. You can also put "car_idealrange=id; return TRUE;",
> etc, to get an idea of what IDs are being delivered. It is very nasty
> trying to debug interrupt handlers, but this approach can help.
>
> The diag port mentioned is shown here:
>
> http://www.youtube.com/watch?v=-24PoWtHVzk
>
>
> Regards, Mark.
>
> On 16 Sep, 2013, at 4:55 PM, Håkon Markussen <hakon.markussen at gmail.com>
> wrote:
>
> Hi Thomas,
>
> *"Still has some debugging to do on the i-Miev code, as i'm only get
> "SOC: 0%" from STAT?"
> *
>
> Are you able to read any CAN-bus values from your iMiEV?
>
> I experienced once at my Think City, that the Ovms-module did not read the
> CAN-bus at all; I got 0% SOC.
> The problem was I had two external CAN-devices connected at the same time
> (Duinomite Mega + OVMS). It worked fine when both modules were powered on
> at the same time, but Ovms failed to read the bus when the Duinomite Mega
> was powered off.
>
> Du you have access to any kind of can-reader tool? This can be used to
> verify that you are looking at the correct bytes.
> I've used P-CAN USB adapter
> http://www.peak-system.com/PCAN-USB.199.0.html?&L=1
> and PCANView
> http://www.computer-solutions.co.uk/gendev/can-basic-dll.htm
>
> You can use it to verify you have SOC in msg 0x374 byte 1.
>
> To understand the mask and filter, you have to consider the mask as a bit
> "enable" / "disable". Any zero in the mask bit disables that specific bit.
> The filter gives a range of bit combinations.
> Both mask an filter is 11 bit length (0-10), all 8 bits from SIDH + 3 most
> significant bits from SIDL
>
> Your Mask0 (RXM0) is 11111111 000 (0x7F8) which enables bit 3 to 10
> Your Filter0 (RXF0) is 01100000 000
> In combination with your mask0, this gives the message range from 0x300 to
> 0x3F8, which covers your messages.
>  01100000 000 -> 0x300
>  011111111 000 -> 0x3F8
> (however you have an minor error in your comment 0x300 .. 0x3E0)
>
> The same goes for mask1 and filter2, filter3, filter4,which applies to
> poll1(). But you have to make sure that the mask1 enables sufficient number
> of bits for the corresponding filters.
> Your mask1 is 11111111 111 so that is OK.
> Your filter2 is  01010000 101 (0x285) which is OK
> Your filter 3 is 10000010 010 (0x412) which is OK
>
> You have yet not built any vehicle specific SMS function, so the STAT-sms
> is created in the net_msg.c file . I think it this file prints SOC to SMS
> regardless of the doorbit status.
>
> A hint is using the diag-port for sending SMS (saves you sms cost) for
> debuging).
>
> Br.
> Håkon
>
> 2013/9/15 Thomas Bergo <thomas.bergo at gmail.com>
>
>> 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
>>
>>
> _______________________________________________
> 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/20130918/ceed7b9c/attachment.htm>