ecuEdit v2.4 - ECU Tuning & Logging solution

[calvinc]

It's imho, bc you always skip my question about openness of ecu descriptions in ecuExplorer

what would you like to know about ecuExplorer? if its the .dat file definitions then they are attached.

serious professional tool can't be free

so then linux is not serious and not free? what about OpenOffice.org? what about NSIS? what about asterisk?

Serious free tool smell utopian communism.

maybe there are just others that think differently to you? it seems like your motivation for contributing does not match the ethos of what openecu.org was started for.

calvin.

[epifan]

It's imho, bc you always skip my question about openness of ecu descriptions in ecuExplorer

what would you like to know about ecuExplorer? if its the .dat file definitions then they are attached.

ok So, I'm not expected that would be secret in that time BTW, dat-file looks very advanced

serious professional tool can't be free

so then linux is not serious and not free? what about OpenOffice.org? what about NSIS? what about asterisk?

I'm talking about "ecu-tuning" range of tools.
Linux, openoffice and etc are not end-tools that may be used easy and directly in commercial purpose, like ECU-tuning.

Serious free tool smell utopian communism.

maybe there are just others that think differently to you? it seems like your motivation for contributing does not match the ethos of what openecu.org was started for.

OMG May be you exclude me from openecu mebership for that? Or may be you a little different uderstand the ethos of openecu.org? Why I'm must use made-up rules? I'm help someone of openecu community - that's a goal. At the last of 3 month ecuEdit was only one map editor and map describer on openecu...
P.S. Users are decide what they wants.

[calvinc]

Linux, openoffice and etc are not end-tools that may be used easy and directly in commercial purpose, like ECU-tuning.

i think this is where our differences are...

does it matter to you if people use ecuedit to tune customers' car and make money whilst they use your software for free?

personally i'm not bothered if people make money off using tari software. my software doesnt tell them what fuel, timing, boost values to use. it doesnt tell them how to fix mapping problems. therefore i see it that the money they make is reward for their experience in engine tuning. and the more people that use the tari software the bigger support base it will get and hopefully grow into a great product.

calvin.

[New2Scoobs]

the more people that use the tari software the bigger support base it will get and hopefully grow into a great product.

calvin.

No question! It's a great product right now.

ECUEdit is also a great product - I appreciate having the use of both.

And not to forget anyone - Openport is a great cable too!

[Jeramie]

P.S. Lets wait until Calvin release they ecuExplorer with map edit support... may be this release would not be free

any and all TARI software will forever be free!

this is not a race or game. i do this because i want free tools to be available for our community. maybe your motives are different?

calvin.

Clavinc has the right idea, this is "open source".

[ahains]

There is plenty of room in the world for open source, closed source for free, and closed source for pay software to coexist happily

