[jonbill]

I dont understand much of this thread, but if 60-2 is too high a tooth count, you could borrow from the audi 135 decoder and effectively turn turn it into a 30-1.

[PSIG]

I dont understand much of this thread, but if 60-2 is too high a tooth count, you could borrow from the audi 135 decoder and effectively turn turn it into a 30-1.

Certainly a good idea once a viable signal makes it from the crankshaft to the processor. They you can manipulate it to your heart's content. Getting the information to the processor is currently the hurdle these edge cases present.

[PSIG]

@Eric H - You can certainly reverse-engineer (including very specific component choice values and factors), but yes, that would bring focus onto me for effectively enabling the process. It's not an issue until it is, and so-far has not been. No biggie for you, in-private, but general release of info would be quite detrimental to the DIY cause. Certainly other controlled releases of tech I have done or might do would be threatened. I hope you understand. The alternative is to avoid that scenario entirely, and suggest using a different circuit for issues specific to a project, when other factors are set in stone or unavoidable.

[Eric H]

No worries, I won't tell anyone.

[hindsight]

I wholeheartedly agree with the philosophy of looking holistically at the entire system, but like Eric, in my case I'm limited. The motorcycle I'm working on is somewhat rare, and the goal is to have a plug-and-play ecu replacement. The timing is built into the flywheel, which *could* be re-engineered and replaced, but it will be far more cost effective to tune the VR conditioner to ensure reliable signal.

Reducing the redline of the engine to c7300 isn't the end of the world, as the bike very rarely sees that end of the rev range, but in due course I'll test with MAX9926 and see where that takes me for now. Eric, I'll also be interested to hear where your investigations take you.

But also - I agree about understanding the limitations of the devices with which we work, I think it would be tremendously useful if guidelines were available (response rates, advised maximum frequency, and your advice on falling edge, for example), without revealing commercially sensitive details about the product itself.

None of this should take anything away from the DSC product itself - it has worked, and has worked well - and I'm only seeing issues at the very ragged edge of the upper range, where most engines don't need to go.

[Jama]

Hi Eric,

Really interesting investigation you have going on here, and I've just caught up on Slack as well.
I'm James, the one behind DIY-EFI and the CORE4.
If you need any information about the circuits of the CORE4 I'll be happy to share them with you, also I'll be happy to try out any potential improvements.
Drop me a line on here, slack or email if you need anything.

James

[hindsight]

Hi James -

Thanks for the reply, I purchased my CORE4 from you right at the start of the lockdown... having the time on my hands has been quite handy

I'm neither qualified or knowledgeable enough to suggest hardware component improvements (sounds like Eric may well be though!), so I'll limit my replies to showing observations from some structured testing, and will benefit from learning what others think. What I'm doing here is definitely useful to what I'm trying to achieve, and I hope others can find some use from the data that I'm generating. I can see some software enhancements that we could make to help speeduino accommodate these inevitable latencies from components, but that's a different discussion I guess.


For the benefit of those not on slack, I've done a bit of investigation today, expanding on what I was doing previously. I've created an automated test rig for measuring pulse duration and timing, whilst also providing a 60-2 signal generator to drive a crank signal. The results are quite interesting. Following on from the above conversation about VR Conditioners, I've plotted a bare MEGA2560, a CORE4 device with IGBT outputs, and a CORE4 device with the DSC conditioners and the IGBTs also. It certainly suggests that the components used to interface the MEGA2560 to the real world have a significant and increasing impact on spark timing as the revs increase (which would be natural, as components will each introduce a finite latency into the signal path). Chart below for reference. (note: I'm not yet wholly satisfied that the latency rise/retardation above 6250rpm on the black data series is real.. I'll do a bit more work on that in due course)

Once I get another conditioner for comparison, I'll publish another test report.



Mike

[Eric H]

Hindsight,
Are you using the falling edge as the trigger? It is very important that you do.
Using the rising edge will definitely give increasing lag as the tooth rate increases.

[hindsight]

Not yet Eric, I'll reconfigure as such once next time around when I start testing an alternate VR conditioner

Thanks,
Mike

[PSIG]

As we have established these are non-typical applications for common modules, and I have hopefully impressed users to first look at the entire package for best solutions; while modding the modules is not suggested, they can be minimally modified to "tune" signal performance for specific applications and hardware components. Modding simple I/O resistors have specific consequences, and changes should not be attempted without good understanding of goals and multiple effects and results. Modifications are always compromises.

With that said and for those desiring to tweak their signal performance for specific applications, the input and output resistors may be changed-out or piggybacked (stacked parallel resistors). The DSC may be treated as two separate signal processors, Channel 1 and Channel 2. This is important, as the ECM board filters are often of different values for crank and cam circuits, and must be tuned independently. As shown on your supplier's site, the Trigger Edge setting should be Falling, and VR sensor output polarity should be correct (approaching edge going high).

Tuning the DSC I/O:
In the image below, resistors are marked for input stage (IN1 and IN2) and output pullups (OUT1 and OUT2). Outputs should be tuned first in most cases. All tuning should be on the ECM, with the sensors and other components to be used when installed. Testing or re-testing under cranking and running conditions is strongly recommended in order to also tune for system noise as a strong factor. If there was no system noise, we could use an unfiltered perfect square wave, and no need for tuning. But all systems have noise. A square signal is not important, as Speeduino only reads one edge. A usable signal with clean falling edge and without noise is important.

Output resistors are simple pullups, and affect the output signal rise time and voltage, primarily affecting high-RPM. The DSC does NOT have any output capacitors, and output signal is most affected by ECM circuit filter capacitors. For this reason, the DSC output resistors have changed value in various versions as ECMs have changed filter capacitors. For faster rise time and higher high-RPM voltage peak, reduce the OUT resistor value incrementally. Alternatively, or simultaneously, reduce the ECM filter capacitor value. Excessive reduction of either alone may result in excessive noise (EMI) and lost signal or lost sync.

Input resistors are NOT shunt resistors, and are to regulate the input signal current to the input stage circuit. Input resistors are balanced to permit minimum-RPM signal response, while preventing over-driven signals at high-RPM. Generally, the input resistors are tuned as high-value as possible to prevent signal over-drive (loss of signal at high-RPM), without raising minimum RPM sensing (cranking) threshold above minimum low-battery cranking or ECM detection speed.

DSCv22_In-Out resistors_sm.jpg (109.38 KiB) Viewed 5374 times