Volvo Forum

dikidera

Since I am analyzing the TF80SC firmware, no I havent found any maps yet (beyond gear ratio tables etc). The firmware I am analyzing is vastly more different than AW55, completely rewritten control stack. I believe the firmware I have is from 2016+ and is written as Gen 2 TF80. I was confused as prometey once said that TF80 and AW55 are plug and play software-wise, but perhaps he was talking about P2 TF80 and the P3 has different codebase.

In any case, after failing to find Current -> PWM conversion register accesses, even after finding all SH2 trickery.

Get this. It loads an address FFFFFFF5 and does an 8 bit left shift, this becomes FFFFF500 to which it adds offsets to access ATUI members. But there was nothing, nowhere where it accessed duty cycle registers.
According to claude opus 4.5, the TF80 Gen 2 tcm might be using an external PWM generator controlled via serial? I would've never guessed this so early on, it was going all over the place and just when I was about to interrupt it, it found that singular clue.

Anyway, I was wondering if there are any PCB shots of the TCMs. My dump comes from 31361502 part number.

The AW55 firmware is nearly completely understood by me, but TF80 Gen 2 is almost completely rewritten.

dikidera

crasbe wrote: ↑13 Jan 2026, 17:32
dikidera wrote: ↑13 Jan 2026, 09:18
Here is a python script, that given a HW part number, will extract all diagnostic parameters with names and units(if applicable) from VIDA. It was written by AI yes. May contain bugs.

Thank you for the script! I played around with SQL requests and some Python parsing too, but your script is a lot nicer indeed.
My VIDA installation is stuck in an old 32-bit Windows 7 VM, so I'll probably have to get a newer Windows version to export the database to SQLite format and actually play around with the script.

What is still unclear to me: as far as I could tell the VIDA database only contains the diagnostic responses? At least the links that vtl posted were all based on diagnostic requests. What I'm interested in is the normal CAN bus communication, which does not include the diagnostic requests.
The goal would be to replace the ECM entirely and "pretend" to be the ECM, which would require replicating all the CAN messages it usually sends. Those aren't the diagnostic messages though.

Is that what the "status" category is for? Is that the data that's sent on the CAN buses during normal operation? (As I said, I haven't played around with your script yet, maybe the answer would be obvious from the output).

Decoding the IDs is the easy part. Knowing what the encoded data is a bit more difficult it requires reverse engineering of the module you wish to emulate.

The first step is extracting the ECM from the car and running on the bench. This allows you to isolate about 90% of the CAN ids the module will "use". Why 90%? Some CAN ids will appear only when IGN Key in POS II and likely communication between ECM<=>CEM and ECM<=>ABS, so some IDs may not appear(or they might).

Second step is extracting the ROM, you need this in order to find the area with the CAN signal configuration. Note, across modules e.g ECM,TCM,ETM the can signal configuration will be stored differently, in different ROM areas, in different structures etc, they dont always follow a clear cut single spec design. CAN IDs as I mentioned are serialized and depend on the MCU's CAN module memory layout.
Usually you have a structure for storing the data and/or encoding it, very simple functions, then for reading(this reads from already stored by the system data) and thirdly is the read/dispatch tables that the system iterates over to construct the ID and send the messages as well as receive.

dikidera

vtl wrote: ↑29 Dec 2025, 07:53
dikidera wrote: ↑29 Dec 2025, 07:43 It is its internal monologue, I just showed its thinking. The fact that it now knows even if its internal monologue is slop, is already a win. Sure, I gave it all my knowledge, it has full access to my IDB file for the TCM, it has all my knowledge, like 1, 1.5+ years of variable naming, comments etc. But it did everything, the full analysis on its own, of things I couldn't do.

And other functions which I could not figure out, it reconstructed the algorithm on its own, I then threw that info on Gemini 3 Pro for full verification and it agreed as well.
So, what problem you were trying to solve before declaring a bankruptcy and turning to AI?

Well for one, the full structure of the CAN signal configuration(at least for tcm). From how specifically the ordering is on the CAN IDs, who sets them specifically, where, what each bit pattern represents.It made mistakes, but if you correct it and nudge in the right path, it seems to produce miracles. Provided the code is not obfuscated though.

