[Ovmsdev] i-Miev/C-Zero/iOn
Nikolay Shishkov
nshishkov at yahoo.com
Thu Sep 19 18:25:31 HKT 2013
Hi Thomas,
Here is some info on the messages that you can see on the Miev CAN bus.
0x210 - accelerator pedal
0x298 - trip meter
0x346 - range
0x373 - amps, volts
0x374 - SOC
0x389 - Amp, Volts
0x412 - speed, odometer
0x418 - shifter position
0x424 - switches and stuff - like lights, etc.
0x6E1, 0x6E2, 0x6E3, 0x6E4 - cell voltages, and temps
Once you get familiar with the ovms, maybe you can find it easier to use the Twizy or the Think code, instead of starting from scratch.
Hope this helps,
Nikolay
________________________________
From: Thomas Bergo <thomas.bergo at gmail.com>
To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
Sent: Thursday, September 19, 2013 9:01 AM
Subject: Re: [Ovmsdev] i-Miev/C-Zero/iOn
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> 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>
>>
>>
>>>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
>>>
>>>
>>>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
>>>
>>>
>>
_______________________________________________
>>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/20130919/6b841b74/attachment.htm>
More information about the OvmsDev
mailing list