Yet more fun with speed and ref sensors...
04-05-2019, 01:18 PM
#16
Rennlist Member
Hi Tom,
A fairly simple interface box with 16 MHZ and fast A to D, could create a virtual missing tooth output using the Speed and Ref signals. Using an AGC type approach with ring gear tooth count predicting a 10 deg (or less) window for Ref sensor location (would eliminate false Ref sensor location readings)
The starter kickback can be eliminated by requiring a full rotation, 360 deg, before allowing sensor output to the ECM (no spark first revolution). I expect kickback is caused by a false read of the diagnostic pins before the first full revolution.
Keep up the good work.
A fairly simple interface box with 16 MHZ and fast A to D, could create a virtual missing tooth output using the Speed and Ref signals. Using an AGC type approach with ring gear tooth count predicting a 10 deg (or less) window for Ref sensor location (would eliminate false Ref sensor location readings)
The starter kickback can be eliminated by requiring a full rotation, 360 deg, before allowing sensor output to the ECM (no spark first revolution). I expect kickback is caused by a false read of the diagnostic pins before the first full revolution.
Keep up the good work.
04-05-2019, 05:24 PM
#17
Rennlist Member
Thread Starter
Ha! Yep, that's my life!
My thinking is that the code paths in the uC would be entirely deterministic and fixed cycle count. Basically a bare-metal interrupt handler with a small, carefully cycle counted service routine. Thus the skew from the input to the output should be minimal relative to the rotational speed, and accurate based on the stability of the uC's clock. This approach should be straightforward given an integral ratio between the input and output teeth--e.g. the 951's 132 tooth/rev to the Renix 66 tooth/rev.
(Edit in case it wasn't completely clear: I'm envisioning the uC would work entirely in the digital domain, with the MAX9926 [or equivalent] handling the analog-to-digital conversion).
Thanks! I may take you up on that. Of course, what I really need is access to that swank test bed you have! If I prototype the software for the uC maybe we can have a testing party at your place some day?
My thinking is that the code paths in the uC would be entirely deterministic and fixed cycle count. Basically a bare-metal interrupt handler with a small, carefully cycle counted service routine. Thus the skew from the input to the output should be minimal relative to the rotational speed, and accurate based on the stability of the uC's clock. This approach should be straightforward given an integral ratio between the input and output teeth--e.g. the 951's 132 tooth/rev to the Renix 66 tooth/rev.
(Edit in case it wasn't completely clear: I'm envisioning the uC would work entirely in the digital domain, with the MAX9926 [or equivalent] handling the analog-to-digital conversion).
Thanks! I may take you up on that. Of course, what I really need is access to that swank test bed you have! If I prototype the software for the uC maybe we can have a testing party at your place some day?
Back on the hardware side, the MAX9926 will create a good pulse, but all the uC interrupt pins I've tried have hair triggers so are also vulnerable to noise, meaning you can get false triggers at the uC despite perfect output from the MAX9926. Bosch sent both outputs from the S100 chip through 74xx02 logic gates before triggering the interrupt, one of which is hard-wired to never change -- so whether that was to bump the output current, act as an inverter, filter out noise, or do something else, I don't know. You are more than welcome to test software on my test rig. Once I finish my project, I can even loan it out.
I ended up getting a $100 function generator, which creates a perfect speed sensor output without effort. It also claims to be able to do arbitrary waveforms like the ref sensor, but that requires programming at a desktop computer which I haven't tried yet. 
04-05-2019, 05:31 PM
#18
Rennlist Member
Thread Starter
Hi Tom,
A fairly simple interface box with 16 MHZ and fast A to D, could create a virtual missing tooth output using the Speed and Ref signals. Using an AGC type approach with ring gear tooth count predicting a 10 deg (or less) window for Ref sensor location (would eliminate false Ref sensor location readings)
The starter kickback can be eliminated by requiring a full rotation, 360 deg, before allowing sensor output to the ECM (no spark first revolution). I expect kickback is caused by a false read of the diagnostic pins before the first full revolution.
Keep up the good work.
A fairly simple interface box with 16 MHZ and fast A to D, could create a virtual missing tooth output using the Speed and Ref signals. Using an AGC type approach with ring gear tooth count predicting a 10 deg (or less) window for Ref sensor location (would eliminate false Ref sensor location readings)
The starter kickback can be eliminated by requiring a full rotation, 360 deg, before allowing sensor output to the ECM (no spark first revolution). I expect kickback is caused by a false read of the diagnostic pins before the first full revolution.
Keep up the good work.
I'd agree with the first full rotation theory, except that it doesn't line up with my experience. I run e85, and on very cold days I need to crank it more to get it to light up. I've had kick back happen after plenty of constant cranking...
04-07-2019, 04:56 PM
#19
Rennlist Member
Hi Tom,
The kickback after multiple revolutions affirms the software does not look at an expected range of allowable positions for the Ref signal to occur. But in fact looks at amplitude, which is a product of cranking RPM. So an uptick in cranking RPM could be interpreted as Ref signal level.
The kickback after multiple revolutions affirms the software does not look at an expected range of allowable positions for the Ref signal to occur. But in fact looks at amplitude, which is a product of cranking RPM. So an uptick in cranking RPM could be interpreted as Ref signal level.
