NefMoto

I have a K-box RS4 (http://gm.mainframe.no/pics/rs4/rs4.jpg) with AZR engine code.
There are no definitions posted for this particular kind of ECU here, but from binary comparison I can see it is close to H-Box and H-Box is close to M-Box.

I want to start tuning my car, and also develop a set of base tunes as well, from which to start working on other cars in the future.

So I was thinking what the best approach would be.
I could try to find all the maps in K-Box through binary analysis, and then use it as base, or alternatively I could try to transfer as much existing stuff as possible to M-Box. To basically make a factory M-Box RS4 tune. This appeals to me more.
I am not at all new to tuning, but I am new to ME7.

From looking at the materials available, the obvious maps to transfer seem to be:
* MLHFM, KFKHFM, MLOFS - HFM linearization
* KRKTE, TVUB, FKKVS, TEMIN - Fuel supply
* KFMIRL - Drivers wish
* LDRXN, KFLDHBN, KFDLULS, DSOLFS, KFTARX, KFLDRL - Boost control
* KFLDIMX, LDIATA, LDRQ0S, LDRQ1ST, KFLDRQ2 - Boost PID
* KFZW, KFZW2 - Ignition timing
* KRFKLN, KRALH, KRANH, DWKRMSN, KFFLLDE, KRDWA, KFLAMKRL - Knock control
* NMAX, Rev limit, also need to tune the one based on Oil temp sensor.
* KFMIOP, KFMIZUOF, TMNSMN, TANSMN - Torque limiting
* NLLM, NFSM, KFMRES, KFMRESK - Idle
* KVB, FKVA - Consumption display

I guess I could write a program that will compare all the different maps between each other, and do this all automatically. But this is assuming that all the maps are the same dimension in the first place...

Did I miss anything obvious?
I guess there are not a lot of people with RS4's on here, as I did not really find much when searching for "RS4"...

There is a tool on here that does exactly that.

http://nefariousmotorsports.com/forum/index.php/topic,493.0.html

Cool, open source as well.
Saves me the trouble.

I guess it will still be a lot of work to get my RS4 to M-Box though...

Decided to write my own tool, since I needed to do something specific.
I will post source...

I wanted to re-use Nyet's stuff, but (really, no offense!) it was quite messy, and hard to re-use, so I ended up rolling my own .kp parser, while using nyet's as a reference (thank you!).
I then compared RS4 F box and S4 G box.

There are about 500 maps, which are present in one .kp, but not the other.
There are 119 maps, which have changes to their structure (axis size).
Finally, there are 833 maps with changed calibration data.
So, the automatic comparison has been done, everything else will have to be pretty much done by hand :/
At least it's about 4x less work now.

The output of the tool is attached. If anyone wants to help, feel free to :)

Nice job! Which version of WinOls is your .KP parser compatible with?

Dunno, I used nyet's .kp's from his SVN.
If you give me a .kp I can try to parse it.

Subscribing.  I am very interested in an M-box version of the RS4 bin even in stock from.  I have an APR stage 3 S4 which uses RS4 MAF and injectors so it'd be a great starting place for tuning.

Awesome work and +rep!

OK. Here's a bunch from V1.5. Cheers.

Doesn't parse it out of the box. I can post the source if you want to try to make it work.

There is already a Stage 3 M-Box posted by Tony on here. All you need is to change 2 maps and a constant for the MAF and then a couple of constants and maps for the injectors.

Yea. Its completely different. I started on later versions and gave up..

BTW i'm not surprised (or offended) you didn't use my source :) its a huge mess.

Biggest problem with the source is that you don't seem to use an IDE. That'd make a lot of things better.
I've attached my zipped source to the post, you can have a look through it if you like.
It's not perfect, but I would not call it a mess. Should be quite readable as well.

Thanks for testing prj.

Ridiculous. Real projects don't use ide's. The build system can't be kept under revision control.

You are trolling right?
If not, I'll be happy to explain and prove you completely wrong, but IDE and the build system are not connected at all most of the time.

