From a marketing standpoint the majority of consumers do not know a wideband from a narrow band nor how to install or tune an ECU. As a result consumers will either do a side by side comparison with input from users or go with whatever their tuner recommends.

With the first purchasing mechanism the ECU toting the largest number of rows and tuneable parameters is often chosen. With the second method you will see a tuner recommending the product that gives them the best results in the fewest number of hours.

As a result the success of the VEMS based system is highly dependant on the tuning software and firmware. Reason being that the hardware is very well designed for flexibility and adding features is often as simple as adding to the firmware and tuning software.

Technologies Available

There are a number of different technologies available for the tuning software. With each comes some advantages and disadvantages.

C:

* Pros: Same language as firmware, very common with many libraries available, compiled result is often compact and fast.

* Cons: Development may be slower, depending on the tools chosen the GUI may be a timeconsuming endeavour. GUI portability may be a lot of work. GTK and glade seems to be the most portable across OS-es, and even across languages (see Perl below). Too bad that GTK works slow on win32 and does not fit on GBA. Doing it in C means we are reimplementing some stuff that is already done: reference counting, exceptions and maybe dynamic dispatch. Although significant work, it is still lower footprint than getting them via libgcj or libstdc++

Java:

* Pros: Write once run on any platform, common language with lots of design tools and libraries with a good JCL for support. Secure and stable with regards to memory management and importing shared files and/or internet updates. I gave JAVA another chance by studying how it can be compiled to native code via gcj (same core as gcc) and linking with C code successfully: [JAVA and C calling each other, compiled to native code experiment with README notes]. Unfortunately the libgcj footprint seems prohibitive for GBA, and it's unlikely that it's possible to make it work without libgcj.

* Cons: Speed. JVM (or libgcj library) and JCL require a lot of space. JVM also requires significant CPU resources.

C++:

* Pros: good widgetset, such as QT (not suitable for GBA). Although somewhat less suitable, there is more field-experience in compiling C++ to native code than JAVA to native code

* Cons: the language itself is even more demanding than JAVA. Depending on libstdc++ it's unlikely to fit in GBA

Domain Specific Language

http://c2.com/cgi/wiki?DomainSpecificLanguage most likely using an engine written in C.

* Pros: designed to the exact needs. Very efficient.

* Cons: might be much work

Perl:

* Pros: many libraries available, and most of the configuration and talk-to-ecu (think: BootLoader) code is already written. Mik reminded that glade GUI stuff from MegaTunix can be used as is, see [gnome tutorial]

* Cons: although lightweight compared to JAVA, still need a VM to run. More programming errors turn up only at runtime (compared to C or especially JAVA)

Delphi:

* Pros: Fast development, fast easy GUI design, common language with many components available, compiled result is quite reasonably sized and runs fast for a RAD language. Compiled result also doesn't require piles of DLLs to run.

* Cons: Code is tied to win32 with little or no chance of portability.

Visual Basic:

* Pros: Fast development, fast easy GUI design, common language with lots of libraries available.

* Cons: Results are often large, requiring a vast number of DLLs and MFC junk that can cause a support nightmare. Compiled code isn't exactly fast, portability is limited to the win32 platform.

Portability:

This is listed in many of the above pros/cons. Portability can mean being able to run the application on a number of different platforms such as Linux/BSD, Mac, Win32.

Portability can also mean multilingual support. The majority of american made and marketed standalone ECUs support only one language. While multilingual support may be important, it is often a design of the GUI/application.

One big unanswered question here is what proportion of the target market is using anything but windows? There are currently no known aftermarket units available which support anything but windows/DOS. Is this an attribute we can afford to support? Will it give us any competitive edge? Or is it just the right way to do it?

What is the downside of OS portability?

Quite simply support. Java is definitely a preferred environment and supports many platforms, but it still does not mean the application will run on every platform and for every support request a support person knowledgable in that area is required.

What is the downside of language portability?

Not only does this require a native speaker of the language to translate the tuning software, but it also requires support to be provided in that language. Also, every new feature or change made to the tuning application will need N translations. This greatly slows the release of updates and bugfixes.

The question here is one of simple business. Will the extra sales gained by providing multilingual support justify the extra costs for providing it?

Productivity Enhancing Features:

There are some features that would greatly improve the productivity of a tuner. The objective here is to get them up and running in as few minutes as possible.

Here are a few ideas:

Stock map repository:

Nobody wants a tuned car that won't start in the cold or doesn't cruise very well. Automakers have spent lots of money figuring this stuff out and really all we need is the ability to emulate the stock ECU so the tuner can concentrate on adding boost or fine tuning power output for the user's changes.

With many OBD2 cars this info can be read via a standard protocol. It would be nice if we could provide an online library of base maps to get a car running.

Wizards to get a unique setup running:

Sometimes a tuner will encounter an application not listed or so modified that the stock map will not be a good starting place. While some may be able to pull the proper formulas out of thin air it requires most to do some research. It would be nice to have some wizards to allow entry of details in a variety of ways, for example, cylinders, compression ratio, BSFC, injector sizes etc. With all this data we can calculate a number of values to make educated guesses so the initial map is easier to produce.

Internet updates:

Bugs are annoying. It would be nice to have bugfixes for the firmware and software a checked whenever the computer is connected to the internet.

History saved in each map:

Many times if you look at a tuner's computer you will find a pile of maps named: B18C5-leaner.bin, B18C5-idlefixed.bin, B18C5-racegas.bin and the list goes on.

It may be nicer to have a bin file format that will save notes and changes. This is especially useful when trying out new parameters. For example cold start enrichments where each new setting must be tried after some time passes. Reviewing the history would also be an invaluable feature.