_ | | _ | | | |_| | \___/
#### ## ##### ## ## ## ## ### ##
__ __ \ \ / / \ \ /\ / / \ \/ \/ / \ /\ / \/ \/
## ###### ## ## ## ###
###### ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##
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: Learning curve historical record of prevous problems or wiki interactions * Is it possible to move Ignition out 0 to one of the P259 pins ? ** currently no. It would require a firmware modification. What would be the reason for it? The IGBT can handle anything (and more) that the p259 can. ** If this is about a HW change, and a low voltage (vs. 400V capable, such as a DPAK IGBT) open drain output is sufficient for you, I recommend using a simple uC output or 74AHCT132PWR or 74HC259D and use NPN resistors (such as PDTC123 if low current enough, or other SOT23 or ULQ2003 if current demand is higher). Looks like bins change but Megatune displayed is fixed and must be edited to reflect the new bins.....I guess I am one of the crazy ones that wants to alter the Warmup Coolant Bins. These have not (yet?) moved to flash, if they do not respond to Config File Changes, than it's a megatune issue. Configure outside megatune: * Manmcd dump * extract the warmup_clt_range[]= section as you only need that * save as config_cltrange.txt * edit ** add +40 to the Fahrenheit temp ** convert to hexa * make mtt * send .mtt file to the ECM via TerminalProgram * remember that you have the new bins in the ECU, not the values MegaTune shows ** when tuning warmup enrichment, MegaTune might even recolor the wrong bins, so take care Confirmed: Use config to update bins, edit Megatune init file to reflect the proper new bins. The Warmup active configuration page does not need to be edited as it properly reflects the actual temperature. For those of you that like to understand what you are doing, I have another DUH for you. The criptic I259 and P259 stand for Ignition 259 and Power 259 (I think). The ignition 74HC259 logic level latch which is capible of sourcing output current through a 10K current limiting resistor the the Gate of the Ignition IGBT (Isolated Gate Bipolar Transistor, I think). The Power 259 is not capible of sourcing output current but does have open collector outputs capible of sinking 350 mamps of current. This is how they sink to ground one side of a fan or fuel pump relay coil. ---- '''on 12-1 crank trigger only''' For a single cylinder four stroke, we could desire spark every other crankrev. This would need camsync. With only crank trigger, the best we can do is fire every crankrev, a sortof wasted spark. To generate a spark (normally before TDC) for every revolution, set another_trigger_tooth=24 (decimal 36), since another_trigger_tooth=00 or FF might not get what you want. another_trigger_tooth=0c (decimal 12) could actually work, but without camsync it would have the same effect as anything above decimal 12 (1 event for every crankrev, timed from the tooth trigger_tooth teeth after the missing tooth). Decimal 36 has the advantage over decimal 12 that it does not add an (unnecessary, wasted) spark when (maybe finally) you configure camsync. If you like experimenations, try another_trigger_tooth=0,12 and random values above 12 (I think they will work the same way with only cranktrigger). '''another_trigger_tooth was made for multiple cylinder engines''', where several (2 for a 4cyl) events are needed for every crankwheel missing tooth. For a single-cyl, it's just a disturbing value that is '''to be kept out of the way''', that's all. wiki docs state ignchmax should be "cyl-s (-1) but says "Resist the temptation to set ignchmax=00". The warning is for multiple-cyl engine (and only takes effect when knock-retard is used: individual cylinder-based). For a single cylinder engine, the formula yields zero and ignchmax=00 is perfect. * to generate a spark at TDC for every revolution on 12-1 crank trigger only, set another_trigger_tooth=24 (decimal 36), since another_trigger_tooth=00 or FF would not get what you want (the RPM-calc could be applied with uneven teeth-spacings). ** nothing special about trigger_tooth and ign_tdcdelay, set it as for any other engine GenBoard/UnderDevelopment/AlphaN says- pw = req_fuel * MAP * VE(RPM, MAP) / lambda(RPM,MAP) * gammae * ego_corr (speed density: config13 bit2=0) pw = req_fuel * VE(RPM,TPS) / lambda(RPM,TPS) * gammae * ego_corr (with alphaN, without MAP: config13 bit2=1) Notes: * the gamma_enrichment is the multiple of warmup, afterstart, airdenfactor, baro, etc... enrichments. ** airden: gas law, appr. 10% enrichment for -30C change in MAT ** baro: there is a linear 4% enrichment for 10% less than normal baro (to compensate for more gasflow caused by lower exhaust backpressure) * the '''lambdacorr table''' (the 1/lambda is stored for efficiency, so we call it lambdacorr not lambda) is '''used as a constant multiplier in open loop mode and closed loop as well'''. This is the only reasonable operation that gets the desired operation when user changes VE table. ** note that in closed loop mode, ego_corr is adjusted by the ego controller (config.ego_ ...) considering the measured lambda and target lambda (VE table) ** in open-loop mode, ego_corr is always 1.0 (stored as 128 inside SRAM) so the ego_corr is not changed according to the measured lambda. * firmware (eg. for v3.x) sample MAP before starting, and store that value (unless it deviates from config.baro more than config.dbaro: in that case, eg. if ECM resets during engine running, we don't believe that baro is 20kPa and config.baro is used). grep baro global.h **uint8_t config13; // c13, bit3:baro bit2:alphan bit1:WBO2 bit0:oddfire ** uint8_t baro; // mean barometric pressure ** uint8_t dbaro; // max difference in barometric pressure Why does MegaTune 2.25b not fetch ecu values from the constants page. I set the batt_cal to 165, close Megatune then reopen without loading a MegaTune config file, goto constants and try to fetch data. Batt_cal remains at 0 even though it must be 165 as voltage is being displayed correctly. This is not a big problem, just a curiosity. A: possible version mismatch. Megatune 2.25b is not enough version info to know that you have a matching vemsv3.ini and firmware. We have the complete megatune packages to get rid of confusion problems here. 1.0.30 release package is unfortunately delayed, will upload tonight. Stand by and download that as soon as the new non-rc package is up. //Emil Thanks for the heads up. I believe I downloaded the complete MegaTune package and uploaded the included firmware. I am mostly sure of this as it is the only version of MegaTune and firmware I have. Summary of problem: Megatune reads RPM and MAP correctly but battery voltage is zero. Megatune will write configuration values but only after accepting the low voltage write anyway error warning. Configuration values varified using terminal, however, config can not be written in terminal (probably blocked by low voltage error. A/D must be functional as MAP is correct. Further... put varriable supply into TPS with TPSL=0 and TPSH=ff zero volts is 0% throttle while 4.3V is 100%. Two A/D channels are working while a third attached to a voltage divider is not. Hardware: The top of R13 is at Vin (13Vdc), the middle of the divider is about 2.9V. The 2.9V is present on processor pin 61, ADC0 in. TPS is reading correctly and thus I believe Vref is ok. I believe the hardware is functioning just fine. Is there a way to reflash firmware over riding the low input voltage lockout (which I assume is why I can not flash it the normal way)? The board deffinitely does not have a low input voltage problem. Has this problem occure with other boards? History on Current Problem: I was working with correctly scaling RPM late yesterday. Returned this morning and assembled V3.3 does not communicate well. Under Megatune the voltage is zero while correctly reading the RPM. I can dump tables in terminal but can not reflash firmware. The unit has not been opened (for that matter, it was not even moved on the bench) and thus I do not suspect we did anything to the hardware. Has anyone seen this problem? More Information: I can not update the configuration via terminal. However, I can update values using Megatune (like RPMK(0) and RPMK(1)) and they are reflected in a terminal dump of the configuration registers. Megatune gives a voltage too low to flash, flash anyway message. I let it rewrite anyway and the write was successful. '''A: Have you changed vbatt calibration? I dont remember exactly the name but you'll find it in the menus. If you have any more config related problems, please upload whole mcd and mct output, or msq file from megatune (dont forget to also write megatune version) //Emil''' I was playing with config and thus could have changed vbatt cal. I used review to look at ALL configuration under MegaTune. There is no reference to Vbatt calibration. I have added my config via a link below. If I find a fouled Vbat cal in config, how can I change it (as I can only write config values in MegaTune and MegaTune does not give access to Vbatt calibraiton values)? Batt_Cal=0!! so somehow I screwed it up. Please advise on how to write Batt_Cal from MegaTune or other method that allows for writing with low (perceived) battery voltage. I will look to released firmware for a starting value. * line 6 on Constants view, Battery Calibration is the key. ---- * Firmware version, fill in your info here ** 1.0.xx as released with megatune 2.25b * vemsv3.ini for megatune version ** mt-r2.25b654 * config.txt (output from Manmcd) ** MembersPage/BillHart/ProblemConfig * tables.txt (output from Manmct) ** MembersPage/BillHart/ProblemTables * saved config in megatune format (.msq) ** MembersPage/BillHart/MegatuneConfig ---- '''Solution: I was trying to set RPM calibration in MegaTune. The fetch ecu data function in the constants page does not work and thus when I Fetched, Changed RPM Calibration, and ReSent new data, I wrote a zero to Batt_Cal. The voltage then reads zero which prevents updating values in terminal. Moral- Be carefull in writing just one value in a setup page as the others may not have been fetched from the VEMS unit correctly and thus will be corrupted when you rewrite the page to the VEMS unit.''' Trigger Question 12-1 Wheel single cylinder VR primary trigger Signal being generated by parallel port to op-amp Signal is zero to -3 to +4 to zero Total pulse is 1/20 of the pulse to pulse period single pulse spacing is .794 msec RPM=[1/(.000794*12)]*60 or 6297rpm * Megatune displays 1570 which is almost exactly off by a factor of four * another_trigger_tooth with 12-1 crankwheel, use 24 / cylcount * rpmk[0] and rpmk[1] (upper and lower bytes, respectively): use 12000 / cylcount Dump from V3.3 primary_trigger=01 # secondary_trigger=02 #02 is disabled says Megatune and one configuration example while another configuration example says it is disabled if 0FF????? tooth_wheel=0B # wiki says actual number of teeth 12 -1 or 11 decimal 0B hex trigger_tooth=01 #left at one for now as "timing" not yet important '''another_trigger_tooth=06''' # with 12-1, 06 means 2 events per crankrot, that is 4 events per camrot (4cyl) OK so is another_trigger_tooth=18 or 24 dec acceptable for a one cylinder 4-stroke????? crank_minper=9C #entered 2000 for now wiki says this should be 60sec / max RPM / number of engine events * 2 which would be 60/8000/1*2 or 15,000 usecs this number was not accepted by Megatune tooth_wheel_twidth1=0A #wiki says dec=255/(2*imag teeth) or 255/(2*12)=10.xxx phase 240 for 12-1 and twidth1=phase/(imag teeth * 2) or 240/(12*2) or 10 dec/ 0A hex tooth_wheel_twidth2=14 #wiki says (missing teeth +1)* dec or (1+1)*10 =20 dec or 14 hex I beleive I have followed the wiki examples and my VR pulse input looks ok. Can anyone provide some guidance. * primary_trigger=01 (for toothed wheel, simple enough) * tooth_wheel=0B (12 minus one is 11 dec which is 0B Hex) * tooth_wheel_twidth1=0A # decimal 10, so 720 degrees equals 240 ** reset_engphase_after=F0 # decimal 240 * tooth_wheel_twidth1 needs to be the phase difference between two incoming pulses (== the width of the tooth plus adjacent gap). Beware that it's not in degrees! Unit is determined by config.reset_engphase_after (=>720 degrees), which is usually 240 or 216 depending the number of teeth on the wheel (60/24/12 or 36). GenBoard/Manual/InputTriggerCamSync should tell more. * trigger_tooth=00 is the pulse (== max height middle for a normally conected VR) after the missing tooth. 01 is one tooth later and so on. trigger_tooth + ign_tdcdelay together describe the TDC event for the cyl that is in the last slot of h[2]. Check examples from MembersPage, easier to see from them. As you say, these are the "fiddle factor", since the tooth location usually does not fall directly on TDC. '''Solution: Problem solved... Answers to follow'''' Pulse Width Calculation Does the V3.3 firmware calculate base injector pulse width using VE and Required Fuel only or does it factor in A/F values from the A/F table? Put differently, is the A/F table only for autotune or is it also used for open loop injector pulse width calculations? Is there a detailed explanation of exactly how the injector pulse width is calculated apart from trying to decipher the C code? A: The lambda target table is always in use in the calcs, i dont know where to find the description though //Emil Please advise on what is connected to the flying green jacketed wire protruding from the front cover with white and green wires. '''A:''' Exhaust Temp sensor (( I will look to Wiki fof hookup info, page GenBoard/Manual/ExhaustGasTemp)), just wire the sensor in and do the calibration described on that page We usually call "reverse an existing ignition advance curve" as "alien" logging. Searching for alien on SiteIndex, I found OnlineCourse/AlienIgnitionLogging. Secondary_trigger can still (in recent firmwares) be configured for alien measurements (except for 5cyl), but the alien variables seem to have been ripped from comm.c. Even if they show up on LCD, only useful if they are sent to the PC (like MegaTune) for analysis. Fortunately not difficult to get comm.c send the variables related to alien measurements. *WikiAdvert: mailto:bill@lolachampcar.com 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.