Another dropped cranking RPM
Read the manual to see if your question is answered there before posting. If you have questions about MS1/Extra or MS2/Extra or other non-B&G code configuration or tuning, please post them at http://www.msextra.com The full forum rules are here: Forum Rules, be sure to read them all regularly.
Also, I have no explanation for why you are losing synch with fuel and not without fuel. Even more puzzling is why the trigger+/- isn't counting when you lose synch. Unless it is counting up and down with 0 net effect. Are you using the 2.883jt1 or plain j code ?
Can you post the msq you used for these runs ?
[Edited to correct deltaTs - off by a factor of 10.]
The wheel is made correctly enough for the stock ECU. The engine is a 2 cylinder 180off with 11.3:1 compression and virtually no flywheel, so I think thats the explanation of the 16-23ms (160-310rpms). I ended up setting the next pulse tolerance to 125% to make this work.
Also could you clarify this a bit for me,
- deltaT: the time delta (interval) between rpm pulses in microseconds.
this is actually crank revolution times?
- trigger±: The code for toothed wheels checks for missing or extra teeth and handles them if they occur, but only allows one or 2 corrections in a row. More than this and it re-synchs. This will tell users when they have noise or weak signal issues.
Is this revolutions with missed teeth? Actual missing teeth? And before or after the pulse tolerance and pulse mask etc?
- tachCount: counts tach pulses for use in correlating datalog values with tach pulses (at lo rpm).
From the log this appears to be crank revolutions? Did you mean tachout pulses?
Thanks Again,
Geoff
- Attachments
-
- megasquirt200803251919.msq
- (25.12 KiB) Downloaded 50 times
geoffct wrote: - deltaT: the time delta (interval) between rpm pulses in microseconds.
this is actually crank revolution times?
It is the time between skip teeth - the processor is interrupted every time a tooth arrives, when it counts 12 teeth, as in your case, it calculates deltaT as the differenec btween present cpu clock time and the saved clock time 12 teeth ago. It is accurate to within better than a microsecond, because all the times are stored at the time the tooth arrives, even if the interrupt isn't entered until a bit later because there was another interrupt at that instant.
- trigger±: The code for toothed wheels checks for missing or extra teeth and handles them if they occur, but only allows one or 2 corrections in a row. More than this and it re-synchs. This will tell users when they have noise or weak signal issues.
Is this revolutions with missed teeth? Actual missing teeth? And before or after the pulse tolerance and pulse mask etc?
Again each time atooth arrives, the processor compares tooth deltaT (not a recorded vraiable like rpm deltaT) =present time - last tooth time, with the previous toth deltaT. If the new tooth time is within PulseTol % of the old, it is accepted. If it is out of tolerance too long, the trigger+/- counter counts down (missing tooth) if too short it counts up (extra tooth). This should also answer your PulseTol question in the next post - in your case pulse tol is used for tooth to tooth error checking.
- tachCount: counts tach pulses for use in correlating datalog values with tach pulses (at lo rpm).
From the log this appears to be crank revolutions? Did you mean tachout pulses?
Except in your 2 cyl, 12 tooth wheel, 12 skip teeth case, tach pulses are not crank revs, but in your case they are the same thing.
Thanks Again,
Geoff
It is possible that the synch logic won't handle the excessive variation you have from one rev to the next. I need to try to duplicate this condition and see if I can get it to lose synch. This may take a few days, but I will let you know what I find. Meanwhile I may give you a test code version that simply omits all error checking and see if that loses synch. I don't think you can do this just by setting Pulse tol high.geoffct wrote:Here is the MSQ as promised, I am not 100% sure about the settings anymore, there were far too many nights of adjusting this or that, trying to make things work.
Since this is untested code, the best way to test it is without fuel first, using conditions and inputs as close as possible to those when you ran the previous datalog. On that there were no resynchs, but you can check that the timing remains on track, then you can try it with fuel.
What still puzzles me is that the timing between teeth was alternating 160, 250 ms whether you had fuel(combustion) or not. It shouldn't have done that with no combustion - or is it the fact that it is an odd angle engine so there are 2 compressions on one rev and none on the other - but still I would expect the effect to be stronger with combustion - maybe something like 190, 220 without combustion.
- Attachments
-
- Monitor_v2.883jt2.abs.zip
- (37.05 KiB) Downloaded 44 times
Could I rework the trigger timing to average a bit better?
On the stock ecu, I was still seeing pulsing at higher rpms.
Thanks Again,
Geoff
Geoff
- Attachments
-
- datalog200804031840.xls
- (43.89 KiB) Downloaded 37 times