I'm a senior java dev fyi.

As a c/c++ guy its always driven me crazy that you can't build dependency information for java sources. And ant is a mess. I see no good reason why an IDE would help anything. The code is a mess, period. An IDE wouldn't help it.

Dependency information? Maven does that or Ant in conjunction with Ivy.
Ant is no more a mess than a shell script. It's just an alternative for a shell script.

So yes, you can have dependency information for Java libraries, the entire world does that all the time.
Also, the IDE and the build system are not connected together.

You are stating these things as facts, even though they are not true - know thy tools.
Anyway, this discussion has no place on this forum. Sorry for slightly criticizing your work.

My main concern about an IDE was that your code was not formatted/organized to conventions, so it made it hard to read, but if not for your code, I'd have to code it from scratch. This would probably take me quite a bit more time than the 6 hours it took to put this together with your stuff as reference, so thanks for that, your code was useful.

I'm open to suggestions. What formatting changes would an IDE fix?

Also, I'd welcome patches (or a whole new repo) for both an ant/ivy build system, or maven system. Like I said, I'm a c/c++ guy who uses makefiles, and rarely uses windows to do any building, since cmd.exe is a joke, and cygwin is a fat bloated slow mess.

Also, I'd like to extend it to be able to output the "new" (xml) format xdfs.

Please consider putting your source under github or something similar so I can take a look.

Will do soon.
Also, I made an XDF XML writer before in Java.

I think we can take large chunks of that and re-use it.

I got it generating XDF XML's now.
I need to make it generate tables for axes as well and link them to the tables.

Everything else works.
It also makes a single jar using this: http://code.google.com/p/onejar-maven-plugin/ (http://code.google.com/p/onejar-maven-plugin/)

I'll try to finish this tomorrow, and will post the source up. I'll lack folder support at start, so that'll have to be done as well...
I don't want to post something completely half baked that does not work properly, it at least needs to take a .kp and output a usable .xdf from it.
I am thinking to just output the .xdf to stdout and let users redirect it to wherever they want.

It wouldn't be really doing anything that your parser isn't doing now though, aside from having perhaps a refactored codebase, which is not really all that relevant.

Don't forget to swap axis for tables with >256 columns... tuner pro still crashes on those..

I know, don't worry :)

Probably should make a separate thread for it, but:
https://github.com/prj/me7-tools (https://github.com/prj/me7-tools)

mvn install (or mvn package) to build it. You need Maven 3.
one jar plugin will tell you where it has generated the jar, just run with java -jar path/to/jar path/to/kpfile.

This stuff is pretty basic atm, it needs folder support, all the axes need to go into one category in tuner pro, it doesn't really support inverse stuff, doesn't support non-eprom stuff etc.
But it generates an XML XDF, and from here it's just some polishing to do, as the basic framework is in place.

dope thread.  subscribed.

I'll try to add folder support tonight.
But so far not bad for 2 days work :P

Thanks!

Looking forwards to checking it out (pun intended) time permitting.

A few other features from my program you might want to look into

1) CSV output of tables
2) feature to read in a binary to generate max/min values for CSV output so you can compare various values from different boxes (e.g. KRKTE from RS4 vs S4 etc)

I don't really want to rewrite your whole tool.
I'm not going to add CSV support, I have no need for it personally, and it'd take a bunch of my time.
It's open source though, so if you want to re-use my code, you always can. Or I can give you committer if you want to try working on this as well.

As for comparing values - that little compare program I made does that for me and outputs the differences.
I'll have to go through every change it found manually and learn about everything anyway. I can speak German fluently, so that helps.

I'm very familiar with tuning, older motronics, ASM, etc (more than 100 cars tuned at this point), but I am just starting with ME7.
So I am just developing the tools I need. Because this forum has a wealth of knowledge, I feel it is correct to contribute back, and not do this quietly.

Btw, another thought...
Since we have the English funktionsrahmen for ME7.3, and some acronym definitions, what about including a filter on parsing the map pack, and then looking up the map names in a sort of dictionary file?

