[Ovmsdev] i-Miev/C-Zero/iOn
Thomas Bergo
thomas.bergo at gmail.com
Thu Sep 19 15:01:30 HKT 2013
Yesterday I managed to verify that both poll0 and poll1 interrupt is called.
Printed "car_idealrange =id;" from poll0 to see the PID's that triggered
the interrupt. Only get id 768 (0x300) printed out.
Also tried to do a the printout fom inside case 0x374: but no updates. The
strange ting is that I can see a lot of "374" messages, and none "300" when
using my laptop.
Start wonder if the PID "374" that I find on my laptop is not a hex value?
Any one here that has any experiance with CAN-Do SW for analysing CAN
mesages?
Will do some more testing later.
Regards, Thomas
onsdag 18. september 2013 skrev Mark Webb-Johnson følgende:
>
> Is there a simple way to print out a value to the DIAG port for debugging?
>
>
> You can just net_puts it, normally prefixed with a "#" sign as a comment.
> Have a look in diag.c for lots of examples. You will need to type 'ATE1'
> when going into diag mode, to get the echo output. The way it works is that
> you send the command to the modem (net_puts()), which discards it as
> unrecognised, but echos it back to the terminal.
>
> But, you can't do that in interrupt handlers - only in normal ticker(), or
> message handler, style code
>
> Regards, Mark.
>
> On 18 Sep, 2013, at 8:22 PM, Thomas Bergo <thomas.bergo at gmail.com<javascript:_e({}, 'cvml', 'thomas.bergo at gmail.com');>>
> wrote:
>
> 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 <javascript:_e({},
> 'cvml', '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:
>>
>> OVMS Setup Diagnostics Mode <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<javascript:_e({}, 'cvml', '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 <javascript:_e({},
>> 'cvml', '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 <javascript:_e({},
>>> 'cvml', '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<javascript:_e({}, 'cvml', '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 <javascript:_e({}, 'cvml',
>>>> 'OvmsDev at lists.teslaclub.hk');>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk <javascript:_e({}, 'cvml',
>>>> 'OvmsDev at lists.teslaclub.hk');>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <javascript:_e({}, 'cvml',
>>> 'OvmsDev at lists.teslaclub.hk');>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <javascript:_e({}, 'cvml',
>> 'OvmsDev at lists.teslaclub.hk');>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <javascript:_e({}, 'cvml',
>> 'OvmsDev at lists.teslaclub.hk');>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk <javascript:_e({}, 'cvml',
> '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/20130919/43e9fe66/attachment.htm>
More information about the OvmsDev
mailing list