Advice for making sense of a data packet / decoding

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

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.

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

I'm trying to figure out a function I can apply to the 5th byte that will give me the "true" value as an output, without using a look-up table or similar, so any help on figuring this out would be greatly appreciated.

I'm trying to figure out a function I can apply to the 5th byte that will give me the "true" value as an output, without using a look-up table or similar, so any help on figuring this out would be greatly appreciated.

How will you know the "true" value when it bites you in the butt?

What is the mysterious device sending the data?

PaulS:
How will you know the "true" value when it bites you in the butt?

What is the mysterious device sending the data?

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

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

The full range of data is as follows:

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

Even in binary there doesn't seem to be an obvious pattern.

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

The full range of data is as follows:

If this really is the "full range of data" then a lookup table 13 bytes long, with a couple of lines of code, is all you need.

uno52:
The full range of data is as follows:

Even in binary there doesn't seem to be an obvious pattern.

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

Invert the bits

                 pattern   transpose     invert
1101 1010 // 16 x101 1xxx = xxx1 101x = 101 0 010x 2
0001 1010 // 17 x001 1xxx = xxx1 100x = 101 0 011x 3
1110 1010 // 18 x110 1xxx = xxx1 011x = 101 0 100x 4
0010 1010 // 19 x010 1xxx = xxx1 010x = 101 0 101x 5
0100 1010 // 20 x100 1xxx = xxx1 001x = 101 0 110x 6
1000 1010 // 21 x000 1xxx = xxx1 000x = 101 0 111x 7
1111 0010 // 22 x111 0xxx = xxx0 111x = 101 1 000x 8
0011 0010 // 23 x011 0xxx = xxx0 110x = 101 1 001x 9
0101 0010 // 24 x101 0xxx = xxx0 101x = 101 1 010x 10 
1001 0010 // 25 x001 0xxx = xxx0 100x = 101 1 011x 11
0110 0010 // 26 x110 0xxx = xxx0 011x = 101 1 100x 12
1010 0010 // 27 x010 0xxx = xxx0 010x = 101 1 101x 13
1100 0010 // 28 x100 0xxx = xxx0 001x = 101 1 110x 14

I think you have the msb, lsb ordering backwards, and possibly framing (first bit -> byte), polarity inversion

Chuck

chucktodd:
Invert the bits

                 pattern   transpose     invert

1101 1010 // 16 x101 1xxx = xxx1 101x = 101 0 010x 2
0001 1010 // 17 x001 1xxx = xxx1 100x = 101 0 011x 3
1110 1010 // 18 x110 1xxx = xxx1 011x = 101 0 100x 4
0010 1010 // 19 x010 1xxx = xxx1 010x = 101 0 101x 5
0100 1010 // 20 x100 1xxx = xxx1 001x = 101 0 110x 6
1000 1010 // 21 x000 1xxx = xxx1 000x = 101 0 111x 7
1111 0010 // 22 x111 0xxx = xxx0 111x = 101 1 000x 8
0011 0010 // 23 x011 0xxx = xxx0 110x = 101 1 001x 9
0101 0010 // 24 x101 0xxx = xxx0 101x = 101 1 010x 10
1001 0010 // 25 x001 0xxx = xxx0 100x = 101 1 011x 11
0110 0010 // 26 x110 0xxx = xxx0 011x = 101 1 100x 12
1010 0010 // 27 x010 0xxx = xxx0 010x = 101 1 101x 13
1100 0010 // 28 x100 0xxx = xxx0 001x = 101 1 110x 14




I think you have the msb, lsb ordering backwards, and possibly framing (first bit -> byte), polarity inversion

Chuck

Interesting, that seems to make sense.

I believe the first byte (FF) is a preamble, and then the left-most bit of each byte seems to be a parity bit.

I will have a play and see what I can get done, but I really appreciate your help, it's certainly made some progress for me!

Good analysis Chuck!

The first bit (or last bit) seems to be a parity bit for odd parity (all bit patterns have odd nr of 1's)

1 1 0 1 1 0 1 0  // 16 
0 1 0 1 1 0 1 1  // transpose
1 0 1 0 0 1 0 0  // invert
? ? ? n n n n p  // n = number (2), p = parity (odd)

Perhaps the mystery device is a PS2 keyboard.

Paul