Decoding Nissan style Mitsi Electric 360 slot cam sensors

[Fred]

http://www.ms3efi.com/viewtopic.php?p=202#p202

Yep, the DSP devices on the table can sample the ADC at a minimum of 1MHz. In fact the 56F8013 can be pushed even faster. However, the limitation becomes the event clock rate of the xgate setup of 1 MHz, having the DSP run any faster will not help. Consider that on every 1usec the Xgate checks the logic level of the DSP output waveform, its either high or low. If the DSP samples and processes zero-crossings at 1usec, its output will either be high (VR voltage higher than threshold) or low (lower than threshold). Even if the DSP was cranking at 100MHz the limitation would be the master 1usec sample clock on the xgate side.

For the question of 1usec being fast enough, I use the relation:

delta_time (millisec) = (166.7 * degrees_crank_between_teeth)/RPM

Assuming a worst case wheel of a tooth every one degree (or 360 teeth) and a RPM of 10,000, the relation yields a value of 16.67usec time between teeth events. The DSP/xgate sample at 1usec, so there will be 16 sample events in this time window. So it can be said that at 10,000 RPM the sampling resolution is 1/16 of a degree (someone check my math, I am tired right now..). I would say that 1/16th of a degree resolution at 10,000 RPM is in the range of being good enough!

Said another way, taking the above relation and rearranging (solve for RPM), the RPM to yield a 1usec delta_t value (with one degree tooth spacing, or 360 teeth) is 16,700RPM

Optispark's high-res channel can just bite me!

- Bruce

I agree :-) However I don't know if much code will be running between each! More likely a simple counter should be used, but I guess if it was optimised you could read it directly. However physical jitter would probably become an issue then.

Fred.

(extra emphasis added to opti comment)

[SleepyKeys]

My plan is to use a counter so that is has a resolution similar to a common crank trigger. Figured that way the main code would operate without knowing the difference. An old unix guy is supposed to help get started with gcc inline asm. We'll see if he comes though. If not a dive into the xdp512 docs should do the trick.

[Fred]

You would be better off doing the entire ISR in asm, and keeping it very short and simple. Having said that, do it in C first and see what the generated ASM looks like, it could be perfect already given how dead simple it is to just increment a variable.

You shouldn't need to put an dirty ASM in our code base to achieve your goals.

Fred.

[MotoFab]

My plan is to use a counter so that is has a resolution similar to a common crank trigger. Figured that way the main code would operate without knowing the difference. An old unix guy is supposed to help get started with gcc inline asm. We'll see if he comes though. If not a dive into the xdp512 docs should do the trick.

Are you talking about using a divide-by-n counter, Sean?

- Jim

[SleepyKeys]

I'm not sure exactly what instructions are available to me with the 12x/gate but I'm they may be along the lines of divide-by-n. I guess worse case a simple cmos IC would solve the problem. I would like to keep the solution native to the xdp512 code space.

As soon as I get everything moved to my new place I should have some real time to dedicate to freeems. So far I have been disappointed with my contribution(s)..... But sometimes you gotta do what u gotta do.

[MotoFab]

I'm not sure exactly what instructions are available to me with the 12x/gate but I'm they may be along the lines of divide-by-n. I guess worse case a simple cmos would solve the problem. I would like to keep the solution native to the xdp512 code space.

That's what I thought you were talking about, using a divide-by-n 74HC part of some sort.

Inside the processor, you can use every 45th falling edge of the 2° signal and make a 90° signal out of it. Or, whatever way you want to slice it up.

- Jim

[Fred]

BTW Sean, I did some testing last night and measured two significant functions at less than 0.8us run time. If you simple do a outerRingCounter++ and nothing else in the ISR you should be totally fine. Then the count information can be handled in the secondary ISR to determine which cylinder it is. How come you get all the easy jobs :-p ;-)

Don't worry about contributions/no contributions. Offering to buy the board without knowing me so early on was a fairly telling move on your part. Much respect for that.

Now, pull your finger out :-p (jokes ;-) )

Fred.

[BenFenner]

Not sure how much help I can be but I've dealt with the Nissan trigger situation a bit. I've got a USDM SR20DE engine with VEMS engine management. VEMS can't keep up with the amount of information the stock CAS disc pushes out, so a replacement disc must be used. Some folks experience this on RWD SR20DE(T) engines with AEM's EMS as well. Once again, I'm not sure how much help I can be, but I do have a lot of pictures and measurements of two different types of SR20DE CAS discs. Pages 1 - 3 of my project build thread on the VEMS forum have the detailed pictures and other findings that might be of help.

http://195.159.109.134/vemsuk/forum/ind ... 215.0.html

I had to swap my entire distributor/CAS for a newer (smaller) design so I've got the old one laying around if someone could make use of it for experiments.

[Fred]

Hi, welcome along :-)

Isn't it nice that VEMS doesn't magically become "another ECU" lol. It felt strange reading it actually. Good to see!

For me the Toyota decoder is most important as that will be my test mule if I get that far in the UK. Once I get home it could be any of Toyota, Mazda, 36-1 or Nissan that I need for testing. For Sean though, he has the LT1 optispark unit and wants to make good use of it so that is his priority. In other words, I don't need any test equipment, and Sean already has his own.

Thanks for offering though!

Fred.

[SleepyKeys]

Here is a basic sketch of what I was thinking as a way to decode this beast. ANY input would be appriciated!!!





when I say primaryISR and primaryISRcode I'm referring about two different loops. primaryISR will be very tight. primaryISRcode would be Freds primaryISR loop. Essentially this would make the OPTI into a 24x pseudo crank trigger.