Tuning Software.

[fivebob]

This is a simple survey about what people like, a little bit of what they don't like, and what would be nice to haves.

Also if there was a generic user interface that allowed you to program any ECU using a wide variety of input devices computer, tablet, smartphone , etc, would you pay, if so how much would you expect to pay.

And if you were a software developer how would you pay for the development.

• Completely open source.
• Donation.
• Keep all the best features for a "Pro" version.
• Full commercial product.
• SAAS model, pay to use web based service that allows tuner to connect to ecu.
• Other.

[Lith]

program any ECU using a wide variety of input devices computer, tablet, smartphone , etc, would you pay, if so how much would you expect to pay.

Sounds a bit like you're thinking about similar things to what I have been... though I've been thinking probably a little more specifically about particular brands of ECU, I might just be not being open minded enough but I can't picture how you could do a generic interface to cover "programming" a variety of different types of aftermarket ECU given even on the surface things seem similar - there are quite different approaches to how a "tune" is formed etc.

Would be a pretty seriously huge project to try and achieve that, and I'm not 100% sure it would be commercially viable when you get the likes of Link constantly updating their own software - the required support to keep current would be massive.

I do think that a tablet would be really handy for tuning though, though the G4 Link software works fine on a Windows tablet - one of my mates uses one as his dash in his race car

[Akane]

Auto tuning via wideband input and other various parameters are always nice, something that auto fills the table with a rough safe AFR ratio and ign timing is great, that just took a few hours off my tuning time.

Ability to change 1 point in the table and interpolate the values to the surrounding values is awesome too IMO.

Pro version for $$$ for features that motorsport people will use, like the anti-lag bang bangs, and the launch control.

[iOnic]

I'm not entirely sure that there is a need for a one size fit's all software package but I'm interested in where this goes anyhow.

For me personally, features that eased road tuning would be brilliant. Things like the virtual dyno in Evoscan, the automatic difference reporting in Tunerstudio and highlighting of cells used during a run and log analysis etc. The VE Analyze feature in Tunerstudio is also good for tidying things up.

Good luck Sounds like an interesting project.

[fivebob]

Sounds a bit like you're thinking about similar things to what I have been... though I've been thinking probably a little more specifically about particular brands of ECU, I might just be not being open minded enough but I can't picture how you could do a generic interface to cover "programming" a variety of different types of aftermarket ECU given even on the surface things seem similar - there are quite different approaches to how a "tune" is formed etc.

Would be a pretty seriously huge project to try and achieve that, and I'm not 100% sure it would be commercially viable when you get the likes of Link constantly updating their own software - the required support to keep current would be massive.

You do it the same way you eat an elephant, one byte at a time. Even better than that, you get someone else to eat the elephant for you, even better still is if you can get the elephant to eat itself, but that requires that the software is popular enough that manufacturers will provide an interface that conforms to a standard.

It's not as hard as it seems when you try to look at it as one monolithic chunk. Just make it like any other multi-tiered application. Basically the interface programs a virtual ECU that implements every feature that any of your supported ECUs require. So the interface only ever "talks" to a known device. Then the client at the ECU end receives data in a known format, runs it through a "Device Translator" and then outputs to the ECU by whatever physical connection the ECU accepts, eg serial, USB, CAN etc. That way to add a new ECU to the list of supported devices all you have to do is translate a generic "map" to the proprietary format and implement the comms layer.

At worst the translation of the map might require several generic thunking layers before being passed to the proprietary layer using a "Chain of Responsibility" pattern. Most of the proprietary layers could be made generic as you get more devices that want to support the specific feature. That way you get controlled feature growth and a manageable development environment.

[sergei]

Licence: GPL+voluntary donations for individuals (no support bar community forums), fee/annual subscription for commercial use (but comes with support).

Main gripe with tuning software (based on short experience with Link) is that GUI is counter-intuitive and made by engineers.

Another very useful feature I always wanted is ability to script, but that actually depends more on the ECU firmware than tuning software.

[fivebob]

I'm not entirely sure that there is a need for a one size fit's all software package but I'm interested in where this goes anyhow