From there specific functions related to the hydraulic pressure on some maps.

Here is some output. Note where it said acceptance mask is actually the diagnostic Id 000FFFFE, it was simply wrong there.

Code: Select all

====================================================================================================
TABLE: dword_7ECC8 (off_7EA20 - HCAN0 base)
====================================================================================================
  Header (0x00-0x07): 00 00 00 00 FF FF 00 00
  Acceptance Mask: 0xFFFF

  CAN ID ENTRIES (offset 0x08-0x47):
  Mbox  Offset   Raw Bytes        Encoded      29-bit CAN ID 
  ----------------------------------------------------------------------
  0     0x08     00 00 00 00      (disabled)
  1     0x0C     00 00 00 00      (disabled)
  2     0x10     00 00 00 00      (disabled)
  3     0x14     00 00 00 00      (disabled)
  4     0x18     00 00 00 00      (disabled)
  5     0x1C     00 00 00 00      (disabled)
  6     0x20     00 00 00 00      (disabled)
  7     0x24     00 00 00 00      (disabled)
  8     0x28     00 00 00 00      (disabled)
  9     0x2C     00 00 00 00      (disabled)
  10    0x30     00 00 00 00      (disabled)
  11    0x34     00 00 00 00      (disabled)
  12    0x38     00 00 00 00      (disabled)
  13    0x3C     00 00 00 00      (disabled)
  14    0x40     00 00 00 00      (disabled)
  15    0x44     00 00 00 00      (disabled)

  TRAILING DATA (after CAN IDs):
  Control bytes (0x48-0x57): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Interpretation: M0=off M1=off M2=off M3=off M4=off M5=off M6=off M7=off M8=off M9=off M10=off M11=off M12=off M13=off M14=off M15=off 
  Active mailbox bitmask (0x58-0x5B): 0x0000 = binary 0000000000000000
    Active RX mailboxes: 
  End marker (0x5C-0x5F): FF FF FF FF

====================================================================================================
TABLE: dword_7F128 (hcan0_off_7EA48 - secondary)
====================================================================================================
  Header (0x00-0x07): 00 00 00 00 FF FF 00 00
  Acceptance Mask: 0xFFFF

  CAN ID ENTRIES (offset 0x08-0x47):
  Mbox  Offset   Raw Bytes        Encoded      29-bit CAN ID 
  ----------------------------------------------------------------------
  0     0x08     00 00 00 00      (disabled)
  1     0x0C     00 00 00 00      (disabled)
  2     0x10     00 00 00 00      (disabled)
  3     0x14     00 00 00 00      (disabled)
  4     0x18     00 00 00 00      (disabled)
  5     0x1C     00 00 00 00      (disabled)
  6     0x20     00 00 00 00      (disabled)
  7     0x24     00 00 00 00      (disabled)
  8     0x28     00 00 00 00      (disabled)
  9     0x2C     00 00 00 00      (disabled)
  10    0x30     00 00 00 00      (disabled)
  11    0x34     00 00 00 00      (disabled)
  12    0x38     00 00 00 00      (disabled)
  13    0x3C     0A 85 7C 40      0x0A857C40   0x10A2407C
  14    0x40     CA C6 18 F1      0xCAC618F1   0x18DAF118
  15    0x44     08 09 05 00      0x08090500   0x01200005

  TRAILING DATA (after CAN IDs):
  Control bytes (0x48-0x57): 00 00 00 00 00 00 00 00 00 00 00 00 00 08 08 08
    Interpretation: M0=off M1=off M2=off M3=off M4=off M5=off M6=off M7=off M8=off M9=off M10=off M11=off M12=off M13=on M14=on M15=on 
  Active mailbox bitmask (0x58-0x5B): 0x2000 = binary 0010000000000000
    Active RX mailboxes: 13 
  End marker (0x5C-0x5F): FF FF FF FF

