MicroSquirt.com read only forum (Jan.15,2018)

What was the delay and trig offset for the datalog - and any other difference from the above msq.

The .msq is identical for the datalog that I updated.
One other thing I forgot to mention- when I change the delay teeth, the tachloss happens at a different RPM range, very similar to the issues others were having.

Tomorrow morning I'll change my delay teeth and adjust offset accordingly, IIRC with a delay teeth of ~22 my tachloss will be around 2800RPM, not sure about this. I'll datalog this in a similar fashion as before and upload the datalog and .msq.

Thanks, I hope to get the new files up early tomorrow.

Previous setup (.msq and datalog on 1st sheet of this thread) settings were 30 delay teeth and -22 degrees trigger offset. Found tachcount reset around 3550 RPM.

The attached datalog and .msq is identical .msq except for delay teeth now set at 26 and trigger offset at -8 degrees. My datalog shows tachcount resets at 3100 RPM and at around 3750 RPM.

The tachcount reset seldomly happens at mentioned RPM's, some days more than others. But 1 thing is consistent (based on previous settings from months ago), with skipped teeth at 0 and trigger offset at ~ -305 degrees I get no tachcount resets. I will reset my .msq to those settings (and recheck with timing light) and see if I get any resets.

2 things seem consistent, 1) the resets only happen when delay teeth are not zero, 2) the RPM at which the reset happens is dependent on the delay teeth #.

I tried your exact same msqs, code version with a 130-0 signal that ramps up and down continuously from 3000 to 4000 rpm. I tried all your trigger offset/ delay teeth combos and there was no difference - I saw loss of tach, but it is only because my signal generator has degraded. If I fiddle with it and wait I can make it rock steady indefinitely, and if I fiddle some more I can make it lose tach synch every second or two or even more, and it is totally unrelated to delay teeth/ trig offset. In your case, which has a mechanically generated signal in the sense that the wheel is mechanical with some variation in teeth, distance from sensor, resonances that can vibrate the sensor, etc, it may very well be that there is an effect from delay teeth. All I can do right now is look for a better signal generator.

grippo wrote:I tried your exact same msqs, code version with a 130-0 signal that ramps up and down continuously from 3000 to 4000 rpm. I tried all your trigger offset/ delay teeth combos and there was no difference - I saw loss of tach, but it is only because my signal generator has degraded. If I fiddle with it and wait I can make it rock steady indefinitely, and if I fiddle some more I can make it lose tach synch every second or two or even more, and it is totally unrelated to delay teeth/ trig offset. In your case, which has a mechanically generated signal in the sense that the wheel is mechanical with some variation in teeth, distance from sensor, resonances that can vibrate the sensor, etc, it may very well be that there is an effect from delay teeth. All I can do right now is look for a better signal generator.

Al
Will the JimStim do it?
I got my JimStim to do 132 + 1 with the newer firmware and a USB to 3.3V cable

I can test here with 130 if you want (assuming I can recall how to download the pattern).

I found out there is nothing wrong with my signal generator, the scope traces were perfect, but the single tooth crank synch was getting close to the edge of the wheel tooth. What I think was happening is that the crank synch and then wheel tooth 1 (=1st tooth after crank synch) generated interrupts in that order, as they should, but occasionally, they would be blocked by a 3rd interrupt, probably the clock timer or an output compare. Then, since both were pending, the processor chooses the one with highest priority to execute first - NOT the one that came first. The interrupt which has always had top priority is the tach/wheel tooth interrupt, so wheel tooth1 was processed and as part of the processing it looks for the crank synch, which, although it triggered an interrupt, was not yet allowed to execute, and that is where crank synch gets set. So the ecu reset synch. This is not a bug, you want the tach input signal to have priority if you want the best timing accuracy. And if the tooth had been placed in the center between two wheel teeth edges this would not have happened until a higher rpm where there is a processor limit. But what could be done to lessen this requirement is that before resetting synch the code can check if the crank synch is already present on the pin - this happens when it comes in, regardless of when the interrupt actually gets serviced. Then the crank synch interrupt flag could be cleared and the interrupt would go away until the next time.

I will think about implementing this, but in the meantime, how is your crank synch set up - is it a nub welded on the flywheel and is everything factory or is it custom and possibly off center a bit. Note that what counts in centering are the edges. The crank synch edge needs to be in the middle of 2 tooth edges, the edges being rising or falling depending on what you select. So it may be that you can better center things by how you slect the edges. You will have to compensate for edge changes by changing trigger offset a few degrees.

Wow, I'm not gonna lie, some of that is over my head. Currently my Ignition Input Capture is set to Rising edge, if I change to Falling edge could this remedy the problem thus using the negative going portion of the VR signal? maybe?

The reluctor wheel is stock, I believe the 1 tooth is identical to the 130 teeth ring. Both VR sensors are close to each other, mounted in the bellhousing picking up the reluctance from the teeth on (I think) the flywheel.

grippo wrote:
I will think about implementing this, but in the meantime, how is your crank synch set up - is it a nub welded on the flywheel and is everything factory or is it custom and possibly off center a bit. Note that what counts in centering are the edges. The crank synch edge needs to be in the middle of 2 tooth edges, the edges being rising or falling depending on what you select. So it may be that you can better center things by how you slect the edges. You will have to compensate for edge changes by changing trigger offset a few degrees.

I would be careful with that. I found one edge of the ref sensor to be sharp and predictable and the other not on the 132 tooth flywheel.
When I scoped it, the sharp edge of the ref sensor was in between the edges of the flywheel teeth.
I have a screenshot somewhere if you want to see it.

Peter Florance wrote:

grippo wrote:
I will think about implementing this, but in the meantime, how is your crank synch set up - is it a nub welded on the flywheel and is everything factory or is it custom and possibly off center a bit. Note that what counts in centering are the edges. The crank synch edge needs to be in the middle of 2 tooth edges, the edges being rising or falling depending on what you select. So it may be that you can better center things by how you slect the edges. You will have to compensate for edge changes by changing trigger offset a few degrees.

I would be careful with that. I found one edge of the ref sensor to be sharp and predictable and the other not on the 132 tooth flywheel.
When I scoped it, the sharp edge of the ref sensor was in between the edges of the flywheel teeth.
I have a screenshot somewhere if you want to see it.

I should also mention that my car has a similar Motoronic flywheel and sensor set that I have never used. 116 teeth and one reference sensor.
I wonder if I should hook it up and see if I can sync on it?

The best position is for the reluctor synch edge to be in the center of two flywheel tooth edges. If the rising/ falling edge was selected to achieve this, then all should be good. But if there is doubt you could try changing the rising to falling on the reluctor.

After more testing and coding I am back to thinking there is something wrong with my setup. I won't be able to get back to this until Sunday earliest, but Peter, if you want to test Rob's msq and his code version on the bench with a simulated 130 tooth wheel that would be helpful. What you would be looking for are loss of synch - the rpm gauge will momentarily flick to 0. But the best way is to bring up the spare gauge labeled spare 1 or 2 or maybe reset. You can tell you have the right gauge because it will come up as 1 and if you are synched and cut off the tach signal it will increment. So you can walk away and come back an hour later and if it is still 1 there were no resynchs, if it counts to 5, there were 5 resynchs. But what I am seeing are continuous resynchs, several per sec, then after I have fooled around or made a code change, they go away and it is rock solid for hours. Then I leave it exactly as is with power off and go to bed. When I wake up and turn everything on it resynchs all over the place.