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

Thu Sep 19 22:52:28 HKT 2013

I'm pretty sure. I got this calculation from Xavier, he made the first
version of the Canion app. A Android app to visualize data from the can-bus
on i-Miev, iOn and C-Zero.
https://play.google.com/store/apps/details?id=emobility.canion&hl=no

The calculation also seams to be correct when i logged the can bus during
charging yesterday, I had 14 bars and SOC was 85% with this calculation.

Regards, Thomas

2013/9/19 Håkon Markussen <hakon.markussen at gmail.com>

> @Thomas:
> Are you sure this calculation is correct for iMiEV?
> *car_SOC = (char)(((int)can_databuffer[1] - 10) / 2);
> *
>
> This means byte 1 can be:
> Ah (d10) = 0% SOC  (minimum)
> 6Eh (d110) = 50% SOC
> D2h (d210) = 100% SOC (maximum)
>
> Br.
> Håkon
>
>
> 2013/9/19 Thomas Bergo <thomas.bergo at gmail.com>
>
>> Thank you for your attention.
>>
>> This is the same information that i have:
>>
>> SOC shuld be 0x374, byte 1. This I have confirmed using my laptop and the
>> CAN-Do SW.
>>
>> I used the Think code as a template for setting up the filter and poll
>> interupts. So I belived that it shuld be a straight forward task to read
>> the messages.
>>
>> I will post my filter setup and poll1 code later,  I belive that you will
>> see what's wrong.
>>
>> Regards, Thomas
>>
>> torsdag 19. september 2013 skrev Nikolay Shishkov følgende:
>>
>>  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 <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
>>>
>>>
>> _______________________________________________
>> 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/7c33b9c6/attachment.htm>