Just wondering. No tuners local to me tune ecutek, but it would be nice to get a professional tune for my JDM version 7 motor without paying money for a license or hardware. I could trade my reflashed ecu for a stock one and even make a little money on the deal.

Because none of the OpenECU stuff does realtime tuning. Yet.

EcuTek doesn't offer realtime tuning either. I don't think that's the problem.

I think 1- there is a liability of use free 'unsupported' software. If something is wrong in the definition of the ROM and your car suffers damage because of it, I'm sure shops do not want that liability. 2- there is no protection of a tuner's work so I think that has dissuaded people from using it as well.

Mike

IMHO, the main problem is the knowing that when a customer shows up you won't be without a particular map defined that you need. I would hate to have a customer show up for a scheduled time only to tell them, "sorry, the ignition correction map for your car hasn't been found yet, I can't tune your car". There are dozens if not hundreds of ECU models out there.

Second is knowing the definitions you DO have are correct. It would really suck to tune a car and something like a misdefined table axis cause problems in the middle of tuning the car. These problems could be extremely hard to troubleshoot.

Other than that, I'd hope tuners are at least downloading the software and using it, at least familiarising themselves with it. I think the flashing itself is very reliable. There have been enough people reading and flashing for a while now to say that. I do expect things to improve over time, and hope those who choose not to tune with it now will change their minds later.

Right now, only the newest Ecutek stuff protects a tuners work from being read out anyway. And it also seems to permanently lock the ECU.

Right now they have tools that work well, and they know how to use them. They would have to learn the new stuff, and the good ones probably are now. Once they have a larger base, I am sure you will start to see it...

we are currently aquiring the parts and software.
However, we are going to have to learn a lot with it before we start doing customers cars. Our own cars will be test platforms.

I think you will find this a lot. COBB is probably really hating this right now.
Protune licenses are so darn expensive, we want to try open ecu first.

How much is a protuner license?

we are currently aquiring the parts and software.
However, we are going to have to learn a lot with it before we start doing customers cars. Our own cars will be test platforms.

I think you will find this a lot. COBB is probably really hating this right now.
Protune licenses are so darn expensive, we want to try open ecu first.

4500.

takes a long time to get that back. People charge around 500 -600 for a protune. But you have the cost of running the dyno, shop, fans, employees, etc.

reflashed a stock evo ecu. Car had exhaust, intake and a boost controller. got him 60whp and 65 ftlbs of torque. Currently enjoying the open ecu stuff.

Just wondering. No tuners local to me tune ecutek, but it would be nice to get a professional tune for my JDM version 7 motor without paying money for a license or hardware. I could trade my reflashed ecu for a stock one and even make a little money on the deal.

We are now able to tune over the internet via the EasyECU. Now anyone who lives far away can now be tuned by I-Speed USA.

Cheers,
Crawford Performance / I-Speed USA

Get the EasyECU and we will can it over the internet. So anyone that does not live near us can now be tuned by I-Speed USA.

If you have any questions please ask

Cheers,
Crawford Performance / I-Speed USA

Stop it... seriously... just stop. That's not what he asked. It's a blatant advertisement for EcuTek by you in a non-vendor forum. Map switching by EcuTek for $$$ more... :lol:

Get the EasyECU and we will can it over the internet. So anyone that does not live near us can now be tuned by I-Speed USA.

If you have any questions please ask

Cheers,
Crawford Performance / I-Speed USA

No **** cut it out.
The EasyECU is a crock. It has NO USER TUNING ability at all. Net tuning is the newest trick by more than one tuner. I would not net tune a car. Just not worth the risk. What if for some reason the "NET tune" overboosts and det to hell. But the owner of the car feels great power and never knows until the motor goes pop. What then?
I am sure the phone call would go something like:

TUNER: Hello you have reached YYYYYYY tuning, please leave a measage.
OWNER: WTF the map you sent me blew my motor.
TUNER: We got your message please call back at OUR convience.
OWNER: I have tried calling 5 times in the last week no one has gotten back to me.
TUNER: Sorry for the late response we have been very busy at the shop.
OWNER: Well WTF your map blew my motor. What are you going to do about it.
TUNER: Well you never sent a log so you are on your own.

TMS

I have had a few customers with the openecu on the dyno. It seems okay, not really great. It really does lack the ability to access all maps, but it is cost effective and gains can be had. I still charge the same per hour as tuning any other management.