====================================================================================================
TABLE: also_can_ids_7F320 (hcan0_off_7EA70 - MAIN)
====================================================================================================
  Header (0x00-0x07): 00 00 00 00 FF FF 00 00
  Acceptance Mask: 0xFFFF

  CAN ID ENTRIES (offset 0x08-0x47):
  Mbox  Offset   Raw Bytes        Encoded      29-bit CAN ID 
  ----------------------------------------------------------------------
  0     0x08     00 00 00 00      (disabled)
  1     0x0C     00 00 00 00      (disabled)
  2     0x10     00 00 00 00      (disabled)
  3     0x14     0A 8A 06 00      0x0A8A0600   0x11420006
  4     0x18     88 88 24 00      0x88882400   0x11100024
  5     0x1C     0A 85 7C 40      0x0A857C40   0x10A2407C
  6     0x20     08 84 06 00      0x08840600   0x10800006
  7     0x24     08 0A 06 00      0x080A0600   0x01400006
  8     0x28     0A 05 16 00      0x0A051600   0x00A20016
  9     0x2C     08 04 1E 40      0x08041E40   0x0080401E
  10    0x30     0A 02 6C 40      0x0A026C40   0x0042406C
  11    0x34     CA C6 18 F1      0xCAC618F1   0x18DAF118
  12    0x38     08 88 22 00      0x08882200   0x11000022
  13    0x3C     08 09 05 00      0x08090500   0x01200005
  14    0x40     88 06 22 00      0x88062200   0x00D00022
  15    0x44     08 06 2A 40      0x08062A40   0x00C0402A

  TRAILING DATA (after CAN IDs):
  Control bytes (0x48-0x57): 00 00 00 08 08 08 08 08 08 08 08 08 08 08 08 08
    Interpretation: M0=off M1=off M2=off M3=on M4=on M5=on M6=on M7=on M8=on M9=on M10=on M11=on M12=on M13=on M14=on M15=on 
  Active mailbox bitmask (0x58-0x5B): 0x07F8 = binary 0000011111111000
    Active RX mailboxes: 3 4 5 6 7 8 9 10 
  End marker (0x5C-0x5F): FF FF FF FF

====================================================================================================
TABLE: can_ids_7F4FC (off_7EA98)
====================================================================================================
  Header (0x00-0x07): 00 00 00 00 FF FF 00 00
  Acceptance Mask: 0xFFFF

  CAN ID ENTRIES (offset 0x08-0x47):
  Mbox  Offset   Raw Bytes        Encoded      29-bit CAN ID 
  ----------------------------------------------------------------------
  0     0x08     00 00 00 00      (disabled)
  1     0x0C     00 00 00 00      (disabled)
  2     0x10     00 00 00 00      (disabled)
  3     0x14     00 00 00 00      (disabled)
  4     0x18     00 00 00 00      (disabled)
  5     0x1C     00 00 00 00      (disabled)
  6     0x20     00 00 00 00      (disabled)
  7     0x24     00 00 00 00      (disabled)
  8     0x28     0A 8A 06 00      0x0A8A0600   0x11420006
  9     0x2C     88 88 24 00      0x88882400   0x11100024
  10    0x30     0A 85 7C 40      0x0A857C40   0x10A2407C
  11    0x34     08 84 06 00      0x08840600   0x10800006
  12    0x38     08 0A 06 00      0x080A0600   0x01400006
  13    0x3C     0A 05 16 00      0x0A051600   0x00A20016
  14    0x40     08 04 1E 40      0x08041E40   0x0080401E
  15    0x44     0A 02 6C 40      0x0A026C40   0x0042406C

  TRAILING DATA (after CAN IDs):
  Control bytes (0x48-0x57): 00 00 00 00 00 00 00 00 08 08 08 08 08 08 08 08
    Interpretation: M0=off M1=off M2=off M3=off M4=off M5=off M6=off M7=off M8=on M9=on M10=on M11=on M12=on M13=on M14=on M15=on 
  Active mailbox bitmask (0x58-0x5B): 0xFF00 = binary 1111111100000000
    Active RX mailboxes: 8 9 10 11 12 13 14 15 
  End marker (0x5C-0x5F): FF FF FF FF

