Pages: 1 [2] 3 4 5
Author Topic: Logging with KWP-2000 protocol  (Read 36961 times)
setzi62
Full Member
***

Karma: +126/-0
Offline Offline

Posts: 249


« Reply #15 on: November 11, 2010, 05:56:34 AM »

Just a crazy idea,  we could upload a function, and add it as a process ID for the ecu to complete and then end comms.  Our new function would then broadcast a set frame of preamble + addresss data we define (n addresses) + crc check when the k line is empty.   
Starting an own process/task on the ecu would be a hard job. Need to setup
a task table and code in ram and then find a way to start the task periodically.
Probably an alarm is free for this use. But conflicts with the running tasks that already
use the serial port could not be avoided.
What can be done is: you can load own code and table into the external ram and then
link it in by redirecting a pointer. So your code gets called whenever a message comes
in and works as an additional message handler for your own logging message.
The code can work on a table and collect all memory locations in one go.
Logged
setzi62
Full Member
***

Karma: +126/-0
Offline Offline

Posts: 249


« Reply #16 on: November 11, 2010, 06:03:55 AM »

On the ecu's I inspected only one memory section could be defined for reading with dynDefLI's.
Or I am too stupid to define multiple sections? Shouldn't it be done like this:
2C F0 04                            - clear
2C F0 03 01 10 38 00 00     - define 1st section
2C F0 03 02 10 38 10 00     - define 2nd section
21 F0                                 - read
And on some ECU's the readMemoryByAddress is NOT supported, even after
securityAccess & turning on debugSession. Seems like the list of different communication
implementations on ME7 is endless ...
So a "general" data logger most probably needs to support different methods
for reading the memory.
Logged
ArgDub
Full Member
***

Karma: +57/-1
Offline Offline

Posts: 203


« Reply #17 on: November 11, 2010, 11:17:11 AM »

Tony, seems that developer of ecux found a way to bypass the three entries restriction. I've just checked that it can pull at least 67 values (8-16bit mix at non consecutive address) with a single readDataByLocalIdentifier. Also, noted it doesn't use DynamicallyDeifineLocalIdentifier, it defines LocalIdentifier writing directly to ram.

It's funny that whatever baud rate you choose, it never change timing nor baud rate, so reading 67 values it achives 12 samples per second at default 10400 bauds, and 14 sps if you read one value.

Guillermo
Logged
ArgDub
Full Member
***

Karma: +57/-1
Offline Offline

Posts: 203


« Reply #18 on: November 11, 2010, 11:21:33 AM »

Forgot to add it uses development session.
Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +114/-4
Offline Offline

Posts: 1390


2001.5 Audi S4 Stage 3


« Reply #19 on: November 11, 2010, 12:37:10 PM »

Tony, seems that developer of ecux found a way to bypass the three entries restriction. I've just checked that it can pull at least 67 values (8-16bit mix at non consecutive address) with a single readDataByLocalIdentifier. Also, noted it doesn't use DynamicallyDeifineLocalIdentifier, it defines LocalIdentifier writing directly to ram.

It's funny that whatever baud rate you choose, it never change timing nor baud rate, so reading 67 values it achives 12 samples per second at default 10400 bauds, and 14 sps if you read one value.

Guillermo

Thanks for looking into that. The dynamically defined local identifier entries are stored in RAM, so it is possible you could use WriteMemoryByAddress and manually write them into RAM without using DynamicallyDefineLocalIdentifier. Writing the entires straight into RAM would allow you to bypass the three entry limit per local identifier. The three entry limit is only enfored when defining identifiers.

But this trick is even less portable across ECUs, because you need to find where the local identifier entries are stored and make sure to not to use RAM used by anything else. You could find the location of the local identifier entries by reading RAM, defining local identifiers, and reading RAM again. I am not sure how you can confirm how much RAM is free to use if you want to use more than the standard three entries per identifier. Also, by doing it this way you lose the ability to run in a Standard diagnostic session.

I am planning on releasing my data logger based on ReadMemoryByAddress before I work on trying any new techniques. But it's pretty cool to be hearing some new ideas on the subject. Grin
Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
setzi62
Full Member
***

Karma: +126/-0
Offline Offline

Posts: 249


« Reply #20 on: November 12, 2010, 03:02:10 AM »

Yeah, thanks for the information that you all gave in this thread, that was really what
I hoped to find. This presents again a good starting point for my own experiments  Wink

Guillermo, did you log the serial interface to find out what happens, and would you
share such a log?
Logged
ArgDub
Full Member
***

Karma: +57/-1
Offline Offline

Posts: 203


« Reply #21 on: November 12, 2010, 10:16:38 PM »

