Developer section / Beta Ini files
Locking / Status:
Write your name here when you are actively working on the files
- Unlocked, uploaded [024] - EL
BUGS Found:
- This isn't a bug, but can the RPM constant be calculated by the number of cylinders (12000/ncyl) in the constants window? This causes trouble for some V6 or V8 people.
- do we know any case when rpmk "RPM constant" is not 12000 / ncyl ? If it's always 12000/ncyl, we can calculate it in firmware (just define RPMK_AUTO ; doesn't take much cycles, and frees 2 config bytes too)
- Prime pulse in config is changed when altering boost vs rpm table -MS
- strange looking boost vs rpm table, this will stay this way. megatune problem
- Lambda table does not work good. fixed MT ini used incorrect page reading lambda table. Also firmware fix for unitialized variable in table reading committed to both branches.
- setting beyond extreme (leaner than 1.28 or richer than 0.56) lambda values overflow (at least in 3D view). Lambda values should be limited in config. Fortunately this shouldn't bite anyone in real life.
- the "controller voltage too low for flash-burning" is annoying (at low VBatt), our eeprom (flash is not used for config) can be written even at only 4.5V
- the Kpa readings doesn't work good if i use kpafac and kpaoffset - possible solution below - DB
- the firing sequence during cranking is not right too (in megatune?) in firmware this is believed 2b fixed
- DutyCycle calculation is still wrong. Check my page at MembersPage/GergelyLezsak/MegaTune
- "Boost solenoid off below this pressure", and the boost table boost bins are divided by two. So if you set 70 Kpa boost than the boost target will be 140 Kpa.
- Not actual bug but config pages lines are limited to 20, keep this in mind when editing inis. Does MT support colums like hardcoded std_constants?
- make a "knock gauge" in megatune, it would be very helpfull in tuning. During tuning, i always watching the knock diff characters in the LCD, but lcd IS TOO SLOW to correctly realize knock. So i think megatune Knock Gauge would be necessary.
- I had no idea that knock was working at all, if someone helps me with the firmware part, i'm ready to make a new megatune + firmware release on monday, who can write a simple knock config howto ? //Emil
- Configurable sensors
- Temperature sensors (Configurable scaling, not compile time)
- Will need firmware mods
- Misc inputs (currently 3 spare inputs, Is there easier way to configure scaling of these? Currently, .ini-editing is needed)
- Could maybe be done without touching firmware.. Testing has to be done
- Temperature sensors (Configurable scaling, not compile time)
- Script for re-generating a new config.xml when all scaling is done, or manual generating after May 15
Proposed features
- allow numeric setting of h[1] (8 numbers). Title: "Reference tooth for each cyl". Each entry belongs to the relevant h[2] ("ign sequence output selection") so it would be nice to arrange in a way to emphasize this
- stepper step sequence is not straightforward Stepper can be connected 3 ways, and each can be 2 direction (when testing with mdi.. you know immediately if only the direction is wrong) that is 6 combinations total:
- 1-2, 3-4 0xc9 or 0xd8 most common would rather be written as 0x27 or 0x36 (because 00 02 01 03 or 00 03 01 02)
- 1-3, 2-4 0x1b or 0x39 (because 00 01 02 03 or 00 03 02 01)
- 1-4, 2-3 0x1e or 0x2D (because 00 01 03 02 or 00 02 03 01)
- why don't we make a 8x8 (button) matrix for the INJGROUPs ? Even with EC36pins as the column index (and injgroup number as the row index). Let's call them INJGROUP, because INJFET (in output channel selection dropdown) is bad naming, definitely confusing. INJGROUP5 is clear indication that the group is configured elsewhere
- I have thought of that view earlier, but not possible with current megatune.
- cranking_threshold=03 should display 399 in MegaTune (and 350..450 user-input should be translated to 03). Displaying 300 or 400 is not good, because we really want to know (even over a phonecall) that it's not an old megatune with cranking_threshold=04 but a good one !
- I can look at this tomorrow //Emil
- dwell-wizard: knowing the RPM and actual dwell from the controller, entering 3 values and measuring transformer supply current we can make dwell-tuning fun (same procedure we do manually, see MembersPage/YasecElise/Ignition):
- fires_per_camrot=2 # wasted spark 1 fire per crankrot, that is 2 for camrot. Would be 1 if measuring 1 COP, or 4 if measuring the current of all 4 cyls
- desired_peak=6 # desired peak current (A). Good assumption is that average current during the dwell period is 1/2 of this.
- meas_ohm=0.033 # the resistor used to measure supply current of ignition transformer primary (max 0.1 Ohm is used, often 3 in parallel)
- RPM=1200 # read from realtime data
- actual_dwell=2.8 # (msec) read from realtime data
- optimal_mV_measurement: actual_dwell * fires_per_camrot / (120000 / RPM) * desired_peak /2 * meas_ohm * 1000 = 5.5 (mV)
- the user could adjust dwell in MegaTune until the displayed optimal mV measurement is close to the DVM DC (mean-voltage) mV measurement
- Unfortunately it is only possible to have config parameters that exist in the ECU, and only multiplication allowed, Probably hard to fix this wizard in current megatune, so
- either we need a hardcoded wizard (the warmup wizard is very similar, has everything needed)
- or cheat with config variables (inject them to dummy /dev/null in the ECU) and make the calculated value appear as a calculated config variable. Even than, actual_dwell and RPM might be a problem. We can avoid division if megatune doesn't like it (by exporting const/RPM= rpm_period internal variable; it is actually already exported by mdx.. command, we just need to move to a fixed memory location).
Beta files
- [r025]
- [r024] - firmware 1.0.15 rc1 fixes
- hopefully fixed DutyCycle in Megatune / Logs
- Added MAP based , min and max (Basic Settings)
- Added Tachometer output (Extras / Tachometer)
- Help texts started, added on Basic Settings, Injector Outputs and Tachometer screens, press F1 to get there.
- Mikael Pihlblads VEMS-logger is added to the package, still under testing
- [r023] - firmware v13rc5 fixes
- Fixed offsets for new config parameters
- Added a ALS activated revlimiter
- [r021] second trial for v13 candidate - MP
- dwell in 64usec
- spark changed from (INTspark*90)/255 to INTspark>>1
- VBatt added to log
- [r020] first ini for firmware v13 candidate - MP
- mapADC in real 250Pa units (16bit), no scaling needed in MT any more
- high resolution rpm (16bit)
- more realtime variables
- check dwell, sent out in 4usec resolution in uint8 not uint16, overflows @ 1msec
- [r018] ini file for firmware v12 - EL
- map-sensor scaling fixed
- last version for firmware v12
- [r017] ini file for firmware v12 - MP
- Corrections to iac_conf related things
- page size for t[] & b[] increased to fit both tables
- battfac with scale added
- kpaoffs corrected
- MAP scaling is still a question. With kpaoffs=0 and kpafac=254kPa kPa readings in LCD are correct but MT shows some 70kPa. Changed map formula to map = mapADC and readings matched with std 2.5bar sensor.
- [r016] ini file for STABLE1_0 - MP
- lambda table limited 0.56 .. 1.28
- MAP scaling
- corrected ego_lean_limit -> ego_rich_limit
- iac_conf bits are incorrect
- BUGS:
- kpaoffs conflict vs. firmware v12
- battfac missing from menu, no scaling
- b and t tables are set as pages 2 and 3
- both b and t atables are however under "page = 6" section, ie. page 2
- in comm.c page 2 points to boost TPS table and page 3 to PAGE_PTR_DUMMY ie. &config.
- [r015] ini file for STABLE1_0 - MP
- use correct page for lambda table
- separate scales for PWM/stepper type idle positions, iac stepper msec added
- latest firmware + megatune package, precompiled for 8x8 and kpa config res. = 1[r014]
- changed page order, some minor fixes [r013] -EL
- error in size of table and map scaling, fixed for lambda table [vemsv3_v11_r012]
- afrtable changed to lambda table with proper scales [vemsv3_v11_r011]
- map scaling update [vemsv3_v11_r010]
- even more ini updates [vemsv3_v11_r009.zip]
- some missing IAC stuff added
- rpmk, baro, dbaro added
- LCD settings added
- ego_conf added. What does ego_conf bit5 do (NBO2_adc7) in addition to egoType? ego.c uses it for reading correct ADC channel, could egoType bit used for same purpose?
- more ini updates [vemsv3_v11_r008]
- secondary trigger bits added. TODO: disabling doesn't set secondary_trigger to 0x02
- inj_stage2_tps scaled
- some typos fixed
- more ini updates [vemsv3_v11_r007] (including also r006)
- WOT / RPM actuators submenu added
- Injector staging submenu added
- Knock sampling submenu added
- Knock action submenu added
- Multitooth submenu added
- Some more items addded to Acceleration enrichments menu
- more ini updates [vemsv3_v11_r003]
- added warmup enrichment menu (celcius/farenheit)
- removed std_enrichments
- more ini updates [vemsv3_v11_r002]
- added remaining iac settings
- reorganised iac related variables
- a bit updated [ini-file] for official release above
There is an error in the .ini file - the line
map = { (kpafac/ 255) * mapADC + kpaofs}
should probably be
map = { (kpafac/ 255) * (mapADC + kpaofs/8)}
Or else the readings in megatune will be wrong if the offset calibration is used
BTW, why use the sampled value directly? and not the real value in KPA?
MAP saga
The r14 and r15 ini files still bad.
- maybe just that kpaoffs change not applied to megatune ini files?
- The kpaoffs setting still says mV instead of kPa !!! bad
Firmware calculations: just changed, see fuelcalc.c and GenBoard/Manual/Config/ManifoldAbsolutePressure .
The way we it could be done in Megatune: it recieves sensor8 value of map; sensor8 = sensor11 >> 3
map = { (mapADC * kpafac) / 128 + kpaoffs/4 -32 }
But functionality needs to be tested. Assumed map is needed in 1 kPa unit (not in 250Pa finer resolution, as in firmware).
It's obvious that we can't get the calculation right in megatune, and sending the raw value is bad anyway.
It's best time to break up with the broken 8-bit sensor-raw value, and send the precise and "guaranteed to match what firmware believes" 16 bit engine.kpa250 value to megatune I think megatune will see it as 2 independent 1byte values (x,y), and we make a computed kpa=x*256+y. It's nice for logging as well. 2 kPa resolution is almost useless when one likes to measure air-filter restriction (measure MAP at WOT in function of RPM).
Old ini-s
- [complete release candidate r007] - 2 kpa k-table scaling. Will not be released in this form.
- it contains a firmware, made from the v8 release. Basically comm.c changed to tell more variables to megatune. comm.c changes commited to CVS STABLE1_0 branch. It also touched lcd_display.c for the correct v3.2 EGT channel. I commited an improved version that allows v3.0 and v3.1 users or special hw to select channel via my_make MCP3208_EGT1 define. global.h 2kpa was already commited. The PRG_RDB .. should be commited (to global.h).
- 2 kpa k-table scaling. This will not be released. We will leave the 1kPa setting standard. We only release firmware and megatun* ini files for 1kPa. 2kPa only for advanced users, non default. So any instructions regarding this will start like "if your MAP is sometimes > 255kPa " ... do this and that ... ( use this firmware, this megatune, etc..).
- swapped l-table and n-table fixed
- separate view for iac refpos added
- [r006]
- vemsv3.ini and config.xml for complete r003 package below
- Some corrections to warmup wizard
- MT requires names awc->aseCount, awev->asePct, cwl/cwh -> crankCold/Hot, primep->primePulse and floodClear
- Added missing hybrid_rpm_a, hybrid_rpm_m
- [r005]
- vemsv3.ini and config.xml for complete r003 package below
- digitalout channel selection corrected
- [r004]
- vemsv3.ini and config.xml for complete r003 package below
- updated scales for ign_dwell14+6, ign_crank_advance,engine_off_delay,ego_minrpm, ego_maxrpm ,awev_temp_scaling
- [r003]
- Complete package this time, both firmware and megatune ini
- EGT scaling done for both channels
- 12 bit raw inputs for 6 other 3208-channels, including FP and EBP
- [r002]
- Removed double idle settings
- [r001]
- Menu for miscout1 + 2
- Menu for some idle settings
- Menu for coolant fan+waterpump
- sparkTable scale changed to 0.25, range to 63.25
- [r000]
- complete firmware + unmodified megatune profile (does not work with included firmware)
- added extra adc channels to realtime variables
- Make firmware keep k-table in 1kpa resolution in release unless explicitely said otherwise and documented well.
- Support 12x12 tables (maybe later..not urgent)
KPA_CONFIG_RESOLUTION=2 must not be default - it confused every user who tried.
If we don't directly maintain the ini, but generate the ini file from template (maybe with C preprocessor? or perl?), that has say %%KPA_CONFIG_RESOLUTION%% which gets substituted, than maintenance is not a headache. Actually the example my_make defines KPA_CONFIG_RESOLUTION in a bad way(== instead of =), which results in 1kPa. For 1 kpa resolution, changes needed in some mapBins* lines from 2.0 to 1.0 to get good kpa reading and easier tuning. Note that the r007 ini seems to pretend that some config variables (eg. ego_maxmap) are 1.0 kPa resolution that are 2.0 when KPA_CONFIG_RESOLUTION is defined as 2.
mmtf - the way to configure other tables with old megatune that only knows about VE table
Often used with megatune 2.16 and 2.20.
mmtf (menu megatune fool) makes it possible to trick old VE-only megatune to think it talks to the VE table (j[]) while it is in fact talks to ignition advance (n[]) or lambdacorr (l[]) table.
We keep an internal pointer (called megatune_table), which default points to ve.ref_table (so default behaviour is consistent):
- mttn mmtf
- mttj mmtf
- mttl mmtf
Don't enter the space, only provided on command boundaries for easier reading.
The mtt. command switches to n(,j,l respectively) table and the mmtf fool megatune to see that table instead of the default j[].
You better only issue mtf command when the VE-tuning screen in megatune is closed. Otherwise you risk writing data into the ignition table that you read from the injection table previously, or the other way around, not good..
Most convenient to issue the table-switching command from a directly attached KeyBoard. Issuing it from TerminalProgram works, but more strokes:
- "close megatune"
- connect TerminalProgram
- go to "Man" mode
- issue the commands (wether the above, or any other from GenBoard/MenuSystem, see refcard)
- say "bye" from the TerminalProgram. The ECU says "Bye" if it was in "Man" mode earlier. Megatune will not communicate if you forget the ECM (RS232 menu) in "Man" mode ("Man" mode is for GenBoard/MenuSystem). ECM stays in "Man" mode even if you quit TerminalProgram. if you disconnect TerminalProgram before saying "bye", you have to connect back to say "bye"
- disconnect the TerminalProgram (or quit). Otherwise megatune says it cannot connect to ECM.
- start megatune
Lambda info should live on a subpage of GenBoard/Manual/Tables
Lambda table is important when the system learns the VE, or when mixture is controlled according to the WideBand lambda sensor even at high-power loadsites.
The original combined (VE / lambda) value is useless for this, since the ECM cannot figure out from that what lambda-target the user wants. This was no issue for original Megasquirt, since it cannot learn, nor control for a (MAP, RPM) dependant WBO2 target.
AFR=14.7 * Lambda for gasoline. (Stoich is lambda=1.0 or AFR=14.7)
Of course lambda can be left 0.8 all over the place initially if you like (but take care not to lean where you shouldn't).
Internal scaling for l[] lamdacorr table is
- lambda = 256/(200+l)
- l = (256 / lambda)- 200
Some decimal examples for l[] lamdacorr table (use numberformat=10 option or convert to hexa)
- 0=>1.28 (lean)
- 56=>1.0
- 120=>0.8
- 255=>0.56 (stupid rich, that rich not used for gasoline)
Firmware-workaround was made so megatune can display and input real lambda values like 0.8 (not 1/lambda=1.25 or internal lambdacorr=120) even with the limited formula capabilities (1/x not possible in megatune ini files).
Misc notes
- megatune 2.16 already support COM ports up to 8.
- If you want to make MStweak compatible log files with megatune, MS_COMPATIBILITY must be in your my_make file. If you do this your engine bits will be correct in the log.
We should propose to include the feature to record mono or stereo wav-s that are syncronized to engine logs. It is often useful. Eg. when
- checking the knock sensor freq
- recording front and rear wheel VSS to analyze wheelspin at race-start
- recording IonSense analog output
- recording ground noises for analysis
- Hexadecimal entries
- Binary Entries, checkbox for each bit or something like that..
- function to set the progressive_delay
[[Manual: Basics.Install.Software]]
- MS_COMPATIBILITY was needed in my_make for old mstweak otherwise it got confused of idle state (or just does not use idle mode data for statistics?). MS_COMPATIBILITY is not used for long, at worst the engine_status column can be cured in spreadsheet program so mstweek is not confused.
Back to: MegaTune