## ## ## ## ###### ###### ## ##
### # # ## # ## ### # # ####
_ __ | | / / | |/ / | \ | |\ \ \_| \_/
##### ## ## ## ## ## ## ## ##
______ |___ / / / / / ./ /___ \_____/
IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now. Visit Preferences to set your user name Summary of change: Currently planning a Audi AAF/7A 20v VEMS Install in a 83'Audi 80GTE quattro (4000q for you yanks :-) AAF 2,5l 5cylnder engine 7A 20v head and intake 89' 20v tubular exhaust manifoild S4 camshaft pulley and tensioner VEMS gen3.3 with fully sequentional injection and COP I am not shure if I will go with the auditrigger setup, since it seems to have some issues. I would rather not use the distributor for timing, but it may have to do for now. I allso have another approach to the audi 3-trigger system i would like to test, as soon as I have the engine running. Consept: The audi 20v engines have 3 sensors: A even 135 tooth starter gear vith VR sensor. A single tooth Crank gear with VR? sensor. And a single window Hall sensor in the Dizzy. The original CPU uses ONLY the single tooth crank-signal wich comes at the same times as the hall signal from the dizzy. This, I believe is done with a gate circuit, because these signals MUST come at the same time, wich can be a pain in the ass! This should be just as easy to do with a divider chip, set to divide by 2. Use the cam signal to reset the chip, wich then will count to 2; only the Crank-signal on the second revolution after reset gets to the CPU. Here, the Crank sync and Cam sync must NOT overlap, as the overlapped crank-signal would be skipped. Why would this be better than the v3.x trigger setup ? The LM1815 detects the crankhome-VR, and the LM1815's output is masked (pulled down) with the cam-HALL. The divider is not done in HW, because the divider in firmware doesn't take much time anyway (much less than the missing tooth detection): the CPU-load of dividing the 135 tooth in interrupt is no problem at all. * So the divider HW would not solve any existing problem, it could save a few clock cycles that help none * but the divider HW would add the risk of reset not hitting the same tooth every time, but a +1 tooth error Any ideas are welcome! Optional: Add document to category: Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.