December 2020 - OvmsDev - Open Vehicles

Keeping OBD-II alive
by Steve Davies 27 Dec '20

27 Dec '20

Hi all, Merry Christmas if you celebrate - beautiful hot weather here in Cape Town but surely a different story for most of you! (Michael: Thanks for the help with that "BC".) My car's OBD currently goes off after a while whenever it's not READY (to drive) (whether charging or not), This obviously affects the usability on my car, especially when charging since you can't follow the charging process properly. I did find that if you use the remote key it will wake things up; if you use BMW Connected drive app to lock/unlock then that also wakes things up. I see that the MGEV seems similar - the docs for that car say: The car is accessible over the OBD port when it is running (ignition on) and for around 40 seconds after it is turned off or the car is "tweaked" (lock button pushed, etc). The OBD port may be kept awake by using the "tester present" message to the gateway ECU. This keeps a lot of systems awake and draws roughly 5A on the 12V bus, so it's not a good idea to do. If the car is unlocked, the gateway can be woken if the car is unlocked by pinging the "tester present" message continuously every 100ms until it responds. If the car is locked this simply causes the gateway to go into some kind of zombie proxy mode that isn't very useful. If the car is locked, the gateway may be woken by sending a session 2 command every 250ms to the gateway. I'm looking at the MGEV code to see how it's done - can see the gist of it. It looks like Chris Staite was the author of the MGEV support - Chris are you on the list? Can you answer some questions for me or give me an outline as to how it goes? My logic would be that if the car is charging it doesn't do much harm to try to keep the OBD-II responsive. I suppose it diverts a little power from charging, but when you are on a long trip and fast charging somewhere you want to know if charging stops! Thanks, Steve

2 3

WiFi client not switching to better AP
by Stephen Casner 23 Dec '20

23 Dec '20

Many months ago I installed another AP for the home network in my garage because the signal quality to the main router was too poor for OVMS to operate. Today I needed to restart the garage AP, so OVMS hear the main router again and associated to it. But even after the garage AP came back up, OVMS stuck with the main router and kept toggling between WiFi and modem because the signal quality was bad. It this behavior just a function of the WiFi driver that we can't control, or is it something we could improve? I fixed it by "wifi mode off" then "wifi mode client". -- Steve I (513443477) netmanager: WIFI client has bad signal quality (-89.2 dBm); disconnect I (513443477) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (513443477) netmanager: Set DNS#0 8.8.8.8 I (513443477) netmanager: Set DNS#1 8.8.4.4 I (513443477) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (513443537) time: Network was reconfigured: restarting SNTP client I (513443547) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513443547) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513443717) ovms-server-v2: Status: Disconnected I (513463467) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (513463467) ovms-server-v2: Status: Connecting... I (513466157) ovms-server-v2: Connection successful I (513466157) ovms-server-v2: Status: Logging in... ... I (513522477) netmanager: WIFI client has good signal quality (-86.9 dBm); connect I (513522477) netmanager: Interface priority is st13 (192.168.1.74/255.255.255.0 gateway 192.168.1.254) I (513522477) netmanager: Set DNS#0 8.8.8.8 I (513522477) netmanager: Set DNS#1 8.8.4.4 I (513522477) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority I (513522527) time: Network was reconfigured: restarting SNTP client I (513522527) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513522527) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513522697) ovms-server-v2: Status: Disconnected I (513529477) netmanager: WIFI client has bad signal quality (-89.0 dBm); disconnect I (513529477) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (513529477) netmanager: Set DNS#0 8.8.8.8 I (513529477) netmanager: Set DNS#1 8.8.4.4 I (513529477) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (513529527) time: Network was reconfigured: restarting SNTP client I (513529537) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513529537) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513539467) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (513539467) ovms-server-v2: Status: Connecting... I (513541987) ovms-server-v2: Connection successful I (513541987) ovms-server-v2: Status: Logging in...

4 30