In my opinion, the "hard" part was done by Colby in getting us a flashing kernel (the cable didn't hurt either).
Everything else is just straightforward software.
I'm not trying to discount the large amount of time & effort put into the tools that are currently available, but given enough time I could realistically write a similar program with my mediocre coding skills, but a flashing kernel is outside of what a normal joe like myself could realistically produce.

Since I greatly favor free, I would certainly choose to use free solutions for logging, map editing, log analysis, and possible autotune (not sure if I would trust an app for this, I might prefer to do this myself). Many other folks are willing to pay a reasonable price for a perhaps more integrated/flashy/extra-goodness solution.
IMHO, there is nothing wrong with selling software if folks are willing to pay for it

[epifan]

new ecuEdit v1.2.0.43beta
- support little endian and big endian numeric representation
- some bug fixes and improvement

Add <default_reverse_bytes value="True"/> tag in <config> tag to change ecuEdit for work with big-endian numeric representation.

Download ecuEdit v1.2.0.43beta

[epifan]

new ecuEdit v1.2.0.45beta
- increment axis in 2D maps
- data captions in 1D maps
- const axis in 2D maps
- some bug fixes and improvement

Download ecuEdit v1.2.0.45beta

Increment axis may be defined by 2 ways
1. We have start value at some offset and increment value at another offset: just include in <rows> tag attribute inc_data_offset="#offset"
2. We have start value at some offset and some increment constant value: include in <rows> tag attribute inc_value="64"

If attribute inc_value exists in <rows> tag and value <> 0 then this is 2nd way else this is 1st way.

const axis in 2D and data captions in 1D does't support yet in map description editor.

1D captions XML example:

Code: Select all

<map name="Rev Limit" type="1">
   <data count="2" offset="#297a2" power="2" format="%.0f" func_2val="toRPM()" func_val2="" caption="RPM" color_dir="0">
      <captions><value>on</value><value>off</value></captions>
   </data>
</map>


2D const axis example:

Code: Select all

<map name="Sample 2d" type="2">
   <rows count="2" format="%.0f" caption="numbers">
      <value>1</value><value>2</value>
   </rows>
   ...
</map>


[NeverLies]

Thanks ! Just tested it on 8 bits 2D axis definition and works fine

[Kha0S]

Thanks ! Just tested it on 8 bits 2D axis definition and works fine

Same here... I also used your 0x10000/[2 byte] setup and it seems to work perfectly when using it as a "fixed" increment value in ecuEdit.

I've created a fully up-to-date A4SG900C XML with lots of maps... I'll upload it shortly.

/Andrew

[epifan]

new ecuEdit v1.2.0.46beta
- convert functions for Increment value (func_2inc, func_inc2 attributes in <rows> tag)
- support EcuID in diffrent ECUs with same size (EVO9 32-bit ECU and Subaru DBW 32-bit ECU)


Download ecuEdit v1.2.0.46beta

Extended ECU descriptions in <config> tag:

Code: Select all

<ecu_desc file_size="#30000" name="Subaru 16bit ECU">
   <map_id offset="#00200" length="8"/>
   <region offset="#00209" length="2"/>
</ecu_desc>
<ecu_desc file_size="#40000" name="EVO 16bit ECU">
   <map_id offset="#3FFFA" length="6"/>
   <region offset="#00000" length="0"/>
</ecu_desc>
<ecu_desc file_size="#80000" name="Subaru 32bit ECU">
   <map_id offset="#02000" length="8"/>
   <region offset="#0200B" length="2"/>
</ecu_desc>
<ecu_desc file_size="#80000" name="EVO 32bit ECU">
   <map_id offset="#3FFFA" length="6"/>
   <region offset="#00000" length="0"/>
</ecu_desc>


[crispyduck]

epifan, this is great stuff your doing here and most useful.

Not sure if anyone else has suggested this yet but .... it would be really useful if you could provide an 'export to csv' format for the maps that you've described. This could work in one or more of the following ways:

1. Export to CSV of all maps that you've described (perhaps create separate files with the name of the map). This would be a top-level menu option.

2. From the map view window where you see the table and graph, you might want to export that map to CSV. Menu option from within the map view window.

3. Lastly, when you select one or more elements from the table in the map view window, this highlights the associated graph. It would be good if you could copy the current selection to the clipboard in a CSV formatted way so that this could be pasted dirrectly onto MS Excel or OpenOffice. The copy would also copy the associated table axis info as well, in addition to the data items selected.

All the above would support those people doing custom graph analysis.

In fact going further again, I'm only doing this so I can get a 'map differences graph'. For example this would provide a 3D graph of the differences between a stock and modified Low Det Fuel map. Given that maps can be based on different axis scales, this difference graph would have to perform any interpolation of values as required.

I'm sure this would be a useful map analysis feature. Anyone else agree?

Anyway, keep up the great work,
-Steve.

[cboles]

I've been thinking of adding ratiometric differencing down the road, but I hadn't really thought about the axis scaling problem. It goes beyond interpolation since the end values of the two maps may be different. I guess one could extrapolate as well to produce values beyond the ends of a given map for the purposes of comparison, but it only make sense to extrapolate in the same way the ECU actually does, which may be map dependent.

Colby

[crispyduck]

Colby,

The ratiometric differencing would be really useful. Regarding the 'ends of the map' issue. I'm simply comparing the max load values that are common between the two maps under comparison. As you've said you'll need something more complicated when you get to the ends of the map.

If your interested I've attached an extract from a spreadsheet I'm trying to do to graphically visualise the differences between my stock and PPP maps. I've only done the Low Det Map so far, but its highlighted that at high revs and low load the 'modified' map takes just over three points of the AFR when compared to 'standard' map. It also shows, that as you might expect, it adds more fuel between 2000-3600 RPM when under higher load.

It's only when you (well me anyway) see things this way then you can spot potential issues.
-Steve.

[epifan]

new ecuEdit v1.2.0.47beta
- Log Viewer support logs overlay (shifting, hiding)
- Copy map to Windows clipboard in HTML-format (Excel direct paste support)

Download ecuEdit v1.2.0.47beta