High tooth count wheel not reving over 2900

[JustinL]

After solving my resetting issue, I was able to go out for a drive to start tuning things up. The car has a 130 tooth wheel with a crank sync. Everything runs pretty well up until 2900 RPM where my trigger +/- starts to count down really fast. This looks to me like the teeth are not being read by the VR sensor at this speed. I'm pretty sure microsquirt can handle teeth that are counting this quickly as it's been bench tested to 18000RPM with a 60 tooth wheel. Do I have a setting wrong in my .msq? Perhaps I'm overloading the VR circuit and it needs a resistor?

Any help is much appreciated

Justin

[grippo]

60 teeth at 18000 may be achievable on the bench but is pushing it on a real engine. But I know 130 teeth will go well past 2900 rpm, probably to 6000-7000 rpm. It is unlikely anything is wrong with the msq if it works fine to 2900 rpm. So yes my best guess is that you need more resistance in the VR circuit.

[JustinL]

I tried a 10K resistor and now I can rev higher, but still missing triggers. Previously I the trigger countdown would start at about 2400 RPM, now It doesn't start until about 3150RPM. What this seems to imply is that I need a much higher resistor. How big should I be looking at? What strategy should I adopt to find the optimal resistance?

Thanks again,

Justin

[SQLGUY]

Well, the easiest thing would probably be to go to Radio Shack and get a 100K linear potentiometer. Connect one end to your VR signal and the middle to the uS input. Adjust it until you have your best tach signal pickup, then disconnect it and measure the resistance between the two points to which you had hooked up wires. That will probably give a non-standard resistor value, but the closest standard value to it will probably be OK.

[JustinL]

I tried various resistors and made a few discoveries. First of all, none of the resistors helped on VR1 the countdown seems to vary in where it starts. I eventually made my tach get really erratic which made me go back and look at my earlier logs. I'm actually reading the RPM really well all the way up past 3500RPM... even though trigger +/- is counting down. To me this suggests that my 130toothed wheel is not the problem, instead it's the crank sync stud that I'm missing. Does this sound right? Resistoring the VR2 input didn't do me any good either with the 10K resistor. Would switching to rising edge make a difference?


As always thanks so much,

Justin

[grippo]

If the trigger+/- is counting down it means you are missing flywheel tooth detections (it only applies to the 1st tach input) or possibly your pulse tolerance is set too small. This could cause a resynch just as easily as missing the crank stud. Once synch is established, the crank stud must fall between the same two flywheel teeth every revolution, so you need a correct tooth count and you need detection of the stud at the right time. If you are not resynching but the trigger+/- is counting down, then the processor is shoving in the missing teeth as long as you don't have 2 in a row. But if the stud is missed you would get a resynch.

By all means try different edge polarities. First try changing the flywheel polarity to see if the trigger+/- goes away. If that doesn't help or makes it worse, go back to the original, but try changing the polarity of the crank stud.

[JustinL]

I tried flipping the polarity of the "M-0 w/falling" to M-0 w/Rising". The problem still persists, but now the trigger counts up from 0 instead of going negative. Also, my delay teeth is set at 0. I tried moving it to 21 as it's the 21st tooth BTDC that should line up with crank sync stud. It only fires briefly then dies like this.

Here is a picture of the ring gear (130 teeth) and the flywheel stud (58.7° BTDC):

[grippo]

I tried flipping the polarity of the "M-0 w/falling" to M-0 w/Rising". The problem still persists, but now the trigger counts up from 0 instead of going negative.

I don't see how it is possible in the code for the crank stud polarity to affect the VR1 trigger count. The only trigger count+/- logic is in the VR1 tooth detection section. The code keeps count of the teeth from the last VR2 detection and if it's not the same on the next detection it declares immediate resynch, it doesn't change the trigger count. This has to be coming from the VR1 sensor.

I know there are people running this flywheel with crank stud configuration, and most flywheels I know of have 100-200 teeth, and most 4cyl engines run to 6000+ rpm. If there are poeple successfully running a configuration like this please let us know so we can put the teeth vs rpm issue to rest. Let us know no. teeth, max rpm and code version.

Next thing to do is check in the Megamnual and microsquirt docs for anything on eliminating VR sensor noise, plus all of Bruce's posts on this. Are you using the stock sensor and was that used on the flywheel. There are different sensors for different types of teeth - basically the sensor detection tip (which may not be obvious without cutting the sensor open) should be correlated with the size and shape of the tooth as well as the tooth speed range.

We are in the process of developing a system to detect tooth problems and fix them, it just takes time.

One last tthought. When you hit the rpm to lose synch, does the engine act erratic or does it smoothly lose some speed then pick back up. The reason I am asking is to see if the missing of teeth is due to the engine running rough because of the timing going away due to a bad config or something wrong on the output side. Have you checked the timing with a timing light and dwell on a datalog or scope while revving the engine in neutral. The dwell should not change much. If it is dropping down with rpm then that would indicate a bad configuration and then we can mess with delay teeth vs trigger offset. It could also lead to the timing not advancing or even going to 0 advance.

[jlturpin]

FIRST OFF. A BIG THANKS TO BRUCE FOR HIS ASSISTANCE WITH ANOTHER ms I WAS HAVING ISSUES WITH.... THANKS.

I am having a very similiar issue (exact) to Justin. I am running 2 factory VR sensors, 132 teeth with -58.6 referece mark or stud. My car is a 944 turbo and has a different tooth count. I have the car running, and does just OK until around 2k rpm. At which point it starts missing.

After I drove the car for a while, bucking and backfiring starting above 2000 RPM I have noted a few things. My AFR's are OK, my timing is OK. Starting around 1800-2200 RPM I start getting a mis, seems to misfire on spark and fuel. It gets worse until it finally just cuts out, just under 2900RMP. After several hours of troubleshooting, and monitoring AFR's, Timing and VE settings, wiring grounds, power supply, a light bulb came on(in my head). I was watching mega-tune while driving, I was in 3rd gear around 2600 rpm bucking and starting to backfire, I down shifted to 2nd, and the tach displayed 3153 and went to zero, the engine probably reved to around 3500, I let it engine break down and the tach picked back up around 1500, it would not count any higher than 3153 in a downshift engine break condition. For some reason, it looks like 2k rpm is about the limit of a clean signal with the Porsche factory high tooth count rpm sensors, and or porsche wiring, doubt it since it is all bosch stuff, similiar to stuff used on high tooth count BMW's. Both sensors are run in individual shielded cables. I am going to try some ground changes and sheilding changes grounding locations.

Also, on the high reset count on the 944, it seems that dme pin 18 and 35 are sourced at the DME relay. This power source seems to be the problem with the resets. Once I switched to a direct battery 12V+ connection, resets are all but gone. There is the ocassional reset, but it could be something i am doing with megatune, I have setup the com port with the lowest buffer setting.

I guess the next step, is to get a toothed wheels to put on the front of the crank and a sensor bracket, or just use it as a data-log and monitor systems.

[jlturpin]

I used a 10K and 20K resistor today with no improvement, I'll continue to look for other solutions.