Help me get my first data item on the I3
by Steve Davies 23 Dec '20

23 Dec '20

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

2 17

How fast can the poller go?
by Steve Davies 22 Dec '20

22 Dec '20

Hi, On the i3 I have to poll for everything - at least if I use the OBD2 port. It seems that the poller only sends one request per second. That's how it looks in the logs. This severely limits how many pids I can poll and basically means I might as well not bother with any of the "real time" metrics. Is there a reason why PollerSend couldn't look through the whole poll list and poll all the entries that are due/overdue on each call? At the moment it just looks until if finds one to do and then it returns. Or maybe if we can't take too long then say do 10 on each call? Thanks, Steve

2 2

Help from a german-speaker
by Steve Davies 22 Dec '20

22 Dec '20

Hi, Can I ask please for help from a german speaker / Kann ich bitte einen deutschen Sprecher um Hilfe bitten? On the i3 I have a pid that returns four ranges. 3 are clearly identified as the remaining range in Confort / Ecopro / Ecopro+ driving modes. The fourth is called STAT_BC_REICHWEITE_WERT - does anyone know what "BC" might stand for? 2020-12-22 10:42:36 SAST D (7528225) v-bmwi3: From ECU KOM, pid REICHWEITE_MCV: got STAT_ECO_MODE_REICHWEITE_WERT=176"km" 2020-12-22 10:42:36 SAST D (7528225) v-bmwi3: From ECU KOM, pid REICHWEITE_MCV: got STAT_COMFORT_MODE_REICHWEITE_WERT=164"km" 2020-12-22 10:42:36 SAST D (7528225) v-bmwi3: From ECU KOM, pid REICHWEITE_MCV: got STAT_BC_REICHWEITE_WERT=169"km" 2020-12-22 10:42:36 SAST D (7528225) v-bmwi3: From ECU KOM, pid REICHWEITE_MCV: got STAT_ECO_PRO_PLUS_REICHWEITE_WERT=184"km" The "BC" range varies - sometimes high relative to the others, sometimes lower. My car has a Sport mode too but the onboard display shows the same range for that as comfort mode (yeah, right!) - so it's not that. Thanks, Steve

2 1

Dcdc converter metrics
by Derek Caudwell 20 Dec '20

20 Dec '20

If additional metrics are being added for the dcdc converter I suggest including the following as well as temp: v.c.12v.voltage 14.2V v.c.12v.current 10A v.c.12v.power 0.14kW For the Leaf I have found the dcdc output voltage, still looking for a current reading to calculate the power output. Cheers Derek

5 6

Advice - mapping I3 data to the standard metrics
by Steve Davies 20 Dec '20

20 Dec '20

