|
1
on: Yesterday at 10:20:09 AM
|
||
| Started by adruss85 - Last post by nyet | ||
|
btw ecuxplot 1.2.6 has a bug with detecting the units of lamsoni (actual lambda). I am preparing a fix.
|
||
|
2
on: Yesterday at 06:59:52 AM
|
||
| Started by adruss85 - Last post by adruss85 | ||
|
I turned on post cat O2 as well as went through wiring with a finetooth comb this morning and Lambda is now tracking as requested. Not sure what the actual factor was but it seems much happier now so I can start bumping up the boost again.
I am probably still due a fuel pump though as duty is 80% chasing 0.85 at 12psi. Thanks for the help |
||
|
3
on: Yesterday at 05:55:17 AM
|
||
| Started by Waldie - Last post by Waldie | ||
|
Hi everyone,
I would like to introduce a project I have been working on for some time: ME7 XCP Tool for ETAS INCA. https://github.com/Waldie186/Tool-for-ETAS-INCA-ME7-Realtime-Emulation-with-CobraRTP-and-XCP/releases/tag/Release I use ETAS INCA regularly in my professional work and personally like working with it a lot. INCA is a very powerful calibration and measurement environment and offers much more than the typical map editing tools commonly used for older Bosch ME7 ECUs. The problem is that proper INCA use on ME7 normally requires development hardware such as an ETK7 or 7.1. The idea behind this project is therefore to use ETAS INCA as the calibration frontend for a normal Bosch ME7 ECU together with CobraRTP FlashOnline. The current version has been tested with ETAS INCA 7.2. Current development target: Stable V1.0 HOW IT WORKS The basic workflow is: ETAS INCA ↓ XCP ME7 XCP Tool ↓ Working BIN ↓ CobraRTP Utility ↓ CobraRTP FlashOnline Emulator ↓ Bosch ME7 Changes made in INCA are sent via XCP to the ME7 XCP Tool. The tool writes these changes into the working BIN and performs the required ME7 checksum correction. The CobraRTP Utility monitors the same working file and uploads the changes into the FlashOnline emulator. This makes it possible to use INCA as the actual calibration interface while CobraRTP takes care of transferring the modified calibration data to the ECU emulator. CURRENT FEATURES XCP server for ETAS INCA Tested with INCA 7.2 ME7 512 kB support ME7 1 MB support Automatic checksum correction ME7Sum by nyet included DAM to A2L converter A2L to XCP A2L converter BIN to Intel HEX converter HEX to BIN converter CobraRTP working-file integration XCP DAQ / dummy tracing for testing English and German GUI PREPARING THE FILES Most ME7 projects do not start with a ready-made A2L. Normally you have something like a DAMOS file together with the matching BIN. INCA expects an A2L description and a matching HEX file for the ECU hardware configuration. Additionally, for this XCP implementation the normal A2L has to be converted into an XCP-compatible A2L. This is the reason why the required converters are included directly in the tool. The normal preparation process is: DAMOS ↓ A2L ↓ XCP A2L and BIN ↓ HEX 1. CONVERT DAMOS TO A2L Open the Converter section in the ME7 XCP Tool. Select DAM to A2L and choose the matching DAMOS file. Example: F19W201t.dam ↓ F19W201t.a2l 2. CONVERT A2L TO XCP A2L The generated A2L must then be converted into an XCP-compatible A2L. Select A2L to XCP A2L. Example: F19W201t.a2l ↓ F19W201t_xcp.a2l The generated XCP A2L is the description file that must be used for the XCP hardware in INCA. 3. CONVERT BIN TO HEX INCA also expects the matching HEX file for the hardware configuration. Use the included BIN to HEX converter. Example: F19W201o.bin ↓ F19W201o.hex You should now have at least: F19W201t_xcp.a2l F19W201o.hex F19W201o.bin All files must belong to the same ECU software version. 4. CREATE THE INCA HARDWARE Start INCA and create a new workspace. Open the Hardware Configuration Editor and create a new XCP device. Use the generated XCP A2L as the ECU description and the matching HEX file as the memory image. After that create an INCA experiment using this hardware configuration. 5. CONFIGURE THE ME7 XCP TOOL Open ME7 XCP Tool for ETAS INCA. Select the same XCP A2L. Then select the matching BIN as the working file. Start the XCP server. 6. CONNECT INCA Open the experiment in INCA and connect the XCP device. The calibration objects from the A2L should now be available inside the experiment. Maps such as KFMIRL, KFMIOP, KFZW, LDRXN, LAMFA and many others can then be opened and calibrated directly from INCA. Every calibration change is sent through XCP to the ME7 XCP Tool and written into the working BIN. 7. COBRARTP Open the CobraRTP Utility and configure it to monitor the same working BIN. The complete workflow is then: Change calibration in INCA ↓ XCP ↓ ME7 XCP Tool ↓ Working BIN updated ↓ Checksum corrected ↓ CobraRTP Utility detects the change ↓ Data uploaded into the FlashOnline emulator ↓ ME7 runs with the changed calibration That is the main purpose of the project. CHECKSUMS The tool currently contains separate checksum handling for ME7 512 kB and ME7 1 MB software. ME7Sum by nyet is also included in the project. Checksum correction is handled automatically as part of the calibration workflow. More different software versions still need to be tested before I consider the project Stable V1.0. LIVE MEASUREMENT AND TRACING The next major development step will be real live measurement inside INCA. Currently planned are three possible measurement backends: Live tracing via a custom CAN RAM patch ME7Logger Vehical The goal is to make real ME7 RAM variables available as INCA measurement channels and later also use them for real operating-point tracing. Typical variables would include nmot_w, rl_w, rlsol_w, zwout, zwist, ldtvm, wdkba_w, lamsoni_w, lamsbg_w, fr_w, tmot and others. The goal is not to provide hundreds of variables with poor refresh rates. I would prefer around 40 to 50 useful variables running smoothly and reliably. WHY INCA MEASUREMENT IS INTERESTING One major advantage of using INCA for measurement is that the ECU does not have to be the only data source. Later it should be possible to have ME7 RAM variables together with data from other measurement hardware in the same INCA experiment and recording. For example: ME7 ECU RAM variables Reference wideband lambda meter External analog pressure sensors Additional temperature sensors Thermocouples Other analog measurement devices This means ECU data, reference lambda, pressures, temperatures and other external signals can all be recorded together in one measurement. For dyno work and engine development this is a major advantage compared with running several separate logging programs and trying to synchronize the logs afterwards. This is one of the main reasons why I want to continue developing the measurement side of this project. PLANNED The first target is Stable V1.0. After that the main planned features are live tracing via CAN patch or alternatively ME7Logger / Vehical, real ME7 RAM measurements in INCA, operating-point tracing and support for additional ME7 platforms including 2.7 Biturbo and R32. TESTING I know that not many people in the ME7 community own or use ETAS INCA. Nevertheless, if you have access to INCA and a suitable ME7 setup, I would really appreciate testing and feedback. The more different ECU software versions we can test, the better the chance of getting this project to a genuinely stable V1.0. If you test it, please report your ECU type, part number, Bosch number, software version, whether it is 512 kB or 1 MB, your INCA version, checksum result and XCP connection result. Success reports are just as useful as bug reports. |
||
|
4
on: Yesterday at 05:54:36 AM
|
||
| Started by Waldie - Last post by Waldie | ||
|
Hi everyone,
I would like to introduce a project I have been working on for some time: ME7 XCP Tool for ETAS INCA. https://github.com/Waldie186/Tool-for-ETAS-INCA-ME7-Realtime-Emulation-with-CobraRTP-and-XCP/releases/tag/Release I use ETAS INCA regularly in my professional work and personally like working with it a lot. INCA is a very powerful calibration and measurement environment and offers much more than the typical map editing tools commonly used for older Bosch ME7 ECUs. The problem is that proper INCA use on ME7 normally requires development hardware such as an ETK7 or 7.1. The idea behind this project is therefore to use ETAS INCA as the calibration frontend for a normal Bosch ME7 ECU together with CobraRTP FlashOnline. The current version has been tested with ETAS INCA 7.2. Current development target: Stable V1.0 HOW IT WORKS The basic workflow is: ETAS INCA ↓ XCP ME7 XCP Tool ↓ Working BIN ↓ CobraRTP Utility ↓ CobraRTP FlashOnline Emulator ↓ Bosch ME7 Changes made in INCA are sent via XCP to the ME7 XCP Tool. The tool writes these changes into the working BIN and performs the required ME7 checksum correction. The CobraRTP Utility monitors the same working file and uploads the changes into the FlashOnline emulator. This makes it possible to use INCA as the actual calibration interface while CobraRTP takes care of transferring the modified calibration data to the ECU emulator. CURRENT FEATURES XCP server for ETAS INCA Tested with INCA 7.2 ME7 512 kB support ME7 1 MB support Automatic checksum correction ME7Sum by nyet included DAM to A2L converter A2L to XCP A2L converter BIN to Intel HEX converter HEX to BIN converter CobraRTP working-file integration XCP DAQ / dummy tracing for testing English and German GUI PREPARING THE FILES Most ME7 projects do not start with a ready-made A2L. Normally you have something like a DAMOS file together with the matching BIN. INCA expects an A2L description and a matching HEX file for the ECU hardware configuration. Additionally, for this XCP implementation the normal A2L has to be converted into an XCP-compatible A2L. This is the reason why the required converters are included directly in the tool. The normal preparation process is: DAMOS ↓ A2L ↓ XCP A2L and BIN ↓ HEX 1. CONVERT DAMOS TO A2L Open the Converter section in the ME7 XCP Tool. Select DAM to A2L and choose the matching DAMOS file. Example: F19W201t.dam ↓ F19W201t.a2l 2. CONVERT A2L TO XCP A2L The generated A2L must then be converted into an XCP-compatible A2L. Select A2L to XCP A2L. Example: F19W201t.a2l ↓ F19W201t_xcp.a2l The generated XCP A2L is the description file that must be used for the XCP hardware in INCA. 3. CONVERT BIN TO HEX INCA also expects the matching HEX file for the hardware configuration. Use the included BIN to HEX converter. Example: F19W201o.bin ↓ F19W201o.hex You should now have at least: F19W201t_xcp.a2l F19W201o.hex F19W201o.bin All files must belong to the same ECU software version. 4. CREATE THE INCA HARDWARE Start INCA and create a new workspace. Open the Hardware Configuration Editor and create a new XCP device. Use the generated XCP A2L as the ECU description and the matching HEX file as the memory image. After that create an INCA experiment using this hardware configuration. 5. CONFIGURE THE ME7 XCP TOOL Open ME7 XCP Tool for ETAS INCA. Select the same XCP A2L. Then select the matching BIN as the working file. Start the XCP server. 6. CONNECT INCA Open the experiment in INCA and connect the XCP device. The calibration objects from the A2L should now be available inside the experiment. Maps such as KFMIRL, KFMIOP, KFZW, LDRXN, LAMFA and many others can then be opened and calibrated directly from INCA. Every calibration change is sent through XCP to the ME7 XCP Tool and written into the working BIN. 7. COBRARTP Open the CobraRTP Utility and configure it to monitor the same working BIN. The complete workflow is then: Change calibration in INCA ↓ XCP ↓ ME7 XCP Tool ↓ Working BIN updated ↓ Checksum corrected ↓ CobraRTP Utility detects the change ↓ Data uploaded into the FlashOnline emulator ↓ ME7 runs with the changed calibration That is the main purpose of the project. CHECKSUMS The tool currently contains separate checksum handling for ME7 512 kB and ME7 1 MB software. ME7Sum by nyet is also included in the project. Checksum correction is handled automatically as part of the calibration workflow. More different software versions still need to be tested before I consider the project Stable V1.0. LIVE MEASUREMENT AND TRACING The next major development step will be real live measurement inside INCA. Currently planned are three possible measurement backends: Live tracing via a custom CAN RAM patch ME7Logger Vehical The goal is to make real ME7 RAM variables available as INCA measurement channels and later also use them for real operating-point tracing. Typical variables would include nmot_w, rl_w, rlsol_w, zwout, zwist, ldtvm, wdkba_w, lamsoni_w, lamsbg_w, fr_w, tmot and others. The goal is not to provide hundreds of variables with poor refresh rates. I would prefer around 40 to 50 useful variables running smoothly and reliably. WHY INCA MEASUREMENT IS INTERESTING One major advantage of using INCA for measurement is that the ECU does not have to be the only data source. Later it should be possible to have ME7 RAM variables together with data from other measurement hardware in the same INCA experiment and recording. For example: ME7 ECU RAM variables Reference wideband lambda meter External analog pressure sensors Additional temperature sensors Thermocouples Other analog measurement devices This means ECU data, reference lambda, pressures, temperatures and other external signals can all be recorded together in one measurement. For dyno work and engine development this is a major advantage compared with running several separate logging programs and trying to synchronize the logs afterwards. This is one of the main reasons why I want to continue developing the measurement side of this project. PLANNED The first target is Stable V1.0. After that the main planned features are live tracing via CAN patch or alternatively ME7Logger / Vehical, real ME7 RAM measurements in INCA, operating-point tracing and support for additional ME7 platforms including 2.7 Biturbo and R32. TESTING I know that not many people in the ME7 community own or use ETAS INCA. Nevertheless, if you have access to INCA and a suitable ME7 setup, I would really appreciate testing and feedback. The more different ECU software versions we can test, the better the chance of getting this project to a genuinely stable V1.0. If you test it, please report your ECU type, part number, Bosch number, software version, whether it is 512 kB or 1 MB, your INCA version, checksum result and XCP connection result. Success reports are just as useful as bug reports. |
||
|
5
on: Yesterday at 12:23:11 AM
|
||
| Started by noice - Last post by kacperoooni | ||
|
i need community opinion about different approach i find. i call it double inverse model Won’t work. Most of the things you need to do prj has already written. I made something similiar and using it with success for a long time now.the key is: no new routines and calls! 0. hw: plug MAP sensor instead of MAF 1. pterw: -pterw_w / pterw is the some kind of tank pressures with DSTGRAD / DSTOFS routine perfectly fit for DSS path -replace udst_w (pressure sensor) with uhfm_w -replace signed to unsigned overflow checkings -grad/ofs values should be set to make pter_w/pter same factor as other me7 pressures. 2. mlhfm: linear as the sensor curve are linear too 3. kfkhfm: - axe replace rl -> pterw with respectively axe values from 250 hpa to 2550 hpa - table values goes from 0.12 at idle to 1.8 at the high rpm to multiply MAP reading and simulate MAF sensor - the values at the pterw axe are flat for now, to fix VE model probably 4. log pter_w vs ps_w and mlhfm_w vs msdk_w and fix kfkhfm smoothly <- im here - the models looks promising, i see ps_w pretty close to sensor readings pter_w. so the pros: - pretty easy convertion, no need for new variables, rotuines etc - LP filter already implemented - hfm diagnose absolutely applicable here - failback to alpha-n (hi Nye!) is here in case of sensor failure cons: - pter_w routine called from 1000ms raster. for now its irrelevant due to kfkhfm values are the same for all pterw readings but in case i want to fix that additional call should be placed somewhere questions: -should i cut mste (tev) from frloh_w calculation? -sould i touch KFURL / KFPRG? -what about DV, is it some kind of interventions i should worry about? -what about all of this? logs attached (its 5120 halved pressures) |
||
|
6
on: August 21, 2026, 10:50:52 PM
|
||
| Started by zidane1967 - Last post by _nameless | ||
|
It helps if you actually post the file. OR if you are asking for an original file set, try using a complete sentence.
|
||
|
7
on: August 21, 2026, 05:42:18 PM
|
||
| Started by adruss85 - Last post by _nameless | ||
|
I've not yet looked at your binary, but something is causing your lambda control το be disabled. I'd not push the car, as you're essentially running lambda 1.0 The fact that your Injector duty cycle reaches 85% while making lambda 1.0 also increases the chances of your fuel delivery system having some issue, as nameless said. I was actually going to mention he should check PROKON settings. If you deleted the downstream o2 sensor and messed up the configuration bits, you will have this. |
||
|
8
on: August 21, 2026, 01:18:13 PM
|
||
| Started by adruss85 - Last post by billkgr | ||
|
I've not yet looked at your binary, but something is causing your lambda control το be disabled.
I'd not push the car, as you're essentially running lambda 1.0 The fact that your Injector duty cycle reaches 85% while making lambda 1.0 also increases the chances of your fuel delivery system having some issue, as nameless said. |
||
|
9
on: August 21, 2026, 12:48:30 PM
|
||
| Started by noice - Last post by fknbrkn | ||
|
i need community opinion about different approach i find. i call it double inverse model
the key is: no new routines and calls! 0. hw: plug MAP sensor instead of MAF 1. pterw: -pterw_w / pterw is the some kind of tank pressures with DSTGRAD / DSTOFS routine perfectly fit for DSS path -replace udst_w (pressure sensor) with uhfm_w -replace signed to unsigned overflow checkings -grad/ofs values should be set to make pter_w/pter same factor as other me7 pressures. 2. mlhfm: linear as the sensor curve are linear too 3. kfkhfm: - axe replace rl -> pterw with respectively axe values from 250 hpa to 2550 hpa - table values goes from 0.12 at idle to 1.8 at the high rpm to multiply MAP reading and simulate MAF sensor - the values at the pterw axe are flat for now, to fix VE model probably 4. log pter_w vs ps_w and mlhfm_w vs msdk_w and fix kfkhfm smoothly <- im here - the models looks promising, i see ps_w pretty close to sensor readings pter_w. so the pros: - pretty easy convertion, no need for new variables, rotuines etc - LP filter already implemented - hfm diagnose absolutely applicable here - failback to alpha-n (hi Nye!) is here in case of sensor failure cons: - pter_w routine called from 1000ms raster. for now its irrelevant due to kfkhfm values are the same for all pterw readings but in case i want to fix that additional call should be placed somewhere questions: -should i cut mste (tev) from frloh_w calculation? -sould i touch KFURL / KFPRG? -what about DV, is it some kind of interventions i should worry about? -what about all of this? logs attached (its 5120 halved pressures) |
||
|
10
on: August 21, 2026, 11:56:07 AM
|
||
| Started by zidane1967 - Last post by zidane1967 | ||
|
EEPROM & stock flash of GOLF4 TDI ATD 100HP 038906019CR
|
||