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@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@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@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@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@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@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@gmail.com>
To: OVMS Developers <ovmsdev@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@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@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:


Regards, Mark.

On 16 Sep, 2013, at 4:55 PM, Håkon Markussen <hakon.markussen@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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev



_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev




_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev