Wheel decoder/scheduler architecture

[Fred]

I'd like to clarify/backtrack/apologise about a few things here.

I still think that the actual pattern handling MUST be low level and pattern specific.

I now know that the math IS too slow to run inside the ISR, BUT, it's fast enough (so far) to run for every event at most RPMs.

What I thought of a week or two back, and started to clarify more recently is the following :

• Specific code runs to determine if a tooth is valid etc
• That specific code uses a generic array to store the timings inside by tooth count and position
• For each ADC sample, the math code runs, determines if, when and for how long each of the maximum possible 24 pulses occur, calculates which tooth is best to schedule from, calculates the appropriate delay from that tooth, loads the data into a generic array
• For each tooth the scheduler runs through the array and configures required pulse widths to start as pre calculated

I guess it depends how you define "to schedule". Months ago when posting to this thread I was thinking "configure the pulses to start" AND "figure out when to start them" which I guess are both parts of the overall scheduling process. So then, if you look at it like that, then yes, some scheduling will run in the main math section and the ISR will just dumbly start whatever requires starting.

As for math etc, there will still be quite a bit done in the ISRs for the purposes of discarding teeth etc. I think for quick reaction for RPM cut effectiveness there should be a "rough" RPM calculation done in the ISR too and no ign and/or fuel scheduled/started if the limits are exceeded etc.

The math code can analyse the tooth timing data recorded by the ISRs to generate an accurate RPM and Delta RPM and Delta Delta RPM to base calcs and timings from.

Fred.

BTW (Off Topic), the HAL is something that is definitely a good thing to have for everything else, I've discussed that in a number of places referring to it as "port configuration code" or similar. I should find/start a thread dedicated to that as it's very important to have that working well for the simplicity of setup and configuration. The only other viable alternative is to have various features hard assigned to various pins which is ugly, but could work for a large enough pin count. If the number of features was less than the number of pins it would be desirable to have no choice about where to put things, just hook it up and turn it on. You can't get more simple than that.

[Fred]

I'd like to discuss conditions under which sync will be declared to be lost and how the scheduling code should function.

Firstly, for VR sensors, the timing MUST be done from the trailing edge of the signal. This is the case because of leading edge hysteresis causing different timings at different RPMs if the leading edge is used, whereas the trailing edge is a clean specific point every time, or at least it should be.

So, during operation, we know the angular velocity at each tooth via a simple distance between and time between calculation. We know the specific width of each tooth in angle from config, and we know the time elapsed since the last tooth pretty much up front. Thus, we can decide to ditch a tooth and optionally lose sync if we notice that :

• The tooth is too wide
• The tooth is too narrow
• The tooth is too early
• The tooth is too late

Some amount of this checking can be done in hardware for particularly narrow teeth to avoid costly CPU time from high frequency noise. I haven't tried this yet, but I will make it user configurable and include it in the operation of the machine for sure.

The first two must be calculated on the trailing edge as the width is required, the other two would be best done on the trailing edge also, however because the hysteresis is consistent at any given RPM, the leading edge is fine for that too. Putting it in the leading edge code will ensure that each interrupt runs optimally quickly thus minimising latencies to other processes.

Additionally, if the basic main teeth are coming in in what appears to be the correct size, speed and order etc, the secondary teeth (where used) could be out of time also, and at least used to confirm that the other teeth have been recorded correctly. For example, if the secondary trigger comes along and finds that only 10 primary teeth have been counted instead of 12 it can also lose sync.

So, to distill it a little more, for the primary Denso teeth (12/24) the following need to be checked :

• The tooth is too wide - trailing edge
• The tooth is too narrow - trailing edge
• The tooth is too early - leading edge
• The tooth is too late - leading edge
• Primary tooth count too high - leading and/or trailing edge(s)

For the secondary teeth (1/2) the following need to be checked :

• The tooth is too wide - trailing edge
• The tooth is too narrow - trailing edge
• The tooth is too early - leading edge
• The tooth is too late - leading edge
• Primary tooth count too low - leading and/or trailing edge(s)

That should help me suss it out. It's good to put it to "paper" before starting to write code for something like this.

Fred.