Primary Trigger fails

[hiphopsteven]

Hello there,

I have a motorbike engine running with vems. I'ts a 1 cilinder 654cc KTM Duke bike.
But I can't get the bike running smoothly, it is stuttering.

When I first used vems it was running on firmware 1.1.74
When I putted the settings to 1 cilinder my ignition table was divided by 2. (I measured it with the scope) So if I would set my ignition to 30 degrees, the scope measured 15 degrees.
Little vems bug???
That's when I decided to adjust the settings to 2 cilinder. It worked the ignition table was correct. So now I have 2 outputs that are in use but not wired (injector en coil for cilinder 2)
No problem at all, the bike runs. (but is still stuttering)

after a lot of hardware checking and replacing I decided to upgrade the firmware to 1.1.92 because I had the feeling it could be a trigger error and I wanted to have a trigger error log.
I got my log and I saw some strange things. First of all the trigger signal (primary, secondary and spark event) where sometimes not measured or detected for about 0.25 seconds.



Also the primary trigger sometimes mistaked with the tooth count...




But this is not always the case, I also have a log (1.30 minutes long) where non of this happends without changing anything to my settings!
all the logs where made with stationary rpm (somewhere around 2200 rpm)

If you look carfully you can see that there are also to many secondary triggers but they are all in the same cranc rotation so that should be no problem..
I use a 18-1 triggerwheel (wich is stock) and a VR sensor (which is stock)

so I figured it could be the shielded cable that is broken? I replaced the cable and then I discovered something strange. When I tapped with the shield of the cable to my engine (ground) the fuelpump was activated. This means that a trigger was detected. The VR sensor is wired to the sensor ground, and the other wire is going directly into the vems box. And of course the shield is grounded.. I also tryed to ground the VR sensor directly to the battery, problem gets even worse.

How can there be a trigger dectection when I tap with my shield to my engine ground???

In this link you can find my config as well..
http://wtrns.fr/5yqlAovE5UgYVQ

[mattias]

What is the resistance of the VR sensor(s) ?
You might need some modifications to the board to better match the sensors and make the input less sensitive to noise.
When you tap the shield to the engine ground it points to small voltage differences in the ground plane, and the input can be (too) sensitive depending on the sensor characteristics.

Some detail on your harness, grounding, etc.. would be nice.

[Nack]

The wiring is as per manual. Sensors grounded on sensorground. Powerground on a seperate powerground.
They combine near 10cm of the EC36 plug. The powerground and battery ground are on the other end connected to the frame of the motorcycle. Also the engine itself is grounded at this point.

Although we get audible misfires at stationary speeds of 2200 rpm and randomly heavy misfires at about 6000-8000 rpm... We can clearly see from the triggerlog sometimes less teeth are counted.

Will have a try to wire up the oscilloscope to the signal tonight!

[hiphopsteven]

Nack is also working on the same bike, that's why he answered your quiestion about the wireing.

The resistance of the VR sensor is 288 ohm....

[Nack]

We may have something here!

Our triggerwheel is a modified stock KTM 690 triggerwheel with the widest teeth ground away, leaving us with a 18-1 triggerwheel.
No problem you might think. But then I realized that the tootwidth defenition in VEMS expects an equal tooth and gap width.
Like: 360/(number of imag. teeth) = 20 degrees

But in our case we have a tooth width of approx. 5 degrees and a gap width of 15 degrees. Can this be the cause of our misfires?
We saw in the triggerlogs a lot of false missing teeth, ones that shouldn't be there.

The rotational speed of the crank during a single rotation can vary relatively much in a heavy single cylinder like ours. We can tell because of the amplitude difference of the VR-sensor output during two consectutive rotations.

Can VEMS handle this unequal tooth-gap widths?


Attached an image of the actual triggerwheel, a scope picture of the actual triggerwheel vr-signal and trigger log

[Nack]

We have probably solved the issue. Secondary trigger was erratic. Solved that and changed some of the Advanced Filtering options in the Primary Triggering menu. Now we have a clean triggerlog!

Still have to do some dyno testing, but it is looking good!

[mattias]

The tooth width number is the degrees between trigger edges, so that is not the real problem here. The sensor on the other hand creates a signal that must be interpreted correctly, most trigger wheels for inductive sensors have an equal length tooth and gap. As long as the zero crossing (from neg to pos voltage) of the signal is always predictable then you're ok.
If you have a choice, use Hall effect sensors - especially for cam sync.

[hiphopsteven]

at this moment, the cam sync is a hall sensor, and the cranckshaft has a VR sensor...

[Benzmac16v]

Try downgrading to 1.1.88.  I had the same thing happen to me with 1.1.92 and my hall setup.  Just gave me random, completely unpredicatable trigger errors.  The car would run as expected for a while, then it would go through a series of trigger errors for a few seconds to a minute.  It just felt like a miss fire because it would re sync itself the next rev and give me more than a few good power strokes before doing it again...  So it did not strand me, but probably put some unnecessary abuse on the rubber components of the driveline.  My guess as to why 1.1.92 did this to me is that I didn't start over with a new 92 config file and something might have changed enough to screw something up in 92.  I am probably only going to use firmwares that have been 'released' now unless I am trying to solve a particular problem...  I really did like the fast sync in 92 and VT...

Also, your shielding should not ground to anything except the sensor ground.  You open yourself up to a large ground loop.  I had a no start condition when my sensor was inadvertently grounded to the block and sensor ground.  Every time my coils fired (they were in the middle of the loop) my ECU would count an extra or miss a tooth.  Took me a few days to figure that one out, but the trigger log helped a lot there.

I also run a wheel where the teeth are very small relative to the gaps, but I run a Hall sensor so it really doesn't care about tooth/gap width so long as they are both big enough for the sensor to see the tooth.

Jim

[Nack]

Thanks for the reply!!

We have made a new (evenly spaced tooth-gap width) 36-1 triggerwheel in stead of the original 18-1 wheel. With firmware 1.1.92 and the triggerwheel with the higher resolution we get the following trigger log running at a relatively  constant 2400 rpm cranking speed.



MASSIVE triggererrors. For some reason it detects a massive amount of missing teeth?! Does anyone has an explanation for this? Or should we just simply use firmware 1.1.88 as by Benzmac16v described above?

Also note the Primary Diff (ms) column. It should be all about 0.7ms (corresponding with a 2400 rpm -> (60/(36*0.0007))) but shows a multiple of two, about half the time causing a false missing gap trigger?!

Filtering was disabled in software at the moment...