Help me get my first data item on the I3
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
Steve, use the vehicle_obdii module to get into OBD polling on the OVMS. You begin by defining the poll requests to be sent in at least one array of type OvmsVehicle::poll_pid_t. A request consists of * the transmission address (CAN ID), this may be a specific address or the broadcast address 0x7df * the expected response address (CAN ID), or 0 in case of a broadcast * the type of the request; OBD also calls this "mode", e.g. 0x22, there are preprocessor definitions for all supported types, e.g. 0x22 = VEHICLE_POLL_TYPE_OBDIIEXTENDED * optionally the PID to access (depending on the request type, may be none / 8 bit / 16 bit) * the poll interval; this may be specified for up to 4 vehicle states (normally used to switch intervals according to the car's operation mode, like sleeping / driving / charging) * optionally the CAN bus to use for the request For your example of polling the SOC, this would be: * transmission address:0x6F1 * response address: 0x607 * type: 0x22 or VEHICLE_POLL_TYPE_OBDIIEXTENDED * PID: 0xDDBC * poll interval: as you like, e.g. { 0, 10, 60 } -- assuming for sleeping, driving, charging End the array with an all zero entry. The poller will automatically loop over the list. Call OvmsVehicle::PollSetPidList() to set the array to be used, call OvmsVehicle::PollSetState() to set the vehicle state (defining the poll intervals). Override OvmsVehicle::IncomingPollReply() with your result processing. The method will be called by the framework for each response part. The framework also supplies polling state variables you can use (see vehicle.h). A typical pattern to collect multiple frames is: void OvmsVehicleRenaultTwizy::IncomingPollReply( canbus* bus, uint16_t type, uint16_t pid, uint8_t* data, uint8_t length, uint16_t mlremain) { string& rxbuf = twizy_obd_rxbuf; // init / fill rx buffer: if (m_poll_ml_frame == 0) { rxbuf.clear(); rxbuf.reserve(length + mlremain); } rxbuf.append((char*)data, length); if (mlremain) return; // complete: switch (pid) { … This pattern collects the payload in a string buffer, regardless of the length. Decoding and converting the payload to metrics is up to you, but normally is simple. For your example: … // complete: switch (pid) { case 0xDDBC: { unsigned int soc_raw = ((unsigned int)rxbuf[0] << 8) | (unsigned int)rxbuf[1]; float soc = soc_raw / 10.0f; StdMetrics.ms_v_bat_soc->SetValue(soc); break; } On your question:
2020-11-15 10:34:36.474 <-- 607␣F1␣03␣7F␣22␣78␣⏎ // this is some unrelated packet?
Actually it's related, it's the first reply of the device and means "I'm busy, but stand by, results will come soon". The poller handles these. If you want to follow the poller operation, activate debug logging for the vehicle module: log level debug vehicle There's more on the poller, but that should get you going. Regards, Michael Am 12.12.20 um 10:19 schrieb 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, So I've written something to poll the SOC%. At this stage I'm trying to debug. I'm running my code - I configured for my BMWI3 module and my car. I set log level debug v-bmwi3, log level verbose canlog, and log level canopen. I can see that can1 is running - I'm sending some packets (I had it poll once per 60 seconds and indeed I'm sending one packet per minute). can can1 status says: OVMS# can can1 status CAN: can1 Mode: Active Speed: 500000 DBC: none Interrupts: 5557 Rx pkt: 5548 Rx err: 0 Rx ovrflw: 0 Tx pkt: 9 Tx delays: 0 Tx err: 0 Tx ovrflw: 0 Wdg Resets: 0 Err Resets: 0 Wdg Timer: 0 sec(s) Err flags: 0x00000000 I put "ESP_LOGD(TAG, "BMWI3: got SOC=%3.1f%%", soc);" in my code after parsing the SOC. But I'm not seeing that log message in the console. Can I enable a trace of CAN1 (without drowning my box!). Can I see what gets transmitted? Thanks, Steve On Sat, 12 Dec 2020 at 13:49, Michael Balzer <dexter@expeedo.de> wrote:
Steve,
use the vehicle_obdii module to get into OBD polling on the OVMS.
You begin by defining the poll requests to be sent in at least one array of type OvmsVehicle::poll_pid_t. A request consists of
- the transmission address (CAN ID), this may be a specific address or the broadcast address 0x7df - the expected response address (CAN ID), or 0 in case of a broadcast - the type of the request; OBD also calls this "mode", e.g. 0x22, there are preprocessor definitions for all supported types, e.g. 0x22 = VEHICLE_POLL_TYPE_OBDIIEXTENDED - optionally the PID to access (depending on the request type, may be none / 8 bit / 16 bit) - the poll interval; this may be specified for up to 4 vehicle states (normally used to switch intervals according to the car's operation mode, like sleeping / driving / charging) - optionally the CAN bus to use for the request
For your example of polling the SOC, this would be:
- transmission address: 0x6F1 - response address: 0x607 - type: 0x22 or VEHICLE_POLL_TYPE_OBDIIEXTENDED - PID: 0xDDBC - poll interval: as you like, e.g. { 0, 10, 60 } -- assuming for sleeping, driving, charging
End the array with an all zero entry. The poller will automatically loop over the list.
Call OvmsVehicle::PollSetPidList() to set the array to be used, call OvmsVehicle::PollSetState() to set the vehicle state (defining the poll intervals).
Override OvmsVehicle::IncomingPollReply() with your result processing. The method will be called by the framework for each response part. The framework also supplies polling state variables you can use (see vehicle.h). A typical pattern to collect multiple frames is:
void OvmsVehicleRenaultTwizy::IncomingPollReply( canbus* bus, uint16_t type, uint16_t pid, uint8_t* data, uint8_t length, uint16_t mlremain) { string& rxbuf = twizy_obd_rxbuf;
// init / fill rx buffer: if (m_poll_ml_frame == 0) { rxbuf.clear(); rxbuf.reserve(length + mlremain); } rxbuf.append((char*)data, length); if (mlremain) return;
// complete: switch (pid) { …
This pattern collects the payload in a string buffer, regardless of the length.
Decoding and converting the payload to metrics is up to you, but normally is simple.
For your example:
… // complete: switch (pid) { case 0xDDBC: { unsigned int soc_raw = ((unsigned int)rxbuf[0] << 8) | (unsigned int)rxbuf[1]; float soc = soc_raw / 10.0f; StdMetrics.ms_v_bat_soc->SetValue(soc); break; }
On your question:
2020-11-15 10:34:36.474 <-- 607␣F1␣03␣7F␣22␣78␣⏎ // this is some unrelated packet?
Actually it's related, it's the first reply of the device and means "I'm busy, but stand by, results will come soon". The poller handles these.
If you want to follow the poller operation, activate debug logging for the vehicle module: log level debug vehicle
There's more on the poller, but that should get you going.
Regards, Michael
Am 12.12.20 um 10:19 schrieb 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
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Steve, with log level verbose for canlog, you can simply activate CAN logging via: can log start monitor crtd …that will log all frames, if that's too much, add a filter like this: can log start monitor crtd 600-7ff Use can log stop to …well, you'll guess it ;-) And as I said, to get the log messages of the vehicle poller, set log level debug on "vehicle". Btw: in case you missed it, have a look at Config→Logging for persistent levels & file logging. Regards, Michael Am 12.12.20 um 16:12 schrieb Steve Davies:
Hi Michael,
So I've written something to poll the SOC%.
At this stage I'm trying to debug. I'm running my code - I configured for my BMWI3 module and my car.
I set log level debug v-bmwi3, log level verbose canlog, and log level canopen.
I can see that can1 is running - I'm sending some packets (I had it poll once per 60 seconds and indeed I'm sending one packet per minute).
can can1 status says:
OVMS# can can1 status CAN: can1 Mode: Active Speed: 500000 DBC: none Interrupts: 5557 Rx pkt: 5548 Rx err: 0 Rx ovrflw: 0 Tx pkt: 9 Tx delays: 0 Tx err: 0 Tx ovrflw: 0 Wdg Resets: 0 Err Resets: 0 Wdg Timer: 0 sec(s) Err flags: 0x00000000
I put "ESP_LOGD(TAG, "BMWI3: got SOC=%3.1f%%", soc);" in my code after parsing the SOC.
But I'm not seeing that log message in the console.
Can I enable a trace of CAN1 (without drowning my box!). Can I see what gets transmitted?
Thanks, Steve
On Sat, 12 Dec 2020 at 13:49, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Steve,
use the vehicle_obdii module to get into OBD polling on the OVMS.
You begin by defining the poll requests to be sent in at least one array of type OvmsVehicle::poll_pid_t. A request consists of
* the transmission address (CAN ID), this may be a specific address or the broadcast address 0x7df * the expected response address (CAN ID), or 0 in case of a broadcast * the type of the request; OBD also calls this "mode", e.g. 0x22, there are preprocessor definitions for all supported types, e.g. 0x22 = VEHICLE_POLL_TYPE_OBDIIEXTENDED * optionally the PID to access (depending on the request type, may be none / 8 bit / 16 bit) * the poll interval; this may be specified for up to 4 vehicle states (normally used to switch intervals according to the car's operation mode, like sleeping / driving / charging) * optionally the CAN bus to use for the request
For your example of polling the SOC, this would be:
* transmission address:0x6F1 * response address: 0x607 * type: 0x22 or VEHICLE_POLL_TYPE_OBDIIEXTENDED * PID: 0xDDBC * poll interval: as you like, e.g. { 0, 10, 60 } -- assuming for sleeping, driving, charging
End the array with an all zero entry. The poller will automatically loop over the list.
Call OvmsVehicle::PollSetPidList() to set the array to be used, call OvmsVehicle::PollSetState() to set the vehicle state (defining the poll intervals).
Override OvmsVehicle::IncomingPollReply() with your result processing. The method will be called by the framework for each response part. The framework also supplies polling state variables you can use (see vehicle.h). A typical pattern to collect multiple frames is:
void OvmsVehicleRenaultTwizy::IncomingPollReply( canbus* bus, uint16_t type, uint16_t pid, uint8_t* data, uint8_t length, uint16_t mlremain) { string& rxbuf = twizy_obd_rxbuf;
// init / fill rx buffer: if (m_poll_ml_frame == 0) { rxbuf.clear(); rxbuf.reserve(length + mlremain); } rxbuf.append((char*)data, length); if (mlremain) return;
// complete: switch (pid) { …
This pattern collects the payload in a string buffer, regardless of the length.
Decoding and converting the payload to metrics is up to you, but normally is simple.
For your example:
… // complete: switch (pid) { case 0xDDBC: { unsigned int soc_raw = ((unsigned int)rxbuf[0] << 8) | (unsigned int)rxbuf[1]; float soc = soc_raw / 10.0f; StdMetrics.ms_v_bat_soc->SetValue(soc); break; }
On your question:
2020-11-15 10:34:36.474 <-- 607␣F1␣03␣7F␣22␣78␣⏎ // this is some unrelated packet?
Actually it's related, it's the first reply of the device and means "I'm busy, but stand by, results will come soon". The poller handles these.
If you want to follow the poller operation, activate debug logging for the vehicle module: log level debug vehicle
There's more on the poller, but that should get you going.
Regards, Michael
Am 12.12.20 um 10:19 schrieb 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On Sat, 12 Dec 2020 at 17:28, Michael Balzer <dexter@expeedo.de> wrote:
with log level verbose for canlog, you can simply activate CAN logging via:
can log start monitor crtd
…that will log all frames, if that's too much, add a filter like this:
can log start monitor crtd 600-7ff
To see what was happening I had to "log level verbose canlog-monitor" I see this being transmitted: V (62436161) canlog-monitor: 1607847148.142477 1T11 6F1 03 22 dd bc 00 00 00 00 There is no reply. The other app I looked at does this on the LM327 as setup before sending the request: 2020-11-15 10:34:35.115 --> ATCEA07⏎ "extended address" 0x07 2020-11-15 10:34:35.127 <-- OK⏎⏎> Looking at the LM327 data sheet this configures an "extended address" which is sent after the 0x6F1 I'm not sure if that 0x03 in what OVMS is sending is that byte, and I need to somehow replace it wih 07, or if I have to get another inserted? Perhaps this is old hat to those more experienced than me.
From the data sheet and the trace it seems I'm also responsible to customise the flow control messages :-
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⏎⏎> I think that comes down to a flow control being "06 F1 07 30 08 00" Here's the page in the LM327 to help understand what it does: [image: image.png]
On Sun, 13 Dec 2020 at 10:58, Steve Davies <steve@telviva.co.za> wrote:
V (62436161) canlog-monitor: 1607847148.142477 1T11 6F1 03 22 dd bc 00 00 00 00
So reading the LM327 discussion of CAN extended addresses, I'm pretty sure this needs to go out as "6F1 07 03 22 DD BC 00 00 00" The "07" in inserted by the use of ATCEA07. The flow control has a similar added byte. Correct me if I'm wrong, but it doesn't look like the CAN component knows how to do this at the moment? Steve
Steve, sorry, totally missed that. That's very unusual, haven't seen that before. I first thought maybe that's using CAN extended frame mode, but that's a totally different thing: it seems the i3 uses the *ISO-TP extended addressing scheme*. Quoting from Wikipedia: https://en.wikipedia.org/wiki/ISO_15765-2
ISO-TP can be operated with its own addressing as so-called/Extended Addressing/or without address using only the CAN ID (so-called/Normal Addressing/). Extended addressing uses the first data byte of each frame as an additional element of the address, reducing the application payload by one byte.
So it's standard frames, with just an additional byte inserted before the protocol, used to extend the CAN ID. The OVMS poller doesn't support this yet. But it shouldn't be hard to add support for this, as it basically just fills the first frame byte from the lower 8 bits of the TX and RX IDs, reduces the payload size by one byte and shifts the offsets by one. PollerSend() and PollerReceive() need to be extended for this, and poll_pid_t needs to be extended by an addressing scheme tag. I'll have a look. Tell me if you'd like to take care of this. Regards, Michael Am 13.12.20 um 09:58 schrieb Steve Davies:
On Sat, 12 Dec 2020 at 17:28, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
with log level verbose for canlog, you can simply activate CAN logging via:
can log start monitor crtd
…that will log all frames, if that's too much, add a filter like this:
can log start monitor crtd 600-7ff
To see what was happening I had to "log level verbose canlog-monitor"
I see this being transmitted:
V (62436161) canlog-monitor: 1607847148.142477 1T11 6F1 03 22 dd bc 00 00 00 00
There is no reply.
The other app I looked at does this on the LM327 as setup before sending the request:
2020-11-15 10:34:35.115 --> ATCEA07⏎ "extended address" 0x07 2020-11-15 10:34:35.127 <-- OK⏎⏎>
Looking at the LM327 data sheet this configures an "extended address" which is sent after the 0x6F1
I'm not sure if that 0x03 in what OVMS is sending is that byte, and I need to somehow replace it wih 07, or if I have to get another inserted?
Perhaps this is old hat to those more experienced than me.
From the data sheet and the trace it seems I'm also responsible to customise the flow control messages :-
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⏎⏎>
I think that comes down to a flow control being "06 F1 07 30 08 00"
Here's the page in the LM327 to help understand what it does:
image.png
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On Sun, 13 Dec 2020 at 12:34, Michael Balzer <dexter@expeedo.de> wrote:
But it shouldn't be hard to add support for this, as it basically just fills the first frame byte from the lower 8 bits of the TX and RX IDs, reduces the payload size by one byte and shifts the offsets by one. PollerSend() and PollerReceive() need to be extended for this, and poll_pid_t needs to be extended by an addressing scheme tag.
In my inspection of traffic it seems that when we send the request frame this extra byte is always set the same as the bottom 8 bits of the RXMODULEID. IE in the example of the SOC - static const OvmsVehicle::poll_pid_t obdii_polls[] = { // TXMODULEID, RXMODULEID, PID, { POLLTIMES }, BUS { 0x6f1, 0x0607, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, { 60, 60, 60 }, 0 }, // SOC { 0, 0, 0x00, 0x00, { 0, 0, 0 }, 0 } }; So the extra byte would need to be RXMODULEID&0xff => 0x0607&0xff = 0x07 Does that seem reasonable? That seems to be consistent over all the queries I looked at in my traces. It isn't always 0x07 - I'm pretty sure it is to do with which ECU we are talking to. (I'm guessing it's some "route" to the ECU being queried since on the i3 there are lots of buses and the OBD isn't directly connected to any of them - the OBD goes to the body domain controller which connects in turn to the other buses. Note also that the flow control frame sent in reply to First Frames also needs to be formatted this way. I'm starting to understand why someone involved with the development of an Android app that can handle i3 OBD2 was full of dark hints of trouble ahead. OTOH, it would have been nice if he'd actually shared info and not just mysterious hints. If you could deal with this for me I'd be very grateful - I'm new to the code and also I'm not an experienced C++ programmer so I'd hate to send you a nasty PR. If you want to change it in a branch I can pull that branch into my fork and take it from there. Thanks, Steve
On Sun, 13 Dec 2020 at 12:34, Michael Balzer <dexter@expeedo.de> wrote:
But it shouldn't be hard to add support for this, as it basically just fills the first frame byte from the lower 8 bits of the TX and RX IDs, reduces the payload size by one byte and shifts the offsets by one. PollerSend() and PollerReceive() need to be extended for this, and poll_pid_t needs to be extended by an addressing scheme tag.
I don't think that the extra byte is included in the replies. (Would help if I could get a reply...): I'm not sure how your time and priorities go - so I started poking around. I hacked at vehicle.cpp to send it in this format. (Not a committable change, I just hard-coded it) V (250161) canlog-monitor: 1607862592.210593 1T11 6F1 07 03 22 dd bc 00 00 00 Frustratingly I'm still not seeing a response logged. (I do see a steady flow of what I assume are idle frames: V (1868881) canlog-monitor: 1607865104.942289 1R11 130 00 f0 fc ff ff V (1868981) canlog-monitor: 1607865105.042269 1R11 130 00 f0 fc ff ff) I haven't done anything to fix the flow control packet format, so I thought that might be the problem. So I tried another one that returns a single frame response - Battery voltage: V (102161) canlog-monitor: 1607863338.229125 1T11 6F1 07 03 22 dd 68 00 00 00 Also no reply. Is the CAN bus on the OBD-II port a bus? Can I connect both my bluetooth dongle and the OVMS to it and then capture what the other app does right in OVMS and as it sees it?
On Sun, 13 Dec 2020 at 15:38, Steve Davies <steve@telviva.co.za> wrote:
On Sun, 13 Dec 2020 at 12:34, Michael Balzer <dexter@expeedo.de> wrote:
But it shouldn't be hard to add support for this, as it basically just fills the first frame byte from the lower 8 bits of the TX and RX IDs, reduces the payload size by one byte and shifts the offsets by one. PollerSend() and PollerReceive() need to be extended for this, and poll_pid_t needs to be extended by an addressing scheme tag.
I don't think that the extra byte is included in the replies. (Would help if I could get a reply...):
I suddenly got a whole lot of warning logged: W (3516211) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 03 7f 22 78 00 00 00 | ..."x... W (3516261) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 10 09 62 dd bc 02 ea | ...b.... W (3518201) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 03 7f 22 78 00 00 00 | ..."x... W (3518261) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 05 62 dd 68 93 85 00 | ..b.h... W (3530211) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 03 7f 22 78 00 00 00 | ..."x... W (3530261) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 10 09 62 dd bc 02 eb | ...b.... W (3532211) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 03 7f 22 78 00 00 00 | ..."x... W (3532261) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 05 62 dd 68 93 86 00 | ..b.h... W (3544211) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 03 7f 22 78 00 00 00 | ..."x... W (3544261) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 10 09 62 dd bc 02 eb | ...b.... W (3546201) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 03 7f 22 78 00 00 00 | ..."x... W (3546261) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 05 62 dd 68 93 87 00 | ..b.h... W (3558211) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 03 7f 22 78 00 00 00 | ..."x... W (3558261) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 10 09 62 dd bc 02 eb | ...b.... W (3560201) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 03 7f 22 78 00 00 00 | ..."x... W (3560261) vehicle: PollerReceive[607]: ignoring unknown/invalid ISO TP frame: f1 05 62 dd 68 93 88 00 | ..b.h... In there I can see "f1 10 09 62 dd bc 02 eb" 0x02eb = 747 = 74.7% - so there is the SOC. :-) and "f1 05 62 dd 68 93 88 00" 0x9388 = 37768 = 377.68 volts - so there is the battery voltage. So it looks like the receivepacket does need to be adjusted too - that f1 I guess is OUR "extended address".
On Sun, 13 Dec 2020 at 15:55, Steve Davies <steve@telviva.co.za> wrote:
In there I can see "f1 10 09 62 dd bc 02 eb" 0x02eb = 747 = 74.7% - so there is the SOC. :-) and "f1 05 62 dd 68 93 88 00" 0x9388 = 37768 = 377.68 volts - so there is the battery voltage.
So it looks like the receivepacket does need to be adjusted too - that f1 I guess is OUR "extended address".
Well I put another nasty hack in PollerReceive and I have my first value :-) D (576161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DD68], expecting 6f1/607-607 D (576201) vehicle: PollerReceive[607]: process OBD/UDS response 22(DD68) frm=0 len=2 off=0 rem=0 D (576201) v-bmwi3: BMWI3: got Volts=380.35V I just did this so as to make the received packet look like a "normal" one : // SD: Hack to remove the extended addressing if (frame->data.u8[0] == 0xf1) { for (uint8_t i = 0; i<7; i++) { frame->data.u8[i] = frame->data.u8[i+1]; } } But my hack is no real solution - it was a test and shows that the poll succeeds with the extended address included on the transmit and expected (and removed) on receive. So like you say the car can be supported with the help of support for the ISO-TP extended addressing scheme. How to proceed? I think it's better if you add the support since I don't know the code well yet. I can make a github issue. But if you don't have time or inclination I can have a go myself since I'm keen to make progress with this over the holidays. Thanks, Steve
Steve, please try the poller rework I just pushed to the new "isotp-extadr" branch. These poll_pid_t records would define the example shown in the ELM327 manual: { 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIISESSION, 0x81, { 20, 0, 0 }, 0, ISOTP_EXTADR }, { 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIIGROUP, 0xa2, { 30, 0, 0 }, 0, ISOTP_EXTADR }, I've used these + matching faked rx frames to verify the implementation. Your SOC poll should look like this: { 0x6F107, 0x607F1, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, { 0, 10, 60 }, 0, ISOTP_EXTADR }, …and your IncomingPollReply() should receive the reply with pid == 0x607F1. Please report your results. Thanks, Michael Am 13.12.20 um 11:33 schrieb Michael Balzer:
Steve,
sorry, totally missed that. That's very unusual, haven't seen that before. I first thought maybe that's using CAN extended frame mode, but that's a totally different thing: it seems the i3 uses the *ISO-TP extended addressing scheme*.
Quoting from Wikipedia: https://en.wikipedia.org/wiki/ISO_15765-2
ISO-TP can be operated with its own addressing as so-called/Extended Addressing/or without address using only the CAN ID (so-called/Normal Addressing/). Extended addressing uses the first data byte of each frame as an additional element of the address, reducing the application payload by one byte.
So it's standard frames, with just an additional byte inserted before the protocol, used to extend the CAN ID.
The OVMS poller doesn't support this yet.
But it shouldn't be hard to add support for this, as it basically just fills the first frame byte from the lower 8 bits of the TX and RX IDs, reduces the payload size by one byte and shifts the offsets by one. PollerSend() and PollerReceive() need to be extended for this, and poll_pid_t needs to be extended by an addressing scheme tag.
I'll have a look. Tell me if you'd like to take care of this.
Regards, Michael
Am 13.12.20 um 09:58 schrieb Steve Davies:
On Sat, 12 Dec 2020 at 17:28, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
with log level verbose for canlog, you can simply activate CAN logging via:
can log start monitor crtd
…that will log all frames, if that's too much, add a filter like this:
can log start monitor crtd 600-7ff
To see what was happening I had to "log level verbose canlog-monitor"
I see this being transmitted:
V (62436161) canlog-monitor: 1607847148.142477 1T11 6F1 03 22 dd bc 00 00 00 00
There is no reply.
The other app I looked at does this on the LM327 as setup before sending the request:
2020-11-15 10:34:35.115 --> ATCEA07⏎ "extended address" 0x07 2020-11-15 10:34:35.127 <-- OK⏎⏎>
Looking at the LM327 data sheet this configures an "extended address" which is sent after the 0x6F1
I'm not sure if that 0x03 in what OVMS is sending is that byte, and I need to somehow replace it wih 07, or if I have to get another inserted?
Perhaps this is old hat to those more experienced than me.
From the data sheet and the trace it seems I'm also responsible to customise the flow control messages :-
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⏎⏎>
I think that comes down to a flow control being "06 F1 07 30 08 00"
Here's the page in the LM327 to help understand what it does:
image.png
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi, It seems to do what is expected - thanks, you are very fast! D (706161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DDBC], expecting 6f107/607f1-607f1 V (706161) canlog-monitor: 1607882591.310736 1T11 6F1 07 03 22 dd bc 00 00 00 D (708161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DD68], expecting 6f107/607f1-607f1 V (708161) canlog-monitor: 1607882593.310901 1T11 6F1 07 03 22 dd 68 00 00 00 But most times I don't get a reply. But not never - here's an example that worked: D (896161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DDBC], expecting 6f107/607f1-607f1 D (896211) vehicle: PollerReceive[607F1]: got OBD/UDS info 22(DDBC) code=78 (pending) D (896211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DDBC) frm=0 len=2 off=0 rem=4 D (896211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DDBC) frm=1 len=4 off=2 rem=0 D (896211) v-bmwi3: BMWI3: got SOC=86.7% D (897161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DD68], expecting 6f107/607f1-607f1 D (897211) vehicle: PollerReceive[607F1]: got OBD/UDS info 22(DD68) code=78 (pending) D (897211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DD68) frm=0 len=2 off=0 rem=0 D (897211) v-bmwi3: BMWI3: got Volts=388.77V The car is charging but otherwise "off" and locked. Perhaps that has something to do with the lack of replies. Steve On Sun, 13 Dec 2020 at 18:24, Michael Balzer <dexter@expeedo.de> wrote:
Steve,
please try the poller rework I just pushed to the new "isotp-extadr" branch.
These poll_pid_t records would define the example shown in the ELM327 manual:
{ 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIISESSION, 0x81, { 20, 0, 0 }, 0, ISOTP_EXTADR }, { 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIIGROUP, 0xa2, { 30, 0, 0 }, 0, ISOTP_EXTADR },
I've used these + matching faked rx frames to verify the implementation.
Your SOC poll should look like this:
{ 0x6F107, 0x607F1, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, { 0, 10, 60 }, 0, ISOTP_EXTADR },
…and your IncomingPollReply() should receive the reply with pid == 0x607F1 .
Please report your results.
Thanks, Michael
Am 13.12.20 um 11:33 schrieb Michael Balzer:
Steve,
sorry, totally missed that. That's very unusual, haven't seen that before. I first thought maybe that's using CAN extended frame mode, but that's a totally different thing: it seems the i3 uses the *ISO-TP extended addressing scheme*.
Quoting from Wikipedia: https://en.wikipedia.org/wiki/ISO_15765-2
ISO-TP can be operated with its own addressing as so-called *Extended Addressing* or without address using only the CAN ID (so-called *Normal Addressing*). Extended addressing uses the first data byte of each frame as an additional element of the address, reducing the application payload by one byte.
So it's standard frames, with just an additional byte inserted before the protocol, used to extend the CAN ID.
The OVMS poller doesn't support this yet.
But it shouldn't be hard to add support for this, as it basically just fills the first frame byte from the lower 8 bits of the TX and RX IDs, reduces the payload size by one byte and shifts the offsets by one. PollerSend() and PollerReceive() need to be extended for this, and poll_pid_t needs to be extended by an addressing scheme tag.
I'll have a look. Tell me if you'd like to take care of this.
Regards, Michael
Am 13.12.20 um 09:58 schrieb Steve Davies:
On Sat, 12 Dec 2020 at 17:28, Michael Balzer <dexter@expeedo.de> wrote:
with log level verbose for canlog, you can simply activate CAN logging via:
can log start monitor crtd
…that will log all frames, if that's too much, add a filter like this:
can log start monitor crtd 600-7ff
To see what was happening I had to "log level verbose canlog-monitor"
I see this being transmitted:
V (62436161) canlog-monitor: 1607847148.142477 1T11 6F1 03 22 dd bc 00 00 00 00
There is no reply.
The other app I looked at does this on the LM327 as setup before sending the request:
2020-11-15 10:34:35.115 --> ATCEA07⏎ "extended address" 0x07 2020-11-15 10:34:35.127 <-- OK⏎⏎>
Looking at the LM327 data sheet this configures an "extended address" which is sent after the 0x6F1
I'm not sure if that 0x03 in what OVMS is sending is that byte, and I need to somehow replace it wih 07, or if I have to get another inserted?
Perhaps this is old hat to those more experienced than me.
From the data sheet and the trace it seems I'm also responsible to customise the flow control messages :-
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⏎⏎>
I think that comes down to a flow control being "06 F1 07 30 08 00"
Here's the page in the LM327 to help understand what it does:
[image: image.png]
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Steve, thanks for testing, glad it's working already. I'll do some more tests to be sure it doesn't affect normal polling, and merge into the master then. Probably not today though. Regarding the missing replies, most vehicles need some sort of diagnostic session to know they need to react to requests. That's normally done with the request type VEHICLE_POLL_TYPE_OBDIISESSION (0x10) plus a session type. There are a few standard session types, but most vehicles use custom types you need to know. Sessions expire, so the request needs to be sent e.g. once per minute. But be aware that may lead to the vehicle staying awake indefinitely, so it's usually a good idea to detect the vehicle state by something you can determine without the need of a session. As your CAN statistics showed lots of received frames before you started transmitting some, it seems there are live data frames on the bus. I suggest looking for a vehicle status indicator in those frames. The RE toolkit is good for this. Regards, Michael Am 13.12.20 um 19:15 schrieb Steve Davies:
Hi,
It seems to do what is expected - thanks, you are very fast!
D (706161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DDBC], expecting 6f107/607f1-607f1 V (706161) canlog-monitor: 1607882591.310736 1T11 6F1 07 03 22 dd bc 00 00 00
D (708161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DD68], expecting 6f107/607f1-607f1 V (708161) canlog-monitor: 1607882593.310901 1T11 6F1 07 03 22 dd 68 00 00 00
But most times I don't get a reply.
But not never - here's an example that worked:
D (896161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DDBC], expecting 6f107/607f1-607f1 D (896211) vehicle: PollerReceive[607F1]: got OBD/UDS info 22(DDBC) code=78 (pending) D (896211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DDBC) frm=0 len=2 off=0 rem=4 D (896211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DDBC) frm=1 len=4 off=2 rem=0 D (896211) v-bmwi3: BMWI3: got SOC=86.7% D (897161) vehicle: PollerSend(1): send [bus=0, type=22, pid=DD68], expecting 6f107/607f1-607f1 D (897211) vehicle: PollerReceive[607F1]: got OBD/UDS info 22(DD68) code=78 (pending) D (897211) vehicle: PollerReceive[607F1]: process OBD/UDS response 22(DD68) frm=0 len=2 off=0 rem=0 D (897211) v-bmwi3: BMWI3: got Volts=388.77V
The car is charging but otherwise "off" and locked. Perhaps that has something to do with the lack of replies.
Steve
On Sun, 13 Dec 2020 at 18:24, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Steve,
please try the poller rework I just pushed to the new "isotp-extadr" branch.
These poll_pid_t records would define the example shown in the ELM327 manual:
{ 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIISESSION, 0x81, { 20, 0, 0 }, 0, ISOTP_EXTADR }, { 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIIGROUP, 0xa2, { 30, 0, 0 }, 0, ISOTP_EXTADR },
I've used these + matching faked rx frames to verify the implementation.
Your SOC poll should look like this:
{ 0x6F107, 0x607F1, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, { 0, 10, 60 }, 0, ISOTP_EXTADR },
…and your IncomingPollReply() should receive the reply with pid == 0x607F1.
Please report your results.
Thanks, Michael
Am 13.12.20 um 11:33 schrieb Michael Balzer:
Steve,
sorry, totally missed that. That's very unusual, haven't seen that before. I first thought maybe that's using CAN extended frame mode, but that's a totally different thing: it seems the i3 uses the *ISO-TP extended addressing scheme*.
Quoting from Wikipedia: https://en.wikipedia.org/wiki/ISO_15765-2 <https://en.wikipedia.org/wiki/ISO_15765-2>
ISO-TP can be operated with its own addressing as so-called/Extended Addressing/or without address using only the CAN ID (so-called/Normal Addressing/). Extended addressing uses the first data byte of each frame as an additional element of the address, reducing the application payload by one byte.
So it's standard frames, with just an additional byte inserted before the protocol, used to extend the CAN ID.
The OVMS poller doesn't support this yet.
But it shouldn't be hard to add support for this, as it basically just fills the first frame byte from the lower 8 bits of the TX and RX IDs, reduces the payload size by one byte and shifts the offsets by one. PollerSend() and PollerReceive() need to be extended for this, and poll_pid_t needs to be extended by an addressing scheme tag.
I'll have a look. Tell me if you'd like to take care of this.
Regards, Michael
Am 13.12.20 um 09:58 schrieb Steve Davies:
On Sat, 12 Dec 2020 at 17:28, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
with log level verbose for canlog, you can simply activate CAN logging via:
can log start monitor crtd
…that will log all frames, if that's too much, add a filter like this:
can log start monitor crtd 600-7ff
To see what was happening I had to "log level verbose canlog-monitor"
I see this being transmitted:
V (62436161) canlog-monitor: 1607847148.142477 1T11 6F1 03 22 dd bc 00 00 00 00
There is no reply.
The other app I looked at does this on the LM327 as setup before sending the request:
2020-11-15 10:34:35.115 --> ATCEA07⏎ "extended address" 0x07 2020-11-15 10:34:35.127 <-- OK⏎⏎>
Looking at the LM327 data sheet this configures an "extended address" which is sent after the 0x6F1
I'm not sure if that 0x03 in what OVMS is sending is that byte, and I need to somehow replace it wih 07, or if I have to get another inserted?
Perhaps this is old hat to those more experienced than me.
From the data sheet and the trace it seems I'm also responsible to customise the flow control messages :-
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⏎⏎>
I think that comes down to a flow control being "06 F1 07 30 08 00"
Here's the page in the LM327 to help understand what it does:
image.png
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Everyone, in case you missed the BMW i3 thread: I've added support for the ISO-TP "extended addressing scheme" to our poller (see below for details). The extension should not affect standard polling, but I had to touch all polling lists to add the protocol tag. I've tested the change with my car (Twizy) but would like to get some test results for other vehicle modules before merging into the master. Please pull, checkout and build from the "isotp-extadr" branch to test this with your car, and report your results. Thanks! Regards, Michael Am 13.12.20 um 17:24 schrieb Michael Balzer:
Steve,
please try the poller rework I just pushed to the new "isotp-extadr" branch.
These poll_pid_t records would define the example shown in the ELM327 manual:
{ 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIISESSION, 0x81, { 20, 0, 0 }, 0, ISOTP_EXTADR }, { 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIIGROUP, 0xa2, { 30, 0, 0 }, 0, ISOTP_EXTADR },
I've used these + matching faked rx frames to verify the implementation.
Your SOC poll should look like this:
{ 0x6F107, 0x607F1, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, { 0, 10, 60 }, 0, ISOTP_EXTADR },
…and your IncomingPollReply() should receive the reply with pid == 0x607F1.
Please report your results.
Thanks, Michael
Am 13.12.20 um 11:33 schrieb Michael Balzer:
Steve,
sorry, totally missed that. That's very unusual, haven't seen that before. I first thought maybe that's using CAN extended frame mode, but that's a totally different thing: it seems the i3 uses the *ISO-TP extended addressing scheme*.
Quoting from Wikipedia: https://en.wikipedia.org/wiki/ISO_15765-2
ISO-TP can be operated with its own addressing as so-called/Extended Addressing/or without address using only the CAN ID (so-called/Normal Addressing/). Extended addressing uses the first data byte of each frame as an additional element of the address, reducing the application payload by one byte.
So it's standard frames, with just an additional byte inserted before the protocol, used to extend the CAN ID.
The OVMS poller doesn't support this yet.
But it shouldn't be hard to add support for this, as it basically just fills the first frame byte from the lower 8 bits of the TX and RX IDs, reduces the payload size by one byte and shifts the offsets by one. PollerSend() and PollerReceive() need to be extended for this, and poll_pid_t needs to be extended by an addressing scheme tag.
I'll have a look. Tell me if you'd like to take care of this.
Regards, Michael
Am 13.12.20 um 09:58 schrieb Steve Davies:
On Sat, 12 Dec 2020 at 17:28, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
with log level verbose for canlog, you can simply activate CAN logging via:
can log start monitor crtd
…that will log all frames, if that's too much, add a filter like this:
can log start monitor crtd 600-7ff
To see what was happening I had to "log level verbose canlog-monitor"
I see this being transmitted:
V (62436161) canlog-monitor: 1607847148.142477 1T11 6F1 03 22 dd bc 00 00 00 00
There is no reply.
The other app I looked at does this on the LM327 as setup before sending the request:
2020-11-15 10:34:35.115 --> ATCEA07⏎ "extended address" 0x07 2020-11-15 10:34:35.127 <-- OK⏎⏎>
Looking at the LM327 data sheet this configures an "extended address" which is sent after the 0x6F1
I'm not sure if that 0x03 in what OVMS is sending is that byte, and I need to somehow replace it wih 07, or if I have to get another inserted?
Perhaps this is old hat to those more experienced than me.
From the data sheet and the trace it seems I'm also responsible to customise the flow control messages :-
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⏎⏎>
I think that comes down to a flow control being "06 F1 07 30 08 00"
Here's the page in the LM327 to help understand what it does:
image.png
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I've merged the rework into the master now. Regards, Michael Am 17.12.20 um 09:21 schrieb Michael Balzer:
Everyone,
in case you missed the BMW i3 thread: I've added support for the ISO-TP "extended addressing scheme" to our poller (see below for details).
The extension should not affect standard polling, but I had to touch all polling lists to add the protocol tag.
I've tested the change with my car (Twizy) but would like to get some test results for other vehicle modules before merging into the master.
Please pull, checkout and build from the "isotp-extadr" branch to test this with your car, and report your results.
Thanks!
Regards, Michael
Am 13.12.20 um 17:24 schrieb Michael Balzer:
Steve,
please try the poller rework I just pushed to the new "isotp-extadr" branch.
These poll_pid_t records would define the example shown in the ELM327 manual:
{ 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIISESSION, 0x81, { 20, 0, 0 }, 0, ISOTP_EXTADR }, { 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIIGROUP, 0xa2, { 30, 0, 0 }, 0, ISOTP_EXTADR },
I've used these + matching faked rx frames to verify the implementation.
Your SOC poll should look like this:
{ 0x6F107, 0x607F1, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, { 0, 10, 60 }, 0, ISOTP_EXTADR },
…and your IncomingPollReply() should receive the reply with pid == 0x607F1.
Please report your results.
Thanks, Michael
Am 13.12.20 um 11:33 schrieb Michael Balzer:
Steve,
sorry, totally missed that. That's very unusual, haven't seen that before. I first thought maybe that's using CAN extended frame mode, but that's a totally different thing: it seems the i3 uses the *ISO-TP extended addressing scheme*.
Quoting from Wikipedia: https://en.wikipedia.org/wiki/ISO_15765-2
ISO-TP can be operated with its own addressing as so-called/Extended Addressing/or without address using only the CAN ID (so-called/Normal Addressing/). Extended addressing uses the first data byte of each frame as an additional element of the address, reducing the application payload by one byte.
So it's standard frames, with just an additional byte inserted before the protocol, used to extend the CAN ID.
The OVMS poller doesn't support this yet.
But it shouldn't be hard to add support for this, as it basically just fills the first frame byte from the lower 8 bits of the TX and RX IDs, reduces the payload size by one byte and shifts the offsets by one. PollerSend() and PollerReceive() need to be extended for this, and poll_pid_t needs to be extended by an addressing scheme tag.
I'll have a look. Tell me if you'd like to take care of this.
Regards, Michael
Am 13.12.20 um 09:58 schrieb Steve Davies:
On Sat, 12 Dec 2020 at 17:28, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
with log level verbose for canlog, you can simply activate CAN logging via:
can log start monitor crtd
…that will log all frames, if that's too much, add a filter like this:
can log start monitor crtd 600-7ff
To see what was happening I had to "log level verbose canlog-monitor"
I see this being transmitted:
V (62436161) canlog-monitor: 1607847148.142477 1T11 6F1 03 22 dd bc 00 00 00 00
There is no reply.
The other app I looked at does this on the LM327 as setup before sending the request:
2020-11-15 10:34:35.115 --> ATCEA07⏎ "extended address" 0x07 2020-11-15 10:34:35.127 <-- OK⏎⏎>
Looking at the LM327 data sheet this configures an "extended address" which is sent after the 0x6F1
I'm not sure if that 0x03 in what OVMS is sending is that byte, and I need to somehow replace it wih 07, or if I have to get another inserted?
Perhaps this is old hat to those more experienced than me.
From the data sheet and the trace it seems I'm also responsible to customise the flow control messages :-
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⏎⏎>
I think that comes down to a flow control being "06 F1 07 30 08 00"
Here's the page in the LM327 to help understand what it does:
image.png
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Thanks, I’ll resync my branch. Steve On Tue, 22 Dec 2020 at 17:50, Michael Balzer <dexter@expeedo.de> wrote:
I've merged the rework into the master now.
Regards, Michael
Am 17.12.20 um 09:21 schrieb Michael Balzer:
Everyone,
in case you missed the BMW i3 thread: I've added support for the ISO-TP "extended addressing scheme" to our poller (see below for details).
The extension should not affect standard polling, but I had to touch all polling lists to add the protocol tag.
I've tested the change with my car (Twizy) but would like to get some test results for other vehicle modules before merging into the master.
Please pull, checkout and build from the "isotp-extadr" branch to test this with your car, and report your results.
Thanks!
Regards, Michael
Am 13.12.20 um 17:24 schrieb Michael Balzer:
Steve,
please try the poller rework I just pushed to the new "isotp-extadr" branch.
These poll_pid_t records would define the example shown in the ELM327 manual:
{ 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIISESSION, 0x81, { 20, 0, 0 }, 0, ISOTP_EXTADR }, { 0x7b004, 0x7c0f1, VEHICLE_POLL_TYPE_OBDIIGROUP, 0xa2, { 30, 0, 0 }, 0, ISOTP_EXTADR },
I've used these + matching faked rx frames to verify the implementation.
Your SOC poll should look like this:
{ 0x6F107, 0x607F1, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0xDDBC, { 0, 10, 60 }, 0, ISOTP_EXTADR },
…and your IncomingPollReply() should receive the reply with pid == 0x607F1 .
Please report your results.
Thanks, Michael
Am 13.12.20 um 11:33 schrieb Michael Balzer:
Steve,
sorry, totally missed that. That's very unusual, haven't seen that before. I first thought maybe that's using CAN extended frame mode, but that's a totally different thing: it seems the i3 uses the *ISO-TP extended addressing scheme*.
Quoting from Wikipedia: https://en.wikipedia.org/wiki/ISO_15765-2
ISO-TP can be operated with its own addressing as so-called *Extended Addressing* or without address using only the CAN ID (so-called *Normal Addressing*). Extended addressing uses the first data byte of each frame as an additional element of the address, reducing the application payload by one byte.
So it's standard frames, with just an additional byte inserted before the protocol, used to extend the CAN ID.
The OVMS poller doesn't support this yet.
But it shouldn't be hard to add support for this, as it basically just fills the first frame byte from the lower 8 bits of the TX and RX IDs, reduces the payload size by one byte and shifts the offsets by one. PollerSend() and PollerReceive() need to be extended for this, and poll_pid_t needs to be extended by an addressing scheme tag.
I'll have a look. Tell me if you'd like to take care of this.
Regards, Michael
Am 13.12.20 um 09:58 schrieb Steve Davies:
On Sat, 12 Dec 2020 at 17:28, Michael Balzer <dexter@expeedo.de> wrote:
with log level verbose for canlog, you can simply activate CAN logging via:
can log start monitor crtd
…that will log all frames, if that's too much, add a filter like this:
can log start monitor crtd 600-7ff
To see what was happening I had to "log level verbose canlog-monitor"
I see this being transmitted:
V (62436161) canlog-monitor: 1607847148.142477 1T11 6F1 03 22 dd bc 00 00 00 00
There is no reply.
The other app I looked at does this on the LM327 as setup before sending the request:
2020-11-15 10:34:35.115 --> ATCEA07⏎ "extended address" 0x07 2020-11-15 10:34:35.127 <-- OK⏎⏎>
Looking at the LM327 data sheet this configures an "extended address" which is sent after the 0x6F1
I'm not sure if that 0x03 in what OVMS is sending is that byte, and I need to somehow replace it wih 07, or if I have to get another inserted?
Perhaps this is old hat to those more experienced than me.
From the data sheet and the trace it seems I'm also responsible to customise the flow control messages :-
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⏎⏎>
I think that comes down to a flow control being "06 F1 07 30 08 00"
Here's the page in the LM327 to help understand what it does:
[image: image.png]
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Stephen Davies Chief Technical Officer, Telviva (PTY) Ltd (previously Connection Telecom (PTY) Ltd Direct: 0878200262 / Reception: 0878200200 Written on the go, please excuse brevity/typos.
participants (2)
-
Michael Balzer -
Steve Davies