So we could have an English dictionary file, and any map ID's that match it, would automatically be translated?

no need, ill just make another github repo and send pull requests for stuff i think you might find useful.

I've been meaning to separate out the mesim tool from ecuxplot anyway. This would be a good excuse.


helllll yea. thank you. btw im looking forwards to learning how to properly architect java projects from you (again, since im a c/c++ guy). hopefully you'll be kind enough to mentor me (at least with the maven/ant stuff). I have a TON of questions about dependency based building, and ant/maven still don't seem to do what (for example) gcc -M does

I think Maven should do most of of the dependency stuff you'd need.
Just need to use it more I guess. It's all pretty daunting at start.

I do C/C++ myself as well, but I am not as good at it as I am at Java. I don't see the use of trying to enforce the habits of one language on another though.
The majority of the world is pretty happy with using Maven. If you check my project you can see an example where I have separated out the module for parsing the map pack, which is not executable by itself (it's just a library) and added another module, which depends on the map pack parser and actually generates an executable jar that emits XDF from the parsed map pack data.
In a broad way of thinking a maven module project can be something like the gcc -M that you are used to, but it is different as well.

I also used JAXB for XML generation, instead of printing strings or DOM. Maybe something of interest as well.
You could easily make a CSV creating module, which depends on my map pack parser for example. Though, I would need to set up a repository for it, if you wanted to do it separately outside the multi-module project, so that it can pull it down automatically.

Anyway, you could indeed use my codebase as an excuse to separate ecuxplot from the rest of the stuff.

Oh and as for setting up Java projects. Take a look at my code, it should give an example of how to do all this.
Most of the config files (pom.xml) are auto generated by the IDE though, there's very little work done by hand.

at risk of going far off topic, we have a hard and fast rule here at work: nothing autogenerated ever gets checked into SCM... too hard to maintain merges/branches etc.

this is part of the reason i'm wary of IDEs... they become a requirement to doing anything with the project.

isn't there another way to generate the maven configs? or perhaps a command line utility that can be written to parse some other *human editable* meta config file that can be stored in scm?

Uhm, the IDE just makes creating the maven configs easier, but you can do the same via maven archetype generation.
It's still meant to be written and modified by hand though, it's not an auto generated file per-se.
And yes, it's pretty obvious that you don't check in auto-generated files into SCM... Don't worry, you could say I've been doing this Java stuff for a few years :)

The pom's are very much human editable config files, they define the project, and they should be in SCM.
Here is a short getting-started maven tutorial:
http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html (http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html)
Here is a longer one:
http://maven.apache.org/guides/getting-started/index.html (http://maven.apache.org/guides/getting-started/index.html)
And here is the pom reference manual:
http://maven.apache.org/pom.html (http://maven.apache.org/pom.html)

No I understand that the maven configs are supposed to be human editable; you just implied (or I thought you did) that the only "true" source for a config file should be an IDE..

No, not at all.
The IDE is a convenience tool, the project must build from the command line when checked out from SCM.

Btw, I use Visual Studio for C++, does that make me the antichrist? :D
Sorry.

Added folder support, but it's pretty useless since TunerPro only supports labels up to 100'th category and only supports 255 categories in total.
So I just put all the axes into Category 255 and if the map pack contains more than 254 categories, I just don't put them in the XDF.
Perhaps should ask on the TunerPro forums if Mark wants to support more than 255 categories.

Also, I attached a binary to this post, if anyone wants to try out the generator.
All you need to do is download it, then run: and it will dump the xdf to stdout.
If you want it into a file, run it like this:

Oh yea, here's the attachment..

LOL. I have no religious bias for one IDE over another because I universally hate all of them, so no, saying "Eclipse" wouldn't change my opinion of your choice of IDEs :)

@prj
Maybe it would be beneficial to start a new thread for your XDF generator. I bet a lot of people are missing this because of the title!

I agree, will do.