EGO correction and it's importance/downsides/gotchas

[Fred]

I think you need to re read my posts.

I never told you that you were wrong. I just told you that coding something that writes flash on the fly without human intervention is something I personally am very strongly interested in NOT doing. As opposed to not interested in doing it.

There is a lot more to that than perhaps meets the eyes. I personally think it is a bad idea, although I see your particular use for it. The fact that OEMs do this is not a good argument either as they have different motivations and reasons than a home modifier.

What you have done is show up, and start posting without reading a great deal. That is fairly typical, however don't get upset so easily when you post on something that was decided months and months and months ago and wonder why you are told that I won't be writing such code.

Priorities are :

VERY high accuracy of timing and values
Code architecture
Wheel decoding
Flash burning
Serial comms (decent serial comms)
Good basic SD maths
Sequential fuel
Coil per plug ignition
Port management

etc.

Catering for those that change components more often than reasonable is not high on MY list of things to do. Your list may vary and you are welcome to pursue that list here. However any ECU can work impeccably without AFR/EGO correction.

Additionally, I know quite a few bike owners that don't change heads, exhausts, etc often. In fact, if you changed such components often enough that retuning was an issue on the time frame front, you probably wouldn't have time to sleep or eat either. Why would you change a head often anyway? Poor cooling? Poor port work? Poor manufacturer design? I know most jap bikes happily do large mileage without issues and make high specific power too. Most people like to consider the mods they do before they do them and choose wisely so they can spend more time driving the vehicle than modifying it. How often exactly are you talking here? Daily? Weekly? Monthly? Why not finish the bike and then tune it?

Regardless of any of your answers, the most important things here are those that benefit all users. Writing to flash on the fly benefits a VERY narrow range of users and for that reason mainly is not high on the list of things to do.

You seem to have come in here with some very fixed ideas and an lack of willingness to discuss them. Perhaps spend a bit more time reading first and then start throwing opinions around once you are familiar with the foundations of this site and reasons for doing this at all :-)

Thanks for your input so far, most appreciated.

Fred.

[Fred]

For those following and thinking my last post is out of place the following message was heavily edited...

The programming for this is not significant AT ALL.

I think you misunderstood some of my words in my prevous post.

I dont want to argue about this anymore. Hopefully the ems will be designed in such a way that evolving it into different directions will be easy.

Fred.

[austinbob]

How much flash memory is onboard this microprocessor?

What are the problems with writing to flash memory?

Does the current design have a datalog capability? If so, where is the data written?

[austinbob]

wonder why you are told that I won't be writing such code.

Any suggestions I have do not assume that you will have to write the code. I plan to be fully capable of writing any special code. That is one of things that I hope to learn here. I will write the code that implements the auto-tuning.

[Fred]

How much flash memory is onboard this microprocessor?

What are the problems with writing to flash memory?

1. 512K 32K of which is always accessible.
2. 10000 write/erase cycles per block (4 blocks)

[Fred]

How much flash memory is onboard this microprocessor?

What are the problems with writing to flash memory?

Does the current design have a datalog capability? If so, where is the data written?

Please READ your PM. If you keep editing messages at the rate you are I will remove your ability to edit posts.

3. The current design has no data to log and no where to log it. Any useful datalogging will be external to the CPU at the least, and possibly external to the box.

[Fred]

Any suggestions I have do not assume that you will have to write the code. I plan to be fully capable of writing any special code. That is one of things that I hope to learn here. I will write the code that implements the auto-tuning.

You have missed the point. For normal users it is not desirable to have it. As such official releases probably won't carry code that does that. Maintaining a patch to do it on your personal unit should be no problem though.

Fred.

[austinbob]

Please READ your PM. If you keep editing messages at the rate you are I will remove your ability to edit posts.

If you remove my abilit to edit my posts I will leave the forum.

[austinbob]

1. 512K 32K of which is always accessible.
2. 10000 write/erase cycles per block (4 blocks)

I know that the two ecms I have used on my bikes have the ability to store data for later download and display. Can you please give me some idea of how they are doing this? For instance the last 30 minutes of 30 different recorded parameters are stored in my current ecm. How are they doing this?

[Fred]

Please READ your PM. If you keep editing messages at the rate you are I will remove your ability to edit posts.

If you remove my abilit to edit my posts I will leave the forum.

At the rate you are going, you won't need to. Please mind your attitude and take care posting. IE think first, read first, consider first, research first, and then post once you know what you have to say. That way edits are for later corrections and additions when you want to keep things compact etc.

If you have trouble with this, please check with Little Billy for guidance.

I know that the two ecms I have used on my bikes have the ability to store data for later download and display. Can you please give me some idea of how they are doing this? For instance the last 30 minutes of 30 different recorded parameters are stored in my current ecm. How are they doing this?

There are dozens of ways that this could be done and they are all in hardware. Our hardware can't do that, and I don't want it to.

You need to look at this from the greater good point of view. Logging is a distinctly separate thing from RUNNING the engine. Therefore it is best isolated into it's own block of functionality. Remember that the hardware will be freeform too. What that means is that the core stuff has to support the core stuff well. If we try to get a core thing supporting everything we will end up in a mess like MS is. There will be a lot of things that are vastly different about this system to MS and other ECUs and they will be different for GOOD reasons.

Fred.