RomRaider

I had seen that post. It's definitely interested. If it was something that were to be implemented within RR it would also need to support all the current flashing methods for other and older ROMs. I'm not sure how much work that would add to the diesel project as it's really focused on diesel and 32bit ECU's.
I don't have any diesel ECU's to experiment with but I do have a spare petro (non-CAN) ECU for testing that I have yet to try. This would certainly be a good way to get more intimate with the ECU. I'll think about what I could assist with as I'd like to have a reason to better understand the ECU's operation.

The main trick is how to download a bootloader into ecu RAM and to start the code loaded.
After that you may use your own or any other SH bootloader for ecu reflash.

They seem to have embedded gnuplot:

http://www.gnuplot.info/

Its open source and GPL (I think) so probably an appropriate choice for RR. gnuplot has been around
forever and is not written in java, so you would have to write some interfacing code.

While the diffing tools in RR are nice, I find it nicer to actually visualize the diffs or more than one table
on a 3D graph at the same time. So I've been cut and pasting the tables out of RR and using gnuplot
to manually compare tables.

Dan

Can you post a couple screen shots of that compare method?

Sure, but I'll do even better. Give me a bit of time and I'll prepare some gnuplot input files if you like and you can generate them yourself as well as see what gnuplot is about. Might help you decide if it really is the right direction. I'm not 100% sure but don't think it has an in process (callable) binary API so you will have to learn to use pipes or just use input files and system calls (which is sort of ugly).

Basically what I like to do is two things:

• Plot two or more 2D maps on the same 3D plot. This is nice so you can see where they sit relative to each other on the same scale. It's also nice to see what the discretization differences are between the tables. The discretization of load vs rpm can differ from one rom to the next.
• Generate diffs of two roms and plotting the differences in 3D. Recall our interpolation discussion. Basically you compute the differences by interpolating the 2D data onto a 'shared' uniform discretization with an appropriate tabulation range based on the input discretization ranges. Or, another approach is to interpolate the table with a smaller range onto the one with the larger range and then compute the differences there.

Dan

Quick question: is "RamTune" analogous to live tuning of the device while driving? Is so, is the hold up on that something related to the device itself, or the architecture of RR? Excuse my noobness

The key issue has been the lack of capacity for coding the front end GUI (in Java I assume). Sounds like you might have some time to help out with this

Check out this post - the code for live tuning is already available, the GUI is the issue:

viewtopic.php?f=25&t=6539&start=15

OK, thanks!

I had a poke around that thread, and the source, and the app, and it would appear that the work required to implement this is relatively minor compared to what has already been done. Hence my interest.

I'll definitely help a bit to get things moving, if it turns out that RR is suitable for my purposes, but I can't promise huge involvement in it as I have way too many other responsibilities as it is leading my own project.

If the two threads that I started can be sorted out in the next few weeks, expect me to be poking around. I don't know if my poking will move things in the right direction for the existing users, but hopefully we can find a way to integrate both pieces of code together in harmony.

Fred.

There's one tiny tweak that would only take you guys a small bit amount of time and work towards integrating the airboy spreadsheet stuff into the logger. And that is on the maf tab, have it check the OL/CL status and if CL run as normal, and if OL use the wideband an commanded afr to get afr error. Then you can tune CL and OL in one swoop. You just easily already do that in a spreadsheet, BUT I like the output from the maf screen because it makes it easier to see while I'm logging if I hit every area I needed to. I use it the same way I would use a live histogram and cell hit counts in other software. I wish I could help out on the programming end, but I'm a mechanical guy who's dabbled enough in programming to know I should just stick to mathcad and mattlab.

After tackling the definition formatting and getting some new speed density patches out, I plan on finishing up a tab for 32bit speed density tuning. I've always wanted the other tools integrated as well.

A great first step for this would be to add functionality to live-interpolate certain maps while logging. Then we would need to build a dependency structure in the XML to ensure compensations and what not get picked up.

I feel like you are making this more complicated than it is. You would just need the code to create the afr error pid and the code to choose between graphing the afr error pid or the afr learning pid. All the other code for this should already be in use in the maf page. Again, I'm just a simpleton.

Indeed, that is a bit complex, but will ultimately provide you with more data without hosing up the logger.

That's a great point, I totally forgot about that shortfall. The best place to start would be to allow calculated parameters to derive from extended parameters to create things like WB AFR error. It would be easier to code in RR than interpolation as well.