I would like to know, if there is already a public available logger/software that is able to log 996 DME above 20 Hz while gathering more than 20-30 values per sample and being complete free which one you select. In fact you can log everything which is in the DME's memory.

There were always some rumors I noticed from this forum, but never really saw it or at least some examples.
I decided to make such a tool public for free, if there is some demand for it, AND someone to maintain and support it (e.g. through a thread in here) as I do not have the time to be check this forum regulary.

It is not such a nice GUI like durametric, but in this case it's an advantage when being alone in the car to only hit ENTER with a config file.

The tool only needs a computer (with some experience it could be done even on a mac) and a simple china K-Line interface for 5 bucks.
the single downside is that you need to initially patch the flash mem of the DME to make it work.

 

Hi... I'd be interested in working with you on it.

I am a 20+ year software engineer and I think it would be interesting to work on something like this.

PM me or let me know here if you're interested and we can talk.

 

I would suspect that many would be interested, what exactly is the patch doing to the DME? I had always thought the OBD protocol limited data exchange, will this patch effect normal loggers?

 

so I can assume there is none of public?

the patch is enabling a kwp2000 subroutine allowing code to be injected in the DME that is overtaking the raw serial communication for that session only (np to OBD it). therefore no further OBD protocol overheads are bothering. the limit is only the serial interface hardware, which means even for 57kbps/baud there is a lot room to get logging data like eg 50Hz with 40 word wide parameters = only 4000 baud.

I pm'ed mxracer already.

 

So if I understand correctly, you're bypassing the OBDII restrictions and writing straight to the port? Is the data still formatted as OBDII? Does this have any effect on the CPU, i.e. it has enough cycles and isn't dropping anything? I know it's a RTOS but am not real familiar with it, just want to make sure the CPU doesn't get bogged or skip something important lol.

So far as I know there's NO public tool to log faster than the OBDII protocol which is actually a little slow IMO. Something faster would sure be welcomed I'd think! A quickie Java gui to setup the config file for the logger might be nice and perhaps something to easily patch the DME and I would think people would be all over it. Is the code Windows based? If you're moving enough data I think Windows can sometimes get interrupt tied but this doesn't sound quite that fast?

Sadly not a developer but I understand the issue and do requirements development for software type things and have tuned standalones. I WELL understand the issues with the OBDII slow data rate! I'd love to see a way to do realtime changes next if anyone has worked that. Flashing every change seems like a real pain to someone who's been spoiled with a standalone I'm moving to a standalone soon but I know many don't want to, this could be a very nice tool. Thanks for offering to share, hopefully people will recognize the potential and pick it up!

 

RS38, take a look at this thread.

Specs may be there somewhere. The one essential thing needed from the logger is individual cylinder ignition pull values. The data's there but Durametric can't get it out in an understandable mode.
I wish I could help you but unfortunately I'm technically challenged in that area of expertice...

 

I'll answer in the order of Q:

Yes. I may need to admit that I did not write this tool, I adopted it to 996T Porsche. Sadly it does not work with 997+
No. The logging stream contains only raw logging data as requested, this makes the overhead nearly zero, compared to ReadData by LocalIdentifier even in block chunks*.
(No.)Of course it has certain impact, but less than normal OBD2 (->KWP2000 Read Data by Local Identifier which the correct name what Durametric does*) has. If you like, you can also log the current DME CPU cycles in percent. I did that beforehand and even at highest revs it does not get close to 100%.

pete linked to the tool I obviously had in mind, which may be similar but seems restricted to 20 given engine values.
I do not know if they reach the 60Hz by a KWP function or by injecting code, also there is not hint on Kevins website if they still sell it or quit support.

I don't think Java is a good idea, as many users don't have the runtime installed and hating all these updates and security issues.
There is of course a lot of hand work to be done if you want to start from scratch or modify my configs. You need the complete .A2L from your DME with all RAM adresses to assign the wanted values.

as I mentioned before the data rate is no problem even for the slowest Win95 laptop with youngtimer PentiumPro 4000 bps or 57kbps is the transfer speed of modems in the 90s....

*the DME supports a maximum of 8 values for each so called dynamicallyDefinedLocalIdentifier

 

Ah, so each of the various DME might have different memory address? Sounds like you had to parse a good bit for a starting point on your configuration?

I mentioned Java because it's crossplatform and not too bad to develop with. It's had its security issues but IMO it's worth dedicating a cheap laptop to the car

Breaking the previous rate issues is awesome, slow data stinks. That you can do this with CPU to spare is terrific. I hope that others can move this forward for sure, there should be some interest!

 

I supply this to some of my bigger turbo customers. MOST versions of US software are covered floor higher speed RAM logging.

 

Subscribing...

 

Tony, would this be available without the tune?

 

I know that tool!

 

No, unforntuately not. To log ram data on the 996 (high speed) a code change, not just a tuning change needs to be made. Basically the tool will only work on cars running my software and not even all of them.

 

Oukkidoukki.

 

in fact it seems Tony provides sth. very similar. The patch I mentioned is indeed in the code segment of the DME enabling the upload of the memory reader subroutine.
I did logging the knock voltage of each cylinder as well, as it gives a slightly better feeling of how close you are to the knocking angles. Did you also experience a single cylinder to always send higher knock voltages than the others and have an explanation in mind?
Here is an example after inserting the log data into excel an examining a WOT run. this sample was logged with 40 Hz and roughly 50-60 values per sample already hiding some less important.
When you narrow down your concerns to certain parts of your tune (PID fine tuning, knock, shifting, Rev-limiter, fueling) you limit of course the full set of possible samples (>700) to below 100.