I can honestly say that the ECUTek is still much better due to support and the ability to find and use all needed maps.

The issues I saw were mainly access to maps. But also the fact that I didn't have a selection of tuned maps I could trust make for a longer tune.

I have had a few customers with the openecu on the dyno. It seems okay, not really great. It really does lack the ability to access all maps, but it is cost effective and gains can be had. I still charge the same per hour as tuning any other management.

I can honestly say that the ECUTek is still much better due to support and the ability to find and use all needed maps.

The issues I saw were mainly access to maps. But also the fact that I didn't have a selection of tuned maps I could trust make for a longer tune.

Once you have YOUR base maps done the tuning time goes WAY down.
New tables are being released just about on a weekly basis.

TMS

It's hard to speak in general about the openecu tools as there are three different tuning programs out there that were developed separately: Enginuity, Ecuflash, and Ecuedit. All three use an xml database file, although with different formats, which include the definitions for each ecu revision. The software is only as good as the definition file and without a decent one, you can't do much for tuning.

Ecuflash and Ecuedit currently don't come with much, if any, support for Subarus out-of-the-box. For these two programs, most users use a program called Xmlwrite (not associated with Ecuflash or Ecuedit), which generates an xml file based on definitions that its creator "borrowed" from a major company's tuning software. I don't think that this company was too happy about this and probably put the hammer down on him as he's since removed his download links (although you can find it elsewhere). Ecuflash is free to use, but Ecuedit is shareware.

