[Ovmsdev] Help me get my first data item on the I3

[Steve Davies]

Hi,

Can I ask someone to help me get started with pulling data off the OBD-2 on
the I3.

I have info on what works via an LM327 and I know the pids, but it would
help me for some pointers as to how to do it on the OVMS.

You know - the goal to get the first one working.

Here's an example definition - the SOC of the main battery.  This is
extracted from decompiling a definition file for ediasbas/ediasblib:

(The "_EN" text is translated using Google cloud translate so the German is
the original)

The "job" is defined like so:

         {
            "SERVICE" : "22",
            "ID" : "0xDDBC",
            "DIV" : "-",
            "INFO" : "aktueller Anzeige Soc",
            "RES_TABELLE" : "RES_0xDDBC_D",
            "ARG_TABELLE" : "-",
            "EINHEIT" : "-",
            "DATENTYP" : "-",
            "ARG" : "ANZEIGE_SOC",
            "LABEL" : "-",
            "ADD" : "-",
            "MUL" : "-",
            "INFO_EN" : "current advertisement Soc",
            "L/H" : "-",
            "RESULTNAME" : "-",
            "NAME" : "-",
            "SG_ADR" : "-"
         },

The "results" are defined like so:

      "RES_0XDDBC_D" : [
         {
            "DIV" : "10.0",
            "INFO_EN" : "current advertisement Soc",
            "DATENTYP" : "unsigned int",
            "EINHEIT" : "%",
            "INFO" : "aktueller Anzeige Soc",
            "MASKE" : "-",
            "RESULTNAME" : "STAT_ANZEIGE_SOC_WERT",
            "L/H" : "high",
            "MUL" : "1.0",
            "ADD" : "0.0",
            "NAME" : "-"
         },
         {
            "NAME" : "-",
            "ADD" : "0.0",
            "MUL" : "1.0",
            "L/H" : "high",
            "RESULTNAME" : "STAT_MAXIMALE_ANZEIGE_SOC_WERT",
            "INFO" : "obere Grenze des Anzeige Soc",
            "MASKE" : "-",
            "INFO_EN" : "upper limit of the display Soc",
            "EINHEIT" : "%",
            "DATENTYP" : "unsigned int",
            "DIV" : "10.0"
         },
         {
            "RESULTNAME" : "STAT_MINIMALE_ANZEIGE_SOC_WERT",
            "L/H" : "high",
            "MUL" : "1.0",
            "NAME" : "-",
            "ADD" : "0.0",
            "DIV" : "10.0",
            "INFO_EN" : "lower limit of the display Soc",
            "EINHEIT" : "%",
            "DATENTYP" : "unsigned int",
            "INFO" : "untere Grenze des Anzeige Soc",
            "MASKE" : "-"
         }
      ],

I read it that three unsigned ints (16 bits each) are returned.
Each is divided by 10 to return a "%".


I traced an app that can retrieves this parameter using an LM327 based OBD2
interface.

That app initialises the LM327 like so:

2020-11-15 10:34:28.831 --> ATD Return all settings to default
2020-11-15 10:34:28.849 --> ATE0 Disable command echo
2020-11-15 10:34:28.861 --> ATH1 Show CAN message headers
2020-11-15 10:34:28.875 --> ATAL Allow long messages
2020-11-15 10:34:28.887 --> ATPBE101 Set programmable param 0x2c to 0xE1,
0x2d to 0x01
       - 2c=0xE1:
          - 11 bit IDs
          - variable data-length code
          - 11 or 29 bit received IDs
          - use data format ISO 15765-4 (CAN)
       - 2d=0x01
          - Use rate divisor of 1
2020-11-15 10:34:28.901 --> ATSPB Use protocol USER1 CAN (as set above I
think)
2020-11-15 10:34:28.949 --> ATBI Bypass initialisation - apparently a bad
idea... ?
2020-11-15 10:34:28.964 --> ATSH6F1 Set header bytes to 0x6F1 ( 0x06F1 ? )
2020-11-15 10:34:28.978 --> ATAT0 Disable adaptive timing - wait up to ATSF
time
2020-11-15 10:34:28.992 --> ATSTFF Maximum wait


Then, when it fetches this PID it does the following:

2020-11-15 10:34:35.101 --> ATCRA607⏎                       // Listen for
0x607
2020-11-15 10:34:35.114 <-- OK⏎⏎>
2020-11-15 10:34:35.115 --> ATCEA07⏎                        // "extended
address" 0x07 [matches 607?]
2020-11-15 10:34:35.127 <-- OK⏎⏎>
2020-11-15 10:34:35.129 --> ATFCSH6F1⏎                      // Flow control
header
2020-11-15 10:34:35.141 <-- OK⏎⏎>
2020-11-15 10:34:35.143 --> ATFCSD07300800⏎                 // Flow control
data
2020-11-15 10:34:35.156 <-- OK⏎⏎>
2020-11-15 10:34:35.157 --> ATFCSM1⏎                        // Flow control
mode
2020-11-15 10:34:35.170 <-- OK⏎⏎>

2020-11-15 10:34:36.367 --> 22␣DD␣BC⏎                       // asking for
"extended" PID 0xDDBC
2020-11-15 10:34:36.474 <-- 607␣F1␣03␣7F␣22␣78␣⏎            // this is some
unrelated packet?
2020-11-15 10:34:36.539 <-- 607␣F1␣10␣09␣62␣DD␣BC␣02␣4C␣⏎   // reply -->
0x24C = 588 = 58.8 SOC
     607␣F1␣21␣03␣A6␣00␣69␣FF␣FF␣⏎                          // 0x03A6 = =
93.4%, 0x0069 = 10.5%
2020-11-15 10:34:37.598 <-- ⏎>

Remember the LM327 takes the sent bytes and wraps with into a full CAN
message - though I'm not sure exactly how that comes out - I presume that
"extended address" goes in somewhere.

--> 22 DD BC is the PID
<-- 2 part reply.  First has the SOC.  Second has 0x03A6 (934) and 0x0069
(105)

First int is 588 or 58.8% which is the physical SOC of the battery.
934 is 93.4 which is the physical SOC level which the car displays as
"100%" (i3 keeps some headroom "reserved").
105 is 10.5 which is the physical SOC level that the car displays as 0%.

I'd appreciate some help to give me a head-start to be able to retrieve
this attribute on the OVMS box.

Thanks,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201212/fdd05966/attachment-0003.htm>