# # # # # # # # ##
###### # ## ## ## # ######
_____ ( _ ) | (_) | | _ | | | | | (_) (_)
## ## ##### ## ## ## ## ## ##
_____ / ____| | | | | | |____ \_____|
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: '''BMW triggers''' New: MembersPage/GergelyLezsak/MFiftyTwoTUB - '''M52B28TUB''' trigger details page ---- I plan to summarize common BMW trigger info on this page. Crank trigger on BMW engines from the 80's is 60-2 teeth inductive (VR). Engine codes are M10, M20, M30 First generation of camshaft pulse sender is an inductive pickup on the HV ignition cable for cylinder #1. This appeared on later M20, M30 engines. Second generation of cam pulse senders is inductive (VR) pickup on the camshaft end, single pulse before cyl #1 TDC. Apparently pulse is at the same time when the missing teeth are on the crank trigger. Engine codes: S38, M50 Scope printout of an S38 signal: http://quasar.dynaweb.hu/~lezsi/vems/bmwtrigger/s38-trigger-scope.jpg Apparently this coincidence of cam signal and missing teeth was not supported by old VEMS firmwares (1.2.26 or earlier). The cause is that secondary (cam) pulse is sometimes processed earlier than the first crank pulse, but sometimes later. Triggerlog of this situation (from M50B25 non-vanos engine): http://quasar.dynaweb.hu/~lezsi/vems/bmwtrigger/v3.3_u006408-2013-10-19-14.23.17.triggerlog '''Requires 1.2.27 or newer firmware, confirmed on bench and engine as well.''' With 1.2.26 or earlier firmware: crank-trigger only, and wasted spark. (ignoring secondary trigger). This results in a simple 60-2 setup, running fine. ---- Triggerlog captured in 19200 baud is only good for cranking (at least with 36-1, 60-2 or higher toothcount), as a limitation of serial throughput. '''Beyond cranking RPM, switch to higher baudrate''' See the first sentence of the [http://vems.hu/vt/help/main/tools/triggerlog.html related help] - Thanks, I know this speed limitation, however I thought these logs were made @57600 baud. * Is the connection speed stored in the log? ** the log has certain number of events per seconds (timestamps are stored in 2 bytes, typically, slightly more on average with CRC protection and frame header). ** So (unless very few events because of low RPM) : 0..1919 bytes/sec => baudrate=19200 ** 1920 bytes / sec or more => higher baudrate ** usually it's very obvious (without hexdump -C or any calculation) if line is saturated (phantom missing teeth seen in irregular pattern). But it cannot happen during cranking (even with a theoretical 250 tooth crankwheel). ** changing to 38400 or higher baudrate is required (to get proper triggerlog) if engine speed exceeds appr 900 RPM (assuming 60-2)... but usually triggerlog is used for cranking http://quasar.dynaweb.hu/~lezsi/vems/bmwtrigger/v3.3_u006408-2013-10-19-16.28.17.triggerlog This is a log of an '''engine startup and running fine without missing events''' or trigger errors in vemstune. ----- Trigger log of a BMW M44B19 engine (crank VR + cam HALL) Primary trigger is BMW standard of 60-2 teeth, while cam trigger is 4 teeth with different length for this engine. Scope measurement of the log: https://drive.google.com/open?id=0B_SvHmHLyXE2YXFYTllQNDlDb0k&authuser=0 Triggerlog pic: https://drive.google.com/open?id=0B_SvHmHLyXE2YWRMc1VyQ19QOGM&authuser=0 Triggerlog: https://drive.google.com/open?id=0B_SvHmHLyXE2YVBqdHRlMS1pNzQ&authuser=0 Relevant cfg: https://drive.google.com/open?id=0B_SvHmHLyXE2aDgwdDNaYXRsMEE&authuser=0 I have difficulties setting secondary trigger. Using rising edge, the signal comes after the 14th primary teeth, so "secignore" value of ~15-20 seemed to be a good idea (with or without using sectrig minimum/maximum angle between 80-100 degrees). Still I cannot get this sorted, all I get is various trigger position errors in triggerlog. Any ideas how to get this working? I'm on fw. version 1.2.16 . (tried to go to fresh 1.2.2x versions, but all of them is missing the vems.hex file, so VemsTune couldn't do firmware update). '''Answers in relevant sharing report''' http://vems.hu/vemstune/bugreports/reports.php?cmd=view&key=Kn5Sgq - Apparently changing firmware version to latest '''1.2.27 solved this trigger issue''', thanks. (needed to upgrade bootloader and lock AVR fuses first) However a strange behavior happened today: After a few normal cranking attempts, the ECU refused to leave bootmode, and firmware verify reported that firmware in flash is corrupt. Re-uploading firmware solved the problem, still its frightening to know it can happen -I've never experienced such before. Update: I had serious missfire problems on this car, the engine hardly even running. -It is resolved later by installing new ignition harness. Obviously the AVR got damaged, and that ECU should be gut replaced, or marked as such: * can be misleading if used for bench tests * should NOT be used on real engine at all, especially on vehicle Firmware corruption happened on another car with ignition issues, running on 1.2.27 fw. On 2014-08-01 phonecall it was explicitely adviced that the obviously '''damaged ECU should not be used as is, only after gut replacement. It will not work.''' Flash CRC calc is implemented (although taking more than a few msec) could be enabled to prevent startup with corrupted flash (unfortunately also disables for corruption that is absolutely harmless for engine running => prevents limphome). Will not make a damaged AVR work. '''Replace the damaged hardware'''. * 2 years passed since this problem, the car runs fine on the original ECU hardware, no problems since misfire sorted... 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.