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

I'm out of town now, so I won't be able to try reversing the polarity until I get back in 10 days.

I can try that, though, but I don't follow what you mean by "whole 720 degree cycle". I only have a crank trigger wheel, and I'm running wasted spark, so AFAIK, everything for my engine would be a whole 360 degree cycle.

Another thing that came to mind was that I could, if it wouldn't weaken the pulses too far, narrow down the teeth to make the rising and falling edges closer together. Another mod I could make would be to add seven more teeth in order to make a 16-2 wheel... to make the missing teeth easier to detect.

I had tried already both rising edge and falling edge. Falling edge worked much better with the dual tach setup, and I never got tach with rising edge on the 8-1 wheel. What's the difference between flipping polarity of the pickup wires and switching the edge triggering? Do they not accomplish the same thing?

One thing I wanted to mention is that my stock VR sensor set has a three wire output (two signal wires and one shared ground). Currently the signal wires go to pins 4 and 32 and the ground wire goes to 33. So, while I can switch polarity easily enough for the trigger wheel setup, since that only uses one pickup, I would have had to rewire back to the timing plate to do it with the dual tach setup.

Thanks,
Paul

Near TDC for the missing tooth section 1 comp, 4 exh, then the next rev 1 Exh, 4 comp. Same for the middle teeth area, cyl 2,3. But you are right these should undoubtedly produce the same accel/decel results.

You can certainly do 16-2, but you should be able to get 8-1 working - I know of at least one person who did.

There are pictures in the Megamanual of what the scope and the resulting square waves look like with polarity reversed. As best I remember, it was important that the wire polarity be correct, but I believe you can see for yourself if that is true from the figures. BTW, I'm assuming you were firing spark while cranking. It would be interesting to compare with the coils unplugged.

Are you talking about firing spark with the tach test code or the datalog? Does the tach test code do anything to the coil drivers? With the datalog I had the engine running for most of it, then stopped the engine and cranked five times to show what was happening typically when uS was trying (and failing) to synch.

By the way, what is "correct" wire polarity? The scope photo I posted earlier was reading pin 32 relative to 33; the VR pulse swings positive first, then negative. Is that nornal or inverted from what uS expects?

In retrospect, I am really surprised to see such different traces from the two inputs. I have, in the past, scoped both VR signals concurrently, at the Ampseal connector. They both went positive then negative, they were also the same amplitude and the same shape. The fact that the processor is getting such different results from processing signals that look the same make me wonder whether there's something wrong with my Microsquirt. It certainly does explain, though, why I had to add advanced offset in order to get dual tachs working with a rising edge trigger.

I was talking about a comparison on the tach test code. But you are right - I keep thinking the engine is sparking when running the test code, but it can't spark. So it means the actual output under real cranking would show much more variation - certainly a lot more speedup in the middle. No the test code does not affect the outputs in any way. So it is more for showing noise/ missing teeth and polarity issues than for times between teeth.

As far as edge detection you want to use the edge that gives you the most vertical line on the raw signal trace, not the edge that flares. The reason is that the square wave generation is based on zero crossing points. A vertical line is unambiguous and exact, a flaring in to zero is very fuzzy, a tiny bit more or less voltage can change the zero crossing point by a huge amount.

It may be that you can get some idea of the state of the input circuits by swapping the two sensor wires where they connct to VR1 and VR2.

OK. I do have two more questions, though:

1. Some third-party documentation says that the Microsquirt inputs are inverted relative to the Megatune/Megasquirt indications, and that a physical rising edge (on a scope) will be falling edge as far as Microsquirt is concerned. Is that true?

2. When you test you tach checker software with dual tachs do you see the same shaped patters on "crank" and "cam"? If so, do they look more like the blue or the yellow from mine?

Thanks,
Paul

As I remember from when I first tested microsquirt, there was a difference in polarity with MS2, but I can't remember whether it was in the inputs or outputs or both.

When I tested the dual tach inputs I got that both tach inputs on the scope, where I had the probes on the VR1,2 inputs to the processor, were identical to those which I recorded using the tach ref program. This was easy to tell as the high level parts were much narrower than the low level sections on both inputs, on both scope and graph.

I'm not sure I understand your second answer here. It sounds like you're saying that you tested dual tachs with inputs driven by a square wave rather than a VR pulse, and that that input square wave was the same as what was shown by the tach tester software. Is that correct?

If that's the case, were you using pins 32/33 (VR) or 30/31 (Opt)? Since pin 4 is used for both VR2 and OPT2, isn't there already some different signal processing going on for the pin 4 input relative to the pin 32 input?

I guess what I really need to know is, when Microsquirt is being fed VR pulses, what should the tach tester signals look like - my blue signal, my yellow signal, or something else entirely?

Thanks,
Paul

SQLGUY wrote:I'm not sure I understand your second answer here. It sounds like you're saying that you tested dual tachs with inputs driven by a square wave rather than a VR pulse, and that that input square wave was the same as what was shown by the tach tester software. Is that correct?

Yes and Bruce confirmed that the microsquirt does NOT invert input polarity - what is on the scope should be what the processor sees.

SQLGUY wrote: If that's the case, were you using pins 32/33 (VR) or 30/31 (Opt)? Since pin 4 is used for both VR2 and OPT2, isn't there already some different signal processing going on for the pin 4 input relative to the pin 32 input?

I was using the VR channels for both square wave inputs.

SQLGUY wrote: I guess what I really need to know is, when Microsquirt is being fed VR pulses, what should the tach tester signals look like - my blue signal, my yellow signal, or something else entirely?

I would say both should look like the yellow trace, but the important point is how the edge times come out. The processor is going to see a square wave no matter what you feed in - it can't sense anything else. For the dual tach case you just need a pair of edges on each channel to give you the same correct rpm. For a missing tooth wheel you also want the missing section time to be as close as possible to 2x the regualr sections.

grippo wrote: For a missing tooth wheel you also want the missing section time to be as close as possible to 2x the regualr sections.

So what happens if it's larger, I'm thinking FZR1000, YZF1000 or FZ700 8-1 set up, where the small 8mm diameter pits are sensed by the VR sensor and then it passes over a much larger slot (endmilled witha large diameter tool, as opposed to a drilling)

Is there any way to compensated for this in software?

Looking for topic will edit later..it's "The ignition only on a motorcycle" thread in this section (Ignition Set Up, Tuning and Troubleshooting)

In your wheel what is essential for it to work with the software is that the missing section be an integer number of teeth in length. For example 8-2 is ok. But the teeth themselves don't have to be 50% duty cycle, they can be anything. Pick an edge, rising or falling, then measure the distances from rising to rising or falling to falling. You should get 8 numbers, one of which will be about 2x the other 7. If this is not even approximately the case, then it won't work with the present software. It could be made to work, but we just can't custom code for every wheel, there are just too many of them.