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

Matt Beard OVMS smvo at mxf.org.uk
Sat Sep 21 17:32:25 HKT 2013


My understanding of the way the CAN filtering works is that the mask is not
correct in the above code.

vehicle_mitsubishi_poll0() is attempting to accept messages with SIDs
0x346, 0x373, 0x374, 0x389, but the filter SID is set to 0x300 with mask
0x7f8 meaning that only messages with SIDs 0x30n where n is 8-f would be
received.

To receive all 0x3nn messages we could use filter SID 0x300 and mask 0x700,
but I am worried that may cause a flood of messages.

I will see if I can try the following:

// Buffer 0 (filters 0, 1) for extended PID responses
  RXB0CON = 0b00000000;
  // Mask0 = 0b11100000000 (0x700), filterbit 0,1,2 deactivated
  RXM0SIDL = 0b00000000;
  RXM0SIDH = 0b11100000;

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

I may also try modifying the RX0 mask during the 1-second poll so that it
cycles through filtering a single SID each time, meaning that it will take
4 seconds for a full update. I don't think this will be an issue as none of
this data is fast changing.

Matt Beard



On 19 September 2013 16:10, Thomas Bergo <thomas.bergo at gmail.com> wrote:

> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/20130921/4aac5863/attachment-0001.html>


More information about the OvmsDev mailing list