Beta firmware to support interpolation

[brentp]

I'm very close to making available a beta firmware that fully supports interpolated calculation of ignition advance values.

The work involved a major rewrite of key portions of the firmware. Suprisingly, it only took a little bit of debugging before I was able to watch it operate correctly on the live test bench.

My main concern right now is I significantly increased the amount of processing needed to determine the proper ignition advance. As a result a noticable delay occurs between the reception of the PIP signal and the emitting of the SAW pulse. This may be an issue at higher RPM's, since the PIP signal occurs progressively more frequently.

In a day or so I will make the firmware available for testing- preferrably by those of you that have a test bench set up. If tested on an engine, it should be monitored *carefully* and under low engine load.

That's all for now!

Brent

[KITT]

Good work Brent! What rpm is higher rpm? And would running a faster oscillator help with the delay?

cheers

Matt Dearden
(2lt Pinto Cat)
http://www.cate1.co.uk/megajolt

[brentp]

It may be an issue at high RPMs on V8's, since the PIP signal occurs 2x as often as on the 4 cylinder EDIS. You don't want the system to 'run out of time' when sending the SAW signal back.

A faster oscillator could help, but this must be a software only upgrade. Plus, you don't want to run at the maximum rated speed of the processor for stability reasons.

Another option is to send the *last* ignition advance value, and caculate the next value in the off-time. This way the SAW pulse is sent back immediately, but the calculation is based on the previous ignition event.

Would this be an issue? It really depends on how fast an engine can accelerate/de-accelerate. Clearly, at a steady RPM, the ignition advance remains constant as well. When the engine accelerates, the engine at ignition event X is spinning slower than ignition event X+1. The question is will there be a problem to use the ignition advance value calculated at ignition event X for ignition event X+1.

Anyone care to run the numbers? What's the maximum acceleration rate we'll be seeing out there?

Other than that, I'm really pleased with how it's working. It's nice o finally see the ignition advance value transition smoothly across the ignition map.

If I have time, I may work in a "soft rev limit", where the ignition advance goes to zero degrees 500 RPMs before the hard ignition cut (based on the REV_LIMIT user defined output) Should be simple to implement.

Thanks,
Brent

[Josh_b]

does the time delay occur linear as rpm increases? or is an exponential increase in delay? compared to the current firmware could you gestimate the percentage delay at reaching say 7500rpm (4cyl motor) when compared to the current firmware? look forward to trying it

[GarethS]

Well done Brent, I have been following the forums (i.e. lurking) waiting for this for a while. I don't have a bench but I would be willing to try this on a low/unloaded engine that I will be setting up in the new year.

However I have a minor concern regarding the "high revs" you mention. Useful power on the cam for this engine will run out at 8k to 8.5k and the top limit will be 9.5k to 10k. Additionally it has a relatively low rotating mass so will be rather quick acceleration unloaded.

Good luck with the further work.

[brentp]

The firmware is ready for testing on an engine. For me, I'm limited to just idle testing and no load revving, since my MR2 is out of commission due to suspension work I'm doing.

I would love some brave souls to test this further. Be sure to start your testing under no load conditions, then progress to low load, making sure it works correctly.

You can download the beta firmware under the 'files' section.

Please let me know how your testing goes!!

Brent

[Northy]

Brent,

This is a great idea, it will save me buying an extra "black box" and would be a worthwhile adition.

IMHO this is more usefull than switching between to different maps on the fly, but that seems to be winning the poll!

Cheers

G

[aldrin]

Hi Brent,
I hope to be fitting my Mjl soon, great project.
I was looking through the source code I am not a programmer nor am i familiar with the motorola instructions. I have done a little low level coding and can usually follow well commented source code (eg. like yours)

It seems that the process of walking through the RPM table starts at the slowest RPM, meaning recovering the value for higher RPM takes progressivly longer.

Would it be better to start the RPM table at the highest RPM value and work down?
This would recovering values for high RPM with progressivly fewer program cycles, thus freeing processor time.

I couldn't find the source code for the Beta version, I was looking through the 'latest relese' one.

I'm not sure if I have followed the code correctly, of if it is applicable to the Beta version, but I just thought I would mention it.

Aldrin

[brentp]

Hi,

thanks for the insightful comments. The new beta software actually corrects this, along with a few other things, in addition to the big feature of adding linear interpolation (which is really cool, by the way!) I'd like to see some more feedback from all of you on the beta firmware!

Brent

[aldrin]

Hi Brent,

Is the source code for the Beta version posted any where ? It is interesting to try any follow it to findout how things are working.

Aldrin