[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.openvehicles.com/pipermail/ovmsdev/attachments/20130921/4aac5863/attachment.htm>
More information about the OvmsDev
mailing list