|
prj
|
 |
« Reply #105 on: February 09, 2018, 04:59:09 AM »
|
|
|
I think it was like - F(RPM, Pressure) -> аctuator lift? I don't remember exactly, but basically you can set the precontrol map and then set the actuator linearization map the same way as you would do KFLDRL, and it works perfectly fine.
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #106 on: February 09, 2018, 02:41:15 PM »
|
|
|
... some of these boost control related maps (wg valve opening to diff. pressure in the actuator and vice versa) define the wg cracking pressure, so to get the right throttle functioning one would have to touch these too. At least I have not seen the KFVPDKS maps present in other ME7 sorts.
OK, as much as they have the WG opening pressures encoded in them, they have nothing to do with throttle control whatsoever, there is no KFVPDKS in this ECU, but there is one dimensional VPDKSE that gives the vpsspls that I was looking for. On other ME7 the choice between KF... variant with RPM and VPDKSE without is done through codewords, here it is just compiled out (or perhaps the codewords are compile time options on all of them, don't know). Otherwise the code follows the FR for MED9, so no secrets here anymore. The precontrol calculation though - oh dear, I dissected the procedure calculation after calculation (I might be bothered to present it here in some human readable form some time later), and I simply cannot believe that somebody at Bosch decided to spend resources on developing this mess, and that Bosch managed to convince clients that this is the way to go and calibrate boost control. What is left to do is to look carefully at this mess and see if possibly there is a way similar to what you showed in the LDRPID thread - linearizing some maps, flattening others, and perhaps, just perhaps one could narrow down the whole exercise to one map. It would avoid introducing new code. Oh, and no, it should not be to WG lift, it has to be to one step before that, x axis to the map that gives WG lift (HLDSTNGMT), that's what PID corrects. But it is essentially a reversed WG lift with a small offset, so it could be as well to WG lift, just with a different conversion formula. EDIT: looks to me that literally 8-bytes patch would do the trick of turning KFETAVD into RPM x Pressure direct pre-control map, the rest should work out of the box. |
|
|
|
« Last Edit: February 09, 2018, 03:05:21 PM by woj »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #107 on: February 09, 2018, 03:47:59 PM »
|
|
|
There you go...
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #108 on: February 11, 2018, 01:21:07 PM »
|
|
|
(I might be bothered to present it here in some human readable form some time later)
So there it is, re-scalings / precision corrections / capings / etc. are skipped, pvd/pvds/pu are filter / intercooler pressure drops corrected, tpd = pressure downstream turbine, tpu = pressure upstream turbine (or the other way round), not really sure about umsrln, at least it seems to be related to it. Almost certainly there are mistakes in this, including the possibility that I got totally all wrong. Pre-control value pc is: KFOFLVDSNG(nmot_grad, nmot) + umsrln (?) * POTFVPATL(pvds / pu) * iat
-------------------------------------------------------------------------------------------------------------------
KFPFVPATL(tpd / tpu, KFEXPABG(egt, lambda)) * KFCPABGFL(lambda, egt) * egt * KFETAVD(compressor_massflow, pvd / pu) * ETATUR(tpu / tpd) * turbine_massflow
This is then PID corrected and WG lift is taken from HLDSTNGMT(pc_corrected), after which it ends up to be DC after a sequence of maps. Names are according to some guessed translations from the Alfa MiTo damos, totally clueless about some of them: KFOFLVDSNG - Offset for compressor line POTFVPATL - Potential function pressure ratio at the compressor resp. turbine KFPFVPATL - Potential function pressure ratio at the turbine KFEXPABG - Exponent exhaust turbocharger KFCPABGFL - Specific heat capacity ratio exhaust gas to fresh air KFETAVD - Efficiency compressor ETATUR - Efficiency turbine HLDSTNGMT - WG lift from utilization massflow turbine |
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #109 on: February 12, 2018, 03:06:23 PM »
|
|
|
I dug into the WG control and the whole mess with differential pressures in WG actuator and understood a lot of what is going on in there. Out of interesting findings - there is an adaptation mechanism for spring pressure, so these linearizing maps for DC with differential pressures should not matter much, as long as one frees the adaptation ranges appropriately (on my factory bin, for example, slope adaptation is disabled by having a 1.0-1.0 limit on it). And something that has been bothering me for a while - the bit semantics of CWPVDREG:
.0 - enable the above mentioned WG spring pressure adaptation
.1 - something that 80% looks to me like an adaptation slope value inverter for when the boost valve is connected in reverse (0% DC vents to atmosphere rather than WG actuator).
.3 - some additional pvds filtering, OFF on many bins I have seen, but ON on one of the Abarth Esseesse bins I have been looking at once.
|
|
|
|
|
Logged
|
|
|
|
NBR
Full Member
Karma: +20/-7
 Offline
Posts: 79
|
|
« Reply #110 on: February 22, 2018, 05:32:40 AM »
|
|
|
Some very good work here! Will try and digest all of the stuff and organise the maps in Winols. Then call my friend back so we can test out the theory on the dynow
|
|
|
|
|
Logged
|
|
|
|
slickkon
Newbie
Karma: +0/-0
Offline
Posts: 20
|
|
« Reply #111 on: March 02, 2018, 09:07:02 AM »
|
|
|
Hi all,
I've suddenly encountered this really weird problem. when I go on WOT runs, the ECU closes the throttle for a split second at 4500-5000rpm and then goes WOT again.
coincidentally, I had to change the battery on the car. After doing that, the problem went away. couple of days later, it resurfaced again. so I tried resetting the ECU by plugging out the negative on the the battery, and oddly enough the problem went away again. so the cycle carries on.
anyone kind enough to advise on what's wrong? did I fry some part of the ecu by flashing it too many times? lol
Thank in advance!
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #112 on: March 02, 2018, 02:47:55 PM »
|
|
|
I never thought I'd say this myself, but it's probably a good time to post some log and bit more details  |
|
|
|
|
Logged
|
|
|
|
slickkon
Newbie
Karma: +0/-0
Offline
Posts: 20
|
|
« Reply #113 on: March 02, 2018, 04:45:26 PM »
|
|
|
that's the darn thing, I'm still uncertain as to how to take logs (programs?)
Certainly couldn't take logs like VW cars, cos vcds doesn't work with this ECU.
fiatecuscsn is only able to log certain parameters, things like timing CF cannot be monitored. to add to that, the latency on that program is horrible
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #114 on: March 03, 2018, 12:07:32 AM »
|
|
|
Yeah I know, but that's your best option. There you can at least see requested boost / load, boost control DC, etc. might already give some hints.
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #115 on: March 05, 2018, 03:01:07 PM »
|
|
|
OK, a small hack for the inclined ones, maybe somebody will find it useful. One flag in the flash flips the possibility to completely read this ECU out over OBD, including complete RAM contents. (Yes, to be able to read it out, you have to first write it  ). (Not entirely sure if this the locked upload functionality or just the regular read-by-address interface, if these are not the same?) The byte sequence to look for in the flash is (I did not find it on all the bins that I have, maybe these are readable by default?): 00 FF 33 33 3C 00 This should be somewhere before the bin address 0x9C000 (ECU memory address 0xAC000, or on the "longer" bin files). Change the first 00 into 01 and then after starting a diagnostic session with OBD message "10 60" you can OBD with PID 23: 23 XX YY ZZ BB where XX YY ZZ is the starting memory address (can be essentially anything addressable) and BB is the read length, range up to 240 (0xF0). A complete flash readout takes almost 9 minutes this way. Added value is that the RAM that can be read too (E000-FFFF & F0000-F7FFE) has the EEPROM mirror (obviously), so you can read it this way without boot-mode-ing it. Without flipping the flag, only some parts of RAM are readable, flash is not. There is a "permission table" that defines which parts are or are not. With the flag at 01, some checks are still there, but seriously relaxed. |
|
|
|
« Last Edit: March 06, 2018, 05:28:55 AM by woj »
|
Logged
|
|
|
|
Khendal
Full Member
Karma: +9/-8
Offline
Posts: 226
|
|
« Reply #116 on: March 07, 2018, 04:39:39 PM »
|
|
|
I'm beginning to watch/study this ecu...and go inside this Abarth World.
I' ve reading entire thread, and i saw a lot of version of 500 Ecu... 135hp, 140hp, 160hp, 180hp and 190hp, some advice for which it is best to use to start more complete ?
How is the situation nowaday about def files?
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #117 on: March 08, 2018, 02:40:03 PM »
|
|
|
Yes, with the spread of all the special edition versions of F500/Abarth came several versions of this ECU, and in all honesty I do not follow all of them. I studied two particular versions / families - one 120hp version that sits in my car, and one of the older Abarth/SS ones. My 120hp version has a twin factory 150hp version, that is, the code and map locations are identical, they differ only in calibration data, essentially gold to study the maps and proper mapping. For the Abarth one I have also purposely chosen a particular version that has different factory calibrations available, here three, two are similar (150-155hp I think, or was it 150/160, don't know), the third one is the SS version (180hp). This is even more valuable, because the SS has different injectors, fuel rail, 3 bar map sensors, and a turbo with a much stiffer spring in WG.
Functionally these two families are almost identical (here and there are some less important additional maps in the second family), but there are some notable differences in the code. The 120/150 version has an "artificial" cut of the target boost pressure to 2.5bar (see one of my earlier posts), can be bypassed by code editing, and also the KFZWOP map is byte based with RL axis limited to the 191% range (this is also fixable with code editing, albeit a bit less trivial one). On the second family the artificial boost pressure limit is not there, and KFZWOP is word based with full range axis. Also, the second family code supports automatic transmission, the first family does not. Finally, the second family can handle (from what I can tell) an impulse based speed sensor from the gearbox, while the first family only takes speed from CAN/ABS.
These are the only differences I noted so far, and after having said all that I should post the associated bins (some of them again) I guess, so here they go - family 1 is P684 and P685, family 2 is P409 and the two P662-s. As for definitions, publicly available is only the Alfa MiTo 135hp version to be found earlier in the thread, I also attached the bin (P688). Otherwise tedious compare and match work, a bit difficult because the definition does not have all the maps and some of them messed up (badly), some times in offsets, sometimes in conversions / units.
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #118 on: March 09, 2018, 09:04:11 AM »
|
|
|
After some experimentation and logging on the car I can now also confirm that the internal range of the psr and psrs/pssol variables on these ECUs is 5120hpa, even on my smaller 120hp one.
|
|
|
|
|
Logged
|
|
|
|
|
IamwhoIam
|
|
« Reply #119 on: March 09, 2018, 09:12:50 AM »
|
|
|
hehehehehe, I was thinking that when I suggested it |
|
|
|
|
Logged
|
I have no logs because I have a boost gauge (makes things easier)
|
|
|
|
