[Ovmsdev] i-Miev/C-Zero/iOn
Matt Beard OVMS
smvo at mxf.org.uk
Sat Sep 21 20:21:02 HKT 2013
This seems to have worked - I am now getting SOC reported as 99% with 43
miles range predicted.
It looks like the range from the car is already in miles, so it is being
reduced by a factor of ~1.6 erroneously.
I will do a bit more testing, then report.
Matt
On 21 September 2013 10:32, Matt Beard OVMS <smvo at mxf.org.uk> wrote:
>
> 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/19157a1f/attachment.htm>
More information about the OvmsDev
mailing list