setzi, I would like to hear about those experiments Grin

Attached are two logs, first RPM and IAT were logged, in second 68 variables were logged. I wrote an explanatory note next to messages but there are many question marks for you guys.

Edit:
ECU 06A906032HS
« Last Edit: November 12, 2010, 10:19:48 PM by ArgDub » Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +114/-4
Offline Offline

Posts: 1390


2001.5 Audi S4 Stage 3


« Reply #22 on: November 14, 2010, 01:16:35 PM »

The first write of 8 bytes is manually defining a dynamically defined local identifier. The five writes of 61 bytes are all going to unused RAM regions. I believe this is manually writing the dynamically defined local identifier entries.
Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
setzi62
Full Member
***

Karma: +126/-0
Offline Offline

Posts: 249


« Reply #23 on: November 15, 2010, 09:02:54 AM »

It's like Tony said, the data table of the local identifier (describing ram address +
number of bytes for each variable to be read) is written into unused ram and
the data pointer in the local identifier table is redirected to the new data table.
For the 68 variables log the communication speed should have been 57600 baud.
I did some small updates in the excel file comments about this.

At all, the used logging method is a nice trick to get over some limits of the ecu functionality.

Just for curiosity: when playing with dynDefLI's, I saw two things:
- could use 3 memory regions per ddli only if the first two regions each just contain one byte.
- with a Cbox image for the definition of a ddli the memory address had to be
  given in swapped order (low byte first, the middle and finally last high byte), strange??
Logged
prj
Hero Member
*****

Karma: +269/-16
Offline Offline

Posts: 3375


« Reply #24 on: January 20, 2013, 05:51:51 AM »

Using some specs and some data in this thread I implemented a data logger.

I wanted to try readByMemoryAddress, as that seems a bit more portable, and hoped to use it on a few other ECU's as well.
However, as I see it:
1. readMemoryByAddress only takes a single address and then a length in bytes, I can not give it an array of addresses.
2. The maximum update rate I got out of my ECU on my bench is about 17hz using this method.

So unless I am doing something wrong, it is my understanding that I have to read out whole big blocks of RAM.
If I read two different blocks I will get about 8-9 samples per second.
No idea if I ever get a reply to this, as it seems that most people who have understanding of these things have left this forum for greener pastures, but here is to trying...
Logged
prj
Hero Member
*****

Karma: +269/-16
Offline Offline

Posts: 3375


« Reply #25 on: January 20, 2013, 06:12:25 AM »

I think I missed the accessTimingParameters service...
Will try it, and probably increase the sample rate Smiley
Logged
prj
Hero Member
*****

Karma: +269/-16
Offline Offline

Posts: 3375


« Reply #26 on: January 20, 2013, 11:18:05 AM »

Yup, that allowed me to get 50hz...
So if I use the dynamic identifier hack I can get 50hz with arbitrary addresses, but this is ECU specific and we already have ME7Logger for that.
ReadMemoryByAddress should work on the diesel ECU's as well, so I need to get some of them and test.
« Last Edit: January 20, 2013, 11:19:50 AM by prj » Logged
nyet
Administrator
Hero Member
*****

Karma: +385/-44
Offline Offline

Posts: 8829


WWW
« Reply #27 on: January 20, 2013, 10:17:05 PM »

No idea if I ever get a reply to this, as it seems that most people who have understanding of these things have left this forum for greener pastures, but here is to trying...

I am definitely interested. In particular, i'd also like to try to reproduce ME7L functionality (even if it isn't general!) so it can be built as some sort of portable library for use in other platforms, as well as being able to redirect the output somewhere useful (like a domain socket to a local process, or tcp socket to a remote host).

Do you have sample code anywhere in your repo?

I might try to rewrite it in C

i goddamn hate vb with a passion.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
prj
Hero Member
*****

Karma: +269/-16
Offline Offline

Posts: 3375


« Reply #28 on: January 21, 2013, 06:17:02 AM »

Pretty sure ME7L is already written in C.
It's not hard to get the logging working, but for ME7 there is already ME7Logger and I am doing this mostly to get it to work on some Diesel ECU's, and maybe newer ECU's like MED9 and EDC16.
Not sure if they will work on K-Line or need a CAN interface though.
Logged
nyet
Administrator
Hero Member
*****

Karma: +385/-44
Offline Offline

Posts: 8829


WWW
« Reply #29 on: January 21, 2013, 02:49:17 PM »

Pretty sure ME7L is already written in C.

I'm pretty sure setzi isn't going to give me the source code Sad
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
Pages: 1 [2] 3 4 5
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.022 seconds with 16 queries. (Pretty URLs adds 0s, 0q)