Jump to content
Jason-ABRP

Decoding the i3's PIDs

By Jason-ABRP, in i3

Recommended Posts

PaulS

PaulS

Posted
Posted
On 2/1/2020 at 1:30 PM, rs38 said:

doesn't this one work?

"AT PB E1 01\nAT CRA 612\nAT SH 6F1\nAT FC SH 6F1\nAT FC SD 12 30 0F 02\nAT FC SM1\nAT CEA 12\nAT CM 600\nAT H1\nAT SP B\nAT BI\nAT AL\n"

If anyone has Torque Pro (I don't) and wants to give things a try, here's an initialisation sequence I've extracted from Deep OBD. 

"AT D\nAT E0\nAT PP 2C OFF\nAT SH 6F1\nAT CF 600\nAT CM 700\nAT PB C0 01\nAT SPB\nAT AT0\nAT ST FF\nAT AL\nAT H1\nAT S0\nAT L0\n"

I can't be sure it'll work for Torque, but I now have Deep OBD working and can log data to SD card. @Jason (ABRP) is there any way to use off-line data logs?

Link to comment
Share on other sites
jim3cantos

jim3cantos

Posted
Posted
On 3/9/2020 at 10:15 AM, gmytis said:

I think some German developers making an app with integrated ABRP. But it's not released yet.

https://www.goingelectric.de/forum/viewtopic.php?f=69&t=54309&sid=2fc2cdb9b3f111f60fdfcefc427860d6

 

App released for Android (in beta). Workaround for the Integration with ABRP: https://www.goingelectric.de/forum/viewtopic.php?p=1230975#p1230975

Screenshot_20200409-161654.png

Screenshot_20200409-161604.png

Screenshot_20200409-161405.png

  • Like 2
Link to comment
Share on other sites
Jacquet Daniel

Jacquet Daniel

Posted
Posted

Hi Jason, Daniel speaking,

I received my I3s, I installed the VGATE and I look the screen with details, but I have no link with ABRP and a message appear every time :

"Data could not be send to ABPR (end of input at caracter of 0)" and  "Data could not be sent to ABRP (unexpected end of stream on com.android.okhttp.Address@bc0b916f)"

Would you be so kind to help me.

Best regard Daniel

 

Link to comment
Share on other sites
jim3cantos

jim3cantos

Posted
Posted
On 4/12/2020 at 2:38 AM, Jason (ABRP) said:

I added instructions for this to the app, so you don't have to add it as a non-i3, let me know if you run into any issues with the ABRP side of the setup.

As I did the first integration with the workaround indicated above, it took me some time to find the option (Under settings (select "detailed view"- my car model - settings - show live data instructions) to integrate directly with Notified app when trying to repeat the integration steps with a second phone: 

image.png

@Jason (ABRP), may be split this thread in two (i3 PID, Notified app) could be a good idea...

 

Link to comment
Share on other sites
KillCoffee

KillCoffee

Posted
Posted

Hi guys, sorry if im reply to this old post. I am a Mini Cooper SE owner, im trying to extract data from OBD to send it to ABRP. I bought Autopi.io but I can't find the right protocol to connect the car and the autopi. how did you manage to connect and have replies from the car? I've seen someone is using a computer program.. what is it?

Link to comment
Share on other sites
jim3cantos

jim3cantos

Posted
Posted
2 minutes ago, KillCoffee said:

Hi guys, sorry if im reply to this old post. I am a Mini Cooper SE owner, im trying to extract data from OBD to send it to ABRP. I bought Autopi.io but I can't find the right protocol to connect the car and the autopi. how did you manage to connect and have replies from the car? I've seen someone is using a computer program.. what is it?

Take a look at electrified app. In the thread about the app in goingelectric.de forum, I read a few days ago that it works with the Mini Cooper SE.

Link to comment
Share on other sites
Steve Davies

Steve Davies

Posted
Posted
On 2/17/2020 at 10:32 AM, Fridgeir said:

be aware that you have to change parts of the init sequence for each control unit if you want to read out its data

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.

 

 

Link to comment
Share on other sites
Steve Davies

Steve Davies

Posted
Posted

 

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.

 

Link to comment
Share on other sites
Steve Davies

Steve Davies

Posted
Posted (edited)

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.

 

Edited by Steve Davies
Link to comment
Share on other sites
Steve Davies

Steve Davies

Posted
Posted
9 minutes ago, Fridgeir said:

it will be more difficult, if you receive answer with a lot of more data ?

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:

Quote

# Get jobs run out of the Deep OBD log file:
steve@maximus Log % grep '^executeJob' ifh.trc | awk '{ print $2 }' | sort | uniq -c | sort -nr
 557 'STATUS_LESEN'
  46 'SVK_LESEN'
  46 'HERSTELLINFO_LESEN'
  19 'INITIALISIERUNG'
  12 'STATUS_MESSWERTE_IBS'
  11 'STATUS_GWSZ_ANZEIGE'
  10 'SERIENNUMMER_LESEN'

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.

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Go to topic listing

Links

Contact Us

Bo - Lead Developer and Tesla owner: bo@abetterrouteplanner.com

Jason - New Car Models, Developer and Bolt owner : jason@abetterrouteplanner.com

Idreams - Forums Administrator, Forums Developer and Tesla owner : idreams@abetterrouteplanner.com

×
×
  • Create New...