Ok, but what if the interface let you customise how you interact with it, so that you could build you own tuning screens, with the info and functions you wanted, that behaved in the way you wanted?


I'm not talking about a standard GUI that forces the user to enter data in the same way, but a configurable interface that let's the user interact with the software the way they're most comfortable with.

[sergei]

I'm not talking about a standard GUI that forces the user to enter data in the same way, but a configurable interface that let's the user interact with the software the way they're most comfortable with.

I like the way you think.

[fivebob]

Easy to achieve with an HTML5+ JavaScript(JQuery) front end.

You probably won't like my ideas for the server and ECU interface though.

• .Net server using SignalR for communicating between clients.
• .Net translation engine using XML based rule file and/or plugins.
• .Net Micro Framework interface device for talking to serial, CAN interfaces. Also could be used to connect Android phone directly to the ECU.

[fivebob]

Another very useful feature I always wanted is ability to script, but that actually depends more on the ECU firmware than tuning software.

If you mean scripts that would run on the ECU, that's beyond what an interface can do, but if the ECU supported that sort of thing, or other methods such as decision trees like a lot of dash loggers use, then they could be represented in the user interface and be translated to program them into the ECU.

If you want scripting plugins to run anywhere in the system apart from the ECU itself, then all layers should support this.

[iOnic]

I'm not entirely sure that there is a need for a one size fit's all software package but I'm interested in where this goes anyhow

Ok, but what if the interface let you customise how you interact with it, so that you could build you own tuning screens, with the info and functions you wanted, that behaved in the way you wanted?

Sorry if this is a whole other tangent I don't think it really helps you find out what you want. FWIW I'm not a pro tuner, it's not what I do for a job. Just an interest. I've tuned many cars but my opinion is just that so I wouldn't put too much thought into it

Unless I don't completely understand your description (almost certain ), this is already available on many tuning software packages. I use Tunerstudio for Megasquirt as an example because I enjoy using it and it's flexible enough to let you do just about anything you want.

