TOYOTA SUPRA V6 biturbo
- 6 cyl , 2.5 L
- 2 turbocharger
- low impedance injectors
- VR primary trigger
- stock 12 toothed crankwheel (30 crankdeg per tooth)
Engine started with 1.1.11. Needs tuning.
Igncut.als is logged since firmware 1.1.8 ("A" command offset 52). Meaning: 0 .. 16 (0 is no igncut, that is normal operation). It just needs to be logged from MegaTune (new MT release will have it from factory - scheduled 2007-02-10).
Dangerous idea - DO NOT remove a teeth
An idea was to remove 1 tooth (black circle) => 12-1 toothwheel.
There is some risk of an abnormally high amplitude VR signal at the missing tooth. Scope (or soundcard) recording of this trigger is definitely a good idea.
Camsync 1 pulse is available (otherwise an M8 screw would do it, used with GT101 HALL sensor, see sensors in WebShop), see InputTrigger/MultiToothNoneMissing and treat it as 24 + 1 setup (as if 24 was on cam; but 12 on crank is better timing precision, of course, because no cambelt sloppniness).
Q: MembersPage/PhatBob what model of Supra is this from? All the Toyotas I've seen have a 12 tooth per crank revolution and one or two cam sync's. I have a fair bit of toyota info so if you could give me the engine number I'll see what I can find
A: 1JZGTE engine. It has two cam sync.
- You should be able to use these triggers without modifying the crank trigger as this is, believe it or not, the same trigger pattern as you find on the Honda, Mazda RX7 and other Toyotas. With this trigger and cam sync you should be able to run semi-sequential and wasted spark very easily.
Config for 1.1.11 firmware
1.1.x firmware
- early 1.1.0 to 1.1.10 only supported missing tooth wheels (with or without camsync) and 135 tooth auditrigger
- since 1.1.11 also supports the simple none_missing toothwheel. This is actually simpler than the missing tooth code. It is configured as "coiltype", but several variable that were "don't care" earlier now are important
- primary_trigger=07 # coil type, filtering, rising edge. Alternatively 06 would be falling edge (could be suitable for HALL, but not for VR)
- secondary_trigger=19 # camsync, rising edge; alternatively 1d is same, but with filtering
- tooth_wheel=18 # decimal 24 tooth (between cam pulses)
- trigger_tooth=01 # or upto 03
- ign_tdcdelay=C4 # 98 crankdegrees
- another_trigger_tooth=04 # 24 tooth / 6 cylinders
- tooth_width is allowed to be higher than 64 degrees. The missing tooth width is the upper byte. (there is no missing tooth anyway). Use 0 if the tooth distance is less than 64 degrees.
- tooth_wheel_twidth2=00
- tooth_wheel_twidth1=78 # decimal 120, that is 30 crankdeg per tooth
These should not surprise anyone:
- RPM constant for 6 cyl = 2000 (=0x07d0)
- rpmk[0]=07
- rpmk[1]=d0
- alternate=15 # injgroups 5 .. 0 (fire all banks during cranking)
- ignchmax=05 # ignition 5..0
- reset_engphase_after=40 # since camsync is used
- h[1]=00 14 10 0C 08 04 .. ..
- h[2]=10 60 50 40 30 20 .. ..
- This table assumes that after ignch1: ignch2, ignch3, ignch4, ignch5 and ignch6 fire in this order. Which is recommended, but not actually wired this way in the Supra installed by Fero.
After the (secondary trigger) campulse (taken from the middle cam transceiver; not the other cam transceiver at cyl6 that was 360 crankdegrees offsetted), the (primary trigger) cranktooth is named tooth0 (first, topmost entry in the example h[1] reftooth table). Tooth 4,8,12,16 and 20 follow, in this order (going from bottom to top in MegaTune).
128 degrees (trigtooth=1 + ign_tdcdelay=98 crankdegrees) after tooth0 we have the TDC of cyl2 (connected to channel 1 in our example, that is 0x10 in the first entry of the h[2] ignition output table ).
The car is running now with Firmware_1.1.11, and we made the base tuning on it. We we'll take it onto the local DYNO soon. Here are the working config files:
real POWERSHIFT firmware request:
Similar to shiftcut but not full igncut, but retard and partial igncut.
Many racecars using this method with great results! Here it is:
- we don't need to cut 100% ignition, we should be able to define the cut%, for example ign_cut=30%
- we also need to retard the ignition, for example shift_ign_retard= 35 degrees
- absolute or relative ? I guess absolute (degrees after TDC)
- we need to define the shift time (this is already implemented), for example 100ms
- we need to define the minimal TPS%, when the powershift is active, for example: powershift_min_TPS=80%
- why is this necessary ? so shiftcut does not interfere with low-load (clutch-assisted) shifting ? I cannot imagine any problems with the 100ms igncut (will not be able to create boost in that time with that air quantity)
- and at last, we need to define the upshift and downshift sensor voltage thresholds. It's needed because we couldn't place a switch easily to activate this function, but it's easy to place a linear potmeter to the shifter(sequential gearboxes), so we need to know the voltages when upshift and downshift is happening.
- For example upshift_volt > 3.46V and downshift_volt < 0.94V.
- but otherwise same action for upshift and downshift, right ?
I tested this system in cars with other ECU-s. Surprisingly great effect. Shifting is very short, very accurate, and the boost pressure never falls, it's consantly the same from the first gear till the last gear. Please implement this great system into VEMS! Thanks!
NOS
We need to use NOS in the car, so i have some ideas about it.Here is how i think about VEMS with nitro:
- we need to define the output that will be activate or inactivate the NOS
- Also we needed to define min_RPM, max_RPM and min_TPS for the nitro output to ba active.This is needed to save our engine from damage.
- When the nitro output active, than we need +/- modification factor for the ignition table, for example -5 degrees
- Also we need +/- modification factor for the fueltable, for example +15%.
- this will not work as the N2O solenoid feeds RPM independent flow, while the fuel injectors feed RPM-dependent flow. At higher RPM added fuel would be too much, at low RPM it would be too little
Positive, negative modification is needed because on this way, this solution could be used with water injection systems too!
I think this system could provide great NOS control for us. Please implement it into VEMS.Thanks!
Because of the variaty of demands, we're implementing a switch function that switches ALL tables and config to a new set (almost like swapping controller ;-)
Besides the analog input condition, we make it depend on misc1 condition (if configured so).
Note: it would be easy to connect the switch between misc1 output pin (instead of GND) and input, but the switch-back from the alternative config to primary config would be problematic.