EVO PnP

For Mitsubishi Technical Chat
Post Reply
Jolly Green Monster
Posts: 25
Joined: Mon Jul 28, 2008 9:06 pm

EVO PnP

Post by Jolly Green Monster »

is it planned?

Simon
Charlie
Syvecs Staff- Tea Boy
Posts: 114
Joined: Thu May 22, 2008 1:28 pm

Re: EVO PnP

Post by Charlie »

Hi Simon,

Yes, its very much planned, we currently need to get an EVO up and running on a GP, then we can do the base board for the PnP

Regards,

Charlie
pat
Syvecs Staff - Cleaner
Posts: 356
Joined: Fri May 23, 2008 10:23 am
Location: Out there... somewhere
Contact:

Re: EVO PnP

Post by pat »

Simon,

Just to expand on what Charlie has said above...

Up until FPGA release 2.16 the crank synchronisation logic was unable to lock on to a 4G63 crank signal because it has only two teeth. The previous FPGA would look for consecutive signal edges of a given direction (rising or falling) and these would be 180 degrees apart, thereby exceeding the maximum of 127 degrees tolerable. With FPGA 2.16 bi-edge triggering was added, allowing detection of both rising and falling edges, which places consecutive edges "only" 90 degrees apart, which is in tolerance. You may have noticed in the 1.5.1 firmware release that this version supports the new FPGA with bi-edge triggering, which was necessary to be able to support the 4G63 pattern at all, but you'll notice an absence of a 4G63 pattern in the engine configuration page.

The 4G63 pattern should be added to a test release that will NOT be available as a general release, so that the true offset can be measured. We have sync logs of the pattern but presently it's not clear where the edges happen relative to events such as #1 TDC, so we need to measure that. If you look at the pattern you'll see that the crank is devoid of any unique pattern that could be used as a key (like the -1 in a 36-1) so we cannot get 360 sync off the crank alone, and the cam signal has more than one tooth, so we cannot key off that either, it therefore cannot be supported by a generic pattern, (much like the Subaru patterns) and has to be a predefined pattern.

Soon after the pattern is tested and true timing information is available, a new code release with a 4G63 pattern will be available, however I should stress that this pattern will be highly deprecated. We will support it because we have no choice. It is a terrible pattern that I wouldn't want to run a lawn mower on, never mind a performance engine, and we would urge anyone considering building a decent 4G63 to ditch the standard trigger wheel as part of their build. This has two benefits.... a) we already support more generic patterns ;) and b) vastly improved timing accuracy and sync diagnostics.

Let me try to explain what I mean by improved sync diagnostics. The S6 is paranoid about synchronisation. It continuously verifies that pulses it expects to see do happen, and that they happen when they should. You'll no doubt have seen the minimum and maximum gap widths definitions, these define what is acceptable in terms of when pulses happen. If a pulse happens outside of the permissible window, a sync fault happens, the S6 shuts down fuel and spark because as far as it is concerned, it has no idea where the crank is at. The pattern was wrong, so it could be anywhere. Safest option is to do nothing until positive lock is achieved again. Now it gets interesting, because if your gaps are nominally 90 degrees and you're going to tolerate the crank speeding up or slowing down 50% between pulses (as it may well do while cranking), then suddenly you find that you need to verify a pulse that's (90*1.5) = 135 degrees later, which is beyond the 127 degrees that the FPGA can cope with, ergo it is not possible to do maximum gap width checking on such patterns...

It is quite frightening to think that for 90 degrees of crank rotation you have no idea where the crank is at, you knew where it was on the last edge, you knew the engine speed at that point and where it should be now, but who knows where it really is ? If you contrast this with a 36-1 pattern, you get an update every 10 degrees, which is a whole lot more sensible, and as a bonus, "every tooth counts", events will always be scheduled to occur referenced to the nearest tooth, so not only do you get frequent updates as you approach the event, you're also waiting until the last moment to get it as close as you possibly can to where you want it to be. Because 36-1 is capable of 360 sync without any cam signal at all, it can be used with a Manual Cam Checklist, so we can support the stock Evo cam pattern with 36-1 crank, no need for additional machining :)

Hope this makes some sense,

Pat.
Post Reply