[Ovmsdev] i-Miev/C-Zero/iOn
Matt Beard OVMS
smvo at mxf.org.uk
Sun Sep 22 00:43:17 HKT 2013
OK,
The iMiev/iOn/C-Zero code currently works with the attached source file.
The charge state and SOC work, as do the charge voltage and current it
seems. Estimated range works, and I made the "ideal range" assume that 100%
would ideally get you 80miles.
I added battery temperature, based on the average of 24 of the 64 available
temperature values, and this seems to work. I also tried to set tPEM to min
cell temperature and tMotor to max cell temperature, but seem to have done
something wrong!
I have run out of time, so feel free to look at what I have done and fiddle!
Matt
P.S. I don't know how to tell if odo and speed are correct, but I changed
them as I am pretty certain that the values on the CAN bus are in miles and
mph when the car is set to miles.
P.P.S. We need some iMiev pictures in the app now!
On 21 September 2013 13:21, Matt Beard OVMS <smvo at mxf.org.uk> wrote:
> 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/c4bf2f61/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C-Zero_Charging.PNG
Type: image/png
Size: 171799 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130921/c4bf2f61/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vehicle_mitsubishi.c
Type: text/x-csrc
Size: 9245 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130921/c4bf2f61/attachment-0002.bin>
More information about the OvmsDev
mailing list