====================================================================================================
TABLE: unk_7EE88 (off_7EAC0 - HCAN1 base)
====================================================================================================
  Header (0x00-0x07): 00 00 00 00 FF FF 00 00
  Acceptance Mask: 0xFFFF

  CAN ID ENTRIES (offset 0x08-0x47):
  Mbox  Offset   Raw Bytes        Encoded      29-bit CAN ID 
  ----------------------------------------------------------------------
  0     0x08     00 00 00 00      (disabled)
  1     0x0C     00 00 00 00      (disabled)
  2     0x10     00 00 00 00      (disabled)
  3     0x14     00 00 00 00      (disabled)
  4     0x18     00 00 00 00      (disabled)
  5     0x1C     00 00 00 00      (disabled)
  6     0x20     00 00 00 00      (disabled)
  7     0x24     00 00 00 00      (disabled)
  8     0x28     00 00 00 00      (disabled)
  9     0x2C     00 00 00 00      (disabled)
  10    0x30     00 00 00 00      (disabled)
  11    0x34     00 00 00 00      (disabled)
  12    0x38     00 00 00 00      (disabled)
  13    0x3C     00 00 00 00      (disabled)
  14    0x40     00 00 00 00      (disabled)
  15    0x44     00 00 00 00      (disabled)

  TRAILING DATA (after CAN IDs):
  Control bytes (0x48-0x57): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Interpretation: M0=off M1=off M2=off M3=off M4=off M5=off M6=off M7=off M8=off M9=off M10=off M11=off M12=off M13=off M14=off M15=off 
  Active mailbox bitmask (0x58-0x5B): 0x0000 = binary 0000000000000000
    Active RX mailboxes: 
  End marker (0x5C-0x5F): FF FF FF FF

====================================================================================================
TABLE: dword_7F608 (diagnostic_hcan1_off_7EAE8)
====================================================================================================
  Header (0x00-0x07): 00 00 00 00 FF FF 00 00
  Acceptance Mask: 0xFFFF

  CAN ID ENTRIES (offset 0x08-0x47):
  Mbox  Offset   Raw Bytes        Encoded      29-bit CAN ID 
  ----------------------------------------------------------------------
  0     0x08     00 00 00 00      (disabled)
  1     0x0C     00 00 00 00      (disabled)
  2     0x10     00 00 00 00      (disabled)
  3     0x14     00 00 00 00      (disabled)
  4     0x18     00 00 00 00      (disabled)
  5     0x1C     00 00 00 00      (disabled)
  6     0x20     00 00 00 00      (disabled)
  7     0x24     00 00 00 00      (disabled)
  8     0x28     00 00 00 00      (disabled)
  9     0x2C     00 00 00 00      (disabled)
  10    0x30     00 00 00 00      (disabled)
  11    0x34     00 00 00 00      (disabled)
  12    0x38     00 00 00 00      (disabled)
  13    0x3C     CB C6 F1 33      0xCBC6F133   0x18DB33F1
  14    0x40     CA C6 F1 18      0xCAC6F118   0x18DA18F1
  15    0x44     6B 00 FE FF      (acceptance mask entry)

  TRAILING DATA (after CAN IDs):
  Control bytes (0x48-0x57): 00 00 00 00 00 00 00 00 00 00 00 00 00 08 08 08
    Interpretation: M0=off M1=off M2=off M3=off M4=off M5=off M6=off M7=off M8=off M9=off M10=off M11=off M12=off M13=on M14=on M15=on 
  Active mailbox bitmask (0x58-0x5B): 0xE000 = binary 1110000000000000
    Active RX mailboxes: 13 14 15 
  End marker (0x5C-0x5F): FF FF FF FF

