60-2 sync losses over ≈2k rpm

For discussing and developing different RPM/Position decoders using our superior modular architecture! One thread per pattern, please.
User avatar
ruzki
QFP80 - Contributor
Posts: 86
Joined: Thu Jun 20, 2013 4:24 pm

60-2 sync losses over ≈2k rpm

Post by ruzki »

em_knaps reported that he achieved a rpm above 8k rpm with his Volvo.
Fred thought a workaround in the fixed config file could resolve this problem, but for me as well some others it did not work.
So me an other ´s do have the problem off sync losses above approximately 2000 rpm.
By looking at the trigger pattern on Volvo Flywheels i noticed that the teeth´s on lots of them are not evenly spaced, whereas my 60-2 wheel has even spaced tooth´s and gaps.

My question is therefore: Could this be a reason ?
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: 60-2 sync losses over ≈2k rpm

Post by Fred »

Can you post a photograph illustrating what you call unevenly spaced?

And did I provide you access to the somewhat improved missing tooth code? I made a few minor tweaks to performance, and some correctness fixes. The latter is pretty important. Em_knaps' engine could not have run without these fixes.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
ruzki
QFP80 - Contributor
Posts: 86
Joined: Thu Jun 20, 2013 4:24 pm

Re: 60-2 sync losses over ≈2k rpm

Post by ruzki »

And did I provide you access to the somewhat improved missing tooth code? I made a few minor tweaks to performance, and some correctness fixes. The latter is pretty important. Em_knaps' engine could not have run without these fixes.
Yes, you did and you also gave me the idle code. I merged them together but i tried the "work around" on the standard code.
I will test the tweak with the improved code first.
Can you post a photograph illustrating what you call unevenly spaced?
Unevenly spaced is probably not the correct definition. I ment that width of the teeths are smaller than the width of the gaps.
Picture shows a Volvo Flywheel ..
Trigger_Vol.JPG
Georg
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: 60-2 sync losses over ≈2k rpm

Post by Fred »

OK, so to understand VR sensors, you have to understand that you only get ONE meaningful edge, and that edge is right in the middle of the solid tooth. The edge that occurs *somewhere* in the gap is variable in position, and as such, useless. It's very normal to have bigger gaps, to an extreme in some cases, where there's a single tooth, and a long tapered ramp to maintain magnetic flux. For hall this isn't true, but I only care about one edge for missing tooth regardless of type.

Let me know if you have luck with the tweaked code + hack on your bench or, gasp, car.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Nige
QFP80 - Contributor
Posts: 61
Joined: Sat Aug 10, 2013 5:47 am
Location: New Zealand
Contact:

Re: 60-2 sync losses over ≈2k rpm

Post by Nige »

I know little of coding but more on efi setup; but a query: you should have a peak in the middle of the tooth, not an edge? If polarity of the sensor is correct, then you should be using the falling edge as it won't drift (erm, much) as it passes zero point. All aftermarket ECU's try and get you to use falling ideally with high voltage when tooth passing, though old Haltech made you reverse the polarity of the sensor on missing tooth setup... was a limitation of how the 60-2 encoder was done apparently.
IRC nick: ignitionigel or Nige
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: 60-2 sync losses over ≈2k rpm

Post by Fred »

Falling edge is correct for an unprocessed signal, the Voltage is positive as it approaches the tooth, zero at the centre of the tooth, and negative as it recedes away from the tooth, hence zero crossing in centre of tooth, and hence it being precisely reliable position wise. The other zero crossing on the way back up is gradual and unpredictable in nature relying more on electrical characteristics of the system, and the shape of the trough in the wheel.

FreeEMS, by design, mandates use of a processing circuit that produces a rising edge on the zero crossing (usually max9926 / max9924). The code is not adjustable in this respect as all compatible hardware systems are required to provide suitable quality isolation and processing capabilities. Same goes for all hall/opto setups, such as the 4g63/miata/mx5/evo/etc, inversion of that signal is required, or the code will not function, however all compatible circuits do invert, and thus it's a zero-config thing and total non-issue.

Hope that helps clear things up :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
DonTZ125
QFP80 - Contributor
Posts: 57
Joined: Tue Feb 12, 2013 5:43 am
Location: Scarborough, ON
Contact:

Re: 60-2 sync losses over ≈2k rpm

Post by DonTZ125 »

A couple comments ... First, the sync loss over 2k on a 60-2 is a known issue with the MAX992x over on the VoldeSquirt forums. While the code is different, the chip is the same, and the proven solution is a 10k shunt resistor across the VR+ & VR- inputs.
Fred wrote:OK, so to understand VR sensors, you have to understand that you only get ONE meaningful edge, and that edge is right in the middle of the solid tooth.
I have to disagree. The zero-crossing through the middle of a narrow tooth is the most accurate and repeatable, but it is not the only usable signal. There are several brazilian Japanese bikes out there from the 80s and 90s that used 3 short teeth and 1 long tooth; the width of the long tooth is such that zero-crossing detection is useless - unpredictable and unrepeatable - as the signal can come in at any point in the 30-60 degree span (depending on the model). These systems use edge detection, triggering on the leading edge of the tooth and using the much greater 'hang time' of the long tooth for crank position reference.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: 60-2 sync losses over ≈2k rpm

Post by Fred »

Proven with code disassembly or presumed? There are quite a few OEM systems with a "good enough" attitude to making things work. That certainly sounds like one of them. I'm making the assumption that it's definitely VR, however a hall setup with three short one long is perfectly feasible. Let me rephrase:

You only get one high-quality edge from a typical zero-crossing detector that is considered by the discerning to be acceptable. Better? :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
DonTZ125
QFP80 - Contributor
Posts: 57
Joined: Tue Feb 12, 2013 5:43 am
Location: Scarborough, ON
Contact:

Re: 60-2 sync losses over ≈2k rpm

Post by DonTZ125 »

Better. ;)

(And yes, it's VR; no, no code dismantling - but there's no way of getting a usable zero-crossing signal out of a tooth 36 degrees in span!)
User avatar
ruzki
QFP80 - Contributor
Posts: 86
Joined: Thu Jun 20, 2013 4:24 pm

Re: 60-2 sync losses over ≈2k rpm

Post by ruzki »

So I bench tested the Code with the Ardu-Stim an R-C circuit, and it works! It revs up to 16k rpm with ease!
A couple comments ... First, the sync loss over 2k on a 60-2 is a known issue with the MAX992x over on the VoldeSquirt forums. While the code is different, the chip is the same, and the proven solution is a 10k shunt resistor across the VR+ & VR- inputs.
Right! I got a 5k shunt resistor right now. I noticed that if remove a 4,99k resistor for the VR-Sensor input so that there is no longer input resistance of 10k Ohm but 4,99k ohm. It seems to work.
Also it seems like I have to reverse the input of the VR Sensor.

Further investigation will follow! But for now, Congratulations Fred it works!
Post Reply