Hi Michael et al, I set my first goal to get all the metrics that are required for the standard dashboard to work on the I3. I've got some questions about the intended use of the metrics. Hope someone can give advice: I'm sorry this is a tome, I did work to shorten it. 1) How do I understand a "trip"? My car has a trip-meter that you can reset. It also by itself seems to have some heuristic for trips that it uses for the "ecodrive" stuff. There are some PIDS that return trip-related data but I must still figure out when they reset - whether it goes by the trip feature. But what does OVMS regard as a "trip"? For me: I would want it to work automatically - ie reset the trip stats each time the car goes to READY except perhaps if it has just been a few minutes since it was turned off. 2) About temperatures: The i3 has SO MANY temperature sensors, especially in the "electrical machine electronics" - how to map them to the standard metrics in OVMS? I guess you will say it's my call, but I'd like what I do to be consistent with other vehicles. There are the following standard metrics relating to temperature (you can see some I mapped already) a) Battery temps: These I took from a PID that returns a "coldest", "hottest" and mean for the pack as a whole : v.b.p.temp.avg 21.27°C v.b.p.temp.max 21.83°C v.b.p.temp.min 21.04°C v.b.p.temp.stddev v.b.p.temp.stddev.max v.b.temp 21.27°C A min, max, and mean doesn't give me enough to work out a standard deviation. And: what is a "maximum" stddev? Is that over time? And for v.b.temp I just used the avg temp from above. I could have used the max instead - any view? : b) v.e.temp: ("environmental temp") Found a value for outside / ambient temp : v.e.temp 21.5°C c) v.m.temp - motor temp: There are two temps for the "e-machine". These are inside the actual electric motor. I used the hotter of the two : v.m.temp 25.3968°C d) v.e.cabintemp: I haven't looked into the aircon system yet: e) v.i.temp: Inverter temp: There are 4 inverter temps: // Temperature converter phase U / Temperatur Umrichter Phase U 2020-12-16 17:59:10 SAST D (289275) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_UMRICHTER_PHASE_U_WERT=35.8020"°C" // Temperature converter phase V / Temperatur Umrichter Phase V 2020-12-16 17:59:10 SAST D (289275) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_UMRICHTER_PHASE_V_WERT=35.0532"°C" // Temperature converter phase W / Temperatur Umrichter Phase W 2020-12-16 17:59:10 SAST D (289275) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_UMRICHTER_PHASE_W_WERT=34.7568"°C" // Temperature inverter gate driver / Temperatur Inverter Gatedriver 2020-12-16 17:59:10 SAST D (289275) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_UMRICHTER_GT_WERT=45.5832"°C" I just took the highest. f) v.c.temp: charger temp: For v.c.temp there are also 4 measurements: // Temperature SLE-PowerFactorCorrection / Temperatur SLE-PowerFactorCorrection 2020-12-16 17:59:10 SAST D (289285) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_SLE_PFC_WERT=27.0972"°C" // Temperature SLE rectifier / Temperatur SLE-Gleichrichter 2020-12-16 17:59:10 SAST D (289285) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_SLE_GR_WERT=28.0488"°C" // Temperature SLE push-pull converter / Temperatur SLE-Gegentaktwandler 2020-12-16 17:59:10 SAST D (289285) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_SLE_GTW_WERT=27.5652"°C" // Temperature of the SLE board / Temperatur des SLE Boards 2020-12-16 17:59:10 SAST D (289285) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_SLE_BO_WERT=29.0004"°C" (SLE also called KLE elsewhere - Komfort Ladeelectronik I think it is) I took the hottest. My car also has DC charging but if I understand that rightly there isn't any high power electrical stuff onboard for that, contactors are closed to give the external - so nothing to get hot except the battery itself. Then I have some more temps - DC/DC converter used to supply the 12v systems (and to charge the 12 battery). I don't see any standard metrics for this subsystem? // Temperature of the DCDC board / Temperatur des DCDC Boards 2020-12-16 17:59:10 SAST D (289285) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_DCDC_BO_WERT=35.8488"°C" // Temperature DC / DC push-pull converter / Temperatur DC/DC-Gegentaktwandler 2020-12-16 17:59:10 SAST D (289285) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_DCDC_GTW_WERT=32.0892"°C" // Temperature DC / DC buck converter / Temperatur DC/DC-Tiefsetzer 2020-12-16 17:59:10 SAST D (289285) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_DCDC_TS_WERT=59.9976"°C" // Temperature of the DCDC board / Temperatur des DCDC Boards 2020-12-16 17:59:10 SAST D (289285) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_DCDC_GR_WERT=31.6524"°C" - "ELUP power output stage". Dunno what "ELUP" is and didn't find it in the technical training info I have. // Temperature on the power board - measuring point ELUP power output stage / Temperatur auf dem Powerbord - // Messstelle ELUP Leistungsendstufe 2020-12-16 17:59:10 SAST D (289285) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_ELUP_LE_WERT=30.0768"°C" - And 2 processor temps: // Temperature processor MC0 / Temperatur Prozessor MC0 2020-12-16 17:59:10 SAST D (289285) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_PROZESSOR_MC0_WERT=39.9048"°C" // Temperature processor MC2 / Temperatur Prozessor MC2 2020-12-16 17:59:10 SAST D (289285) v-bmwi3: From ECU EME, pid AE_TEMP_LE: got STAT_TEMP_PROZESSOR_MC2_WERT=39.9048"°C" 3) What to do about "range". So I found a pid that returns a "range" - but it always be the range in so-called "Comfort" mode. The car instrument display actually shows range according to the mode the car is in. I normally drive in "Eco-pro". There's another PID that gives a figure for each of the 4 modes my car has got. How do other vehicles handle this? I'd like to show users all the ranges, and then put the range in the current mode into the standard metric v.b.range.est And I don't think I understand exactly the difference between "est", "ideal", and "full". My best guess for how to make them work: "est" is the figure the car gives up - either that "comfort mode" number or the number for the current mode "ideal": my best idea for how to get this is the WLTP range for the car's battery capacity scaled by the SOH% and the SOC% to come up with some sort of theoretically "possible" figure? "full": not sure - My idea would be to take the "est" figure from the car and scale it up to a range if the battery was full. Thanks, Steve

