Do we need another 3D ignition system?

[Joe 90]

I'm thinking of building my own 3D ignition system, and I'm wondering if it would be of interest to anyone else. I would make it not only fully mappable but I would develop the software as open source freeware. This would allow anyone to modify the functionality and to add new features.

 

Would anyone else be interested?

 

I will be on the road by Christmas. Photos here

[Irrelevant]

I'm surprised none of the existing EMSs don't use open source software(O/S). I can see why from one commercial angle - it gets them custom when a change is needed and protects their IPR, but from a quality aspect, O/S would be unbeatable - just look at the software world, O/S is extremely successful - GNU/Linux, Apache, Tomcat, JBoss, etc. etc. The most impressive thing is the speed at which it evolves and how quickly problems are resolved.

If your idea was to work, you'd need powerful hardware to run the EMS, something with plenty of spare inputs/outputs, which had a fair bit of processing power/memory. Without this I doubt anyone would bother using it, unless it was extremely cheap.

If you had some really meaty hardware, along with a base EMS program/GUI - something to base developments on, I think you'd have a good chance at attracting some of the real brains lurking around this forum. Once you get a couple of them involved and start getting some really fancy functionality, more people will get involved and the thing will snowball. That's why absolute top end hardware is essential - because you'll need it very quickly and you can't afford to have the hardware limiting the development.

You'd also need to select whatever programming language is used very carefully. You'd want something that is simple to write, understand and document. I think a lot of mobile phones, as well as car and burgler alarms, use some flavour of Java - don't know which one though. Java moves so fast, they're forever bringing out new application frameworks and development kits and it's a long time since I was involved with it. Maybe there is something better to use - someone will know and no doubt post a recommendation.

 

I think you've got an excellent idea. I wish I could help but it's not really my area of expertise. I'd certainly be interested in how things go. If the EMS lived up to potential I would of course get one, as I'm sure many other people would.

 

J351 TPE . . . battered old X/Flow

[Graham Perry]

Isn't someone else on here already doing something like this (Bill Shurvinton ?)

 

Edited by - Graham Perry on 15 Dec 2003 22:38:40

[oilyhands]

There is also the DIY EFI system (Mega-squirt) which has open source code and hardware design, why re-invent the wheel? The website is well publicised and AFAIK there is an active forum that would welcome further input.

 

It is interesting to see that vendors of O/S systems are trying to 'brand' the products and adding value to try to break the 'open' mold...

 

Having written bags of code at very low level, the fewer people involved in a project the tighter and more efficient the code, once committee coding starts things expand into nebulous masses of often unnecessary code extremely rapidly. Ok for utlities etc. but not ideal for kernels, device drivers and microcode.

 

Oily

[Joe 90]

I've had a look around DIY EFI, but that's not exactly open source, more code sharing.

 

The comment about running on powerful hardware ties up with my thinking. Flexibility really has to be the key feature, because an off the shelf solution is fine if your needs are fixed. I was thinking along the lines of a power/IO board with a processing board as a daughterboard module. This would make it possible to quickly add new IO stuff.

 

Development must be easy and quick. Developers are going to give up if they add a little feature and the CPU runs out of processing power. Assembly language is out, C++ and Java are in.

 

Features I would like to see are:

USB PC interface for programming, mapping, data logging.

 

Screwdriver map adjustments (e.g. on the rolling road, no programming hardware or software neccessary)

 

Really good diagnostics. The ECUs know everything, they just wont normally tell you.

 

Anything else?

 

I will be on the road by Christmas. Photos here

[Bill Shurvinton]

No point doing anything new.

 

The megasquirt does for 99% of needs now. For the other 1% there is a C version that has been done using the atmel chip and next year the UMS will come out, which will be in C and have native wideband support, which means it will fully autotune. Set the target AFRs and drive off.

 

In the UK there are a number of kitcars already running MS, from rotaries, through Zetecs to RV8s and even a turbocharged hillman imp. Whilst there is no traction control in place, there is launch control and a basic flat shift, support for turbo apps, staged injection and water injection. There is also a remote display that you can use to tune on the fly.

 

In the US it is running on 1000HP drag motors.

 

So unless you want to add ABS, traction control or flybywire (which I am writing, just haven't gotten far) I'm not sure if you would add much other than an interesting personal project.

[Joe 90]

I didn't know about the megasquirt. It certainly looks interesting, although it also doesn't do ignition. Assembler isn't my idea of fun, but with a low performance processor I guess C++ was never going to be realistic. Poking around the web site, it looks like they are going to more powerful systems though.

 

I will be on the road by Christmas. Photos here

[Bill Shurvinton]

It does, just they don't update the website much. There are code bases for dizzy and DIS ignition systems already. There's a Zetec engined W****y recently fired up on that this weekend.

 

The reason for assembler is no free C compiler for the HC08. The HC12 that UMS uses does have this. The HC08 is NOT low power though. At 8MHz it does the fuel and spark calculations 1500 times per second to stop itself getting bored.

 

However for 100 quid you can't grumble. Cheap EFI for the masses. Luv it.