====================================================================================================
TABLE: dword_7F7BC (hcan1_off_7EB10 - MAIN HCAN1)
====================================================================================================
  Header (0x00-0x07): 00 00 00 00 FF FF 00 00
  Acceptance Mask: 0xFFFF

  CAN ID ENTRIES (offset 0x08-0x47):
  Mbox  Offset   Raw Bytes        Encoded      29-bit CAN ID 
  ----------------------------------------------------------------------
  0     0x08     00 00 00 00      (disabled)
  1     0x0C     00 00 00 00      (disabled)
  2     0x10     00 00 00 00      (disabled)
  3     0x14     00 00 00 00      (disabled)
  4     0x18     00 00 00 00      (disabled)
  5     0x1C     00 00 00 00      (disabled)
  6     0x20     00 00 00 00      (disabled)
  7     0x24     CB C6 F1 33      0xCBC6F133   0x18DB33F1
  8     0x28     CA C6 F1 18      0xCAC6F118   0x18DA18F1
  9     0x2C     0A 87 00 40      0x0A870040   0x10E24000
  10    0x30     08 0E 26 00      0x080E2600   0x01C00026
  11    0x34     88 07 06 00      0x88070600   0x00F00006
  12    0x38     0A 07 26 40      0x0A072640   0x00E24026
  13    0x3C     0A 03 1E 40      0x0A031E40   0x0062401E
  14    0x40     0A 01 24 40      0x0A012440   0x00224024
  15    0x44     6B 00 FE FF      (acceptance mask entry)

  TRAILING DATA (after CAN IDs):
  Control bytes (0x48-0x57): 00 00 00 00 00 00 00 08 08 08 08 08 08 08 08 08
    Interpretation: M0=off M1=off M2=off M3=off M4=off M5=off M6=off M7=on M8=on M9=on M10=on M11=on M12=on M13=on M14=on M15=on 
  Active mailbox bitmask (0x58-0x5B): 0xFF80 = binary 1111111110000000
    Active RX mailboxes: 7 8 9 10 11 12 13 14 15 
  End marker (0x5C-0x5F): FF FF FF FF

====================================================================================================
TABLE: unk_7F970 (off_7EB38)
====================================================================================================
  Header (0x00-0x07): 00 00 00 00 FF FF 00 00
  Acceptance Mask: 0xFFFF

  CAN ID ENTRIES (offset 0x08-0x47):
  Mbox  Offset   Raw Bytes        Encoded      29-bit CAN ID 
  ----------------------------------------------------------------------
  0     0x08     00 00 00 00      (disabled)
  1     0x0C     00 00 00 00      (disabled)
  2     0x10     00 00 00 00      (disabled)
  3     0x14     00 00 00 00      (disabled)
  4     0x18     00 00 00 00      (disabled)
  5     0x1C     00 00 00 00      (disabled)
  6     0x20     00 00 00 00      (disabled)
  7     0x24     CB C6 F1 33      0xCBC6F133   0x18DB33F1
  8     0x28     CA C6 F1 18      0xCAC6F118   0x18DA18F1
  9     0x2C     0A 87 00 40      0x0A870040   0x10E24000
  10    0x30     08 0E 26 00      0x080E2600   0x01C00026
  11    0x34     88 07 06 00      0x88070600   0x00F00006
  12    0x38     0A 07 26 40      0x0A072640   0x00E24026
  13    0x3C     0A 03 1E 40      0x0A031E40   0x0062401E
  14    0x40     0A 01 24 40      0x0A012440   0x00224024
  15    0x44     6B 00 FE FF      (acceptance mask entry)

  TRAILING DATA (after CAN IDs):
  Control bytes (0x48-0x57): 00 00 00 00 00 00 00 08 08 08 08 08 08 08 08 08
    Interpretation: M0=off M1=off M2=off M3=off M4=off M5=off M6=off M7=on M8=on M9=on M10=on M11=on M12=on M13=on M14=on M15=on 
  Active mailbox bitmask (0x58-0x5B): 0xFF80 = binary 1111111110000000
    Active RX mailboxes: 7 8 9 10 11 12 13 14 15 
  End marker (0x5C-0x5F): FF FF FF FF

====================================================================================================
TABLE: off_7F04C (off_7EB60 - LINBUS)
====================================================================================================
  ** LINBUS table - different format (RAM addresses, not CAN IDs) **
  Raw header: FF FF 00 00 FF FF DD C7 FF FF DE 51 00 07 EC 7C

