Description for some unknown values

[VladLupashevskyi]

Just wanted to share what I found out:

In JSON there are Unk1 and Unk2 in GlobalPresentations.Scales.

I just did quick analysis of "DT_Zielgang" and "DT_istgang" for EGS52. As you might notice it mentions the same BitPosition and Size for both (1 byte). But actually this one byte contains both values.

And exactly these Unk1 and Unk2 specify which enum corresponds to which value.

Unk1 and Unk2 are always equal for this example, but I might assume that in can also specify the range.

To understand it better just do a diff for both presentations :)

[jglim]

Hello VladLupashevskyi,

That as an interesting find, appreciate the push in the right direction. I think I understand your meaning that the enum mappings are defined by Unk1/Unk2 (since they seem to be always equal).

Assuming DT_Istgang (target gear?) is run, the result can then be interpreted based on its 1-byte result:

Response	Enum
0x00	"N"
0x01	"1"
0x02	"2"
0x03	"3"
0x04	"4"
0x05	"5"
0x0B	"R"
0x0C	"R (2.)"
0x0D	"P"
0x0E	"Kraftfrei"
0x0F	"Unplausibel"

When I find time, I will check if there are more occurrences, as I am curious about the duplication of value in Unk1/Unk2 as well. Thanks again for your time and effort to write this issue.

[VladLupashevskyi]

@jglim That's absolutely correct and matches the value I'm getting from the real TCM. Also that matches the CAN data which @rnd-ash has described here (enums GS_GIC and GS_GZC): https://github.com/rnd-ash/ultimate_nag52/blob/13f16275b90f295ad6a5aeeb3e3580b0827fc446/can_frames/can_c_enums.h#L112

The reason why there is a gap 0x06-0x0A, because these values are not used for the EGS52, but used for CVT for example. Istgang from german is the actual gear and Zielgang is the target gear.

[VladLupashevskyi]

@jglim So I think I was right that Unk1 and Unk2 specify the range, go to PRES_Wahlprogramm of EGS52 and check the last value where you have a pair of Unk1 and Unk2 as 4 - 255 which corresponds to out of range value and makes totally sense.

[rnd-ash]

@jglim @VladLupashevskyi , I have found other CBF values that use nibbles to represent data. Same is also in a lot of CAN Data that I have. From scanning through CaesarSuite, it appears you set your minimum data length as being 8 (1 bytes).

Also to note @jglim , there are some data values I found in KL203M.CBF that are offset by an odd number of bits.

[jglim]

@VladLupashevskyi Thanks! That fits well, and I've implemented the changes.

@rnd-ash That's correct, the project currently ignores bits that are not byte-aligned as I do not know if the CBF format has a specifier for non-standard bit order. With enough testing, the (artificial) restriction can probably be lifted.

[VladLupashevskyi]

@jglim Just one this I also noticed is that Unk13 from global presentations sometimes shows the max value enum can have. And Unk1b is always 3 if it's enum, or 2,5,6 if it's just a number

[jglim]

Got it, this Unk13 change looks correct in EGS52 and I'll rename it to EnumMaxValue in a later commit.

Unk1b seems to contain type information, though I am still cautious about naming as the canonical type definition. The original c32s library has a rather difficult way of describing types, and I've tried to replicate some of its behavior (including using Unk1b), seen around this snippet: https://github.com/jglim/CaesarSuite/blob/0026efcc8fdd22ed7706ddfd76c37e14b401e700/Caesar/Caesar/DiagPresentation.cs#L351

• 2: hexdump, though c32 has a different way of inferring that type
• 5: looks like unsigned integer, but could be wrong
• 6 : ascii dump
• 7: no idea, just following the disassembly
• 8: regular number