Cold weather running microsquirt

i tried the car again today with out my laptop plugged in but when it completed the warmup cycle it did the same thing horrible sync loss at 2500rpm, i turn the car off and start again same thing. i shut the car off and let it sit for at least 5 minutes i can rev to 3500-4500 rpm but still get sync loss. still reason 17. i moved the spark plug wires away from the harness and checked my connections. i dont have any noise filtering on because i dont know how to set it up. can someone please help me out here as i cannot go any farther until i can cleanly rev to redline- 6500.

composite log

Edit2:
Your cam/crank edges aren't setup correctly, which is causing the sync loss.

If you look at screen 34 of 47, you'll see that the active Cam and Crank edges are right on top of each other, and actually trade places, causing the sync loss. You're triggering on the opening of the Cam window (falling edge in logs). This will shift your timing by ~90 degrees from expected. You can probably fix this by using the opposite Crank edge, and adjusting timing slightly, or by changing Cam edge and going back to normal CAS/Shaft alignment, and adjusting timing by a lot.

I'll try to annotate a couple screen shots from your log tomorrow to show the above notes pictorially.

Thanks a lot. I had talked to josh from YoshiFab yesterday and he informed me that I should be running a 60* offset instead of 10* degrees, I will be doing that today. When I do that I will still need to switch the cam edge correct? Then I will proceed to reset base timing.

The offset won't cause lost syncs. Changing the offset only reduces timing error in some applications, firmware dependent.

If you're triggering on incorrect edges, address that issue first.

Ok. I will change the trigger issue. do i need to change both or just the cam edge?

DSM CAS Lost Sync Analysis

TLDR - try changing the Ignition Capture to Falling and use a timing light to slightly adjust Tooth #1 Angle.

The underlying problem is that the more recent MSextra instructions for using the Opto-Isolator for the Cam input use a different circuit than the older instructions. The Official DSM CAS Guide was based on the older circuit.

The newer circuit connects the CAS inner wheel Cam sensor to the OptoIn pad and jumpers a couple diodes. The older circuit connects the CAS inner wheel Cam sensor to the XG1 pad. The newer circuit inverts the signal between the CAS and the CPU, the older circuit is non-inverting. As such, the MegaSquirt "2nd Trigger" edge needs to set to Rising when using the new circuit, and set to Falling when using the older circuit.

Your .msq has the "2nd Trigger" set to Falling. This causes the opening of the CAM slot to be used as the reference position instead of the closing edge of the CAM slot. This in turn causes the timing to be off by ~75degrees (the length of the CAM slot). Rotating the Aux shaft can help correct for this, but simply changing the 2nd Trigger edge should have resulted in the CAM slot ~half covered by the sensor when at TDC with a ~10degree offset.

The other problem with using the wrong Cam edge is that the rising Crank pulse edge occurs at almost the identical position. Your log initially shows the Cam falling edge occurring just barely after a Crank rising edge. These edges get closer later in the log. Eventually, the edges swap and the Cam edge occurs just before the Crank edge. This results in a short slot count -- 23 teeth counted between Cam events instead of the correct 24. When this is detected, a LostSync error is declared.

I've run out of time for tonight but I'll edit this post later to add some annotated screenshots from your composite log that show how the Cam/Crank edges shift and result in the LostSync.


Update: here are some screen shots from MegaLogViewer showing the composite log.

The log shows Cam events as Green spikes and Crank events as Blue spikes. The Green Cam spikes are going downwards because MS is configured for 2ndTriggerActiveOn = FallingEdge; the Blue Crank spikes are going upwards because MS is configured for IgnitionInputCapture = RisingEdge.