With this I am able to understand the relationship better of many data structure and reveal patterns previously eluding me.

Treur

vtl wrote: ↑29 Dec 2025, 07:53
dikidera wrote: ↑29 Dec 2025, 07:43 It is its internal monologue, I just showed its thinking. The fact that it now knows even if its internal monologue is slop, is already a win. Sure, I gave it all my knowledge, it has full access to my IDB file for the TCM, it has all my knowledge, like 1, 1.5+ years of variable naming, comments etc. But it did everything, the full analysis on its own, of things I couldn't do.

And other functions which I could not figure out, it reconstructed the algorithm on its own, I then threw that info on Gemini 3 Pro for full verification and it agreed as well.
So, what problem you were trying to solve before declaring a bankruptcy and turning to AI?

Oh, come on.... ))) Yesterday I decompiled some software and fed it all to the AI. It ended up giving me an HTML file with all the sequences (what I should send, what responses I should get, what to catch, and where to crash). Yes, you can figure this out yourself, but it's better to delegate such routine tasks to the AI.

dikidera wrote: ↑29 Dec 2025, 07:43 It is its internal monologue, I just showed its thinking. The fact that it now knows even if its internal monologue is slop, is already a win. Sure, I gave it all my knowledge, it has full access to my IDB file for the TCM, it has all my knowledge, like 1, 1.5+ years of variable naming, comments etc. But it did everything, the full analysis on its own, of things I couldn't do.

And other functions which I could not figure out, it reconstructed the algorithm on its own, I then threw that info on Gemini 3 Pro for full verification and it agreed as well.

So, what problem you were trying to solve before declaring a bankruptcy and turning to AI?

dikidera

vtl wrote: ↑29 Dec 2025, 05:31 I still can't read this slop, it is written like for brain damaged (by brain damaged, too) "By reconstructing the full 29-bit extended CAN ID through bitwise operations, we calculate a substantial identifier value of 0x0080401E, which translates to 8,404,510 in decimal." - zero value in this whole sentence. Actually, negative: I still read it.

It is its internal monologue, I just showed its thinking. The fact that it now knows even if its internal monologue is slop, is already a win. Sure, I gave it all my knowledge, it has full access to my IDB file for the TCM, it has all my knowledge, like 1, 1.5+ years of variable naming, comments etc. But it did everything, the full analysis on its own, of things I couldn't do.

And other functions which I could not figure out, it reconstructed the algorithm on its own, I then threw that info on Gemini 3 Pro for full verification and it agreed as well.

dikidera

For a while now these pressure..there was just something that did not make sense. If the TCM commands 122 psi hold pressure, a static parameter...well that is too low, but according to the internet, at WOT at the clutches we should get up to 287 psi at 80 psi main line pressure

So I guess here we have boost valves/pressure regulator valves affecting these pressures? At 80 psi main line, WOT hold pressure is 287 psi which equals a ~3.6x boost.But at idle 5 psi main line, at high temps clutch pressure could be 73-89 signifying a greater boost of more than 16x.There seems to be a non-linear boost factor.

If we assume at max line pressure of 80 psi that our boost is 3.6, it makes sense for some calculations. A static clutch value of 122.6 psi gets normalized to say max line pressure, in code that is 74 psi for SLT, SLS but 79.7 for SLU. If we have a boost factor of 3.6, then if SLT=MAX, 74 * 3.6 = 266.4 psi and 79.7*3.6=~287 psi. Too easy for this to be the answer, and other things dont make sense.

The math doesn't always check out, cause I routinely have a main line much lower than 74 psi when driving calmly, but SLS can be 62, depending on whatever was computed from maps. It seems like the variables from the valve body design are quite necessary to compute actual pressures here.

dikidera

Despite not touching anything related to 3-4 upshift, I have developed a harsher upshift. For 2-3 I have increase the shift time to almost double to get more smoothness, but in the process of doing so, there is a slight flare but not in all conditions. So instead I plan to reduce shift times to less than the original in effect making the shifts quicker.

