Fuel Efficiency 0Hp Tune for the 5.0L...
21 - 39 of 39 Posts
Progress is slow. I’m spending most of my time learning how the ecu works and organizes data. I’m working on the hope that I might be able to build valid tunes out of factory xcals instead of using a bin file.
The number of parameters in this engine is staggering.
The number of parameters in this engine is staggering.
Last night, big break through... I was finally able to extract the itn list from the xcal. Next is to organize that, apply the map pack I have to it and then work on extracting the address list for the itns. This processing the xcal/bin is taking so much longer than trying to figure out the delete itself. Why couldn't I just be happy with badly overdriven turbos and a bunch of code blocking?!
Bit of a bigger update:
I'm on the third major rewrite of my editor. The problem:
I have one bin that actually works with the ez lynk autoagent 2.0 and the truck runs on it. This bin also was made from an original calibration as it has no vehicle details, recorded kilometers or whatever.
The WinOLS mappack I bought for the ISV comes with a bin, but it's a slightly different arrangement that produces a long list of errors. It's also interesting to note, that the bin that comes with the WinOLS map pack has mileage on it, which means it was taken from an ecu in a truck. 97,000km(mi?)
Initially I applied the map to the bin that works, but I believe I've mentioned it before, the maps do not perfectly line up. A number of parameters could be found manually, looking for a number of similar bytes in a line. That was not the case for all of them, especially the fault blocking table.
Now I am working off a new Nissan/Cummins .XCAL for my ecu part number. Ideally it will be possible to modify and support every ecu part number with a modifed xcal. I will need to do some more testing but it might also be possible to install the modified file with Nissan Consult.
I exported the WinOLS map pack to json because it has all the correct itn numbers for each parameter. My application can now read the table of contents and the address of every one of those itn's. The next big part will be assigning each map to each itn from the table of contents. Then extracting the data for each itn. That's where it starts getting murcky, as the conversions are not perfectly clear to me for the different data types that are stored in the ecm.
Once I can get the data out, I can document the engine and then learn the best way to modify the program. Another road block is that the winols map pack is aligned to one bin, with everything mapped to the locations in that bin and doesn't use the table of contents. As a result I don't have all of the itns for the axis data because the axis data is hard coded into the winols map pack.
This is both a ton of fun and absolutely frustrating, but I'm getting there.
I talked with ez lynk support and once I have some xcals I'm ready to try, they'll help me make sure they're setup right.
I'm on the third major rewrite of my editor. The problem:
I have one bin that actually works with the ez lynk autoagent 2.0 and the truck runs on it. This bin also was made from an original calibration as it has no vehicle details, recorded kilometers or whatever.
The WinOLS mappack I bought for the ISV comes with a bin, but it's a slightly different arrangement that produces a long list of errors. It's also interesting to note, that the bin that comes with the WinOLS map pack has mileage on it, which means it was taken from an ecu in a truck. 97,000km(mi?)
Initially I applied the map to the bin that works, but I believe I've mentioned it before, the maps do not perfectly line up. A number of parameters could be found manually, looking for a number of similar bytes in a line. That was not the case for all of them, especially the fault blocking table.
Now I am working off a new Nissan/Cummins .XCAL for my ecu part number. Ideally it will be possible to modify and support every ecu part number with a modifed xcal. I will need to do some more testing but it might also be possible to install the modified file with Nissan Consult.
I exported the WinOLS map pack to json because it has all the correct itn numbers for each parameter. My application can now read the table of contents and the address of every one of those itn's. The next big part will be assigning each map to each itn from the table of contents. Then extracting the data for each itn. That's where it starts getting murcky, as the conversions are not perfectly clear to me for the different data types that are stored in the ecm.
Once I can get the data out, I can document the engine and then learn the best way to modify the program. Another road block is that the winols map pack is aligned to one bin, with everything mapped to the locations in that bin and doesn't use the table of contents. As a result I don't have all of the itns for the axis data because the axis data is hard coded into the winols map pack.
This is both a ton of fun and absolutely frustrating, but I'm getting there.
I talked with ez lynk support and once I have some xcals I'm ready to try, they'll help me make sure they're setup right.
Oh my. I was just looking into something like this. Read your whole run so far. Impressive. I just got a used ezlynk in the mail today. Got it for 200 freedom dollars. I found your posts looking to see how I could get some bin and tcm files to try and tune a delete myself. I’ve got some experience with hptuners and uprev but NA applications. I’m more of a hardware guy when it comes to figuring out what is needed. (Currently working on a cost effective coolant reroute to completely bypass the EGR cooler on deleted trucks.) again. Awesome man this is how hotrodding should be. Keep up the good work. I’d pay you for your work for sure.
Hand calculated tank average, 10.97L/100km (~21us.mpg). Stock wheel/tire sizes, mixed driving but 50% or more on highway. I am constantly driving with an aim towards economy, but not hypermilling. I run with hvac off, but vent on so the ac compressor is not being cycled. The ac compressor uses ~1L/100km.
I'm having issues with extracting the different data points from the xcal, plus the realities of life has slowed this project down a bit. This engine certainly has the potential to be very efficient.
I'm having issues with extracting the different data points from the xcal, plus the realities of life has slowed this project down a bit. This engine certainly has the potential to be very efficient.
Today I successfully extracted 1,2 and 4 byte single datapoints from itns I have information for! Due to the way winols handles maps, all the axis data does not directly correspond. That’s going to be a pretty major uphill battle to extract tables.
I can see light at the end of the tunnel. I will eventually be able to make a profile editor for the ez lynk ecu editor, as well as directly editing thr xcal like I’m doing in my app so far.
I can see light at the end of the tunnel. I will eventually be able to make a profile editor for the ez lynk ecu editor, as well as directly editing thr xcal like I’m doing in my app so far.
I keep taking random parameters and comparing the results between the winols demo version I have, a hexeditor with the original xcal open and the results of my silly little application. Everything I have personally checked corresponds correctly between all three. Confidence is growing. I guess this part of the project has only been dragging on for two weeks, but the whole project to get better fuel economy extends a bit earlier than when this thread was started.
Something that is really important to me is somehow sharing this knowledge. We have rare trucks that are not made anymore, a unique engine that isn't made anymore and keeping knowledge like this behind a paywall seems wrong.
Any questions or suggestions on how to share this knowledge so others can use it would be greatly appreciated.
snippet from my git log!
Something that is really important to me is somehow sharing this knowledge. We have rare trucks that are not made anymore, a unique engine that isn't made anymore and keeping knowledge like this behind a paywall seems wrong.
Any questions or suggestions on how to share this knowledge so others can use it would be greatly appreciated.
snippet from my git log!
Code:
e678369 2 minutes ago NavyCuda (HEAD -> master, origin/master) OPEN Continuing work on extracting data from XCal
fb04abf 2 days ago NavyCuda OPEN Working on data type conversions...
c3edfc5 2 days ago NavyCuda YAY! Major breakthrough. Collecting some data from xcal
78cb731 4 days ago NavyCuda Fixed Table of Contents array indexing issue
6460629 4 days ago NavyCuda OPEN Major advancements. Search, and write methods added
fa25702 6 days ago NavyCuda OPEN Working on search methods. Verified basic cursor function
13e9a40 8 days ago NavyCuda OPEN Working on implimenting the new cursor.
96a582d 9 days ago NavyCuda OPEN Major rewrite...
64d7d7a 9 days ago NavyCuda OPEN Added loading progress percent. Started finding values
7fd8045 10 days ago NavyCuda OPEN Got comments working, now working on getting values
83e523d 10 days ago NavyCuda OPEN Major changes to how the itns and the index table interact
a26c129 10 days ago NavyCuda OPEN Working on Documenting the engine.
e3abf3f 12 days ago NavyCuda Starting to pull apart the WinOLS map pack. Some difficulties
2bff812 12 days ago NavyCuda YAY! Itn table and addresses successfully extracted
feb96df 13 days ago NavyCuda Got up to about where I was before...
aa128ed 13 days ago NavyCuda Got everything in place. some issues with git ignore, but that will clear up.
592e60f 13 days ago NavyCuda Set all the projects upToday, successfully have compiled a large list of itns from a number of ecfgs. I can't put any more time into it today, but this should really get me closer to filling out all of the missing itns from the xcal. There are ~19,000 parameters for the ISV, and my list is sitting at about 76,000 parameters, so I'm hoping I can get almost everything filled out nicely. I certainly have found the majority of the axis data I was missing.
So it's a bit more complicated than just finding the correct itn from a big list of itns pulled from the ecfgs.
Say for example on one engine the charge air pressure table is 10x10, but on another engine it's 10x14. Even though the itn number is the same, the purpose of the itn is the same, it doesn't correctly align with the data as its stored in the ecm. So now, I don't just have to search all the ecfgs for unique itn numbers, I need to get all of the itns and process them individually against the values that come out of the calibration to ensure that I use the right variant of an itn to build my tables.
my goodness what a can of worms this is.
Say for example on one engine the charge air pressure table is 10x10, but on another engine it's 10x14. Even though the itn number is the same, the purpose of the itn is the same, it doesn't correctly align with the data as its stored in the ecm. So now, I don't just have to search all the ecfgs for unique itn numbers, I need to get all of the itns and process them individually against the values that come out of the calibration to ensure that I use the right variant of an itn to build my tables.
my goodness what a can of worms this is.
I had to rebuild my xml model a few more times in order to read the ecfgs correctly. Now however I have the means to read a large number of ecfgs and store all the parameters individually. Xml parsing turned out to be rather difficult with the way data types are nested into the xml.
The calterm ecfg files are just xml documents. There is a compatibility header that tells the Cummins CalTerm software some details about the engine that the ecfg is supposed to work with. That information is also stored in the xcal and compared to the ecfg when it's loaded. Since I'm writing my own editor, that problem isn't a big deal.
My code is very messy right now and not optimized at all. Once the xcal and the winols map pack are loaded, my application uses about 400mb ram. Processing all the ecfgs I currently have available to me (only about 400mb worth) rocketed the ram usage to over 4gb. The resulting xml library of unique parameters is 47mb.
The calterm ecfg files are just xml documents. There is a compatibility header that tells the Cummins CalTerm software some details about the engine that the ecfg is supposed to work with. That information is also stored in the xcal and compared to the ecfg when it's loaded. Since I'm writing my own editor, that problem isn't a big deal.
My code is very messy right now and not optimized at all. Once the xcal and the winols map pack are loaded, my application uses about 400mb ram. Processing all the ecfgs I currently have available to me (only about 400mb worth) rocketed the ram usage to over 4gb. The resulting xml library of unique parameters is 47mb.
None of the tables are working yet, and the data is only coming out in hex... there is still a lot of work to do. I'm up to ~18,000 of the ~19,500 itns mapped.
This document is based off how Cummins CalTerm documents the engine, however the value is in hexadecimal instead of the human readable value. Also, the parameters are not separated by group or manager.
Edit to add: Some of the comments are so long that notepad automatically wraps them. Something like visual studio code does not force line wrapping.
This document is based off how Cummins CalTerm documents the engine, however the value is in hexadecimal instead of the human readable value. Also, the parameters are not separated by group or manager.
Edit to add: Some of the comments are so long that notepad automatically wraps them. Something like visual studio code does not force line wrapping.
My current project is learning how the WinOLS map pack stores the map information. The Cummins xml is very straight forward, because all the parameters are indexed by the xcal.
I decided that I didn't want to write to completely different methods for processing an itn from the winols map pack or from the engine parameters. So now when the winols map is applied to the itn, it is then converted into a cummins engine parameter.
Then when I'm processing the data I only have to write methods to handle the cummins engine parameters. This is important, because with the cummins xml I have a nice clean model that is easy to use for extracting the tables and data points. The winols stuff is tied to the bin it was made with.
I also started experimenting with calculating the offsets from the winols map pack for the different axes, so it looks like I'll be able to work backwards. I have the right name and description but the winols map pack doesn't store the itn number. However, what I can do is take the backwards offset, look for an empty itn that has the same starting address and byte length, then build an engine parameter for it.
My goodness. I mean, I'm having fun, but all I wanted is better fuel economy and now I'm writing an ecu editor for our trucks.
I decided that I didn't want to write to completely different methods for processing an itn from the winols map pack or from the engine parameters. So now when the winols map is applied to the itn, it is then converted into a cummins engine parameter.
Then when I'm processing the data I only have to write methods to handle the cummins engine parameters. This is important, because with the cummins xml I have a nice clean model that is easy to use for extracting the tables and data points. The winols stuff is tied to the bin it was made with.
I also started experimenting with calculating the offsets from the winols map pack for the different axes, so it looks like I'll be able to work backwards. I have the right name and description but the winols map pack doesn't store the itn number. However, what I can do is take the backwards offset, look for an empty itn that has the same starting address and byte length, then build an engine parameter for it.
My goodness. I mean, I'm having fun, but all I wanted is better fuel economy and now I'm writing an ecu editor for our trucks.
As is common for me while writing something, I realize that I've made such a mess getting to where I am that it's time to go back and re write things. So, I am technically starting from scratch, however I have lots of code that is reusable. This time I'm trying to do a better job of documenting and planning my development. One major issue is that I'm not a professional developer by any means. I'm self taught and this project should make obvious to anyone who has read every post... I just keep trying until I figure it out, even if I approach it from the wrong way and bash my head against the wall.
So the issue I keep having is a division of responsibilities for my objects and methods as well as generalizing as much code as possible because I repeat myself too much.
So, today, I have done no coding and have spend the last oh two or three hours building a loose flow chart of the relationship between the calibration, engine parameters, the stored engine parameter in the cummins econfig and a hint at the daunting task of converting the winols map to the ecfg parameter. it's really sad, seeing how few datapoints cummins needs and how many winols has, that the winols map pack is missing so much information.
So the issue I keep having is a division of responsibilities for my objects and methods as well as generalizing as much code as possible because I repeat myself too much.
So, today, I have done no coding and have spend the last oh two or three hours building a loose flow chart of the relationship between the calibration, engine parameters, the stored engine parameter in the cummins econfig and a hint at the daunting task of converting the winols map to the ecfg parameter. it's really sad, seeing how few datapoints cummins needs and how many winols has, that the winols map pack is missing so much information.
This is really... really scary for me...
I still have a long way to go, so it isn't much to look at but I'm going to leave all the code for this version of the editor out in the wild. There is no support offered, implied or even suggested. It's going to take a while to be any kind of useful, is mostly just a library with a console for testing. Eventually there will be a UI, but that's a long, long way down the road.
xcals, ecfgs, etc will not be included with the project and most be sourced on your own.
github.com
I still have a long way to go, so it isn't much to look at but I'm going to leave all the code for this version of the editor out in the wild. There is no support offered, implied or even suggested. It's going to take a while to be any kind of useful, is mostly just a library with a console for testing. Eventually there will be a UI, but that's a long, long way down the road.
xcals, ecfgs, etc will not be included with the project and most be sourced on your own.
GitHub - navycuda/CumminsEcmEditor: An experimental editor for the Cummins ecm calibrations.
An experimental editor for the Cummins ecm calibrations. - GitHub - navycuda/CumminsEcmEditor: An experimental editor for the Cummins ecm calibrations.
github.com
I'm slightly further ahead than I was before, while also being slightly further behind.
I have a much cleaner, more efficient way of producing the strings for documenting the engine parameters. I almost have a working method for generating the Y_Axis tables. Once that's done I'll be onto the more complicated Z tables.
Progress is slow, but it's still progress.
I have a much cleaner, more efficient way of producing the strings for documenting the engine parameters. I almost have a working method for generating the Y_Axis tables. Once that's done I'll be onto the more complicated Z tables.
Progress is slow, but it's still progress.
21 - 39 of 39 Posts
Join the discussion
