rusefi.com

yes

Because that's how we schedule, I would avoid trying to put ignition near the missing tooth, since that's where we have the most timing uncertainty.

So the solution for this wheel is to correct offset angle for the effect of the large tooth and let it go. Offset is largely away from sync point.

So long as it syncs reliably, yes. In fact, that's what Bosch did from the factory on their 60-2: the missing tooth is always centered-ish between two cylinders to that it's hard to have this problem.

Do you agree that the timing gun is wrong at high rpm ?

Did you know that problem ?

Some more tests today.
As Matt predicted once the first anormal tooth is passed sync is OK.
Strangely the sync is not on the male part of the tooth but in the void.
Changing the "use only rising edge" option did nothing.

Bad news after today's tests :

I triggered the scope with the "trigger error led" signal to investigate on high speed sync losses.

The scope showed repeatedly that the error was thrown on the end of the abnormal first tooth.

Crank signal and row vr signal were both absolutely normal. No spikes or other problem.

Does the software throw an error if instant RPM varies brutally?

I presume the long tooth is triggering the noise filtering code of trigger_central.cpp :

Please post a link to your tune. I would suggest that you do NOT try noise filtering feature.

Due to the sync problems, Rusefi work is stopped.

3 solutions for me :
- having a working decoder programed by the devs
- having the oem ecu working with a normal 60 - 2 flywheel and cut the Renix flywheel to that spec
- add a 60-2 wheel on the crank pulley and a supplementary vr sensor. This has been done on the race engine for the 2l formula renault race car.

Will try to go on for the 2 which are in my hands.

JPh wrote: ↑

Sat May 22, 2021 5:58 am

- having a working decoder programed by the devs

Back to https://rusefi.com/forum/viewtopic.php?p=40386#p40386

Can I please have a much longer, unedited block of gap sync output? I'd say 200 of these "gap" messages please?

Andrey the 60-2 is just a more modern version of the RENIX 44-2-2 or 66-2-2. All have the big male tooth at the beginning of sync part. So you have solved the problem in the past.

Will post the trigger log as soon as possible.

Is this file OK ?

Hello guys,
this will be my first post on this Forum and I hope its ok to introduce myself this way.

People do misunderstand this Renault tigger wheel.
I had this issue myself years ago.. I saw people grinding off this tooth because they could not get it working.

example: http://forum.diyefi.org/viewtopic.php?f=56&t=2395&p=42661&hilit=renault+trigger#p42661

Also there should be other posts in other forums .. MS etc.

I think that Renault did this long teeth only to make sure that the engine can not turn in the wrong direction

Basically this problem ist easy to solve. One just needs to find the right settings.
Depending on the direction of rotation, either only rising or falling edge can be used.
With a classic 60-2 wheel, both falling and rising edge can be used in both rotation directions.

I hope that the following picture makes it easier to understand.
With falling edges the trigger is by 0.5 tooth of..

[attachment=0]2465A_1.jpg[/attachment

i am not 100% sure if we have open issues here

if we do it could be either about sync or about non sync tooth positions

recent discovery is that logical VR flip is not same as wiring flip on MRE at least on Subaru

AndreyB wrote: ↑

Mon Jun 14, 2021 7:54 pm

recent discovery is that logical VR flip is not same as wiring flip on MRE at least on Subaru

that's a subaru thing - there's wiring in the harness, so the VR pins aren't the same

When experimenting on that problem, the use of the "use only rising edge" option never had an influence on the result.

How can you use the rising edge of the big tooth? When this edge is detected, the sync even has not yet arrived (the long time of the interval can only be treated at the end of the tooth) .

JPh wrote: ↑

Wed Jun 16, 2021 3:31 am

When experimenting on that problem, the use of the "use only rising edge" option never had an influence on the result.

The picture above is just an example. If one reverses the direction of roatation, rising edge will no longer work but falling edge will.
You may have an hardware setup that will only work with falling edge.
There will be one hardware/software configuration that will show you the correct gap length.

JPh wrote: ↑

Sun Apr 11, 2021 7:36 am

Here is the VR sensor signal and the crank signal of MRE :
Renault sync.png

My understanding is that this arrangement causes tooth N°1 to be abnormaly long (It begins earlier).

Just take at look at you picture here. 2 teeth will have a duration of 3 indexes on your scope.
2 Missing teeth will have also a duration of 3 indexes.
If you only look at the rising edges of the long-gap-tooth you will see that you have a duration of 3,5 indexes.
If you only look on the falling edges you will see that you have a correct duration of 3 indexes.

If this is the signal that goes in to the Rusefi than you will only get an correct tigger signal with falling edges.

Now I do not got a deep understandig of the rusefi code but I think that the code will only use rising edges independent of the "use ony rising edge" option in TunerStudio. May somebody correct me on this one.
If this is really the case you only can change this situation with hardware.
On possibility would be to use an logic inverter like:
https://www.digikey.de/product-detail/de/on-semiconductor/NC7SZ05P5X/NC7SZ05P5XCT-ND/2053150

Or you could just grind away the long tooth

First Ruzki thanks for your knowledgeable help, I appreciate to have some interest for this topic.

Using the falling edge of the big male tooth is OK but has the drawback this edge is caused by the decay of magnetism along the tooth and not the effect of a well defined edge. Just for sync purpose it's OK.

For me, a hardware solution is not possible because you have to invert after the tle 8888 to keep it's signal processing features.

Milling the tooth is not a problem for me, I have the equipment in house but I need to keep oem ecu working for driving to the track.

Do you know if the Sirius 32 can work with a normal 60-2 wheel ?

Maybe there are drawbacks but I can tell you that the cars I know do work for years with falling edge up to 7800rpm.

In my opinion it should work but I can not tell for sure because I've never tested it.
Maybe the guys who sell this are the right ones to ask:
https://efi-parts.co.uk/product/vw-audi-flywheel-for-renault-f-block-engine/

If you can not grind down the long tooth you will need to trigger through falling edge in any case.
By adding a logic inverter the ECU would trigger through falling edge as well.

BTW: Volvo B20F engines had a real 60-2 trigger wheel.
The wheel of this engines does fit for Renault F-engines since this Volvo engine is a Renault engine.
But it hard to find these engines nowadays.

Root cause:
these TWO edges can move around with speed

Has there been an improvement in trigger decoding since "snapshot_20210416_121019_mre_f4_rusefi" ?

I'm unable to reproduce the problem. The trigger decoding is perfect up 5800 RPM (upper limit of my flywheel spinner) with 60-2 decoder !

The only sync losses are the normal ones when sync catches up at very low RPM.

Yes, there was probably a bunch of improvements of different natures - redundancy gap count in specific decoder and overall performance work across the board.

Should I reload old firmware to confirm the progress made?

Reverted to old firmware. Trigger errors came back.
Congratulations for finding the problem!