You can see a more accurate Cam waveform representation if you have the paid version of MLV and turn on Options-RenderIncludingNonInterruptData. [If you enable NoiseFiltering but leave the Crank and Cam options off, the composite log will also include both Crank edges -- I'm not sure if this is a feature for all MS versions or just MSextra 3.3.] You can get a rough idea what the Cam waveform looks like from the 2nd column of numbers, the "SecLevel Flag".



The 3rd column of numbers is the TriggerFlag or selected Cam edge when setup for a DSM CAS. The circled "1.0" value is the falling Cam edge at the white cursor in the waves. The 5th column of numbers is the elapsed time, in milliseconds, since the previous Crank or Cam event.

In this picture, from near the beginning of the log, the time per crank tooth is ~2.9ms or ~1700rpm. The cursor is on the Crank event just before the Cam event. In this case, the Cam event is only 0.01914ms after the Crank event. This is way too close for reliable operation.

Here's a picture from later in the log showing several occurrences of LostSync.



In this case, the cursor is on the Cam event just before the second LostSync region. If you click on each of the Cam events leading up to the cursor, you can find the delay between the previous Crank event and the Cam event (or just find the events with a 1.0 in the Trigger column). This is the equivalent of the 0.02ms number from the first (good) picture.

The delays, in milliseconds, are all very very small:
6.6E-4
6.6E-4
0.0
6.6E-4
0.0

The failing Cam event at the cursor has a delay of 1.56228ms, instead of near 0. In this case, the Cam event shifted and occurred just before the Crank event (which occurred 6.6E-4ms later). This results in only 23 Crank teeth between Cam events, and causes the LostSync. If you notice, the top of the screen is the trigger event for the previous Cam (1.0 in Trigger column), and there are only 23 Crank entries before the failing Cam.

I know this is hard to follow, especially from a dense description, but can folks understand what's happening?

The selected Cam/Crank edges are almost on top of each other and, if they swap order, a LostSync occurs. I don't know why the events would swap order but a 6.6E-4 millisecond delta is really small, probably less than 0.2 thousandths of an inch in distance on the CAS wheel (or ~5 microns for you metric types). Maybe temperature, vibration, and rpm are enough to give this mechanical shift.

The fix for this problem is to use the opposite edge of the Crank signal so that it will be far away from the selected Cam edge. The Crank pulses are a little less than 50% duty cycle so changing edges results in a ~0.4 tooth delay. With 24 teeth per 2 engine revs, this gives ~12degrees of timing delay. It's late so I won't say if the delay is + or - degrees of BTDC timing.

Let me know if there are questions, or egregious typos, and I'll address them tomorrow.


For 142 guy's questions, I think the MSextra guides must have changed again. The old MegaManual used the old Opto circuit. The MSextra 3.2 & 3.3 guides used only the new Opto circuit, but I do see that the latest 3.4 guide now includes both. Ahhh the joys of MegaSquirt and its ever changing recommendations.

-Bob

bobxyz said:

The underlying problem is that the more recent MSextra instructions for using the Opto-Isolator for the Cam input use a different circuit than the older instructions. The Official DSM CAS Guide was based on the older circuit.

The newer circuit connects the CAS inner wheel sensor to the OptoIn pad and jumpers a couple diodes. The older circuit connects the CAS inner wheel sensor to the XG1 pad. The newer circuit inverts the signal between the CAS and the CPU, the older circuit is non-inverting. As such, the MegaSquirt "2nd Trigger" edge needs to set to Rising when using the new circuit, and set to Falling when using the older circuit.

-Bob

Click to expand...

I am not advocating for either arrangement for wiring up the cam signal through the opto in circuit; but, I am curious about the reference 'the more recent MSextra instructions for using the Opto-Isolator for the Cam input use a different circuit than the older instructions '.

The MS2/Extra 3.4.x version of the Hardware manual dated 2015-07-09 lists both the pull up resistor style input and the ground switching style input circuits for use with the opto isolator input (page 73 of the manual). The manual states that the ground switching configuration 'will usually give more reliable operation'. The B&G documentation also describes the ground switching circuit (you have to search for this) for use with Hall and optical sensors, stating that it is more immune to noise. I must admit that it is not immediately obvious to me why the ground switching circuit would be more reliable or immune to noise than the pull up resistor method. That said is there a more recent version of the manual (that I have missed) or is there some other reference that no longer favours the ground switching circuit?

As an additional note to the MS2/Extra manual ground switching circuit, you need to consider reducing the resistance of R12. 390 ohm may result in marginal operation of the opto isolator. The 4n25 opto isolator needs a forward voltage of at least 1.2 volts on its input and should be biased to have a forward current of around 10 ma. With Vcc at 5 volts and losing 1.2 volts across the 4n25 input and about 0.4 volts when the CAS is in its low state, R12 should be reduced to about 360 -330 ohms to get closer to 10 mA through the 4n25 input.

Bobxyz thanks so much for taking the time to explain how the sync loss is happening and how to read the composite logs and understand them it's a HUGE help.

So what we ended up doing is changing the cam from rising to falling and then set the offset to 30* with a fixed 10* of timing. We then started the car and looked to see what it got us for timing. It ended up being retarded by about 5*. We then turned the cas counter clock wise as far as we could and that put us around 20-30* advance (I don't remember exactly what it was). So then I set the offset to 49* and that put us at 9* advance so I backed it off by 1 and we ended at 48* offset with a fixed timing of 10*. I turned the timing table back on and the car fired up MUCH MUCH quicker, it now idles at 900 rpm, it went through the warmup cycle and I was able to rev up to 5k with no sync loss, it fell on its face because above 4K the fuel table hadn't been touched so it was pig rich. We took it out and ran some passes (it was getting dark quick and I don't have any of my lights wired up) it revs clean up to 5k in first and clean in every other gear up until about 1 psi of boost because the VE table is so rich. Now it looks like I'm getting a sync loss when ever ts tries to write something to the controller. We were using auto tune and each time it made a change and wrote it, it would loose sync. Is this a common problem? I figure when I take it out today I will turn off the auto write make a pass then stop save, write to controller, rinse and repeat. I'm using the usb to serial from diy I'm just not sure why it's happening.

With MS1 and MS2, any time you burn anything to the ECU with the engine running it will reset the processor and cause a susequent sync loss condition.

Great, glad you got it running without Lost Sync (other than the expected hiccup whenever updating MS configuration)!

For completeness, when convenient, can you post a new composite log along with your final MS settings (IgnitionCapture edge, 2ndTrigger edge, Tooth #1 offset), and if you still have a rotated aux shaft or not?

Ok I will run a log in a few minutes

updated tune

ok here is the updated tune with a composite log. i left the aux gear turned one tooth inside the window so when you are looking at it the window is completely inside the sensor instead of half in/out. the cas has been advanced as far as it can go (tuned it counter clockwise). that ended up allowing me to run a 48* offset and gave me a fixed timing of 10* with both ign. capture on falling and 2nd trigger active set to falling.

Just to follow up on Bob’s notes about the cam and tach transitions being close to, or actually falling on top of one another if you use the cam falling edge as a trigger. I had noticed the time difference issue of the respective triggers that Bob identified when bench testing the CAS earlier; however, I was still fumbling with the trigger function on my scope so at the time I was not able to capture any waveforms and make any quantitative measurements of the problem. I finally managed to figure out the trigger function yesterday and was able to do some tests today.

For these tests, I have the CAS in the Yoshifab adapter mounted in a vice and I am driving it with a cordless handheld drill. The maximum speed at which the CAS can be driven by the drill is around 1000 RPM. For this test, I am using simple pull-up resistors on the two CAS outputs. The CAS has the high resolution Yoshifab disk installed.

The following picture shows the CAS outputs (Cam – blue, tach – yellow) with the CAS being driven at about 122 RPM. I say ‘about’ because I estimated the RPM by measuing the period of the first tach pulse following the cam pulse, multiplied that by 24 to get the period of rotation for the disk and multiplied the reciprocal of the period of rotation by 60 to get the approximate RPM. Because I am manually holding the trigger the RPM can be quite variable, so the measured RPM values have a fair degree of uncertainty.

The issue that Bob identified is quite clear in the picture.



Zooming in on the falling edge of the cam signal, the time separation between triggering on the falling edge of the cam signal and the rising edge of the next tach signal is only 0.6 ms. This works out to about 0.44 degrees of rotation of the disk.



Zooming in on the rising edge of the cam signal, the time separation between triggering on the rising edge of the cam signal and the next falling edge of the tach signal is 4.5 ms. This works out to about 3.3 degrees rotation of the disk.



Clearly, as Bob notes, there is a lot more angular separation if you are triggering on the rising cam edge and the subsequent falling tach edge.

At 6000 RPM (my B20’s red line), the .44 degree angular separation between the falling edge cam signal and subsequent rising edge tach signal is down to around 24 micro seconds. However, the MS2 processor clock speed is 24 Mhz which means a clock period of 0.042 micro seconds. The MS2 clock can run through approximately 570 cycles between the cam trigger and tach trigger events. I don’t know how the ignition timing loop is set up in the MS code; but, I expect that servicing the cam and tach trigger interrupts with the 0.44 degree separation might not be a problem for my B20. Using the rising edge of the cam pulse / falling edge of the tach pulse does give you a larger angle spread; however, conversely it does chew into the available time following the tach pulse for calculating the ignition advance (which is also probably not going to present a problem).

I am currently using a falling edge cam capture and rising edge tach capture in my MS configuration (so I am triggering off of the back edge of the cam signal). I have bench tested the set up to about a crank speed of 2500 RPM (different drill!) without sync loss. I recognize that this is a somewhat limited test and as such, is not definitive. Actual in vehicle experience may cause me to switch to the rising edge cam capture..

Because of the signal processing circuits present in the CAS, I was initially concerned that the phase relationship between the cam and tach windows might be changing with disk speed and as such, there might be a definitive edge that you had to trigger off of if you wanted to maintain a consistent angular relationship between the two signals. To check this out, I repeated the measurements that I took with CAS speeds at roughly doubled increments (up to the limits of my drill). The results follow:



Within the uncertainty of the calculated value of RPM, I think it is reasonable to assume that the angle separation between the cam and tach pulse remains consistent regardless of whether the rising edge or falling edge of the cam signal is used as the trigger.

Bob’s update to his recent post where he identifies the time between the cam and tach triggers being in the order of 66 micro seconds at 1700 RPM is a little surprising; but, not out of the realm of possibility. The first variable is the Yoshifab high resolution disk. It is clear that the phasing of the tach windows relative to the cam window has changed from the one used by gross polluter in his 2010 thread. It may be reasonable to assume that there are variations between production runs on the recent disks. It would not take too much variation in punching out the tach or cam windows to mess up that 0.4 degree spread that I measured on the disk that I have. The second issue is the 4n25 opto isolator. With the 4.7 k ohm load resistor (R13) that is used in the MS build the 4n25 has a fixed response time / propagation delay of around 0.030 ms.








If you are using the Vr input for your tach signal, it likely has a different propagation delay. If the Vr circuit propagation delay is much shorter than the opto isolator, this will chew into the margin between the cam and tach triggers if you are using the falling edge cam trigger (it messes up the rising edge also; but, you have more margin to play with). If you are using a disk which already has minimal spacing between the cam and tach windows, this propagation delay could start introducing sync errors as the RPM increases. As it turns out, I am using opto isolators for both my cam and tach inputs. This introduces a consistent 0.030 ms delay on both triggers which preserves the phase relationships present on the disk (it just means that everything is 0.030 ms late!).

As an observation, MS2 was never designed to have a cam input so the potential difference in transportation delay in the opto versus the Vr circuit would not have been a design issue. Bringing the cam signal in through the opto circuit was a bit of a bodge job. Much better to have identical circuits on both signals (dual op amp comparators or dual opto isolators) which introduce identical propagation delays to both signals. Just my opinion.

If I still had the Vr circuit on my MS board it would be easy to measure the propagation delay through the Vr circuit. However, my Vr circuit hit the dustbin to make space for a second opto input so that is not in the cards. Maybe somebody else is interested in doing this to see whether using different style circuits is just a little bodge or a significant bodge.

In short, triggering on the falling edge of the cam signal may work just fine; but, may not. Triggering on the rising edge of the cam signal should be a more durable solution, providing your Yoshifab disk is not significantly different than my disk or Bob’s disk. If there are variations in the Yoshifab production runs which alter the phasing between the cam and tach windows, there is no guarantee as to which edge to use. The up side is that if one edge is flakey, the other edge should work. You may need to test using a scope or the process that Bob used to confirm the appropriate edge to trigger on. If you want to completely eliminate this particular piece of uncertainty, you could always go to the OEM 4 & 2 disc that came in my CAS and block off one of the cam slots. That would give you lots of angular margin between the cam and tach windows!

Acurry6 said:

ok here is the updated tune with a composite log. i left the aux gear turned one tooth inside the window so when you are looking at it the window is completely inside the sensor instead of half in/out. the cas has been advanced as far as it can go (tuned it counter clockwise). that ended up allowing me to run a 48* offset and gave me a fixed timing of 10* with both ign. capture on falling and 2nd trigger active set to falling.

Click to expand...

The new log looks fine -- the Cam edge is well away from the Crank edge (~0.25ms away at a ~1.5ms crank period, where the 1.5ms is about the same rpm that had ~0ms edge-to-edge delay and was failing before).

In theory, you can spin the aux shaft to any position before installing the belt, spin the distributor shaft to any position before insertion, and rotate the CAS to any position and then cancel it all out by setting the Tooth#1 offset value between 0 and 720 degrees in the MS configuration. In practice, it's best to start with the standard alignments, with Cam slot ~half under the sensor, and 10 degree angle with correct cam/crank edges. This should be close enough for initial startup and timing light adjustment.

Happy tuning,
Bob

--------------------
Comments for 142guy:

- Looks like a nice scope, good sample rate, deep memory and a much better display than my cheap Chinese automotive scope (Hantek 1008).

- Your Hyundai CAS falling Cam to rising Crank (on scope) is fairly small. I'd stay away from this pair and use any of the other edge pairs.

- The filtering of the cam/crank signals should have a constant delay (no change with rpm) unless the speed is so high that the internal signals never reach min/max values. Take a look at the opto output to confirm.

- The nice part of using the Composite Log is that it shows what the CPU sees after any inversion and any filtering delays. As long as the cam and crank filter delays are fixed, the Composite log will show if the chosen edges are too close.

You can't deny the price attraction of the Hantek, plus it has just a pile of channels.

Your suggestion about switching to the rising edge of the cam signal is reasonable; however, to date during testing it has not generated any sync errors in the composite logger. Although my test speeds have been limited. The real proof will be when it gets installed on a running engine and I may end up switching at that point.

You refer to the Hyundai CAS; however, I think it should be clear for people that this particular issue is not related to the source of the CAS. It is more related to the Yoshifab disk. Its a fair observation to say that for the current production run of Yoshifab disks, switching on the rising edge of the cam signal is the safe bet. However, the disk has changed in the past and as such, future users should be aware that observation may not remain valid. As you noted previously, nothing seems to stay fixed with Megasquirt.