I have also done some drains and fills with very small quantities of ATF, like 2 liters so far, no effect yet. But I will do more, this time only original Volvo fluid, I will do 10l, but because it is expensive, I will accumulate over time.

In the process of reverse engineering the tcm shift logic, I have discovered I think the ramp rate parameter, so far it is dimensionless. This also required me to further my understanding of the pressure control logic.
The ramp rate parameter is deferred to the logic that actually calculates current and then duty cycle, that logic is an interrupt handler called every few ms. This is in contrast to my belief that the shift functions responsible for fill time and clutch control also factored in ramp rate.

The ramp rate is a combination of static parameters, feedback from already dispatched and applied pressures, a further transformation from static maps related to temperature(these maps decrease before further being processed in the main interrupt handlers for the solenoids. It is a dynamic value but has a lower limit of 1500 which I cannot figure out if its percentage, if its pressure per X ms.

Example: Minimum ramp rate = 1500. 1500 / 10 = 150 * <value from temp map> which is say 463 for 0C / 1000 = 69; 5200(gf cm2 max pressure perhaps or something else) * 100 / 69 = 7536, 5200 could be anything, I always labeled it as the max possible lube pressure supplied from SLT for SLS but these were early labels. As temp goes up, the computed value decreases and approaches 5200(but ramp rate is dynamically calculated).

This value is then passed on to the interrupt handler along the target pressure. From then we have an interesting thing. We have another table with maximum pressures that more clearly show the actual max pressure to the clutch that SLS can supply, or so I had labeled it.

So it becomes 17333(246 psi) * 1000 / 7536 = 2300 and 2300 is compared to the target pressure for part of the slope and I am guessing gets integrated several times. The target pressure is a complex value, not statically derived and only valid for the first 3 parts of the slope, and there are 5 slopes in total.
Adaptations modify only the first slope which is more directly responsible for whether we have flare or not.

dikidera

prometey1982 wrote: ↑05 May 2025, 08:59
dikidera wrote: ↑05 May 2025, 04:43 I have already reflashed my TCM at least 20 maybe even 30 times. The SH7055 ROM has a max erase cycle of 100 times, and reflashing for small changes is slow and cumbersome.

It will be a real technical challenge to enable real-time tuning on this so I can change the maps on the fly.
100 раз, это оценка снизу. На самом деле, они переживают сильно больше перепрошивок.

I will keep that in mind, thank you prometey.

I have in the process also discovered one of the adaptations for P->R and possibly P->D or even R->D and the clunk or harsh reverse/harsh drive.
The adaptation had a too high pressure set, it actually amounts to a raw pressure of 2.84 PSI, which is not a whole lot, but it is enough to cause a harsh engagement. What I did was invert it, now it was negative 3 or negative 4 psi. Buttery smooth reverse and drive engagements, in fact imperceptible. However it was only tested on a specific gearbox temperature of around 45-50c and an ambient temp of 27c.
It is more than possible that at super low or super high temps(70-80-90c and above) that this too low of a pressure results in slow engagement/delayed. Who knows.

In other experiments I increased the shift time from 2-3 to be nearly double what it was set in an attempt to make it smoother. This did in fact make it smoother BUT I have noticed that as the transmission re-adapted that there is a slight slip in certain situations, aka flare.

prometey1982

dikidera wrote: ↑05 May 2025, 04:43 I have already reflashed my TCM at least 20 maybe even 30 times. The SH7055 ROM has a max erase cycle of 100 times, and reflashing for small changes is slow and cumbersome.

It will be a real technical challenge to enable real-time tuning on this so I can change the maps on the fly.

100 раз, это оценка снизу. На самом деле, они переживают сильно больше перепрошивок.

Search found 90 matches: tcm

Re: Vida CEM swapping

Re: Vida CEM swapping

Re: Vida CEM swapping

Re: Vida CEM swapping

Re: Vida CEM swapping

Re: Vida CEM swapping

Re: Vida CEM swapping

Re: Vida CEM swapping

Re: Vida CEM swapping

Re: Vida CEM swapping