View Single Post
      07-11-2023, 11:43 AM   #37
Hyperion42
New Member
11
Rep
6
Posts

Drives: G21
Join Date: Jul 2023
Location: Germany

iTrader: (0)

I want to share my findings, not because they are a particularly breakthrough in decoding the data, but to maybe get someone else to think along with me, and because no one else posted anything in this direction.

To start with something easy/small, I looked at the Pre-LCI G20 data first. Here is the data structure I could come up with to parse the entire staging data (1 and 2 combined):

Code:
struct data
{
    u8 a;
    u8 b;
};

struct section
{
    u8 id;
    be u16 num_data_entries;
    data entries[num_data_entries];
};

section data[while(std::mem::read_unsigned($, 1))] @ 0x00;
I am using ImHex for this, but apart from last line it should be pretty readable for everyone. This data structure can be applied to all of the staging data I've seen here, G20 LCI for both EU and US, as well as G82, and seems to fit quite well. However, as one can easily tell, the data is not really well defined and we have still no idea what is going on here.

Going back to G20 Pre-LCI then to look at the data. There are 5 sections in total, the first section has 15 entries. The first 6 entries are as follows:

Code:
[50, 0], [50, 0] ,[25, 0], [25, 0], [25, 0], [63, 100], ...
My thinking is: As we see the same pairs repeating multiple times, the mapping to specific light modules can't be part of the data. I believe Michael already confirmed that by showing us that coding different staging data from other models, and then comparing the result with the actual model (G21 Pre-LCI with G20 LCI vs the real G20 LCI) seems to play some part of the animation on the wrong light modules.

Furthermore, in all data that has been posted here the first section for all of them has 15 entries - roughly matching the number of LM mappings Michael posted. Looking at the number of entries for all sections, we see for the G20 Pre-LCI: 1: 15, 2: 5, 3: 3, 4: 3, 5: 6

With that I believe the mapping to the light module is actually the index into the entries array. The first section initializes all 15 channels, while the other sections might only specify data for the channels that changed.

Looking then at the first 6 entries of each section we see the following:

Code:
1: [50,  0], [50,  0] ,[25,  0], [25,  0], [25,  0], [63, 100], ...
2: [50,  0], [50,  0], [25,  0], [12, 20], [60, 67]
3: [60, 43], [59, 20], [12,  0]
4: [50,   0], [12, 20], [60, 46]
5: [50, 46], [50, 46], [50, 46], [60, 43], [59, 20], [12,   0]
Could it be that the first part of each tuple is the timedelta, and the second one is the intensity? I don't know, at this point I am stuck as I can't properly match this with the video that Michael posted. Maybe someone else has an idea? Maybe this is also going into a totally wrong direction.

If someone wants to contribute, it would help to create annotations for Michaels videos: Which parts of the lights change, for how long do they change, and when do they start changing. With that we could try to make more sense of the data.
Appreciate 2
BLK.G20215.50