So, how many teeth do I really need?

[SQLGUY]

I re-flashed to 2.886 (I had been running 2.884), and reconfigured from scratch. The system still seems to be rather finicky about synching... often it doesn't seem to want to synch, but after power cycling uS and trying again a few times it will synch up. Once it gets a trigger it keeps it and runs just fine from there on out. Seems like something about my setup doesn't mesh well with whatever logic is involved in initial acquisition of the trigger wheel signal.

(MSQ is attached)

I ended up with delay teeth of 6 and trigger offset of -10. The low RPM jitter is MUCH better, down to about +/- 5 degrees, where there used to be +/- 20 or more. Throttle response seems better as well.

I think I'll take 'er for a ride and see how she's doing.

P.S. I had gotten the 10% and .2 ms from here: http://www.megamanual.com/ms2/wheel.htm

These are called the time mask and percentage mask, respectively, in the ignition options dialog of MegaTune. For wheel decoding you must use values close to 0.2 ms and 10%. However, to not break any existing setups, the default values are 0 and 50%, the same values hardwired into pre-v2.5 code. Be sure to adjust these values when you set up for a trigger wheel (note that they are in a separate dialog from the trigger wheel settings).

Is this no-longer valid? What about the recommendation to use last interval, rather than alpha, beta, gamma with a trigger wheel?

Cheers,
Paul

[SQLGUY]

Currently I have the defaults for pulse tolerance (50, 70, 25). I have two questions about this:

1. When first cranking, this is 50% of what? Since there's no synch and no historical information, what does uS expect the interval to be? Max cranking RPM / teeth?

2. Might I have better luck with initial synch if I tweaked the cranking tolerance?

Thanks,
Paul

[grippo]

The %,time masks are needed for normal and dual tach mode, but are not used in the code, regardless of the setting, when No_Teeth > 0. I am reviewing some things in the manual and will make a note to fix the quoted statement.

alpha-beta-gamma generally doesn't provide much improvement, basically because it doesn't catch the very first change, which at low rpms is importanet. You will find that worst case timing errors are at low rpm, because there is more time for the errors to build up.

You can try CrankTols of 30 and 70 and see if they help, but I wouldn't go much further. Pulse Toelrance is used as follows:

abs( (t2 - t1) * 100 / t1 ) < Tol% . So you need two times between teeth, t1 and t2, (3 teeth total) before you can test. Then you just set t2 = t1 and calculate a new t2, and so on.

If yopu want to see what the processor sees you can try the below applications. The first you just save on you PC and double click to start it. The other you download into your microsquirt or ms2 in place of the existing code. It WON't RUN the car - it is only to look at the cranking pulses. You leave your wiring intact, close MT, don't worry about ini files or msqs. Do the following:

1. Bring up the pc viewer and set the proper comm port
2. power up microsquirt
3. start cranking and hit the Run Test button to record the tooth data. You can hit the Run button first, but must start cranking within 2 secs or it will time out anjd you will have to hit the run test button again.
4. The data will stop being collected when > 3000 bytes of data are collected or you stop cranking for > 2 sec. The processor then sends it the data and it is plotted.

The embedded program comes up in a state where the pump, injectors and ignition should all be off, but CHECK to make sure that is the case. The program captures data from both Input Captures, but only if it sees edges.
When done, just reload your running code and msq.

The program is rough and needs a scale button and an erase points button, but the scale will only be needed for 24 or more teeth, and when you want to rerun, just close and reopen the pc program.

[SQLGUY]

Here's the result:



I would have thought this looks OK, but I still get synch only about once in a dozen or more tries. Could this be an overflow issue somewhere? The max delta T with my 8-1 wheel and my cranking speed of about 450RPM is almost 550ms.

If there is an issue where the delta t during cranking is overflowing somewhere, that would also explain why the bike synched more easily with one plug out: less compression = higher cranking speed = shorter max delta t.

By the way, I did pull pin 4, just to make sure the other VR signal wasn't confusing the ECU; didn't make a difference other than getting rid of the yellow line in the tach tester application.

Thanks,
Paul

[grippo]

There is no overflow issue. The deltaTs in the log are in microsec and the time scale on the plot is 50 ms per division. I calculate about 67 ms between tach pulses (180 deg apart) at 450 rpm. I tested the dual tach (= 1 tooth) at 120 rpm with no overflow. Note also the vertical scale is meaningless - the processor only sees 0 or 5V.

This is where we need the scale blow up so we can measure the times between teeth and see what the pulse tolerance should be. This part is easy, but it isn't apparent how to clear the screen for a replot.

The only thing that definitely looks bad are the two closely spaced missing teeth at the end. But I don't trust this data because it is probably where you stopped cranking and the engine was running on inertia.

