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

Thu Sep 19 21:57:06 HKT 2013

@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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20130919/7c1bf935/attachment-0001.html>