Need help deciphering a riddle, reverse engineering, help decode this!

I am reverse engineering a device that spits out ASCII sentences and I have my code complete and working 100% for gathering the data, parsing it and displaying it on a serial LCD but…

The makers of this device did something weird with how they create the ASCII representation of two HEX numbers for one of the variables.

The data sentences look like this “=029A14000089221716” always starting with = and ending with so far so good right?

Now the variable that I am parsing in this problem is the characters located in position [5] & [6] and this variable is suppose to represent the Advance on an electronic ignition.

Here is the problem that whoever created that thing created for me:

The variables come out in this weird pattern…I can use their graphical monitoring program to see what the Advance is suppose to read and it does not match the actual decimal equivelant of the HEX variable, it is like they used some kind of lookup table or something to create their data. Here is what it looks like:

HEX DEC Equiv What shows on their monitor program Offset

0E 14 20 +6
0F 15 21 +6
10 16 22 +6
(NO 23)
11 17 24 +7
12 18 25 +7
(NO 26)
13 19 27 +8
14 20 28 +8
15 21 29 +8
(NO 30)
16 22 31 +9
17 23 32 +9
(NO 33)
18 24 34 +10
19 25 35 +10
1A 26 36 +10
(NO 37)
1B 27 38 +11
1C 28 39 +11
(NO 40)
1D 29 41 +12
1E 30 42 +12
1F 31 43 +12
(NO 44)
20 32 45 +13

The range of the Advance variable is suppose to be 20-45…

See the patterns? What gives here? So far this is how I have gotten around it:

//ADV DISPLAY
    mySerial.print("?x04?y1"); //Position the cursor
    mySerial.print("  "); //For clearing the ## characters
    mySerial.print("?x04?y1"); //Reposition the cursor
    char ADVData[3]; //Create array for ADV data
    ADVData[0] = string[5]; //Load the first ASCII representation of the first HEX number into the array
    ADVData[1] = string[6]; //Load the second ASCII representation of the second HEX number into the array
    ADVData[2] = '\0'; //Load a Null character into the array
    int ADVBase=16; //Set the base for the strol function to HEX
    long int ADV; //Define the ADV Variable
    ADV = strtol(ADVData, NULL, ADVBase); //Run the strol function on the ADVData array and return the variable to ADV
    if (ADV == 14) chart = 20;
    if (ADV == 15) chart = 21;
    if (ADV == 16) chart = 22;
    if (ADV == 17) chart = 24;
    if (ADV == 18) chart = 25;
    if (ADV == 19) chart = 27;
    if (ADV == 20) chart = 28;
    if (ADV == 21) chart = 29;
    if (ADV == 22) chart = 31;
    if (ADV == 23) chart = 32;
    if (ADV == 24) chart = 34;
    if (ADV == 25) chart = 35;
    if (ADV == 26) chart = 36;
    if (ADV == 27) chart = 38;
    if (ADV == 28) chart = 39;
    if (ADV == 29) chart = 41;
    if (ADV == 30) chart = 42;
    if (ADV == 31) chart = 43;
    if (ADV == 32) chart = 45;
    mySerial.print(chart, DEC); //Print the ADV as developed by the chart above

I have no idea why they would have created their data sentences this way since they lose the ability to display 23,26,30,33,37,40,44 unless the original source for these variables are the limiting factor???

What says the super smart people??? This device that I am making is to for displaying the data from an electronic ignition. The maker of that supplies a graphical computer program to display all this info but I want to do away with the requirement to use a laptop to display the data. The small LCD setup and uController are the answer to this problem…

Can you provide format of the message?
Is it possible, that couple bytes at the end CRC?

I did above…

There is no CRC in these data sentences. Only ASCII representations of HEX numbers that represent 8 variables.

The characters I am refering to above are in positions [5] and [6] and are suppose to represent a decimal number between 20-45 which is the advance angle on an electronic ignition.

I can get the data, parse the data and display the data, the problem is the weirdness in the way they encoded the data as explained above.

I already have a fix in place that works as stated above but I would like to know why they did that and if there is an easier way to parse these two characters knowing what they did is weird…

In this case, there is no magic, my friend.
Just simple ROUND error. Look at the table:

C=A*B D=ROUND( C, 0 ).

14 1.4 19.6 20
15 1.4 21 21
16 1.4 22.4 22
17 1.4 23.8 24
18 1.4 25.2 25
19 1.4 26.6 27
20 1.4 28 28
21 1.4 29.4 29
22 1.4 30.8 31
23 1.4 32.2 32
24 1.4 33.6 34
25 1.4 35 35
26 1.4 36.4 36
27 1.4 37.8 38
28 1.4 39.2 39
29 1.4 40.6 41
30 1.4 42 42
31 1.4 43.4 43
32 1.4 44.8 45
33 1.4 46.2 46
34 1.4 47.6 48
35 1.4 49 49
36 1.4 50.4 50
37 1.4 51.8 52
38 1.4 53.2 53
39 1.4 54.6 55
40 1.4 56 56

Cheers.

See I knew someone would know!!!!

Thanks!!!

You are welcome.

But what kind of device is this?
just curious.

An electronic ignition for an airplane...