Does the polarity look correct to you - on my bench I see the missing section as low. If you got the right polarity on your previous setup and haven't changed anything, then it is probably OK.

Until we get the scale fixed, I would try raising the pulse tol. If nothing else, tomorrow night II can send you a code version that multiplies your data by say 4. That should give good resolution to measure the times between teeth.

[SQLGUY]

The polarity on my original setup was set the same and worked reliably. The thing here is that, once it does synch up the engine stabilizes perfectly and runs great. It's just that on most cranking attempts it never synchs - never shows any RPM at all.

The end of the trace is where I stopped cranking. I previously ran a couple of other tests with longer cranking times, and the pattern was always clean and consistent to the end.

I have tried cranking tolerances of 30%, 70%, and even 100%. The first time I tried 70%, the bike started right up, but that was after it had been sitting overnight. I ran it for a minute or so, then stopped it and tried to restart it. No RPM at all. I tried several more times, and with a couple of different cranking tolerance values... still no RPM. It was after that that I loaded the tach testing code.

So, the root of the problem is that my setup seems very borderline for initial synch.

I never had any problem getting tach with the dual tach setup, so I'm not concerned with that area of the code. Have you tried simulating an 8-1 wheel cranking at 450RPM or less?

Thanks,
Paul

[grippo]

I have run an 8 - 1 wheel, but don't remember the rpm. In any case I will try to run your exact msq tonight.

[grippo]

I ran the msq exactly as is with an 8-1 wheel at 450 rpm. I didn't see any problems on either output channel. There were no missed pulses. Of course there isn't any jitter on this. But I don't think that is the problem. At this point all I can think to do is blow up the graph. I have attached a code version that will double the scale and I can double it again if that is needed.

[SQLGUY]

Here's the result from this one:



I reattached pin 4, so this trace includes the "cam signal" from the second VR pickup (yellowish). There were about another ten screen-widths worth of stuff that looked just like this. The leading and trailing ends of the trace each had one or two long pulses.

After trying this and reflashing back to 2.886, I also took the wheel out and did a bit of work on it to make the teeth better aligned in the flat and closer to the same length. They are now pretty much identical in vertical alignment when they pass the pickup and there is probably half a millimeter variation in length. This didn't seem to make a difference on initial synch, though.

I also did manange to get it started twice (out of about two dozen cranking attempts). During one of those startups, I recorded the attached datalog. I started the datalog after the engine was already running (I would have started the datalog first if I'd known that I was going to be able to start the engine). I let the datalog run through me revving the bike a bit, then stopped the engine and tried about five times to restart it (unsuccessfully) before stopping the datalog. Hopefully there's something helpful in there.

Thanks,
Paul

[grippo]

I think you have a polarity issue. My polarity was like the yellow plot so I was suspicious, but I think this shows what is going on. Both of these graphs should be the same because the sensors are the same and I believe they are both going through a VR input circuit on the processor board. Since they aren't the same, I am guessing the wires from the sensors are reversed when tied to the microsquirt wires. Although you will get a square wave either way you will see a big difference in deltaTs across the missing teeth. The way people should use this is to get a fine line mm ruler, preferably one of the clear ones, and pick a polarity and write down the measurements from each edge atarting with the edge before the missing section and going through a whole rev cycle or more. Looking at the blue graph, rising edges, I got 10,12,9,8,6.7,7,9,10 . You can see the compression slowdown as you get near the ends because you are at TDC then the times get smaller(faster) in the middle. However the missing section is 12 surrounded by 10 and 9. This won't do, the missing section should be approx. double the neighbors. If you measure falling edges on the same graph you get 9, 14, 7.5, 9.5, 7.2, 6, 8, 10 - much better. I believe you will get even better or just as good with the yellow curve. I would leave everything as is and just reverse the wires for the blue curve and see if that doesn't get you started. Then you could fool with the polarity and see if you can't get it even better.

Note this also explains why the dual tach setup works better, because there you are sampling the wheel at the same spot each time, so speedup/slowdown or even tooth misalignment isn't a factor. This is like the great improvement we saw when sampling MAP at the same point ibn the engine cycle. The values were much more consistent. However, with the toothed wheel we can't do this. We could measure across the whole rev cycle and divide by 8 teeth and use that number to compare to the missing, but that assumes each rev is the same speed, plus it could slow down synch to have to wait.

Whate we need to do is maybe add a printout or another graph that shows the percent errors as they would be calculated in the processor. Then you could see what tolerance would be best. These could even be incorporated as tooth compensation factors in the program, at least during cranking. But I think you would need to do a whole 720 deg cycle for this and until you got synch you would'nt know which cycle you were on.