3 4

Hologram SIM card NOT included anymore
by Michael Balzer 18 Dec '20

18 Dec '20

Mark, Fasttech have changed the OVMS kits to NOT include the Hologram SIM card anymore. I don't know why and when they did so, but by this we now are lying to users in all our descriptions. This applies to our project websites as well as to Glyn's shop. Do you know the background? Is this temporary? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 6

Apple push notifications no longer working
by Michael Balzer 17 Dec '20

17 Dec '20

Mark, a user informed me he no longer gets any push notifications to iOS. Looking into the logs, it seems the initial connect to the gateway fails in a way the perl code does not handle. I've found this in the Apple forums: https://developer.apple.com/forums/thread/667248 It seems the protocol we use has been deprecated, but it should continue to work until March. Do you see a similar effect on your server? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 7

Detecting dead CAN bus - stop polling etc
by Steve Davies 15 Dec '20

15 Dec '20

Hi, I notice that my OVMS is sending poll requests but the OBD on my car is apparently off / non-responsive (but the 12v power on the OBD is obviously still there since the OVMS is running... OVMS logs: E (4672161) can: can1: intr=16491786 rxpkt=2794 txpkt=12 errflags=0x8040d9 rxerr=0 txerr=128 rxovr=0 txovr=107 txdelay=30 wdgreset=0 errreset=0 "txovr" - overrun? I guess? And I saw that txdelay climb from 0 to 30 after a reboot and as packets queued up for sending. I also see I'm not receiving any frames - the car normally sends a steady stream of idle or keep-alives or something - so from that I take it the BDC is off. "can can1 status" is showing that interrupts are still being received but no packets. When I did turn on the car it sent a stream of those frames. OVMS I think dumped a backlog, then a message about overflow started streaming by and then the OVMS rebooted. So it seems important that I stop sending polls in this situation (and perhaps flush the outbound queue?). Perhaps I can just watch what's coming in and if I haven't seen any packets arrive for some seconds I should stop polling and if possible flush pending transmits. Can start again when something turns up. Can I find an example as to how to do something like this? I guess I could manipulate the poll state, but for me it seems like this is actually a lower level thing since the canbus is actually dead and no polls can be done. At the moment the blocked transmits seem to pile up in the queue and we end up sending many at once when the link comes back. I found an argument "maxqueuewait" in the canbus calls (like Write) but it defaults to 0 which I guess is forever. So for me it does make sense that polls should have a maxqueuewait that is less than the poll interval. Or is there a well established way to deal with this? Thanks, Steve On Sun, 13 Dec 2020 at 20:47, Michael Balzer <dexter(a)expeedo.de> wrote: > 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(a)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(a)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(a)lists.openvehicles.com >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> > > _______________________________________________ > 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(a)lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev >

2 1