When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
While testing, etc., I kept noticing two recurring blips after the reference sensor pulse on the scope. When I'd spin the motor in the normal direction, the blips would come just after the reference pulse, but if I spun the flywheel backwards the same blips would appear just before the reference sensor pulse. They behave just like the primary pulse, just smaller. Among other things, that means the get bigger as the RPMS go up. I got up to over 2 volts peak to peak at about 800 rpm. I'm guessing at redline, they'd be a good multiple of that. After scratching my head a while, I finally realized the ref sensor was picking up the two pins on the flywheel that are there for the third diagnostic sensor (the one many people remove as useless). I can spin the flywheel by hand and watch the signal blip as those two pins pass below the sensor. The DME has no problem with them obviously, but I can't help but wonder if they are causing some of the trigger problems people experience with stand-alone systems? The modern VR sensor conditioning chips are "adaptive" and are pretty good at differentiating phantom pulses (especially the MAX9926 chip), but still. Those chips can detect pulse in the millivolt range, so seems possible they'd be fooled. I can't say for sure if it's causing anyone issues, but if I were experiencing triggering issues with the stock sensors on a stand-alone system, I'd sure remove those two pins and see it if helps....! They don't do anything, and removing them is free, so worth a try...
Also note that the ref signal still starts on the upslope, as the DME requires, even with the motor spinning backwards. The only way for it to start on the downslope is to reverse the two sensor signals when installing the pins in the connectors.
Wow, you might be on to something there! I had always read that the Bosch ML 3.1 DME had a robust chipset for analog to digital signal conversion and postulated that this may be the reason some VEMS users are having trigger issues. But I never even considered those forgotten extra studs! They can be removed after removing the redundant sensor and rotating the engine until they are accessible.
This also shows the continued value of this forum due to longtime, knowledgable users sticking around and taking the time to test things and post results with actual data instead of hype! Like anything of that ilk, the current 944 Turbo Facebook groups seem to be all about instant gratification and "me too" posts---anything longer than two sentences is likely TLDR (too long, didn't read) for most users. Which is kind of ironic as these 30+ year-old cars require a fair amount of knowledge and skill to diagnose properly . . . .
Every time I get burned out on the trolls, off topic sniping and idiots regurgitating "facts" they know nothing about, someone comes out with something like this. Get a load of that test rig! Super cool Tom!
FWIW, aluminum flywheels, at least Fidanza, are too narrow to even have a place for the second and third pins. So I can vouch for Tom's assertion that not having them is not a problem.
If this nails the random standalone trigger issues, I'd say affected users owe you a drink Tom M. Where is the sensor located?
I don't have a pic right now, but have you ever seen the capped-off 3-pin connector attached to the bracket on the rear of the cam tower? That is the connector for the diagnostic sensor, which is mounted at the rear of the bell housing.
In the meantime, in addition to stand-alone trigger issues, I'm wondering if removing those pins might contribute to the all-too-common starter kick-back issue. Porsche officially attributed that issue to starter motor EFI and added a shield sleeve, but Porsche may not have felt free to give up on the diagnostic sensor. Somewhere in the inner sanctum of a Bosch R&D center, there's surely a zillion dollar piece of test equipment that relies on those pins. For the rest of us, they just add ballast. I spin that test flywheel with an electric drill, and I can see the EFI noise from the drill on the scope. I assume the starter motor is even worse -- so certainly understand how/why Porsche decided it was the problem. But the extra pins create a much heavier pulse than any noise spike, so you have to wonder. The pins in my test rig out in the open, so the magnetic fields are not interrupted as much by surrounding structures. It's 'possible' the phantom signals are slightly smaller on an actual motor as a result (which I'll test at some point), but they get bigger with RPMs and I'm spinning at below-idle speeds. Notching the bellhousing also removes a little strip of aluminum that might otherwise mute the phantom pulses to some extent. When I get the chance, I'm going to remove those pins from my car and see if it helps on the kick-back issue. Certainly can't hurt, and think of the weight I'll save.
Last edited by Tom M'Guinn; 04-04-2019 at 04:30 PM.
I had always read that the Bosch ML 3.1 DME had a robust chipset for analog to digital signal conversion and postulated that this may be the reason some VEMS users are having trigger issues.
The DME uses one chip to process both the speed and reference sensor, along with some large current limiting resistors and logic gates. The chip is labelled S100 on the DME and appears to be a proprietary chip designed specifically for this purpose. The raw AC signals from the sensors are not computer friendly. They can range from virtually nothing to over a hundred volts, with frequencies ranging from 3 or 4Hz to over 15KHz. Then add EFI from everywhere and it's clear why so many systems have a hard time catching every last pulse 15k times a second, while still weeding out every last stray pulse/noise at the same time. The S100 chip takes all that and turns it into two nice clean 5 volt (dc) signals that toggle to ground exactly as the pin or tooth passes under the sensor (at the so-called zero-crossing point). That signal is then sent to the two hardware interrupt pins on the 8051 processor, so the processor can keep track of each pulse as they occur, interrupting whatever other processing it is doing at the time. All-in-all, pretty amazing technology from an era when good calculators cost hundreds of dollars. There's no wonder why the Focus 9/Rouge DME re-uses exactly one active part scavenged off old DME's -- the S100 chip!
p.s., the S100 does not seem to exist on the early 944 DME. Dare contributed an old DME to the cause, and at some point I'll dig into that and see what they did to read the sensors. Presumably some combo of Schmitt triggers and comparators, etc., but the hope would be that all the components are standard parts so that the circuit can be recreated without need for the s100 chip.
Last edited by Tom M'Guinn; 04-04-2019 at 04:33 PM.
I don't have a pic right now, but have you ever seen the capped-off 3-pin connector attached to the bracket on the rear of the cam tower? That is the connector for the diagnostic sensor, which is mounted at the rear of the bell housing.
Yes I have seen it, and wondered what it's purpose was, thanks. I think the top 944 engineer in the UK said that the DME has a lot more capacity than Porsche needed for the 944.
Say, wouldn't removing those pins in-car be quite the challenge, given they apparently need heat to remove? Like playing "Operation" but with a torch lol
While we're on the subject of those pins and that sensor... what CAN you possibly read from that setup? RPM?
... Dare contributed an old DME to the cause, and at some point I'll dig into that and see what they did to read the sensors. Presumably some combo of Schmitt triggers and comparators, etc., but the hope would be that all the components are standard parts so that the circuit can be recreated without need for the s100 chip.
What about this MAX9926 chip? Is it not up to the task of reading these signals?
I've been thinking that if I can find a reliable circuit to digitize the signals, it should be possible to convert the speed and reference signals from a 951 into a simulated missing tooth signal that is compatible with after-market ECUs--e.g. a Renix 44-2-2 or 66-2-2-2 pattern. This would allow my Microsquirt ECU to run with the stock sensors. In theory it should be possible to implement the conversion in a small uC like an ATtiny25.
Very nice work, and thought logic. I'm thinking a zip wheel to cut off the other studs, or dremel tool.
I too have experienced the starter kickback, on occasion. And wondered what was going on.
The signal size and multiple points of undesired pickup, really drive home the sensor gap setting critical measurement.
I wonder if there is some Automatic Gain Control (AGC) going on as the REF sensor conditioned signal tunes out other signals. AGC in aircraft radar adjusts the threshold of reflected energy at the antenna, so only the largest signals are shown, to reduce video clutter. That would help explain why the starter kickback occurs, prior to the AGC function tuning out the other two near pins.
Much as the Don't Care premise in logic programming, the speed signals, establish allowable RPM ranges, based on tooth count, such that a reference signal, cannot be read more the once per 130 (if FW has 130 teeth) speed inputs.
Alan
What about this MAX9926 chip? Is it not up to the task of reading these signals?
I've been thinking that if I can find a reliable circuit to digitize the signals, it should be possible to convert the speed and reference signals from a 951 into a simulated missing tooth signal that is compatible with after-market ECUs--e.g. a Renix 44-2-2 or 66-2-2-2 pattern. This would allow my Microsquirt ECU to run with the stock sensors. In theory it should be possible to implement the conversion in a small uC like an ATtiny25.
The MAX9926 could turn an ant's EKG into a digital pulse! It was literally too good for my purposes, at least on the bench. Whether it is that good at 6500 rpm while bombarded with EFI noise, I dunno, but all reviews are great. I haven't used that uC, but its stats look sufficient for that. At 16MHz, for reference, the ATMEGA328 would have no problem turning the speed/ref signals into either of those pulse patterns. The challenge that comes to mind is not creating the pulse, but rather getting the zero-crossing points right. With so many fewer pulses, you could have the right pulse pattern and timing "right" but still be off 6 to 8 degrees without careful attention to how/when you fire each pulse. But hey, that's what software guys are for...
p.s., I have a MAX9926 evaluation board you're welcome to have in return for the old DME. I may have fried the actual chip on it (oops) but think I have spares you could swap in. PM if interested.
Originally Posted by Alan 91 C2
Very nice work, and thought logic. I'm thinking a zip wheel to cut off the other studs, or dremel tool.
I too have experienced the starter kickback, on occasion. And wondered what was going on.
The signal size and multiple points of undesired pickup, really drive home the sensor gap setting critical measurement.
I wonder if there is some Automatic Gain Control (AGC) going on as the REF sensor conditioned signal tunes out other signals. AGC in aircraft radar adjusts the threshold of reflected energy at the antenna, so only the largest signals are shown, to reduce video clutter. That would help explain why the starter kickback occurs, prior to the AGC function tuning out the other two near pins.
Much as the Don't Care premise in logic programming, the speed signals, establish allowable RPM ranges, based on tooth count, such that a reference signal, cannot be read more the once per 130 (if FW has 130 teeth) speed inputs.
Alan
Re sensor gap, see my video in the other post on this topic!
If you cut them off, I just worry you'd never be able to get them out and/or back in if ever needed. If removing them throws the flywheel out of balance (??), I'd be inclined to replace them with stainless or brass set screws to maintain the weight without the trigger effect.
On the modern VR conditioning chips, there is something akin to AGC. Both the LM1815 and the MAX9926 look for the next signal based in part on how the last one looked. The LM1815 seems less sophisticated but both are "adaptive" in real-time. To over-simplify, as the true pulse amplitude grows, so does the trigger threshold for the next pulse. I'm using a microprocessor in my project and have coded/implemented a very modest version of the "don't care" concept for one aspect of it, but I don't know if Bosch did that with their coding (though I've never heard of them doing it).
Originally Posted by Dan Martinic
While we're on the subject of those pins and that sensor... what CAN you possibly read from that setup? RPM?
On a practical level, they have no known usefulness really.
The MAX9926 could turn an ant's EKG into a digital pulse! It was literally too good for my purposes, at least on the bench. Whether it is that good at 6500 rpm while bombarded with EFI noise, I dunno, but all reviews are great. I haven't used that uC, but its stats look sufficient for that. At 16MHz, for reference, the ATMEGA328 would have no problem turning the speed/ref signals into either of those pulse patterns. The challenge that comes to mind is not creating the pulse, but rather getting the zero-crossing points right. With so many fewer pulses, you could have the right pulse pattern and timing "right" but still be off 6 to 8 degrees without careful attention to how/when you fire each pulse. But hey, that's what software guys are for...
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).
p.s., I have a MAX9926 evaluation board you're welcome to have in return for the old DME. I may have fried the actual chip on it (oops) but think I have spares you could swap in. PM if interested.
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?
04-04-2019, 12:27 AM
Yet more fun with speed and ref sensors...
Where is the sensor located?
