- OvmsDev - Open Vehicles

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

Re: [Ovmsdev] Changing Existing Functionalities
by Derek Caudwell 14 Dec '20

14 Dec '20

I envisage following a robust testing process outside of the main repo being a bit more difficult with the Leaf because of the quite substantial changes in the can bus framework/messages over the years. A change that works for more recent years but not for prior years is not always easy to spot, also improvements/additions of metrics may only work on a particular year unless another dev with a prior year implements and tests them. Without a group of Leaf devs or testers across the various years that can be called upon to test prior to putting through a PR to main I expect future changes will stay in Leaf devs repos untested for other MYs, as there is no particular reason for others to jump in and test the code to confirm compatibility. PR487 will be a good test case to see if the approach proposed can work in practice.

2 1

Re: [Ovmsdev] Changing Existing Functionalities
by Derek Caudwell 13 Dec '20

13 Dec '20

Hi Michael, Thanks for clarifying, until then I had been using "edge" on the basis that is where other devs would pick up on any issues with other models, so that issues got resolved before "eap" where they go out to a wider test community. Jaunius (@mjkapkan), and other Leaf devs I suggest circulating the repo that can be pulled from for testing on this mailing list before it goes to the master PR, or is there a way to notify others through github? Kind regards Derek (@drc38)

2 1

Changing Existing Functionalities
by jaunius＠gmx.com 12 Dec '20

12 Dec '20

Hi, Already several times there have been instances where functionalities or existing metrics are changed and merged without reviews from previous developers. This leads to additional time of rolling back the changes when often the changes brake something for different model year cars. In turn this leads to more time spent on rolling back the changes and etc. Do we have some kind of guidlines to avoid this? Kind regards, Jaunius Sent using the GMX mail app

2 1