Enginuity has its own defintions and is free. The definitions are updated periodically and it always important to check for updates as they can occur in-between releases of the Enginuity software (I've seen users still using 2 month old definitions before). The capability of the definitions, as far as access to tables, is somewhere in-between Streettuner and Protuner/Ecutek. I think the capability is more than enough for the professional tuner to use with a typical tune. I've looked at many custom tunes, and rarely is anything changed other than what you currently have access to in Enginuity. Make sure you have changed your userlevel to 4 in the View menu or you will not have access to all the tables.

That being said, Enginuity (and the other openecu tools) are currently in beta status. So, bug and errors occur from time to time. As long as the professional tuners know what the values should be, they should be able to spot any inconsistencies in the definition file or program operation. I'm sure the early releases of Ecutek and Protuner were not bug free, so it shouldn't be that great of an issue, in most cases. The definitions have pretty comprehesive support for different revisions. If a customer comes in with a revision not supported, the tuner can download one of the many readily available stock roms and choose one that is compatible with the customer's car and supported in the definitions. There are a few gaps in support with the new 32bit ecus (namely 05 FXT, 06 LGT, 06 BajaT) but these are filling fast as users upload their stock rom to the Enginuity site to be added to the definitions.

Get the EasyECU and we will can it over the internet. So anyone that does not live near us can now be tuned by I-Speed USA.

If you have any questions please ask

Cheers,
Crawford Performance / I-Speed USA
Should i really trust you to tune my car if you can't manage anything resembling correct English?

well...IMHO, I had an accessport and got rid of it for the enginuity/ openECU stuff. same type of maps...car runs just as good if not better and its free! With the 500 I made back from seling the accessport, I bought the LC-1 XD kit for 340 and the tacrix cable for 100. Now I can safetly tune w/ enginuity for free!! Wayyy better IMO!!

Should i really trust you to tune my car if you can't manage anything resembling correct English?

I would say no, sorry for the rushed response, it has been updated. Anyways if you have any questions about the EasyECU just ask.

As for internet tuning, we have done this for about 5 years now. So to say this is a new service is completely incorrect. I would suggest anyone to do their own research before jumping to conclusions.

Cheers,
Crawford Performance / I-Speed USA

It's not that Internet Tuning is new... it's that EasyECU is a ripoff for what you get. I think everyone would gladly pay what tuners are asking for it if it had some user tuning capability in it like ST for the AP does. Switching maps that someone else created for you is useless to some people. I want to know what's in there... not just blindly trust someone that they have everything correct. Simple things like revlimit is sometimes set too high by some tuners. In the end, it doesn't matter... I want to see what's in my map before I put the damn thing on my car. Even if the car runs great, I still want to know what's in there. Not everyone will agree with this, but that's just me and I know there's others out there that want the same thing.

I never though I'd actually say this, but F EcuTek and go buy a Cobb AP with tuning software to boot if you don't want to use the free stuff. In my opinion the free stuff will have very limited support because no one and I mean NO ONE is working to put together a complete XML package for any of the tuning products out there. It's really a shame too because it could have given some people that can't afford the retail products something to use. I guess we'll see how badass EcuTek's products will be once the new Cobb AP comes out.... damn... I really didn't think I'd be saying that.

because no one and I mean NO ONE is working to put together a complete XML package for any of the tuning products out there. It's really a shame too because it could have given some people that can't afford the retail products something to use. I guess we'll see how badass EcuTek's products will be once the new Cobb AP comes out.... damn... I really didn't think I'd be saying that.
You keep saying no one has a complete xml package. Yet, Enginuity is a complete. You need to take a look at it if you haven't lately.

You keep saying no one has a complete xml package. Yet, Enginuity is a complete. You need to take a look at it if you haven't lately.

It's not complete. I'll bust out my ecuEdit and XML files and compare anyday. Simply put, you don't have every single table that's available with xmlwrite defs in Enginuity. (Example... you didn't have the gear dependant boost tables in your xmls until about what... a few days ago.) People using the xmlwrite defs have always had them.

I'm not trying to be ugly, I'm just pointing out my findings.

None of the currently available packages for tuning are complete. Don't take this personally, but ecuEdit is far more advanced in it's capabilities then Enginuity is. I don't care how you look at it... that program is way above everything else out there. However, it's lacking the def files and since no one (from the rumors I've heard) will EVER update xmlwrite all these apps that depend upon these defs will be left in the dark. There was plenty of time to solve these def issues in the beginning, but everyone had it up their ass to make 20 billion tuning/logging apps instead of collaborating to make one "really good" app that "everyone" could use. So, as time went by certain people involved with those projects started dropping off in their development... some from getting bored, others from probably getting threatened by certain companies. I think we can all agree that development seems to have hit a plateau on openecu as of recent time.

My work on EcuFlash has slowed over the summer because I have a lot of work which needed to be done for other non-automotive projects I am involved in (read: things that pay the bills). After mid-September, I plan to hit EcuFlash again pretty hard and add a lot of new features that have been brewing that I haven't had time to finish. By the end of the year my goal is to have it exceed anything out there currently, free or commercial.

colby

XMLwrite is a DIRECT copy of Ecutek. The dude that created it somehow got access to Ecutek's software and most likely hacked their data file and created the software to convert their definitions to xml files compatible with the openecu software. So, yeah, it has more tables. You aren't going to see another version as I doubt the guy want to stick his neck out and have Ecutek chop it off. So the argument that someone should have had a definitions file for the openecu tools comparable to a stolen copy from a commercial company who's been working on it for years and has many resources is ridiculous.

Yes, XMLwrite has more tables. The tables that it does have that Enginuity doesn't, 99% of them you wouldn't need to tune with (Enginuity had the per gear boost compensation for several months, just not the disable speed). The tables that Enginuity has that xmlwrite doesn't are more useful. Such as Initial IAM (32bit), Timing Compensation (Intake Temp) (32bit), Timing Compensation (Coolant Temp) (next version), Injector Latency (32bit - XMLwrite's is incorrect), Additional Closed Loop Load/TPS tables (some 32bit), Individual CEL Fixes via checkbox, and TGV threshold fixes (16bit). Plus Enginuity has support for revisions not supported by Xmlwrite. I'm sure Ecutek added this stuff by now, but you aren't going to see it if you latch yourself onto a set of definitions that will never be updated.

There are even hundreds of additional tables on a rom that Xmlwrite doesn't support, so by your standard, even XMLwrite isn't even close to being complete. If you would like to see the advancement of the openecu tools then you can always contribute. All of these guys (with the exception of Ecuedit) develop this stuff in their leisure time for FREE.

xmlwrite was meant to be a stepping stone in order to get things moving. Just take a sec and think where we would be without out.
Enginuity's defs are built using this tool as a base, then tested and ironed out by their team. They stepped up and did exactly what i had in mind when i created that app. That is great work and if there were more people involved on doing this instead of bitching around and discussing fairy tales, a lot more progress would have been done.
The rom structures have been known for quite some time now, 16bit was discovered by Calvin and i have figured out the 32bit. Adding new defs is easy, if you disassemble the rom and know what to look for.
xmlwrite has a new version and will always be updated regardless of what you might think or hear as a rumor :disco:
Is it going to be available for public?.....that is another story.

and yes this was done for free

Tea Cups, I do contribute. While I don't have the time to contribute to actually writing these apps I do contribute by testing them throughly (except for yours because like I stated before... you're tied to Sun's Java engine and I'd never install that engine on my PC. It's too much of a security risk and just plain sucks when it comes to speed on Java apps that I do use in my browser for work.) I'm sorry if I can't contribute in any other way... last time I checked, there's no definition stating that testing the apps and reporting back isn't helping.

xswrex, if what I stated above is not the truth (I did say it was a rumor... didn't I), then why be so freaking secrative with xmlwrite at this point? Is it because you feel that you've put so much time in it that you won't see any kickback for that time spent? I got news for you... it's a free project. You knew what it was when you got involved with it. However, since others have recently gotten the urge to start charging for isht that should have (and was well stated that it would be) free to begin with maybe you should get in touch with epifan and bundle your "constantly updated" as you put it version of xmlwrite with his ecuEdit software and charge for it. Hell, he's charging for his... have him bump up the price a little and get that kickback for you program. Everyone would be happy at that point.

All this bullisht about (no, I made this for myself and I'm not releasing it to anyone out there, muhahahaha) needs to stop. Figure out what you want out of this and make it happen. Releasing something to the public to get them over a big hurdle and then not doing anything more is like getting someone hooked on crack and then not continuing to supply them. In the end, it's just pissing people off.

I told everyone GREED would get the better of them... and now you know it's true. :rolleyes:

I'm not complaining about Xmlwrite and it has been an awesome reference tool in getting the definitions up and started and giving us an idea of what is possible. Certainly xswrex has contributed greatly by being the first to figure out the data structure of the 16bit and 32bit ecus. We would not be as far as we are today without his help - no doubt.

JRSCCivic98 - It's too bad you don't like Java. I've never had any issues with Java apps before but to each his own. We could use additional help in testing, so if you ever change your mind, let us know. As far as Xmlwrite being bundled with Ecuedit, that would be a bad move for Epifan. It's one thing if they were bundled with a free open source program and another if bundled with a for-profit piece of software. I'm no lawyer, but it would seem that Ecutek would have more ground to stand on in a lawsuit in that case.

JRSCCivic98 - It's too bad you don't like Java. I've never had any issues with Java apps before but to each his own. We could use additional help in testing, so if you ever change your mind, let us know. As far as Xmlwrite being bundled with Ecuedit, that would be a bad move for Epifan. It's one thing if they were bundled with a free open source program and another if bundled with a for-profit piece of software. I'm no lawyer, but it would seem that Ecutek would have more ground to stand on in a lawsuit in that case.

It's not that I don't like Java. I just don't like Sun's Java engine. I use MS Virtual Machine's engine for my Java uses and it's perfectly fine. It's too bad that Sun had that lawsuite a while back which caused MS to stop bundling thier Java engine with the OS.

As for what epifan did with ecuEdit and wanting to charge for it... that's just plain stupid if you ask me. It's not what the original goal was for everyone at openecu from my understanding. In the end I really don't think the free stuff is going to go as far as it could have... it's really a shame.

On a side note about Enginuity, did you ever think about compiling the program to run as an executable standalone so there would be no need for external engines to make it run? I think I may have asked this before... I don't know if there's anything out there that can do this kind of coversion from Java based apps... I'm not a programmer. :confused:

It's not that I don't like Java. I just don't like Sun's Java engine. I use MS Virtual Machine's engine for my Java uses and it's perfectly fine. It's too bad that Sun had that lawsuite a while back which caused MS to stop bundling thier Java engine with the OS.

As for what epifan did with ecuEdit and wanting to charge for it... that's just plain stupid if you ask me. It's not what the original goal was for everyone at openecu from my understanding. In the end I really don't think the free stuff is going to go as far as it could have... it's really a shame.

Logging, real-time tuning, graphing, and flashing are already on table as planned additions to Enginuity, so it's not like it is a stagnant program that isn't being developed. And updates to Enginuity and the definition file are pretty regular. It's only a manner of time before it is a comprehensive package for tuners.

Here's some screenshots of Enginuity for those that might be interested. This is of an 05 USDM STi with the latest definition file. This shows all the tables supported for this particular revision (and is typical of most 32bit roms):

http://www.enginuity.org/files/ss_2_201.jpg

http://www.enginuity.org/files/ss_3_967.jpg

http://www.enginuity.org/files/ss_4_164.jpg

My work on EcuFlash has slowed over the summer because I have a lot of work which needed to be done for other non-automotive projects I am involved in (read: things that pay the bills). After mid-September, I plan to hit EcuFlash again pretty hard and add a lot of new features that have been brewing that I haven't had time to finish. By the end of the year my goal is to have it exceed anything out there currently, free or commercial.

colby

we are using the ecuflash on the evo's with great success...

therefor we are patiently waiting for the subaru version.... but im also a big fan of cobb.....

cb

therefor we are patiently waiting for the subaru version....

There's no Subaru version. What you have now works with Subaru as well. You just need to sit down with xmlwrite or something and build your Subaru XML files. I kinda never understood why it came with EVO defs, but no Subaru defs. :rolleyes:

JRSC, I'd be interested in your input on the JRE. If I can make Enginuity run reliably on different JREs and make more people happy, I'd gladly do it, but I don't have any experience with them. If you'd be interested in helping with that, and after that with using Enginuity some and giving more input (as you're the only person who is opposed to Sun's JRE, though I did finally see someone who had an issue with another), send me a PM or something and we can work this out.

I originally started using Java because it was what I knew best and the experience will help me a lot at work (and hopefully find future jobs). Platform independence was a plus that I didn't really concern myself with, but at least a few people ARE using it in Linux and Mac now. Adding new features and stablizing the app are top priorities, but it'll be a lot easier to fix OS and JRE issues as they come up rather than having a ton a year from now and fix them all then.


Now, back to the original issue. It seems the biggest thing holding tuners back (that they'll disclose publicly) is the lack of liability and testing. Continuous updates to the definition file are great for us nerds, but not what the mass market is looking for. Some sort of comprehensive testing and certification program would be a big step, I think. Sort of like stable and daily builds of many open source projects. I'd be interested in getting with someone to set a program like this up, whether it be a professional tuner or whatever. Any ideas?

Tea Cups, I do contribute. While I don't have the time to contribute to actually writing these apps I do contribute by testing them throughly (except for yours because like I stated before... you're tied to Sun's Java engine and I'd never install that engine on my PC. It's too much of a security risk and just plain sucks when it comes to speed on Java apps that I do use in my browser for work.) I'm sorry if I can't contribute in any other way... last time I checked, there's no definition stating that testing the apps and reporting back isn't helping.

xswrex, if what I stated above is not the truth (I did say it was a rumor... didn't I), then why be so freaking secrative with xmlwrite at this point? Is it because you feel that you've put so much time in it that you won't see any kickback for that time spent? I got news for you... it's a free project. You knew what it was when you got involved with it. However, since others have recently gotten the urge to start charging for isht that should have (and was well stated that it would be) free to begin with maybe you should get in touch with epifan and bundle your "constantly updated" as you put it version of xmlwrite with his ecuEdit software and charge for it. Hell, he's charging for his... have him bump up the price a little and get that kickback for you program. Everyone would be happy at that point.

All this bullisht about (no, I made this for myself and I'm not releasing it to anyone out there, muhahahaha) needs to stop. Figure out what you want out of this and make it happen. Releasing something to the public to get them over a big hurdle and then not doing anything more is like getting someone hooked on crack and then not continuing to supply them. In the end, it's just pissing people off.

I told everyone GREED would get the better of them... and now you know it's true. :rolleyes:

What did you use to benchmark Sun VM vs the MS vm? Any benchmarks you can point me at? Id be surprised at much difference as Microsoft leverages Suns source code to implement their virtual machine.

http://www.microsoft.com/mscorp/java/

What are these security issues you're talking about?

JRSC, I'd be interested in your input on the JRE. If I can make Enginuity run reliably on different JREs and make more people happy, I'd gladly do it, but I don't have any experience with them. If you'd be interested in helping with that, and after that with using Enginuity some and giving more input (as you're the only person who is opposed to Sun's JRE, though I did finally see someone who had an issue with another), send me a PM or something and we can work this out.

I originally started using Java because it was what I knew best and the experience will help me a lot at work (and hopefully find future jobs). Platform independence was a plus that I didn't really concern myself with, but at least a few people ARE using it in Linux and Mac now. Adding new features and stablizing the app are top priorities, but it'll be a lot easier to fix OS and JRE issues as they come up rather than having a ton a year from now and fix them all then.


Now, back to the original issue. It seems the biggest thing holding tuners back (that they'll disclose publicly) is the lack of liability and testing. Continuous updates to the definition file are great for us nerds, but not what the mass market is looking for. Some sort of comprehensive testing and certification program would be a big step, I think. Sort of like stable and daily builds of many open source projects. I'd be interested in getting with someone to set a program like this up, whether it be a professional tuner or whatever. Any ideas?

What kind of testing?
There are a lot of people using the opensource tools to tune thier car now. As you know I have been using Enginutiy on a lot of different builds. Right now I am in the middle of an Sti tune. GT35R, headers, 3.25" blow through MAF, kelford cams, FMIC, Stock modded injectors and WI. The car idles like stock after the MAF cal and injector scaling. I plan on tuning the stock ECU to a consertive tune @ 20psi. Then the Utec will take over from there. The reason for that is the stock sensors max out ~25psi. Even if I could replace the MAP sensor the stock ECU can not tune above the 5V MAF limit. So the Utec is needed in SD mode to tune higher than 25psi on this setup. Do you want to setup a help line or something?

TMS

Not a help line. Just a way to say with as much certainty as possibly that all of the tables in a given definition file are 100% accurate. Then make it an "official" definition and let the interested parties know. It would probably change at least a few minds I'd think.

5v on the MAF is an awful lot of air. You're pushing more than that? :D

3.25" blow through MAF is maxxing out ~25psi@6200rpm. :)

TMS

At the end of the day, it all boils down to risk and support.

Like all open source, source is forum base and pretty non-existent, except some professional body offering it.

I believe EcuTek and Cobb are different and offer guarantees in case of problems. Open source is just the opposition. All is at you.

You can tell the customer you are not liable, and he will leave you and go to man that will take the liability :)

To be honest, I have seen EcuTek Flash, EcuEdit and Enquity and I prefer EcuEdit and sometimes Enguity. To me, EcuTek is just crap in the interface and features it offers. There had no incentive to push their product until these new tools came out.

Cobb tuning looks good, but I find these products have a lot of hipe, but it is a good product, giving you the ability to change your maps on the fly.

I think once a nice car pc or similar product is shown, the opensource or semi opensource community would be sailing.

I have tuned cars where people got rid of their Cobb package, ECUTek and other piggy back stuff.

Once the XML defs is sorted out and good definition of bugs are resolved, I think tuners will creep towards it slowly.

What did you use to benchmark Sun VM vs the MS vm? Any benchmarks you can point me at? Id be surprised at much difference as Microsoft leverages Suns source code to implement their virtual machine.

http://www.microsoft.com/mscorp/java/

What are these security issues you're talking about?

There are admin tools that run on Java (as there have been a few years ago as well). At that time it was an HP JetDirect web interface that ran on Java. Sun's would crawl... if you ran MS's it would fly through the interface. As for security issues, I don't think they are documented ones. From what I have seen throughout the past few years as more and more people were pushed to run Sun's Java because MS couldn't (because of Sun's BS lawsuit) update theirs, the cache directory that Sun's Java has was pretty much a holding tank for various Java based web virii and Trojans. It seemed that it was a lot simpler for someone to get a Java based package downloaded that contained malitious code and infect their PC with Sun's engine then it was with MS's engine. On every single PC that I would run upon that had spyware/adware/trojans loaded in it I would find infected Java package files in the Sun cache directory. Obviously the coding wasn't very good on security from Sun at those times. (this was as early as last year) Since I've seen all these issues I don't use Sun's engine and I try and push clients to not use it either. Sure, there's not anything else to use at the moment that's easily available, but if you have a copy of MS VM and apply all the updates you will be very safe. Only problem with MS's VM... it doesn't work well with external Java programs outside of the browser.

So, with that said, here's a few links I sent Tea Cups... I told him to forward these to you for your info... I guess he didn't.

Here are some links to info about converting Java programs to exe-files.

http://www.geocities.com/marcoschmid...mp.html#native
http://www.yoda.arachsys.com/java/javaexe.html
http://www.dobysoft.com/products/nativej/index.html
http://www.excelsior-usa.com/jetdev.html
http://www.osd.ch/products/
http://www-106.ibm.com/developerwork...l,l=805,p=cgui
http://www.developer.com/java/other/article.php/2179061
http://gcc.gnu.org/java/
http://www.thefreecountry.com/compilers/java.shtml
http://www.duckware.com/jexepack/index.html

There are admin tools that run on Java (as there have been a few years ago as well). At that time it was an HP JetDirect web interface that ran on Java. Sun's would crawl... if you ran MS's it would fly through the interface. As for security issues, I don't think they are documented ones. From what I have seen throughout the past few years as more and more people were pushed to run Sun's Java because MS couldn't (because of Sun's BS lawsuit) update theirs, the cache directory that Sun's Java has was pretty much a holding tank for various Java based web virii and Trojans. It seemed that it was a lot simpler for someone to get a Java based package downloaded that contained malitious code and infect their PC with Sun's engine then it was with MS's engine. On every single PC that I would run upon that had spyware/adware/trojans loaded in it I would find infected Java package files in the Sun cache directory. Obviously the coding wasn't very good on security from Sun at those times. (this was as early as last year) Since I've seen all these issues I don't use Sun's engine and I try and push clients to not use it either. Sure, there's not anything else to use at the moment that's easily available, but if you have a copy of MS VM and apply all the updates you will be very safe. Only problem with MS's VM... it doesn't work well with external Java programs outside of the browser.

So, with that said, here's a few links I sent Tea Cups... I told him to forward these to you for your info... I guess he didn't.

Here are some links to info about converting Java programs to exe-files.


I went through them.....

http://www.geocities.com/marcoschmid...mp.html#native
-Link Doesnt work


http://www.yoda.arachsys.com/java/javaexe.html
-This talks about how even native code compilers often require the JRE to be installed (no download savings in the end). Also helps support my personal findings Java is at about 80% of native C speed.


http://www.dobysoft.com/products/nativej/index.html
-From the link faq:

"Does NativeJ compile my Java application into native code?

No, NativeJ generates a Win32 EXE that will launch your Java application using the JVM. You will still need to include your application class or jar files. Think of these as DLLs or COM objects that are included with many native applications."



http://www.excelsior-usa.com/jetdev.html
-Link doesnt work



http://www.osd.ch/products/
-Link doesnt work



http://www-106.ibm.com/developerwork...l,l=805,p=cgui
-Link doesnt work


http://www.developer.com/java/other/article.php/2179061
-This is just about Swing / AWT and SWT Gui libs. Doesnt say anything about native code compilers.



http://gcc.gnu.org/java/
-Yeah.. no. I've used this both as an interpreter and a native code compiler. Lol, not the best out there. When someone has an issue with linux and Java, I find its mostly because their using GCJ.



http://www.thefreecountry.com/compilers/java.shtml
-This link references Excelsior Jet. From the FAQ:

"What Excelsior JET is not?

Excelsior JET is not a packager of Java applications into Windows EXE/Linux binaries. It really compiles your Java class files into native x86 (IA-32) instructions. The resulting executables need the Excelsior JET Runtime to run, but not the Sun JRE."

This includes a more cut and dry JVM to run its apps.


http://www.duckware.com/jexepack/index.html
-This is just a packager and not a native code compiler.


I remember from one of your earlier posts talking about your desire for a native compilation. In all reality its not going to happen. I've only seen the capability of running a subset of the features of the Java VM as native code, or the use of a cut down VM.

Speed really isn't an issue these days so a native code compiler is only really good for obfiscating code to protect IP. Since Enginuity is open source.. meh.

A JVM can be cut down to a 10 meg zip to be included with an application. I'll eventually work on that with Enginuity.

And Suns lawsuit was not BS. MS practice of embrace, extend and break the competition was in full effect. They changed their VM to make users either build MS or other platform programs. Write once no more then. Check out this timeline. Considering how much MS payed out to Sun on all this, I think most agree MS was in the wrong.
http://www.directionsonmicrosoft.com/sample/DOMIS/update/2004/05may/0504sdsle_sb.htm

Undocumented security issues? I dunno man. I've only seen problems with MS VM. Not that this will be an issue in 2007 (you'll have some pissed off clients). A quick google turns up more links for MS related security issues. I've never seen the level of problems you claim.
http://www.google.com/search?hl=en&q=Java+VM+security+issues&btnG=Google+Search

It would be helpful in the future if you supplied more complete support for your claims.

What kind of testing?
There are a lot of people using the opensource tools to tune thier car now. As you know I have been using Enginutiy on a lot of different builds. Right now I am in the middle of an Sti tune. GT35R, headers, 3.25" blow through MAF, kelford cams, FMIC, Stock modded injectors and WI. The car idles like stock after the MAF cal and injector scaling. I plan on tuning the stock ECU to a consertive tune @ 20psi. Then the Utec will take over from there. The reason for that is the stock sensors max out ~25psi. Even if I could replace the MAP sensor the stock ECU can not tune above the 5V MAF limit. So the Utec is needed in SD mode to tune higher than 25psi on this setup. Do you want to setup a help line or something?

TMS

Something like osecuroms is a step in the right direction. It would be even better if tuners that used these roms reported information on timing, afrs, egts etc and how much gains they saw.

Maybe a better question is what makes users trust a closed map from COBB more than somethings thats available for all to see, test and tune? How can the OS community provide what value they do?

Something like osecuroms is a step in the right direction. It would be even better if tuners that used these roms reported information on timing, afrs, egts etc and how much gains they saw.

Maybe a better question is what makes users trust a closed map from COBB more than somethings thats available for all to see, test and tune? How can the OS community provide what value they do?

I really think that ATM the open source tools are very scary for noobs to EM. The AP you just plug and pray that it will work for you, and the efact that there is a well known tuner backing it up.

TMS

I really think that ATM the open source tools are very scary for noobs to EM. The AP you just plug and pray that it will work for you, and the efact that there is a well known tuner backing it up.

TMS

So, what if enginuity had two fronts in the GUI. One like now, that allows for user tuning. And another that has a simple menu system and flow like...

-select your cars make
-select your cars year
-select the octane available to you
-select your stage of mods.
-connect OBD2 cable
-press flash, wherin your current rom is backed up, and the new one is flashed

We would have to bundle a number of roms with Enginuity, but thats not too much of an issue. Or, have enginuity fetch the proper rom from osecuroms.org.

You think that might alleviate some acceptance problems?

*yeah, we need that flashing code in Enginuity first, it'll get there*

^^^
That might make more people use it. I think alot of people think that tuning is some sort of magic, and are afraid to try tuning on thier own.
That list would be a good start to getting more people to use the OS tools. I would also add some data to back up the staged maps. Plots of AFR, boost, ing timing and maybe HP and TQ.

TMS

mark said this once before, and i agree... if you are a total newb to tuning, then the open source tools are very confusing.

if you aren't new to tuning, you pretty much just jump right in and go.

jrsc, get off the rag already. :lol:

There are admin tools that run on Java (as there have been a few years ago as well). At that time it was an HP JetDirect web interface that ran on Java. Sun's would crawl... if you ran MS's it would fly through the interface. As for security issues, I don't think they are documented ones. From what I have seen throughout the past few years as more and more people were pushed to run Sun's Java because MS couldn't (because of Sun's BS lawsuit) update theirs, the cache directory that Sun's Java has was pretty much a holding tank for various Java based web virii and Trojans. It seemed that it was a lot simpler for someone to get a Java based package downloaded that contained malitious code and infect their PC with Sun's engine then it was with MS's engine. On every single PC that I would run upon that had spyware/adware/trojans loaded in it I would find infected Java package files in the Sun cache directory. Obviously the coding wasn't very good on security from Sun at those times. (this was as early as last year) Since I've seen all these issues I don't use Sun's engine and I try and push clients to not use it either. Sure, there's not anything else to use at the moment that's easily available, but if you have a copy of MS VM and apply all the updates you will be very safe. Only problem with MS's VM... it doesn't work well with external Java programs outside of the browser.

So, with that said, here's a few links I sent Tea Cups... I told him to forward these to you for your info... I guess he didn't.

Here are some links to info about converting Java programs to exe-files.

http://www.geocities.com/marcoschmid...mp.html#native
http://www.yoda.arachsys.com/java/javaexe.html
http://www.dobysoft.com/products/nativej/index.html
http://www.excelsior-usa.com/jetdev.html
http://www.osd.ch/products/
http://www-106.ibm.com/developerwork...l,l=805,p=cgui
http://www.developer.com/java/other/article.php/2179061
http://gcc.gnu.org/java/
http://www.thefreecountry.com/compilers/java.shtml
http://www.duckware.com/jexepack/index.html

i think you said it best when you stated:

I'm not a programmer. :confused:

if you aren't new to tuning, you pretty much just jump right in and go.
And I think the same could be said for any other tuning software. People just don't seem to want to accept that.

I have to say, I'm a newbie to tuning but trying to actively learn all I can by reading books and the internet. After reading a whole lot, I've recently switched from Cobb Stage 2 to Enginuity stage 2 with some of my own slight mods to the map for 93 octane. It's not that hard at all, you just have to read and pay attention to what you're doing. So far no problems except more butt dyno power!!