Added PID json file for MiniCooperSE electric #4
Conversation
The protocol "B" is unsure, could be 6 or 7 instead. "B" is entered because of the AT command "ATSPB" in the initialisation commands The equations Letters are also unsure : example : received data for 22DDBC (soc) to module 607 is : 607F1100962DDBC01A6607F12103E50091FFFF that is interpreted by me as : 607 F1 10 09 62 DD BC 01 A6 607 F1 21 03 E5 00 91 FF FF ? A B C D E F G H ? I J K L M N O P the actual SOC is found in the 01 A6 pair. In my interpretation that is G + H : 01A6 in hex equals 422 in decimal. Divide by 10 to get the SOC : 42.2% therefore the equation is (G*256+h)*0.1 if the 01 A6 pair is actually byte A and B the equation must be altered to (A*256+B)*0.1
Added PID json file for MiniCooperSE electric
|
Can you provide sample data for all the commands? Maybe also with the actual value. Then i can add some tests for these pids. We already have tests for the other vehicles to make sure we do not break anything in the commands. If we have real world data it makes it easier to verify the pid list before publishing it. |
|
As for the position chars... The data after the command is the data which is required. Will already write some tests to see if our current parser can deal with that format, maybe you can do some adjustments to the other commands meanwhile and provide some data so i can enhance the tests later on. |
|
Ok i can read 42.2% SoC from the supplied data above with adjusted chars to A and B. So it seems once the chars are corrected, we can add this fairly fast. Requires a new app version though as i needed to do some adjustments to the OBD response parser. |
|
here some more commands and responses
so the voltage equation should be INT16(A:B)*0.01 |
|
This one is a little more complicated i think because the reponse containss multiple 607 (ecu number). I think I remember that those responses were actually on a separate line sendATCommand("226335"); // SOH State Of Health so actually :
I don't have a clue what equation letter to give to the "00" and "64" bytes as they are on the second line. Perhaps C & D ?? |
Co-authored-by: Samuel Brucksch <SamuelBrucksch@users.noreply.github.com>
|
That one is a multi frame response i think. Multi frame messages normally have len 10 |
|
Ah thought so, sendATCommand("22DDC0"); // Battery temperatures (min, max, avg)
|
|
Looking good, i now added a custom protocolB as it seems to be more close to 7 but is a bit different. So we can leave it at protocol B. |
|
Do you also have a value for current? Maybe connect a charger, then you should get a stable negative value, that should be easy to confirm if it is correct (for example on 11kW and 355V you should see roughly -30A. |
|
For battery current : sendATCommand("22DD69"); // Battery Current Relevant data = 011A (from position 26, length 4 bytes) = Battery Current * 100 => 0x011A HEX = 282 dec = 2,82 Amps I will look for negative values but i think that the MSB of A is the plus or minus sign. Then the equation should be something like : |
|
Do you by change also have car speed? We use that to estimate if the car is charging, when speed is 0 and current is negative. Alternatively a boolean flag for is_charging would also work. |
Yes, but that is on a different ecu : 660 which is the KOMBI or instrument cluster the command to send is : 22D107 The response is 660F10562D1070000 and the speed is in 0.1 kph resolution value min is 0 value max is 154, the mini doesn't go faster ;) Getting the is_charging parameter by speed = 0 and current is negative is also how i do it :) But be carefull : when coming to a stop for a trafic light with regen (= charging) and eventually speed = 0 as well. So you need at least 2 consecutive samples of speed = 0 and current < 0 to get a more reliable is_charging = true |
|
Ok let's leave speed for now, we also have an estimation based on GPS speed. We can always enhance the commands later on if everything works. So now i have everything tested which is available here. Thanks for the data. I'll add this to the backend soon and then you can test it. |
awesome, thanks so much. Looking forward to testing. And if you need more values, PID etc just let me know. I'll setup an Arduino sketch where I can type in commands and see the responses in the serial monitor so I can record them, That makes it easier to test different commands |
I don't care, choose whatever you want |
|
Please send a mail to samuel@iternio.com with your apple ID so i can invite you to our test version. Also include the mail associated to your ABRP account so i can add the tester role to your account so you can test it, when it tis available. |
|
I pulled some values of the current while idle (not charging) and while charging : command = 22DD69 response while idle (discharging the battery) I think the current data is now FF 98 (*0.1 Amps) = -103 = -1.03 Amps while charging @ 1.8 kW (and still idling) now the current data is 00 00 01 38 = 312 = 3.12 Amps @ 400 Volt = 1.2 kW which seems correct So the current is positive while charging and negative while discharging the battery. So maybe the equation needs a minus sign in front. I don't exactly know how ABRP sees positive and negative current. Also the values are separated by spaces between the bytes. I don't know if that affects anything. I'll do a test where I issue all commands multiple times and log the responses. Maybe that helps in bench testing the parsing. |
|
Here is a complete dataset of the data that is now available in the json, I follow every step in the init section and now the output is a little different, no spaces and no ecu number any more. I guess some ATcommands you changed have done that :) I entered the 4 datacommands 5 times each and the responses are below : Attempting to connect to VGATE 22DDBC 22DD68 22DD69 226335 |
|
Yes charging needs to be negative and driving positive. |
charging needs to be negative and driving positive
Setting ATSTFF to ATST0F. ST is the timeout command. FF is a timeout period of 1024 msec which is far too long, the message comes almost instantly. setting the value to 0F instead of FF brings the timeout down to 64 msec which works fine (tested in my own iOs app). ATST00 also works but is slower. ATST01 (4 msec timeout is too short, no data is received)
|
Hi @remmie1972 Did you set ATCAF1 somewhere before when requesting the data? Could you please try the same command list with ATCAF0 as additional init command? |
|
Ok nevermind, i just implemented that notation as well... |
|
Still i'm wondering, sometimes you get different results for the same query: Do you know why it sometimes comes with |
|
And also that format is again different from what you initially showed: So this is a bit confusing now. Why are there so many different representations of the same data? Normally if the init sequence is always the same, the incoming data should also look the same. |
|
Hi Samuel, the colons appear when I do not use ATH1 (headers on) in the init commands. here's same examples switching between ATCAF0 / ATCAF1 (auto formatting ?) and ATH0 / ATH1 (headers on/off) and ATS0 / ATS1 (spaces on/off) `ATZ ELM327 v2.2 ATD OK ATE0 ATS0 ATCAF0 ATAL ATPBE101 ATSPB ATBI ATSH6F1 ATAT0 ATST0F ATCRA607 ATCEA07 ATFCSH6F1 ATFCSD07300800 ATFCSM1 22DDBC ATCAF1 22DDBC ATH1 22DDBC ATH0 22DDBC ATCAF0 22DDBC ATCAF1 22DDBC ATH1 22DDBC ATs1 22DDBC |
sorry for the confusion, that was me playing around with some of the settings. This one is with headers on (ATH1) and spaces on (ATS1). |
|
Can we somehow get rid of these additional messages: so that only the actual data bytes show up? (line 3 and 4 of the response) |
|
Do you prefer the output with colons (as the init sequence is now) or with the headers so the 607 ecu number is in the data? |
|
I don't care if the ECU is there or not, we don't use it. But it has to be consistent. We only use the ECU on multi frame messages that are not auto formatted, but with auto formatting we do not need it. What is confusing for me is, that even on single frames we get some data before, that is unexpected for me (at least i did not see it on a different car) The same command should always return the same structure. |
The 22DDBC is the command I typed and the response is the 7F2278 009 0:62DDBC01EB 1:03D40087FFFF I have no idea why the 7F2278 and the 009 are there.
I agree but it appears that BMW does something strange there. I will use the init structure as it is now and then issue the same command for lets say 20 times and maybe we can see a pattern. The data itself is the same but in the second response 7F2278 is added in front. |
|
Ok lets try this:
I think i can deal with the additional data in front, if i know the rest of the data is always the same format |
OK I think that is the following log. I noticed that when copying the data from the Arduino serial monitor to the GitHub comment windows the data gets additional line feeds. I'll attach a screenshot of the data seen on the serial monitor. I can see no distinct patter as to when the additional data in front appears and when not. the 22DDBC command is the command typed by me :
|
|
Yes i think that looks doable. Can you send me the whole command chain including init commands and everything again please? So i use the correct init sequence for our obd command list as well and can adjust the tests. You can also send the responses as mail if the formatting is off on github. |
|
I also noticed this morning that in the ABRP app the OBDBLE option for the Mini Cooper SE was active so I tried it. I could select the iOS-vlink module. and it gave me 3 green ok signs. the last one took a few seconds. However the data was not yet being imported. Now I guess I know why :) LOL. |
For reference on GitHub, these are 3 screenshots with :
|
|
Oh i forgot, we need to add attributions. Check https://github.com/iternio/ev-obd-pids/blob/main/jaguar/README.md for reference. You can add a README.md in the mini directory. |
|
Thanks for implementing this for the Mini Cooper SE ! Would that need a separate pull request from me or can you just copy the page to a BMW section. Or do you rather want to wait until the test with the Mini is done ? There are still some values that can be discovered :
|
|
We have the most important values, so we can work on the others later on if it is confirmed to be working. Internally we can map one file to multiple cars, so no need to copy over to other directories. |
|
I think i know where those additional bytes come from. Please check the ELM327 spec: So i think if we skip the You also have a command in there |
|
Hi Samuel, Unfortunately that does not work, it actually makes things worse. I mistyped the ATFCCSM1. It is not an automated sequence. I just type one after the other and see what happens. |
|
Ok...well it works now anyways, just wanted to avoid additional data to prevent possible bugs, but let's test this first... Will send you a mail when the test version is available. |
The protocol "B" is unsure, could be 6 or 7 instead. "B" is entered because of the AT command "ATSPB" in the initialisation commands
The equations Letters are also unsure : example : received data for 22DDBC (soc) to module 607 is : 607F1100962DDBC01A6607F12103E50091FFFF
that is interpreted by me as :
607 F1 10 09 62 DD BC 01 A6 607 F1 21 03 E5 00 91 FF FF
? A B C D E F G H ? I J K L M N O P
the actual SOC is found in the 01 A6 pair. In my interpretation that is G + H : 01A6 in hex equals 422 in decimal. Divide by 10 to get the SOC : 42.2%
therefore the equation is (G*256+h)0.1
if the 01 A6 pair is actually byte A and B the equation must be altered to (A256+B)*0.1