I've recorded some packets from a device which uses two lines to send them; clock, and data.

The device is a temperature controller, and these are the output packets being sent to the dual 7-segment temperature display controller.

Been scratching my head for a while now, but can't seem to see anything obvious that relates the data I have to their "true" values.

Each packet consists of 7 bytes, and only the 5th byte changes.

Below are all of the temperature packets in HEX.

FF 7F 3E FE DA FF 3E // 16
FF 7F 3E FE 1A FF 3E // 17
FF 7F 3E FE EA FF 3E // 18
FF 7F 3E FE 2A FF 3E // 19
FF 7F 3E FE 4A FF 3E // 20
FF 7F 3E FE 8A FF 3E // 21
FF 7F 3E FE F2 FF 3E // 22
FF 7F 3E FE 32 FF 3E // 23
FF 7F 3E FE 52 FF 3E // 24
FF 7F 3E FE 92 FF 3E // 25
FF 7F 3E FE 62 FF 3E // 26
FF 7F 3E FE A2 FF 3E // 27
FF 7F 3E FE C2 FF 3E // 28

The "true" values are at the end of each line, after the "//".

Below is the binary representation of just the 5th byte from each packet.

1101 1010 // 16
0001 1010 // 17
1110 1010 // 18
0010 1010 // 19
0100 1010 // 20
1000 1010 // 21
1111 0010 // 22
0011 0010 // 23
0101 0010 // 24
1001 0010 // 25
0110 0010 // 26
1010 0010 // 27
1100 0010 // 28

There must be some kind of reasonable way to determine the temperature from the packet without the need for a look-up table, but I just can't figure it out!

Any help would be greatly appreciated.

 

There is a pattern. If you read the bits of the 5th byte from right to left and ignore the left-most bit then the values are in a descending sequence.

 

There is a pattern. If you read the bits of the 5th byte from right to left and ignore the left-most bit then the values are in a descending sequence.

So obvious now... I knew it couldn't be that obscure, but when you've been looking at those 1's and 0's for a day, things start looking a bit odd.

Thanks so much for the help!

 

There is a pattern. If you read the bits of the 5th byte from right to left and ignore the left-most bit then the values are in a descending sequence.

Ah, that's the ticket! I had a suspicion that the values were read right to left. Dropping the last bit was the piece I was missing.

Here is a C function to map the decoded values to the "true" results. Note that '*_in' is the decoded values and correspondingly '*_out' is the "true" values.

long map(long x, long in_min, long in_max, long out_min, long out_max)
{
  return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}

 

By my reckoning the left-most bit is a parity bit.

 

Sorry Alec,

Can you work out in detail just any two of them? You said "descending".

Not my best day today.

/EDIT

Now I understand: I was trying to match your process with the decimal numbers on the right as provided by the OP which I conclude, are not correct. That's why.

Checked again the three bottom ones: 35, 34 and finally 33. Descending.

Gracias.

EDIT/

 

Hi Agustin.
Consider the first two values in the table showing the 5th byte.
Ignoring the left-most (parity) bit and reading bits from right to left, true value 16 reads as 0101 101 whereas true value 17 reads as 0101 100, i.e. is one less.

 

By my reckoning the left-most bit is a parity bit.

It does indeed, seems to be odd parity

 

Sorry Alec,

Can you work out in detail just any two of them? You said "descending".

Not my best day today.

/EDIT

Now I understand: I was trying to match your process with the decimal numbers on the right as provided by the OP which I conclude, are not correct. That's why.

Checked again the three bottom ones: 35, 34 and finally 33. Descending.

Gracias.

EDIT/

The "true" values at the end are what the temperature read out on a display is for that packet.

So what I mean is that when the first packet is sent, the reading on the temperature display is 16 degrees, and so on.

I guess my original question may have been a little ambiguous, and I was trying to find the pattern, rather than specifically relating the packets to the "true" value, since when you have the pattern, in this case descending by one each time, it is easy to offset the packet values to get the true value.

There is actually more to this problem than I originally posted, and given the interest and lightning quick responses I'll definitely be updating this thread with the progress I make.

I have been using a logic analyser to read the data, but am now working on writing some code to read the values using an Arduino. Seems to be a little more difficult than anticipated though, since when I plug the clock and data lines from the temperature controller into the Arduino input pins, the temperature controller is not happy at all...

 

OK AAC,

So, the values after // are "actually displayed values". I feel better now. I was trying to match them straight...!

The point then is to find how the algorithm (or is it a hardware display decoder) comes to those displayed ones.

 

Hola again AAC,

What is the maximum temperature that the display is supposed to show?

Thinking in loud voice: values as per Alec's sequence, (45 to 33), deducted from 61 give (16 to 28). Maybe there is a way there. (Yes you said offset).

 

Hola again AAC,

What is the maximum temperature that the display is supposed to show?

Thinking in loud voice: values as per Alec's sequence, (45 to 33), deducted from 61 give (16 to 28). Maybe there is a way there. (Yes you said offset).

16 to 28 is the full range that the display shows, or at least, those are the maximum values this temperature controller allows the temperature to be set at.

 

Found out the issue I was having.

I was assuming that the temperature control unit was sending clock pulses and data, but when I disconnected the display I could not pick up any packets on the Arduino.

I set up my logic analyser to output one of the packets I recorded earlier, and it was registering fine on the Arduino so I assumed my code was okay. Decided to do a bit more probing and it turns out the display unit actually sends the clock pulses, which ironically makes the code easier for me since I can just request data whenever I want it.

 

Hola again AAC,

What is the maximum temperature that the display is supposed to show?

Thinking in loud voice: values as per Alec's sequence, (45 to 33), deducted from 61 give (16 to 28). Maybe there is a way there. (Yes you said offset).

Do you know what the values corresponding the the largest an smallest input value? Decoded, not encoded. Thus "1101 1010" decodes to decimal 87.

With those maximum and minumum values and their corresponding display values, the equation for the display value given any input was posted in post #4.

 

Not C conversant myself but thanks djf