Originally Posted by Jonny H (Post 9038093)

Let's clear a few things up:

'Firmware' is generally used to describe code that is 'embedded' in a device, but yes at the end of the day it is still software :)

Things may be cheaper in the US but in the UK right now (all prices before tax and shipping):

Permatune. £494
MSD 6AL-2 + blaster coil . £505
Original Bosch (used). £400 - 600
Classic Retrofit. £795 - £995
Elf ignition. £900 - 1200
Porsche Original OEM Bosch. £2400

All our units are made in the UK, hand assembled, soak tested and setup per customer requirements in house.

Originally Posted by Jonny H (Post 9037835)

Ok, my patience is wearing a bit thin but I will attempt explain, again, why we move the input trigger point.

Mr West is describing a 'predictive timing' scheme whereby the ECU tries to 'guess' when the next spark should occur.

At the most simplistic level, this is done by making an assumption that the next spark will occur in the same time interval as the last timing gap measured.

More complex systems, use a predictive algorithm which needs to be 'tuned' as most are based on a (sort of) PID contoller.

Predictive systems cannot cope well with rapid changes in RPM.

In this case we need to define "rapid". Even a relatively inexpensive microprocessor, $2-3, would have enough computing power/capability to "predict" the next firing point based on a multiplicity of parameters, including rate of rise, or fall, in RPM.

They tend to lag and then overshoot.

Only if the selected microprocessor instruction execution rate is too slow for the task (tasks ?) at hand, or the multi-tasking burden is so great that not enough time is left for proper computation of the various parameters involved. I would guess the latter in the case of the CDI+ design.

They also do not work very well if there are not a sufficient number of triggers in the engine rotation to calculate the time interval and that is why these systems typically require the use of a toothed timing wheel (more triggers per rotation). As our system uses the points/VR, we have only six trigger points. We have tried out a predictive scheme but the results were poor. The engine idle was unsteady and the pickup was unresponsive.

The only way to guarantee that the timing is accurate is to move the trigger point forward in time

so you are always calculating a hold off ahead of the cylinder you want to fire.

So, how does your 10 degree predictive timing computation differ from the 60 degree one? That 10% advance trigger input time to plug firing varies greatly in timing from 800 RPM to 7000 RPM! So your programming must use current RPM as a computational parameter, and done correctly would have a parameter for rate of RPM rise/fall parameter.


It isn't adjusting changing the ignition timing, it's moving the trigger point. This is no different in fact to fitting a Pertronix where you have to re-time the engine.

The timing compensation is primarily concerned with dialing out any delay caused by input filtering. Nothing to do with the microprocessor.

The firmware updates are about adding features. Since the product was launched we have added:

1) Tacho smoothing
2) Distributor input smoothing
3) MFI fuel pump cut-off control
4) Configuration of interval between dual sparks
5) Configurable number of triggers before first spark
6) Programmable output / shift light control. Inversion etc.

None of those affect the main operation of the unit and many customers are still on version 1.0.

We are looking at being able to read a MAP sensor from an input and also driving an additional fuel injector from an output.

Originally Posted by wwest (Post 9038726)

In some cases firmware does not correlate with/to software, FPGA configuration memory download, for instance.

Example: Strobe Data Osprey QXP

FPGA configuration is down loaded with each power on cycle.

Originally Posted by wwest (Post 9038726)

In some cases firmware does not correlate with/to software, FPGA configuration memory download, for instance.

Example: Strobe Data Osprey QXP

FPGA configuration is down loaded with each power on cycle.

Originally Posted by Jonny H (Post 9038922)

Yeah, I give up.

Omex, MSD, Megasquirt and many others employ the same 'hold off' scheme we do for timing. It isn't a new thing, been around for ages yet Mr West singles us out for a fight? I just don't get it.

Btw, FPGA config is not firmware as there are no executable instructions, just logic. Now how do I get that stupid wavey smiley? Ah, here it is SmileWavy

Originally Posted by wwest (Post 9039041)

Why does the term "firmware" not apply to a stream of 1's and 0's downloaded to an FPGA...??

And if not then what term is correct?

Yes, it seems that the term "software" always applies to executable code.

And "firmware" seems to apply primary to software that is somehow embedded, executing from ROM, or at power on time transferred from to ram for execution.

Originally Posted by Jonny H (Post 9038922)

Yeah, I give up.

Omex, MSD, Megasquirt and many others employ the same 'hold off' scheme we do for timing. It isn't a new thing, been around for ages yet Mr West singles us out for a fight? I just don't get it.

Btw, FPGA config is not firmware as there are no executable instructions, just logic. Now how do I get that stupid wavey smiley? Ah, here it is SmileWavy

Originally Posted by wwest (Post 9039081)

A dual rank hardware down count register pair, one of which is currently in active use, triggered by the 10 degree advance distributor signal, and triggering the spark circuit upon reaching zero count. The second register will be pre-loaded with the results of the computed "guess". Those results computed based on the previous time period between firings, adjusted by a parameter reflecting the rate of rise or fall of RPM.

Once a plug firing occurs the second register is loaded with the new down count value and the cycle begins yet again.

The above hardware implementation would easily free up enough processor time to accomodate multi-tasking routines.

Originally Posted by Mothy (Post 9038804)

Jonny

Don't engage with him - no matter what you write he will pick fault - he can't help it as he always has to be the only guy who is right and he does it by letting everyone else know they are wrong.

One day he will grow up and understand that research does not just mean bullying everyone else to their point of view.

In the mean time just ignore him - we all do.

And keep up the interesting work. If the results are good it will sell itself.

Tim

Originally Posted by wwest (Post 9039081)

I'm going to go out on a limb here and make you a bet. I'm betting that if you check with the lead CDI+ designer that you will find....

A dual rank hardware down count register pair, one of which is currently in active use, triggered by the 10 degree advance distributor signal, and triggering the spark circuit upon reaching zero count. The second register will be pre-loaded with the results of the computed "guess". Those results computed based on the previous time period between firings, adjusted by a parameter reflecting the rate of rise or fall of RPM.

Once a plug firing occurs the second register is loaded with the new down count value and the cycle begins yet again.

The above hardware implementation would easily free up enough processor time to accomodate multi-tasking routines.

Originally Posted by ischmitz (Post 9039455)

We should start a periodic thread about chipping an air conditioner with oil additives to improve multiple spark Kettering ignition systems with optical coils....