(This isn't my image, just an example)


This is what I use as my tuning screen (when doing a run). The graphs are live rolling histograms so I can watch trends at a glance and can also view history through the run. Each graph can be customized so I can have any value I'd like to graph on this screen, I can set it to behave in a particular way (rescale automatically, set off a warning at a specified value, highlight cells on my fuel/ignition map where afr/iat/other have exceeded a specified value, start logging when a specified data reaches a specified value etc)

As this person has shown in his image, you can overlay any graphs together to ease analysis. With this screen in the foreground, I can keep my actual 2d/3d map in the background knowing that there is a live trace highlighting where on the map I've been during my run and I've customized it to highlight cells that need changes made based on data you have already specified.

For me personally, since I don't own a dyno, anything that reduces the amount of things I'm doing during a run will be welcome. My primary focus is driving the car and listening for knock - software needs to actively monitor everything else for me in spite of me glancing over at the screen. The most important thing for me is recording data and having it presented in a way that gives me visual difference reporting and allows me to make quick adjustments.

[Vertigo]

.net :/ xml :/

[fivebob]

Yes I know most software has that, but what I'm talking about goes beyond that and presents you with a common interface for any ECU, so you can concentrate on tuning, not learning new software for each ECU.

Plus the added benefit of taking a map between devices. So if you changed ECUs you wouldn't have to start from scratch, or manually convert the settings.

What about remote tuning, dyno interfaces, or indeed interfacing to any device. It wouldn't. Be hard to put a 3 axis G-sensor into the comms device so you could gave a measure of torque . Also interface it to the Speedo or onboard GPS is possible.

Also allowing for scripting/plugins at any layer could give you auto-tune features or any other custom feature required.

[fivebob]

.net :/ xml :/

Got a better solution?

For this exercise I think they are the most appropriate technologies.

.net mainly because it can be used for making the comms devices. Plus the SignalR technology for comms and mvc for page generation..

XML because it's the best way to represent an ECU and its features.

[iOnic]

Yes I know most software has that, but what I'm talking about goes beyond that and presents you with a common interface for any ECU, so you can concentrate on tuning, not learning new software for each ECU.

Plus the added benefit of taking a map between devices. So if you changed ECUs you wouldn't have to start from scratch, or manually convert the settings.

What about remote tuning, dyno interfaces, or indeed interfacing to any device. It wouldn't. Be hard to put a 3 axis G-sensor into the comms device so you could gave a measure of torque . Also interface it to the Speedo or onboard GPS is possible.

Also allowing for scripting/plugins at any layer could give you auto-tune features or any other custom feature required.

Sounds interesting Watching for progress/updates

[Vertigo]

.net :/ xml :/

Got a better solution?

For this exercise I think they are the most appropriate technologies.

.net mainly because it can be used for making the comms devices. Plus the SignalR technology for comms and mvc for page generation..

XML because it's the best way to represent an ECU and its features.

.net limits the app to windows only pretty much, so thats a huge downside for a linux user, or even a mac user. xml is just horrid. use yml for local storage/config files, or if for api talking, use json.

there are plenty of better techs than the ones microsoft is evangelical about.

[sergei]

.net is job security for most developers that do it as a job.
just like the saying "No one got fired for buying IBM", could be said "No one got fired for writing in .net".

Of course as I understand for fivebob .net is the most logical solution as he works with it on daily basis.

From my point of view it is very poisonous and not portable.
I am not a developer, but I would have gone with C or Python, or even Perl.

[fivebob]

.net limits the app to windows only pretty much, so thats a huge downside for a linux user, or even a mac user

I think you may have misunderstood the requirements for using the app, all the end user needs is a browser, doesn't matter what OS you run it under.

The comms device, wouldn't care either it only needs a network connection.

The only place that a Windows machine would be required is a central server for serving up the pages, even that isn't strictly necessary as you could use PhoneGap to encapsulate the app for smartphone/tablet devices. Would still need a server for remote tuning though.

xml is just horrid.

Not really, you just use it to serialize objects you don't have to touch or even understand xml.

or if for api talking, use json.

Underlying transport to/from the client is Json, but it's irrelevant anyway as you call objects directly regardless of where the reside, how they communicate makes no difference.

there are plenty of better techs than the ones microsoft is evangelical about.

Be brave tell us how you could do it better.

[fivebob]

.net is job security for most developers that do it as a job.
just like the saying "No one got fired for buying IBM", could be said "No one got fired for writing in .net".

Not really, there's good reasons to use .net is some applications. Job security has little to do with it.

Of course as I understand for fivebob .net is the most logical solution as he works with it on daily basis.

The fact that I work with it makes me more grounded and able to understand what's good about it. I'm language/OS agnostic so I pick the best tool for the job, and 35yrs of programming and system design experience tells me that it's a suitable tool for the job

,

From my point of view it is very poisonous and not portable.
I am not a developer, but I would have gone with C or Python, or even Perl.

What, no assembler in your list that would be my pick if I was being biased. Apart from that,C is the only real option and that gets tedious after a while.

[Vertigo]

.net limits the app to windows only pretty much, so thats a huge downside for a linux user, or even a mac user

I think you may have misunderstood the requirements for using the app, all the end user needs is a browser, doesn't matter what OS you run it under.

The comms device, wouldn't care either it only needs a network connection.

The only place that a Windows machine would be required is a central server for serving up the pages, even that isn't strictly necessary as you could use PhoneGap to encapsulate the app for smartphone/tablet devices. Would still need a server for remote tuning though.

Are we talking about an app that a home enthusiast would be using? In which case, the server and client (browser) would be on the same machine. A linux user would have a hard time of this by the sounds of it. Thats all Im worried about - you asked us what we would like to see, and Id like to not have to run Windows.

xml is just horrid.

Not really, you just use it to serialize objects you don't have to touch or even understand xml.

Fair enough. Your app i guess Id use something else, personally.

there are plenty of better techs than the ones microsoft is evangelical about.

Be brave tell us how you could do it better.

I probably couldnt - my programming expertise is in PHP/MySQL, with some embedded knowledge gained dicking around with an Arduino. But Python, C, etc etc etc, as Sergei suggested would be great alternatives.