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

Thomas Bergo thomas.bergo at gmail.com
Thu Sep 19 23:10:25 HKT 2013


Here is the code I'm trying for reading the SOC,

*Filter:*

// Filters: low byte bits 7..5 are the low 3 bits of the filter, and bits
4..0 are all zeros
  //          high byte bits 7..0 are the high 8 bits of the filter
  //          So total is 11 bits

  // Buffer 0 (filters 0, 1) for extended PID responses
  RXB0CON = 0b00000000;
  // Mask0 = 0b11111111000 (0x7F8), filterbit 0,1,2 deactivated
  RXM0SIDL = 0b00000000;
  RXM0SIDH = 0b11111111;

  // Filter0 0b01100000000 (0x300..0x3F8)
  RXF0SIDL = 0b00000000;
  RXF0SIDH = 0b01100000;


*Can_poll*:

////////////////////////////////////////////////////////////////////////
// can_poll()
// This function is an entry point from the main() program loop, and
// gives the CAN framework an opportunity to poll for data.
//
BOOL vehicle_mitsubishi_poll0(void)
  {
  unsigned int id = ((unsigned int)RXB0SIDL >>5)
                  + ((unsigned int)RXB0SIDH <<3);

  can_datalength = RXB0DLC & 0x0F; // number of received bytes
  can_databuffer[0] = RXB0D0;
  can_databuffer[1] = RXB0D1;
  can_databuffer[2] = RXB0D2;
  can_databuffer[3] = RXB0D3;
  can_databuffer[4] = RXB0D4;
  can_databuffer[5] = RXB0D5;
  can_databuffer[6] = RXB0D6;
  can_databuffer[7] = RXB0D7;

  RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag

  car_estrange = id; //debug

  switch (id)
    {
    /*
    case 0x346:
      car_estrange = MiFromKm((unsigned int)can_databuffer[7]); // Range
      car_idealrange = car_estrange;
    break;

    case 0x373:
      // BatCurr & BatVolt
    break;
    */

    case 0x374:
      car_idealrange = id; //debug
      car_SOC = (char)(((int)can_databuffer[1] - 10) / 2); //SOC
    break;

    case 0x389:
      car_linevoltage = (unsigned int)can_databuffer[1];
      car_chargecurrent = ((unsigned int)can_databuffer[6] / 10);
    break;
    }

  return TRUE;
  }


I using car_estrange and car_idealrange for debug. car_estrange gets
updates, but car_idealrange is never updated and are always 0.
Have also tried car_estrange++; in the code, and I can see that the number
increases for each DIAG message.


Regards, Thomas



2013/9/19 Thomas Bergo <thomas.bergo at gmail.com>

> 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/9ec718e1/attachment.htm>


More information about the OvmsDev mailing list