Jump to content

Steve Davies

Members
  • Posts

    19
  • Joined

  • Last visited

  • Days Won

    3

Steve Davies last won the day on March 2

Steve Davies had the most liked content!

Reputation

6 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, GPS elevation datum is sometimes not that accurate. The height value that my OVMS box comes up with when I'm parked at home varies by say 5 meters. So: is it better to feet this height figure to ABRP with the API, or is it better to leave it out and allow ABRP to use its own number that comes I assume from map data?
  2. Hi, My project to add BMW i3 support to OpenVehicles' OVMS box is going along quite well. Here's a snapshot of metrics that I'm collecting at this point (I removed the OVMS "system" ones): v.b.12v.current -6.48A v.b.12v.voltage 14.57V v.b.12v.voltage.alert v.b.12v.voltage.ref 12.6V v.b.c.temp v.b.c.temp.alert v.b.c.temp.dev.max v.b.c.temp.max v.b.c.temp.min v.b.c.voltage v.b.c.voltage.alert v.b.c.voltage.dev.max v.b.c.voltage.max v.b.c.voltage.min v.b.cac 121.54Ah v.b.consumption 0Wh/km v.b.coulomb.recd v.b.coulomb.recd.total v.b.coulomb.used v.b.coulomb.used.total v.b.current 0.72A v.b.energy.recd v.b.energy.recd.total v.b.energy.used -978.297kWh v.b.energy.used.total v.b.health Excellent v.b.p.level.avg 93.83% v.b.p.level.max 94.53% v.b.p.level.min 93.23% v.b.p.level.stddev v.b.p.temp.avg 21.72°C v.b.p.temp.max 22°C v.b.p.temp.min 21°C v.b.p.temp.stddev v.b.p.temp.stddev.max v.b.p.voltage.avg 4.1868V v.b.p.voltage.max 4.189V v.b.p.voltage.min 4.185V v.b.p.voltage.stddev v.b.p.voltage.stddev.max v.b.power 0.285kW v.b.range.est 250km v.b.range.full 250km v.b.range.ideal 250km v.b.soc 100% v.b.soh 96% v.b.temp 21.72°C v.b.voltage 401.93V v.c.charging no v.c.climit 3.2A v.c.current 0A v.c.duration.full v.c.duration.range v.c.duration.soc v.c.efficiency 0% v.c.kwh v.c.limit.range v.c.limit.soc v.c.mode v.c.pilot yes v.c.power v.c.state done v.c.substate v.c.temp 22.7916°C v.c.time 0Sec v.c.timermode v.c.timerstart v.c.type v.c.voltage 0V v.d.cp yes v.d.fl no v.d.fr no v.d.hood no v.d.rl no v.d.rr no v.d.trunk no v.e.alarm v.e.aux12v v.e.awake yes v.e.c.config v.e.c.login v.e.cabinfan v.e.cabinintake v.e.cabinsetpoint v.e.cabintemp v.e.cabinvent v.e.charging12v yes v.e.cooling v.e.drivemode v.e.drivetime 0Sec v.e.footbrake v.e.gear 0 v.e.handbrake v.e.headlights v.e.heating v.e.hvac v.e.locked yes v.e.on no v.e.parktime 1059Sec v.e.regenbrake v.e.temp 20.5°C v.e.throttle v.e.valet v.i.efficiency v.i.power v.i.temp 35.0064°C v.m.rpm 0 v.m.temp 21.4344°C v.p.acceleration v.p.altitude 10.6m v.p.direction 0° v.p.gpshdop 0.9 v.p.gpslock yes v.p.gpsmode AN v.p.gpsspeed 0km/h v.p.latitude -34.xxx v.p.location Home v.p.longitude 18.xxx v.p.odometer 14534km v.p.satcount 9 v.p.speed 0km/h v.p.trip v.tp.fl.p v.tp.fl.t v.tp.fr.p v.tp.fr.t v.tp.rl.p v.tp.rl.t v.tp.rr.p v.tp.rr.t v.type I3 v.vin xi3.s.pollermode 1 xi3.v.b.p.ocv.avg 4.1898V xi3.v.b.p.ocv.max 4.192V xi3.v.b.p.ocv.min 4.188V xi3.v.b.range.bc 250km xi3.v.b.range.comfort 250km xi3.v.b.range.ecopro 253km xi3.v.b.range.ecoproplus 262km xi3.v.b.soc.actual 93.2% xi3.v.b.soc.actual.highlimit 93.3% xi3.v.b.soc.actual.lowlimit 10.5% xi3.v.c.chargecablecapacity 32A xi3.v.c.chargeledstate 0 xi3.v.c.chargeplugstatus Connected xi3.v.c.current.dc 0A xi3.v.c.current.dc.limit 1.8A xi3.v.c.current.dc.maxlimit 16A xi3.v.c.current.phase1 0A xi3.v.c.current.phase2 0A xi3.v.c.current.phase3 0A xi3.v.c.db.plugconnected no xi3.v.c.dc.chargevoltage 0V xi3.v.c.dc.contactorstatus 0 xi3.v.c.dc.controlsignals 0 xi3.v.c.deratingreasons 0 xi3.v.c.error 0 xi3.v.c.failsafetriggers 0 xi3.v.c.interruptionreasons 0 xi3.v.c.pilotsignal 6A xi3.v.c.readytocharge yes xi3.v.c.voltage.dc 402.4V xi3.v.c.voltage.dc.limit 420V xi3.v.c.voltage.phase1 0V xi3.v.c.voltage.phase2 0V xi3.v.c.voltage.phase3 0V xi3.v.d.chargeport.dc no xi3.v.e.obdtraffic yes xi3.v.gps_speed 0km/h xi3.v.wheel1_speed 0km/h xi3.v.wheel2_speed 0km/h xi3.v.wheel3_speed 0km/h xi3.v.wheel4_speed 0km/h xi3.v.wheel_speed 0km/h A few I need to debug (energy used -977kWh - well that would be nice!) I need to test 3-phase and DC charging. If possible get the TPMS tyre pressure info. And work on the remaining metrics - the ones above with no values. My main remaining problem is to try to get data while the car is charging - it turns off the OBD gateway. There are hints for other cars that show some tricks that might work. To stay on topic OVMS can feed ABRP and its nice that the box is dedicated so always up and running and providing info on the SOC etc. As you can see OVMS captures much more info which is of interest to anyone who really wants to know what is going on with their car.
  3. Sure. So you are seeing a reply sent in two frames. The returned value is 0xfffffe44. The first 2 bytes are in the first reply (after the 62DD69 which is the extended PID being sent in the reply) ie that is the FFFF. And the second 2 bytes are in the second reply after the 21 - ie FE44. This is actually a signed long (32 bit) integer. It's in what is called 2s complement format. You can tell that its a negative number because it is larger than 0x80000000. If you ask your calculator to turn that into decimal it will probably say 4294966852 - that is what you get it you treat it as unsigned. But to get the real number do 0xfffffe44 - 0x100000000 (or in decimal 4294966852 - 4294967296 = -444. So the value is -4,44A. For signed short (16 bit) values the idea is the same, except that numbers >= 0x8000 are negative and to get the true negative value you need to subtract 65536. Not sure if signed 8 bit values are used but for that 0x00 to 0x7F are 0 to +127 and 0x80 to 0xFF are -128 to -1. Regards,
  4. I’ve starred adding support for i3 to OVMS - first few metrics are being captured and over the next few weeks I’m gonna try get it to a reasonable state. OVMS can feed ABRP
  5. Hi, Thanks for the suggestion, I'm making some progress with understanding the i3 OBD2 setup and I'm looking to add support to OVMS (openvehicles.com) which would provide a dedicated feed from a dedicated box in the car. So I'm using Electrified but long term hoping to be able to use OVMS.
  6. If I try to run ABRP in landscape on my Android tablet this is what I get: Description: Replace this text As you can see, the map is centred on the middle of the screen, but on this tablet the charge chart takes up almost half of the screen. Would it be possble to notice that the chart etc are open like this and move the current car position to the middle of the part that is visible? Would work so much better. Other options might be a more formal split screen with the journey data on the left and the map on the right. Thanks, Steve
  7. Hi, I'm making reasonable progress in understanding the i3 PIDs with help from the decompiled .PRG files from inside Deep OBD and by looking at Bluetooth traces in Wireshark. 22 D1 07: Returns current speed (STAT_GESCHWINDIGKEIT_WERT - Speed Value) 22 DD BC: Returns state of charge (22 DD C4 also state of charge - one is the displayed one and the other I think is the absolute SOC) 22 63 35: Returns 2 part reply - second part (the 607 F1 21 part) contains the battery State of Health in percent 22 DD 68: Returns high voltage battery voltage in 1/100th of a volt (DD B4 seems to return similar as above) 22 DD 69: 2 part reply: 607 F1 21 part contains the current high voltage battery and a 2s complement signal 16 bit value in 1/100th of an amp. -ve is discharging. 22 DD C0: 2 part reply containing 3 battery temps - is it three sensors, or a low/high/average? 22 F1 90: 4 part reply containing the 17 digit vin with each byte returned as 2 hex digits, eg 30 for "0", 39 for "9". 22 DE 86: 3 part reply - in the first part is the AC charge voltage in volts. There are more values in the reply but I don't know what they mean 22 DE 87: 2 part reply - in the first part is the AC current in 1/10ths of an amp. There are more values in the reply but I don't know what they mean 22 D1 12: reply has 2 temp values (STAT_A_TEMP_ANZEIGE_WERT (display) and STAT_A_TEMP_ROHWERT_WERT (raw)) - real temp is (value / 2 - 40). External temp I think 22 42 0C: 2 part reply which has what looks like range in the various driving modes. I have an i3s and get 4 numbers that look credibly like range in the 4 modes (but which mode are we in? Don't know where to get that) Still trying to understand this one : 22 DE 84: "AE_BETRIEBSZUSTAND_SLE" (Operating condition?) returns 4 parts but don't know what the values mean - more experiments needed Still looking for mileage, range.
  8. No - The crashes were with navigating using the app The issue with exporting to Excel was a different problem.
  9. Hi @Fridgeir, Yes - I see that in the prg files there are "jobs" defined which are in the file in "BEST/1" - the decompiler renders them in assembler. From reading around this code is apparently compiled from BEST/2 code that I don't have of course. What I see is that many pids are read using a job STATUS_LESEN, commented "Reading one or more statuses". So this is the simple case that I've been looking at. I took a quick look at the job SVK_LESEN - it's defined with some assembler code which I find is code in something called BEST/1. It's compiled BEST/2 apparently though I don't have the original high level source code. But for me I need to look how far I need to go since most attributes I asked deep_obd to fetch - and it was many - are retrieved with the STATUS_LESEN job: I guess I should look at the INITIALISIERUNG jobs for the ECUs since you are alluding to initialisation steps. But at the moment I'm thinking to modify Deep OBD to post values to my MQTT broker and then store there or forward on to ABRP and other tools. Since it can already handle all this stuff. Or to have a look at OVMS and see if it can use EDIABAS library. It's not promising since that runs on ESP32 so to get the .net stuff running on it won't be simple. This has been a very interesting day spent unpacking this stuff.
  10. OK - a first pass to unravel Deep OBD. ArgString: 'ARG;HV_SPANNUNG_BATTERIE' executeJob('sme_i1.prg'): 'STATUS_LESEN' (Send): 83 07 F1 22 DD B4 2E Send SF ELM send SPACE ELM data mode terminated ELM CAN send: '070322DDB4000000' ELM CAN rec: '607F1037F2278' Rec SF Received length: 3 (Resp): 83 F1 07 7F 22 78 94 NR78(07) added ELM CAN rec: '607F10562DDB49CF1' Rec SF Received length: 5 (Resp): 85 F1 07 62 DD B4 9C F1 FD NR78(07) removed Deep ODB contains a sme_i1.prg file (amongst others for other ECUs). I passed it through a "decompiler" called BESTDIS that I found which turned it into something readable. In the decompiled prg file I find: TBEG "SG_FUNKTIONEN" HEAD "ARG", "ID", "RESULTNAME", "INFO", "EINHEIT", "LABEL", "L/H", "DATENTYP", "NAME", "MUL", "DIV", "ADD", "SG_ADR", "SERVICE", "ARG_TABELLE", "RES_TABELLE" ... LINE "HV_SPANNUNG_BATTERIE", "0xDDB4", "STAT_HV_SPANNUNG_BATT_WERT", "Batteriespannung hinter den Sch<FC>tzen, unabh<E4>ngig vom Sch<FC>tzzustand", "V", "-", "High", "unsigned int", "-", "1.0", "100.0", "0.0", "-", "22", "-", "-" ... So we see the 0xDDB4 which is labelled "ID" here and is sent by Deep OBD in the CAN request. Its "unsigned int" and the final value is result = value * 1 / 100 + 0. 0x9CF1 = 40177 40177 * 1 / 100 + 0 = 401.77V which is what Deep OBD displayed.
  11. Looks like VGATE OBD / Bluetooth adapter has ELM327 https://www.elmelectronics.com/wp-content/uploads/2016/07/ELM327DSF.pdf Or maybe it is just a reimplementation since ads for the VGATE iCar2 says it has an ARM processor? There is lots of info in the data sheet that I still need to read. I also grabbed the initialisation commands from Deep OBD's log: Date: 2020-11-07 13:03:00 ArgString: 'SVK_AKTUELL' executeJob('sme_i1.prg'): 'SVK_LESEN' executeJob('sme_i1.prg'): 'INITIALISIERUNG' Device connected: True ELM CMD send: 'ATD' - factory default ELM CMD rec: '^MOK^M>' ELM CMD send: 'ATE0' - don't echo ELM CMD rec: 'ATE0^MOK^M>' ELM CMD send: 'ATPP2COFF' - Default "Protocol B (USER1) CAN options" ELM CMD rec: 'OK^M>' ELM CMD send: 'ATSH6F1' - Set header to 0x6F1 ELM CMD rec: 'OK^M>' ELM CMD send: 'ATCF600' ELM CMD rec: 'OK^M>' ELM CMD send: 'ATCM700' - ATCF600 + ATCM700 = filter to receive only ids 6xx ELM CMD rec: 'OK^M>' ELM CMD send: 'ATPBC001' - ATPB C0 01 - not documented? ELM CMD rec: 'OK^M>' ELM CMD send: 'ATSPB' - Use USER1 CAN 11 bit ids, 125kbps ELM CMD rec: 'OK^M>' ELM CMD send: 'ATAT0' - Disable adaptive timing ELM CMD rec: 'OK^M>' ELM CMD send: 'ATSTFF' - Wait up to 255*4msec = ~ 1 sec for replies ELM CMD rec: 'OK^M>' ELM CMD send: 'ATAL' - Allow long messages ELM CMD rec: 'OK^M>' ELM CMD send: 'ATH1' - Replies capture additional header bits ELM CMD rec: 'OK^M>' ELM CMD send: 'ATS0' - Don't put spaces between bytes ELM CMD rec: 'OK^M>' ELM CMD send: 'ATL0' - No LF after CR ELM CMD rec: 'OK^M>' ELM CMD send: 'ATCSM0' - Not sure? ATCS maybe (CAN status counts) but where is the reply? ELM CMD rec: 'OK^M>' ELM CMD send: 'ATCTM5' - Not documented in the ELM327 datasheet ELM CMD rec: 'OK^M>' ELM CMD send: 'ATJE' - use JE1939 ELM data format (automatic conversion to little endian) ELM CMD rec: 'OK^M>' ELM CMD send: 'AT@1' - Display the device information ELM CMD rec: 'OBDII to RS232 Interpreter^M>' ELM ID: 'OBDII to RS232 Interpreter^M>' ELM CMD send: 'AT#1' - Undocumented; seems the adapter didn't make much of it. ELM CMD rec: '?^M>' ELM Manufacturer: '?^M>' - From this log message it seems AT#1 is expected to return manufacturer. ELM full transport: False Deep ODB is on github so this is helpful to understand the full log. Here's the logs around Deep OBD's where it seems to requesting "HV_SPANNUNG_BATTERIE" (HV battery voltage) ArgString: 'ARG;HV_SPANNUNG_BATTERIE' executeJob('sme_i1.prg'): 'STATUS_LESEN' (Send): 83 07 F1 22 DD B4 2E Send SF ELM send SPACE ELM data mode terminated ELM CAN send: '070322DDB4000000' ELM CAN rec: '607F1037F2278' Rec SF Received length: 3 (Resp): 83 F1 07 7F 22 78 94 NR78(07) added ELM CAN rec: '607F10562DDB49D12' Rec SF Received length: 5 (Resp): 85 F1 07 62 DD B4 9D 12 1F NR78(07) removed The battery was around 400 volts. 0x9D12 is 40223 decimal so I'm guessing that is in centivolts and so it is 402.23V and the last 0x1F in the reply is a checksum or similar (ATH1 does tell the ELM327 to send the full reply message and the data sheet makes reference to a checksum byte). I think what I will do next is to try to have a look deeper at Deep OBD since all this stuff is parameterised in a db and see what it reveals. One approach is to modify Deep OBD to send measured data to an MQTT server - useful for me to get it into OpenenergyMonitor - but then it is easy to send on to ABRP or elsewhere.
  12. No- my decoding of AT SH 6F1 and the AT CF / AT SF isn't right. I'm just trying to understand properly how those 11 bits are laid out to see that 6F1 means and the 6xx filter.
  13. So as I understand it Electrified and other OBD2 apps are talking using serial over bluetooth to the LM327 in the adapter, and it is the LM327 that is making the OBD2 requests and reading replies. LM327 datasheet is here: https://pdf1.alldatasheet.com/datasheet-pdf/view/197403/ELM/ELM327.html (amongst other places). Hilariously they reached to the 80s for inspiration and use Hayes "AT" command approach. These are to configure the LM327 and are not passed over to the OBD2 interface. With reference to the data sheet the init string proposed decodes as follows: AT D - factory settings AT E0 - no character echo (same as Hayes) AT PP 2C OFF - Sets configuration for CAN protocol B to factory default AT SH 6F1 - Sets OBD2 message header bits - 11 bits in our case. 110 1111 0001 - followup with what this means AT CF 600 - CAN message filter - 110 0000 0000 AT CM 700 - CAN message mask - 111 0000 0000 --> read together this means receive only messages with the top three bits set to 110 (6) --> which appears to be "mode" 6 messages, --> ie "Test results, other component/system monitoring (Test results, oxygen sensor monitoring for CAN only)" AT PB C0 01 - PB not documented in my data sheet? AT SPB - SPB not documented AT AT0 - Disable adaptive timing AT ST FF - Wait up to 255 * 4ms = ~ 1sec for a response to a request AT AL - Allow long messages AT H1 - Show ALL bytes of replies AT S0 - Not documented AT L0 - No LF after CR I will have a go now to do some captures from my car and see what I discover. @Fridgeir I have Electrified but am getting lockup problems. My first prize would be to get the Open Vehicle Monitoring System (https://www.openvehicles.com/) supporting the i3 since that is an all in one permanently installed solution.
  14. No, I can't access "My Drives" from Canary - it doesn't find them. I was using Firefox. I think it has to do with a stale token for the API and logging out and in again seems to sort it out. Steve
  15. Hi, I'm using ABRP Android in my i3 along with the Electrified app for live info. I used it now for a trip of about 130 kms. How does ABRP know my trip has ended? Can I tell it "I've arrived" and have it stop? As you can see here there is 20 minutes of "stationary" at the end of the trip in "My trips". This messes up the stats - average speed and the like. My i3 leaves the ODB2 power on for a while and Electrified was running so I suppose this is the root - do I have to kill Electrified to stop it report in? Thanks, Elbow
×
×
  • Create New...