Elise / K-Rover trigger
From fw 1.2.17, this special trigger is also supported with camsync
- original implementation was without camsync
- engine was mostly installed with wasted spark anyway
This trigger supports cylinder numbers:
- 4 (next trigger tooth=18) (most often used)
- 6 (next trigger tooth=12) since teeth 0,12,24 exist
- 12 eg in the iconic LAMBORGHINI DIABLO (next trigger tooth=6) since teeth 0,6,12,18,24,30 exist
- 8 cyl possible also (next trigger tooth=9): teeth 0,9,18,27 exist
- but if CYL=8 is configured for exact RPM reading... (For ign and inj the primtrig settings matter not the configured CYL number) then firmware assumes ChryslerHemi (a different kind of trigger) where "number of teeth on wheel"=32 also, but "Number of cyl"=8
- so if you know any factory 8cyl engine with this Rover triggerwheel, yell here ! (then minor config change must be applied to differentiate the 2 trigger patterns when 32 teeth, 8 cyl is configured)
- Any info about the Rover-K camsync position sensor standard position ?
- we're testing this rover-k / elise trigger with camsync chosen edge anywhere from 10-350 deg: but NOT exactly at tooth0 (and also testing without camsync)
- if, though extremely unlikely (would be very stupid and according to all available information is NOT the case), both edges happen to race with tooth0, we either need a proper secignore setting, or change the internal numbers to move about 180 deg ...)
- from 1 source, at least one edge of sectrig seems to be very near TDC, so NOT racing with tooth0 (good)
- write here if you're installing an engine with similar trigger, or upgrading an old install to new firmware and wish to communicate / feed-back
Best location of the LCD display is on the removable steering wheel.
So, after searching a bit for the wireless connection of the VEMS display with the RS232 link, I find the RF Solutions company in GB, they have the right solution for that. (Try before with ZigBee, but this kind of wireless communication is not the best from technical side)
There the link:
http://www.rfsolutions.co.uk/acatalog/Smart_Radio_433_Transceiver_Module.html
I do now a bit research for the best display module for the VEMS. Too small displays are not practical, if we count with the vibrations in most of the racecars today.
Bye: Yasec
The car got an 1.6L 4cyl NA engine because it is believed to better compete in that class, compared to the 1.8L engine.
Location: 3h drive West from Budapest (Sopron, at Austrian border).
Because of illness the project was delayed, but it should be completed
This engine has a special trigger, and the PlugAndPlay harness makes overview and debug hard.
IAC
MembersPage/YasecElise/IdleAir Simple bipolar stepper
MembersPage/YasecElise/Ignition
MAP / AlphaN
The engine has a MAP sensor. However, because of very aggressive cams, some loadsites might need to be tuned from TPS (AlphaN).
Trigger - Rover K-series wheel (we refer to it as "elise" trigger)
The engine has camsync, but because of wasted spark, only primary trigger will be used for now.
- Primary trigger VR
Is there a chance that something is fundamentally wrong with the trigger ?
Maybe the trigger is HALL ? can you measure ohm between trigger pins ? Both polarity.
Try to record the trigger signal with notebook soundcard.
Try 20k pullup on the trigger signal.
This crankwheel is very smart construction, because it can sync in half revolution (often even earlier!).
- Early startup is supported (the right output channel will be fired as soon as it can be found).
- camsync is currently not fully supported for this elise trigger (recommended to keep secondary_trigger disabled in config)
We made some modifications to signalgen to generate the wav sound files to test the trigger setup on the table. Firmware code was tested against this.
The trigger is supported from 1.0.38 with the following setting (multitooth, no camsync) MAKE SURE YOU TRY THESE TOO, there is a mismatch right at the very first (primary_trigger=00 is not 01 although it might work with both edges if the sensor is HALL for sure):
- primary_trigger=01 # multitooth (advanced filter is not applied; actually, advanced filter could work with N-1 setting)
- secondary_trigger=02 # disabled
- another_trigger_tooth=12 # decimal 18, no surprise
- tooth_wheel=20 # decimal 32, no surprise (36-4 wheel)
- trigger_tooth=04 # 0..12 could work with different TDC position; 4 seems right with above drawing
- ign_tdcdelay=78 # decimal 120, that is 60 degrees; according to drawing, TDC is 60 degrees after tooth 4
- this can be varied of course, but F0 sounds way too high (adjust trigger_tooth instead);
- is it possible to check with timing light ?
- ignchmax=03 # fire ign channels 3..0, and ign sequence:
- h[2]=02 03 02 03 00 00 00 00
- assuming 03 channel (EC36pin36) is wired to fire spark for cyl1 and 4 TODO: confirm or correct this !!!!
- 02 channel (EC36pin34) fires cyl2 and 3
Take InputTrigger/TriggerLog to check the tooth pulsetrain correctness. (upload the binary too, and possibly the output after formatted with perl binary.pl < terminal.log > terminal.txt )
Because of the extremely fast acceleration (this engine has a special coating and lightweight structure) and the special trigger wheel, some modifications were necessary to the advanced multitooth filter.
Trying 1.0.48 experimental firmware ... http://cell.dyndns.ws/del/v3_firmware_1.0.48.zip
Test results with 1.1.88
Rover-K_Lotus-elise_(e324) trigger fixed in firmware 1.1.88
Works with camsync too.
To configure just use the "rover-k_lotus-elise_e324 "configlet in primary trigger settings.
Tested config: http://www.vems.hu/files/MembersPage/YasecElise/v3.3_n001212-A-2011.01.25-10.52.59.vemscfg
A describtion of the trigger (HU; just to confirm the direction and position seen on the image):\n
Mind1, itt küldöm a képet, immáron dedikált lendkerékkel. A felsõ holtpont fizikailag ott van, ahol a lendkerék tövében a csap van. (azaz van 6db felfogató csavar + 1 tájoló csap, na a csap van felül holtponton) A jeladó ehez képest lejjebb van, gondoltam azt a bordát jelölöm meg, amit "lát" a szenzor felsõ holtpontban. Komikus mód ez úgy semmilyen rendszerben nincs semmivel se. Utána a forgásirány szerint még kettõ bordát "olvas" a szenzor, és kezdõdik az elsõ kihagyás. Udv Yas Azt hittem soha nem fox feliratkozni.:) Lenne 1 kersem:) Ha lehetne akkor kommentalnad magyarul is a torteneseket? Lassan azert tanulok angolul:) A_Feri/Saybor:)
Here are the configuration files:
Seems very nice, signal and polarity is correct. Analysis of the file, missing teeth:
- position (in [triggerlog]), difference from following
- 41 3
- 47 13
- 73 2
- 77 14
- 105 3
- 111 13
- 137 2
- 141 14
- 169 3
- 175
3,13,2,14, ... pattern seems correct for the wheel.
worst case: (note that the log is very-very short read below! There are likely to be worse cases)
- highest tg/tg_prev for single tooth: 1.16 (2010/1733)
- lowest tg/tg_prev for missing tooth: 1.41 (1869/1318)
The problem is, that the engine stroke kicks the engine at the 169 position, so the crank accelerates (I guess it has a lightweight flywheel).
Therefore the 1318 (*4 usec) difference is followed by 1869 difference, which is LESS THAN 1.5 * 1328. Normally a missing tooth is 2x normal tooth, and the standard code only consides it missing if >1.5 x
We must use multitooth advanced filter (checking toothrel_ ... on GenBoard/UnderDevelopment/FirmwareChanges), and set the treshold, so 1869 / 1318=1.41 is accepted as missing tooth.
- primary_trigger=09 # instead of 01, to enable multitooth advanced filter
- toothrel_normal=44 # or 54; tg_prev * n/16 <= tg <= tg_prev * (1+N/16)
- toothrel_missing=40 # tg_prev * (1.25 + m/8) <= tg <= tg_prev * (2.5 + M/8)
Explanation - N,n,M,m are one hexa digit each:
- toothrel_normal=Nn #tg_prev * n/16 <= tg <= tg_prev * (1+N/16)
- toothrel_missing=Mm #tg_prev * (1.25 + m/8) <= tg <= tg_prev * (2.5 + M/8)
OLD semantics - before 1.0.40
If the tg (time-gap) between 2 teeth compared to tg_prev (previous time-gap)
- if( tg_prev * (1-n/16) <= tg <= tg_prev * (1+N/16)) than it's considered normal tooth
- if( tg_prev * (1.5 + m/8) <= tg <= tg_prev * (2.5 + M/8)) than it's considered missing tooth
NEW semantics - since 1.0.41
If the tg (time-gap) between 2 teeth compared to tg_prev (previous time-gap)
- if( tg_prev * n/16 <= tg <= tg_prev * (1+N/16)) than it's considered normal tooth
- if( tg_prev * (1.25 + m/8) <= tg <= tg_prev * (2.5 + M/8)) than it's considered missing tooth
As you see, for the missing-tooth condition, original 1.5+m/8 changed to 1.25+m/8 in http://www.vems.hu/files/Firmware/release/v3_firmware_1.0.41.zip
In our case, it's critical than N is 6 or less. Thresholds for different config:
- toothrel_normal=6x # 1+6/16 = 1.375
- toothrel_normal=5x # 1+5/16 = 1.31
- toothrel_normal=4x # 1+4/16 = 1.25 ... recommended
Apparently it's problematic to define a good threshold for this engine. 1.5 was too high by any means, 1.375 didn't work either (we don't know exactly why, it didn't improve from 1.5).
The best is somewhere between 1.16 and 1.41, my vote is to try
- 1.25 (toothrel_normal=44) first and
- 1.31 (toothrel_normal=54) later
If it really doesn't want to work - note: longer triggerlog needed to decide -maybe (but this is hard, requires nontrivial firmware mod)
- when missing tooth is expected, we should allow tg > 1.25 * tg_prev to be considered as missing tooth
- when normal tooth is expected, we should allow tg < 1.5 * tg_prev to be considered as normal tooth
- what to do when nothing expected ? (at the beginning). 1.31 would be a good threshold ?
Also upload the binary triggerlog (before formatting with binary.pl). Use zip if fileyhingy otherwise does not allow upload.
Analysis of new [log2]
This is a long log, with appr 33 perfect crank rotations.
With improved binary.pl (see http://www.vems.hu/files/MembersPage/YasecElise/trig2_all.zip ) it's easier to spot MISSINGTOOTH for certain threshold (default 1.5, but any other (like 1.31) can be specified on the command line.
The right side is interesting (left side is rabbish), after some good MISSINGTOOTH 13,2,14,3 patterns, the missing tooth was missed, look at the 15 (should be =13+2):\n
257 3518 1.63 MISSINGTOOTH 14 258 48646 1.77 MISSINGTOOTH 2 259 1565 0.44 260 7430 0.15 261 1543 0.98 262 1804 0.24 263 3151 2.04 MISSINGTOOTH 3 264 20230 11.21 MISSINGTOOTH 3 265 1620 0.51 266 21511 1.06 267 1717 1.05 268 46343 2.15 MISSINGTOOTH 2 269 1855 1.08 270 16137 0.34 271 2090 1.12 272 10761 0.66 273 2477 1.18 274 44297 4.11 MISSINGTOOTH 3 275 2282 0.92 276 59914 1.35 MISSINGTOOTH 1 277 2427 1.06 278 31498 0.52 279 2530 1.04 280 57866 1.83 MISSINGTOOTH 2 281 2670 1.05 282 28171 0.48 283 2734 1.02 284 44553 1.58 MISSINGTOOTH 2 285 2478 0.9 286 44551 0.99 287 1702 0.68 288 42504 0.95 289 2168 1.27 HERE_IS_THE_MISSED_MISSING_TOOTH_PROBLEM 290 30724 0.72 291 837 0.38 292 17414 0.56 293 1560 1.86 MISSINGTOOTH 15 294 6147 0.35 295 723 0.46
While the trigger and RPM seemed clean without combustion (eg if no injectors), wheel errors started when injectors got power and combustion took place. This had 2 reason (not easy to find, and almost impossible without above triggerlog):
- power-GND noise injected into VR trigger signal ground (fixed)
- the engine accelerates so extremely fast (due to a coating applied similar as in F1) that the missing tooth's 2 gap took shorter than the previous 1 tooth, just 20 crankdegrees earlier!!! Units are 4 usec (36-4 wheel, single tooth is 10 crankdegrees, so you can calculate RPM):
- 2734 (single)
- 2478 (single)
- 1702 (single)
- 2168 DOUBLE, that is 2 teeth, but only 1.27* more gap than previous 1702, and less than the moving average of previous teeth. This required the 1.0.49 and my_make -D ONLY_LAST_TOOTHTIME so the missing tooth is recognized
- 837 (single)
- 1560 DOUBLE
1.0.49 compiled with ONLY_LAST_TOOTHTIME defined allowed this engine to run.
Earlier (without combustion), it was clearly seen, that 1..2 tooth before the MISSINGTOOTH (after the long, 13 or 14 periods) the engine accelerates appr 10% every tooth. It is so consistent (0.93, 0.81 and 0.92, 0.82, but really very consistent throughout the whole long log!) that makes it suspect there is no combustion taking place AT ALL, we just see the compressed air acting in the cylinder accelerating the engine. RPM was all fine, but with combustion it all went wrong because of the extreme angular acceleration.
So what's wrong with this setup ?
- Does the timing lamp show fire when expected ?
- both on cyl2,3 and cyl1,4 ?
- Maybe base timing is off? (maybe as much as 180 crankdegrees ?)
- it has been verified (Fero just told on phone) that ECU times exactly when expected.
- or fuel quantity way off ?
- fuel pressure ?
- injector supply +12V ?
The original loom (remember than plug-and-play install is always much more problematic than making a new loom) is somewhat brain-dead. The supply to the injectors, fuel-pump, ignition transformers (and ECU) is fed from the starter-motor, instead of the battery. This might mean 1..2V more voltage drop than necessary, which can make a big difference (starting or not), especially with a discharged battery.
Engine started after the supply+ was connsected properly, from the battery. Looking back, this was rather a miracle
The problem was easy to fix (though developer help was needed) when publishing InputTrigger/TriggerLog (see above).
No amount of hard work would help start this engine without doing this triggerlog.
Engine is running
some tuning to do, and upload config and tables.
IIRC trigger_tooth=04 and ign_tdcdelay=54 crankdegrees
Multitooth advanced filter (primary_trigger=09) settings (if Marcell remembers correctly, Fero should update):
- toothrel_normal=0x43 (1.25 threshold) or 0x53 (1.3125 threshold)
- toothrel_missing=0x50
old files:
Question?
Is there a final known good set of trigger settings for this engine?
- as always, start from an engine setup of same cyl count, then in VemsTune, from the bottom of primary trigger dialog apply the relevant configlet (K-Rover / elise in this case; with or without camsync)
- that is quick to apply, and maintained
- also, that is used when testing in lab.
Some very old files:
Firmware 1.0.41 with individual throttle bodies:
http://www.vems.hu/files/Fero/lotus/config.txt